From jira-events at lists.jboss.org  Tue Oct  1 02:15:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 1 Oct 2013 02:15:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1507) Investigate failure in
 StatefulWithXPCFailoverTestCase
In-Reply-To: <JIRA.12494123.1371055191000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494123.1371055191000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494123.1371055191000.7468.1380608103837@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808449#comment-12808449 ] 

RH Bugzilla Integration commented on WFLY-1507:
-----------------------------------------------

Richard Jan?k <rjanik at redhat.com> made a comment on [bug 963610|https://bugzilla.redhat.com/show_bug.cgi?id=963610]

I haven't seen testBasicXPC fail, but there is a fail in testSecondLevelCache. I'm putting it here, since the stacktraces are largely the same and it is also possible that testBasicXPC will show itself in time. I have also changed the name of the bug to better reflect this.

Seen here: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-jgroups-tcpgossip-rhel-matrix/65/jdk=ibm16,label=RHEL6_x86/testReport/org.jboss.as.test.clustering.cluster.ejb3.xpc/StatefulWithXPCFailoverTestCase%28ASYNC-tcp%29/testSecondLevelCache/

Error Message

expected:<200> but was:<500>

Stacktrace

java.lang.AssertionError: expected:<200> but was:<500>
	at org.junit.Assert.fail(Assert.java:88)
	at org.junit.Assert.failNotEquals(Assert.java:743)
	at org.junit.Assert.assertEquals(Assert.java:118)
	at org.junit.Assert.assertEquals(Assert.java:555)
	at org.junit.Assert.assertEquals(Assert.java:542)
	at org.jboss.as.test.clustering.ClusterHttpClientUtil.establishView(ClusterHttpClientUtil.java:53)
	at org.jboss.as.test.clustering.cluster.ejb3.xpc.StatefulWithXPCFailoverTestCase.establishView(StatefulWithXPCFailoverTestCase.java:303)
	at org.jboss.as.test.clustering.cluster.ejb3.xpc.StatefulWithXPCFailoverTestCase.testSecondLevelCache(StatefulWithXPCFailoverTestCase.java:159)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
	at java.lang.reflect.Method.invoke(Method.java:611)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
	at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:270)
	at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
	at sun.reflect.GeneratedMethodAccessor15.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
	at java.lang.reflect.Method.invoke(Method.java:611)
	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
	at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:53)
	at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
	at java.lang.reflect.Method.invoke(Method.java:611)
	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
	at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
	at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129)
	at sun.reflect.GeneratedMethodAccessor13.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
	at java.lang.reflect.Method.invoke(Method.java:611)
	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89)
	at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
	at java.lang.reflect.Method.invoke(Method.java:611)
	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
	at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
	at java.lang.reflect.Method.invoke(Method.java:611)
	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
	at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
	at java.lang.reflect.Method.invoke(Method.java:611)
	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111)
	at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263)
	at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226)
	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
	at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
	at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
	at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185)
	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
	at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
	at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
	at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234)
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133)
	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
	at java.lang.reflect.Method.invoke(Method.java:611)
	at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188)
	at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166)
	at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101)
	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)

Standard Output

&#27;[0m03:42:03,794 INFO  [stdout] (http-/127.0.0.1:8080-1) [node-0/ejb, node-1/ejb] != [node-0/ejb], waiting for a view change event...
&#27;[0m&#27;[0m03:42:14,156 INFO  [org.jboss.as.clustering] (Incoming-6,shared=tcp) JBAS010225: New cluster view for partition ejb (id: 1, delta: 1, merge: true) : [node-0/ejb, node-1/ejb]
&#27;[0m&#27;[0m03:42:14,159 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-6,shared=tcp) ISPN000093: Received new, MERGED cluster view: MergeView::[node-0/ejb|1] [node-0/ejb, node-1/ejb], subgroups=[node-1/ejb|0] [node-1/ejb], [node-0/ejb|0] [node-0/ejb]
&#27;[0m&#27;[0m03:42:14,163 INFO  [org.jboss.as.clustering] (Incoming-8,shared=tcp) JBAS010226: New cluster view for partition ejb: 1 (org.jboss.as.clustering.impl.CoreGroupCommunicationService$GroupView at 43834383 delta: 1, merge: true)
&#27;[0m&#27;[0m03:42:14,167 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-8,shared=tcp) ISPN000093: Received new, MERGED cluster view: MergeView::[node-0/ejb|1] [node-0/ejb, node-1/ejb], subgroups=[node-1/ejb|0] [node-1/ejb], [node-0/ejb|0] [node-0/ejb]
&#27;[0m&#27;[33m03:42:14,165 WARN  [org.jgroups.protocols.pbcast.NAKACK] (Incoming-7,shared=tcp) JGRP000011: node-1/ejb: dropped message 1 from non-member node-0/ejb (view=MergeView::[node-0/ejb|1] [node-0/ejb, node-1/ejb], subgroups=[node-1/ejb|0] [node-1/ejb], [node-0/ejb|0] [node-0/ejb])
&#27;[0m&#27;[31m03:42:18,825 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/stateful].[org.jboss.as.test.clustering.ViewChangeListenerServlet]] (http-/127.0.0.1:8080-1) JBWEB000236: Servlet.service() for servlet org.jboss.as.test.clustering.ViewChangeListenerServlet threw exception: java.lang.InterruptedException: Cluster 'ejb' failed to establish view [node-0/ejb, node-1/ejb] within 15000 ms.  Current view is: [node-0/ejb]
	at org.jboss.as.test.clustering.ViewChangeListenerBean.establishView(ViewChangeListenerBean.java:77) [classes:]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) [rt.jar:1.6.0]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) [rt.jar:1.6.0]
	at java.lang.reflect.Method.invoke(Method.java:611) [rt.jar:1.6.0]
	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72) [jboss-as-ee-7.3.0.Final-redhat-6.jar:7.3.0.Final-redhat-6]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:58) [jboss-as-ee-7.3.0.Final-redhat-6.jar:7.3.0.Final-redhat-6]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:58) [jboss-as-ee-7.3.0.Final-redhat-6.jar:7.3.0.Final-redhat-6]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [jboss-as-ejb3-7.3.0.Final-redhat-6.jar:7.3.0.Final-redhat-6]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) [jboss-as-jpa-7.3.0.Final-redhat-6.jar:7.3.0.Final-redhat-6]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53) [jboss-as-ee-7.3.0.Final-redhat-6.jar:7.3.0.Final-redhat-6]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) [jboss-as-ejb3-7.3.0.Final-redhat-6.jar:7.3.0.Final-redhat-6]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:272) [jboss-as-ejb3-7.3.0.Final-redhat-6.jar:7.3.0.Final-redhat-6]
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:339) [jboss-as-ejb3-7.3.0.Final-redhat-6.jar:7.3.0.Final-redhat-6]
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:238) [jboss-as-ejb3-7.3.0.Final-redhat-6.jar:7.3.0.Final-redhat-6]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
	at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79) [jboss-as-ejb3-7.3.0.Final-redhat-6.jar:7.3.0.Final-redhat-6]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [jboss-as-ejb3-7.3.0.Final-redhat-6.jar:7.3.0.Final-redhat-6]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [jboss-as-ejb3-7.3.0.Final-redhat-6.jar:7.3.0.Final-redhat-6]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [jboss-as-ejb3-7.3.0.Final-redhat-6.jar:7.3.0.Final-redhat-6]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) [jboss-as-ee-7.3.0.Final-redhat-6.jar:7.3.0.Final-redhat-6]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [jboss-as-ejb3-7.3.0.Final-redhat-6.jar:7.3.0.Final-redhat-6]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
	at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45) [jboss-as-ee-7.3.0.Final-redhat-6.jar:7.3.0.Final-redhat-6]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165) [jboss-as-ee-7.3.0.Final-redhat-6.jar:7.3.0.Final-redhat-6]
	at org.jboss.as.ejb3.remote.LocalEjbReceiver.processInvocation(LocalEjbReceiver.java:249) [jboss-as-ejb3-7.3.0.Final-redhat-6.jar:7.3.0.Final-redhat-6]
	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:181) [jboss-ejb-client-1.0.23.Final-redhat-1.jar:1.0.23.Final-redhat-1]
	at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocation(EJBObjectInterceptor.java:58) [jboss-ejb-client-1.0.23.Final-redhat-1.jar:1.0.23.Final-redhat-1]
	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183) [jboss-ejb-client-1.0.23.Final-redhat-1.jar:1.0.23.Final-redhat-1]
	at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocation(EJBHomeInterceptor.java:83) [jboss-ejb-client-1.0.23.Final-redhat-1.jar:1.0.23.Final-redhat-1]
	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183) [jboss-ejb-client-1.0.23.Final-redhat-1.jar:1.0.23.Final-redhat-1]
	at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:42) [jboss-ejb-client-1.0.23.Final-redhat-1.jar:1.0.23.Final-redhat-1]
	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183) [jboss-ejb-client-1.0.23.Final-redhat-1.jar:1.0.23.Final-redhat-1]
	at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:125) [jboss-ejb-client-1.0.23.Final-redhat-1.jar:1.0.23.Final-redhat-1]
	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183) [jboss-ejb-client-1.0.23.Final-redhat-1.jar:1.0.23.Final-redhat-1]
	at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:253) [jboss-ejb-client-1.0.23.Final-redhat-1.jar:1.0.23.Final-redhat-1]
	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:198) [jboss-ejb-client-1.0.23.Final-redhat-1.jar:1.0.23.Final-redhat-1]
	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181) [jboss-ejb-client-1.0.23.Final-redhat-1.jar:1.0.23.Final-redhat-1]
	at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144) [jboss-ejb-client-1.0.23.Final-redhat-1.jar:1.0.23.Final-redhat-1]
	at com.sun.proxy.$Proxy68.establishView(Unknown Source)
	at org.jboss.as.test.clustering.ViewChangeListenerServlet.doGet(ViewChangeListenerServlet.java:70) [classes:]
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:734) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
	at org.jboss.modcluster.container.jbossweb.JBossWebContext$RequestListenerValve.event(JBossWebContext.java:91)
	at org.jboss.modcluster.container.jbossweb.JBossWebContext$RequestListenerValve.invoke(JBossWebContext.java:72)
	at org.jboss.as.web.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:134) [jboss-as-web-7.3.0.Final-redhat-6.jar:7.3.0.Final-redhat-6]
	at org.jboss.as.web.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:99) [jboss-as-web-7.3.0.Final-redhat-6.jar:7.3.0.Final-redhat-6]
	at org.jboss.as.web.session.JvmRouteValve.invoke(JvmRouteValve.java:92) [jboss-as-web-7.3.0.Final-redhat-6.jar:7.3.0.Final-redhat-6]
	at org.jboss.as.web.session.LockingValve.invoke(LockingValve.java:64) [jboss-as-web-7.3.0.Final-redhat-6.jar:7.3.0.Final-redhat-6]
	at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.3.0.Final-redhat-6.jar:7.3.0.Final-redhat-6]
	at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.3.0.Final-redhat-6.jar:7.3.0.Final-redhat-6]
	at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.3.0.Final-redhat-6.jar:7.3.0.Final-redhat-6]
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:336) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:920) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
	at java.lang.Thread.run(Thread.java:738) [vm.jar:1.6.0]

&#27;[0m
                
> Investigate failure in StatefulWithXPCFailoverTestCase
> ------------------------------------------------------
>
>                 Key: WFLY-1507
>                 URL: https://issues.jboss.org/browse/WFLY-1507
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: jaikiran pai
>            Assignee: Paul Ferraro
>            Priority: Blocker
>             Fix For: 8.0.0.Alpha2
>
>         Attachments: log2.txt
>
>
> Numerous exceptions are reported and the tests fails intermittently but often in StatefulWithXPCFailoverTestCase.
> Entire logs attached.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Tue Oct  1 02:15:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 1 Oct 2013 02:15:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1507) Investigate failure in
 StatefulWithXPCFailoverTestCase
In-Reply-To: <JIRA.12494123.1371055191000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494123.1371055191000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494123.1371055191000.7471.1380608104077@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808450#comment-12808450 ] 

RH Bugzilla Integration commented on WFLY-1507:
-----------------------------------------------

Richard Jan?k <rjanik at redhat.com> changed the Status of [bug 963610|https://bugzilla.redhat.com/show_bug.cgi?id=963610] from ON_QA to ASSIGNED
                
> Investigate failure in StatefulWithXPCFailoverTestCase
> ------------------------------------------------------
>
>                 Key: WFLY-1507
>                 URL: https://issues.jboss.org/browse/WFLY-1507
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: jaikiran pai
>            Assignee: Paul Ferraro
>            Priority: Blocker
>             Fix For: 8.0.0.Alpha2
>
>         Attachments: log2.txt
>
>
> Numerous exceptions are reported and the tests fails intermittently but often in StatefulWithXPCFailoverTestCase.
> Entire logs attached.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Tue Oct  1 02:43:02 2013
From: jira-events at lists.jboss.org (Aftab Khan (JIRA))
Date: Tue, 1 Oct 2013 02:43:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-207) Inconsistent Stack Map when
 inserting throw Expression with Java 7
In-Reply-To: <JIRA.12495073.1372170431000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495073.1372170431000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495073.1372170431000.7495.1380609782822@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JASSIST-207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aftab Khan updated JASSIST-207:
-------------------------------

    Attachment: AGDelegateImpl.class

    
> Inconsistent Stack Map when inserting throw Expression with Java 7
> ------------------------------------------------------------------
>
>                 Key: JASSIST-207
>                 URL: https://issues.jboss.org/browse/JASSIST-207
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.18.0-GA
>            Reporter: Ben Romberg
>            Assignee: Shigeru Chiba
>            Priority: Critical
>             Fix For: 3.18.1-GA, 3.19.0-GA
>
>         Attachments: afterInsertThrowExpression.txt, AGDelegateImpl.class, beforeInsertThrowExpression.txt, conditionalThrowExceptionInserted.txt
>
>
> I wrote a unit-test for javassist, reproducing the issue:
> {code}
> public class ThrowExpressionCorruptsStackMapTableTest extends JvstTestRoot {
> 	public ThrowExpressionCorruptsStackMapTableTest(String name) {
> 		super(name);
> 	}
> 	public void testInsertLocalVars() throws Exception {
> 		CtClass cc = sloader.get("test4.LocalVars");
> 		CtMethod m1 = cc.getDeclaredMethod("run");
> 		m1.insertBefore("throw new AssertionError((Object) \"assertion error\");");
> 		cc.writeFile();
> 		Object obj = make(cc.getName());
> 		assertEquals(10, invoke(obj, "run"));
> 	}
> }
> {code}
> Throws:
> java.lang.VerifyError: Expecting a stack map frame in method test4.LocalVars.run()I at offset 45
> My use-case is almost the same, inserting a "throw AssertionError(...)" expression with insertBefore. However, I get a slightly different error message:
> Stack map does not match the one at exception handler 37 in method timeofday.TimeOfDay.getSecond()I at offset 27

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 02:45:02 2013
From: jira-events at lists.jboss.org (Aftab Khan (JIRA))
Date: Tue, 1 Oct 2013 02:45:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-207) Inconsistent Stack Map when
 inserting throw Expression with Java 7
In-Reply-To: <JIRA.12495073.1372170431000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495073.1372170431000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495073.1372170431000.7501.1380609902952@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JASSIST-207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808453#comment-12808453 ] 

Aftab Khan commented on JASSIST-207:
------------------------------------

Hi Shigeru,
I am facing the same issue in javassist-3.18.1-GA .
I have attached the class file for reference

The error message i am getting is:
Caused by: java.lang.VerifyError: Expecting a stackmap frame at branch target 416 in method com.emeter.activitygwy.transport.AGDelegateImpl.processWorkResponseMessage$Impl(Lcom/emeter/activitygwy/xsd/activitygwy/gen/WorkResponseMessageDocument;)V at offset 379
        at java.lang.Class.getDeclaredConstructors0(Native Method)
        at java.lang.Class.privateGetDeclaredConstructors(Class.java:2404)
        at java.lang.Class.getDeclaredConstructors(Class.java:1853)
        at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.determineCandidateConstructors(AutowiredAnnotationBeanPostProcessor.java:229)
        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.determineConstructorsFromBeanPostProcessors(AbstractAutowireCapableBeanFactory.java:962)
        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:935)
        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:485)
        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456)
        at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:294)
        at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:225)
        at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:291)
        at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193)
        at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveReference(BeanDefinitionValueResolver.java:322)
        at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:106)
        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyPropertyValues(AbstractAutowireCapableBeanFactory.java:1360)
        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1118)
        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:517)
        ... 25 more

Please help regarding the same.

Regards,
Aftab


                
> Inconsistent Stack Map when inserting throw Expression with Java 7
> ------------------------------------------------------------------
>
>                 Key: JASSIST-207
>                 URL: https://issues.jboss.org/browse/JASSIST-207
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.18.0-GA
>            Reporter: Ben Romberg
>            Assignee: Shigeru Chiba
>            Priority: Critical
>             Fix For: 3.18.1-GA, 3.19.0-GA
>
>         Attachments: afterInsertThrowExpression.txt, AGDelegateImpl.class, beforeInsertThrowExpression.txt, conditionalThrowExceptionInserted.txt
>
>
> I wrote a unit-test for javassist, reproducing the issue:
> {code}
> public class ThrowExpressionCorruptsStackMapTableTest extends JvstTestRoot {
> 	public ThrowExpressionCorruptsStackMapTableTest(String name) {
> 		super(name);
> 	}
> 	public void testInsertLocalVars() throws Exception {
> 		CtClass cc = sloader.get("test4.LocalVars");
> 		CtMethod m1 = cc.getDeclaredMethod("run");
> 		m1.insertBefore("throw new AssertionError((Object) \"assertion error\");");
> 		cc.writeFile();
> 		Object obj = make(cc.getName());
> 		assertEquals(10, invoke(obj, "run"));
> 	}
> }
> {code}
> Throws:
> java.lang.VerifyError: Expecting a stack map frame in method test4.LocalVars.run()I at offset 45
> My use-case is almost the same, inserting a "throw AssertionError(...)" expression with insertBefore. However, I get a slightly different error message:
> Stack map does not match the one at exception handler 37 in method timeofday.TimeOfDay.getSecond()I at offset 27

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 03:14:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 1 Oct 2013 03:14:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-268) Delayed rule schedules are
 computed erroneously
In-Reply-To: <JIRA.12500980.1379579634000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500980.1379579634000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500980.1379579634000.7517.1380611642614@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-268:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> Delayed rule schedules are computed erroneously
> -----------------------------------------------
>
>                 Key: DROOLS-268
>                 URL: https://issues.jboss.org/browse/DROOLS-268
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final,  6.0.0.CR3
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>             Fix For: 6.0.0.Final
>
>
> Consider the following case, where all patterns are events
> $a : A()
> $b : B()
> not C( this after[0,N] $a )
> When the schedule time is computed, the ACTIVATION timestamp is considered
> as the starting timestamp, rather than $a's timestamp.
> If $b is insert after $a, the rule's schedule will be N time units after $b.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 03:16:03 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 1 Oct 2013 03:16:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-268) Delayed rule schedules are
 computed erroneously
In-Reply-To: <JIRA.12500980.1379579634000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500980.1379579634000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500980.1379579634000.7520.1380611763867@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-268.
--------------------------------

    Fix Version/s: 5.5.1.Final
       Resolution: Done

    
> Delayed rule schedules are computed erroneously
> -----------------------------------------------
>
>                 Key: DROOLS-268
>                 URL: https://issues.jboss.org/browse/DROOLS-268
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final,  6.0.0.CR3
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> Consider the following case, where all patterns are events
> $a : A()
> $b : B()
> not C( this after[0,N] $a )
> When the schedule time is computed, the ACTIVATION timestamp is considered
> as the starting timestamp, rather than $a's timestamp.
> If $b is insert after $a, the rule's schedule will be N time units after $b.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 03:18:03 2013
From: jira-events at lists.jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Tue, 1 Oct 2013 03:18:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-257) Past events beyond
 expiration are not expired
In-Reply-To: <JIRA.12500351.1378778236000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500351.1378778236000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500351.1378778236000.7535.1380611883495@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-257:
------------------------------------------

    Fix Version/s: 6.0.0.CR5
                       (was:  6.0.0.CR4)

    
> Past events beyond expiration are not expired
> ---------------------------------------------
>
>                 Key: DROOLS-257
>                 URL: https://issues.jboss.org/browse/DROOLS-257
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final,  6.0.0.CR3
>            Reporter: Davide Sottara
>            Assignee: Mark Proctor
>            Priority: Critical
>             Fix For: 5.5.1.Final, 6.0.0.CR5
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 03:18:03 2013
From: jira-events at lists.jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Tue, 1 Oct 2013 03:18:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-254) "Exists OR" rules are
 compiled inconsistently
In-Reply-To: <JIRA.12500231.1378486146000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500231.1378486146000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500231.1378486146000.7539.1380611883673@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-254:
------------------------------------------

    Fix Version/s: 6.0.0.CR5
                       (was:  6.0.0.CR4)

    
> "Exists OR" rules are compiled inconsistently
> ---------------------------------------------
>
>                 Key: DROOLS-254
>                 URL: https://issues.jboss.org/browse/DROOLS-254
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final,  6.0.0.CR3
>            Reporter: Davide Sottara
>            Assignee: Mark Proctor
>            Priority: Critical
>             Fix For: 5.5.1.Final, 6.0.0.CR5
>
>
> Exists ( A or B ) is transformed into ( Exists A ) or ( Exists B )
> In case both A and B are asserted, they result in two activations, 
> whereas one would expect only one. 
> Moreover, the equivalent not ( (not A) and (not B) ) results in only
> one activation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 03:18:03 2013
From: jira-events at lists.jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Tue, 1 Oct 2013 03:18:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-251) Classloader fails to resolve
 when annotation and declared class have the same name
In-Reply-To: <JIRA.12500015.1378364475000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500015.1378364475000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500015.1378364475000.7543.1380611883820@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-251:
------------------------------------------

    Fix Version/s: 6.0.0.CR5
                       (was:  6.0.0.CR4)

    
> Classloader fails to resolve when annotation and declared class have the same name
> ----------------------------------------------------------------------------------
>
>                 Key: DROOLS-251
>                 URL: https://issues.jboss.org/browse/DROOLS-251
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.CR2
>            Reporter: Davide Sottara
>            Assignee: Mark Proctor
>             Fix For: 5.5.1.Final, 6.0.0.CR5
>
>
> package test
> declare Annot
>   fld : int @Annot
> end
> The packagebuilder type resolver will confuse the annotation with the declared class and throw exceptions (varies depending on optional import
> statements)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 03:18:03 2013
From: jira-events at lists.jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Tue, 1 Oct 2013 03:18:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-249) Handle conflicts when using
 @position in declared types
In-Reply-To: <JIRA.12500013.1378364090000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500013.1378364090000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500013.1378364090000.7547.1380611883996@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-249:
------------------------------------------

    Fix Version/s: 6.0.0.CR5
                       (was:  6.0.0.CR4)

    
> Handle conflicts when using @position in declared types
> -------------------------------------------------------
>
>                 Key: DROOLS-249
>                 URL: https://issues.jboss.org/browse/DROOLS-249
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.CR2
>            Reporter: Davide Sottara
>            Assignee: Mark Proctor
>            Priority: Minor
>             Fix For: 5.5.1.Final, 6.0.0.CR5
>
>
> declare A
>  f : int @position(2)
>  g : int @position(1)
> end
> declare B extends A
>  h : int @position(3)
>  i : int @position(2)
> end
> The resulting field order may not be deterministic because of
>  - the clashes (2)
>  - the missing pos (0)
> this is dangerous when used with positional constraints
> B( $x, $y, $z, $w ; )
> Marked as minor because of the obvious workaround

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 03:18:04 2013
From: jira-events at lists.jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Tue, 1 Oct 2013 03:18:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-238) (Trait) hierarchy indexing
 and lookup is dramatically slower than needed
In-Reply-To: <JIRA.12499302.1377277962000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499302.1377277962000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499302.1377277962000.7551.1380611884202@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-238:
------------------------------------------

    Fix Version/s: 6.0.0.CR5
                       (was:  6.0.0.CR4)

    
> (Trait) hierarchy indexing and lookup is dramatically slower than needed
> ------------------------------------------------------------------------
>
>                 Key: DROOLS-238
>                 URL: https://issues.jboss.org/browse/DROOLS-238
>             Project: Drools
>          Issue Type: Quality Risk
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.CR1
>            Reporter: Davide Sottara
>            Assignee: Mark Proctor
>            Priority: Critical
>             Fix For: 5.5.1.Final, 6.0.0.CR5
>
>
> The encoding is not optimized for performance, and suffers particularly in case of large, flat taxonomies

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 03:18:04 2013
From: jira-events at lists.jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Tue, 1 Oct 2013 03:18:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-201) Improve Rule Removal
In-Reply-To: <JIRA.12497212.1374649467000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497212.1374649467000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497212.1374649467000.7553.1380611884285@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-201:
------------------------------------------

    Fix Version/s: 6.0.0.CR5
                       (was:  6.0.0.CR4)

    
> Improve Rule Removal
> --------------------
>
>                 Key: DROOLS-201
>                 URL: https://issues.jboss.org/browse/DROOLS-201
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>            Assignee: Mark Proctor
>             Fix For: 6.0.0.CR5
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 03:18:04 2013
From: jira-events at lists.jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Tue, 1 Oct 2013 03:18:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-198) Separate Rete and Phreak
In-Reply-To: <JIRA.12496969.1374456180000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496969.1374456180000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496969.1374456180000.7557.1380611884451@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-198:
------------------------------------------

    Fix Version/s: 6.0.0.CR5
                       (was:  6.0.0.CR4)

    
> Separate Rete and Phreak
> ------------------------
>
>                 Key: DROOLS-198
>                 URL: https://issues.jboss.org/browse/DROOLS-198
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>            Assignee: Mark Proctor
>             Fix For: 6.0.0.CR5
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 03:18:04 2013
From: jira-events at lists.jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Tue, 1 Oct 2013 03:18:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-134) Metadata inheritance is not
 resolved correctly when typeDeclarations are created implicitly
In-Reply-To: <JIRA.12491626.1368431589000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12491626.1368431589000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12491626.1368431589000.7561.1380611884622@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-134:
------------------------------------------

    Fix Version/s: 6.0.0.CR5
                       (was:  6.0.0.CR4)

    
> Metadata inheritance is not resolved correctly when typeDeclarations are created implicitly
> -------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-134
>                 URL: https://issues.jboss.org/browse/DROOLS-134
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.1.Final
>            Reporter: Davide Sottara
>            Assignee: Mark Proctor
>            Priority: Blocker
>             Fix For: 5.5.1.Final, 6.0.0.CR5
>
>
> Implicit TypeDeclarations do not resolve declared metadata modifiers correctly

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 03:18:04 2013
From: jira-events at lists.jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Tue, 1 Oct 2013 03:18:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-126) Drools Verifier does not
 support Conditional Branches
In-Reply-To: <JIRA.12490994.1367522395000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12490994.1367522395000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12490994.1367522395000.7565.1380611884810@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-126:
------------------------------------------

    Fix Version/s: 6.0.0.CR5
                       (was:  6.0.0.CR4)

    
> Drools Verifier does not support Conditional Branches
> -----------------------------------------------------
>
>                 Key: DROOLS-126
>                 URL: https://issues.jboss.org/browse/DROOLS-126
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.Beta2
>            Reporter: Davide Sottara
>            Assignee: Toni Rikkola
>            Priority: Blocker
>             Fix For: 5.5.1.Final, 6.0.0.CR5
>
>
> Drools Verifier has not been updated since the introduction of the Conditional Branches. 
> Any rule with a ConditionalBranchDescr would generate an exception
> when Verified.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 03:18:04 2013
From: jira-events at lists.jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Tue, 1 Oct 2013 03:18:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-115) Add support for strong
	negation
In-Reply-To: <JIRA.12474560.1347671752000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12474560.1347671752000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12474560.1347671752000.7569.1380611884926@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-115:
------------------------------------------

    Fix Version/s: 6.0.0.CR5
                       (was:  6.0.0.CR4)

    
> Add support for strong negation
> -------------------------------
>
>                 Key: DROOLS-115
>                 URL: https://issues.jboss.org/browse/DROOLS-115
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Davide Sottara
>            Assignee: Davide Sottara
>            Priority: Minor
>             Fix For: 6.0.0.CR5
>
>
> Drools "not" operator implements a type of "negation by failure", i.e. not X() behaves as the negation of "exists" or, in other words, translates as "it is NOT asserted that ...".
> However, another form of stronger negation is needed to express conditionals such as "it is asserted that NOT ..."
> It should be possible, then, to assert facts both in a "positive" and "negative" way, to assert THAT and THAT NOT. 
> The language should also support a "neg" CE to create "negative" patterns which will match with negative facts. I.e. it should be possible to write rules such as:
> when $p : Person() and Car( owner == $p ) then
> // a positive, matching Car is present in the WM
> when $p : Person() and neg Car( owner == $p ) then
> // a negative, matching Car is present in the WM
> when $p : Person() and not Car( owner == $p ) then
> // neither a positive nor a negative fact exists in the WM
> For a more detailed description and motivation see e.g.:
> https://oxygen.informatik.tu-cottbus.de/publications/wagner/WebRules2Neg.pdf

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 03:18:05 2013
From: jira-events at lists.jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Tue, 1 Oct 2013 03:18:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-88) Support generics in declared
	types' fields
In-Reply-To: <JIRA.12487865.1364200178000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12487865.1364200178000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487865.1364200178000.7571.1380611885063@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-88:
-----------------------------------------

    Fix Version/s: 6.0.0.CR5
                       (was:  6.0.0.CR4)

    
> Support generics in declared types' fields
> ------------------------------------------
>
>                 Key: DROOLS-88
>                 URL: https://issues.jboss.org/browse/DROOLS-88
>             Project: Drools
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Davide Sottara
>            Assignee: Davide Sottara
>            Priority: Minor
>             Fix For: 5.5.1.Final, 6.0.0.CR5
>
>
> It should be possible to write:
> declare Foo
>   list : List<String>
> end
> While not supported in rules using the mvel dialect, it makes declared types much more readable, and adds some type-safety to java rules.
> Notice that this ticket is NOT related to the possibility of declaring generic classes, such as Foo<T>.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 03:38:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 1 Oct 2013 03:38:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1710) Messages get too large due to
 big headers (in large clusters)
In-Reply-To: <JIRA.12501895.1380613041619@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501895.1380613041619@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501895.1380613041619.7616.1380613082861@jira02.app.mwc.hst.phx2.redhat.com>

Bela Ban created JGRP-1710:
------------------------------

             Summary: Messages get too large due to big headers (in large clusters)
                 Key: JGRP-1710
                 URL: https://issues.jboss.org/browse/JGRP-1710
             Project: JGroups
          Issue Type: Bug
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 3.4


In some cases, messages get bigger than the max bundling size because of large headers:
{noformat}
ERROR Sep 30 17:33:08,096 | Timer-5,c0,172.29.189.9-svc9-ZM26S32728-59135 | [TP.java:1335] | (org) | 172.29.189.9-svc9-ZM26S32728-59135: failed sending message to 172.29.190.181-svc2-00832091-31665 (70850 bytes): java.lang.Exception: message size (70850) is greater than max bundling size (64000). Set the fragmentation/bundle size in FRAG and TP correctly, headers: GMS: GmsHeader[INSTALL_MERGE_VIEW]: view=MergeView::[172.29.190.174-svc6-00832251-874|27] (1479) ...
{noformat}

In the case of INSTALL_MERGE_VIEW, we send the full view (*not* the DeltaView) and the digest in the header. With 1479 members (as shown the the example above), this increases the message size beyond the max bundling size.

Possible SOLUTION
* Place the header fields in the message's buffer instead
* Move FRAG2 *under* GMS
** Investigate impact on flow control etc

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 03:41:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 1 Oct 2013 03:41:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1710) Messages get too large due to
 big headers (in large clusters)
In-Reply-To: <JIRA.12501895.1380613041000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501895.1380613041000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501895.1380613041000.7618.1380613262504@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1710:
---------------------------

    Description: 
In some cases, messages get bigger than the max bundling size because of large headers:
{noformat}
ERROR 17:33:08,096 | Timer-5,c0,172.29.189.9-svc9-ZM26S32728-59135 | [TP.java:1335] | (org) | 172.29.189.9-svc9-ZM26S32728-59135: failed sending message to 172.29.190.181-svc2-00832091-31665 (70850 bytes): java.lang.Exception: message size (70850) is greater than max bundling size (64000). Set the fragmentation/bundle size in FRAG and TP correctly, headers: GMS: GmsHeader[INSTALL_MERGE_VIEW]: view=MergeView::[172.29.190.174-svc6-00832251-874|27] (1479) ...
{noformat}

In the case of INSTALL_MERGE_VIEW, we send the full view (*not* the DeltaView) and the digest in the header. With 1479 members (as shown the the example above), this increases the message size beyond the max bundling size.

Possible SOLUTION
* Place the header fields in the message's buffer instead
* Move FRAG2 *under* GMS
** Investigate impact on flow control etc

  was:
In some cases, messages get bigger than the max bundling size because of large headers:
{noformat}
ERROR Sep 30 17:33:08,096 | Timer-5,c0,172.29.189.9-svc9-ZM26S32728-59135 | [TP.java:1335] | (org) | 172.29.189.9-svc9-ZM26S32728-59135: failed sending message to 172.29.190.181-svc2-00832091-31665 (70850 bytes): java.lang.Exception: message size (70850) is greater than max bundling size (64000). Set the fragmentation/bundle size in FRAG and TP correctly, headers: GMS: GmsHeader[INSTALL_MERGE_VIEW]: view=MergeView::[172.29.190.174-svc6-00832251-874|27] (1479) ...
{noformat}

In the case of INSTALL_MERGE_VIEW, we send the full view (*not* the DeltaView) and the digest in the header. With 1479 members (as shown the the example above), this increases the message size beyond the max bundling size.

Possible SOLUTION
* Place the header fields in the message's buffer instead
* Move FRAG2 *under* GMS
** Investigate impact on flow control etc


    
> Messages get too large due to big headers (in large clusters)
> -------------------------------------------------------------
>
>                 Key: JGRP-1710
>                 URL: https://issues.jboss.org/browse/JGRP-1710
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> In some cases, messages get bigger than the max bundling size because of large headers:
> {noformat}
> ERROR 17:33:08,096 | Timer-5,c0,172.29.189.9-svc9-ZM26S32728-59135 | [TP.java:1335] | (org) | 172.29.189.9-svc9-ZM26S32728-59135: failed sending message to 172.29.190.181-svc2-00832091-31665 (70850 bytes): java.lang.Exception: message size (70850) is greater than max bundling size (64000). Set the fragmentation/bundle size in FRAG and TP correctly, headers: GMS: GmsHeader[INSTALL_MERGE_VIEW]: view=MergeView::[172.29.190.174-svc6-00832251-874|27] (1479) ...
> {noformat}
> In the case of INSTALL_MERGE_VIEW, we send the full view (*not* the DeltaView) and the digest in the header. With 1479 members (as shown the the example above), this increases the message size beyond the max bundling size.
> Possible SOLUTION
> * Place the header fields in the message's buffer instead
> * Move FRAG2 *under* GMS
> ** Investigate impact on flow control etc

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 03:43:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 1 Oct 2013 03:43:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1710) Messages get too large due to
 big headers (in large clusters)
In-Reply-To: <JIRA.12501895.1380613041000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501895.1380613041000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501895.1380613041000.7622.1380613382820@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808460#comment-12808460 ] 

Bela Ban commented on JGRP-1710:
--------------------------------

In general, headers should be relatively small as fragmentation is based on a message's *buffer* (payload) and doesn't take the headers into account until the transport is reached where the *full size* (including the headers) is computed. If the headers add a lot to the total size, then the transport might have to discard the message.
                
> Messages get too large due to big headers (in large clusters)
> -------------------------------------------------------------
>
>                 Key: JGRP-1710
>                 URL: https://issues.jboss.org/browse/JGRP-1710
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> In some cases, messages get bigger than the max bundling size because of large headers:
> {noformat}
> ERROR 17:33:08,096 | Timer-5,c0,172.29.189.9-svc9-ZM26S32728-59135 | [TP.java:1335] | (org) | 172.29.189.9-svc9-ZM26S32728-59135: failed sending message to 172.29.190.181-svc2-00832091-31665 (70850 bytes): java.lang.Exception: message size (70850) is greater than max bundling size (64000). Set the fragmentation/bundle size in FRAG and TP correctly, headers: GMS: GmsHeader[INSTALL_MERGE_VIEW]: view=MergeView::[172.29.190.174-svc6-00832251-874|27] (1479) ...
> {noformat}
> In the case of INSTALL_MERGE_VIEW, we send the full view (*not* the DeltaView) and the digest in the header. With 1479 members (as shown the the example above), this increases the message size beyond the max bundling size.
> Possible SOLUTION
> * Place the header fields in the message's buffer instead
> * Move FRAG2 *under* GMS
> ** Investigate impact on flow control etc

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 03:45:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 1 Oct 2013 03:45:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1710) Messages get too large due to
 big headers (in large clusters)
In-Reply-To: <JIRA.12501895.1380613041000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501895.1380613041000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501895.1380613041000.7655.1380613502642@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1710:
---------------------------

    Description: 
In some cases, messages get bigger than the max bundling size because of large headers:
{panel}
ERROR 17:33:08,096 | Timer-5,c0,172.29.189.9-svc9-ZM26S32728-59135 | [TP.java:1335] | (org) | 172.29.189.9-svc9-ZM26S32728-59135: failed sending message to 172.29.190.181-svc2-00832091-31665 (70850 bytes): java.lang.Exception: message size (70850) is greater than max bundling size (64000). Set the fragmentation/bundle size in FRAG and TP correctly, headers: GMS: GmsHeader[INSTALL_MERGE_VIEW]: view=MergeView::[172.29.190.174-svc6-00832251-874|27] (1479) ...
{panel}

In the case of INSTALL_MERGE_VIEW, we send the full view (*not* the DeltaView) and the digest in the header. With 1479 members (as shown the the example above), this increases the message size beyond the max bundling size.

Possible SOLUTION
* Place the header fields in the message's buffer instead
* Move FRAG2 *under* GMS
** Investigate impact on flow control etc

  was:
In some cases, messages get bigger than the max bundling size because of large headers:
{noformat}
ERROR 17:33:08,096 | Timer-5,c0,172.29.189.9-svc9-ZM26S32728-59135 | [TP.java:1335] | (org) | 172.29.189.9-svc9-ZM26S32728-59135: failed sending message to 172.29.190.181-svc2-00832091-31665 (70850 bytes): java.lang.Exception: message size (70850) is greater than max bundling size (64000). Set the fragmentation/bundle size in FRAG and TP correctly, headers: GMS: GmsHeader[INSTALL_MERGE_VIEW]: view=MergeView::[172.29.190.174-svc6-00832251-874|27] (1479) ...
{noformat}

In the case of INSTALL_MERGE_VIEW, we send the full view (*not* the DeltaView) and the digest in the header. With 1479 members (as shown the the example above), this increases the message size beyond the max bundling size.

Possible SOLUTION
* Place the header fields in the message's buffer instead
* Move FRAG2 *under* GMS
** Investigate impact on flow control etc


    
> Messages get too large due to big headers (in large clusters)
> -------------------------------------------------------------
>
>                 Key: JGRP-1710
>                 URL: https://issues.jboss.org/browse/JGRP-1710
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> In some cases, messages get bigger than the max bundling size because of large headers:
> {panel}
> ERROR 17:33:08,096 | Timer-5,c0,172.29.189.9-svc9-ZM26S32728-59135 | [TP.java:1335] | (org) | 172.29.189.9-svc9-ZM26S32728-59135: failed sending message to 172.29.190.181-svc2-00832091-31665 (70850 bytes): java.lang.Exception: message size (70850) is greater than max bundling size (64000). Set the fragmentation/bundle size in FRAG and TP correctly, headers: GMS: GmsHeader[INSTALL_MERGE_VIEW]: view=MergeView::[172.29.190.174-svc6-00832251-874|27] (1479) ...
> {panel}
> In the case of INSTALL_MERGE_VIEW, we send the full view (*not* the DeltaView) and the digest in the header. With 1479 members (as shown the the example above), this increases the message size beyond the max bundling size.
> Possible SOLUTION
> * Place the header fields in the message's buffer instead
> * Move FRAG2 *under* GMS
> ** Investigate impact on flow control etc

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 03:51:02 2013
From: jira-events at lists.jboss.org (Aftab Khan (JIRA))
Date: Tue, 1 Oct 2013 03:51:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-207) Inconsistent Stack Map when
 inserting throw Expression with Java 7
In-Reply-To: <JIRA.12495073.1372170431000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495073.1372170431000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495073.1372170431000.7675.1380613862676@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JASSIST-207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808463#comment-12808463 ] 

Aftab Khan commented on JASSIST-207:
------------------------------------

The issue has been resolved and working in javassist-3.18.1-GA.
Thanks,
Aftab
                
> Inconsistent Stack Map when inserting throw Expression with Java 7
> ------------------------------------------------------------------
>
>                 Key: JASSIST-207
>                 URL: https://issues.jboss.org/browse/JASSIST-207
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.18.0-GA
>            Reporter: Ben Romberg
>            Assignee: Shigeru Chiba
>            Priority: Critical
>             Fix For: 3.18.1-GA, 3.19.0-GA
>
>         Attachments: afterInsertThrowExpression.txt, AGDelegateImpl.class, beforeInsertThrowExpression.txt, conditionalThrowExceptionInserted.txt
>
>
> I wrote a unit-test for javassist, reproducing the issue:
> {code}
> public class ThrowExpressionCorruptsStackMapTableTest extends JvstTestRoot {
> 	public ThrowExpressionCorruptsStackMapTableTest(String name) {
> 		super(name);
> 	}
> 	public void testInsertLocalVars() throws Exception {
> 		CtClass cc = sloader.get("test4.LocalVars");
> 		CtMethod m1 = cc.getDeclaredMethod("run");
> 		m1.insertBefore("throw new AssertionError((Object) \"assertion error\");");
> 		cc.writeFile();
> 		Object obj = make(cc.getName());
> 		assertEquals(10, invoke(obj, "run"));
> 	}
> }
> {code}
> Throws:
> java.lang.VerifyError: Expecting a stack map frame in method test4.LocalVars.run()I at offset 45
> My use-case is almost the same, inserting a "throw AssertionError(...)" expression with insertBefore. However, I get a slightly different error message:
> Stack map does not match the one at exception handler 37 in method timeofday.TimeOfDay.getSecond()I at offset 27

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 04:06:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 1 Oct 2013 04:06:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-217) MVEL throws an exception
 when using bound variables and map accessors
In-Reply-To: <JIRA.12498528.1376459523000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498528.1376459523000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498528.1376459523000.7697.1380614762864@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-217:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> MVEL throws an exception when using bound variables and map accessors
> ---------------------------------------------------------------------
>
>                 Key: DROOLS-217
>                 URL: https://issues.jboss.org/browse/DROOLS-217
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.CR1
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Minor
>
> Map( $c : this[ "x" ], $c op value )
> throws an exception as MVEL tries to compile the constraint 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 04:06:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 1 Oct 2013 04:06:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1710) Messages get too large due to
 big headers (in large clusters)
In-Reply-To: <JIRA.12501895.1380613041000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501895.1380613041000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501895.1380613041000.7703.1380614763212@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808467#comment-12808467 ] 

Bela Ban commented on JGRP-1710:
--------------------------------

As a quickfix, we could place a *second* FRAG2 just above the transport: if VIEW and INSTALL_MERGE_VIEW etc carry their payload in the message's body instead of the header, then that second FRAG2 would fragment the message again.

As a long term solution we should investigate whether FRAG2 cannot be *moved* (instead of duplicated) just above the transport.
                
> Messages get too large due to big headers (in large clusters)
> -------------------------------------------------------------
>
>                 Key: JGRP-1710
>                 URL: https://issues.jboss.org/browse/JGRP-1710
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> In some cases, messages get bigger than the max bundling size because of large headers:
> {panel}
> ERROR 17:33:08,096 | Timer-5,c0,172.29.189.9-svc9-ZM26S32728-59135 | [TP.java:1335] | (org) | 172.29.189.9-svc9-ZM26S32728-59135: failed sending message to 172.29.190.181-svc2-00832091-31665 (70850 bytes): java.lang.Exception: message size (70850) is greater than max bundling size (64000). Set the fragmentation/bundle size in FRAG and TP correctly, headers: GMS: GmsHeader[INSTALL_MERGE_VIEW]: view=MergeView::[172.29.190.174-svc6-00832251-874|27] (1479) ...
> {panel}
> In the case of INSTALL_MERGE_VIEW, we send the full view (*not* the DeltaView) and the digest in the header. With 1479 members (as shown the the example above), this increases the message size beyond the max bundling size.
> Possible SOLUTION
> * Place the header fields in the message's buffer instead
> * Move FRAG2 *under* GMS
> ** Investigate impact on flow control etc

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 04:06:03 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 1 Oct 2013 04:06:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-216) Map accessors and custom
 evaluators do not work together
In-Reply-To: <JIRA.12498527.1376459367000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498527.1376459367000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498527.1376459367000.7700.1380614763018@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-216:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> Map accessors and custom evaluators do not work together
> --------------------------------------------------------
>
>                 Key: DROOLS-216
>                 URL: https://issues.jboss.org/browse/DROOLS-216
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.CR1
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Minor
>
> Map( this[ "x" ] custOp value ) fails.
> The custom evaluator is passed the map itself, rather than the value 
> corresponding to the key.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 04:10:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 1 Oct 2013 04:10:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1710) Messages get too large due to
 big headers (in large clusters)
In-Reply-To: <JIRA.12501895.1380613041000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501895.1380613041000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501895.1380613041000.7708.1380615003691@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1710:
---------------------------

    Workaround Description: Place *FRAG* just above the transport. FRAG (in contrary to FRAG2) uses {{Message.size()}} to determine whether a message needs to be fragmented, and therefore takes headers into account, too.
                Workaround: Workaround Exists

    
> Messages get too large due to big headers (in large clusters)
> -------------------------------------------------------------
>
>                 Key: JGRP-1710
>                 URL: https://issues.jboss.org/browse/JGRP-1710
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> In some cases, messages get bigger than the max bundling size because of large headers:
> {panel}
> ERROR 17:33:08,096 | Timer-5,c0,172.29.189.9-svc9-ZM26S32728-59135 | [TP.java:1335] | (org) | 172.29.189.9-svc9-ZM26S32728-59135: failed sending message to 172.29.190.181-svc2-00832091-31665 (70850 bytes): java.lang.Exception: message size (70850) is greater than max bundling size (64000). Set the fragmentation/bundle size in FRAG and TP correctly, headers: GMS: GmsHeader[INSTALL_MERGE_VIEW]: view=MergeView::[172.29.190.174-svc6-00832251-874|27] (1479) ...
> {panel}
> In the case of INSTALL_MERGE_VIEW, we send the full view (*not* the DeltaView) and the digest in the header. With 1479 members (as shown the the example above), this increases the message size beyond the max bundling size.
> Possible SOLUTION
> * Place the header fields in the message's buffer instead
> * Move FRAG2 *under* GMS
> ** Investigate impact on flow control etc

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 05:36:03 2013
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 1 Oct 2013 05:36:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2058) Standalone profile hangs
 using Java 8 developer preview
In-Reply-To: <JIRA.12500648.1379021721000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500648.1379021721000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500648.1379021721000.7852.1380620163009@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai updated WFLY-2058:
-------------------------------

    Issue Type: Bug  (was: Feature Request)
      Priority: Major  (was: Minor)

    
> Standalone profile hangs using Java 8 developer preview
> -------------------------------------------------------
>
>                 Key: WFLY-2058
>                 URL: https://issues.jboss.org/browse/WFLY-2058
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 8.0.0.Alpha4
>         Environment: Windows 7 Home Premium 64-bit i7 3610QM 2.3GHz 16GB RAM
>            Reporter: Gerard Krupa
>            Assignee: Jason Greene
>              Labels: hangs, java8, jdk8, standalone.bat
>         Attachments: server.log
>
>
> When attempting to run the standalone profile after a clean install, the server hangs after
> 22:23:08,362 INFO  [org.jboss.as] (MSC service thread 1-6) JBAS015899: WildFly 8.0.0.Alpha4 "WildFly" starting
> The log only shows:
> 22:23:08,368 DEBUG [org.jboss.as.config] (MSC service thread 1-6) Configured system properties:
> ...
> 22:23:08,369 DEBUG [org.jboss.as.config] (MSC service thread 1-6) VM Arguments: -XX:+TieredCompilation -XX:+UseCompressedOops -Dprogram.name=standalone.bat -Xms64M -Xmx512M -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Dorg.jboss.boot.log.file=D:\app-servers\wildfly-8.0.0.Alpha4\standalone\log\server.log -Dlogging.configuration=file:D:\app-servers\wildfly-8.0.0.Alpha4\standalone\configuration/logging.properties 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 05:36:03 2013
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 1 Oct 2013 05:36:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2058) Standalone profile hangs
 using Java 8 developer preview
In-Reply-To: <JIRA.12500648.1379021721000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500648.1379021721000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500648.1379021721000.7857.1380620163269@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai closed WFLY-2058.
------------------------------

    Resolution: Duplicate Issue


Duplicate of WFLY-2057

                
> Standalone profile hangs using Java 8 developer preview
> -------------------------------------------------------
>
>                 Key: WFLY-2058
>                 URL: https://issues.jboss.org/browse/WFLY-2058
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 8.0.0.Alpha4
>         Environment: Windows 7 Home Premium 64-bit i7 3610QM 2.3GHz 16GB RAM
>            Reporter: Gerard Krupa
>            Assignee: Jason Greene
>              Labels: hangs, java8, jdk8, standalone.bat
>         Attachments: server.log
>
>
> When attempting to run the standalone profile after a clean install, the server hangs after
> 22:23:08,362 INFO  [org.jboss.as] (MSC service thread 1-6) JBAS015899: WildFly 8.0.0.Alpha4 "WildFly" starting
> The log only shows:
> 22:23:08,368 DEBUG [org.jboss.as.config] (MSC service thread 1-6) Configured system properties:
> ...
> 22:23:08,369 DEBUG [org.jboss.as.config] (MSC service thread 1-6) VM Arguments: -XX:+TieredCompilation -XX:+UseCompressedOops -Dprogram.name=standalone.bat -Xms64M -Xmx512M -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Dorg.jboss.boot.log.file=D:\app-servers\wildfly-8.0.0.Alpha4\standalone\log\server.log -Dlogging.configuration=file:D:\app-servers\wildfly-8.0.0.Alpha4\standalone\configuration/logging.properties 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 06:01:04 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 1 Oct 2013 06:01:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2190) Priviledge alignment for
	scoped resources
In-Reply-To: <JIRA.12501904.1380621634198@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501904.1380621634198@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501904.1380621634198.7915.1380621664287@jira02.app.mwc.hst.phx2.redhat.com>

Heiko Braun created WFLY-2190:
---------------------------------

             Summary: Priviledge alignment for scoped resources
                 Key: WFLY-2190
                 URL: https://issues.jboss.org/browse/WFLY-2190
             Project: WildFly
          Issue Type: Enhancement
          Components: Domain Management
            Reporter: Heiko Braun
            Assignee: Brian Stansberry
             Fix For: 8.0.0.CR1


server-groups show different privildges for server-group=* and server-group=<specific instance>. when accessing these as a scoped role we use the <specific instance> to determine the operation priviledges. 

wouldit be possible that the operation permissions for server-group=<specific instance>:<add|remove> show the same permissions as server-group=*:<add|remove>? 




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 06:03:02 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 1 Oct 2013 06:03:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2190) Priviledge alignment for
	scoped resources
In-Reply-To: <JIRA.12501904.1380621634000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501904.1380621634000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501904.1380621634000.7922.1380621782567@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun updated WFLY-2190:
------------------------------

    Description: 
server-groups show different privildges for {{server-group=*}} and {{server-group=<specific instance>}}. when accessing these as a scoped role we use the <specific instance> to determine the operation priviledges. 

Would it be possible that the operation permissions for {{server-group=<specific instance>:<add|remove>}} show the same permissions as {{server-group=*:<add|remove>}}? 




  was:
server-groups show different privildges for server-group=* and server-group=<specific instance>. when accessing these as a scoped role we use the <specific instance> to determine the operation priviledges. 

wouldit be possible that the operation permissions for server-group=<specific instance>:<add|remove> show the same permissions as server-group=*:<add|remove>? 





    
> Priviledge alignment for scoped resources
> -----------------------------------------
>
>                 Key: WFLY-2190
>                 URL: https://issues.jboss.org/browse/WFLY-2190
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> server-groups show different privildges for {{server-group=*}} and {{server-group=<specific instance>}}. when accessing these as a scoped role we use the <specific instance> to determine the operation priviledges. 
> Would it be possible that the operation permissions for {{server-group=<specific instance>:<add|remove>}} show the same permissions as {{server-group=*:<add|remove>}}? 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 06:30:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Tue, 1 Oct 2013 06:30:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-794)
 javax.naming.NameNotFoundException: rmi://127.0.0.1:1090/jmxrmi thrown when
 creating MBeanServerConnection
In-Reply-To: <JIRA.12488795.1365437999000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12488795.1365437999000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488795.1365437999000.8065.1380623402801@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reopened WFLY-794:
---------------------------------

      Assignee: Stuart Douglas  (was: Bartosz Baranowski)

    
> javax.naming.NameNotFoundException: rmi://127.0.0.1:1090/jmxrmi thrown when creating MBeanServerConnection
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-794
>                 URL: https://issues.jboss.org/browse/WFLY-794
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMX
>            Reporter: Alex Corvino
>            Assignee: Stuart Douglas
>         Attachments: jmx-test.jar, JmxClient.java, JMXConnectionBean.java, JmxServer.java
>
>
> When trying to create a MBeanServerConnection to a NON-JBoss application from within an EJB a "javax.naming.NameNotFoundException" is thrown. 
> Steps to reproduce:
> Set up a stand-alone application that exposes an MBean. (ActiveMQ will work in this case.)
> Modify the attached JMXConnectionBean.java to connect to the ActiveMQ instance.
> Deploy the bean. A NameNotFoundException will be thrown.
> I've seen this behavior in 7.1.1.Final, 7.1.2.Final (EAP), 7.1.3.Final (EAP), EAP 6.1.0.Alpha (7.2.0.Final). 
> Note that this behavior is NOT seen when connecting to another JBoss server. 
> Full stack trace:
> {code} 
> Caused by: java.io.IOException: Failed to retrieve RMIServer stub: javax.naming.NameNotFoundException: rmi://127.0.0.1:1090/jmxrmi -- service jboss.naming.context.java.rmi:."127.0.0.1:1090".jmxrmi
> 	at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:340) [:1.6.0_26]
> 	at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:248) [:1.6.0_26]
> 	at com.example.JMXConnectionBean.init(JMXConnectionBean.java:28)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_26]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_26]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_26]
> 	at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_26]
> 	at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:70)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.ee.component.ManagedReferenceInterceptor.processInvocation(ManagedReferenceInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:44)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor$CustomSessionInvocationContext.proceed(SessionInvocationContextInterceptor.java:126)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:211)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.requiresNew(CMTTxInterceptor.java:313)
> 	at org.jboss.as.ejb3.tx.SingletonLifecycleCMTTxInterceptor.processInvocation(SingletonLifecycleCMTTxInterceptor.java:56)
> 	at org.jboss.as.ejb3.tx.SingletonLifecycleCMTTxInterceptor.processInvocation(SingletonLifecycleCMTTxInterceptor.java:42)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor.processInvocation(SessionInvocationContextInterceptor.java:71)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:152)
> 	... 9 more
> Caused by: javax.naming.NameNotFoundException: rmi://127.0.0.1:1090/jmxrmi -- service jboss.naming.context.java.rmi:."127.0.0.1:1090".jmxrmi
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:87)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:173)
> 	at org.jboss.as.naming.InitialContext.lookup(InitialContext.java:47)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:209)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:392) [:1.6.0_26]
> 	at javax.management.remote.rmi.RMIConnector.findRMIServerJNDI(RMIConnector.java:1888) [:1.6.0_26]
> 	at javax.management.remote.rmi.RMIConnector.findRMIServer(RMIConnector.java:1858) [:1.6.0_26]
> 	at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:257) [:1.6.0_26]
> 	... 37 more
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 06:47:06 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 1 Oct 2013 06:47:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1960) CDI @Inject of @Stateless
 @WebService cause WELD-001408 Unsatisfied dependencies
In-Reply-To: <JIRA.12499428.1377603560000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499428.1377603560000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499428.1377603560000.8105.1380624426222@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808530#comment-12808530 ] 

RH Bugzilla Integration commented on WFLY-1960:
-----------------------------------------------

Stuart Douglas <sdouglas at redhat.com> made a comment on [bug 1001610|https://bugzilla.redhat.com/show_bug.cgi?id=1001610]

Rejecting dev_ack as per Martin's comment, as the test is invalid.
                
> CDI @Inject of @Stateless @WebService cause WELD-001408 Unsatisfied dependencies
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-1960
>                 URL: https://issues.jboss.org/browse/WFLY-1960
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld, EJB, Web Services
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Aslak Knutsen
>            Assignee: Martin Kouba
>
> CDI @Inject of @WebService does not work. 
> {code}
> import javax.ejb.Stateless;
> import javax.jws.WebService;
>  
> @Stateless
> @WebService
> public class TestBean {
> }
>  
>  
> import javax.inject.Inject;
>  
> import org.jboss.arquillian.container.test.api.Deployment;
> import org.jboss.arquillian.junit.Arquillian;
> import org.jboss.shrinkwrap.api.ShrinkWrap;
> import org.jboss.shrinkwrap.api.asset.EmptyAsset;
> import org.jboss.shrinkwrap.api.spec.WebArchive;
> import org.junit.Test;
> import org.junit.runner.RunWith;
>  
>  
> @RunWith(Arquillian.class)
> public class TestBeanIT {
>  
>     @Inject
>     TestBean bean;
>  
>     @Deployment
>     public static WebArchive createDeployment() {
>         WebArchive arch =  ShrinkWrap.create(WebArchive.class);
>         arch.addClass(TestBean.class);
>         arch.addAsWebInfResource(EmptyAsset.INSTANCE, "beans.xml");
>         return arch;
>     }
>  
>     @Test
>     public void fooTest() throws Exception {
>  
>     }
> }
> {code}
> Using CDI to do a non contextual injection on a class where @EJB is used instead of @Inject works.
> {code}
> @RunWith(Arquillian.class)
> public class TestBeanIT {
>  
>     @EJB
>     TestBean bean;
>     ...
> }
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 06:49:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 1 Oct 2013 06:49:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1507) MFC2: multicast flow control
In-Reply-To: <JIRA.12473640.1346760591000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12473640.1346760591000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12473640.1346760591000.8113.1380624543068@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808531#comment-12808531 ] 

Bela Ban commented on JGRP-1507:
--------------------------------

h3. Fragmentation and flow control
It would be nice if we could move FRAG / FRAG2 over the transport so that fragmentation happens _just before sending the message_. This would also solve https://issues.jboss.org/browse/JGRP-1710.

The problem here is that a very large message might overwhelm flow control: if we allow it to pass, FRAG will generate a high number of fragments out of which many might get discarded due to buffer overflow...

                
> MFC2: multicast flow control
> ----------------------------
>
>                 Key: JGRP-1507
>                 URL: https://issues.jboss.org/browse/JGRP-1507
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>         Attachments: Design.pdf
>
>
> The current flow control protocol (MFC) is slowing things down when we have high traffic in multicast networks (UDP based stack), especially when ethernet flow control (802.3) is disabled.
> One reason is that the number of credits (similar to the window size in TCP) is static, and doesn't change. E.g. it doesn't increase when there's no loss and doesn't shrink when there is loss. 
> (This will be addressed by a different JIRA later)
> Another reason is that sender credits are currently only used up when *sending* messages, but not when *receiving* messages. Thus, if we have 50MB of credits, a sender A can send 50MB until A blocks. However, when it receives 20MB of traffic from B while it sends the 50MB, it doesn't take the 20MBs into account.
> Therefore, a receiver S can be overwhelmed by receiving both A's and B's traffic (the switch might even start discarding messages before they reach S).
> The change from MFC to MFC2 is that a sender only maintains 1 'credits' counter (number of bytes): whenever it sends a message, it decrements credits. Whenever it receives traffic from someone else, it also decrements credits. When credits is 0, the sender blocks (asking for more credits). When credits drops below a certain threshold, it multicasts 1/N of the max credits (N = number of cluster members). (TBD: perhaps it should mcast a fixed number, independent of the cluster size).
> The advantage of this scheme is that a sender blocks sooner, and not when it's too late (congestion).
> Example:
> - credits = 100MB
> - Concurrently: A sends 50MB, B sends 30MB and C sends 60MB
> - At time T1, A has sent 20MB, and we've already received 10MB from B and 20 from C, credits is now 50MB
> - At time T2, A sent another 20MB, and received 20MB from C. credits is now 10MB, and A multicasts 35MB (rounded)
> - At T3, A receives another 10MB from B, credits=0
> - At T4, A blocks trying to send its remaining 10MBs, as credits = 0
> - At T5, A receives its 35MB of credits and sends its remaining 10MB, and also receives 20MB from C, and the remaining 10MB from B. credits is now -5 and A would block sending more credits
> - At T6, A multicasts 35MBs of credits
> - At T7, A receives 35MB of credits from B and C, credits= ca 65MB
> - At T8, A receives its own 35MBs of credits, credits=~100MB

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 06:55:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 1 Oct 2013 06:55:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1507) MFC2: multicast flow control
In-Reply-To: <JIRA.12473640.1346760591000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12473640.1346760591000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12473640.1346760591000.8119.1380624903160@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808531#comment-12808531 ] 

Bela Ban edited comment on JGRP-1507 at 10/1/13 6:54 AM:
---------------------------------------------------------

h3. Fragmentation and flow control
It would be nice if we could move FRAG / FRAG2 over the transport so that fragmentation happens _just before sending the message_. This would also solve https://issues.jboss.org/browse/JGRP-1710.

The problem here is that a very large message might overwhelm flow control: if we allow it to pass, FRAG will generate a high number of fragments out of which many might get discarded due to buffer overflow...

Downside: if we have a large message P:5 and FRAG2 generates 100 fragments, if at least 1 fragment is lost, the receiver will ask P to retransmit message 5, resulting in re-sending of P:5 and  - due to fragmentation - sending of another 100 fragments.
So, in the worst case, losing 1 fragments causes the resending of 100 fragments. Not a good idea...
                
      was (Author: belaban):
    h3. Fragmentation and flow control
It would be nice if we could move FRAG / FRAG2 over the transport so that fragmentation happens _just before sending the message_. This would also solve https://issues.jboss.org/browse/JGRP-1710.

The problem here is that a very large message might overwhelm flow control: if we allow it to pass, FRAG will generate a high number of fragments out of which many might get discarded due to buffer overflow...

                  
> MFC2: multicast flow control
> ----------------------------
>
>                 Key: JGRP-1507
>                 URL: https://issues.jboss.org/browse/JGRP-1507
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>         Attachments: Design.pdf
>
>
> The current flow control protocol (MFC) is slowing things down when we have high traffic in multicast networks (UDP based stack), especially when ethernet flow control (802.3) is disabled.
> One reason is that the number of credits (similar to the window size in TCP) is static, and doesn't change. E.g. it doesn't increase when there's no loss and doesn't shrink when there is loss. 
> (This will be addressed by a different JIRA later)
> Another reason is that sender credits are currently only used up when *sending* messages, but not when *receiving* messages. Thus, if we have 50MB of credits, a sender A can send 50MB until A blocks. However, when it receives 20MB of traffic from B while it sends the 50MB, it doesn't take the 20MBs into account.
> Therefore, a receiver S can be overwhelmed by receiving both A's and B's traffic (the switch might even start discarding messages before they reach S).
> The change from MFC to MFC2 is that a sender only maintains 1 'credits' counter (number of bytes): whenever it sends a message, it decrements credits. Whenever it receives traffic from someone else, it also decrements credits. When credits is 0, the sender blocks (asking for more credits). When credits drops below a certain threshold, it multicasts 1/N of the max credits (N = number of cluster members). (TBD: perhaps it should mcast a fixed number, independent of the cluster size).
> The advantage of this scheme is that a sender blocks sooner, and not when it's too late (congestion).
> Example:
> - credits = 100MB
> - Concurrently: A sends 50MB, B sends 30MB and C sends 60MB
> - At time T1, A has sent 20MB, and we've already received 10MB from B and 20 from C, credits is now 50MB
> - At time T2, A sent another 20MB, and received 20MB from C. credits is now 10MB, and A multicasts 35MB (rounded)
> - At T3, A receives another 10MB from B, credits=0
> - At T4, A blocks trying to send its remaining 10MBs, as credits = 0
> - At T5, A receives its 35MB of credits and sends its remaining 10MB, and also receives 20MB from C, and the remaining 10MB from B. credits is now -5 and A would block sending more credits
> - At T6, A multicasts 35MBs of credits
> - At T7, A receives 35MB of credits from B and C, credits= ca 65MB
> - At T8, A receives its own 35MBs of credits, credits=~100MB

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 07:05:02 2013
From: jira-events at lists.jboss.org (Eduardo Martins (JIRA))
Date: Tue, 1 Oct 2013 07:05:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2115) JNDI URLs should not be
	relative to java:/
In-Reply-To: <JIRA.12501039.1379607710000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501039.1379607710000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501039.1379607710000.8151.1380625502617@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808536#comment-12808536 ] 

Eduardo Martins commented on WFLY-2115:
---------------------------------------

This may end up being same issue as WFLY-794 , yet the error msg is misleading and should be fixed.
                
> JNDI URLs should not be relative to java:/
> ------------------------------------------
>
>                 Key: WFLY-2115
>                 URL: https://issues.jboss.org/browse/WFLY-2115
>             Project: WildFly
>          Issue Type: Bug
>          Components: Naming
>            Reporter: David Lloyd
>            Assignee: Eduardo Martins
>             Fix For: 8.0.0.CR1
>
>
> If you look up or bind to/from JNDI name which is a URL (for example "rmi:"), instead of using any kind of standard lookup process, it just pushes the URL into a "java:/" name, which is definitely wrong.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 07:17:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 1 Oct 2013 07:17:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1569) Not possible to reload server
 when JTS transactions are activated
In-Reply-To: <JIRA.12494844.1371818256000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494844.1371818256000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494844.1371818256000.8170.1380626223121@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808540#comment-12808540 ] 

RH Bugzilla Integration commented on WFLY-1569:
-----------------------------------------------

tom.jenkinson at redhat.com changed the Status of [bug 1011379|https://bugzilla.redhat.com/show_bug.cgi?id=1011379] from NEW to POST
                
> Not possible to reload server when JTS transactions are activated
> -----------------------------------------------------------------
>
>                 Key: WFLY-1569
>                 URL: https://issues.jboss.org/browse/WFLY-1569
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Ond?ej Chaloupka
>            Assignee: Stefano Maestri
>
> When transactions are set for JTS being used
>  - <jts/> tag under transactions subsystem
>  - transactions="on" under jacorb subsystem
> then it is not possible to reload the server.
> The reload causes the following exception being shown.
> {code}
> 14:30:56,388 WARN  [com.arjuna.ats.jts] (MSC service thread 1-5) ARJUNA022083: JacOrbRCServiceInit - Failed to start RC service: org.omg.CORBA.OBJECT_NOT_EXIST: POA destroyed
>  at org.jacorb.poa.POA.checkDestructionApparent(POA.java:1409)                           
>  at org.jacorb.poa.POA.set_servant(POA.java:1979)                          
>  at com.arjuna.ats.internal.jts.orbspecific.jacorb.recoverycoordinators.JacOrbRCServiceInit.startRCservice(JacOrbRCServiceInit.java:197) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]        
>  at com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement.startRCservice(RecoveryEnablement.java:137) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]        
>  at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:66) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]         
>  at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:104) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]              
>  at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:224) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]               
>  at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65) [narayana-jts-integration-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]            
>  at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:139) [wildfly-transactions-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]              
>  at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1942) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]                
>  at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1875) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]                  
>  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]                       
>  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]                       
>  at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]                       
> 14:30:56,396 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.txn.ArjunaRecoveryManager: org.jboss.msc.service.StartException in service jboss.txn.ArjunaRecoveryManager: JBAS010101: Recovery manager create failed                                 
>  at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:142)                      
>  at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1942) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]                
>  at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1875) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]                  
>  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]                       
>  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]                       
>  at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]                       
> Caused by: java.lang.RuntimeException: ARJUNA012364: RecoveryActivator init failed for com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement            
>  at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:67)                 
>  at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:104)                      
>  at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:224)                       
>  at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65)                  
>  at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:139)                      
>  ... 5 more 
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Tue Oct  1 07:17:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 1 Oct 2013 07:17:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1569) Not possible to reload server
 when JTS transactions are activated
In-Reply-To: <JIRA.12494844.1371818256000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494844.1371818256000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494844.1371818256000.8176.1380626223352@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808542#comment-12808542 ] 

RH Bugzilla Integration commented on WFLY-1569:
-----------------------------------------------

tom.jenkinson at redhat.com made a comment on [bug 1011379|https://bugzilla.redhat.com/show_bug.cgi?id=1011379]

https://github.com/jbossas/jboss-eap/pull/478
                
> Not possible to reload server when JTS transactions are activated
> -----------------------------------------------------------------
>
>                 Key: WFLY-1569
>                 URL: https://issues.jboss.org/browse/WFLY-1569
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Ond?ej Chaloupka
>            Assignee: Stefano Maestri
>
> When transactions are set for JTS being used
>  - <jts/> tag under transactions subsystem
>  - transactions="on" under jacorb subsystem
> then it is not possible to reload the server.
> The reload causes the following exception being shown.
> {code}
> 14:30:56,388 WARN  [com.arjuna.ats.jts] (MSC service thread 1-5) ARJUNA022083: JacOrbRCServiceInit - Failed to start RC service: org.omg.CORBA.OBJECT_NOT_EXIST: POA destroyed
>  at org.jacorb.poa.POA.checkDestructionApparent(POA.java:1409)                           
>  at org.jacorb.poa.POA.set_servant(POA.java:1979)                          
>  at com.arjuna.ats.internal.jts.orbspecific.jacorb.recoverycoordinators.JacOrbRCServiceInit.startRCservice(JacOrbRCServiceInit.java:197) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]        
>  at com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement.startRCservice(RecoveryEnablement.java:137) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]        
>  at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:66) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]         
>  at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:104) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]              
>  at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:224) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]               
>  at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65) [narayana-jts-integration-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]            
>  at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:139) [wildfly-transactions-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]              
>  at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1942) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]                
>  at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1875) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]                  
>  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]                       
>  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]                       
>  at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]                       
> 14:30:56,396 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.txn.ArjunaRecoveryManager: org.jboss.msc.service.StartException in service jboss.txn.ArjunaRecoveryManager: JBAS010101: Recovery manager create failed                                 
>  at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:142)                      
>  at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1942) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]                
>  at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1875) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]                  
>  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]                       
>  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]                       
>  at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]                       
> Caused by: java.lang.RuntimeException: ARJUNA012364: RecoveryActivator init failed for com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement            
>  at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:67)                 
>  at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:104)                      
>  at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:224)                       
>  at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65)                  
>  at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:139)                      
>  ... 5 more 
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Tue Oct  1 07:23:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 1 Oct 2013 07:23:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1710) Messages get too large due to
 big headers (in large clusters)
In-Reply-To: <JIRA.12501895.1380613041000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501895.1380613041000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501895.1380613041000.8213.1380626582668@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808551#comment-12808551 ] 

Bela Ban commented on JGRP-1710:
--------------------------------

As discussed on JGRP-1507: FRAG\{2\} cannot be moved over the transport as retransmission of large messages with 1 fragment missing would cause retransmission of the entire message (all fragments).

Therefore, the current strategy is to move large data from the header into the message's buffer and - if needed - add a second FRAG\{2\} directly over the transport. This second fragmentation protocol would typically not have to do any work, as fragmentation is done by the first fragmentation protocol. The only case where work would need to be done is when large data are added by a protocol, e.g. view and digest by {{INSTALL_MERGE_VIEW in GMS}}.

The advantage of moving large data into the body of a message is that FRAG2.down() can do a cheap {{Message.getLength()}}, compared to a more costly {{Message.size()}} by {{FRAG.down(){{.
                
> Messages get too large due to big headers (in large clusters)
> -------------------------------------------------------------
>
>                 Key: JGRP-1710
>                 URL: https://issues.jboss.org/browse/JGRP-1710
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> In some cases, messages get bigger than the max bundling size because of large headers:
> {panel}
> ERROR 17:33:08,096 | Timer-5,c0,172.29.189.9-svc9-ZM26S32728-59135 | [TP.java:1335] | (org) | 172.29.189.9-svc9-ZM26S32728-59135: failed sending message to 172.29.190.181-svc2-00832091-31665 (70850 bytes): java.lang.Exception: message size (70850) is greater than max bundling size (64000). Set the fragmentation/bundle size in FRAG and TP correctly, headers: GMS: GmsHeader[INSTALL_MERGE_VIEW]: view=MergeView::[172.29.190.174-svc6-00832251-874|27] (1479) ...
> {panel}
> In the case of INSTALL_MERGE_VIEW, we send the full view (*not* the DeltaView) and the digest in the header. With 1479 members (as shown the the example above), this increases the message size beyond the max bundling size.
> Possible SOLUTION
> * Place the header fields in the message's buffer instead
> * Move FRAG2 *under* GMS
> ** Investigate impact on flow control etc

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 08:09:03 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 1 Oct 2013 08:09:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-217) MVEL throws an exception
 when using bound variables and map accessors
In-Reply-To: <JIRA.12498528.1376459523000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498528.1376459523000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498528.1376459523000.8332.1380629343256@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-217.
--------------------------------

    Fix Version/s: 5.5.1.Final
                   6.0.0.CR5
       Resolution: Done

    
> MVEL throws an exception when using bound variables and map accessors
> ---------------------------------------------------------------------
>
>                 Key: DROOLS-217
>                 URL: https://issues.jboss.org/browse/DROOLS-217
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.CR1
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Minor
>             Fix For: 5.5.1.Final, 6.0.0.CR5
>
>
> Map( $c : this[ "x" ], $c op value )
> throws an exception as MVEL tries to compile the constraint 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 08:09:03 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 1 Oct 2013 08:09:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-216) Map accessors and custom
 evaluators do not work together
In-Reply-To: <JIRA.12498527.1376459367000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498527.1376459367000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498527.1376459367000.8334.1380629343331@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-216.
--------------------------------

    Fix Version/s: 5.5.1.Final
                   6.0.0.CR5
       Resolution: Done

    
> Map accessors and custom evaluators do not work together
> --------------------------------------------------------
>
>                 Key: DROOLS-216
>                 URL: https://issues.jboss.org/browse/DROOLS-216
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.CR1
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Minor
>             Fix For: 5.5.1.Final, 6.0.0.CR5
>
>
> Map( this[ "x" ] custOp value ) fails.
> The custom evaluator is passed the map itself, rather than the value 
> corresponding to the key.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 08:27:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 1 Oct 2013 08:27:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2181) TempFileProviderService
 creates a static, non-daemon thread pool
In-Reply-To: <JIRA.12501805.1380532508000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501805.1380532508000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501805.1380532508000.8376.1380630422619@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808596#comment-12808596 ] 

RH Bugzilla Integration commented on WFLY-2181:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1012968|https://bugzilla.redhat.com/show_bug.cgi?id=1012968] from POST to MODIFIED
                
> TempFileProviderService creates a static, non-daemon thread pool
> ----------------------------------------------------------------
>
>                 Key: WFLY-2181
>                 URL: https://issues.jboss.org/browse/WFLY-2181
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>
> This can prevent the server from shutting down

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 08:27:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 1 Oct 2013 08:27:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2096) WeldApplicationFactory
 doesn't implement setApplication() correctly
In-Reply-To: <JIRA.12500836.1379414469000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500836.1379414469000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500836.1379414469000.8380.1380630422825@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808597#comment-12808597 ] 

RH Bugzilla Integration commented on WFLY-2096:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1008998|https://bugzilla.redhat.com/show_bug.cgi?id=1008998] from NEW to MODIFIED
                
> WeldApplicationFactory doesn't implement setApplication() correctly
> -------------------------------------------------------------------
>
>                 Key: WFLY-2096
>                 URL: https://issues.jboss.org/browse/WFLY-2096
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld, JSF
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Martin Kouba
>            Assignee: Stuart Douglas
>
> The problem is described in WELD-913. The fix was only applied to Weld servlet support [1] and not AS7/WildFly8 integration code (most probably because the target environment of the issue was Tomcat).
> [1]
> https://github.com/weld/core/blob/master/environments/servlet/core/src/main/java/org/jboss/weld/environment/servlet/jsf/WeldApplicationFactory.java

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 09:11:02 2013
From: jira-events at lists.jboss.org (Josef Cacek (JIRA))
Date: Tue, 1 Oct 2013 09:11:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2191) Intermittent fail of
 AdvancedLdapLoginModuleTestCase and SPNEGOLoginModuleTestCase due to
 java.nio.BufferOverflowException
In-Reply-To: <JIRA.12501923.1380632972688@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501923.1380632972688@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501923.1380632972688.8453.1380633062651@jira02.app.mwc.hst.phx2.redhat.com>

Josef Cacek created WFLY-2191:
---------------------------------

             Summary: Intermittent fail of AdvancedLdapLoginModuleTestCase and SPNEGOLoginModuleTestCase due to java.nio.BufferOverflowException
                 Key: WFLY-2191
                 URL: https://issues.jboss.org/browse/WFLY-2191
             Project: WildFly
          Issue Type: Bug
          Components: Test Suite
    Affects Versions: 8.0.0.Alpha4
            Reporter: Josef Cacek
            Assignee: Josef Cacek


org.jboss.as.test.integration.security.loginmodules.negotiation.AdvancedLdapLoginModuleTestCase and
org.jboss.as.test.integration.security.loginmodules.negotiation.SPNEGOLoginModuleTestCase 
fail intermittently after java.nio.BufferOverflowException in Apache directory server. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 09:15:04 2013
From: jira-events at lists.jboss.org (Stefano Maestri (JIRA))
Date: Tue, 1 Oct 2013 09:15:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2192) MessageEndpointFactory should
 use unique RA id
In-Reply-To: <JIRA.12501926.1380633231082@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501926.1380633231082@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501926.1380633231082.8470.1380633304687@jira02.app.mwc.hst.phx2.redhat.com>

Stefano Maestri created WFLY-2192:
-------------------------------------

             Summary: MessageEndpointFactory should use unique RA id
                 Key: WFLY-2192
                 URL: https://issues.jboss.org/browse/WFLY-2192
             Project: WildFly
          Issue Type: Bug
            Reporter: Stefano Maestri
            Assignee: Stefano Maestri
            Priority: Blocker
             Fix For: 8.0.0.Beta1


This is causing a regression in TCK

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 09:32:02 2013
From: jira-events at lists.jboss.org (Kurt Stam (JIRA))
Date: Tue, 1 Oct 2013 09:32:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-266) KIE resolving dependend
	artifacts issue
In-Reply-To: <JIRA.12500919.1379513154000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500919.1379513154000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500919.1379513154000.8500.1380634322560@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kurt Stam updated DROOLS-266:
-----------------------------

    Attachment: kie-load-from-maven-issue.tgz


fixed the test
run 
mvn clean install -DskipTests=true
mvn package
                
> KIE resolving dependend artifacts issue
> ---------------------------------------
>
>                 Key: DROOLS-266
>                 URL: https://issues.jboss.org/browse/DROOLS-266
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR3
>            Reporter: Kurt Stam
>            Assignee: Mario Fusco
>         Attachments: kie-load-from-maven-issue.tgz, kie-load-from-maven-issue.tgz
>
>
> This happens when for a dependency the scope is
> - set to 'provided' and
> - a parameter (in the case ${jbpm.version}) is used in the version field.
> So the relevant entry in the pom is:
> <dependency>
>       <groupId>org.drools</groupId>
>       <artifactId>drools-core</artifactId>
>       <version>${drools.version}</version>
>       <scope>provided</scope>
>     </dependency>
> which leads to
> 11:15:02,584  WARN Dependency artifact not found for: org.jbpm:jbpm-bpmn2:${jbpm.version}
> and then the NPE. I'm guessing the parameter is not being resolved.
> 1. it probably should resolve parameters
> 2. if a dependency is scoped as 'provided' I think it is supposed to locate it on the classpath and NOT from maven. However I'm not sure this is the way that works in testing anyway.
> 3. if the dependency  cannot be found it should probably stop and not even proceed rather then warn?
> 4. it should be interesting to see why it gets the NPE.
> If you change the dependency from 'provided' to 'test' things work fine.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 09:34:02 2013
From: jira-events at lists.jboss.org (Michael Musgrove (JIRA))
Date: Tue, 1 Oct 2013 09:34:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1957) Upgrade Narayana to 5.0.0.M5
In-Reply-To: <JIRA.12499415.1377592323000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499415.1377592323000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499415.1377592323000.8503.1380634442580@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Musgrove updated WFLY-1957:
-----------------------------------

    Fix Version/s: 8.0.0.Beta1
                       (was: 8.0.0.CR1)

    
> Upgrade Narayana to 5.0.0.M5
> ----------------------------
>
>                 Key: WFLY-1957
>                 URL: https://issues.jboss.org/browse/WFLY-1957
>             Project: WildFly
>          Issue Type: Component  Upgrade
>          Components: Transactions
>            Reporter: Paul Robinson
>            Assignee: Paul Robinson
>             Fix For: 8.0.0.Beta1
>
>
> In particular, needed for the fix to WFLY-1929.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 09:34:02 2013
From: jira-events at lists.jboss.org (Michael Musgrove (JIRA))
Date: Tue, 1 Oct 2013 09:34:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1957) Upgrade Narayana to 5.0.0.M5
In-Reply-To: <JIRA.12499415.1377592323000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499415.1377592323000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499415.1377592323000.8507.1380634442769@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Musgrove reassigned WFLY-1957:
--------------------------------------

    Assignee: Michael Musgrove  (was: Paul Robinson)

    
> Upgrade Narayana to 5.0.0.M5
> ----------------------------
>
>                 Key: WFLY-1957
>                 URL: https://issues.jboss.org/browse/WFLY-1957
>             Project: WildFly
>          Issue Type: Component  Upgrade
>          Components: Transactions
>            Reporter: Paul Robinson
>            Assignee: Michael Musgrove
>             Fix For: 8.0.0.Beta1
>
>
> In particular, needed for the fix to WFLY-1929.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 09:34:02 2013
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Tue, 1 Oct 2013 09:34:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2193) Upgrade javax.json to version
	1.0.3
In-Reply-To: <JIRA.12501927.1380634375048@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501927.1380634375048@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501927.1380634375048.8508.1380634442807@jira02.app.mwc.hst.phx2.redhat.com>

Shelly McGowan created WFLY-2193:
------------------------------------

             Summary: Upgrade javax.json to version 1.0.3
                 Key: WFLY-2193
                 URL: https://issues.jboss.org/browse/WFLY-2193
             Project: WildFly
          Issue Type: Feature Request
            Reporter: Shelly McGowan
             Fix For: 8.0.0.CR1


WildFly consumes org.glassfish:javax.json artifacts, version 1.0. This needs to be updated.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 09:36:02 2013
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Tue, 1 Oct 2013 09:36:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2193) Upgrade javax.json to version
	1.0.3
In-Reply-To: <JIRA.12501927.1380634375000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501927.1380634375000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501927.1380634375000.8511.1380634562496@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan reassigned WFLY-2193:
------------------------------------

    Assignee: Shelly McGowan

    
> Upgrade javax.json to version 1.0.3
> -----------------------------------
>
>                 Key: WFLY-2193
>                 URL: https://issues.jboss.org/browse/WFLY-2193
>             Project: WildFly
>          Issue Type: Feature Request
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>             Fix For: 8.0.0.CR1
>
>
> WildFly consumes org.glassfish:javax.json artifacts, version 1.0. This needs to be updated.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 09:38:02 2013
From: jira-events at lists.jboss.org (Kurt Stam (JIRA))
Date: Tue, 1 Oct 2013 09:38:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-266) KIE resolving dependend
	artifacts issue
In-Reply-To: <JIRA.12500919.1379513154000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500919.1379513154000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500919.1379513154000.8515.1380634682500@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808637#comment-12808637 ] 

Kurt Stam commented on DROOLS-266:
----------------------------------

expected output:

------------------------------------------------------
 T E S T S
-------------------------------------------------------
Running org.overlord.dtgov.dtgovworkflows.KieTest
Reading your .m2 repo
artifact=org.overlord.dtgov.issue266:dtgov-workflows:jar:2.0.0-SNAPSHOT
0    [main] WARN  org.kie.scanner.MavenClassLoaderResolver  - Dependency artifact not found for: org.jbpm:jbpm-bpmn2:${jbpm.version}
413  [main] WARN  org.kie.scanner.MavenClassLoaderResolver  - Dependency artifact not found for: org.jbpm:jbpm-shared-services:${jbpm.version}
753  [main] WARN  org.kie.scanner.MavenClassLoaderResolver  - Dependency artifact not found for: org.jbpm:jbpm-persistence-jpa:${jbpm.version}
1097 [main] WARN  org.kie.scanner.MavenClassLoaderResolver  - Dependency artifact not found for: org.jbpm:jbpm-runtime-manager:${jbpm.version}
1416 [main] WARN  org.kie.scanner.MavenClassLoaderResolver  - Dependency artifact not found for: org.drools:drools-core:${drools.version}
1751 [main] WARN  org.kie.scanner.MavenClassLoaderResolver  - Dependency artifact not found for: org.drools:drools-compiler:${drools.version}
2108 [main] WARN  org.kie.scanner.MavenClassLoaderResolver  - Dependency artifact not found for: org.kie:kie-api:${drools.version}
2458 [main] WARN  org.kie.scanner.MavenClassLoaderResolver  - Dependency artifact not found for: org.jboss.netty:netty:${drools.version}
java.lang.NullPointerException
	at sun.net.util.URLUtil.urlNoFragString(URLUtil.java:47)
	at sun.misc.URLClassPath.getLoader(URLClassPath.java:321)
	at sun.misc.URLClassPath.access$000(URLClassPath.java:62)
	at sun.misc.URLClassPath$1.next(URLClassPath.java:221)
	at sun.misc.URLClassPath$1.hasMoreElements(URLClassPath.java:232)
	at java.net.URLClassLoader$3$1.run(URLClassLoader.java:583)
	at java.net.URLClassLoader$3$1.run(URLClassLoader.java:581)

                
> KIE resolving dependend artifacts issue
> ---------------------------------------
>
>                 Key: DROOLS-266
>                 URL: https://issues.jboss.org/browse/DROOLS-266
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR3
>            Reporter: Kurt Stam
>            Assignee: Mario Fusco
>         Attachments: kie-load-from-maven-issue.tgz, kie-load-from-maven-issue.tgz
>
>
> This happens when for a dependency the scope is
> - set to 'provided' and
> - a parameter (in the case ${jbpm.version}) is used in the version field.
> So the relevant entry in the pom is:
> <dependency>
>       <groupId>org.drools</groupId>
>       <artifactId>drools-core</artifactId>
>       <version>${drools.version}</version>
>       <scope>provided</scope>
>     </dependency>
> which leads to
> 11:15:02,584  WARN Dependency artifact not found for: org.jbpm:jbpm-bpmn2:${jbpm.version}
> and then the NPE. I'm guessing the parameter is not being resolved.
> 1. it probably should resolve parameters
> 2. if a dependency is scoped as 'provided' I think it is supposed to locate it on the classpath and NOT from maven. However I'm not sure this is the way that works in testing anyway.
> 3. if the dependency  cannot be found it should probably stop and not even proceed rather then warn?
> 4. it should be interesting to see why it gets the NPE.
> If you change the dependency from 'provided' to 'test' things work fine.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 09:42:02 2013
From: jira-events at lists.jboss.org (Ivo Studensky (JIRA))
Date: Tue, 1 Oct 2013 09:42:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1913) CLI 'module add' command fail
 if a drive letter is specified in its resource path
In-Reply-To: <JIRA.12499050.1377075768000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499050.1377075768000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499050.1377075768000.8518.1380634922516@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808638#comment-12808638 ] 

Ivo Studensky commented on WFLY-1913:
-------------------------------------

I've hacked up a simple test case for the CLI deployment archive involving a simple war which works as expected.
I will continue on this and test it with the archive you attached.

https://github.com/istudens/wildfly/commit/411d60fa299484db688ccde747a04bc19107b70a
                
> CLI 'module add' command fail if a drive letter is specified in its resource path
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-1913
>                 URL: https://issues.jboss.org/browse/WFLY-1913
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>             Fix For: 8.0.0.Beta1
>
>         Attachments: install-mojarra-2.0.0.cli
>
>
> If a drive letter is specified in the resource path the module add command fails on MS Windows. It cannot locate such a resource because of doubled drive letter in the translated path.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 09:45:02 2013
From: jira-events at lists.jboss.org (Ivo Studensky (JIRA))
Date: Tue, 1 Oct 2013 09:45:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1913) CLI 'module add' command fail
 if a drive letter is specified in its resource path
In-Reply-To: <JIRA.12499050.1377075768000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499050.1377075768000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499050.1377075768000.8526.1380635102782@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808640#comment-12808640 ] 

Ivo Studensky commented on WFLY-1913:
-------------------------------------

Ah, nevermind. It needs a module add command included in the deploy.scr script. I will enhance the test case accordingly and fix the issue.
                
> CLI 'module add' command fail if a drive letter is specified in its resource path
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-1913
>                 URL: https://issues.jboss.org/browse/WFLY-1913
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>             Fix For: 8.0.0.Beta1
>
>         Attachments: install-mojarra-2.0.0.cli
>
>
> If a drive letter is specified in the resource path the module add command fails on MS Windows. It cannot locate such a resource because of doubled drive letter in the translated path.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 09:53:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Tue, 1 Oct 2013 09:53:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2181) TempFileProviderService
 creates a static, non-daemon thread pool
In-Reply-To: <JIRA.12501805.1380532508000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501805.1380532508000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501805.1380532508000.8575.1380635582589@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-2181.
----------------------------------

    Fix Version/s: 8.0.0.Beta1
       Resolution: Done

    
> TempFileProviderService creates a static, non-daemon thread pool
> ----------------------------------------------------------------
>
>                 Key: WFLY-2181
>                 URL: https://issues.jboss.org/browse/WFLY-2181
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Beta1
>
>
> This can prevent the server from shutting down

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 09:55:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Tue, 1 Oct 2013 09:55:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2156) Upgrade scannotation to 1.0.3
In-Reply-To: <JIRA.12501531.1380123304000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501531.1380123304000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501531.1380123304000.8578.1380635702673@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas updated WFLY-2156:
---------------------------------

    Assignee: Weinan Li  (was: Stuart Douglas)

    
> Upgrade scannotation to 1.0.3
> -----------------------------
>
>                 Key: WFLY-2156
>                 URL: https://issues.jboss.org/browse/WFLY-2156
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: REST
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Weinan Li
>            Assignee: Weinan Li
>
> RESTEasy has a dependency on 1.0.3 of scannotation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 09:57:02 2013
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Tue, 1 Oct 2013 09:57:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2193) Upgrade javax.json to version
	1.0.3
In-Reply-To: <JIRA.12501927.1380634375000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501927.1380634375000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501927.1380634375000.8586.1380635822761@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated WFLY-2193:
---------------------------------

    Git Pull Request: https://github.com/wildfly/wildfly/pull/5187

    
> Upgrade javax.json to version 1.0.3
> -----------------------------------
>
>                 Key: WFLY-2193
>                 URL: https://issues.jboss.org/browse/WFLY-2193
>             Project: WildFly
>          Issue Type: Feature Request
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>             Fix For: 8.0.0.CR1
>
>
> WildFly consumes org.glassfish:javax.json artifacts, version 1.0. This needs to be updated.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 10:03:02 2013
From: jira-events at lists.jboss.org (Ivo Studensky (JIRA))
Date: Tue, 1 Oct 2013 10:03:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1913) CLI 'module add' command fail
 if a drive letter is specified in its resource path
In-Reply-To: <JIRA.12499050.1377075768000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499050.1377075768000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499050.1377075768000.8600.1380636182814@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808640#comment-12808640 ] 

Ivo Studensky edited comment on WFLY-1913 at 10/1/13 10:02 AM:
---------------------------------------------------------------

Ah, nevermind, too many context switches on my side. It needs a module add command included in the deploy.scr script. I will enhance the test case accordingly and fix the issue.
                
      was (Author: istudens):
    Ah, nevermind. It needs a module add command included in the deploy.scr script. I will enhance the test case accordingly and fix the issue.
                  
> CLI 'module add' command fail if a drive letter is specified in its resource path
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-1913
>                 URL: https://issues.jboss.org/browse/WFLY-1913
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>             Fix For: 8.0.0.Beta1
>
>         Attachments: install-mojarra-2.0.0.cli
>
>
> If a drive letter is specified in the resource path the module add command fails on MS Windows. It cannot locate such a resource because of doubled drive letter in the translated path.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 10:19:02 2013
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Tue, 1 Oct 2013 10:19:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2193) Upgrade javax.json to version
	1.0.3
In-Reply-To: <JIRA.12501927.1380634375000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501927.1380634375000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501927.1380634375000.8635.1380637142508@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated WFLY-2193:
---------------------------------

    Issue Type: Component  Upgrade  (was: Feature Request)

    
> Upgrade javax.json to version 1.0.3
> -----------------------------------
>
>                 Key: WFLY-2193
>                 URL: https://issues.jboss.org/browse/WFLY-2193
>             Project: WildFly
>          Issue Type: Component  Upgrade
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>             Fix For: 8.0.0.CR1
>
>
> WildFly consumes org.glassfish:javax.json artifacts, version 1.0. This needs to be updated.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 10:42:02 2013
From: jira-events at lists.jboss.org (Radim Vansa (JIRA))
Date: Tue, 1 Oct 2013 10:42:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1711) DELAY2: Do not keep the
	thread waiting
In-Reply-To: <JIRA.12501933.1380638415577@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501933.1380638415577@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501933.1380638415577.8706.1380638522526@jira02.app.mwc.hst.phx2.redhat.com>

Radim Vansa created JGRP-1711:
---------------------------------

             Summary: DELAY2: Do not keep the thread waiting
                 Key: JGRP-1711
                 URL: https://issues.jboss.org/browse/JGRP-1711
             Project: JGroups
          Issue Type: Feature Request
    Affects Versions: 3.4
            Reporter: Radim Vansa
            Assignee: Bela Ban
            Priority: Minor


Current version of the DELAY protocol is rather simplistic - the thread is just put to sleep for some period of time. However, this does not reflect the network delay very well as it consumes the thread during the latency period.

As the protocol should be usually placed just above TP, I'd suggest that for outcoming delay, the message/event should be placed into priority queue and another dedicated thread should pass it down after the latency period.

For the incoming messages, we'd probably need a way to access TP's threadpools, and to find out where the currently executing thread belongs. Then, the message/event would also use priority queue and take a thread from the same threadpool in order to deliver it to upper layers.

Another feature of this new implementation of delay protocol would be to allow constant latency, or rather specify the latency interval (from - to: currently from is always 0).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 10:44:02 2013
From: jira-events at lists.jboss.org (Radim Vansa (JIRA))
Date: Tue, 1 Oct 2013 10:44:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1711) DELAY2: Do not keep the
	thread waiting
In-Reply-To: <JIRA.12501933.1380638415000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501933.1380638415000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501933.1380638415000.8710.1380638642550@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808660#comment-12808660 ] 

Radim Vansa commented on JGRP-1711:
-----------------------------------

As the implementation of incoming messages delay would be more complicated, I think that implementing outcoming delay could be sufficient. Anyway, I can't distinguish where the message got delayed on network. What was the reason to provide both delays in DELAY?
                
> DELAY2: Do not keep the thread waiting
> --------------------------------------
>
>                 Key: JGRP-1711
>                 URL: https://issues.jboss.org/browse/JGRP-1711
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 3.4
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>            Priority: Minor
>
> Current version of the DELAY protocol is rather simplistic - the thread is just put to sleep for some period of time. However, this does not reflect the network delay very well as it consumes the thread during the latency period.
> As the protocol should be usually placed just above TP, I'd suggest that for outcoming delay, the message/event should be placed into priority queue and another dedicated thread should pass it down after the latency period.
> For the incoming messages, we'd probably need a way to access TP's threadpools, and to find out where the currently executing thread belongs. Then, the message/event would also use priority queue and take a thread from the same threadpool in order to deliver it to upper layers.
> Another feature of this new implementation of delay protocol would be to allow constant latency, or rather specify the latency interval (from - to: currently from is always 0).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 10:52:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 1 Oct 2013 10:52:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1711) DELAY2: Do not keep the
	thread waiting
In-Reply-To: <JIRA.12501933.1380638415000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501933.1380638415000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501933.1380638415000.8731.1380639122850@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808664#comment-12808664 ] 

Bela Ban commented on JGRP-1711:
--------------------------------

I think the reason was that with loopback, messages are copied and sent back up. But you're right: this is done above the transport so the above is moot.
                
> DELAY2: Do not keep the thread waiting
> --------------------------------------
>
>                 Key: JGRP-1711
>                 URL: https://issues.jboss.org/browse/JGRP-1711
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 3.4
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>            Priority: Minor
>
> Current version of the DELAY protocol is rather simplistic - the thread is just put to sleep for some period of time. However, this does not reflect the network delay very well as it consumes the thread during the latency period.
> As the protocol should be usually placed just above TP, I'd suggest that for outcoming delay, the message/event should be placed into priority queue and another dedicated thread should pass it down after the latency period.
> For the incoming messages, we'd probably need a way to access TP's threadpools, and to find out where the currently executing thread belongs. Then, the message/event would also use priority queue and take a thread from the same threadpool in order to deliver it to upper layers.
> Another feature of this new implementation of delay protocol would be to allow constant latency, or rather specify the latency interval (from - to: currently from is always 0).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 10:54:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 1 Oct 2013 10:54:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1711) DELAY2: Do not keep the
	thread waiting
In-Reply-To: <JIRA.12501933.1380638415000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501933.1380638415000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501933.1380638415000.8734.1380639242626@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1711:
---------------------------

    Fix Version/s: 3.4


Radim,
I'm busy with 2 other issues. If you submit a pull request by Friday morning, I can get your fix into 3.4, otherwise I'll push it into 3.5.
                
> DELAY2: Do not keep the thread waiting
> --------------------------------------
>
>                 Key: JGRP-1711
>                 URL: https://issues.jboss.org/browse/JGRP-1711
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 3.4
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.4
>
>
> Current version of the DELAY protocol is rather simplistic - the thread is just put to sleep for some period of time. However, this does not reflect the network delay very well as it consumes the thread during the latency period.
> As the protocol should be usually placed just above TP, I'd suggest that for outcoming delay, the message/event should be placed into priority queue and another dedicated thread should pass it down after the latency period.
> For the incoming messages, we'd probably need a way to access TP's threadpools, and to find out where the currently executing thread belongs. Then, the message/event would also use priority queue and take a thread from the same threadpool in order to deliver it to upper layers.
> Another feature of this new implementation of delay protocol would be to allow constant latency, or rather specify the latency interval (from - to: currently from is always 0).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 11:51:02 2013
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Tue, 1 Oct 2013 11:51:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2178) exception in distributable
 webapp leads to infinispan lock contention
In-Reply-To: <JIRA.12501776.1380388525000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501776.1380388525000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501776.1380388525000.8825.1380642662748@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro closed WFLY-2178.
------------------------------

    Resolution: Rejected


Fixed by UNDERTOW-107.
The lock contention is due to the lock never being released because undertow threw an exception when attempting to trigger the session destroy listener.
                
> exception in distributable webapp leads to infinispan lock contention 
> ----------------------------------------------------------------------
>
>                 Key: WFLY-2178
>                 URL: https://issues.jboss.org/browse/WFLY-2178
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Thomas Fr?hbeck
>            Assignee: Paul Ferraro
>         Attachments: lockContention_server.log
>
>
> Exception in session.invalidate leads to:
> ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-23) ISPN000136: Execution error: org.infinispan.util.concurrent.TimeoutExceptio
> n: Unable to acquire lock after [15 seconds] on key [FIsDATdNvtWFPLx-x-00_6x0] for requestor [GlobalTransaction:<storage/web>:171:local]! Lock held by [GlobalTransaction:<storage/web>:170:local]
> server.log attached

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Tue Oct  1 11:53:02 2013
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Tue, 1 Oct 2013 11:53:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1885) ServiceActivator blocks
 server startup if more than 8 services - platformspecific
In-Reply-To: <JIRA.12498645.1376549515000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498645.1376549515000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498645.1376549515000.8829.1380642782696@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro closed WFLY-1885.
------------------------------

    Resolution: Done


Re-closing.  Please read previous comment regarding singleton service creation.
                
> ServiceActivator blocks server startup if more than 8 services - platformspecific
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-1885
>                 URL: https://issues.jboss.org/browse/WFLY-1885
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering, Server
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Thomas Fr?hbeck
>            Assignee: Paul Ferraro
>            Priority: Minor
>             Fix For: 8.0.0.Beta1
>
>         Attachments: stack.log.gz, wildfly-Beta1_blocked_server_on_8_HASingletons.txt.gz
>
>
> We try to start more than 8 services by ServiceActivator.
> We follow hasingleton quickstart.
> Server startup is blocked on Linux but not on windows (?!?).
> If we introduce a delay of e.g. 1 second, all services start correctly also on Linux:
> public void activate(ServiceActivatorContext context) {
>   ESMSSingletonServiceBase<T> service = getSingletonService();
>   log.info("ESMSService will be installed: " + service.getSingletonServiceName());
>   SingletonService<String> singleton = new SingletonService<String>(service.getSingletonServiceName(), service);
>   singleton.build(new DelegatingServiceContainer(context.getServiceTarget(), context.getServiceRegistry()))
>     .addDependency(ServerEnvironmentService.SERVICE_NAME, ServerEnvironment.class, service.env)
>     .setInitialMode(ServiceController.Mode.ACTIVE).install();
>   // TODO: diesen Workaround evtl mal beheben. 
>   // (Server startet im Moment nicht anders... zumindest nicht auf Linux! Timingproblem?)
>   try {
> 	Thread.sleep(1000);
>   } catch (InterruptedException e) {}
> Thread dump of Linux blocked server attached

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Tue Oct  1 11:55:02 2013
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Tue, 1 Oct 2013 11:55:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-928) Starting a server with
 multiple web apps , causes  deploymeent failures
In-Reply-To: <JIRA.12486589.1362603773000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12486589.1362603773000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12486589.1362603773000.8838.1380642902927@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro closed WFLY-928.
-----------------------------

    Fix Version/s: 8.0.0.Beta1
       Resolution: Done


Fixed by introduction of GlobalComponentRegistryService.
                
> Starting a server with multiple web apps , causes  deploymeent failures
> -----------------------------------------------------------------------
>
>                 Key: WFLY-928
>                 URL: https://issues.jboss.org/browse/WFLY-928
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>            Reporter: Shay Matasaro
>            Assignee: Paul Ferraro
>             Fix For: 8.0.0.Beta1
>
>
> When the server starts with multiple web apps , and each one tries to create its cache , the first one locks all other because of a lock on cache manager see ISPN-2898
> this results in deployment failure , and the apps will not get redeployed

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 12:32:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 1 Oct 2013 12:32:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-266) KIE resolving dependend
	artifacts issue
In-Reply-To: <JIRA.12500919.1379513154000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500919.1379513154000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500919.1379513154000.8925.1380645122609@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated DROOLS-266:
-------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1014157

    
> KIE resolving dependend artifacts issue
> ---------------------------------------
>
>                 Key: DROOLS-266
>                 URL: https://issues.jboss.org/browse/DROOLS-266
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR3
>            Reporter: Kurt Stam
>            Assignee: Mario Fusco
>         Attachments: kie-load-from-maven-issue.tgz, kie-load-from-maven-issue.tgz
>
>
> This happens when for a dependency the scope is
> - set to 'provided' and
> - a parameter (in the case ${jbpm.version}) is used in the version field.
> So the relevant entry in the pom is:
> <dependency>
>       <groupId>org.drools</groupId>
>       <artifactId>drools-core</artifactId>
>       <version>${drools.version}</version>
>       <scope>provided</scope>
>     </dependency>
> which leads to
> 11:15:02,584  WARN Dependency artifact not found for: org.jbpm:jbpm-bpmn2:${jbpm.version}
> and then the NPE. I'm guessing the parameter is not being resolved.
> 1. it probably should resolve parameters
> 2. if a dependency is scoped as 'provided' I think it is supposed to locate it on the classpath and NOT from maven. However I'm not sure this is the way that works in testing anyway.
> 3. if the dependency  cannot be found it should probably stop and not even proceed rather then warn?
> 4. it should be interesting to see why it gets the NPE.
> If you change the dependency from 'provided' to 'test' things work fine.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 12:47:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 1 Oct 2013 12:47:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-266) KIE resolving dependend
	artifacts issue
In-Reply-To: <JIRA.12500919.1379513154000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500919.1379513154000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500919.1379513154000.8938.1380646022631@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808699#comment-12808699 ] 

RH Bugzilla Integration commented on DROOLS-266:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> made a comment on [bug 1014157|https://bugzilla.redhat.com/show_bug.cgi?id=1014157]

Fixed by https://github.com/droolsjbpm/drools/commit/bcbfd88b3

Note that this fix works only if you have kie-ci on the classpath.
                
> KIE resolving dependend artifacts issue
> ---------------------------------------
>
>                 Key: DROOLS-266
>                 URL: https://issues.jboss.org/browse/DROOLS-266
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR3
>            Reporter: Kurt Stam
>            Assignee: Mario Fusco
>         Attachments: kie-load-from-maven-issue.tgz, kie-load-from-maven-issue.tgz
>
>
> This happens when for a dependency the scope is
> - set to 'provided' and
> - a parameter (in the case ${jbpm.version}) is used in the version field.
> So the relevant entry in the pom is:
> <dependency>
>       <groupId>org.drools</groupId>
>       <artifactId>drools-core</artifactId>
>       <version>${drools.version}</version>
>       <scope>provided</scope>
>     </dependency>
> which leads to
> 11:15:02,584  WARN Dependency artifact not found for: org.jbpm:jbpm-bpmn2:${jbpm.version}
> and then the NPE. I'm guessing the parameter is not being resolved.
> 1. it probably should resolve parameters
> 2. if a dependency is scoped as 'provided' I think it is supposed to locate it on the classpath and NOT from maven. However I'm not sure this is the way that works in testing anyway.
> 3. if the dependency  cannot be found it should probably stop and not even proceed rather then warn?
> 4. it should be interesting to see why it gets the NPE.
> If you change the dependency from 'provided' to 'test' things work fine.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 12:47:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 1 Oct 2013 12:47:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-266) KIE resolving dependend
	artifacts issue
In-Reply-To: <JIRA.12500919.1379513154000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500919.1379513154000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500919.1379513154000.8941.1380646022757@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808700#comment-12808700 ] 

RH Bugzilla Integration commented on DROOLS-266:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> changed the Status of [bug 1014157|https://bugzilla.redhat.com/show_bug.cgi?id=1014157] from NEW to MODIFIED
                
> KIE resolving dependend artifacts issue
> ---------------------------------------
>
>                 Key: DROOLS-266
>                 URL: https://issues.jboss.org/browse/DROOLS-266
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR3
>            Reporter: Kurt Stam
>            Assignee: Mario Fusco
>         Attachments: kie-load-from-maven-issue.tgz, kie-load-from-maven-issue.tgz
>
>
> This happens when for a dependency the scope is
> - set to 'provided' and
> - a parameter (in the case ${jbpm.version}) is used in the version field.
> So the relevant entry in the pom is:
> <dependency>
>       <groupId>org.drools</groupId>
>       <artifactId>drools-core</artifactId>
>       <version>${drools.version}</version>
>       <scope>provided</scope>
>     </dependency>
> which leads to
> 11:15:02,584  WARN Dependency artifact not found for: org.jbpm:jbpm-bpmn2:${jbpm.version}
> and then the NPE. I'm guessing the parameter is not being resolved.
> 1. it probably should resolve parameters
> 2. if a dependency is scoped as 'provided' I think it is supposed to locate it on the classpath and NOT from maven. However I'm not sure this is the way that works in testing anyway.
> 3. if the dependency  cannot be found it should probably stop and not even proceed rather then warn?
> 4. it should be interesting to see why it gets the NPE.
> If you change the dependency from 'provided' to 'test' things work fine.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 12:49:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 1 Oct 2013 12:49:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-266) KIE resolving dependend
	artifacts issue
In-Reply-To: <JIRA.12500919.1379513154000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500919.1379513154000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500919.1379513154000.8945.1380646142622@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-266.
--------------------------------

    Fix Version/s: 6.0.0.CR5
       Resolution: Done

    
> KIE resolving dependend artifacts issue
> ---------------------------------------
>
>                 Key: DROOLS-266
>                 URL: https://issues.jboss.org/browse/DROOLS-266
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR3
>            Reporter: Kurt Stam
>            Assignee: Mario Fusco
>             Fix For: 6.0.0.CR5
>
>         Attachments: kie-load-from-maven-issue.tgz, kie-load-from-maven-issue.tgz
>
>
> This happens when for a dependency the scope is
> - set to 'provided' and
> - a parameter (in the case ${jbpm.version}) is used in the version field.
> So the relevant entry in the pom is:
> <dependency>
>       <groupId>org.drools</groupId>
>       <artifactId>drools-core</artifactId>
>       <version>${drools.version}</version>
>       <scope>provided</scope>
>     </dependency>
> which leads to
> 11:15:02,584  WARN Dependency artifact not found for: org.jbpm:jbpm-bpmn2:${jbpm.version}
> and then the NPE. I'm guessing the parameter is not being resolved.
> 1. it probably should resolve parameters
> 2. if a dependency is scoped as 'provided' I think it is supposed to locate it on the classpath and NOT from maven. However I'm not sure this is the way that works in testing anyway.
> 3. if the dependency  cannot be found it should probably stop and not even proceed rather then warn?
> 4. it should be interesting to see why it gets the NPE.
> If you change the dependency from 'provided' to 'test' things work fine.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 13:14:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 1 Oct 2013 13:14:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2194) Difficulty Enabling SSL for
 Management Interfaces Using CLI
In-Reply-To: <JIRA.12501945.1380647585782@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501945.1380647585782@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501945.1380647585782.8970.1380647642623@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-2194:
--------------------------------------

             Summary: Difficulty Enabling SSL for Management Interfaces Using CLI
                 Key: WFLY-2194
                 URL: https://issues.jboss.org/browse/WFLY-2194
             Project: WildFly
          Issue Type: Task
          Components: CLI, Domain Management, Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 8.0.0.Beta1


Trying to enable the HTTPS port for the HTTP management interface using the CLI results in the following: -

{code}
[standalone at localhost:9990 /] ./core-service=management/management-interface=http-interface:write-attribute(name=secure-socket-binding, value=management-https)
Communication error: java.util.concurrent.ExecutionException: Operation failed: Operation failed: Channel closed
{code}

Server side the following is logged: -

{code}
17:59:54,193 INFO  [org.jboss.as.server] (management-handler-thread - 4) JBAS015890: Creating http management service using socket-binding (management-http) and secure-socket-binding (management-https)
17:59:54,212 INFO  [org.jboss.as.server] (management-handler-thread - 4) JBAS015888: Creating http management service using socket-binding (management-http)
17:59:54,236 WARN  [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014626: Operation was interrupted before stability could be reached
{code}

i.e. What appears to be happening is that as communication is lost with the client the update is being detected as a failure.

As interface updates do result in restarting the services used to make the updates it may be better to switch these to reload required updates instead of being immediate - also the chances are that security realm updates would be made simultaneously and those also require a reload.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 13:14:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 1 Oct 2013 13:14:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2194) Difficulty Enabling SSL for
 Management Interfaces Using CLI
In-Reply-To: <JIRA.12501945.1380647585000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501945.1380647585000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501945.1380647585000.8973.1380647642792@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2194:
-----------------------------------

    Affects Version/s: 8.0.0.Alpha4

    
> Difficulty Enabling SSL for Management Interfaces Using CLI
> -----------------------------------------------------------
>
>                 Key: WFLY-2194
>                 URL: https://issues.jboss.org/browse/WFLY-2194
>             Project: WildFly
>          Issue Type: Task
>          Components: CLI, Domain Management, Security
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Beta1
>
>
> Trying to enable the HTTPS port for the HTTP management interface using the CLI results in the following: -
> {code}
> [standalone at localhost:9990 /] ./core-service=management/management-interface=http-interface:write-attribute(name=secure-socket-binding, value=management-https)
> Communication error: java.util.concurrent.ExecutionException: Operation failed: Operation failed: Channel closed
> {code}
> Server side the following is logged: -
> {code}
> 17:59:54,193 INFO  [org.jboss.as.server] (management-handler-thread - 4) JBAS015890: Creating http management service using socket-binding (management-http) and secure-socket-binding (management-https)
> 17:59:54,212 INFO  [org.jboss.as.server] (management-handler-thread - 4) JBAS015888: Creating http management service using socket-binding (management-http)
> 17:59:54,236 WARN  [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014626: Operation was interrupted before stability could be reached
> {code}
> i.e. What appears to be happening is that as communication is lost with the client the update is being detected as a failure.
> As interface updates do result in restarting the services used to make the updates it may be better to switch these to reload required updates instead of being immediate - also the chances are that security realm updates would be made simultaneously and those also require a reload.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 13:49:02 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Tue, 1 Oct 2013 13:49:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2195) add defensive check against
 EntityManagerFactory/EntityManager already being closed by ill-behaved
 deployment
In-Reply-To: <JIRA.12501948.1380649737008@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501948.1380649737008@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501948.1380649737008.9008.1380649742929@jira02.app.mwc.hst.phx2.redhat.com>

Scott Marlow created WFLY-2195:
----------------------------------

             Summary: add defensive check against EntityManagerFactory/EntityManager already being closed by ill-behaved deployment
                 Key: WFLY-2195
                 URL: https://issues.jboss.org/browse/WFLY-2195
             Project: WildFly
          Issue Type: Bug
          Components: JPA / Hibernate
            Reporter: Scott Marlow
            Assignee: Scott Marlow
             Fix For: 8.0.0.CR1


When closing container managed entity manager or entity manager factory, check if the entity manager factory was already closed unexpectedly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 13:51:02 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Tue, 1 Oct 2013 13:51:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2195) add defensive check against
 EntityManagerFactory/EntityManager already being closed by ill-behaved
 deployment
In-Reply-To: <JIRA.12501948.1380649737000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501948.1380649737000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501948.1380649737000.9011.1380649862545@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808709#comment-12808709 ] 

Scott Marlow commented on WFLY-2195:
------------------------------------

This is needed for the entityManagerFactoryCloseExceptions tck test.
                
> add defensive check against EntityManagerFactory/EntityManager already being closed by ill-behaved deployment
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2195
>                 URL: https://issues.jboss.org/browse/WFLY-2195
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 8.0.0.CR1
>
>
> When closing container managed entity manager or entity manager factory, check if the entity manager factory was already closed unexpectedly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 14:27:02 2013
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Tue, 1 Oct 2013 14:27:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2193) Upgrade javax.json to version
	1.0.3
In-Reply-To: <JIRA.12501927.1380634375000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501927.1380634375000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501927.1380634375000.9052.1380652022564@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated WFLY-2193:
---------------------------------

    Fix Version/s: 8.0.0.Beta1
                       (was: 8.0.0.CR1)

    
> Upgrade javax.json to version 1.0.3
> -----------------------------------
>
>                 Key: WFLY-2193
>                 URL: https://issues.jboss.org/browse/WFLY-2193
>             Project: WildFly
>          Issue Type: Component  Upgrade
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>             Fix For: 8.0.0.Beta1
>
>
> WildFly consumes org.glassfish:javax.json artifacts, version 1.0. This needs to be updated.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 14:27:02 2013
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Tue, 1 Oct 2013 14:27:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2193) Upgrade javax.json to version
	1.0.3
In-Reply-To: <JIRA.12501927.1380634375000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501927.1380634375000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501927.1380634375000.9053.1380652022635@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan resolved WFLY-2193.
----------------------------------

    Resolution: Done


The pull request has been merged. Resolving.
                
> Upgrade javax.json to version 1.0.3
> -----------------------------------
>
>                 Key: WFLY-2193
>                 URL: https://issues.jboss.org/browse/WFLY-2193
>             Project: WildFly
>          Issue Type: Component  Upgrade
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>             Fix For: 8.0.0.Beta1
>
>
> WildFly consumes org.glassfish:javax.json artifacts, version 1.0. This needs to be updated.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 14:37:02 2013
From: jira-events at lists.jboss.org (=?UTF-8?Q?Micha=C5=82_Zegan_=28JIRA=29?=)
Date: Tue, 1 Oct 2013 14:37:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2196) add x-forwarded-* headers
	support
In-Reply-To: <JIRA.12501951.1380652584167@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501951.1380652584167@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501951.1380652584167.9065.1380652622516@jira02.app.mwc.hst.phx2.redhat.com>

Micha? Zegan created WFLY-2196:
----------------------------------

             Summary: add x-forwarded-* headers support
                 Key: WFLY-2196
                 URL: https://issues.jboss.org/browse/WFLY-2196
             Project: WildFly
          Issue Type: Feature Request
            Reporter: Micha? Zegan
            Priority: Minor


Hello.
If it is desirable, can you add the possibility for wildfly/undertow subsystem to retrieve x-forwarded-host and similar headers and set a remote ip address and hostname based on it?
This header is set by proxy servers to indicate proxies this request has passed and to indicate the client's real ip address.
It's extremely useful if an application checks and uses the hostname or ip of a client that connects to it.
In the case of wildfly directly open to the public, the ip and host given will be that of a client, but if the server where an application is running is just a backend server and there is a frontend before it that proxies to it, the ip and host will be that of the proxy, often localhost if the proxy sits on the same machine, that is undesirable because you don't want to ip-ban a proxy.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Tue Oct  1 16:16:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 1 Oct 2013 16:16:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2197)
 ClientCompatibilityUnitTestCase is broken in an IPv6 environment
In-Reply-To: <JIRA.12501953.1380658491711@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501953.1380658491711@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501953.1380658491711.9102.1380658563453@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-2197:
--------------------------------------

             Summary: ClientCompatibilityUnitTestCase is broken in an IPv6 environment
                 Key: WFLY-2197
                 URL: https://issues.jboss.org/browse/WFLY-2197
             Project: WildFly
          Issue Type: Bug
          Components: Domain Management, Test Suite
    Affects Versions: 8.0.0.Alpha4
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
            Priority: Minor
             Fix For: 8.0.0.Beta1


ClientCompatibilityUnitTestCase has "localhost" hard coded as the address it tries to connect to. This fails when IPv6 is configured for testsuite runs, as the server is not listening on 127.0.0.1 but rather ::1.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 16:32:02 2013
From: jira-events at lists.jboss.org (Kurt Stam (JIRA))
Date: Tue, 1 Oct 2013 16:32:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-194) Add support in KIE to
 register custom Wagons
In-Reply-To: <JIRA.12496882.1374227726000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496882.1374227726000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496882.1374227726000.9106.1380659522619@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808727#comment-12808727 ] 

Kurt Stam commented on DROOLS-194:
----------------------------------

Hi Mario,

1. We store the kieJars in our S-RAMP repository (instead of maven). 

2. Now when KIE wants to read this kiejar (https://github.com/Governance/dtgov/blob/master/dtgov-war/src/main/java/org/overlord/dtgov/jbpm/util/KieUtil.java) we register the sramp Wagon extension:
     
<code>
Extension extension = new Extension();
     extension.setArtifactId("s-ramp-wagon"); //$NON-NLS-1$
     extension.setGroupId("org.overlord.sramp"); //$NON-NLS-1$
     extension.setVersion(wagonVersion);
     build.addExtension(extension);
     project.setBuild(build);
</code>
So this registers the sramp protocol.

The issue is that in your Aether class you don't honor this custom protocol. So to fix this we added
<code>
@Override
        public Wagon lookup( String roleHint ) throws Exception {
            if ( "http".equals( roleHint ) ) { //$NON-NLS-1$
                return new AhcWagon();
            }
            if ( "sramp".equals( roleHint ) ) { //$NON-NLS-1$
                return new SrampWagonProxy();
            }
            return null;
        }

</code>
However it should be possible to have it figure this out byitself; or at least one should be able to add Wagon by way of configuration.

I'm going to add a test for it using something like the FileWagon so you don't need a running S-RAMP server.

                
> Add support in KIE to register custom Wagons
> --------------------------------------------
>
>                 Key: DROOLS-194
>                 URL: https://issues.jboss.org/browse/DROOLS-194
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Kurt Stam
>            Assignee: Mark Proctor
>
> The ManualWagonProvider subclass of Aether in KIE registers the HTTPWagon. It should be possible to add your own Wagon through config our automated machinery when another Wagon is put on the classpath and references in the build/extensions of a MavenProject. To get the SrampWagon to work we used the following code:
> {quote}
> private static class ManualWagonProvider implements WagonProvider {
>         public Wagon lookup( String roleHint ) throws Exception {
>             if ( "http".equals( roleHint ) ) {
>                 return new AhcWagon();
>             }
>             if ( "sramp".equals( roleHint ) ) {
>                 return new SrampWagon();
>             }
>             return null;
>         }
>         public void release( Wagon wagon ) { }
>     }
> {quote}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 16:32:02 2013
From: jira-events at lists.jboss.org (Kurt Stam (JIRA))
Date: Tue, 1 Oct 2013 16:32:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-194) Add support in KIE to
 register custom Wagons
In-Reply-To: <JIRA.12496882.1374227726000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496882.1374227726000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496882.1374227726000.9109.1380659522824@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808727#comment-12808727 ] 

Kurt Stam edited comment on DROOLS-194 at 10/1/13 4:31 PM:
-----------------------------------------------------------

Hi Mario,

1. We store the kieJars in our S-RAMP repository (instead of maven). 

2. Now when KIE wants to read this kiejar (https://github.com/Governance/dtgov/blob/master/dtgov-war/src/main/java/org/overlord/dtgov/jbpm/util/KieUtil.java) we register the sramp Wagon extension:
     
{code:java}
Extension extension = new Extension();
     extension.setArtifactId("s-ramp-wagon"); //$NON-NLS-1$
     extension.setGroupId("org.overlord.sramp"); //$NON-NLS-1$
     extension.setVersion(wagonVersion);
     build.addExtension(extension);
     project.setBuild(build);
{code:}
So this registers the sramp protocol.

The issue is that in your Aether class you don't honor this custom protocol. So to fix this we added
{code:java}
@Override
        public Wagon lookup( String roleHint ) throws Exception {
            if ( "http".equals( roleHint ) ) { //$NON-NLS-1$
                return new AhcWagon();
            }
            if ( "sramp".equals( roleHint ) ) { //$NON-NLS-1$
                return new SrampWagonProxy();
            }
            return null;
        }

{code}
However it should be possible to have it figure this out byitself; or at least one should be able to add Wagon by way of configuration.

I'm going to add a test for it using something like the FileWagon so you don't need a running S-RAMP server.

                
      was (Author: kurtstam):
    Hi Mario,

1. We store the kieJars in our S-RAMP repository (instead of maven). 

2. Now when KIE wants to read this kiejar (https://github.com/Governance/dtgov/blob/master/dtgov-war/src/main/java/org/overlord/dtgov/jbpm/util/KieUtil.java) we register the sramp Wagon extension:
     
<code>
Extension extension = new Extension();
     extension.setArtifactId("s-ramp-wagon"); //$NON-NLS-1$
     extension.setGroupId("org.overlord.sramp"); //$NON-NLS-1$
     extension.setVersion(wagonVersion);
     build.addExtension(extension);
     project.setBuild(build);
</code>
So this registers the sramp protocol.

The issue is that in your Aether class you don't honor this custom protocol. So to fix this we added
<code>
@Override
        public Wagon lookup( String roleHint ) throws Exception {
            if ( "http".equals( roleHint ) ) { //$NON-NLS-1$
                return new AhcWagon();
            }
            if ( "sramp".equals( roleHint ) ) { //$NON-NLS-1$
                return new SrampWagonProxy();
            }
            return null;
        }

</code>
However it should be possible to have it figure this out byitself; or at least one should be able to add Wagon by way of configuration.

I'm going to add a test for it using something like the FileWagon so you don't need a running S-RAMP server.

                  
> Add support in KIE to register custom Wagons
> --------------------------------------------
>
>                 Key: DROOLS-194
>                 URL: https://issues.jboss.org/browse/DROOLS-194
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Kurt Stam
>            Assignee: Mark Proctor
>
> The ManualWagonProvider subclass of Aether in KIE registers the HTTPWagon. It should be possible to add your own Wagon through config our automated machinery when another Wagon is put on the classpath and references in the build/extensions of a MavenProject. To get the SrampWagon to work we used the following code:
> {quote}
> private static class ManualWagonProvider implements WagonProvider {
>         public Wagon lookup( String roleHint ) throws Exception {
>             if ( "http".equals( roleHint ) ) {
>                 return new AhcWagon();
>             }
>             if ( "sramp".equals( roleHint ) ) {
>                 return new SrampWagon();
>             }
>             return null;
>         }
>         public void release( Wagon wagon ) { }
>     }
> {quote}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 18:47:02 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 1 Oct 2013 18:47:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2190) Priviledge alignment for
	scoped resources
In-Reply-To: <JIRA.12501904.1380621634000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501904.1380621634000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501904.1380621634000.9176.1380667622696@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-2190:
-----------------------------------

        Parent: WFLY-490
    Issue Type: Sub-task  (was: Enhancement)

    
> Priviledge alignment for scoped resources
> -----------------------------------------
>
>                 Key: WFLY-2190
>                 URL: https://issues.jboss.org/browse/WFLY-2190
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> server-groups show different privildges for {{server-group=*}} and {{server-group=<specific instance>}}. when accessing these as a scoped role we use the <specific instance> to determine the operation priviledges. 
> Would it be possible that the operation permissions for {{server-group=<specific instance>:<add|remove>}} show the same permissions as {{server-group=*:<add|remove>}}? 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 19:23:02 2013
From: jira-events at lists.jboss.org (Brad Maxwell (JIRA))
Date: Tue, 1 Oct 2013 19:23:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2198) Remote Naming throws the same
 exception for different causes
In-Reply-To: <JIRA.12501957.1380669681415@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501957.1380669681415@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501957.1380669681415.9232.1380669782498@jira02.app.mwc.hst.phx2.redhat.com>

Brad Maxwell created WFLY-2198:
----------------------------------

             Summary: Remote Naming throws the same exception for different causes
                 Key: WFLY-2198
                 URL: https://issues.jboss.org/browse/WFLY-2198
             Project: WildFly
          Issue Type: Bug
          Components: Naming
            Reporter: Brad Maxwell
            Assignee: Brad Maxwell


A generic NamingException are thrown if all of the servers specified are unreachable as well as if the user/pass are invalid and a security exception is thrown up, they both are converted into a RuntimeException and a message listing the servers it was unable to call is reported.

We should be throwing a different exception in the cases we know the cause, such as connection timeout or authentication exception. 

If all the the servers specified are not not running:
--------------------------------------------------------------------------------------------
javax.naming.NamingException: Failed to connect to any server. Servers tried: [remote://localhost:4447]
  at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:213)

If one of the servers is running, but the client's username/password are incorrect
--------------------------------------------------------------------------------------------
javax.naming.NamingException: Failed to connect to any server. Servers tried: [remote://localhost:4447]
  at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:213)


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  1 19:29:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 1 Oct 2013 19:29:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2198) Remote Naming throws the same
 exception for different causes
In-Reply-To: <JIRA.12501957.1380669681000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501957.1380669681000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501957.1380669681000.9235.1380670142540@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2198:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1014414

    
> Remote Naming throws the same exception for different causes
> ------------------------------------------------------------
>
>                 Key: WFLY-2198
>                 URL: https://issues.jboss.org/browse/WFLY-2198
>             Project: WildFly
>          Issue Type: Bug
>          Components: Naming
>            Reporter: Brad Maxwell
>            Assignee: Brad Maxwell
>
> A generic NamingException are thrown if all of the servers specified are unreachable as well as if the user/pass are invalid and a security exception is thrown up, they both are converted into a RuntimeException and a message listing the servers it was unable to call is reported.
> We should be throwing a different exception in the cases we know the cause, such as connection timeout or authentication exception. 
> If all the the servers specified are not not running:
> --------------------------------------------------------------------------------------------
> javax.naming.NamingException: Failed to connect to any server. Servers tried: [remote://localhost:4447]
>   at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:213)
> If one of the servers is running, but the client's username/password are incorrect
> --------------------------------------------------------------------------------------------
> javax.naming.NamingException: Failed to connect to any server. Servers tried: [remote://localhost:4447]
>   at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:213)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  2 03:14:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Wed, 2 Oct 2013 03:14:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2157) JSF ViewExpiredException
	without cookies.
In-Reply-To: <JIRA.12501535.1380124956000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501535.1380124956000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501535.1380124956000.9553.1380698042872@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808785#comment-12808785 ] 

Stuart Douglas commented on WFLY-2157:
--------------------------------------

This is indeed an Undertow issue, I will fix it up. 
                
> JSF ViewExpiredException without cookies.
> -----------------------------------------
>
>                 Key: WFLY-2157
>                 URL: https://issues.jboss.org/browse/WFLY-2157
>             Project: WildFly
>          Issue Type: Bug
>          Components: JSF, Web (Undertow)
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Marek Schmidt
>            Assignee: Stuart Douglas
>         Attachments: weld-numberguess.war
>
>
> On a Firefox browser with cookies disabled, a simple CDI/JSF application (Weld Numberguess example) shows the following exception (same WAR works fine on EAP 6.1 with cookies disabled)
> {noformat}
> 14:17:27,508 ERROR [io.undertow.request] (default task-5) Servlet request failed HttpServerExchange{ POST /weld-numberguess/home.jsf}: javax.servlet.ServletException: viewId:/home.jsf - View /home.jsf could not be restored.
>         at javax.faces.webapp.FacesServlet.service(FacesServlet.java:659) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
>         at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
>         at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at org.wildfly.extension.undertow.security.SecurityContextCreationHandler.handleRequest(SecurityContextCreationHandler.java:54)
>         at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:207) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:194) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:72) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:128) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:628) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
>         at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> Caused by: javax.faces.application.ViewExpiredException: viewId:/home.jsf - View /home.jsf could not be restored.
>         at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:210) [jsf-impl-2.2.1-jbossorg-1.jar:]
>         at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.1-jbossorg-1.jar:]
>         at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:121) [jsf-impl-2.2.1-jbossorg-1.jar:]
>         at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) [jsf-impl-2.2.1-jbossorg-1.jar:]
>         at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
>         ... 29 more
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  2 03:14:03 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Wed, 2 Oct 2013 03:14:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2073) Uploading a file using JSF
 2.2 throws an exception
In-Reply-To: <JIRA.12500717.1379188731000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500717.1379188731000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500717.1379188731000.9555.1380698043102@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-2073.
----------------------------------

    Fix Version/s: 8.0.0.Beta1
       Resolution: Done

    
> Uploading a file using JSF 2.2 throws an exception
> --------------------------------------------------
>
>                 Key: WFLY-2073
>                 URL: https://issues.jboss.org/browse/WFLY-2073
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Alpha4
>         Environment: Ubuntu OS 64 bit, Java 7 (java version "1.7.0_40"), JSF version 2.2.1, JSF vender JBoss by Red Hat
>            Reporter: alexandre xypas
>            Assignee: Stuart Douglas
>              Labels: servlet, undertow
>             Fix For: 8.0.0.Beta1
>
>
> Using JSF 2.2, the following should work:
> <h:form enctype="multipart/form-data">
>       <h:inputFile value="#{bean.file}" required="true">
>            <f:ajax listener="#{bean.handleFileUploadAjax}" render="@form" />
>       </h:inputFile>
>       <h:messages />
>  </h:form>
> With the bean:
>         private Part file; // +GET/SET
> 	public void handleFileUploadAjax(AjaxBehaviorEvent event) {
> 	    System.out.println("file size: " + part.getSize());
> 	    System.out.println("file type: " + part.getContentType());
> 	    System.out.println("file info: " + part.getHeader("Content-Disposition"));
> 	}
> The problem remains without using Ajax.
> but throws the following exception when a file is uploaded:
> 22:46:04,333 WARNING [javax.enterprise.resource.webcontainer.jsf.lifecycle] (default task-3) UT000017: Form value is a file, use getFile() instead: java.lang.IllegalStateException: UT000017: Form value is a file, use getFile() instead
> 	at io.undertow.server.handlers.form.FormData$FormValueImpl.getValue(FormData.java:206) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.spec.HttpServletRequestImpl.getParameter(HttpServletRequestImpl.java:576) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at javax.servlet.ServletRequestWrapper.getParameter(ServletRequestWrapper.java:194) [jboss-servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
> 	at com.sun.faces.context.RequestParameterMap.containsKey(RequestParameterMap.java:99) [jsf-impl-2.2.1-jbossorg-1.jar:]
> 	at java.util.Collections$UnmodifiableMap.containsKey(Collections.java:1337) [rt.jar:1.7.0_40]
> 	at com.sun.faces.renderkit.html_basic.FileRenderer.decode(FileRenderer.java:85) [jsf-impl-2.2.1-jbossorg-1.jar:]
> 	at javax.faces.component.UIComponentBase.decode(UIComponentBase.java:831) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIInput.decode(UIInput.java:771) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1225) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIInput.processDecodes(UIInput.java:676) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIForm.processDecodes(UIForm.java:225) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1220) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1220) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIViewRoot.processDecodes(UIViewRoot.java:929) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at com.sun.faces.lifecycle.ApplyRequestValuesPhase.execute(ApplyRequestValuesPhase.java:78) [jsf-impl-2.2.1-jbossorg-1.jar:]
> 	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.1-jbossorg-1.jar:]
> 	at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) [jsf-impl-2.2.1-jbossorg-1.jar:]
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:208) [javamelody-core-1.46.0.jar:1.46.0]
> 	at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:181) [javamelody-core-1.46.0.jar:1.46.0]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at com.xypas.filter.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:28) [classes:]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at org.primefaces.webapp.filter.FileUploadFilter.doFilter(FileUploadFilter.java:70) [primefaces-4.0-SNAPSHOT.jar:4.0-SNAPSHOT]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at com.ocpsoft.pretty.PrettyFilter.doFilter(PrettyFilter.java:145) [prettyfaces-jsf2-3.3.3.jar:]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at org.wildfly.extension.undertow.security.SecurityContextCreationHandler.handleRequest(SecurityContextCreationHandler.java:54)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:207) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:194) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:72) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:128) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:628) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> 22:46:04,344 ERROR [io.undertow.request] (default task-3) Servlet request failed HttpServerExchange{ POST /doctor/doctorUpdates.xhtml}: javax.servlet.ServletException: UT000017: Form value is a file, use getFile() instead
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:659) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:208) [javamelody-core-1.46.0.jar:1.46.0]
> 	at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:181) [javamelody-core-1.46.0.jar:1.46.0]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at com.xypas.filter.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:28) [classes:]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at org.primefaces.webapp.filter.FileUploadFilter.doFilter(FileUploadFilter.java:70) [primefaces-4.0-SNAPSHOT.jar:4.0-SNAPSHOT]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at com.ocpsoft.pretty.PrettyFilter.doFilter(PrettyFilter.java:145) [prettyfaces-jsf2-3.3.3.jar:]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at org.wildfly.extension.undertow.security.SecurityContextCreationHandler.handleRequest(SecurityContextCreationHandler.java:54)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:207) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:194) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:72) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:128) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:628) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> Caused by: java.lang.IllegalStateException: UT000017: Form value is a file, use getFile() instead
> 	at io.undertow.server.handlers.form.FormData$FormValueImpl.getValue(FormData.java:206) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.spec.HttpServletRequestImpl.getParameter(HttpServletRequestImpl.java:576) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at javax.servlet.ServletRequestWrapper.getParameter(ServletRequestWrapper.java:194) [jboss-servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
> 	at com.sun.faces.context.RequestParameterMap.containsKey(RequestParameterMap.java:99) [jsf-impl-2.2.1-jbossorg-1.jar:]
> 	at java.util.Collections$UnmodifiableMap.containsKey(Collections.java:1337) [rt.jar:1.7.0_40]
> 	at com.sun.faces.renderkit.html_basic.FileRenderer.decode(FileRenderer.java:85) [jsf-impl-2.2.1-jbossorg-1.jar:]
> 	at javax.faces.component.UIComponentBase.decode(UIComponentBase.java:831) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIInput.decode(UIInput.java:771) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1225) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIInput.processDecodes(UIInput.java:676) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIForm.processDecodes(UIForm.java:225) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1220) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1220) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIViewRoot.processDecodes(UIViewRoot.java:929) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at com.sun.faces.lifecycle.ApplyRequestValuesPhase.execute(ApplyRequestValuesPhase.java:78) [jsf-impl-2.2.1-jbossorg-1.jar:]
> 	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.1-jbossorg-1.jar:]
> 	at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) [jsf-impl-2.2.1-jbossorg-1.jar:]
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	... 42 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  2 04:35:02 2013
From: jira-events at lists.jboss.org (David Hladky (JIRA))
Date: Wed, 2 Oct 2013 04:35:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2199) There is AS7 instead of
 Wildfly on Projects page
In-Reply-To: <JIRA.12501977.1380702880196@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501977.1380702880196@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501977.1380702880196.9678.1380702902857@jira02.app.mwc.hst.phx2.redhat.com>

David Hladky created WFLY-2199:
----------------------------------

             Summary: There is AS7 instead of Wildfly on Projects page
                 Key: WFLY-2199
                 URL: https://issues.jboss.org/browse/WFLY-2199
             Project: WildFly
          Issue Type: Bug
          Components: Web (JBoss Web)
            Reporter: David Hladky
            Assignee: Remy Maucherat


Hi, in order to fix ORG-1814 I need the Wildfly web pages author to fill project properties file and tell me his URL, so I can add it to the web page. 

More information (including example) can be found here: https://www.jboss.org/help/awestructguide (the last chapter).

Make sure it is a property file and not a link to a property file, that is in i-frame. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  2 04:41:02 2013
From: jira-events at lists.jboss.org (Ben Romberg (JIRA))
Date: Wed, 2 Oct 2013 04:41:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-209) Nested classes read from
 ClassMemberValue cannot be loaded
In-Reply-To: <JIRA.12501979.1380703145381@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501979.1380703145381@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501979.1380703145381.9710.1380703262931@jira02.app.mwc.hst.phx2.redhat.com>

Ben Romberg created JASSIST-209:
-----------------------------------

             Summary: Nested classes read from ClassMemberValue cannot be loaded
                 Key: JASSIST-209
                 URL: https://issues.jboss.org/browse/JASSIST-209
             Project: Javassist
          Issue Type: Bug
    Affects Versions: 3.18.0-GA
            Reporter: Ben Romberg
            Assignee: Shigeru Chiba


I'm trying to upgrade Javassist in my project from version 3.16.1 to 3.18.0. I'm using the ClassMemberValue to load the (String) class-name of an annotation value, in order to load the class with Javassist using ClassPool.get(...).

In 3.16.1, the returned class-name String for nested classes contained the $-sign, as in package.ParentClass$NestedClass, which didn't have any issues using the String with ClassPool.get(...).

In 3.18.0 however, the returned class-name String for nested classes changed to a pure dot-notation, as in package.ParentClass.NestedClass, which cannot be used with ClassPool.get(...) anymore, as Javassist tries to load the class-file from package/ParentClass/NestedClass.class instead of package/ParentClass$NestedClass.class.

I don't see any way to work around the issue without hacking into internal API (by inheriting from ClassMemberValue within my own package javassist.bytecode.annotation to gain access to the package private fields), as the class-name String is the only way to get the annotation value. As this is a generic class (and not always a nested class), I also cannot simply replace the last dot with a $-sign.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  2 04:51:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 2 Oct 2013 04:51:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBRULES-3699) Large memory allocation
 per request in drools-camel-server
In-Reply-To: <JIRA.12480200.1354270938000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12480200.1354270938000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12480200.1354270938000.9740.1380703863539@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBRULES-3699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808814#comment-12808814 ] 

RH Bugzilla Integration commented on JBRULES-3699:
--------------------------------------------------

Mario Fusco <mfusco at redhat.com> changed the Status of [bug 958387|https://bugzilla.redhat.com/show_bug.cgi?id=958387] from ASSIGNED to MODIFIED
                
> Large memory allocation per request in drools-camel-server
> ----------------------------------------------------------
>
>                 Key: JBRULES-3699
>                 URL: https://issues.jboss.org/browse/JBRULES-3699
>             Project: JBRULES
>          Issue Type: Quality Risk
>      Security Level: Public(Everyone can see) 
>          Components: drools-camel
>    Affects Versions: 5.4.0.Final
>            Reporter: Toshiya Kobayashi
>            Assignee: Mark Proctor
>         Attachments: JBoss_Benchmark_Request.xml, numbers.drl
>
>
> In drools-camel-server, memory allocation during request/response message handling is quite larger than actual request/response size.
> For example, with attached numbers.drl and JBoss_Benchmark_Request.xml, one SOAP request results in 45MB+ object allocation while the actual request size is 200KB and the response size is 650KB. They are short-lived objects so wouldn't be a memory leak but affect performance especially under high load.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  2 04:51:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 2 Oct 2013 04:51:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBRULES-3699) Large memory allocation
 per request in drools-camel-server
In-Reply-To: <JIRA.12480200.1354270938000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12480200.1354270938000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12480200.1354270938000.9744.1380703863711@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBRULES-3699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808815#comment-12808815 ] 

RH Bugzilla Integration commented on JBRULES-3699:
--------------------------------------------------

Mario Fusco <mfusco at redhat.com> made a comment on [bug 958387|https://bugzilla.redhat.com/show_bug.cgi?id=958387]

As evidenced by Toshiya the biggest part of this memory occupation is caused by the conversion of InputStreams to Strings. Unfortunately I don't think this is avoidable. Moreover there are many ways to perform this conversion, but as for example reported here:

http://www.journaldev.com/706/how-to-convert-inputstream-to-string-in-java

we are apparently already using the most memory efficient one.

I can't find a way a to improve this issue but any other suggestion is welcome.
                
> Large memory allocation per request in drools-camel-server
> ----------------------------------------------------------
>
>                 Key: JBRULES-3699
>                 URL: https://issues.jboss.org/browse/JBRULES-3699
>             Project: JBRULES
>          Issue Type: Quality Risk
>      Security Level: Public(Everyone can see) 
>          Components: drools-camel
>    Affects Versions: 5.4.0.Final
>            Reporter: Toshiya Kobayashi
>            Assignee: Mark Proctor
>         Attachments: JBoss_Benchmark_Request.xml, numbers.drl
>
>
> In drools-camel-server, memory allocation during request/response message handling is quite larger than actual request/response size.
> For example, with attached numbers.drl and JBoss_Benchmark_Request.xml, one SOAP request results in 45MB+ object allocation while the actual request size is 200KB and the response size is 650KB. They are short-lived objects so wouldn't be a memory leak but affect performance especially under high load.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  2 04:53:02 2013
From: jira-events at lists.jboss.org (Ben Romberg (JIRA))
Date: Wed, 2 Oct 2013 04:53:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-209) Nested classes read from
 ClassMemberValue cannot be loaded
In-Reply-To: <JIRA.12501979.1380703145000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501979.1380703145000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501979.1380703145000.9747.1380703982572@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JASSIST-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ben Romberg updated JASSIST-209:
--------------------------------

    Description: 
I'm trying to upgrade Javassist in my project from version 3.16.1 to 3.18.0. I'm using the ClassMemberValue to load the (String) class-name of an annotation value, in order to load the class with Javassist using ClassPool.get(...).

In 3.16.1, the returned class-name String for nested classes contained the $-sign, as in package.ParentClass$NestedClass, which didn't have any issues using the String with ClassPool.get(...).

In 3.18.0 however, the returned class-name String for nested classes changed to a pure dot-notation, as in package.ParentClass.NestedClass, which cannot be used with ClassPool.get(...) anymore, as Javassist tries to load the class-file from package/ParentClass/NestedClass.class instead of package/ParentClass$NestedClass.class.

I don't see any way to work around the issue without hacking into internal API, as the class-name String is the only way to get the annotation value. As this is a generic class (and not always a nested class), I also cannot simply replace the last dot with a $-sign.

  was:
I'm trying to upgrade Javassist in my project from version 3.16.1 to 3.18.0. I'm using the ClassMemberValue to load the (String) class-name of an annotation value, in order to load the class with Javassist using ClassPool.get(...).

In 3.16.1, the returned class-name String for nested classes contained the $-sign, as in package.ParentClass$NestedClass, which didn't have any issues using the String with ClassPool.get(...).

In 3.18.0 however, the returned class-name String for nested classes changed to a pure dot-notation, as in package.ParentClass.NestedClass, which cannot be used with ClassPool.get(...) anymore, as Javassist tries to load the class-file from package/ParentClass/NestedClass.class instead of package/ParentClass$NestedClass.class.

I don't see any way to work around the issue without hacking into internal API (by inheriting from ClassMemberValue within my own package javassist.bytecode.annotation to gain access to the package private fields), as the class-name String is the only way to get the annotation value. As this is a generic class (and not always a nested class), I also cannot simply replace the last dot with a $-sign.


    
> Nested classes read from ClassMemberValue cannot be loaded
> ----------------------------------------------------------
>
>                 Key: JASSIST-209
>                 URL: https://issues.jboss.org/browse/JASSIST-209
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.18.0-GA
>            Reporter: Ben Romberg
>            Assignee: Shigeru Chiba
>
> I'm trying to upgrade Javassist in my project from version 3.16.1 to 3.18.0. I'm using the ClassMemberValue to load the (String) class-name of an annotation value, in order to load the class with Javassist using ClassPool.get(...).
> In 3.16.1, the returned class-name String for nested classes contained the $-sign, as in package.ParentClass$NestedClass, which didn't have any issues using the String with ClassPool.get(...).
> In 3.18.0 however, the returned class-name String for nested classes changed to a pure dot-notation, as in package.ParentClass.NestedClass, which cannot be used with ClassPool.get(...) anymore, as Javassist tries to load the class-file from package/ParentClass/NestedClass.class instead of package/ParentClass$NestedClass.class.
> I don't see any way to work around the issue without hacking into internal API, as the class-name String is the only way to get the annotation value. As this is a generic class (and not always a nested class), I also cannot simply replace the last dot with a $-sign.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  2 04:53:02 2013
From: jira-events at lists.jboss.org (Ben Romberg (JIRA))
Date: Wed, 2 Oct 2013 04:53:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-209) Nested classes read from
 ClassMemberValue cannot be loaded
In-Reply-To: <JIRA.12501979.1380703145000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501979.1380703145000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501979.1380703145000.9749.1380703982649@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JASSIST-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808816#comment-12808816 ] 

Ben Romberg commented on JASSIST-209:
-------------------------------------

Workaround (hack):
{code}
package javassist.bytecode.annotation;

import javassist.bytecode.Descriptor;

public class ClassMemberValueReader {
	public static String readClassMemberValue(ClassMemberValue classMemberValue) {
		String v = classMemberValue.cp.getUtf8Info(classMemberValue.valueIndex);
		return Descriptor.toClassName(v);
	}
}
{code}
                
> Nested classes read from ClassMemberValue cannot be loaded
> ----------------------------------------------------------
>
>                 Key: JASSIST-209
>                 URL: https://issues.jboss.org/browse/JASSIST-209
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.18.0-GA
>            Reporter: Ben Romberg
>            Assignee: Shigeru Chiba
>
> I'm trying to upgrade Javassist in my project from version 3.16.1 to 3.18.0. I'm using the ClassMemberValue to load the (String) class-name of an annotation value, in order to load the class with Javassist using ClassPool.get(...).
> In 3.16.1, the returned class-name String for nested classes contained the $-sign, as in package.ParentClass$NestedClass, which didn't have any issues using the String with ClassPool.get(...).
> In 3.18.0 however, the returned class-name String for nested classes changed to a pure dot-notation, as in package.ParentClass.NestedClass, which cannot be used with ClassPool.get(...) anymore, as Javassist tries to load the class-file from package/ParentClass/NestedClass.class instead of package/ParentClass$NestedClass.class.
> I don't see any way to work around the issue without hacking into internal API, as the class-name String is the only way to get the annotation value. As this is a generic class (and not always a nested class), I also cannot simply replace the last dot with a $-sign.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  2 05:01:02 2013
From: jira-events at lists.jboss.org (Juergen Zimmermann (JIRA))
Date: Wed, 2 Oct 2013 05:01:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2118) PersistenceException breaks
 default error page
In-Reply-To: <JIRA.12501118.1379679983000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501118.1379679983000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501118.1379679983000.9767.1380704462943@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808820#comment-12808820 ] 

Juergen Zimmermann commented on WFLY-2118:
------------------------------------------

When I change stack-trace-on-error="local-only" to stack-trace-on-error="none" ("disabled" caused an XML parse error), then I get the default error page as expected.
                
> PersistenceException breaks default error page
> ----------------------------------------------
>
>                 Key: WFLY-2118
>                 URL: https://issues.jboss.org/browse/WFLY-2118
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>            Reporter: Juergen Zimmermann
>            Assignee: Stuart Douglas
>         Attachments: mojarra-2.1.zip, testcase-WFLY-2118.zip
>
>
> I'm using the latest WildFly snapshot with Undertow 1.0.0.Beta13. When I get a PersistenceException caused by Hibernate due to an invalid entity (according to Bean Validation), then the webbrowser doesn't get the default error page. The stacktrace is shown below. I'll attach a testcase.
> {code}
> [com.arjuna.ats.arjuna] ARJUNA012125: TwoPhaseCoordinator.beforeCompletion - failed for SynchronizationImple< 0:ffffc0a8b801:4240ead4:523ac52c:15, org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization at 20cf7473 >: javax.persistence.PersistenceException: error during managed flush
> 	at org.hibernate.jpa.spi.AbstractEntityManagerImpl$CallbackExceptionMapperImpl.mapManagedFlushFailure(AbstractEntityManagerImpl.java:1785) [hibernate-entitymanager-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:118) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:53) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:273) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:93) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1170) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
> 	at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.endTransaction(TransactionalInterceptorBase.java:131) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.invokeInOurTx(TransactionalInterceptorBase.java:77) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired.intercept(TransactionalInterceptorRequired.java:52) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_40]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_40]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_40]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_40]
> 	at org.jboss.weld.interceptor.proxy.SimpleMethodInvocation.invoke(SimpleMethodInvocation.java:30) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNext(AbstractInterceptionChain.java:90) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNextInterceptor(AbstractInterceptionChain.java:75) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:48) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:41) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:53) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at testcase.web.CustomerModel$Proxy$_$$_WeldSubclass.create(Unknown Source) [classes:]
> 	at testcase.web.CustomerModel$Proxy$_$$_WeldClientProxy.create(Unknown Source) [classes:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_40]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_40]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_40]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_40]
> 	at javax.el.ELUtil.invokeMethod(ELUtil.java:326) [javax.el-3.0-b07.jar:3.0-b07]
> 	at javax.el.BeanELResolver.invoke(BeanELResolver.java:536) [javax.el-3.0-b07.jar:3.0-b07]
> 	at javax.el.CompositeELResolver.invoke(CompositeELResolver.java:256) [javax.el-3.0-b07.jar:3.0-b07]
> 	at com.sun.el.parser.AstValue.invoke(AstValue.java:269) [javax.el-3.0-b07.jar:3.0-b07]
> 	at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:304) [javax.el-3.0-b07.jar:3.0-b07]
> 	at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105) [jsf-impl-2.1.26.jar:2.1.26]
> 	at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:87) [jsf-api-2.1.26.jar:2.1]
> 	at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:101) [jsf-impl-2.1.26.jar:2.1.26]
> 	at javax.faces.component.UICommand.broadcast(UICommand.java:315) [jsf-api-2.1.26.jar:2.1]
> 	at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:786) [jsf-api-2.1.26.jar:2.1]
> 	at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1251) [jsf-api-2.1.26.jar:2.1]
> 	at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) [jsf-impl-2.1.26.jar:2.1.26]
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593) [jsf-api-2.1.26.jar:2.1]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:59) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:209) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:196) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:130) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:614) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> Caused by: javax.validation.ConstraintViolationException: Validation failed for classes [testcase.domain.Customer] during persist time for groups [javax.validation.groups.Default, ]
> List of constraint violations:[
> 	ConstraintViolationImpl{interpolatedMessage='Min length = 2, max length = 32', propertyPath=name, rootBeanClass=class testcase.domain.Customer, messageTemplate='Min length = {min}, max length = {max}'}
> 	ConstraintViolationImpl{interpolatedMessage='Zip code is 5 digits', propertyPath=zip, rootBeanClass=class testcase.domain.Customer, messageTemplate='Zip code is 5 digits'}
> 	ConstraintViolationImpl{interpolatedMessage='A name must have one capital letter, followed by small letters', propertyPath=name, rootBeanClass=class testcase.domain.Customer, messageTemplate='A name must have one capital letter, followed by small letters'}
> ]
> 	at org.hibernate.cfg.beanvalidation.BeanValidationEventListener.validate(BeanValidationEventListener.java:159) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.cfg.beanvalidation.BeanValidationEventListener.onPreInsert(BeanValidationEventListener.java:94) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.action.internal.EntityInsertAction.preInsert(EntityInsertAction.java:196) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.action.internal.EntityInsertAction.execute(EntityInsertAction.java:96) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:377) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:369) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:286) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:340) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:52) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1235) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:405) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:113) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	... 68 more
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  2 05:04:02 2013
From: jira-events at lists.jboss.org (Juergen Zimmermann (JIRA))
Date: Wed, 2 Oct 2013 05:04:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2200) NoSuchElementException after
 upgrade from Beta13 to Beta14
In-Reply-To: <JIRA.12501981.1380704605388@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501981.1380704605388@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501981.1380704605388.9772.1380704642873@jira02.app.mwc.hst.phx2.redhat.com>

Juergen Zimmermann created WFLY-2200:
----------------------------------------

             Summary: NoSuchElementException after upgrade from Beta13 to Beta14
                 Key: WFLY-2200
                 URL: https://issues.jboss.org/browse/WFLY-2200
             Project: WildFly
          Issue Type: Bug
          Components: Web (Undertow)
            Reporter: Juergen Zimmermann
            Assignee: Stuart Douglas


I just switched to a newer WildFly snapshot having Undertow 1.0.0.Beta14. But I'm getting the following stacktrace caused by HttpServletRequestImpl.getParameterNames(). This error didn't happen with 1.0.0.Beta13.

{code}
SEVERE [javax.enterprise.resource.webcontainer.jsf.application] (default task-45) Error Rendering View[/index.xhtml]: java.util.NoSuchElementException
	at java.util.HashMap$HashIterator.nextEntry(HashMap.java:929) [rt.jar:1.7.0_40]
	at java.util.HashMap$KeyIterator.next(HashMap.java:960) [rt.jar:1.7.0_40]
	at io.undertow.servlet.spec.HttpServletRequestImpl.getParameterNames(HttpServletRequestImpl.java:605) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
	at com.sun.faces.context.RequestParameterMap.getEntryIterator(RequestParameterMap.java:126) [jsf-impl-2.1.26.jar:2.1.26]
	at com.sun.faces.context.BaseContextMap$EntrySet.iterator(BaseContextMap.java:166) [jsf-impl-2.1.26.jar:2.1.26]
	at com.sun.faces.context.BaseContextMap$BaseSet.size(BaseContextMap.java:154) [jsf-impl-2.1.26.jar:2.1.26]
	at java.util.Collections$UnmodifiableCollection.size(Collections.java:1055) [rt.jar:1.7.0_40]
	at java.util.AbstractMap.size(AbstractMap.java:84) [rt.jar:1.7.0_40]
	at java.util.AbstractMap.isEmpty(AbstractMap.java:93) [rt.jar:1.7.0_40]
	at java.util.Collections$UnmodifiableMap.isEmpty(Collections.java:1336) [rt.jar:1.7.0_40]
	at com.sun.faces.facelets.util.DevTools.writeVariables(DevTools.java:330) [jsf-impl-2.1.26.jar:2.1.26]
	at com.sun.faces.facelets.util.DevTools.writeVariables(DevTools.java:199) [jsf-impl-2.1.26.jar:2.1.26]
	at com.sun.faces.facelets.util.DevTools.debugHtml(DevTools.java:186) [jsf-impl-2.1.26.jar:2.1.26]
	at com.sun.faces.facelets.tag.ui.UIDebug.writeDebugOutput(UIDebug.java:140) [jsf-impl-2.1.26.jar:2.1.26]
	at com.sun.faces.facelets.tag.ui.UIDebug.encodeBegin(UIDebug.java:122) [jsf-impl-2.1.26.jar:2.1.26]
	at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1817) [jsf-api-2.1.26.jar:2.1]
	at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1822) [jsf-api-2.1.26.jar:2.1]
	at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1822) [jsf-api-2.1.26.jar:2.1]
	at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:447) [jsf-impl-2.1.26.jar:2.1.26]
	at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:125) [jsf-impl-2.1.26.jar:2.1.26]
	at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:286) [jsf-api-2.1.26.jar:2.1]
	at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:286) [jsf-api-2.1.26.jar:2.1]
	at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:286) [jsf-api-2.1.26.jar:2.1]
	at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120) [jsf-impl-2.1.26.jar:2.1.26]
	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.1.26.jar:2.1.26]
	at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139) [jsf-impl-2.1.26.jar:2.1.26]
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594) [jsf-api-2.1.26.jar:2.1]
	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:93) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:55) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:209) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:196) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:130) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:614) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
{code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  2 05:24:02 2013
From: jira-events at lists.jboss.org (Gytis Trikleris (JIRA))
Date: Wed, 2 Oct 2013 05:24:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2201) Server-side XTS handlers not
 added if @WebService#portName is missing
In-Reply-To: <JIRA.12501360.1380015769000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501360.1380015769000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501360.1380015769000.9809.1380705842897@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gytis Trikleris moved JBTM-1940 to WFLY-2201:
---------------------------------------------

          Project: WildFly  (was: JBoss Transaction Manager)
              Key: WFLY-2201  (was: JBTM-1940)
      Component/s: XTS
                       (was: XTS)
                       (was: TXFramework)
         Security:     (was: Public)
    Fix Version/s: 8.0.0.Beta1
                       (was: 5.0.0.Final)

    
> Server-side XTS handlers not added if @WebService#portName is missing
> ---------------------------------------------------------------------
>
>                 Key: WFLY-2201
>                 URL: https://issues.jboss.org/browse/WFLY-2201
>             Project: WildFly
>          Issue Type: Bug
>          Components: XTS
>            Reporter: Paul Robinson
>            Assignee: Gytis Trikleris
>            Priority: Minor
>             Fix For: 8.0.0.Beta1
>
>
> To reproduce, remove portName or targetNameSpace attributes from org.jboss.narayana.compensations.functional.distributed.DistributedTest in the TXFramework suite. You will see that the test fails with:
> {code}
> "MustUnderstand headers: [{http://docs.oasis-open.org/ws-tx/wscoor/2006/06}CoordinationContext] are not understood"
> {code}
> The problem is that the Endpoint is not recognised, by the XTS subsytem, as having a valid @WebService annotation if these attributes are missing. In reality they are optional and an application should be allowed to leave them off. However, these attribute values are used by the XTS subsytem, so we would need to find a way of using the defaults if they are missing from the annotation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  2 05:33:02 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 2 Oct 2013 05:33:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2200) NoSuchElementException after
 upgrade from Beta13 to Beta14
In-Reply-To: <JIRA.12501981.1380704605000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501981.1380704605000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501981.1380704605000.9819.1380706382745@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-2200:
------------------------------

    Affects Version/s: 8.0.0.Beta1

    
> NoSuchElementException after upgrade from Beta13 to Beta14
> ----------------------------------------------------------
>
>                 Key: WFLY-2200
>                 URL: https://issues.jboss.org/browse/WFLY-2200
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Juergen Zimmermann
>            Assignee: Stuart Douglas
>
> I just switched to a newer WildFly snapshot having Undertow 1.0.0.Beta14. But I'm getting the following stacktrace caused by HttpServletRequestImpl.getParameterNames(). This error didn't happen with 1.0.0.Beta13.
> {code}
> SEVERE [javax.enterprise.resource.webcontainer.jsf.application] (default task-45) Error Rendering View[/index.xhtml]: java.util.NoSuchElementException
> 	at java.util.HashMap$HashIterator.nextEntry(HashMap.java:929) [rt.jar:1.7.0_40]
> 	at java.util.HashMap$KeyIterator.next(HashMap.java:960) [rt.jar:1.7.0_40]
> 	at io.undertow.servlet.spec.HttpServletRequestImpl.getParameterNames(HttpServletRequestImpl.java:605) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at com.sun.faces.context.RequestParameterMap.getEntryIterator(RequestParameterMap.java:126) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.context.BaseContextMap$EntrySet.iterator(BaseContextMap.java:166) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.context.BaseContextMap$BaseSet.size(BaseContextMap.java:154) [jsf-impl-2.1.26.jar:2.1.26]
> 	at java.util.Collections$UnmodifiableCollection.size(Collections.java:1055) [rt.jar:1.7.0_40]
> 	at java.util.AbstractMap.size(AbstractMap.java:84) [rt.jar:1.7.0_40]
> 	at java.util.AbstractMap.isEmpty(AbstractMap.java:93) [rt.jar:1.7.0_40]
> 	at java.util.Collections$UnmodifiableMap.isEmpty(Collections.java:1336) [rt.jar:1.7.0_40]
> 	at com.sun.faces.facelets.util.DevTools.writeVariables(DevTools.java:330) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.facelets.util.DevTools.writeVariables(DevTools.java:199) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.facelets.util.DevTools.debugHtml(DevTools.java:186) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.facelets.tag.ui.UIDebug.writeDebugOutput(UIDebug.java:140) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.facelets.tag.ui.UIDebug.encodeBegin(UIDebug.java:122) [jsf-impl-2.1.26.jar:2.1.26]
> 	at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1817) [jsf-api-2.1.26.jar:2.1]
> 	at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1822) [jsf-api-2.1.26.jar:2.1]
> 	at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1822) [jsf-api-2.1.26.jar:2.1]
> 	at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:447) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:125) [jsf-impl-2.1.26.jar:2.1.26]
> 	at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:286) [jsf-api-2.1.26.jar:2.1]
> 	at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:286) [jsf-api-2.1.26.jar:2.1]
> 	at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:286) [jsf-api-2.1.26.jar:2.1]
> 	at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139) [jsf-impl-2.1.26.jar:2.1.26]
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594) [jsf-api-2.1.26.jar:2.1]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:93) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:55) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:209) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:196) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:130) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:614) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  2 05:35:02 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 2 Oct 2013 05:35:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2200) NoSuchElementException after
 upgrade from Beta13 to Beta14
In-Reply-To: <JIRA.12501981.1380704605000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501981.1380704605000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501981.1380704605000.9823.1380706502902@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-2200:
------------------------------

    Fix Version/s: 8.0.0.Beta1

    
> NoSuchElementException after upgrade from Beta13 to Beta14
> ----------------------------------------------------------
>
>                 Key: WFLY-2200
>                 URL: https://issues.jboss.org/browse/WFLY-2200
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Juergen Zimmermann
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Beta1
>
>
> I just switched to a newer WildFly snapshot having Undertow 1.0.0.Beta14. But I'm getting the following stacktrace caused by HttpServletRequestImpl.getParameterNames(). This error didn't happen with 1.0.0.Beta13.
> {code}
> SEVERE [javax.enterprise.resource.webcontainer.jsf.application] (default task-45) Error Rendering View[/index.xhtml]: java.util.NoSuchElementException
> 	at java.util.HashMap$HashIterator.nextEntry(HashMap.java:929) [rt.jar:1.7.0_40]
> 	at java.util.HashMap$KeyIterator.next(HashMap.java:960) [rt.jar:1.7.0_40]
> 	at io.undertow.servlet.spec.HttpServletRequestImpl.getParameterNames(HttpServletRequestImpl.java:605) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at com.sun.faces.context.RequestParameterMap.getEntryIterator(RequestParameterMap.java:126) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.context.BaseContextMap$EntrySet.iterator(BaseContextMap.java:166) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.context.BaseContextMap$BaseSet.size(BaseContextMap.java:154) [jsf-impl-2.1.26.jar:2.1.26]
> 	at java.util.Collections$UnmodifiableCollection.size(Collections.java:1055) [rt.jar:1.7.0_40]
> 	at java.util.AbstractMap.size(AbstractMap.java:84) [rt.jar:1.7.0_40]
> 	at java.util.AbstractMap.isEmpty(AbstractMap.java:93) [rt.jar:1.7.0_40]
> 	at java.util.Collections$UnmodifiableMap.isEmpty(Collections.java:1336) [rt.jar:1.7.0_40]
> 	at com.sun.faces.facelets.util.DevTools.writeVariables(DevTools.java:330) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.facelets.util.DevTools.writeVariables(DevTools.java:199) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.facelets.util.DevTools.debugHtml(DevTools.java:186) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.facelets.tag.ui.UIDebug.writeDebugOutput(UIDebug.java:140) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.facelets.tag.ui.UIDebug.encodeBegin(UIDebug.java:122) [jsf-impl-2.1.26.jar:2.1.26]
> 	at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1817) [jsf-api-2.1.26.jar:2.1]
> 	at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1822) [jsf-api-2.1.26.jar:2.1]
> 	at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1822) [jsf-api-2.1.26.jar:2.1]
> 	at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:447) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:125) [jsf-impl-2.1.26.jar:2.1.26]
> 	at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:286) [jsf-api-2.1.26.jar:2.1]
> 	at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:286) [jsf-api-2.1.26.jar:2.1]
> 	at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:286) [jsf-api-2.1.26.jar:2.1]
> 	at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139) [jsf-impl-2.1.26.jar:2.1.26]
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594) [jsf-api-2.1.26.jar:2.1]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:93) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:55) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:209) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:196) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:130) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:614) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  2 05:57:02 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 2 Oct 2013 05:57:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1452) Undertow subsystem does not
 provide all model description properties
In-Reply-To: <JIRA.12493588.1370386850000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493588.1370386850000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493588.1370386850000.9847.1380707822930@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-1452:
------------------------------

    Fix Version/s: 8.0.0.Beta1
                       (was: 8.0.0.Final)

    
> Undertow subsystem does not provide all model description properties
> --------------------------------------------------------------------
>
>                 Key: WFLY-1452
>                 URL: https://issues.jboss.org/browse/WFLY-1452
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>            Reporter: Stuart Douglas
>             Fix For: 8.0.0.Beta1
>
>
> These have been disabled while the model is still in a state of flux. They must be added before the final release. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  2 05:57:03 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 2 Oct 2013 05:57:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1452) Undertow subsystem does not
 provide all model description properties
In-Reply-To: <JIRA.12493588.1370386850000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493588.1370386850000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493588.1370386850000.9850.1380707823065@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar resolved WFLY-1452.
-------------------------------

      Assignee: Tomaz Cerar
    Resolution: Done

    
> Undertow subsystem does not provide all model description properties
> --------------------------------------------------------------------
>
>                 Key: WFLY-1452
>                 URL: https://issues.jboss.org/browse/WFLY-1452
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>            Reporter: Stuart Douglas
>            Assignee: Tomaz Cerar
>             Fix For: 8.0.0.Beta1
>
>
> These have been disabled while the model is still in a state of flux. They must be added before the final release. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  2 06:14:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 2 Oct 2013 06:14:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2199) There is AS7 instead of
 Wildfly on Projects page
In-Reply-To: <JIRA.12501977.1380702880000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501977.1380702880000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501977.1380702880000.9874.1380708842766@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2199:
-----------------------------------

       Assignee: Jason Greene  (was: Remy Maucherat)
    Component/s:     (was: Web (JBoss Web))

    
> There is AS7 instead of Wildfly on Projects page
> ------------------------------------------------
>
>                 Key: WFLY-2199
>                 URL: https://issues.jboss.org/browse/WFLY-2199
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: David Hladky
>            Assignee: Jason Greene
>
> Hi, in order to fix ORG-1814 I need the Wildfly web pages author to fill project properties file and tell me his URL, so I can add it to the web page. 
> More information (including example) can be found here: https://www.jboss.org/help/awestructguide (the last chapter).
> Make sure it is a property file and not a link to a property file, that is in i-frame. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  2 06:56:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Wed, 2 Oct 2013 06:56:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2118) PersistenceException breaks
 default error page
In-Reply-To: <JIRA.12501118.1379679983000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501118.1379679983000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501118.1379679983000.9989.1380711362592@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808849#comment-12808849 ] 

Stuart Douglas commented on WFLY-2118:
--------------------------------------

I wonder if we should change this behaviour? The intention was to make development easier, as you can see stack traces if you are working on localhost (and there are no proxy headers), but it could be confusing as it overrides the default error page. 
                
> PersistenceException breaks default error page
> ----------------------------------------------
>
>                 Key: WFLY-2118
>                 URL: https://issues.jboss.org/browse/WFLY-2118
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>            Reporter: Juergen Zimmermann
>            Assignee: Stuart Douglas
>         Attachments: mojarra-2.1.zip, testcase-WFLY-2118.zip
>
>
> I'm using the latest WildFly snapshot with Undertow 1.0.0.Beta13. When I get a PersistenceException caused by Hibernate due to an invalid entity (according to Bean Validation), then the webbrowser doesn't get the default error page. The stacktrace is shown below. I'll attach a testcase.
> {code}
> [com.arjuna.ats.arjuna] ARJUNA012125: TwoPhaseCoordinator.beforeCompletion - failed for SynchronizationImple< 0:ffffc0a8b801:4240ead4:523ac52c:15, org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization at 20cf7473 >: javax.persistence.PersistenceException: error during managed flush
> 	at org.hibernate.jpa.spi.AbstractEntityManagerImpl$CallbackExceptionMapperImpl.mapManagedFlushFailure(AbstractEntityManagerImpl.java:1785) [hibernate-entitymanager-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:118) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:53) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:273) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:93) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1170) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
> 	at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.endTransaction(TransactionalInterceptorBase.java:131) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.invokeInOurTx(TransactionalInterceptorBase.java:77) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired.intercept(TransactionalInterceptorRequired.java:52) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_40]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_40]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_40]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_40]
> 	at org.jboss.weld.interceptor.proxy.SimpleMethodInvocation.invoke(SimpleMethodInvocation.java:30) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNext(AbstractInterceptionChain.java:90) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNextInterceptor(AbstractInterceptionChain.java:75) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:48) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:41) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:53) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at testcase.web.CustomerModel$Proxy$_$$_WeldSubclass.create(Unknown Source) [classes:]
> 	at testcase.web.CustomerModel$Proxy$_$$_WeldClientProxy.create(Unknown Source) [classes:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_40]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_40]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_40]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_40]
> 	at javax.el.ELUtil.invokeMethod(ELUtil.java:326) [javax.el-3.0-b07.jar:3.0-b07]
> 	at javax.el.BeanELResolver.invoke(BeanELResolver.java:536) [javax.el-3.0-b07.jar:3.0-b07]
> 	at javax.el.CompositeELResolver.invoke(CompositeELResolver.java:256) [javax.el-3.0-b07.jar:3.0-b07]
> 	at com.sun.el.parser.AstValue.invoke(AstValue.java:269) [javax.el-3.0-b07.jar:3.0-b07]
> 	at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:304) [javax.el-3.0-b07.jar:3.0-b07]
> 	at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105) [jsf-impl-2.1.26.jar:2.1.26]
> 	at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:87) [jsf-api-2.1.26.jar:2.1]
> 	at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:101) [jsf-impl-2.1.26.jar:2.1.26]
> 	at javax.faces.component.UICommand.broadcast(UICommand.java:315) [jsf-api-2.1.26.jar:2.1]
> 	at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:786) [jsf-api-2.1.26.jar:2.1]
> 	at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1251) [jsf-api-2.1.26.jar:2.1]
> 	at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) [jsf-impl-2.1.26.jar:2.1.26]
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593) [jsf-api-2.1.26.jar:2.1]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:59) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:209) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:196) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:130) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:614) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> Caused by: javax.validation.ConstraintViolationException: Validation failed for classes [testcase.domain.Customer] during persist time for groups [javax.validation.groups.Default, ]
> List of constraint violations:[
> 	ConstraintViolationImpl{interpolatedMessage='Min length = 2, max length = 32', propertyPath=name, rootBeanClass=class testcase.domain.Customer, messageTemplate='Min length = {min}, max length = {max}'}
> 	ConstraintViolationImpl{interpolatedMessage='Zip code is 5 digits', propertyPath=zip, rootBeanClass=class testcase.domain.Customer, messageTemplate='Zip code is 5 digits'}
> 	ConstraintViolationImpl{interpolatedMessage='A name must have one capital letter, followed by small letters', propertyPath=name, rootBeanClass=class testcase.domain.Customer, messageTemplate='A name must have one capital letter, followed by small letters'}
> ]
> 	at org.hibernate.cfg.beanvalidation.BeanValidationEventListener.validate(BeanValidationEventListener.java:159) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.cfg.beanvalidation.BeanValidationEventListener.onPreInsert(BeanValidationEventListener.java:94) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.action.internal.EntityInsertAction.preInsert(EntityInsertAction.java:196) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.action.internal.EntityInsertAction.execute(EntityInsertAction.java:96) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:377) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:369) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:286) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:340) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:52) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1235) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:405) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:113) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	... 68 more
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  2 08:14:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Wed, 2 Oct 2013 08:14:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2202) Update to HAL 2.0.2.Final
In-Reply-To: <JIRA.12501998.1380715953282@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501998.1380715953282@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501998.1380715953282.10154.1380716043086@jira02.app.mwc.hst.phx2.redhat.com>

Heiko Braun created WFLY-2202:
---------------------------------

             Summary: Update to HAL 2.0.2.Final
                 Key: WFLY-2202
                 URL: https://issues.jboss.org/browse/WFLY-2202
             Project: WildFly
          Issue Type: Task
          Components: Web Console
            Reporter: Heiko Braun
            Assignee: Heiko Braun
             Fix For: 8.0.0.Beta1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  2 08:29:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 2 Oct 2013 08:29:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1710) Messages get too large due to
 big headers (in large clusters)
In-Reply-To: <JIRA.12501895.1380613041000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501895.1380613041000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501895.1380613041000.10181.1380716942784@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808551#comment-12808551 ] 

Bela Ban edited comment on JGRP-1710 at 10/2/13 8:27 AM:
---------------------------------------------------------

As discussed on JGRP-1507: FRAG\{2\} cannot be moved over the transport as retransmission of large messages with 1 fragment missing would cause retransmission of the entire message (all fragments).

Therefore, the current strategy is to move large data from the header into the message's buffer and - if needed - add a *second* FRAG\{2\} directly over the transport. This second fragmentation protocol would typically not have to do any work, as fragmentation is done by the first fragmentation protocol. The only case where work would need to be done is when large data are added by a protocol, e.g. view and digest by {{INSTALL_MERGE_VIEW in GMS}}.

The advantage of moving large data into the body of a message is that FRAG2.down() can do a cheap {{Message.getLength()}}, compared to a more costly {{Message.size()}} by {{FRAG.down()}}.
                
      was (Author: belaban):
    As discussed on JGRP-1507: FRAG\{2\} cannot be moved over the transport as retransmission of large messages with 1 fragment missing would cause retransmission of the entire message (all fragments).

Therefore, the current strategy is to move large data from the header into the message's buffer and - if needed - add a second FRAG\{2\} directly over the transport. This second fragmentation protocol would typically not have to do any work, as fragmentation is done by the first fragmentation protocol. The only case where work would need to be done is when large data are added by a protocol, e.g. view and digest by {{INSTALL_MERGE_VIEW in GMS}}.

The advantage of moving large data into the body of a message is that FRAG2.down() can do a cheap {{Message.getLength()}}, compared to a more costly {{Message.size()}} by {{FRAG.down(){{.
                  
> Messages get too large due to big headers (in large clusters)
> -------------------------------------------------------------
>
>                 Key: JGRP-1710
>                 URL: https://issues.jboss.org/browse/JGRP-1710
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> In some cases, messages get bigger than the max bundling size because of large headers:
> {panel}
> ERROR 17:33:08,096 | Timer-5,c0,172.29.189.9-svc9-ZM26S32728-59135 | [TP.java:1335] | (org) | 172.29.189.9-svc9-ZM26S32728-59135: failed sending message to 172.29.190.181-svc2-00832091-31665 (70850 bytes): java.lang.Exception: message size (70850) is greater than max bundling size (64000). Set the fragmentation/bundle size in FRAG and TP correctly, headers: GMS: GmsHeader[INSTALL_MERGE_VIEW]: view=MergeView::[172.29.190.174-svc6-00832251-874|27] (1479) ...
> {panel}
> In the case of INSTALL_MERGE_VIEW, we send the full view (*not* the DeltaView) and the digest in the header. With 1479 members (as shown the the example above), this increases the message size beyond the max bundling size.
> Possible SOLUTION
> * Place the header fields in the message's buffer instead
> * Move FRAG2 *under* GMS
> ** Investigate impact on flow control etc

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  2 09:37:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 2 Oct 2013 09:37:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1710) Messages get too large due to
 big headers (in large clusters)
In-Reply-To: <JIRA.12501895.1380613041000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501895.1380613041000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501895.1380613041000.10389.1380721022719@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1710.
----------------------------

    Resolution: Done

    
> Messages get too large due to big headers (in large clusters)
> -------------------------------------------------------------
>
>                 Key: JGRP-1710
>                 URL: https://issues.jboss.org/browse/JGRP-1710
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> In some cases, messages get bigger than the max bundling size because of large headers:
> {panel}
> ERROR 17:33:08,096 | Timer-5,c0,172.29.189.9-svc9-ZM26S32728-59135 | [TP.java:1335] | (org) | 172.29.189.9-svc9-ZM26S32728-59135: failed sending message to 172.29.190.181-svc2-00832091-31665 (70850 bytes): java.lang.Exception: message size (70850) is greater than max bundling size (64000). Set the fragmentation/bundle size in FRAG and TP correctly, headers: GMS: GmsHeader[INSTALL_MERGE_VIEW]: view=MergeView::[172.29.190.174-svc6-00832251-874|27] (1479) ...
> {panel}
> In the case of INSTALL_MERGE_VIEW, we send the full view (*not* the DeltaView) and the digest in the header. With 1479 members (as shown the the example above), this increases the message size beyond the max bundling size.
> Possible SOLUTION
> * Place the header fields in the message's buffer instead
> * Move FRAG2 *under* GMS
> ** Investigate impact on flow control etc

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  2 10:19:02 2013
From: jira-events at lists.jboss.org (Nick Howes (JIRA))
Date: Wed, 2 Oct 2013 10:19:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2203) Error deploying multiple
	*-ds.xml files
In-Reply-To: <JIRA.12502011.1380723512118@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502011.1380723512118@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502011.1380723512118.10538.1380723542608@jira02.app.mwc.hst.phx2.redhat.com>

Nick Howes created WFLY-2203:
--------------------------------

             Summary: Error deploying multiple *-ds.xml files
                 Key: WFLY-2203
                 URL: https://issues.jboss.org/browse/WFLY-2203
             Project: WildFly
          Issue Type: Bug
    Affects Versions: 8.0.0.Beta1
            Reporter: Nick Howes


Our individual *-ds.xml datasources were all deploying fine in Alpha4 but in the Beta1 nightlies this error appears on startup:

{noformat}
15:07:52,111 ERROR [org.jboss.msc.service] (MSC service thread 1-4) MSC000002: Invocation of listener "org.jboss.as.connector.subsystems.datasources.D
ataSourceStatisticsListener at 7d18ac99" failed: java.lang.IllegalArgumentException: JBAS014742: A node is already registered at '(deployment => *)(subsy
stem => datasources)(data-source => *)(statistics => jdbc)'
        at org.jboss.as.controller.registry.NodeSubregistry.register(NodeSubregistry.java:86) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1
-SNAPSHOT]
        at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:149) [wildfly-controller-8
.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
        at org.jboss.as.controller.registry.AbstractResourceRegistration.registerSubModel(AbstractResourceRegistration.java:90) [wildfly-controller-8.
0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
        at org.jboss.as.connector.subsystems.datasources.DataSourceStatisticsListener.transition(DataSourceStatisticsListener.java:72) [wildfly-connec
tor-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
        at org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1533) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
{noformat}

Our datasource files look like this. I haven't tried putting all the datasource elements into one file.

{code}
<?xml version="1.0" encoding="UTF-8"?>
<datasources>
  <datasource jndi-name="java:/AlphaDS" enabled="true" use-java-context="true" pool-name="AlphaDS">
    <connection-url>jdbc:oracle:thin://@db-host:1666/dev-db</connection-url> 
    <driver>oracle</driver>
    <security>
      <user-name>XXX</user-name>
      <password>YYY</password>
    </security>
    <connection-property name="defaultNChar">true</connection-property>
  </datasource>
</datasources>
{code}

{code}
<?xml version="1.0" encoding="UTF-8"?>
<datasources>
  <datasource jndi-name="java:/BetaDS" enabled="true" use-java-context="true" pool-name="BetaDS">
    <connection-url>jdbc:oracle:thin://@db-host:1666/dev-db</connection-url> 
    <driver>oracle</driver>
    <security>
      <user-name>XXX</user-name>
      <password>YYY</password>
    </security>
    <connection-property name="defaultNChar">true</connection-property>
  </datasource>
</datasources>
{code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  2 10:42:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 2 Oct 2013 10:42:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1709) Logging: convert the most
 important WARN and ERROR messages to use IDs and resource bundles
In-Reply-To: <JIRA.12501808.1380533726000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501808.1380533726000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501808.1380533726000.10567.1380724922565@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808947#comment-12808947 ] 

Bela Ban commented on JGRP-1709:
--------------------------------

The following classes below still need to be converted, excluding
- classes that are not officially supported (STOMP, PRIO)
- classes that are not used anymore (e.g. NAKACK, NakReceiverWindow, Retransmitter, DefaultRetransmitter, RangeBasedRetransmitter etc)
- test code (StateTransferTest)
- demos (Whiteboard, GraphPanel, Draw, QuoteServer)

{panel}
src/org/jgroups/stack/Configurator.java
src/org/jgroups/conf/XmlConfigurator.java
src/org/jgroups/conf/PropertyHelper.java
src/org/jgroups/conf/ProtocolConfiguration.java
src/org/jgroups/conf/ClassConfigurator.java
src/org/jgroups/protocols/Locking.java
src/org/jgroups/protocols/FILE_PING.java
src/org/jgroups/protocols/FD_SOCK.java
src/org/jgroups/protocols/RSVP.java
src/org/jgroups/protocols/UDP.java
src/org/jgroups/protocols/FD_PING.java
src/org/jgroups/protocols/COMPRESS.java
src/org/jgroups/protocols/VERIFY_SUSPECT.java
src/org/jgroups/protocols/MFC.java
src/org/jgroups/protocols/MERGE3.java
src/org/jgroups/protocols/FRAG2.java
src/org/jgroups/protocols/FlowControl.java
src/org/jgroups/protocols/ENCRYPT.java
src/org/jgroups/protocols/FORWARD_TO_COORD.java
src/org/jgroups/protocols/S3_PING.java
src/org/jgroups/protocols/FD.java
src/org/jgroups/protocols/UNICAST2.java
src/org/jgroups/protocols/Discovery.java
src/org/jgroups/protocols/JDBC_PING.java
src/org/jgroups/protocols/TCP.java
src/org/jgroups/protocols/UFC.java
src/org/jgroups/protocols/SEQUENCER.java
src/org/jgroups/protocols/AUTH.java
src/org/jgroups/protocols/TP.java
src/org/jgroups/protocols/TCPGOSSIP.java
src/org/jgroups/protocols/MPING.java
src/org/jgroups/protocols/pbcast/GMS.java
src/org/jgroups/protocols/pbcast/GmsImpl.java
src/org/jgroups/protocols/pbcast/STATE_TRANSFER.java
src/org/jgroups/protocols/pbcast/ClientGmsImpl.java
src/org/jgroups/protocols/pbcast/StreamingStateTransfer.java
src/org/jgroups/protocols/pbcast/Merger.java
src/org/jgroups/protocols/pbcast/CoordGmsImpl.java
src/org/jgroups/protocols/pbcast/STABLE.java
src/org/jgroups/protocols/pbcast/FLUSH.java
src/org/jgroups/protocols/pbcast/STATE_SOCK.java
src/org/jgroups/protocols/pbcast/NAKACK2.java
src/org/jgroups/protocols/relay/RELAY2.java
src/org/jgroups/protocols/relay/Relayer.java
src/org/jgroups/protocols/tom/TOA.java
src/org/jgroups/util/TimeScheduler2.java
src/org/jgroups/util/Util.java
src/org/jgroups/util/ForwardQueue.java
src/org/jgroups/util/Queue.java
src/org/jgroups/jmx/ResourceDMBean.java
src/org/jgroups/jmx/JmxConfigurator.java
src/org/jgroups/blocks/RequestCorrelator.java
src/org/jgroups/blocks/GroupRequest.java
src/org/jgroups/blocks/TCPConnectionMap.java
src/org/jgroups/blocks/Request.java
src/org/jgroups/blocks/RpcDispatcher.java
src/org/jgroups/blocks/MethodCall.java
src/org/jgroups/blocks/MessageDispatcher.java
src/org/jgroups/auth/MD5Token.java
src/org/jgroups/auth/FixedMembershipToken.java
src/org/jgroups/auth/SimpleToken.java
src/org/jgroups/auth/X509Token.java
{panel}
                
> Logging: convert the most important WARN and ERROR messages to use IDs and resource bundles
> -------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1709
>                 URL: https://issues.jboss.org/browse/JGRP-1709
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.4
>
>
> Convert WARN and ERROR messages that might be seen by users to use a resource bundle (conf/jg-messages*.properties) and assign unique IDs the those messages.
> Link in BZ: https://bugzilla.redhat.com/show_bug.cgi?id=999671

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  2 10:44:02 2013
From: jira-events at lists.jboss.org (Kurt Stam (JIRA))
Date: Wed, 2 Oct 2013 10:44:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-194) Add support in KIE to
 register custom Wagons
In-Reply-To: <JIRA.12496882.1374227726000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496882.1374227726000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496882.1374227726000.10579.1380725042994@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kurt Stam updated DROOLS-194:
-----------------------------

    Attachment: kie-srampwagon.tgz


Import the project into eclipse - go into the dtgov-workflows module
and run the KieTest. 

If you have a breakpoint set in the Aether class; it will stop and say the hint = "files".

so you return 'null' at the moment. 

it gets "files' from the protocol defined in the url:

ArtifactRepository srampRepo = artifactRepoFactory.createArtifactRepository("central",  //$NON-NLS-1$
    			"files:/tmp/srampRepo",
                
> Add support in KIE to register custom Wagons
> --------------------------------------------
>
>                 Key: DROOLS-194
>                 URL: https://issues.jboss.org/browse/DROOLS-194
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Kurt Stam
>            Assignee: Mark Proctor
>         Attachments: kie-srampwagon.tgz
>
>
> The ManualWagonProvider subclass of Aether in KIE registers the HTTPWagon. It should be possible to add your own Wagon through config our automated machinery when another Wagon is put on the classpath and references in the build/extensions of a MavenProject. To get the SrampWagon to work we used the following code:
> {quote}
> private static class ManualWagonProvider implements WagonProvider {
>         public Wagon lookup( String roleHint ) throws Exception {
>             if ( "http".equals( roleHint ) ) {
>                 return new AhcWagon();
>             }
>             if ( "sramp".equals( roleHint ) ) {
>                 return new SrampWagon();
>             }
>             return null;
>         }
>         public void release( Wagon wagon ) { }
>     }
> {quote}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  2 10:50:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 2 Oct 2013 10:50:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1709) Logging: convert the most
 important WARN and ERROR messages to use IDs and resource bundles
In-Reply-To: <JIRA.12501808.1380533726000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501808.1380533726000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501808.1380533726000.10592.1380725402795@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808947#comment-12808947 ] 

Bela Ban edited comment on JGRP-1709 at 10/2/13 10:49 AM:
----------------------------------------------------------

The following classes below still need to be converted, excluding
- classes that are not officially supported (STOMP, PRIO)
- classes that are not used anymore (e.g. NAKACK, NakReceiverWindow, Retransmitter, DefaultRetransmitter, RangeBasedRetransmitter etc)
- test code (StateTransferTest)
- demos (Whiteboard, GraphPanel, Draw, QuoteServer)

{panel}
-src/org/jgroups/stack/Configurator.java-
src/org/jgroups/conf/XmlConfigurator.java
src/org/jgroups/conf/PropertyHelper.java
src/org/jgroups/conf/ProtocolConfiguration.java
src/org/jgroups/conf/ClassConfigurator.java
src/org/jgroups/protocols/Locking.java
src/org/jgroups/protocols/FILE_PING.java
src/org/jgroups/protocols/FD_SOCK.java
src/org/jgroups/protocols/RSVP.java
src/org/jgroups/protocols/UDP.java
src/org/jgroups/protocols/FD_PING.java
src/org/jgroups/protocols/COMPRESS.java
src/org/jgroups/protocols/VERIFY_SUSPECT.java
src/org/jgroups/protocols/MFC.java
src/org/jgroups/protocols/MERGE3.java
src/org/jgroups/protocols/FRAG2.java
src/org/jgroups/protocols/FlowControl.java
src/org/jgroups/protocols/ENCRYPT.java
src/org/jgroups/protocols/FORWARD_TO_COORD.java
src/org/jgroups/protocols/S3_PING.java
src/org/jgroups/protocols/FD.java
src/org/jgroups/protocols/UNICAST2.java
src/org/jgroups/protocols/Discovery.java
src/org/jgroups/protocols/JDBC_PING.java
src/org/jgroups/protocols/TCP.java
src/org/jgroups/protocols/UFC.java
src/org/jgroups/protocols/SEQUENCER.java
src/org/jgroups/protocols/AUTH.java
src/org/jgroups/protocols/TP.java
src/org/jgroups/protocols/TCPGOSSIP.java
src/org/jgroups/protocols/MPING.java
src/org/jgroups/protocols/pbcast/GMS.java
src/org/jgroups/protocols/pbcast/GmsImpl.java
src/org/jgroups/protocols/pbcast/STATE_TRANSFER.java
src/org/jgroups/protocols/pbcast/ClientGmsImpl.java
src/org/jgroups/protocols/pbcast/StreamingStateTransfer.java
src/org/jgroups/protocols/pbcast/Merger.java
src/org/jgroups/protocols/pbcast/CoordGmsImpl.java
src/org/jgroups/protocols/pbcast/STABLE.java
src/org/jgroups/protocols/pbcast/FLUSH.java
src/org/jgroups/protocols/pbcast/STATE_SOCK.java
src/org/jgroups/protocols/pbcast/NAKACK2.java
src/org/jgroups/protocols/relay/RELAY2.java
src/org/jgroups/protocols/relay/Relayer.java
src/org/jgroups/protocols/tom/TOA.java
src/org/jgroups/util/TimeScheduler2.java
src/org/jgroups/util/Util.java
src/org/jgroups/util/ForwardQueue.java
src/org/jgroups/util/Queue.java
src/org/jgroups/jmx/ResourceDMBean.java
src/org/jgroups/jmx/JmxConfigurator.java
src/org/jgroups/blocks/RequestCorrelator.java
src/org/jgroups/blocks/GroupRequest.java
src/org/jgroups/blocks/TCPConnectionMap.java
src/org/jgroups/blocks/Request.java
src/org/jgroups/blocks/RpcDispatcher.java
src/org/jgroups/blocks/MethodCall.java
src/org/jgroups/blocks/MessageDispatcher.java
src/org/jgroups/auth/MD5Token.java
src/org/jgroups/auth/FixedMembershipToken.java
src/org/jgroups/auth/SimpleToken.java
src/org/jgroups/auth/X509Token.java
{panel}
                
      was (Author: belaban):
    The following classes below still need to be converted, excluding
- classes that are not officially supported (STOMP, PRIO)
- classes that are not used anymore (e.g. NAKACK, NakReceiverWindow, Retransmitter, DefaultRetransmitter, RangeBasedRetransmitter etc)
- test code (StateTransferTest)
- demos (Whiteboard, GraphPanel, Draw, QuoteServer)

{panel}
src/org/jgroups/stack/Configurator.java
src/org/jgroups/conf/XmlConfigurator.java
src/org/jgroups/conf/PropertyHelper.java
src/org/jgroups/conf/ProtocolConfiguration.java
src/org/jgroups/conf/ClassConfigurator.java
src/org/jgroups/protocols/Locking.java
src/org/jgroups/protocols/FILE_PING.java
src/org/jgroups/protocols/FD_SOCK.java
src/org/jgroups/protocols/RSVP.java
src/org/jgroups/protocols/UDP.java
src/org/jgroups/protocols/FD_PING.java
src/org/jgroups/protocols/COMPRESS.java
src/org/jgroups/protocols/VERIFY_SUSPECT.java
src/org/jgroups/protocols/MFC.java
src/org/jgroups/protocols/MERGE3.java
src/org/jgroups/protocols/FRAG2.java
src/org/jgroups/protocols/FlowControl.java
src/org/jgroups/protocols/ENCRYPT.java
src/org/jgroups/protocols/FORWARD_TO_COORD.java
src/org/jgroups/protocols/S3_PING.java
src/org/jgroups/protocols/FD.java
src/org/jgroups/protocols/UNICAST2.java
src/org/jgroups/protocols/Discovery.java
src/org/jgroups/protocols/JDBC_PING.java
src/org/jgroups/protocols/TCP.java
src/org/jgroups/protocols/UFC.java
src/org/jgroups/protocols/SEQUENCER.java
src/org/jgroups/protocols/AUTH.java
src/org/jgroups/protocols/TP.java
src/org/jgroups/protocols/TCPGOSSIP.java
src/org/jgroups/protocols/MPING.java
src/org/jgroups/protocols/pbcast/GMS.java
src/org/jgroups/protocols/pbcast/GmsImpl.java
src/org/jgroups/protocols/pbcast/STATE_TRANSFER.java
src/org/jgroups/protocols/pbcast/ClientGmsImpl.java
src/org/jgroups/protocols/pbcast/StreamingStateTransfer.java
src/org/jgroups/protocols/pbcast/Merger.java
src/org/jgroups/protocols/pbcast/CoordGmsImpl.java
src/org/jgroups/protocols/pbcast/STABLE.java
src/org/jgroups/protocols/pbcast/FLUSH.java
src/org/jgroups/protocols/pbcast/STATE_SOCK.java
src/org/jgroups/protocols/pbcast/NAKACK2.java
src/org/jgroups/protocols/relay/RELAY2.java
src/org/jgroups/protocols/relay/Relayer.java
src/org/jgroups/protocols/tom/TOA.java
src/org/jgroups/util/TimeScheduler2.java
src/org/jgroups/util/Util.java
src/org/jgroups/util/ForwardQueue.java
src/org/jgroups/util/Queue.java
src/org/jgroups/jmx/ResourceDMBean.java
src/org/jgroups/jmx/JmxConfigurator.java
src/org/jgroups/blocks/RequestCorrelator.java
src/org/jgroups/blocks/GroupRequest.java
src/org/jgroups/blocks/TCPConnectionMap.java
src/org/jgroups/blocks/Request.java
src/org/jgroups/blocks/RpcDispatcher.java
src/org/jgroups/blocks/MethodCall.java
src/org/jgroups/blocks/MessageDispatcher.java
src/org/jgroups/auth/MD5Token.java
src/org/jgroups/auth/FixedMembershipToken.java
src/org/jgroups/auth/SimpleToken.java
src/org/jgroups/auth/X509Token.java
{panel}
                  
> Logging: convert the most important WARN and ERROR messages to use IDs and resource bundles
> -------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1709
>                 URL: https://issues.jboss.org/browse/JGRP-1709
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.4
>
>
> Convert WARN and ERROR messages that might be seen by users to use a resource bundle (conf/jg-messages*.properties) and assign unique IDs the those messages.
> Link in BZ: https://bugzilla.redhat.com/show_bug.cgi?id=999671

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  2 10:52:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 2 Oct 2013 10:52:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1709) Logging: convert the most
 important WARN and ERROR messages to use IDs and resource bundles
In-Reply-To: <JIRA.12501808.1380533726000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501808.1380533726000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501808.1380533726000.10595.1380725522632@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808947#comment-12808947 ] 

Bela Ban edited comment on JGRP-1709 at 10/2/13 10:50 AM:
----------------------------------------------------------

The following classes below still need to be converted, excluding
- classes that are not officially supported (STOMP, PRIO)
- classes that are not used anymore (e.g. NAKACK, NakReceiverWindow, Retransmitter, DefaultRetransmitter, RangeBasedRetransmitter etc)
- test code (StateTransferTest)
- demos (Whiteboard, GraphPanel, Draw, QuoteServer)

{panel}
-src/org/jgroups/stack/Configurator.java-
-src/org/jgroups/conf/XmlConfigurator.java-
src/org/jgroups/conf/PropertyHelper.java
src/org/jgroups/conf/ProtocolConfiguration.java
src/org/jgroups/conf/ClassConfigurator.java
src/org/jgroups/protocols/Locking.java
src/org/jgroups/protocols/FILE_PING.java
src/org/jgroups/protocols/FD_SOCK.java
src/org/jgroups/protocols/RSVP.java
src/org/jgroups/protocols/UDP.java
src/org/jgroups/protocols/FD_PING.java
src/org/jgroups/protocols/COMPRESS.java
src/org/jgroups/protocols/VERIFY_SUSPECT.java
src/org/jgroups/protocols/MFC.java
src/org/jgroups/protocols/MERGE3.java
src/org/jgroups/protocols/FRAG2.java
src/org/jgroups/protocols/FlowControl.java
src/org/jgroups/protocols/ENCRYPT.java
src/org/jgroups/protocols/FORWARD_TO_COORD.java
src/org/jgroups/protocols/S3_PING.java
src/org/jgroups/protocols/FD.java
src/org/jgroups/protocols/UNICAST2.java
src/org/jgroups/protocols/Discovery.java
src/org/jgroups/protocols/JDBC_PING.java
src/org/jgroups/protocols/TCP.java
src/org/jgroups/protocols/UFC.java
src/org/jgroups/protocols/SEQUENCER.java
src/org/jgroups/protocols/AUTH.java
src/org/jgroups/protocols/TP.java
src/org/jgroups/protocols/TCPGOSSIP.java
src/org/jgroups/protocols/MPING.java
src/org/jgroups/protocols/pbcast/GMS.java
src/org/jgroups/protocols/pbcast/GmsImpl.java
src/org/jgroups/protocols/pbcast/STATE_TRANSFER.java
src/org/jgroups/protocols/pbcast/ClientGmsImpl.java
src/org/jgroups/protocols/pbcast/StreamingStateTransfer.java
src/org/jgroups/protocols/pbcast/Merger.java
src/org/jgroups/protocols/pbcast/CoordGmsImpl.java
src/org/jgroups/protocols/pbcast/STABLE.java
src/org/jgroups/protocols/pbcast/FLUSH.java
src/org/jgroups/protocols/pbcast/STATE_SOCK.java
src/org/jgroups/protocols/pbcast/NAKACK2.java
src/org/jgroups/protocols/relay/RELAY2.java
src/org/jgroups/protocols/relay/Relayer.java
src/org/jgroups/protocols/tom/TOA.java
src/org/jgroups/util/TimeScheduler2.java
src/org/jgroups/util/Util.java
src/org/jgroups/util/ForwardQueue.java
src/org/jgroups/util/Queue.java
src/org/jgroups/jmx/ResourceDMBean.java
src/org/jgroups/jmx/JmxConfigurator.java
src/org/jgroups/blocks/RequestCorrelator.java
src/org/jgroups/blocks/GroupRequest.java
src/org/jgroups/blocks/TCPConnectionMap.java
src/org/jgroups/blocks/Request.java
src/org/jgroups/blocks/RpcDispatcher.java
src/org/jgroups/blocks/MethodCall.java
src/org/jgroups/blocks/MessageDispatcher.java
src/org/jgroups/auth/MD5Token.java
src/org/jgroups/auth/FixedMembershipToken.java
src/org/jgroups/auth/SimpleToken.java
src/org/jgroups/auth/X509Token.java
{panel}
                
      was (Author: belaban):
    The following classes below still need to be converted, excluding
- classes that are not officially supported (STOMP, PRIO)
- classes that are not used anymore (e.g. NAKACK, NakReceiverWindow, Retransmitter, DefaultRetransmitter, RangeBasedRetransmitter etc)
- test code (StateTransferTest)
- demos (Whiteboard, GraphPanel, Draw, QuoteServer)

{panel}
-src/org/jgroups/stack/Configurator.java-
src/org/jgroups/conf/XmlConfigurator.java
src/org/jgroups/conf/PropertyHelper.java
src/org/jgroups/conf/ProtocolConfiguration.java
src/org/jgroups/conf/ClassConfigurator.java
src/org/jgroups/protocols/Locking.java
src/org/jgroups/protocols/FILE_PING.java
src/org/jgroups/protocols/FD_SOCK.java
src/org/jgroups/protocols/RSVP.java
src/org/jgroups/protocols/UDP.java
src/org/jgroups/protocols/FD_PING.java
src/org/jgroups/protocols/COMPRESS.java
src/org/jgroups/protocols/VERIFY_SUSPECT.java
src/org/jgroups/protocols/MFC.java
src/org/jgroups/protocols/MERGE3.java
src/org/jgroups/protocols/FRAG2.java
src/org/jgroups/protocols/FlowControl.java
src/org/jgroups/protocols/ENCRYPT.java
src/org/jgroups/protocols/FORWARD_TO_COORD.java
src/org/jgroups/protocols/S3_PING.java
src/org/jgroups/protocols/FD.java
src/org/jgroups/protocols/UNICAST2.java
src/org/jgroups/protocols/Discovery.java
src/org/jgroups/protocols/JDBC_PING.java
src/org/jgroups/protocols/TCP.java
src/org/jgroups/protocols/UFC.java
src/org/jgroups/protocols/SEQUENCER.java
src/org/jgroups/protocols/AUTH.java
src/org/jgroups/protocols/TP.java
src/org/jgroups/protocols/TCPGOSSIP.java
src/org/jgroups/protocols/MPING.java
src/org/jgroups/protocols/pbcast/GMS.java
src/org/jgroups/protocols/pbcast/GmsImpl.java
src/org/jgroups/protocols/pbcast/STATE_TRANSFER.java
src/org/jgroups/protocols/pbcast/ClientGmsImpl.java
src/org/jgroups/protocols/pbcast/StreamingStateTransfer.java
src/org/jgroups/protocols/pbcast/Merger.java
src/org/jgroups/protocols/pbcast/CoordGmsImpl.java
src/org/jgroups/protocols/pbcast/STABLE.java
src/org/jgroups/protocols/pbcast/FLUSH.java
src/org/jgroups/protocols/pbcast/STATE_SOCK.java
src/org/jgroups/protocols/pbcast/NAKACK2.java
src/org/jgroups/protocols/relay/RELAY2.java
src/org/jgroups/protocols/relay/Relayer.java
src/org/jgroups/protocols/tom/TOA.java
src/org/jgroups/util/TimeScheduler2.java
src/org/jgroups/util/Util.java
src/org/jgroups/util/ForwardQueue.java
src/org/jgroups/util/Queue.java
src/org/jgroups/jmx/ResourceDMBean.java
src/org/jgroups/jmx/JmxConfigurator.java
src/org/jgroups/blocks/RequestCorrelator.java
src/org/jgroups/blocks/GroupRequest.java
src/org/jgroups/blocks/TCPConnectionMap.java
src/org/jgroups/blocks/Request.java
src/org/jgroups/blocks/RpcDispatcher.java
src/org/jgroups/blocks/MethodCall.java
src/org/jgroups/blocks/MessageDispatcher.java
src/org/jgroups/auth/MD5Token.java
src/org/jgroups/auth/FixedMembershipToken.java
src/org/jgroups/auth/SimpleToken.java
src/org/jgroups/auth/X509Token.java
{panel}
                  
> Logging: convert the most important WARN and ERROR messages to use IDs and resource bundles
> -------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1709
>                 URL: https://issues.jboss.org/browse/JGRP-1709
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.4
>
>
> Convert WARN and ERROR messages that might be seen by users to use a resource bundle (conf/jg-messages*.properties) and assign unique IDs the those messages.
> Link in BZ: https://bugzilla.redhat.com/show_bug.cgi?id=999671

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  2 10:54:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 2 Oct 2013 10:54:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1709) Logging: convert the most
 important WARN and ERROR messages to use IDs and resource bundles
In-Reply-To: <JIRA.12501808.1380533726000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501808.1380533726000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501808.1380533726000.10601.1380725642629@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808947#comment-12808947 ] 

Bela Ban edited comment on JGRP-1709 at 10/2/13 10:52 AM:
----------------------------------------------------------

The following classes below still need to be converted, excluding
- classes that are not officially supported (STOMP, PRIO)
- classes that are not used anymore (e.g. NAKACK, NakReceiverWindow, Retransmitter, DefaultRetransmitter, RangeBasedRetransmitter etc)
- test code (StateTransferTest)
- demos (Whiteboard, GraphPanel, Draw, QuoteServer)

{panel}
-src/org/jgroups/stack/Configurator.java-
-src/org/jgroups/conf/XmlConfigurator.java-
-src/org/jgroups/conf/PropertyHelper.java-
-src/org/jgroups/conf/ProtocolConfiguration.java-
-src/org/jgroups/conf/ClassConfigurator.java-
src/org/jgroups/protocols/Locking.java
src/org/jgroups/protocols/FILE_PING.java
src/org/jgroups/protocols/FD_SOCK.java
src/org/jgroups/protocols/RSVP.java
src/org/jgroups/protocols/UDP.java
src/org/jgroups/protocols/FD_PING.java
src/org/jgroups/protocols/COMPRESS.java
src/org/jgroups/protocols/VERIFY_SUSPECT.java
src/org/jgroups/protocols/MFC.java
src/org/jgroups/protocols/MERGE3.java
src/org/jgroups/protocols/FRAG2.java
src/org/jgroups/protocols/FlowControl.java
src/org/jgroups/protocols/ENCRYPT.java
src/org/jgroups/protocols/FORWARD_TO_COORD.java
src/org/jgroups/protocols/S3_PING.java
src/org/jgroups/protocols/FD.java
src/org/jgroups/protocols/UNICAST2.java
src/org/jgroups/protocols/Discovery.java
src/org/jgroups/protocols/JDBC_PING.java
src/org/jgroups/protocols/TCP.java
src/org/jgroups/protocols/UFC.java
src/org/jgroups/protocols/SEQUENCER.java
src/org/jgroups/protocols/AUTH.java
src/org/jgroups/protocols/TP.java
src/org/jgroups/protocols/TCPGOSSIP.java
src/org/jgroups/protocols/MPING.java
src/org/jgroups/protocols/pbcast/GMS.java
src/org/jgroups/protocols/pbcast/GmsImpl.java
src/org/jgroups/protocols/pbcast/STATE_TRANSFER.java
src/org/jgroups/protocols/pbcast/ClientGmsImpl.java
src/org/jgroups/protocols/pbcast/StreamingStateTransfer.java
src/org/jgroups/protocols/pbcast/Merger.java
src/org/jgroups/protocols/pbcast/CoordGmsImpl.java
src/org/jgroups/protocols/pbcast/STABLE.java
src/org/jgroups/protocols/pbcast/FLUSH.java
src/org/jgroups/protocols/pbcast/STATE_SOCK.java
src/org/jgroups/protocols/pbcast/NAKACK2.java
src/org/jgroups/protocols/relay/RELAY2.java
src/org/jgroups/protocols/relay/Relayer.java
src/org/jgroups/protocols/tom/TOA.java
src/org/jgroups/util/TimeScheduler2.java
src/org/jgroups/util/Util.java
src/org/jgroups/util/ForwardQueue.java
src/org/jgroups/util/Queue.java
src/org/jgroups/jmx/ResourceDMBean.java
src/org/jgroups/jmx/JmxConfigurator.java
src/org/jgroups/blocks/RequestCorrelator.java
src/org/jgroups/blocks/GroupRequest.java
src/org/jgroups/blocks/TCPConnectionMap.java
src/org/jgroups/blocks/Request.java
src/org/jgroups/blocks/RpcDispatcher.java
src/org/jgroups/blocks/MethodCall.java
src/org/jgroups/blocks/MessageDispatcher.java
src/org/jgroups/auth/MD5Token.java
src/org/jgroups/auth/FixedMembershipToken.java
src/org/jgroups/auth/SimpleToken.java
src/org/jgroups/auth/X509Token.java
{panel}
                
      was (Author: belaban):
    The following classes below still need to be converted, excluding
- classes that are not officially supported (STOMP, PRIO)
- classes that are not used anymore (e.g. NAKACK, NakReceiverWindow, Retransmitter, DefaultRetransmitter, RangeBasedRetransmitter etc)
- test code (StateTransferTest)
- demos (Whiteboard, GraphPanel, Draw, QuoteServer)

{panel}
-src/org/jgroups/stack/Configurator.java-
-src/org/jgroups/conf/XmlConfigurator.java-
src/org/jgroups/conf/PropertyHelper.java
src/org/jgroups/conf/ProtocolConfiguration.java
src/org/jgroups/conf/ClassConfigurator.java
src/org/jgroups/protocols/Locking.java
src/org/jgroups/protocols/FILE_PING.java
src/org/jgroups/protocols/FD_SOCK.java
src/org/jgroups/protocols/RSVP.java
src/org/jgroups/protocols/UDP.java
src/org/jgroups/protocols/FD_PING.java
src/org/jgroups/protocols/COMPRESS.java
src/org/jgroups/protocols/VERIFY_SUSPECT.java
src/org/jgroups/protocols/MFC.java
src/org/jgroups/protocols/MERGE3.java
src/org/jgroups/protocols/FRAG2.java
src/org/jgroups/protocols/FlowControl.java
src/org/jgroups/protocols/ENCRYPT.java
src/org/jgroups/protocols/FORWARD_TO_COORD.java
src/org/jgroups/protocols/S3_PING.java
src/org/jgroups/protocols/FD.java
src/org/jgroups/protocols/UNICAST2.java
src/org/jgroups/protocols/Discovery.java
src/org/jgroups/protocols/JDBC_PING.java
src/org/jgroups/protocols/TCP.java
src/org/jgroups/protocols/UFC.java
src/org/jgroups/protocols/SEQUENCER.java
src/org/jgroups/protocols/AUTH.java
src/org/jgroups/protocols/TP.java
src/org/jgroups/protocols/TCPGOSSIP.java
src/org/jgroups/protocols/MPING.java
src/org/jgroups/protocols/pbcast/GMS.java
src/org/jgroups/protocols/pbcast/GmsImpl.java
src/org/jgroups/protocols/pbcast/STATE_TRANSFER.java
src/org/jgroups/protocols/pbcast/ClientGmsImpl.java
src/org/jgroups/protocols/pbcast/StreamingStateTransfer.java
src/org/jgroups/protocols/pbcast/Merger.java
src/org/jgroups/protocols/pbcast/CoordGmsImpl.java
src/org/jgroups/protocols/pbcast/STABLE.java
src/org/jgroups/protocols/pbcast/FLUSH.java
src/org/jgroups/protocols/pbcast/STATE_SOCK.java
src/org/jgroups/protocols/pbcast/NAKACK2.java
src/org/jgroups/protocols/relay/RELAY2.java
src/org/jgroups/protocols/relay/Relayer.java
src/org/jgroups/protocols/tom/TOA.java
src/org/jgroups/util/TimeScheduler2.java
src/org/jgroups/util/Util.java
src/org/jgroups/util/ForwardQueue.java
src/org/jgroups/util/Queue.java
src/org/jgroups/jmx/ResourceDMBean.java
src/org/jgroups/jmx/JmxConfigurator.java
src/org/jgroups/blocks/RequestCorrelator.java
src/org/jgroups/blocks/GroupRequest.java
src/org/jgroups/blocks/TCPConnectionMap.java
src/org/jgroups/blocks/Request.java
src/org/jgroups/blocks/RpcDispatcher.java
src/org/jgroups/blocks/MethodCall.java
src/org/jgroups/blocks/MessageDispatcher.java
src/org/jgroups/auth/MD5Token.java
src/org/jgroups/auth/FixedMembershipToken.java
src/org/jgroups/auth/SimpleToken.java
src/org/jgroups/auth/X509Token.java
{panel}
                  
> Logging: convert the most important WARN and ERROR messages to use IDs and resource bundles
> -------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1709
>                 URL: https://issues.jboss.org/browse/JGRP-1709
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.4
>
>
> Convert WARN and ERROR messages that might be seen by users to use a resource bundle (conf/jg-messages*.properties) and assign unique IDs the those messages.
> Link in BZ: https://bugzilla.redhat.com/show_bug.cgi?id=999671

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  2 11:05:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 2 Oct 2013 11:05:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1709) Logging: convert the most
 important WARN and ERROR messages to use IDs and resource bundles
In-Reply-To: <JIRA.12501808.1380533726000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501808.1380533726000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501808.1380533726000.10619.1380726302635@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808947#comment-12808947 ] 

Bela Ban edited comment on JGRP-1709 at 10/2/13 11:03 AM:
----------------------------------------------------------

The following classes below still need to be converted, excluding
- classes that are not officially supported (STOMP, PRIO)
- classes that are not used anymore (e.g. NAKACK, NakReceiverWindow, Retransmitter, DefaultRetransmitter, RangeBasedRetransmitter etc)
- test code (StateTransferTest)
- demos (Whiteboard, GraphPanel, Draw, QuoteServer)

{panel}
-src/org/jgroups/stack/Configurator.java-
-src/org/jgroups/conf/XmlConfigurator.java-
-src/org/jgroups/conf/PropertyHelper.java-
-src/org/jgroups/conf/ProtocolConfiguration.java-
-src/org/jgroups/conf/ClassConfigurator.java-
src/org/jgroups/protocols/FILE_PING.java
src/org/jgroups/protocols/FD_SOCK.java
src/org/jgroups/protocols/RSVP.java
src/org/jgroups/protocols/UDP.java
src/org/jgroups/protocols/FD_PING.java
src/org/jgroups/protocols/COMPRESS.java
src/org/jgroups/protocols/VERIFY_SUSPECT.java
src/org/jgroups/protocols/MFC.java
src/org/jgroups/protocols/MERGE3.java
src/org/jgroups/protocols/FRAG2.java
src/org/jgroups/protocols/FlowControl.java
src/org/jgroups/protocols/ENCRYPT.java
src/org/jgroups/protocols/FORWARD_TO_COORD.java
src/org/jgroups/protocols/S3_PING.java
src/org/jgroups/protocols/FD.java
src/org/jgroups/protocols/UNICAST2.java
src/org/jgroups/protocols/Discovery.java
src/org/jgroups/protocols/JDBC_PING.java
src/org/jgroups/protocols/TCP.java
src/org/jgroups/protocols/UFC.java
src/org/jgroups/protocols/SEQUENCER.java
src/org/jgroups/protocols/AUTH.java
src/org/jgroups/protocols/TP.java
src/org/jgroups/protocols/TCPGOSSIP.java
src/org/jgroups/protocols/MPING.java
src/org/jgroups/protocols/pbcast/GMS.java
src/org/jgroups/protocols/pbcast/GmsImpl.java
src/org/jgroups/protocols/pbcast/STATE_TRANSFER.java
src/org/jgroups/protocols/pbcast/ClientGmsImpl.java
src/org/jgroups/protocols/pbcast/StreamingStateTransfer.java
src/org/jgroups/protocols/pbcast/Merger.java
src/org/jgroups/protocols/pbcast/CoordGmsImpl.java
src/org/jgroups/protocols/pbcast/STABLE.java
src/org/jgroups/protocols/pbcast/FLUSH.java
src/org/jgroups/protocols/pbcast/STATE_SOCK.java
src/org/jgroups/protocols/pbcast/NAKACK2.java
src/org/jgroups/protocols/relay/RELAY2.java
src/org/jgroups/protocols/relay/Relayer.java
src/org/jgroups/protocols/tom/TOA.java
src/org/jgroups/util/TimeScheduler2.java
src/org/jgroups/util/Util.java
src/org/jgroups/util/ForwardQueue.java
src/org/jgroups/util/Queue.java
src/org/jgroups/jmx/ResourceDMBean.java
src/org/jgroups/jmx/JmxConfigurator.java
src/org/jgroups/blocks/RequestCorrelator.java
src/org/jgroups/blocks/GroupRequest.java
src/org/jgroups/blocks/TCPConnectionMap.java
src/org/jgroups/blocks/Request.java
src/org/jgroups/blocks/RpcDispatcher.java
src/org/jgroups/blocks/MethodCall.java
src/org/jgroups/blocks/MessageDispatcher.java
src/org/jgroups/auth/MD5Token.java
src/org/jgroups/auth/FixedMembershipToken.java
src/org/jgroups/auth/SimpleToken.java
src/org/jgroups/auth/X509Token.java
{panel}
                
      was (Author: belaban):
    The following classes below still need to be converted, excluding
- classes that are not officially supported (STOMP, PRIO)
- classes that are not used anymore (e.g. NAKACK, NakReceiverWindow, Retransmitter, DefaultRetransmitter, RangeBasedRetransmitter etc)
- test code (StateTransferTest)
- demos (Whiteboard, GraphPanel, Draw, QuoteServer)

{panel}
-src/org/jgroups/stack/Configurator.java-
-src/org/jgroups/conf/XmlConfigurator.java-
-src/org/jgroups/conf/PropertyHelper.java-
-src/org/jgroups/conf/ProtocolConfiguration.java-
-src/org/jgroups/conf/ClassConfigurator.java-
src/org/jgroups/protocols/Locking.java
src/org/jgroups/protocols/FILE_PING.java
src/org/jgroups/protocols/FD_SOCK.java
src/org/jgroups/protocols/RSVP.java
src/org/jgroups/protocols/UDP.java
src/org/jgroups/protocols/FD_PING.java
src/org/jgroups/protocols/COMPRESS.java
src/org/jgroups/protocols/VERIFY_SUSPECT.java
src/org/jgroups/protocols/MFC.java
src/org/jgroups/protocols/MERGE3.java
src/org/jgroups/protocols/FRAG2.java
src/org/jgroups/protocols/FlowControl.java
src/org/jgroups/protocols/ENCRYPT.java
src/org/jgroups/protocols/FORWARD_TO_COORD.java
src/org/jgroups/protocols/S3_PING.java
src/org/jgroups/protocols/FD.java
src/org/jgroups/protocols/UNICAST2.java
src/org/jgroups/protocols/Discovery.java
src/org/jgroups/protocols/JDBC_PING.java
src/org/jgroups/protocols/TCP.java
src/org/jgroups/protocols/UFC.java
src/org/jgroups/protocols/SEQUENCER.java
src/org/jgroups/protocols/AUTH.java
src/org/jgroups/protocols/TP.java
src/org/jgroups/protocols/TCPGOSSIP.java
src/org/jgroups/protocols/MPING.java
src/org/jgroups/protocols/pbcast/GMS.java
src/org/jgroups/protocols/pbcast/GmsImpl.java
src/org/jgroups/protocols/pbcast/STATE_TRANSFER.java
src/org/jgroups/protocols/pbcast/ClientGmsImpl.java
src/org/jgroups/protocols/pbcast/StreamingStateTransfer.java
src/org/jgroups/protocols/pbcast/Merger.java
src/org/jgroups/protocols/pbcast/CoordGmsImpl.java
src/org/jgroups/protocols/pbcast/STABLE.java
src/org/jgroups/protocols/pbcast/FLUSH.java
src/org/jgroups/protocols/pbcast/STATE_SOCK.java
src/org/jgroups/protocols/pbcast/NAKACK2.java
src/org/jgroups/protocols/relay/RELAY2.java
src/org/jgroups/protocols/relay/Relayer.java
src/org/jgroups/protocols/tom/TOA.java
src/org/jgroups/util/TimeScheduler2.java
src/org/jgroups/util/Util.java
src/org/jgroups/util/ForwardQueue.java
src/org/jgroups/util/Queue.java
src/org/jgroups/jmx/ResourceDMBean.java
src/org/jgroups/jmx/JmxConfigurator.java
src/org/jgroups/blocks/RequestCorrelator.java
src/org/jgroups/blocks/GroupRequest.java
src/org/jgroups/blocks/TCPConnectionMap.java
src/org/jgroups/blocks/Request.java
src/org/jgroups/blocks/RpcDispatcher.java
src/org/jgroups/blocks/MethodCall.java
src/org/jgroups/blocks/MessageDispatcher.java
src/org/jgroups/auth/MD5Token.java
src/org/jgroups/auth/FixedMembershipToken.java
src/org/jgroups/auth/SimpleToken.java
src/org/jgroups/auth/X509Token.java
{panel}
                  
> Logging: convert the most important WARN and ERROR messages to use IDs and resource bundles
> -------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1709
>                 URL: https://issues.jboss.org/browse/JGRP-1709
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.4
>
>
> Convert WARN and ERROR messages that might be seen by users to use a resource bundle (conf/jg-messages*.properties) and assign unique IDs the those messages.
> Link in BZ: https://bugzilla.redhat.com/show_bug.cgi?id=999671

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  2 11:17:02 2013
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Wed, 2 Oct 2013 11:17:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2204) runtime exceptions thrown
 during parsing crash cli sessions
In-Reply-To: <JIRA.12502024.1380726912333@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502024.1380726912333@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502024.1380726912333.10654.1380727022506@jira02.app.mwc.hst.phx2.redhat.com>

Alexey Loubyansky created WFLY-2204:
---------------------------------------

             Summary: runtime exceptions thrown during parsing crash cli sessions
                 Key: WFLY-2204
                 URL: https://issues.jboss.org/browse/WFLY-2204
             Project: WildFly
          Issue Type: Bug
          Components: CLI
    Affects Versions: 8.0.0.Alpha4
            Reporter: Alexey Loubyansky
            Assignee: Alexey Loubyansky


Runtime exceptions thrown during command line parsing crash CLI sessions.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  2 11:19:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 2 Oct 2013 11:19:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2204) runtime exceptions thrown
 during parsing crash cli sessions
In-Reply-To: <JIRA.12502024.1380726912000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502024.1380726912000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502024.1380726912000.10659.1380727142600@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2204:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=997584

    
> runtime exceptions thrown during parsing crash cli sessions
> -----------------------------------------------------------
>
>                 Key: WFLY-2204
>                 URL: https://issues.jboss.org/browse/WFLY-2204
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>
> Runtime exceptions thrown during command line parsing crash CLI sessions.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  2 11:37:02 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 2 Oct 2013 11:37:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2205) Undeployment prints null
In-Reply-To: <JIRA.12502025.1380728136795@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502025.1380728136795@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502025.1380728136795.10776.1380728222597@jira02.app.mwc.hst.phx2.redhat.com>

Jesper Pedersen created WFLY-2205:
-------------------------------------

             Summary: Undeployment prints null
                 Key: WFLY-2205
                 URL: https://issues.jboss.org/browse/WFLY-2205
             Project: WildFly
          Issue Type: Bug
          Components: Server
    Affects Versions: 8.0.0.Beta1
            Reporter: Jesper Pedersen
            Assignee: Tomaz Cerar


The following is printed during a shutdown of an .ear

{noformat}
11:21:52,260 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015877: Stopped deployment null (runtime-name: msginflow1_mdb_msginflow_ejb.jar) in 16ms
11:21:52,260 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-11) JBAS015877: Stopped deployment null (runtime-name: msginflow_mdb_msginflow_ejb.jar) in 16ms
11:21:52,262 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-11) JBAS015877: Stopped deployment msginflow_mdb.ear (runtime-name: msginflow_mdb.ear) in 18ms
11:21:52,387 INFO  [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS018558: Undeployed "msginflow_mdb.ear" (runtime-name: "msginflow_mdb.ear")
{noformat}

The 'null' part of the .jar undeployment doesn't look nice.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  2 11:37:02 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 2 Oct 2013 11:37:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2205) Undeployment prints null
In-Reply-To: <JIRA.12502025.1380728136000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502025.1380728136000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502025.1380728136000.10779.1380728222762@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808989#comment-12808989 ] 

Tomaz Cerar commented on WFLY-2205:
-----------------------------------

You can reproduce this on current nightly build? As there ware some fixes around this in last few months...
                
> Undeployment prints null
> ------------------------
>
>                 Key: WFLY-2205
>                 URL: https://issues.jboss.org/browse/WFLY-2205
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Jesper Pedersen
>            Assignee: Tomaz Cerar
>
> The following is printed during a shutdown of an .ear
> {noformat}
> 11:21:52,260 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015877: Stopped deployment null (runtime-name: msginflow1_mdb_msginflow_ejb.jar) in 16ms
> 11:21:52,260 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-11) JBAS015877: Stopped deployment null (runtime-name: msginflow_mdb_msginflow_ejb.jar) in 16ms
> 11:21:52,262 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-11) JBAS015877: Stopped deployment msginflow_mdb.ear (runtime-name: msginflow_mdb.ear) in 18ms
> 11:21:52,387 INFO  [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS018558: Undeployed "msginflow_mdb.ear" (runtime-name: "msginflow_mdb.ear")
> {noformat}
> The 'null' part of the .jar undeployment doesn't look nice.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  2 11:39:02 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 2 Oct 2013 11:39:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2205) Undeployment prints null
In-Reply-To: <JIRA.12502025.1380728136000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502025.1380728136000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502025.1380728136000.10783.1380728342630@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808990#comment-12808990 ] 

Jesper Pedersen commented on WFLY-2205:
---------------------------------------

Rebase from today
                
> Undeployment prints null
> ------------------------
>
>                 Key: WFLY-2205
>                 URL: https://issues.jboss.org/browse/WFLY-2205
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Jesper Pedersen
>            Assignee: Tomaz Cerar
>
> The following is printed during a shutdown of an .ear
> {noformat}
> 11:21:52,260 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015877: Stopped deployment null (runtime-name: msginflow1_mdb_msginflow_ejb.jar) in 16ms
> 11:21:52,260 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-11) JBAS015877: Stopped deployment null (runtime-name: msginflow_mdb_msginflow_ejb.jar) in 16ms
> 11:21:52,262 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-11) JBAS015877: Stopped deployment msginflow_mdb.ear (runtime-name: msginflow_mdb.ear) in 18ms
> 11:21:52,387 INFO  [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS018558: Undeployed "msginflow_mdb.ear" (runtime-name: "msginflow_mdb.ear")
> {noformat}
> The 'null' part of the .jar undeployment doesn't look nice.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  2 11:39:02 2013
From: jira-events at lists.jboss.org (Eric Wittmann (JIRA))
Date: Wed, 2 Oct 2013 11:39:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-194) Add support in KIE to
 register custom Wagons
In-Reply-To: <JIRA.12496882.1374227726000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496882.1374227726000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496882.1374227726000.10787.1380728342859@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808991#comment-12808991 ] 

Eric Wittmann commented on DROOLS-194:
--------------------------------------

I should also point out that we actually use a proxy class instead of the core SrampWagon class.  The reason is that the Logger is not injected into the wagon when running in this environment (due to how Aether is creating the wagon, presumably).

It might be worth considering how injection might be supported in this context.
                
> Add support in KIE to register custom Wagons
> --------------------------------------------
>
>                 Key: DROOLS-194
>                 URL: https://issues.jboss.org/browse/DROOLS-194
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Kurt Stam
>            Assignee: Mark Proctor
>         Attachments: kie-srampwagon.tgz
>
>
> The ManualWagonProvider subclass of Aether in KIE registers the HTTPWagon. It should be possible to add your own Wagon through config our automated machinery when another Wagon is put on the classpath and references in the build/extensions of a MavenProject. To get the SrampWagon to work we used the following code:
> {quote}
> private static class ManualWagonProvider implements WagonProvider {
>         public Wagon lookup( String roleHint ) throws Exception {
>             if ( "http".equals( roleHint ) ) {
>                 return new AhcWagon();
>             }
>             if ( "sramp".equals( roleHint ) ) {
>                 return new SrampWagon();
>             }
>             return null;
>         }
>         public void release( Wagon wagon ) { }
>     }
> {quote}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  2 11:47:03 2013
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Wed, 2 Oct 2013 11:47:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1736) CommandLineArgumentUsage
 class substring value discarded
In-Reply-To: <JIRA.12497088.1374523551000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497088.1374523551000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497088.1374523551000.10815.1380728823139@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky updated WFLY-1736:
------------------------------------

       Assignee: Brian Stansberry  (was: Alexey Loubyansky)
    Component/s: Domain Management
                     (was: CLI)

    
> CommandLineArgumentUsage class substring value discarded
> --------------------------------------------------------
>
>                 Key: WFLY-1736
>                 URL: https://issues.jboss.org/browse/WFLY-1736
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Cheng Fang
>            Assignee: Brian Stansberry
>
> CommandLineArgumentUsage class has a substring call but return value discarded:
> {code}
> if( input.get(0).length() > width ){
>                     String tooLong = input.remove(0);
>                     tooLong.substring(0, width-5);
>                     input.add("Command removed. Too long.");
>                 }
> {code}
> FindBugs also finds a static field should be final:
> {code}
> protected static List<String> instructions = new ArrayList<String>();
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  2 12:08:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Wed, 2 Oct 2013 12:08:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2203) Error deploying multiple
	*-ds.xml files
In-Reply-To: <JIRA.12502011.1380723512000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502011.1380723512000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502011.1380723512000.10857.1380730082717@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas updated WFLY-2203:
---------------------------------

       Assignee: Jesper Pedersen
    Component/s: JCA

    
> Error deploying multiple *-ds.xml files
> ---------------------------------------
>
>                 Key: WFLY-2203
>                 URL: https://issues.jboss.org/browse/WFLY-2203
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Nick Howes
>            Assignee: Jesper Pedersen
>
> Our individual *-ds.xml datasources were all deploying fine in Alpha4 but in the Beta1 nightlies this error appears on startup:
> {noformat}
> 15:07:52,111 ERROR [org.jboss.msc.service] (MSC service thread 1-4) MSC000002: Invocation of listener "org.jboss.as.connector.subsystems.datasources.D
> ataSourceStatisticsListener at 7d18ac99" failed: java.lang.IllegalArgumentException: JBAS014742: A node is already registered at '(deployment => *)(subsy
> stem => datasources)(data-source => *)(statistics => jdbc)'
>         at org.jboss.as.controller.registry.NodeSubregistry.register(NodeSubregistry.java:86) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1
> -SNAPSHOT]
>         at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:149) [wildfly-controller-8
> .0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
>         at org.jboss.as.controller.registry.AbstractResourceRegistration.registerSubModel(AbstractResourceRegistration.java:90) [wildfly-controller-8.
> 0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
>         at org.jboss.as.connector.subsystems.datasources.DataSourceStatisticsListener.transition(DataSourceStatisticsListener.java:72) [wildfly-connec
> tor-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
>         at org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1533) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> {noformat}
> Our datasource files look like this. I haven't tried putting all the datasource elements into one file.
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <datasources>
>   <datasource jndi-name="java:/AlphaDS" enabled="true" use-java-context="true" pool-name="AlphaDS">
>     <connection-url>jdbc:oracle:thin://@db-host:1666/dev-db</connection-url> 
>     <driver>oracle</driver>
>     <security>
>       <user-name>XXX</user-name>
>       <password>YYY</password>
>     </security>
>     <connection-property name="defaultNChar">true</connection-property>
>   </datasource>
> </datasources>
> {code}
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <datasources>
>   <datasource jndi-name="java:/BetaDS" enabled="true" use-java-context="true" pool-name="BetaDS">
>     <connection-url>jdbc:oracle:thin://@db-host:1666/dev-db</connection-url> 
>     <driver>oracle</driver>
>     <security>
>       <user-name>XXX</user-name>
>       <password>YYY</password>
>     </security>
>     <connection-property name="defaultNChar">true</connection-property>
>   </datasource>
> </datasources>
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  2 12:10:02 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 2 Oct 2013 12:10:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2203) Error deploying multiple
	*-ds.xml files
In-Reply-To: <JIRA.12502011.1380723512000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502011.1380723512000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502011.1380723512000.10866.1380730202823@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated WFLY-2203:
----------------------------------

    Fix Version/s: 8.0.0.Final
         Priority: Minor  (was: Major)
         Assignee: Stefano Maestri  (was: Jesper Pedersen)

    
> Error deploying multiple *-ds.xml files
> ---------------------------------------
>
>                 Key: WFLY-2203
>                 URL: https://issues.jboss.org/browse/WFLY-2203
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Nick Howes
>            Assignee: Stefano Maestri
>            Priority: Minor
>             Fix For: 8.0.0.Final
>
>
> Our individual *-ds.xml datasources were all deploying fine in Alpha4 but in the Beta1 nightlies this error appears on startup:
> {noformat}
> 15:07:52,111 ERROR [org.jboss.msc.service] (MSC service thread 1-4) MSC000002: Invocation of listener "org.jboss.as.connector.subsystems.datasources.D
> ataSourceStatisticsListener at 7d18ac99" failed: java.lang.IllegalArgumentException: JBAS014742: A node is already registered at '(deployment => *)(subsy
> stem => datasources)(data-source => *)(statistics => jdbc)'
>         at org.jboss.as.controller.registry.NodeSubregistry.register(NodeSubregistry.java:86) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1
> -SNAPSHOT]
>         at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:149) [wildfly-controller-8
> .0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
>         at org.jboss.as.controller.registry.AbstractResourceRegistration.registerSubModel(AbstractResourceRegistration.java:90) [wildfly-controller-8.
> 0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
>         at org.jboss.as.connector.subsystems.datasources.DataSourceStatisticsListener.transition(DataSourceStatisticsListener.java:72) [wildfly-connec
> tor-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
>         at org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1533) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> {noformat}
> Our datasource files look like this. I haven't tried putting all the datasource elements into one file.
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <datasources>
>   <datasource jndi-name="java:/AlphaDS" enabled="true" use-java-context="true" pool-name="AlphaDS">
>     <connection-url>jdbc:oracle:thin://@db-host:1666/dev-db</connection-url> 
>     <driver>oracle</driver>
>     <security>
>       <user-name>XXX</user-name>
>       <password>YYY</password>
>     </security>
>     <connection-property name="defaultNChar">true</connection-property>
>   </datasource>
> </datasources>
> {code}
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <datasources>
>   <datasource jndi-name="java:/BetaDS" enabled="true" use-java-context="true" pool-name="BetaDS">
>     <connection-url>jdbc:oracle:thin://@db-host:1666/dev-db</connection-url> 
>     <driver>oracle</driver>
>     <security>
>       <user-name>XXX</user-name>
>       <password>YYY</password>
>     </security>
>     <connection-property name="defaultNChar">true</connection-property>
>   </datasource>
> </datasources>
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  2 12:30:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Wed, 2 Oct 2013 12:30:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2206) Manualmode test suite copes
 the modules directory multiple times
In-Reply-To: <JIRA.12502031.1380731391735@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502031.1380731391735@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502031.1380731391735.10910.1380731402537@jira02.app.mwc.hst.phx2.redhat.com>

Stuart Douglas created WFLY-2206:
------------------------------------

             Summary: Manualmode test suite copes the modules directory multiple times
                 Key: WFLY-2206
                 URL: https://issues.jboss.org/browse/WFLY-2206
             Project: WildFly
          Issue Type: Bug
          Components: Test Suite
    Affects Versions: 8.0.0.Alpha4
            Reporter: Stuart Douglas
            Assignee: Stuart Douglas


This uses lots of disk space for no good reason

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  2 12:36:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 2 Oct 2013 12:36:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2206) Manualmode test suite copes
 the modules directory multiple times
In-Reply-To: <JIRA.12502031.1380731391000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502031.1380731391000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502031.1380731391000.10919.1380731762561@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809008#comment-12809008 ] 

RH Bugzilla Integration commented on WFLY-2206:
-----------------------------------------------

Stuart Douglas <sdouglas at redhat.com> made a comment on [bug 1014742|https://bugzilla.redhat.com/show_bug.cgi?id=1014742]

Description of problem:

In the testsuite the mutimode tests copy the modules directory multiple times. This uses lots of disk space and slows down CI runs.
                
> Manualmode test suite copes the modules directory multiple times
> ----------------------------------------------------------------
>
>                 Key: WFLY-2206
>                 URL: https://issues.jboss.org/browse/WFLY-2206
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>
> This uses lots of disk space for no good reason

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  2 12:36:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 2 Oct 2013 12:36:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2206) Manualmode test suite copes
 the modules directory multiple times
In-Reply-To: <JIRA.12502031.1380731391000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502031.1380731391000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502031.1380731391000.10921.1380731762677@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2206:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1014742

    
> Manualmode test suite copes the modules directory multiple times
> ----------------------------------------------------------------
>
>                 Key: WFLY-2206
>                 URL: https://issues.jboss.org/browse/WFLY-2206
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>
> This uses lots of disk space for no good reason

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  2 12:42:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 2 Oct 2013 12:42:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2194) Difficulty Enabling SSL for
 Management Interfaces Using CLI
In-Reply-To: <JIRA.12501945.1380647585000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501945.1380647585000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501945.1380647585000.10942.1380732122654@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809011#comment-12809011 ] 

Darran Lofthouse commented on WFLY-2194:
----------------------------------------

The 'NativeManagementWriteAttributeHandler' which was previously the default entry point for the CLI required a reload so the 'HttpManagementWriteAttributeHandler' should be updated to match.
                
> Difficulty Enabling SSL for Management Interfaces Using CLI
> -----------------------------------------------------------
>
>                 Key: WFLY-2194
>                 URL: https://issues.jboss.org/browse/WFLY-2194
>             Project: WildFly
>          Issue Type: Task
>          Components: CLI, Domain Management, Security
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Beta1
>
>
> Trying to enable the HTTPS port for the HTTP management interface using the CLI results in the following: -
> {code}
> [standalone at localhost:9990 /] ./core-service=management/management-interface=http-interface:write-attribute(name=secure-socket-binding, value=management-https)
> Communication error: java.util.concurrent.ExecutionException: Operation failed: Operation failed: Channel closed
> {code}
> Server side the following is logged: -
> {code}
> 17:59:54,193 INFO  [org.jboss.as.server] (management-handler-thread - 4) JBAS015890: Creating http management service using socket-binding (management-http) and secure-socket-binding (management-https)
> 17:59:54,212 INFO  [org.jboss.as.server] (management-handler-thread - 4) JBAS015888: Creating http management service using socket-binding (management-http)
> 17:59:54,236 WARN  [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014626: Operation was interrupted before stability could be reached
> {code}
> i.e. What appears to be happening is that as communication is lost with the client the update is being detected as a failure.
> As interface updates do result in restarting the services used to make the updates it may be better to switch these to reload required updates instead of being immediate - also the chances are that security realm updates would be made simultaneously and those also require a reload.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  2 12:44:03 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 2 Oct 2013 12:44:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2200) NoSuchElementException after
 upgrade from Beta13 to Beta14
In-Reply-To: <JIRA.12501981.1380704605000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501981.1380704605000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501981.1380704605000.10954.1380732243069@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar resolved WFLY-2200.
-------------------------------

    Resolution: Done

    
> NoSuchElementException after upgrade from Beta13 to Beta14
> ----------------------------------------------------------
>
>                 Key: WFLY-2200
>                 URL: https://issues.jboss.org/browse/WFLY-2200
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Juergen Zimmermann
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Beta1
>
>
> I just switched to a newer WildFly snapshot having Undertow 1.0.0.Beta14. But I'm getting the following stacktrace caused by HttpServletRequestImpl.getParameterNames(). This error didn't happen with 1.0.0.Beta13.
> {code}
> SEVERE [javax.enterprise.resource.webcontainer.jsf.application] (default task-45) Error Rendering View[/index.xhtml]: java.util.NoSuchElementException
> 	at java.util.HashMap$HashIterator.nextEntry(HashMap.java:929) [rt.jar:1.7.0_40]
> 	at java.util.HashMap$KeyIterator.next(HashMap.java:960) [rt.jar:1.7.0_40]
> 	at io.undertow.servlet.spec.HttpServletRequestImpl.getParameterNames(HttpServletRequestImpl.java:605) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at com.sun.faces.context.RequestParameterMap.getEntryIterator(RequestParameterMap.java:126) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.context.BaseContextMap$EntrySet.iterator(BaseContextMap.java:166) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.context.BaseContextMap$BaseSet.size(BaseContextMap.java:154) [jsf-impl-2.1.26.jar:2.1.26]
> 	at java.util.Collections$UnmodifiableCollection.size(Collections.java:1055) [rt.jar:1.7.0_40]
> 	at java.util.AbstractMap.size(AbstractMap.java:84) [rt.jar:1.7.0_40]
> 	at java.util.AbstractMap.isEmpty(AbstractMap.java:93) [rt.jar:1.7.0_40]
> 	at java.util.Collections$UnmodifiableMap.isEmpty(Collections.java:1336) [rt.jar:1.7.0_40]
> 	at com.sun.faces.facelets.util.DevTools.writeVariables(DevTools.java:330) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.facelets.util.DevTools.writeVariables(DevTools.java:199) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.facelets.util.DevTools.debugHtml(DevTools.java:186) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.facelets.tag.ui.UIDebug.writeDebugOutput(UIDebug.java:140) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.facelets.tag.ui.UIDebug.encodeBegin(UIDebug.java:122) [jsf-impl-2.1.26.jar:2.1.26]
> 	at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1817) [jsf-api-2.1.26.jar:2.1]
> 	at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1822) [jsf-api-2.1.26.jar:2.1]
> 	at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1822) [jsf-api-2.1.26.jar:2.1]
> 	at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:447) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:125) [jsf-impl-2.1.26.jar:2.1.26]
> 	at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:286) [jsf-api-2.1.26.jar:2.1]
> 	at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:286) [jsf-api-2.1.26.jar:2.1]
> 	at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:286) [jsf-api-2.1.26.jar:2.1]
> 	at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139) [jsf-impl-2.1.26.jar:2.1.26]
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594) [jsf-api-2.1.26.jar:2.1]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:93) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:55) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:209) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:196) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:130) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:614) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  2 12:44:03 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 2 Oct 2013 12:44:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2200) NoSuchElementException after
 upgrade from Beta13 to Beta14
In-Reply-To: <JIRA.12501981.1380704605000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501981.1380704605000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501981.1380704605000.10965.1380732243580@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809014#comment-12809014 ] 

Tomaz Cerar commented on WFLY-2200:
-----------------------------------

Fixed in Undertow Beta 16
                
> NoSuchElementException after upgrade from Beta13 to Beta14
> ----------------------------------------------------------
>
>                 Key: WFLY-2200
>                 URL: https://issues.jboss.org/browse/WFLY-2200
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Juergen Zimmermann
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Beta1
>
>
> I just switched to a newer WildFly snapshot having Undertow 1.0.0.Beta14. But I'm getting the following stacktrace caused by HttpServletRequestImpl.getParameterNames(). This error didn't happen with 1.0.0.Beta13.
> {code}
> SEVERE [javax.enterprise.resource.webcontainer.jsf.application] (default task-45) Error Rendering View[/index.xhtml]: java.util.NoSuchElementException
> 	at java.util.HashMap$HashIterator.nextEntry(HashMap.java:929) [rt.jar:1.7.0_40]
> 	at java.util.HashMap$KeyIterator.next(HashMap.java:960) [rt.jar:1.7.0_40]
> 	at io.undertow.servlet.spec.HttpServletRequestImpl.getParameterNames(HttpServletRequestImpl.java:605) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at com.sun.faces.context.RequestParameterMap.getEntryIterator(RequestParameterMap.java:126) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.context.BaseContextMap$EntrySet.iterator(BaseContextMap.java:166) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.context.BaseContextMap$BaseSet.size(BaseContextMap.java:154) [jsf-impl-2.1.26.jar:2.1.26]
> 	at java.util.Collections$UnmodifiableCollection.size(Collections.java:1055) [rt.jar:1.7.0_40]
> 	at java.util.AbstractMap.size(AbstractMap.java:84) [rt.jar:1.7.0_40]
> 	at java.util.AbstractMap.isEmpty(AbstractMap.java:93) [rt.jar:1.7.0_40]
> 	at java.util.Collections$UnmodifiableMap.isEmpty(Collections.java:1336) [rt.jar:1.7.0_40]
> 	at com.sun.faces.facelets.util.DevTools.writeVariables(DevTools.java:330) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.facelets.util.DevTools.writeVariables(DevTools.java:199) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.facelets.util.DevTools.debugHtml(DevTools.java:186) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.facelets.tag.ui.UIDebug.writeDebugOutput(UIDebug.java:140) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.facelets.tag.ui.UIDebug.encodeBegin(UIDebug.java:122) [jsf-impl-2.1.26.jar:2.1.26]
> 	at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1817) [jsf-api-2.1.26.jar:2.1]
> 	at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1822) [jsf-api-2.1.26.jar:2.1]
> 	at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1822) [jsf-api-2.1.26.jar:2.1]
> 	at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:447) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:125) [jsf-impl-2.1.26.jar:2.1.26]
> 	at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:286) [jsf-api-2.1.26.jar:2.1]
> 	at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:286) [jsf-api-2.1.26.jar:2.1]
> 	at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:286) [jsf-api-2.1.26.jar:2.1]
> 	at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139) [jsf-impl-2.1.26.jar:2.1.26]
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594) [jsf-api-2.1.26.jar:2.1]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:93) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:55) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:209) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:196) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:130) [undertow-servlet-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:614) [undertow-core-1.0.0.Beta14.jar:1.0.0.Beta14]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  2 12:51:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Wed, 2 Oct 2013 12:51:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-194) Add support in KIE to
 register custom Wagons
In-Reply-To: <JIRA.12496882.1374227726000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496882.1374227726000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496882.1374227726000.10983.1380732662744@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-194:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> Add support in KIE to register custom Wagons
> --------------------------------------------
>
>                 Key: DROOLS-194
>                 URL: https://issues.jboss.org/browse/DROOLS-194
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Kurt Stam
>            Assignee: Mario Fusco
>         Attachments: kie-srampwagon.tgz
>
>
> The ManualWagonProvider subclass of Aether in KIE registers the HTTPWagon. It should be possible to add your own Wagon through config our automated machinery when another Wagon is put on the classpath and references in the build/extensions of a MavenProject. To get the SrampWagon to work we used the following code:
> {quote}
> private static class ManualWagonProvider implements WagonProvider {
>         public Wagon lookup( String roleHint ) throws Exception {
>             if ( "http".equals( roleHint ) ) {
>                 return new AhcWagon();
>             }
>             if ( "sramp".equals( roleHint ) ) {
>                 return new SrampWagon();
>             }
>             return null;
>         }
>         public void release( Wagon wagon ) { }
>     }
> {quote}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  2 12:53:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Wed, 2 Oct 2013 12:53:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-194) Add support in KIE to
 register custom Wagons
In-Reply-To: <JIRA.12496882.1374227726000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496882.1374227726000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496882.1374227726000.10988.1380732782596@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-194.
--------------------------------

    Fix Version/s: 6.0.0.CR5
       Resolution: Done

    
> Add support in KIE to register custom Wagons
> --------------------------------------------
>
>                 Key: DROOLS-194
>                 URL: https://issues.jboss.org/browse/DROOLS-194
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Kurt Stam
>            Assignee: Mario Fusco
>             Fix For: 6.0.0.CR5
>
>         Attachments: kie-srampwagon.tgz
>
>
> The ManualWagonProvider subclass of Aether in KIE registers the HTTPWagon. It should be possible to add your own Wagon through config our automated machinery when another Wagon is put on the classpath and references in the build/extensions of a MavenProject. To get the SrampWagon to work we used the following code:
> {quote}
> private static class ManualWagonProvider implements WagonProvider {
>         public Wagon lookup( String roleHint ) throws Exception {
>             if ( "http".equals( roleHint ) ) {
>                 return new AhcWagon();
>             }
>             if ( "sramp".equals( roleHint ) ) {
>                 return new SrampWagon();
>             }
>             return null;
>         }
>         public void release( Wagon wagon ) { }
>     }
> {quote}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  2 12:57:02 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 2 Oct 2013 12:57:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2206) Manualmode test suite copes
 the modules directory multiple times
In-Reply-To: <JIRA.12502031.1380731391000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502031.1380731391000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502031.1380731391000.11001.1380733022758@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar reassigned WFLY-2206:
---------------------------------

    Assignee: Tomaz Cerar  (was: Stuart Douglas)

    
> Manualmode test suite copes the modules directory multiple times
> ----------------------------------------------------------------
>
>                 Key: WFLY-2206
>                 URL: https://issues.jboss.org/browse/WFLY-2206
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Stuart Douglas
>            Assignee: Tomaz Cerar
>
> This uses lots of disk space for no good reason

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  2 13:36:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 2 Oct 2013 13:36:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2207) CLI Unable to connect using
 https-remoting address.
In-Reply-To: <JIRA.12502036.1380735356821@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502036.1380735356821@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502036.1380735356821.11049.1380735362593@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-2207:
--------------------------------------

             Summary: CLI Unable to connect using https-remoting address.
                 Key: WFLY-2207
                 URL: https://issues.jboss.org/browse/WFLY-2207
             Project: WildFly
          Issue Type: Bug
          Components: CLI
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
            Priority: Critical
             Fix For: 8.0.0.Beta1


The CLI is failing to connect over https with the following: -

{code}
[disconnected /] connect https-remoting://localhost:9993
The controller is not available at localhost:9993: java.net.ConnectException: JBAS012144: Could not connect to https-remoting://localhost:9993. The connection timed out: JBAS012144: Could not connect to https-remoting://localhost:9993. The connection timed out
{code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  2 13:54:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 2 Oct 2013 13:54:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2208) CLI over HTTP should switch
 to / be redirected to https automatically.
In-Reply-To: <JIRA.12502037.1380736411850@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502037.1380736411850@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502037.1380736411850.11057.1380736442655@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-2208:
--------------------------------------

             Summary: CLI over HTTP should switch to / be redirected to https automatically.
                 Key: WFLY-2208
                 URL: https://issues.jboss.org/browse/WFLY-2208
             Project: WildFly
          Issue Type: Enhancement
          Components: CLI, Domain Management
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 8.0.0.Beta1


When using the native interface a TLS upgrade was already automatically in place once a keystore was added to the linked realm.

With the switch to http with an upgrade there is no automatic switch to https.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  2 14:28:02 2013
From: jira-events at lists.jboss.org (Ramesh Kodali (JIRA))
Date: Wed, 2 Oct 2013 14:28:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBAS-9548) JBoss 5.0 log file is stopped
 getting updated after a while
In-Reply-To: <JIRA.12502038.1380738396651@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502038.1380738396651@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502038.1380738396651.11083.1380738482531@jira02.app.mwc.hst.phx2.redhat.com>

Ramesh Kodali created JBAS-9548:
-----------------------------------

             Summary: JBoss 5.0 log file is stopped getting updated after a while
                 Key: JBAS-9548
                 URL: https://issues.jboss.org/browse/JBAS-9548
             Project: Application Server 3  4  5 and 6
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Web Services
    Affects Versions: JBossAS-5.0.1.GA
         Environment: Java 2.6, JBoss 5.1
            Reporter: Ramesh Kodali
            Assignee: Alessio Soldano


We are using log back xml to configure application specific log file and copied the log back XML in JBoss class path. After server restarts, JBoss is generating the log files successfully.  It was working from some time even in production.  Recently we have noticed a weird issue in our dev environment that,  application logs are writing in to log file and stopped writing after a while.  We have to restart the JBoss to get back the Log files status.  This issue seems coming continuously now a days.  I would like to know is it some thing related to JBoss or more of environment issue.

Here below the log back configuration we had

<appender name="FILE"
		class="ch.qos.logback.core.rolling.RollingFileAppender">
		<File>${jboss.server.log.dir}/cbs2.log</File>
		<Append>true</Append>

		<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
			<FileNamePattern>${jboss.server.log.dir}/cbs2.%d{yyyy-MM-dd}.%i.log.gz
			</FileNamePattern>
			<timeBasedFileNamingAndTriggeringPolicy
				class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP">
				<maxFileSize>200MB</maxFileSize>
			</timeBasedFileNamingAndTriggeringPolicy>
		</rollingPolicy>

		<layout class="ch.qos.logback.classic.PatternLayout">
			<Pattern>%d{yyyy-MM-dd;HH:mm:ss.SSS} [%thread] %-5level %logger{36} [%M:%L]
				[%X{id}->%X{bcId}:%X{userId}:%X{loginId}] - %msg%n</Pattern>
		</layout>
	</appender>



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  2 18:44:02 2013
From: jira-events at lists.jboss.org (=?UTF-8?Q?Mat=C3=ADas_Blasi_=28JIRA=29?=)
Date: Wed, 2 Oct 2013 18:44:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBASMP-52) jboss-as:deploy deploys ear
 but doesn't deploy contained ejb module
In-Reply-To: <JIRA.12502059.1380753826114@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502059.1380753826114@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502059.1380753826114.11326.1380753842572@jira02.app.mwc.hst.phx2.redhat.com>

Mat?as Blasi created JBASMP-52:
----------------------------------

             Summary: jboss-as:deploy deploys ear but doesn't deploy contained ejb module
                 Key: JBASMP-52
                 URL: https://issues.jboss.org/browse/JBASMP-52
             Project: JBoss AS Maven Plugins
          Issue Type: Bug
          Components: deploy
    Affects Versions: 7.4.Final
         Environment: Linux hostname 3.7.10-gentoo #1 SMP Fri Aug 30 17:01:59 ART 2013 x86_64 Intel(R) Core(TM) i5-2467M CPU @ 1.60GHz GenuineIntel GNU/Linux
            Reporter: Mat?as Blasi
            Assignee: James Perkins


I have a simple ear application (build with maven-ear-plugin).
This application contains just a persistence-unit definition (persistence.xml) and a ejb-module.
The ejb module is another maven build, containing some ejb3, handled with maven-ejb-plugin.

The ear file is correctly built:

myapp.ear
|
+ META-INF/application.xml
+ lib/allmylibs.jar
+ myejb.jar

When trying to deploy the ear with the jboss-as:deploy, the application is deployed (the persistence unit deployment logs in server.log), but no ejb is registered, anyway, no errors in log, and BUILD SUCCESFUL after mvn command.

Finally, an ear file is present under $JBOSS_HOME/standalone/data/content

The strange thing is that if I get that generated ear file, I can succesfully deploy it through the management console, or by copying it to a folder scanned by a deployment-scanner (in both cases the ejbs are correctly deployed)

Nothing found in google! :(

I tried with all the plugin version from 7.1.1 to 7.4.
Also a lot of tries with different maven-ear-plugin and maven-jboss-as-plugin configuration options.... no lucky after two days of work.

Regards,
Mat?as.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Wed Oct  2 18:46:02 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Wed, 2 Oct 2013 18:46:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-279) Implement automatic
 retraction policies other than temporal expiration
In-Reply-To: <JIRA.12502060.1380753914129@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502060.1380753914129@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502060.1380753914129.11327.1380753962823@jira02.app.mwc.hst.phx2.redhat.com>

Davide Sottara created DROOLS-279:
-------------------------------------

             Summary: Implement automatic retraction policies other than temporal expiration
                 Key: DROOLS-279
                 URL: https://issues.jboss.org/browse/DROOLS-279
             Project: Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions:  6.0.0.CR4, 5.5.1.Final
            Reporter: Davide Sottara
            Assignee: Mark Proctor
            Priority: Minor


Retract events automatically when the only potentially matching patterns
are connected to sliding length windows

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  2 21:45:03 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Wed, 2 Oct 2013 21:45:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2136) persistence.xml with
 org.hibernate.ejb.HibernatePersistence should deploy with Hibernate ORM
 4.3.x
In-Reply-To: <JIRA.12501326.1379954479000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501326.1379954479000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501326.1379954479000.11348.1380764703153@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow closed WFLY-2136.
------------------------------


    
> persistence.xml with org.hibernate.ejb.HibernatePersistence should deploy with Hibernate ORM 4.3.x
> --------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2136
>                 URL: https://issues.jboss.org/browse/WFLY-2136
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 8.0.0.CR1
>
>
> currently users migrating from earlier app server versions will get http://pastebin.com/4tRk75vh

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct  3 02:03:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 3 Oct 2013 02:03:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1712) FRAG / FRAG2: CONFIG event
 overrides user-configured frag_size value
In-Reply-To: <JIRA.12502064.1380780130138@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502064.1380780130138@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502064.1380780130138.11377.1380780182534@jira02.app.mwc.hst.phx2.redhat.com>

Bela Ban created JGRP-1712:
------------------------------

             Summary: FRAG / FRAG2: CONFIG event overrides user-configured frag_size value
                 Key: JGRP-1712
                 URL: https://issues.jboss.org/browse/JGRP-1712
             Project: JGroups
          Issue Type: Bug
            Reporter: Bela Ban
            Assignee: Bela Ban
            Priority: Minor
             Fix For: 3.4


When we have multiple FRAG or FRAG2 in the same stack (with different IDs), then each fragmentation protocol sends a CONFIG event (with {{frag_size}}) up and down the stack. When this event is received by a different frag protocol, then it will set its own {{frag_size}}, overriding the previously set value.
Investigate whether we still need the CONFIG event.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct  3 02:36:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 3 Oct 2013 02:36:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1913) CLI 'module add' command fail
 if a drive letter is specified in its resource path
In-Reply-To: <JIRA.12499050.1377075768000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499050.1377075768000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499050.1377075768000.11390.1380782162702@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-1913:
------------------------------------------

    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=991469, https://bugzilla.redhat.com/show_bug.cgi?id=1014921  (was: https://bugzilla.redhat.com/show_bug.cgi?id=991469)

    
> CLI 'module add' command fail if a drive letter is specified in its resource path
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-1913
>                 URL: https://issues.jboss.org/browse/WFLY-1913
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>             Fix For: 8.0.0.Beta1
>
>         Attachments: install-mojarra-2.0.0.cli
>
>
> If a drive letter is specified in the resource path the module add command fails on MS Windows. It cannot locate such a resource because of doubled drive letter in the translated path.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct  3 02:36:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 3 Oct 2013 02:36:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1913) CLI 'module add' command fail
 if a drive letter is specified in its resource path
In-Reply-To: <JIRA.12499050.1377075768000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499050.1377075768000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499050.1377075768000.11392.1380782162969@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809091#comment-12809091 ] 

RH Bugzilla Integration commented on WFLY-1913:
-----------------------------------------------

Ivo Studensky <istudens at redhat.com> made a comment on [bug 1014921|https://bugzilla.redhat.com/show_bug.cgi?id=1014921]

Description of problem:
A regression has been introduced by the bz991469 fix. It breaks module add command included in a CLI module archive. For details see

https://issues.jboss.org/browse/WFLY-1913?focusedCommentId=12808246&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12808246

Version-Release number of selected component (if applicable):
EAP 6.2.0.ER1

How reproducible:
Create a CLI module archive which includes 'module add' command involving a resource taken from the module archive. An example of such an archive can be found at WFLY-1913.
                
> CLI 'module add' command fail if a drive letter is specified in its resource path
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-1913
>                 URL: https://issues.jboss.org/browse/WFLY-1913
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>             Fix For: 8.0.0.Beta1
>
>         Attachments: install-mojarra-2.0.0.cli
>
>
> If a drive letter is specified in the resource path the module add command fails on MS Windows. It cannot locate such a resource because of doubled drive letter in the translated path.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct  3 02:36:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 3 Oct 2013 02:36:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1913) CLI 'module add' command fail
 if a drive letter is specified in its resource path
In-Reply-To: <JIRA.12499050.1377075768000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499050.1377075768000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499050.1377075768000.11398.1380782163708@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809092#comment-12809092 ] 

RH Bugzilla Integration commented on WFLY-1913:
-----------------------------------------------

Ivo Studensky <istudens at redhat.com> changed the Status of [bug 1014921|https://bugzilla.redhat.com/show_bug.cgi?id=1014921] from NEW to ASSIGNED
                
> CLI 'module add' command fail if a drive letter is specified in its resource path
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-1913
>                 URL: https://issues.jboss.org/browse/WFLY-1913
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>             Fix For: 8.0.0.Beta1
>
>         Attachments: install-mojarra-2.0.0.cli
>
>
> If a drive letter is specified in the resource path the module add command fails on MS Windows. It cannot locate such a resource because of doubled drive letter in the translated path.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct  3 03:33:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Thu, 3 Oct 2013 03:33:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-275) RuleEngine
 AfterEvaluator.evaluateCachedRight throws NPE on persisted Session reload
 (Phreak, Stream, PseudoClock)
In-Reply-To: <JIRA.12501735.1380283896000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501735.1380283896000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501735.1380283896000.11495.1380785582627@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-275:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> RuleEngine AfterEvaluator.evaluateCachedRight throws NPE on persisted Session reload (Phreak, Stream, PseudoClock)
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-275
>                 URL: https://issues.jboss.org/browse/DROOLS-275
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR3
>         Environment: Mac OS-X 10.8.5, Hotspot 1.7.0_40
>            Reporter: Duncan Doyle
>            Assignee: Mario Fusco
>
> I persist a KieSession via the Marshaller (serializable) with one fact/event inserted. On reload of the session, I can see that fact is still there (when I check the FactHandles) and the PseudoClock is at the correct time (the time when I persisted it). If I then insert another fact/event into this reloaded session which matches the following rule:
> rule "SimpleFactTimeWindow"
> when
> 	$s1: SimpleFact() from entry-point LinkyStream
> 	$s2: SimpleFact(this != $s1, this after [0s, 10s] $s1) from entry-point LinkyStream
> then
> 	System.out.println("Rule fired, found 2 Facts within the time window.");
> end
> I get a NPE (in both Phreak and ReteOO mode). Exception in Phreak:
> java.lang.reflect.InvocationTargetException
> 	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.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297)
> 	at java.lang.Thread.run(Thread.java:724)
> Caused by: java.lang.NullPointerException
> 	at org.drools.core.base.evaluators.AfterEvaluatorDefinition$AfterEvaluator.evaluateCachedRight(AfterEvaluatorDefinition.java:304)
> 	at org.drools.core.rule.constraint.EvaluatorConstraint.isAllowedCachedRight(EvaluatorConstraint.java:80)
> 	at org.drools.core.common.DoubleBetaConstraints.isAllowedCachedRight(DoubleBetaConstraints.java:117)
> 	at org.drools.core.phreak.PhreakJoinNode.doRightInserts(PhreakJoinNode.java:150)
> 	at org.drools.core.phreak.PhreakJoinNode.doNode(PhreakJoinNode.java:56)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:547)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:533)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:335)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:162)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:117)
> 	at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194)
> 	at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:65)
> 	at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:936)
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1183)
> 	at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:936)
> 	at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:910)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:233)
> 	at org.jboss.ddoyle.brms.cep.ha.management.TestScenarioRunner.secondRun(TestScenarioRunner.java:142)
> 	at org.jboss.ddoyle.brms.cep.ha.management.MainSecondRun.main(MainSecondRun.java:7)
> 	... 6 more
> Exception in ReteOO:
> java.lang.reflect.InvocationTargetException
> 	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.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297)
> 	at java.lang.Thread.run(Thread.java:724)
> Caused by: org.drools.core.RuntimeDroolsException: Unexpected exception executing action org.drools.core.reteoo.PropagationQueuingNode$PropagateAction at 2e3aeda
> 	at org.drools.core.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1225)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:371)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:278)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:131)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:56)
> 	at org.jboss.ddoyle.brms.cep.ha.management.TestScenarioRunner.secondRun(TestScenarioRunner.java:140)
> 	at org.jboss.ddoyle.brms.cep.ha.management.MainSecondRun.main(MainSecondRun.java:7)
> 	... 6 more
> Caused by: java.lang.NullPointerException
> 	at org.drools.core.base.evaluators.AfterEvaluatorDefinition$AfterEvaluator.evaluateCachedLeft(AfterEvaluatorDefinition.java:324)
> 	at org.drools.core.rule.constraint.EvaluatorConstraint.isAllowedCachedLeft(EvaluatorConstraint.java:67)
> 	at org.drools.core.common.DoubleBetaConstraints.isAllowedCachedLeft(DoubleBetaConstraints.java:108)
> 	at org.drools.reteoo.nodes.ReteJoinNode.propagateFromLeft(ReteJoinNode.java:147)
> 	at org.drools.reteoo.nodes.ReteJoinNode.assertLeftTuple(ReteJoinNode.java:99)
> 	at org.drools.core.reteoo.SingleLeftTupleSinkAdapter.doPropagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:213)
> 	at org.drools.core.reteoo.SingleLeftTupleSinkAdapter.propagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:73)
> 	at org.drools.reteoo.nodes.ReteJoinNode.propagateFromRight(ReteJoinNode.java:135)
> 	at org.drools.reteoo.nodes.ReteJoinNode.assertRightTuple(ReteJoinNode.java:125)
> 	at org.drools.reteoo.nodes.ReteBetaNodeUtils.assertObject(ReteBetaNodeUtils.java:47)
> 	at org.drools.reteoo.nodes.ReteJoinNode.assertObject(ReteJoinNode.java:39)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:502)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:387)
> 	at org.drools.core.reteoo.PropagationQueuingNode$AssertAction.execute(PropagationQueuingNode.java:430)
> 	at org.drools.core.reteoo.PropagationQueuingNode.propagateActions(PropagationQueuingNode.java:266)
> 	at org.drools.core.reteoo.PropagationQueuingNode$PropagateAction.execute(PropagationQueuingNode.java:592)
> 	at org.drools.core.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1223)
> 	... 12 more
> What I discovered is that this only happens when I save the KieSession to a file in one JVM and reload it in another. When I load the KieSession in the same JVM as the one in which I persisted it, there is no exception and the rule get's fired (as expected).
> I created a reproducer project for it: https://github.com/DuncanDoyle/DroolsSessionPersistenceNPE/
> I've added some Maven profiles so you can easily observe the behaviour:
> - mvn -PallRuns exec:java    : this runs both the persistence and the reload in the same JVM, no exception, everything works fine.
> - mvn -PfirstRun exec:java    : this runs the first part of the test, and saves the KieSession to a file.
> - mvn -PsecondRun exec:java   : this runs the second part of the test, which loads the previously saved KieSession from the file and inserts a new fact, resulting in the NPE.
> All three tests can also be run in ReteOO mode by adding "-Ddrools.ruleEngine=reteoo" at the end of the command.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct  3 03:41:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 3 Oct 2013 03:41:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-275) RuleEngine
 AfterEvaluator.evaluateCachedRight throws NPE on persisted Session reload
 (Phreak, Stream, PseudoClock)
In-Reply-To: <JIRA.12501735.1380283896000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501735.1380283896000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501735.1380283896000.11514.1380786062702@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809107#comment-12809107 ] 

RH Bugzilla Integration commented on DROOLS-275:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> made a comment on [bug 1013197|https://bugzilla.redhat.com/show_bug.cgi?id=1013197]

Fixed by https://github.com/droolsjbpm/drools/commit/fd644d3aa
                
> RuleEngine AfterEvaluator.evaluateCachedRight throws NPE on persisted Session reload (Phreak, Stream, PseudoClock)
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-275
>                 URL: https://issues.jboss.org/browse/DROOLS-275
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR3
>         Environment: Mac OS-X 10.8.5, Hotspot 1.7.0_40
>            Reporter: Duncan Doyle
>            Assignee: Mario Fusco
>
> I persist a KieSession via the Marshaller (serializable) with one fact/event inserted. On reload of the session, I can see that fact is still there (when I check the FactHandles) and the PseudoClock is at the correct time (the time when I persisted it). If I then insert another fact/event into this reloaded session which matches the following rule:
> rule "SimpleFactTimeWindow"
> when
> 	$s1: SimpleFact() from entry-point LinkyStream
> 	$s2: SimpleFact(this != $s1, this after [0s, 10s] $s1) from entry-point LinkyStream
> then
> 	System.out.println("Rule fired, found 2 Facts within the time window.");
> end
> I get a NPE (in both Phreak and ReteOO mode). Exception in Phreak:
> java.lang.reflect.InvocationTargetException
> 	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.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297)
> 	at java.lang.Thread.run(Thread.java:724)
> Caused by: java.lang.NullPointerException
> 	at org.drools.core.base.evaluators.AfterEvaluatorDefinition$AfterEvaluator.evaluateCachedRight(AfterEvaluatorDefinition.java:304)
> 	at org.drools.core.rule.constraint.EvaluatorConstraint.isAllowedCachedRight(EvaluatorConstraint.java:80)
> 	at org.drools.core.common.DoubleBetaConstraints.isAllowedCachedRight(DoubleBetaConstraints.java:117)
> 	at org.drools.core.phreak.PhreakJoinNode.doRightInserts(PhreakJoinNode.java:150)
> 	at org.drools.core.phreak.PhreakJoinNode.doNode(PhreakJoinNode.java:56)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:547)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:533)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:335)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:162)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:117)
> 	at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194)
> 	at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:65)
> 	at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:936)
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1183)
> 	at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:936)
> 	at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:910)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:233)
> 	at org.jboss.ddoyle.brms.cep.ha.management.TestScenarioRunner.secondRun(TestScenarioRunner.java:142)
> 	at org.jboss.ddoyle.brms.cep.ha.management.MainSecondRun.main(MainSecondRun.java:7)
> 	... 6 more
> Exception in ReteOO:
> java.lang.reflect.InvocationTargetException
> 	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.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297)
> 	at java.lang.Thread.run(Thread.java:724)
> Caused by: org.drools.core.RuntimeDroolsException: Unexpected exception executing action org.drools.core.reteoo.PropagationQueuingNode$PropagateAction at 2e3aeda
> 	at org.drools.core.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1225)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:371)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:278)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:131)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:56)
> 	at org.jboss.ddoyle.brms.cep.ha.management.TestScenarioRunner.secondRun(TestScenarioRunner.java:140)
> 	at org.jboss.ddoyle.brms.cep.ha.management.MainSecondRun.main(MainSecondRun.java:7)
> 	... 6 more
> Caused by: java.lang.NullPointerException
> 	at org.drools.core.base.evaluators.AfterEvaluatorDefinition$AfterEvaluator.evaluateCachedLeft(AfterEvaluatorDefinition.java:324)
> 	at org.drools.core.rule.constraint.EvaluatorConstraint.isAllowedCachedLeft(EvaluatorConstraint.java:67)
> 	at org.drools.core.common.DoubleBetaConstraints.isAllowedCachedLeft(DoubleBetaConstraints.java:108)
> 	at org.drools.reteoo.nodes.ReteJoinNode.propagateFromLeft(ReteJoinNode.java:147)
> 	at org.drools.reteoo.nodes.ReteJoinNode.assertLeftTuple(ReteJoinNode.java:99)
> 	at org.drools.core.reteoo.SingleLeftTupleSinkAdapter.doPropagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:213)
> 	at org.drools.core.reteoo.SingleLeftTupleSinkAdapter.propagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:73)
> 	at org.drools.reteoo.nodes.ReteJoinNode.propagateFromRight(ReteJoinNode.java:135)
> 	at org.drools.reteoo.nodes.ReteJoinNode.assertRightTuple(ReteJoinNode.java:125)
> 	at org.drools.reteoo.nodes.ReteBetaNodeUtils.assertObject(ReteBetaNodeUtils.java:47)
> 	at org.drools.reteoo.nodes.ReteJoinNode.assertObject(ReteJoinNode.java:39)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:502)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:387)
> 	at org.drools.core.reteoo.PropagationQueuingNode$AssertAction.execute(PropagationQueuingNode.java:430)
> 	at org.drools.core.reteoo.PropagationQueuingNode.propagateActions(PropagationQueuingNode.java:266)
> 	at org.drools.core.reteoo.PropagationQueuingNode$PropagateAction.execute(PropagationQueuingNode.java:592)
> 	at org.drools.core.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1223)
> 	... 12 more
> What I discovered is that this only happens when I save the KieSession to a file in one JVM and reload it in another. When I load the KieSession in the same JVM as the one in which I persisted it, there is no exception and the rule get's fired (as expected).
> I created a reproducer project for it: https://github.com/DuncanDoyle/DroolsSessionPersistenceNPE/
> I've added some Maven profiles so you can easily observe the behaviour:
> - mvn -PallRuns exec:java    : this runs both the persistence and the reload in the same JVM, no exception, everything works fine.
> - mvn -PfirstRun exec:java    : this runs the first part of the test, and saves the KieSession to a file.
> - mvn -PsecondRun exec:java   : this runs the second part of the test, which loads the previously saved KieSession from the file and inserts a new fact, resulting in the NPE.
> All three tests can also be run in ReteOO mode by adding "-Ddrools.ruleEngine=reteoo" at the end of the command.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct  3 03:41:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 3 Oct 2013 03:41:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-275) RuleEngine
 AfterEvaluator.evaluateCachedRight throws NPE on persisted Session reload
 (Phreak, Stream, PseudoClock)
In-Reply-To: <JIRA.12501735.1380283896000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501735.1380283896000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501735.1380283896000.11517.1380786062841@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809108#comment-12809108 ] 

RH Bugzilla Integration commented on DROOLS-275:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> changed the Status of [bug 1013197|https://bugzilla.redhat.com/show_bug.cgi?id=1013197] from ASSIGNED to MODIFIED
                
> RuleEngine AfterEvaluator.evaluateCachedRight throws NPE on persisted Session reload (Phreak, Stream, PseudoClock)
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-275
>                 URL: https://issues.jboss.org/browse/DROOLS-275
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR3
>         Environment: Mac OS-X 10.8.5, Hotspot 1.7.0_40
>            Reporter: Duncan Doyle
>            Assignee: Mario Fusco
>
> I persist a KieSession via the Marshaller (serializable) with one fact/event inserted. On reload of the session, I can see that fact is still there (when I check the FactHandles) and the PseudoClock is at the correct time (the time when I persisted it). If I then insert another fact/event into this reloaded session which matches the following rule:
> rule "SimpleFactTimeWindow"
> when
> 	$s1: SimpleFact() from entry-point LinkyStream
> 	$s2: SimpleFact(this != $s1, this after [0s, 10s] $s1) from entry-point LinkyStream
> then
> 	System.out.println("Rule fired, found 2 Facts within the time window.");
> end
> I get a NPE (in both Phreak and ReteOO mode). Exception in Phreak:
> java.lang.reflect.InvocationTargetException
> 	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.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297)
> 	at java.lang.Thread.run(Thread.java:724)
> Caused by: java.lang.NullPointerException
> 	at org.drools.core.base.evaluators.AfterEvaluatorDefinition$AfterEvaluator.evaluateCachedRight(AfterEvaluatorDefinition.java:304)
> 	at org.drools.core.rule.constraint.EvaluatorConstraint.isAllowedCachedRight(EvaluatorConstraint.java:80)
> 	at org.drools.core.common.DoubleBetaConstraints.isAllowedCachedRight(DoubleBetaConstraints.java:117)
> 	at org.drools.core.phreak.PhreakJoinNode.doRightInserts(PhreakJoinNode.java:150)
> 	at org.drools.core.phreak.PhreakJoinNode.doNode(PhreakJoinNode.java:56)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:547)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:533)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:335)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:162)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:117)
> 	at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194)
> 	at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:65)
> 	at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:936)
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1183)
> 	at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:936)
> 	at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:910)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:233)
> 	at org.jboss.ddoyle.brms.cep.ha.management.TestScenarioRunner.secondRun(TestScenarioRunner.java:142)
> 	at org.jboss.ddoyle.brms.cep.ha.management.MainSecondRun.main(MainSecondRun.java:7)
> 	... 6 more
> Exception in ReteOO:
> java.lang.reflect.InvocationTargetException
> 	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.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297)
> 	at java.lang.Thread.run(Thread.java:724)
> Caused by: org.drools.core.RuntimeDroolsException: Unexpected exception executing action org.drools.core.reteoo.PropagationQueuingNode$PropagateAction at 2e3aeda
> 	at org.drools.core.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1225)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:371)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:278)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:131)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:56)
> 	at org.jboss.ddoyle.brms.cep.ha.management.TestScenarioRunner.secondRun(TestScenarioRunner.java:140)
> 	at org.jboss.ddoyle.brms.cep.ha.management.MainSecondRun.main(MainSecondRun.java:7)
> 	... 6 more
> Caused by: java.lang.NullPointerException
> 	at org.drools.core.base.evaluators.AfterEvaluatorDefinition$AfterEvaluator.evaluateCachedLeft(AfterEvaluatorDefinition.java:324)
> 	at org.drools.core.rule.constraint.EvaluatorConstraint.isAllowedCachedLeft(EvaluatorConstraint.java:67)
> 	at org.drools.core.common.DoubleBetaConstraints.isAllowedCachedLeft(DoubleBetaConstraints.java:108)
> 	at org.drools.reteoo.nodes.ReteJoinNode.propagateFromLeft(ReteJoinNode.java:147)
> 	at org.drools.reteoo.nodes.ReteJoinNode.assertLeftTuple(ReteJoinNode.java:99)
> 	at org.drools.core.reteoo.SingleLeftTupleSinkAdapter.doPropagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:213)
> 	at org.drools.core.reteoo.SingleLeftTupleSinkAdapter.propagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:73)
> 	at org.drools.reteoo.nodes.ReteJoinNode.propagateFromRight(ReteJoinNode.java:135)
> 	at org.drools.reteoo.nodes.ReteJoinNode.assertRightTuple(ReteJoinNode.java:125)
> 	at org.drools.reteoo.nodes.ReteBetaNodeUtils.assertObject(ReteBetaNodeUtils.java:47)
> 	at org.drools.reteoo.nodes.ReteJoinNode.assertObject(ReteJoinNode.java:39)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:502)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:387)
> 	at org.drools.core.reteoo.PropagationQueuingNode$AssertAction.execute(PropagationQueuingNode.java:430)
> 	at org.drools.core.reteoo.PropagationQueuingNode.propagateActions(PropagationQueuingNode.java:266)
> 	at org.drools.core.reteoo.PropagationQueuingNode$PropagateAction.execute(PropagationQueuingNode.java:592)
> 	at org.drools.core.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1223)
> 	... 12 more
> What I discovered is that this only happens when I save the KieSession to a file in one JVM and reload it in another. When I load the KieSession in the same JVM as the one in which I persisted it, there is no exception and the rule get's fired (as expected).
> I created a reproducer project for it: https://github.com/DuncanDoyle/DroolsSessionPersistenceNPE/
> I've added some Maven profiles so you can easily observe the behaviour:
> - mvn -PallRuns exec:java    : this runs both the persistence and the reload in the same JVM, no exception, everything works fine.
> - mvn -PfirstRun exec:java    : this runs the first part of the test, and saves the KieSession to a file.
> - mvn -PsecondRun exec:java   : this runs the second part of the test, which loads the previously saved KieSession from the file and inserts a new fact, resulting in the NPE.
> All three tests can also be run in ReteOO mode by adding "-Ddrools.ruleEngine=reteoo" at the end of the command.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct  3 03:43:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Thu, 3 Oct 2013 03:43:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-275) RuleEngine
 AfterEvaluator.evaluateCachedRight throws NPE on persisted Session reload
 (Phreak, Stream, PseudoClock)
In-Reply-To: <JIRA.12501735.1380283896000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501735.1380283896000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501735.1380283896000.11521.1380786182605@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-275.
--------------------------------

    Fix Version/s: 6.0.0.CR5
       Resolution: Done

    
> RuleEngine AfterEvaluator.evaluateCachedRight throws NPE on persisted Session reload (Phreak, Stream, PseudoClock)
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-275
>                 URL: https://issues.jboss.org/browse/DROOLS-275
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR3
>         Environment: Mac OS-X 10.8.5, Hotspot 1.7.0_40
>            Reporter: Duncan Doyle
>            Assignee: Mario Fusco
>             Fix For: 6.0.0.CR5
>
>
> I persist a KieSession via the Marshaller (serializable) with one fact/event inserted. On reload of the session, I can see that fact is still there (when I check the FactHandles) and the PseudoClock is at the correct time (the time when I persisted it). If I then insert another fact/event into this reloaded session which matches the following rule:
> rule "SimpleFactTimeWindow"
> when
> 	$s1: SimpleFact() from entry-point LinkyStream
> 	$s2: SimpleFact(this != $s1, this after [0s, 10s] $s1) from entry-point LinkyStream
> then
> 	System.out.println("Rule fired, found 2 Facts within the time window.");
> end
> I get a NPE (in both Phreak and ReteOO mode). Exception in Phreak:
> java.lang.reflect.InvocationTargetException
> 	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.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297)
> 	at java.lang.Thread.run(Thread.java:724)
> Caused by: java.lang.NullPointerException
> 	at org.drools.core.base.evaluators.AfterEvaluatorDefinition$AfterEvaluator.evaluateCachedRight(AfterEvaluatorDefinition.java:304)
> 	at org.drools.core.rule.constraint.EvaluatorConstraint.isAllowedCachedRight(EvaluatorConstraint.java:80)
> 	at org.drools.core.common.DoubleBetaConstraints.isAllowedCachedRight(DoubleBetaConstraints.java:117)
> 	at org.drools.core.phreak.PhreakJoinNode.doRightInserts(PhreakJoinNode.java:150)
> 	at org.drools.core.phreak.PhreakJoinNode.doNode(PhreakJoinNode.java:56)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:547)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:533)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:335)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:162)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:117)
> 	at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194)
> 	at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:65)
> 	at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:936)
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1183)
> 	at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:936)
> 	at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:910)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:233)
> 	at org.jboss.ddoyle.brms.cep.ha.management.TestScenarioRunner.secondRun(TestScenarioRunner.java:142)
> 	at org.jboss.ddoyle.brms.cep.ha.management.MainSecondRun.main(MainSecondRun.java:7)
> 	... 6 more
> Exception in ReteOO:
> java.lang.reflect.InvocationTargetException
> 	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.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297)
> 	at java.lang.Thread.run(Thread.java:724)
> Caused by: org.drools.core.RuntimeDroolsException: Unexpected exception executing action org.drools.core.reteoo.PropagationQueuingNode$PropagateAction at 2e3aeda
> 	at org.drools.core.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1225)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:371)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:278)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:131)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:56)
> 	at org.jboss.ddoyle.brms.cep.ha.management.TestScenarioRunner.secondRun(TestScenarioRunner.java:140)
> 	at org.jboss.ddoyle.brms.cep.ha.management.MainSecondRun.main(MainSecondRun.java:7)
> 	... 6 more
> Caused by: java.lang.NullPointerException
> 	at org.drools.core.base.evaluators.AfterEvaluatorDefinition$AfterEvaluator.evaluateCachedLeft(AfterEvaluatorDefinition.java:324)
> 	at org.drools.core.rule.constraint.EvaluatorConstraint.isAllowedCachedLeft(EvaluatorConstraint.java:67)
> 	at org.drools.core.common.DoubleBetaConstraints.isAllowedCachedLeft(DoubleBetaConstraints.java:108)
> 	at org.drools.reteoo.nodes.ReteJoinNode.propagateFromLeft(ReteJoinNode.java:147)
> 	at org.drools.reteoo.nodes.ReteJoinNode.assertLeftTuple(ReteJoinNode.java:99)
> 	at org.drools.core.reteoo.SingleLeftTupleSinkAdapter.doPropagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:213)
> 	at org.drools.core.reteoo.SingleLeftTupleSinkAdapter.propagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:73)
> 	at org.drools.reteoo.nodes.ReteJoinNode.propagateFromRight(ReteJoinNode.java:135)
> 	at org.drools.reteoo.nodes.ReteJoinNode.assertRightTuple(ReteJoinNode.java:125)
> 	at org.drools.reteoo.nodes.ReteBetaNodeUtils.assertObject(ReteBetaNodeUtils.java:47)
> 	at org.drools.reteoo.nodes.ReteJoinNode.assertObject(ReteJoinNode.java:39)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:502)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:387)
> 	at org.drools.core.reteoo.PropagationQueuingNode$AssertAction.execute(PropagationQueuingNode.java:430)
> 	at org.drools.core.reteoo.PropagationQueuingNode.propagateActions(PropagationQueuingNode.java:266)
> 	at org.drools.core.reteoo.PropagationQueuingNode$PropagateAction.execute(PropagationQueuingNode.java:592)
> 	at org.drools.core.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1223)
> 	... 12 more
> What I discovered is that this only happens when I save the KieSession to a file in one JVM and reload it in another. When I load the KieSession in the same JVM as the one in which I persisted it, there is no exception and the rule get's fired (as expected).
> I created a reproducer project for it: https://github.com/DuncanDoyle/DroolsSessionPersistenceNPE/
> I've added some Maven profiles so you can easily observe the behaviour:
> - mvn -PallRuns exec:java    : this runs both the persistence and the reload in the same JVM, no exception, everything works fine.
> - mvn -PfirstRun exec:java    : this runs the first part of the test, and saves the KieSession to a file.
> - mvn -PsecondRun exec:java   : this runs the second part of the test, which loads the previously saved KieSession from the file and inserts a new fact, resulting in the NPE.
> All three tests can also be run in ReteOO mode by adding "-Ddrools.ruleEngine=reteoo" at the end of the command.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct  3 05:13:02 2013
From: jira-events at lists.jboss.org (Nick Howes (JIRA))
Date: Thu, 3 Oct 2013 05:13:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2203) Error deploying multiple
	*-ds.xml files
In-Reply-To: <JIRA.12502011.1380723512000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502011.1380723512000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502011.1380723512000.11667.1380791582622@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809130#comment-12809130 ] 

Nick Howes commented on WFLY-2203:
----------------------------------

Tried putting all the datasources into one file but no difference.
                
> Error deploying multiple *-ds.xml files
> ---------------------------------------
>
>                 Key: WFLY-2203
>                 URL: https://issues.jboss.org/browse/WFLY-2203
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Nick Howes
>            Assignee: Stefano Maestri
>            Priority: Minor
>             Fix For: 8.0.0.Final
>
>
> Our individual *-ds.xml datasources were all deploying fine in Alpha4 but in the Beta1 nightlies this error appears on startup:
> {noformat}
> 15:07:52,111 ERROR [org.jboss.msc.service] (MSC service thread 1-4) MSC000002: Invocation of listener "org.jboss.as.connector.subsystems.datasources.D
> ataSourceStatisticsListener at 7d18ac99" failed: java.lang.IllegalArgumentException: JBAS014742: A node is already registered at '(deployment => *)(subsy
> stem => datasources)(data-source => *)(statistics => jdbc)'
>         at org.jboss.as.controller.registry.NodeSubregistry.register(NodeSubregistry.java:86) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1
> -SNAPSHOT]
>         at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:149) [wildfly-controller-8
> .0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
>         at org.jboss.as.controller.registry.AbstractResourceRegistration.registerSubModel(AbstractResourceRegistration.java:90) [wildfly-controller-8.
> 0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
>         at org.jboss.as.connector.subsystems.datasources.DataSourceStatisticsListener.transition(DataSourceStatisticsListener.java:72) [wildfly-connec
> tor-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
>         at org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1533) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> {noformat}
> Our datasource files look like this. I haven't tried putting all the datasource elements into one file.
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <datasources>
>   <datasource jndi-name="java:/AlphaDS" enabled="true" use-java-context="true" pool-name="AlphaDS">
>     <connection-url>jdbc:oracle:thin://@db-host:1666/dev-db</connection-url> 
>     <driver>oracle</driver>
>     <security>
>       <user-name>XXX</user-name>
>       <password>YYY</password>
>     </security>
>     <connection-property name="defaultNChar">true</connection-property>
>   </datasource>
> </datasources>
> {code}
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <datasources>
>   <datasource jndi-name="java:/BetaDS" enabled="true" use-java-context="true" pool-name="BetaDS">
>     <connection-url>jdbc:oracle:thin://@db-host:1666/dev-db</connection-url> 
>     <driver>oracle</driver>
>     <security>
>       <user-name>XXX</user-name>
>       <password>YYY</password>
>     </security>
>     <connection-property name="defaultNChar">true</connection-property>
>   </datasource>
> </datasources>
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct  3 06:08:02 2013
From: jira-events at lists.jboss.org (Michael Anstis (JIRA))
Date: Thu, 3 Oct 2013 06:08:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-280) lock-on-active broken
In-Reply-To: <JIRA.12501976.1380702873000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501976.1380702873000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501976.1380702873000.11729.1380794882626@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Anstis moved GUVNOR-2053 to DROOLS-280:
-----------------------------------------------

              Project: Drools  (was: Guvnor)
                  Key: DROOLS-280  (was: GUVNOR-2053)
             Workflow: GIT Pull Request workflow   (was: classic default workflow)
    Affects Version/s:     (was: drools-6.0.0.CR4)

    
> lock-on-active broken
> ---------------------
>
>                 Key: DROOLS-280
>                 URL: https://issues.jboss.org/browse/DROOLS-280
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Anthony Patricio
>
> Hi,
> lock-on-active is not working as expected.
> I seems to work as activation-group.
> Works fine with 5.x
> Fails with 6.0.0 CR3 and CR4
> Fact:
> public class Poc implements Serializable {
> 	private static final long serialVersionUID = 1L;
> 	private long id = 1;
> 	private boolean test1 = false;
> 	private boolean test2 = false;
> 	private int foundTest = 0;
> ...
> }
> Rule:
> rule "test1"
> lock-on-active 
> dialect "mvel"
>     when
>     	$poc:Poc( isTest1() )
>     then
>     	System.out.println("test1 found");
>     	modify($poc) { setFoundTest($poc.getFoundTest() + 1) }    	
> end
> rule "test2"
> lock-on-active 
> dialect "mvel"
>     when
>     	$poc:Poc( isTest2() )
>     then
>     	System.out.println("test2 found");
>     	modify($poc) { setFoundTest($poc.getFoundTest() + 1) }    	
> end
> Test:
> @Test
> public void lockOnActiveTest() {
> 	// Get the Knowledge base from the DRL file 
> 	KieSession kSession = getSF();
> 			
> 	Poc poc = new Poc();
> 	poc.setTest1(true);
> 	poc.setTest2(true);
> 	
> 	kSession.insert(poc);
> 	
> 	// Fire the rules
> 	kSession.fireAllRules();
> 	
> 	assertTrue("broken",poc.getFoundTest()==2);
> 	
> 	// Clean up
> 	kSession.dispose();
> }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct  3 06:22:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 3 Oct 2013 06:22:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2207) CLI Unable to connect using
 https-remoting address.
In-Reply-To: <JIRA.12502036.1380735356000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502036.1380735356000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502036.1380735356000.11734.1380795722592@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809140#comment-12809140 ] 

Darran Lofthouse commented on WFLY-2207:
----------------------------------------

Additional testing:  This is not just about the automatic prompt to accept unknown certificates, this error is the same if the CLI is configured to use a trust store containing the servers certificate.

                
> CLI Unable to connect using https-remoting address.
> ---------------------------------------------------
>
>                 Key: WFLY-2207
>                 URL: https://issues.jboss.org/browse/WFLY-2207
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>
> The CLI is failing to connect over https with the following: -
> {code}
> [disconnected /] connect https-remoting://localhost:9993
> The controller is not available at localhost:9993: java.net.ConnectException: JBAS012144: Could not connect to https-remoting://localhost:9993. The connection timed out: JBAS012144: Could not connect to https-remoting://localhost:9993. The connection timed out
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct  3 06:31:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 3 Oct 2013 06:31:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1713) MERGE3: view in header is too
 big in large clusters
In-Reply-To: <JIRA.12502089.1380796181951@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502089.1380796181951@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502089.1380796181951.11755.1380796262672@jira02.app.mwc.hst.phx2.redhat.com>

Bela Ban created JGRP-1713:
------------------------------

             Summary: MERGE3: view in header is too big in large clusters
                 Key: JGRP-1713
                 URL: https://issues.jboss.org/browse/JGRP-1713
             Project: JGroups
          Issue Type: Bug
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 3.4


In MERGE3, as a response to a VIEW_REQ, a VIEW_RSP contains the entire view (not a delta view), and because this is returned in the header, we might run into the same issue as in https://issues.jboss.org/browse/JGRP-1710.
SOLUTION:
Move the view carried with a VIEW_RSP into the message body and add FRAG2 over the transport to fragment this message.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct  3 06:35:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 3 Oct 2013 06:35:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1714) Discovery: data in PingHeader
 might be too large in big clusters
In-Reply-To: <JIRA.12502090.1380796496307@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502090.1380796496307@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502090.1380796496307.11758.1380796502546@jira02.app.mwc.hst.phx2.redhat.com>

Bela Ban created JGRP-1714:
------------------------------

             Summary: Discovery: data in PingHeader might be too large in big clusters
                 Key: JGRP-1714
                 URL: https://issues.jboss.org/browse/JGRP-1714
             Project: JGroups
          Issue Type: Bug
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 3.4


Similar to JGRP-1710 and JGRP-1713, investigate {{PingHeader}}. Probable solution: move {{PingHeader.PingData}} from the header to the message body

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct  3 06:37:02 2013
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 3 Oct 2013 06:37:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2209) short versions of command
 arguments (e.g. -h) are not recognized
In-Reply-To: <JIRA.12502091.1380796517449@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502091.1380796517449@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502091.1380796517449.11760.1380796622499@jira02.app.mwc.hst.phx2.redhat.com>

Alexey Loubyansky created WFLY-2209:
---------------------------------------

             Summary: short versions of command arguments (e.g. -h) are not recognized
                 Key: WFLY-2209
                 URL: https://issues.jboss.org/browse/WFLY-2209
             Project: WildFly
          Issue Type: Bug
          Components: CLI
    Affects Versions: 8.0.0.Alpha4
            Reporter: Alexey Loubyansky
            Assignee: Alexey Loubyansky


The validation of command arguments doesn't take into account their short versions leading rejecting the command in case the short versions are used (e.g. -h for --help).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct  3 06:41:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 3 Oct 2013 06:41:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1712) FRAG / FRAG2: CONFIG event
 overrides user-configured frag_size value
In-Reply-To: <JIRA.12502064.1380780130000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502064.1380780130000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502064.1380780130000.11762.1380796862499@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1712.
----------------------------

    Resolution: Done

    
> FRAG / FRAG2: CONFIG event overrides user-configured frag_size value
> --------------------------------------------------------------------
>
>                 Key: JGRP-1712
>                 URL: https://issues.jboss.org/browse/JGRP-1712
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.4
>
>
> When we have multiple FRAG or FRAG2 in the same stack (with different IDs), then each fragmentation protocol sends a CONFIG event (with {{frag_size}}) up and down the stack. When this event is received by a different frag protocol, then it will set its own {{frag_size}}, overriding the previously set value.
> Investigate whether we still need the CONFIG event.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct  3 07:20:03 2013
From: jira-events at lists.jboss.org (Flemming Harms (JIRA))
Date: Thu, 3 Oct 2013 07:20:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1948)
 java.lang.IllegalStateException: Destination queue.ISXO_AuditLogQueue_01
 not active after MessagingClusterHealthMBean restart JMS service
In-Reply-To: <JIRA.12502101.1380799169650@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502101.1380799169650@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502101.1380799169650.11822.1380799203035@jira02.app.mwc.hst.phx2.redhat.com>

Flemming Harms created JBMESSAGING-1948:
-------------------------------------------

             Summary: java.lang.IllegalStateException: Destination queue.ISXO_AuditLogQueue_01 not active after MessagingClusterHealthMBean restart JMS service
                 Key: JBMESSAGING-1948
                 URL: https://issues.jboss.org/browse/JBMESSAGING-1948
             Project: JBoss Messaging
          Issue Type: Bug
          Components: JMS Clustering
    Affects Versions: 1.4.8.SP9
            Reporter: Flemming Harms


I get this error ?java.lang.IllegalStateException: Destination queue.ISXO_AuditLogQueue_01 not active? after MessagingClusterHealthMBean restarts the JMS service with JBoss Messaging 1.4.8.SP9. 

I have 2 node JBoss5 cluster with JBoss Messaging and I have enabled the new failover model and setup the MessagingClusterHealthMBean to monitor split brain.

I disconnect the cable from one of the servers MessagingClusterHealthMBean discover it?s alone and shut down the JMS service as expected. After a while I connect the server again and the server discover the other server and MessagingClusterHealthMBean starts the JMS service also as expected.

But when I connect a client it fails with ?java.lang.IllegalStateException: Destination queue.ISXO_AuditLogQueue_01 not active? and what I can see in the debugger ServerConnectionEndpoint have reference to the old post office where the queue is still exits in the inactiveConditions Set.

Log from the server when it discover it?s alone and it restart the service again

2013-09-07 21:29:06,381 ERROR [org.jboss.messaging.core.impl.postoffice.MessagingPostOffice] (Thread-32) I'm orphaned and now I can't tell others that I'm alive. Shutdown node: 102
2013-09-07 21:29:09,728 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-32) Stopping JBM node on DB failure...
2013-09-07 21:29:09,731 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-32) Queue[/queue/ExpiryQueue] stopped
2013-09-07 21:29:09,732 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-32) Queue[/queue/DLQ] stopped
2013-09-07 21:29:09,733 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-32) Queue[/ISXO/AuditLogQueue, name=ISXO_AuditLogQueue_01] stopped
2013-09-07 21:29:09,733 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-32) Queue[/ISXO/CiscoUCSEventQueue, name=ISXO_CiscoUCSEventQueue_01] stopped
2013-09-07 21:29:09,738 INFO  [org.jboss.jms.server.destination.TopicService] (Thread-32) Topic[/ISXO/RemoteEventTopic, name=ISXO_RemoteEventQueue_01] stopped
2013-09-07 21:29:09,739 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-32) Queue[/ISXO/ScheduledJobQueue, name=ISXO_ScheduledJobQueue_01] stopped
2013-09-07 21:29:11,210 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-32) org.jboss.jms.server.connectionfactory.ConnectionFactory at 366480d7 undeployed
2013-09-07 21:29:11,216 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-32) org.jboss.jms.server.connectionfactory.ConnectionFactory at 467463b3 undeployed
2013-09-07 21:29:11,216 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-32) org.jboss.jms.server.connectionfactory.ConnectionFactory at 21fdb35f undeployed
2013-09-07 21:29:11,216 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-32) org.jboss.jms.server.connectionfactory.ConnectionFactory at 443578f2 undeployed
2013-09-07 21:29:11,235 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-32) org.jboss.jms.server.connectionfactory.ConnectionFactory at ecdede5 undeployed
2013-09-07 21:29:11,298 ERROR [org.jgroups.blocks.ConnectionTable] (OOB-43,192.168.56.102:7900) failed sending data to 192.168.56.101:7900: java.net.SocketException: Socket closed
2013-09-07 21:29:14,413 WARN  [org.jgroups.protocols.pbcast.NAKACK] (OOB-19,192.168.56.102:55200) 192.168.56.102:55200] discarded message from non-member 192.168.56.101:55200, my view is [192.168.56.102
2013-09-07 21:29:14,863 WARN  [org.jgroups.protocols.pbcast.NAKACK] (OOB-19,192.168.56.102:55200) 192.168.56.102:55200] discarded message from non-member 192.168.56.101:55200, my view is [192.168.56.102
2013-09-07 21:29:21,080 INFO  [org.jboss.jms.server.ServerPeer] (Thread-32) JMS ServerPeer[102] stopped
2013-09-07 21:29:21,090 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-32) JBM node is stopped.
2013-09-07 21:29:21,090 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] (Incoming-2,192.168.56.102:55200) Dead members: 1 ([192.168.56.101:55200])
2013-09-07 21:29:21,090 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] (Incoming-2,192.168.56.102:55200) All Members : 1 ([192.168.56.102:55200])
2013-09-07 21:30:24,666 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Restarting JBM node...
2013-09-07 21:30:33,369 INFO  [org.jboss.jms.server.ServerPeer] (Thread-75) JBoss Messaging 1.4.8.SP9 server [102] started
2013-09-07 21:30:33,459 INFO  [STDOUT] (Thread-75) 
---------------------------------------------------------
GMS: address is 192.168.56.102:55200 (cluster=DefaultPartition-JMS-CTRL)
---------------------------------------------------------
2013-09-07 21:30:33,524 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] (Thread-75) org.jboss.messaging.core.impl.postoffice.GroupMember$ControlMembershipListener at 6a500238 got new view [192
2013-09-07 21:30:33,525 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] (Thread-75) I am (192.168.56.102:55200)
2013-09-07 21:30:33,525 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] (Thread-75) New Members : 2 ([192.168.56.101:55200, 192.168.56.102:55200])
2013-09-07 21:30:33,525 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] (Thread-75) All Members : 2 ([192.168.56.101:55200, 192.168.56.102:55200])
2013-09-07 21:30:33,570 INFO  [STDOUT] (pool-151-thread-1) 
---------------------------------------------------------
GMS: address is 192.168.56.102:7900 (cluster=DefaultPartition-JMS-DATA)
---------------------------------------------------------

2013-09-07 21:30:33,779 INFO  [org.jboss.messaging.core.impl.postoffice.MessagingPostOffice] (Thread-75) Waiting for JGroups...
2013-09-07 21:30:33,784 INFO  [org.jboss.messaging.core.impl.postoffice.MessagingPostOffice] (Thread-75) JGroups starts to work again, initializing state
2013-09-07 21:30:33,785 INFO  [org.jboss.messaging.core.impl.postoffice.MessagingPostOffice] (Thread-75) Now node is ready for work.
2013-09-07 21:30:34,896 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) Connector sslbisocket://192.168.56.102:4459 has leasing enabled, lease period 25000 milliseconds
2013-09-07 21:30:34,896 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered connection factory jboss.messaging.connectionfactory:service=SSLConnectionFactory
2013-09-07 21:30:34,896 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) org.jboss.jms.server.connectionfactory.ConnectionFactory at 366480d7 started
2013-09-07 21:30:36,797 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) Connector bisocket://192.168.56.102:4457 has leasing enabled, lease period 25000 milliseconds
2013-09-07 21:30:36,797 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered connection factory jboss.messaging.connectionfactory:service=ConnectionFactory
2013-09-07 21:30:36,797 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) org.jboss.jms.server.connectionfactory.ConnectionFactory at 467463b3 started
2013-09-07 21:30:37,207 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) Connector servlet://192.168.56.102:8080 has leasing enabled, lease period 25000 milliseconds
2013-09-07 21:30:37,207 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered connection factory jboss.messaging.connectionfactory:service=ServletConnectionFactory
2013-09-07 21:30:37,207 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) org.jboss.jms.server.connectionfactory.ConnectionFactory at 21fdb35f started
2013-09-07 21:30:37,440 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) Connector bisocket://192.168.56.102:4457 has leasing enabled, lease period 25000 milliseconds
2013-09-07 21:30:37,441 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered connection factory jboss.messaging.connectionfactory:service=ClusteredConnectionFactory
2013-09-07 21:30:37,441 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) org.jboss.jms.server.connectionfactory.ConnectionFactory at 443578f2 started
2013-09-07 21:30:41,483 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) Connector bisocket://192.168.56.102:4457 has leasing enabled, lease period 25000 milliseconds
2013-09-07 21:30:41,483 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered connection factory jboss.messaging.connectionfactory:service=ClusterPullConnectionFactory
2013-09-07 21:30:41,483 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) org.jboss.jms.server.connectionfactory.ConnectionFactory at ecdede5 started
2013-09-07 21:30:41,483 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered destination jboss.messaging.destination:service=Queue,name=ExpiryQueue
2013-09-07 21:30:41,715 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-75) Queue[/queue/ExpiryQueue] started, fullSize=200000, pageSize=2000, downCacheSize=2000
2013-09-07 21:30:41,715 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered destination jboss.messaging.destination:service=Queue,name=DLQ
2013-09-07 21:30:42,259 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-75) Queue[/queue/DLQ] started, fullSize=200000, pageSize=2000, downCacheSize=2000
2013-09-07 21:30:42,259 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered destination jboss.messaging.destination:service=Queue,name=ISXO_AuditLogQueue_01
2013-09-07 21:30:42,495 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-75) Queue[/ISXO/AuditLogQueue, name=ISXO_AuditLogQueue_01] started, fullSize=200000, pageSize=2000, downCacheSize=20
2013-09-07 21:30:42,495 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered destination jboss.messaging.destination:service=Queue,name=ISXO_CiscoUCSEventQueue_01
2013-09-07 21:30:42,923 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-75) Queue[/ISXO/CiscoUCSEventQueue, name=ISXO_CiscoUCSEventQueue_01] started, fullSize=200000, pageSize=2000, downCa
2013-09-07 21:30:42,923 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered destination jboss.messaging.destination:service=Topic,name=ISXO_RemoteEventQueue_01
2013-09-07 21:30:43,122 INFO  [org.jboss.jms.server.destination.TopicService] (Thread-75) Topic[/ISXO/RemoteEventTopic, name=ISXO_RemoteEventQueue_01] started, fullSize=200000, pageSize=2000, downCacheS
2013-09-07 21:30:43,122 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered destination jboss.messaging.destination:service=Queue,name=ISXO_ScheduledJobQueue_01
2013-09-07 21:30:43,559 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-75) Queue[/ISXO/ScheduledJobQueue, name=ISXO_ScheduledJobQueue_01] started, fullSize=200000, pageSize=2000, downCach
2013-09-07 21:30:43,559 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) JBM node restarted.


Stack trace the ?java.lang.IllegalStateException: Destination queue.ISXO_AuditLogQueue_01 not active?

Daemon Thread [ISXOSchedulerPrioritized_Worker-1] (Suspended (breakpoint at line 3046 in MessagingPostOffice))	
	owns: AtomicAction  (id=519)	
	MessagingPostOffice.routeInternal(MessageReference, Condition, Transaction, boolean, Set) line: 3046	
	MessagingPostOffice.route(MessageReference, Condition, Transaction) line: 983	
	ServerConnectionEndpoint.sendMessage(JBossMessage, Transaction, boolean) line: 796	
	ServerConnectionEndpoint.processTransaction(ClientTransaction, Transaction, boolean) line: 852	
	ServerConnectionEndpoint.sendTransaction(TransactionRequest, boolean) line: 516	
	ConnectionAdvised.org$jboss$jms$server$endpoint$advised$ConnectionAdvised$sendTransaction$aop(TransactionRequest, boolean) line: 106	
	ConnectionAdvised$sendTransaction_N3268650789275322226.invokeTarget() line: not available	
	ConnectionAdvised$sendTransaction_N3268650789275322226(MethodInvocation).invokeNext() line: 111	
	SecurityAspect.handleSendTransaction(Invocation) line: 200	
	NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]	
	NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39	
	DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25	
	Method.invoke(Object, Object...) line: 597	
	PerInstanceAdvice.invoke(Invocation) line: 122	
	ConnectionAdvised$sendTransaction_N3268650789275322226(MethodInvocation).invokeNext() line: 102	
	ServerLogInterceptor.invoke(Invocation) line: 105	
	ConnectionAdvised$sendTransaction_N3268650789275322226(MethodInvocation).invokeNext() line: 102	
	ConnectionAdvised.sendTransaction(TransactionRequest, boolean) line: not available	
	ConnectionSendTransactionRequest.serverInvoke() line: 86	
	JMSServerInvocationHandler.invoke(InvocationRequest) line: 165	
	BisocketServerInvoker(ServerInvoker).invoke(InvocationRequest) line: 930	
	LocalClientInvoker.invoke(InvocationRequest) line: 106	
	Client.invoke(Object, Map, InvokerLocator) line: 2034	
	Client.invoke(Object, Map) line: 877	
	Client.invoke(Object) line: 865	
	ClientConnectionDelegate(DelegateSupport).doInvoke(Client, RequestSupport, boolean) line: 189	
	ClientConnectionDelegate(DelegateSupport).doInvoke(Client, RequestSupport) line: 160	
	ClientConnectionDelegate.org$jboss$jms$client$delegate$ClientConnectionDelegate$sendTransaction$aop(TransactionRequest, boolean) line: 241	
	ClientConnectionDelegate$sendTransaction_N3268650789275322226.invokeTarget() line: not available	
	ClientConnectionDelegate$sendTransaction_N3268650789275322226(MethodInvocation).invokeNext() line: 111	
	FailoverValveInterceptor.invoke(Invocation) line: 92	
	PerInstanceInterceptor.invoke(Invocation) line: 86	
	ClientConnectionDelegate$sendTransaction_N3268650789275322226(MethodInvocation).invokeNext() line: 102	
	ClosedInterceptor.invoke(Invocation) line: 172	
	PerInstanceInterceptor.invoke(Invocation) line: 86	
	ClientConnectionDelegate$sendTransaction_N3268650789275322226(MethodInvocation).invokeNext() line: 102	
	ClientConnectionDelegate.sendTransaction(TransactionRequest, boolean) line: not available	
	ResourceManager.sendTransactionXA(TransactionRequest, ConnectionDelegate) line: 712	
	ResourceManager.commit(Xid, boolean, ConnectionDelegate) line: 392	
	MessagingXAResource.commit(Xid, boolean) line: 275	
	JmsXAResource.commit(Xid, boolean) line: 98	
	XAResourceRecord.topLevelOnePhaseCommit() line: 811	
	AtomicAction(BasicAction).onePhaseCommit(boolean) line: 2656	
	AtomicAction(BasicAction).End(boolean) line: 1784	
	AtomicAction(TwoPhaseCoordinator).end(boolean) line: 94	
	AtomicAction(AtomicAction).commit(boolean) line: 160	
	TransactionImple.commitAndDisassociate() line: 1431	
	TransactionManagerImple(BaseTransaction).commit() line: 137	
	TransactionManagerDelegate(BaseTransactionManagerDelegate).commit() line: 75	
	Ejb3TxPolicy(TxPolicy).endTransaction(TransactionManager, Transaction) line: 170	
	Ejb3TxPolicy(TxPolicy).invokeInOurTx(Invocation, TransactionManager) line: 87	
	TxInterceptor$Required.invoke(Invocation) line: 190	
	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
	TxPropagationInterceptor.invoke(Invocation) line: 76	
	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
	NullInterceptor.invoke(Invocation) line: 42	
	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
	Ejb3AuthenticationInterceptorv2.invoke(Invocation) line: 182	
	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
	ENCPropagationInterceptor.invoke(Invocation) line: 41	
	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
	BlockContainerShutdownInterceptor.invoke(Invocation) line: 67	
	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
	CurrentInvocationContextInterceptor.invoke(Invocation) line: 47	
	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
	CurrentInvocationInterceptor.invoke(Invocation) line: 67	
	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
	EJB3TCCLInterceptor.invoke(Invocation) line: 86	
	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
	StatelessContainer(SessionSpecContainer).invoke(Serializable, SerializableMethod, Object[]) line: 193	
	StatelessContainer(SessionSpecContainer).invoke(Object, SerializableMethod, Object[]) line: 250	
	SessionLocalProxyInvocationHandler(SessionProxyInvocationHandlerBase).invoke(Object, Method, Object[]) line: 188	
	$Proxy702.publishMessages(EventSet) line: not available	
	NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]	
	NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39	
	DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25	
	Method.invoke(Object, Object...) line: 597	
	ClusteredEJB3InvokerJob(EJB3InvokerJob).invokeEjb(Object, JobExecutionContext) line: 196	
	ClusteredEJB3InvokerJob(EJB3InvokerJob).doExecute(JobExecutionContext) line: 141	
	ClusteredEJB3InvokerJob(EJB3InvokerJob).execute(JobExecutionContext) line: 78	
	JobRunShell.run() line: 203	
	SimpleThreadPool$WorkerThread.run() line: 520

Update
========
After debugging the code to understand what is going on I'm pretty sure we have situation where it use an old ServerConnectionEndpoint with a old postoffice instance. In our case we have a bean(stateless) that inject the TopicConnectionFactory and and Topic as resource this could possible reuse an old connection?

I can see that sometimes it get an instance of ServerConnectionEndpoint which contains a reference to the current server peer and to the old post office. The server peer instance actual holde the reference to the new post office, but because the postoffice variable is only set on constructor level this is never changed. 

Furthermore I can see the start method in ConnectionFactory was creating a listener that listens for failed connections, but this was not removed when the service stopped. After I removed the listener when the ConnectionFactory is stopped,  and restarted i'm able to receive updates again and it does not fail with a  "java.lang.IllegalStateException: Destination queue.MyQueue not active"

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Thu Oct  3 07:24:02 2013
From: jira-events at lists.jboss.org (Flemming Harms (JIRA))
Date: Thu, 3 Oct 2013 07:24:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1948)
 java.lang.IllegalStateException: Destination queue.ISXO_AuditLogQueue_01
 not active after MessagingClusterHealthMBean restart JMS service
In-Reply-To: <JIRA.12502101.1380799169000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502101.1380799169000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502101.1380799169000.11834.1380799442768@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Flemming Harms updated JBMESSAGING-1948:
----------------------------------------

    Attachment: postoffice-patch.diff


Suggested patch for solving the ServerConnectionEndpoint can have reference to an old post office
                
> java.lang.IllegalStateException: Destination queue.ISXO_AuditLogQueue_01 not active after MessagingClusterHealthMBean restart JMS service
> -----------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1948
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1948
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.8.SP9
>            Reporter: Flemming Harms
>         Attachments: postoffice-patch.diff
>
>
> I get this error ?java.lang.IllegalStateException: Destination queue.ISXO_AuditLogQueue_01 not active? after MessagingClusterHealthMBean restarts the JMS service with JBoss Messaging 1.4.8.SP9. 
> I have 2 node JBoss5 cluster with JBoss Messaging and I have enabled the new failover model and setup the MessagingClusterHealthMBean to monitor split brain.
> I disconnect the cable from one of the servers MessagingClusterHealthMBean discover it?s alone and shut down the JMS service as expected. After a while I connect the server again and the server discover the other server and MessagingClusterHealthMBean starts the JMS service also as expected.
> But when I connect a client it fails with ?java.lang.IllegalStateException: Destination queue.ISXO_AuditLogQueue_01 not active? and what I can see in the debugger ServerConnectionEndpoint have reference to the old post office where the queue is still exits in the inactiveConditions Set.
> Log from the server when it discover it?s alone and it restart the service again
> 2013-09-07 21:29:06,381 ERROR [org.jboss.messaging.core.impl.postoffice.MessagingPostOffice] (Thread-32) I'm orphaned and now I can't tell others that I'm alive. Shutdown node: 102
> 2013-09-07 21:29:09,728 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-32) Stopping JBM node on DB failure...
> 2013-09-07 21:29:09,731 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-32) Queue[/queue/ExpiryQueue] stopped
> 2013-09-07 21:29:09,732 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-32) Queue[/queue/DLQ] stopped
> 2013-09-07 21:29:09,733 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-32) Queue[/ISXO/AuditLogQueue, name=ISXO_AuditLogQueue_01] stopped
> 2013-09-07 21:29:09,733 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-32) Queue[/ISXO/CiscoUCSEventQueue, name=ISXO_CiscoUCSEventQueue_01] stopped
> 2013-09-07 21:29:09,738 INFO  [org.jboss.jms.server.destination.TopicService] (Thread-32) Topic[/ISXO/RemoteEventTopic, name=ISXO_RemoteEventQueue_01] stopped
> 2013-09-07 21:29:09,739 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-32) Queue[/ISXO/ScheduledJobQueue, name=ISXO_ScheduledJobQueue_01] stopped
> 2013-09-07 21:29:11,210 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-32) org.jboss.jms.server.connectionfactory.ConnectionFactory at 366480d7 undeployed
> 2013-09-07 21:29:11,216 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-32) org.jboss.jms.server.connectionfactory.ConnectionFactory at 467463b3 undeployed
> 2013-09-07 21:29:11,216 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-32) org.jboss.jms.server.connectionfactory.ConnectionFactory at 21fdb35f undeployed
> 2013-09-07 21:29:11,216 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-32) org.jboss.jms.server.connectionfactory.ConnectionFactory at 443578f2 undeployed
> 2013-09-07 21:29:11,235 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-32) org.jboss.jms.server.connectionfactory.ConnectionFactory at ecdede5 undeployed
> 2013-09-07 21:29:11,298 ERROR [org.jgroups.blocks.ConnectionTable] (OOB-43,192.168.56.102:7900) failed sending data to 192.168.56.101:7900: java.net.SocketException: Socket closed
> 2013-09-07 21:29:14,413 WARN  [org.jgroups.protocols.pbcast.NAKACK] (OOB-19,192.168.56.102:55200) 192.168.56.102:55200] discarded message from non-member 192.168.56.101:55200, my view is [192.168.56.102
> 2013-09-07 21:29:14,863 WARN  [org.jgroups.protocols.pbcast.NAKACK] (OOB-19,192.168.56.102:55200) 192.168.56.102:55200] discarded message from non-member 192.168.56.101:55200, my view is [192.168.56.102
> 2013-09-07 21:29:21,080 INFO  [org.jboss.jms.server.ServerPeer] (Thread-32) JMS ServerPeer[102] stopped
> 2013-09-07 21:29:21,090 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-32) JBM node is stopped.
> 2013-09-07 21:29:21,090 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] (Incoming-2,192.168.56.102:55200) Dead members: 1 ([192.168.56.101:55200])
> 2013-09-07 21:29:21,090 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] (Incoming-2,192.168.56.102:55200) All Members : 1 ([192.168.56.102:55200])
> 2013-09-07 21:30:24,666 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Restarting JBM node...
> 2013-09-07 21:30:33,369 INFO  [org.jboss.jms.server.ServerPeer] (Thread-75) JBoss Messaging 1.4.8.SP9 server [102] started
> 2013-09-07 21:30:33,459 INFO  [STDOUT] (Thread-75) 
> ---------------------------------------------------------
> GMS: address is 192.168.56.102:55200 (cluster=DefaultPartition-JMS-CTRL)
> ---------------------------------------------------------
> 2013-09-07 21:30:33,524 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] (Thread-75) org.jboss.messaging.core.impl.postoffice.GroupMember$ControlMembershipListener at 6a500238 got new view [192
> 2013-09-07 21:30:33,525 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] (Thread-75) I am (192.168.56.102:55200)
> 2013-09-07 21:30:33,525 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] (Thread-75) New Members : 2 ([192.168.56.101:55200, 192.168.56.102:55200])
> 2013-09-07 21:30:33,525 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] (Thread-75) All Members : 2 ([192.168.56.101:55200, 192.168.56.102:55200])
> 2013-09-07 21:30:33,570 INFO  [STDOUT] (pool-151-thread-1) 
> ---------------------------------------------------------
> GMS: address is 192.168.56.102:7900 (cluster=DefaultPartition-JMS-DATA)
> ---------------------------------------------------------
> 2013-09-07 21:30:33,779 INFO  [org.jboss.messaging.core.impl.postoffice.MessagingPostOffice] (Thread-75) Waiting for JGroups...
> 2013-09-07 21:30:33,784 INFO  [org.jboss.messaging.core.impl.postoffice.MessagingPostOffice] (Thread-75) JGroups starts to work again, initializing state
> 2013-09-07 21:30:33,785 INFO  [org.jboss.messaging.core.impl.postoffice.MessagingPostOffice] (Thread-75) Now node is ready for work.
> 2013-09-07 21:30:34,896 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) Connector sslbisocket://192.168.56.102:4459 has leasing enabled, lease period 25000 milliseconds
> 2013-09-07 21:30:34,896 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered connection factory jboss.messaging.connectionfactory:service=SSLConnectionFactory
> 2013-09-07 21:30:34,896 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) org.jboss.jms.server.connectionfactory.ConnectionFactory at 366480d7 started
> 2013-09-07 21:30:36,797 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) Connector bisocket://192.168.56.102:4457 has leasing enabled, lease period 25000 milliseconds
> 2013-09-07 21:30:36,797 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered connection factory jboss.messaging.connectionfactory:service=ConnectionFactory
> 2013-09-07 21:30:36,797 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) org.jboss.jms.server.connectionfactory.ConnectionFactory at 467463b3 started
> 2013-09-07 21:30:37,207 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) Connector servlet://192.168.56.102:8080 has leasing enabled, lease period 25000 milliseconds
> 2013-09-07 21:30:37,207 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered connection factory jboss.messaging.connectionfactory:service=ServletConnectionFactory
> 2013-09-07 21:30:37,207 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) org.jboss.jms.server.connectionfactory.ConnectionFactory at 21fdb35f started
> 2013-09-07 21:30:37,440 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) Connector bisocket://192.168.56.102:4457 has leasing enabled, lease period 25000 milliseconds
> 2013-09-07 21:30:37,441 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered connection factory jboss.messaging.connectionfactory:service=ClusteredConnectionFactory
> 2013-09-07 21:30:37,441 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) org.jboss.jms.server.connectionfactory.ConnectionFactory at 443578f2 started
> 2013-09-07 21:30:41,483 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) Connector bisocket://192.168.56.102:4457 has leasing enabled, lease period 25000 milliseconds
> 2013-09-07 21:30:41,483 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered connection factory jboss.messaging.connectionfactory:service=ClusterPullConnectionFactory
> 2013-09-07 21:30:41,483 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) org.jboss.jms.server.connectionfactory.ConnectionFactory at ecdede5 started
> 2013-09-07 21:30:41,483 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered destination jboss.messaging.destination:service=Queue,name=ExpiryQueue
> 2013-09-07 21:30:41,715 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-75) Queue[/queue/ExpiryQueue] started, fullSize=200000, pageSize=2000, downCacheSize=2000
> 2013-09-07 21:30:41,715 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered destination jboss.messaging.destination:service=Queue,name=DLQ
> 2013-09-07 21:30:42,259 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-75) Queue[/queue/DLQ] started, fullSize=200000, pageSize=2000, downCacheSize=2000
> 2013-09-07 21:30:42,259 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered destination jboss.messaging.destination:service=Queue,name=ISXO_AuditLogQueue_01
> 2013-09-07 21:30:42,495 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-75) Queue[/ISXO/AuditLogQueue, name=ISXO_AuditLogQueue_01] started, fullSize=200000, pageSize=2000, downCacheSize=20
> 2013-09-07 21:30:42,495 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered destination jboss.messaging.destination:service=Queue,name=ISXO_CiscoUCSEventQueue_01
> 2013-09-07 21:30:42,923 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-75) Queue[/ISXO/CiscoUCSEventQueue, name=ISXO_CiscoUCSEventQueue_01] started, fullSize=200000, pageSize=2000, downCa
> 2013-09-07 21:30:42,923 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered destination jboss.messaging.destination:service=Topic,name=ISXO_RemoteEventQueue_01
> 2013-09-07 21:30:43,122 INFO  [org.jboss.jms.server.destination.TopicService] (Thread-75) Topic[/ISXO/RemoteEventTopic, name=ISXO_RemoteEventQueue_01] started, fullSize=200000, pageSize=2000, downCacheS
> 2013-09-07 21:30:43,122 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered destination jboss.messaging.destination:service=Queue,name=ISXO_ScheduledJobQueue_01
> 2013-09-07 21:30:43,559 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-75) Queue[/ISXO/ScheduledJobQueue, name=ISXO_ScheduledJobQueue_01] started, fullSize=200000, pageSize=2000, downCach
> 2013-09-07 21:30:43,559 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) JBM node restarted.
> Stack trace the ?java.lang.IllegalStateException: Destination queue.ISXO_AuditLogQueue_01 not active?
> Daemon Thread [ISXOSchedulerPrioritized_Worker-1] (Suspended (breakpoint at line 3046 in MessagingPostOffice))	
> 	owns: AtomicAction  (id=519)	
> 	MessagingPostOffice.routeInternal(MessageReference, Condition, Transaction, boolean, Set) line: 3046	
> 	MessagingPostOffice.route(MessageReference, Condition, Transaction) line: 983	
> 	ServerConnectionEndpoint.sendMessage(JBossMessage, Transaction, boolean) line: 796	
> 	ServerConnectionEndpoint.processTransaction(ClientTransaction, Transaction, boolean) line: 852	
> 	ServerConnectionEndpoint.sendTransaction(TransactionRequest, boolean) line: 516	
> 	ConnectionAdvised.org$jboss$jms$server$endpoint$advised$ConnectionAdvised$sendTransaction$aop(TransactionRequest, boolean) line: 106	
> 	ConnectionAdvised$sendTransaction_N3268650789275322226.invokeTarget() line: not available	
> 	ConnectionAdvised$sendTransaction_N3268650789275322226(MethodInvocation).invokeNext() line: 111	
> 	SecurityAspect.handleSendTransaction(Invocation) line: 200	
> 	NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]	
> 	NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39	
> 	DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25	
> 	Method.invoke(Object, Object...) line: 597	
> 	PerInstanceAdvice.invoke(Invocation) line: 122	
> 	ConnectionAdvised$sendTransaction_N3268650789275322226(MethodInvocation).invokeNext() line: 102	
> 	ServerLogInterceptor.invoke(Invocation) line: 105	
> 	ConnectionAdvised$sendTransaction_N3268650789275322226(MethodInvocation).invokeNext() line: 102	
> 	ConnectionAdvised.sendTransaction(TransactionRequest, boolean) line: not available	
> 	ConnectionSendTransactionRequest.serverInvoke() line: 86	
> 	JMSServerInvocationHandler.invoke(InvocationRequest) line: 165	
> 	BisocketServerInvoker(ServerInvoker).invoke(InvocationRequest) line: 930	
> 	LocalClientInvoker.invoke(InvocationRequest) line: 106	
> 	Client.invoke(Object, Map, InvokerLocator) line: 2034	
> 	Client.invoke(Object, Map) line: 877	
> 	Client.invoke(Object) line: 865	
> 	ClientConnectionDelegate(DelegateSupport).doInvoke(Client, RequestSupport, boolean) line: 189	
> 	ClientConnectionDelegate(DelegateSupport).doInvoke(Client, RequestSupport) line: 160	
> 	ClientConnectionDelegate.org$jboss$jms$client$delegate$ClientConnectionDelegate$sendTransaction$aop(TransactionRequest, boolean) line: 241	
> 	ClientConnectionDelegate$sendTransaction_N3268650789275322226.invokeTarget() line: not available	
> 	ClientConnectionDelegate$sendTransaction_N3268650789275322226(MethodInvocation).invokeNext() line: 111	
> 	FailoverValveInterceptor.invoke(Invocation) line: 92	
> 	PerInstanceInterceptor.invoke(Invocation) line: 86	
> 	ClientConnectionDelegate$sendTransaction_N3268650789275322226(MethodInvocation).invokeNext() line: 102	
> 	ClosedInterceptor.invoke(Invocation) line: 172	
> 	PerInstanceInterceptor.invoke(Invocation) line: 86	
> 	ClientConnectionDelegate$sendTransaction_N3268650789275322226(MethodInvocation).invokeNext() line: 102	
> 	ClientConnectionDelegate.sendTransaction(TransactionRequest, boolean) line: not available	
> 	ResourceManager.sendTransactionXA(TransactionRequest, ConnectionDelegate) line: 712	
> 	ResourceManager.commit(Xid, boolean, ConnectionDelegate) line: 392	
> 	MessagingXAResource.commit(Xid, boolean) line: 275	
> 	JmsXAResource.commit(Xid, boolean) line: 98	
> 	XAResourceRecord.topLevelOnePhaseCommit() line: 811	
> 	AtomicAction(BasicAction).onePhaseCommit(boolean) line: 2656	
> 	AtomicAction(BasicAction).End(boolean) line: 1784	
> 	AtomicAction(TwoPhaseCoordinator).end(boolean) line: 94	
> 	AtomicAction(AtomicAction).commit(boolean) line: 160	
> 	TransactionImple.commitAndDisassociate() line: 1431	
> 	TransactionManagerImple(BaseTransaction).commit() line: 137	
> 	TransactionManagerDelegate(BaseTransactionManagerDelegate).commit() line: 75	
> 	Ejb3TxPolicy(TxPolicy).endTransaction(TransactionManager, Transaction) line: 170	
> 	Ejb3TxPolicy(TxPolicy).invokeInOurTx(Invocation, TransactionManager) line: 87	
> 	TxInterceptor$Required.invoke(Invocation) line: 190	
> 	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
> 	TxPropagationInterceptor.invoke(Invocation) line: 76	
> 	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
> 	NullInterceptor.invoke(Invocation) line: 42	
> 	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
> 	Ejb3AuthenticationInterceptorv2.invoke(Invocation) line: 182	
> 	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
> 	ENCPropagationInterceptor.invoke(Invocation) line: 41	
> 	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
> 	BlockContainerShutdownInterceptor.invoke(Invocation) line: 67	
> 	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
> 	CurrentInvocationContextInterceptor.invoke(Invocation) line: 47	
> 	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
> 	CurrentInvocationInterceptor.invoke(Invocation) line: 67	
> 	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
> 	EJB3TCCLInterceptor.invoke(Invocation) line: 86	
> 	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
> 	StatelessContainer(SessionSpecContainer).invoke(Serializable, SerializableMethod, Object[]) line: 193	
> 	StatelessContainer(SessionSpecContainer).invoke(Object, SerializableMethod, Object[]) line: 250	
> 	SessionLocalProxyInvocationHandler(SessionProxyInvocationHandlerBase).invoke(Object, Method, Object[]) line: 188	
> 	$Proxy702.publishMessages(EventSet) line: not available	
> 	NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]	
> 	NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39	
> 	DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25	
> 	Method.invoke(Object, Object...) line: 597	
> 	ClusteredEJB3InvokerJob(EJB3InvokerJob).invokeEjb(Object, JobExecutionContext) line: 196	
> 	ClusteredEJB3InvokerJob(EJB3InvokerJob).doExecute(JobExecutionContext) line: 141	
> 	ClusteredEJB3InvokerJob(EJB3InvokerJob).execute(JobExecutionContext) line: 78	
> 	JobRunShell.run() line: 203	
> 	SimpleThreadPool$WorkerThread.run() line: 520
> Update
> ========
> After debugging the code to understand what is going on I'm pretty sure we have situation where it use an old ServerConnectionEndpoint with a old postoffice instance. In our case we have a bean(stateless) that inject the TopicConnectionFactory and and Topic as resource this could possible reuse an old connection?
> I can see that sometimes it get an instance of ServerConnectionEndpoint which contains a reference to the current server peer and to the old post office. The server peer instance actual holde the reference to the new post office, but because the postoffice variable is only set on constructor level this is never changed. 
> Furthermore I can see the start method in ConnectionFactory was creating a listener that listens for failed connections, but this was not removed when the service stopped. After I removed the listener when the ConnectionFactory is stopped,  and restarted i'm able to receive updates again and it does not fail with a  "java.lang.IllegalStateException: Destination queue.MyQueue not active"

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Thu Oct  3 07:26:03 2013
From: jira-events at lists.jboss.org (Flemming Harms (JIRA))
Date: Thu, 3 Oct 2013 07:26:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1948)
 java.lang.IllegalStateException: Destination queue.ISXO_AuditLogQueue_01
 not active after MessagingClusterHealthMBean restart JMS service
In-Reply-To: <JIRA.12502101.1380799169000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502101.1380799169000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502101.1380799169000.11847.1380799563580@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Flemming Harms updated JBMESSAGING-1948:
----------------------------------------

    Attachment: ConnectionFactory-diff.patch


Suggested patch for clean up listeners after JMS restart
                
> java.lang.IllegalStateException: Destination queue.ISXO_AuditLogQueue_01 not active after MessagingClusterHealthMBean restart JMS service
> -----------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1948
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1948
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.8.SP9
>            Reporter: Flemming Harms
>         Attachments: ConnectionFactory-diff.patch, postoffice-patch.diff
>
>
> I get this error ?java.lang.IllegalStateException: Destination queue.ISXO_AuditLogQueue_01 not active? after MessagingClusterHealthMBean restarts the JMS service with JBoss Messaging 1.4.8.SP9. 
> I have 2 node JBoss5 cluster with JBoss Messaging and I have enabled the new failover model and setup the MessagingClusterHealthMBean to monitor split brain.
> I disconnect the cable from one of the servers MessagingClusterHealthMBean discover it?s alone and shut down the JMS service as expected. After a while I connect the server again and the server discover the other server and MessagingClusterHealthMBean starts the JMS service also as expected.
> But when I connect a client it fails with ?java.lang.IllegalStateException: Destination queue.ISXO_AuditLogQueue_01 not active? and what I can see in the debugger ServerConnectionEndpoint have reference to the old post office where the queue is still exits in the inactiveConditions Set.
> Log from the server when it discover it?s alone and it restart the service again
> 2013-09-07 21:29:06,381 ERROR [org.jboss.messaging.core.impl.postoffice.MessagingPostOffice] (Thread-32) I'm orphaned and now I can't tell others that I'm alive. Shutdown node: 102
> 2013-09-07 21:29:09,728 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-32) Stopping JBM node on DB failure...
> 2013-09-07 21:29:09,731 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-32) Queue[/queue/ExpiryQueue] stopped
> 2013-09-07 21:29:09,732 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-32) Queue[/queue/DLQ] stopped
> 2013-09-07 21:29:09,733 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-32) Queue[/ISXO/AuditLogQueue, name=ISXO_AuditLogQueue_01] stopped
> 2013-09-07 21:29:09,733 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-32) Queue[/ISXO/CiscoUCSEventQueue, name=ISXO_CiscoUCSEventQueue_01] stopped
> 2013-09-07 21:29:09,738 INFO  [org.jboss.jms.server.destination.TopicService] (Thread-32) Topic[/ISXO/RemoteEventTopic, name=ISXO_RemoteEventQueue_01] stopped
> 2013-09-07 21:29:09,739 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-32) Queue[/ISXO/ScheduledJobQueue, name=ISXO_ScheduledJobQueue_01] stopped
> 2013-09-07 21:29:11,210 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-32) org.jboss.jms.server.connectionfactory.ConnectionFactory at 366480d7 undeployed
> 2013-09-07 21:29:11,216 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-32) org.jboss.jms.server.connectionfactory.ConnectionFactory at 467463b3 undeployed
> 2013-09-07 21:29:11,216 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-32) org.jboss.jms.server.connectionfactory.ConnectionFactory at 21fdb35f undeployed
> 2013-09-07 21:29:11,216 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-32) org.jboss.jms.server.connectionfactory.ConnectionFactory at 443578f2 undeployed
> 2013-09-07 21:29:11,235 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-32) org.jboss.jms.server.connectionfactory.ConnectionFactory at ecdede5 undeployed
> 2013-09-07 21:29:11,298 ERROR [org.jgroups.blocks.ConnectionTable] (OOB-43,192.168.56.102:7900) failed sending data to 192.168.56.101:7900: java.net.SocketException: Socket closed
> 2013-09-07 21:29:14,413 WARN  [org.jgroups.protocols.pbcast.NAKACK] (OOB-19,192.168.56.102:55200) 192.168.56.102:55200] discarded message from non-member 192.168.56.101:55200, my view is [192.168.56.102
> 2013-09-07 21:29:14,863 WARN  [org.jgroups.protocols.pbcast.NAKACK] (OOB-19,192.168.56.102:55200) 192.168.56.102:55200] discarded message from non-member 192.168.56.101:55200, my view is [192.168.56.102
> 2013-09-07 21:29:21,080 INFO  [org.jboss.jms.server.ServerPeer] (Thread-32) JMS ServerPeer[102] stopped
> 2013-09-07 21:29:21,090 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-32) JBM node is stopped.
> 2013-09-07 21:29:21,090 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] (Incoming-2,192.168.56.102:55200) Dead members: 1 ([192.168.56.101:55200])
> 2013-09-07 21:29:21,090 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] (Incoming-2,192.168.56.102:55200) All Members : 1 ([192.168.56.102:55200])
> 2013-09-07 21:30:24,666 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Restarting JBM node...
> 2013-09-07 21:30:33,369 INFO  [org.jboss.jms.server.ServerPeer] (Thread-75) JBoss Messaging 1.4.8.SP9 server [102] started
> 2013-09-07 21:30:33,459 INFO  [STDOUT] (Thread-75) 
> ---------------------------------------------------------
> GMS: address is 192.168.56.102:55200 (cluster=DefaultPartition-JMS-CTRL)
> ---------------------------------------------------------
> 2013-09-07 21:30:33,524 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] (Thread-75) org.jboss.messaging.core.impl.postoffice.GroupMember$ControlMembershipListener at 6a500238 got new view [192
> 2013-09-07 21:30:33,525 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] (Thread-75) I am (192.168.56.102:55200)
> 2013-09-07 21:30:33,525 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] (Thread-75) New Members : 2 ([192.168.56.101:55200, 192.168.56.102:55200])
> 2013-09-07 21:30:33,525 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] (Thread-75) All Members : 2 ([192.168.56.101:55200, 192.168.56.102:55200])
> 2013-09-07 21:30:33,570 INFO  [STDOUT] (pool-151-thread-1) 
> ---------------------------------------------------------
> GMS: address is 192.168.56.102:7900 (cluster=DefaultPartition-JMS-DATA)
> ---------------------------------------------------------
> 2013-09-07 21:30:33,779 INFO  [org.jboss.messaging.core.impl.postoffice.MessagingPostOffice] (Thread-75) Waiting for JGroups...
> 2013-09-07 21:30:33,784 INFO  [org.jboss.messaging.core.impl.postoffice.MessagingPostOffice] (Thread-75) JGroups starts to work again, initializing state
> 2013-09-07 21:30:33,785 INFO  [org.jboss.messaging.core.impl.postoffice.MessagingPostOffice] (Thread-75) Now node is ready for work.
> 2013-09-07 21:30:34,896 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) Connector sslbisocket://192.168.56.102:4459 has leasing enabled, lease period 25000 milliseconds
> 2013-09-07 21:30:34,896 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered connection factory jboss.messaging.connectionfactory:service=SSLConnectionFactory
> 2013-09-07 21:30:34,896 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) org.jboss.jms.server.connectionfactory.ConnectionFactory at 366480d7 started
> 2013-09-07 21:30:36,797 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) Connector bisocket://192.168.56.102:4457 has leasing enabled, lease period 25000 milliseconds
> 2013-09-07 21:30:36,797 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered connection factory jboss.messaging.connectionfactory:service=ConnectionFactory
> 2013-09-07 21:30:36,797 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) org.jboss.jms.server.connectionfactory.ConnectionFactory at 467463b3 started
> 2013-09-07 21:30:37,207 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) Connector servlet://192.168.56.102:8080 has leasing enabled, lease period 25000 milliseconds
> 2013-09-07 21:30:37,207 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered connection factory jboss.messaging.connectionfactory:service=ServletConnectionFactory
> 2013-09-07 21:30:37,207 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) org.jboss.jms.server.connectionfactory.ConnectionFactory at 21fdb35f started
> 2013-09-07 21:30:37,440 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) Connector bisocket://192.168.56.102:4457 has leasing enabled, lease period 25000 milliseconds
> 2013-09-07 21:30:37,441 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered connection factory jboss.messaging.connectionfactory:service=ClusteredConnectionFactory
> 2013-09-07 21:30:37,441 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) org.jboss.jms.server.connectionfactory.ConnectionFactory at 443578f2 started
> 2013-09-07 21:30:41,483 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) Connector bisocket://192.168.56.102:4457 has leasing enabled, lease period 25000 milliseconds
> 2013-09-07 21:30:41,483 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered connection factory jboss.messaging.connectionfactory:service=ClusterPullConnectionFactory
> 2013-09-07 21:30:41,483 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) org.jboss.jms.server.connectionfactory.ConnectionFactory at ecdede5 started
> 2013-09-07 21:30:41,483 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered destination jboss.messaging.destination:service=Queue,name=ExpiryQueue
> 2013-09-07 21:30:41,715 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-75) Queue[/queue/ExpiryQueue] started, fullSize=200000, pageSize=2000, downCacheSize=2000
> 2013-09-07 21:30:41,715 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered destination jboss.messaging.destination:service=Queue,name=DLQ
> 2013-09-07 21:30:42,259 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-75) Queue[/queue/DLQ] started, fullSize=200000, pageSize=2000, downCacheSize=2000
> 2013-09-07 21:30:42,259 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered destination jboss.messaging.destination:service=Queue,name=ISXO_AuditLogQueue_01
> 2013-09-07 21:30:42,495 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-75) Queue[/ISXO/AuditLogQueue, name=ISXO_AuditLogQueue_01] started, fullSize=200000, pageSize=2000, downCacheSize=20
> 2013-09-07 21:30:42,495 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered destination jboss.messaging.destination:service=Queue,name=ISXO_CiscoUCSEventQueue_01
> 2013-09-07 21:30:42,923 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-75) Queue[/ISXO/CiscoUCSEventQueue, name=ISXO_CiscoUCSEventQueue_01] started, fullSize=200000, pageSize=2000, downCa
> 2013-09-07 21:30:42,923 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered destination jboss.messaging.destination:service=Topic,name=ISXO_RemoteEventQueue_01
> 2013-09-07 21:30:43,122 INFO  [org.jboss.jms.server.destination.TopicService] (Thread-75) Topic[/ISXO/RemoteEventTopic, name=ISXO_RemoteEventQueue_01] started, fullSize=200000, pageSize=2000, downCacheS
> 2013-09-07 21:30:43,122 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered destination jboss.messaging.destination:service=Queue,name=ISXO_ScheduledJobQueue_01
> 2013-09-07 21:30:43,559 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-75) Queue[/ISXO/ScheduledJobQueue, name=ISXO_ScheduledJobQueue_01] started, fullSize=200000, pageSize=2000, downCach
> 2013-09-07 21:30:43,559 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) JBM node restarted.
> Stack trace the ?java.lang.IllegalStateException: Destination queue.ISXO_AuditLogQueue_01 not active?
> Daemon Thread [ISXOSchedulerPrioritized_Worker-1] (Suspended (breakpoint at line 3046 in MessagingPostOffice))	
> 	owns: AtomicAction  (id=519)	
> 	MessagingPostOffice.routeInternal(MessageReference, Condition, Transaction, boolean, Set) line: 3046	
> 	MessagingPostOffice.route(MessageReference, Condition, Transaction) line: 983	
> 	ServerConnectionEndpoint.sendMessage(JBossMessage, Transaction, boolean) line: 796	
> 	ServerConnectionEndpoint.processTransaction(ClientTransaction, Transaction, boolean) line: 852	
> 	ServerConnectionEndpoint.sendTransaction(TransactionRequest, boolean) line: 516	
> 	ConnectionAdvised.org$jboss$jms$server$endpoint$advised$ConnectionAdvised$sendTransaction$aop(TransactionRequest, boolean) line: 106	
> 	ConnectionAdvised$sendTransaction_N3268650789275322226.invokeTarget() line: not available	
> 	ConnectionAdvised$sendTransaction_N3268650789275322226(MethodInvocation).invokeNext() line: 111	
> 	SecurityAspect.handleSendTransaction(Invocation) line: 200	
> 	NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]	
> 	NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39	
> 	DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25	
> 	Method.invoke(Object, Object...) line: 597	
> 	PerInstanceAdvice.invoke(Invocation) line: 122	
> 	ConnectionAdvised$sendTransaction_N3268650789275322226(MethodInvocation).invokeNext() line: 102	
> 	ServerLogInterceptor.invoke(Invocation) line: 105	
> 	ConnectionAdvised$sendTransaction_N3268650789275322226(MethodInvocation).invokeNext() line: 102	
> 	ConnectionAdvised.sendTransaction(TransactionRequest, boolean) line: not available	
> 	ConnectionSendTransactionRequest.serverInvoke() line: 86	
> 	JMSServerInvocationHandler.invoke(InvocationRequest) line: 165	
> 	BisocketServerInvoker(ServerInvoker).invoke(InvocationRequest) line: 930	
> 	LocalClientInvoker.invoke(InvocationRequest) line: 106	
> 	Client.invoke(Object, Map, InvokerLocator) line: 2034	
> 	Client.invoke(Object, Map) line: 877	
> 	Client.invoke(Object) line: 865	
> 	ClientConnectionDelegate(DelegateSupport).doInvoke(Client, RequestSupport, boolean) line: 189	
> 	ClientConnectionDelegate(DelegateSupport).doInvoke(Client, RequestSupport) line: 160	
> 	ClientConnectionDelegate.org$jboss$jms$client$delegate$ClientConnectionDelegate$sendTransaction$aop(TransactionRequest, boolean) line: 241	
> 	ClientConnectionDelegate$sendTransaction_N3268650789275322226.invokeTarget() line: not available	
> 	ClientConnectionDelegate$sendTransaction_N3268650789275322226(MethodInvocation).invokeNext() line: 111	
> 	FailoverValveInterceptor.invoke(Invocation) line: 92	
> 	PerInstanceInterceptor.invoke(Invocation) line: 86	
> 	ClientConnectionDelegate$sendTransaction_N3268650789275322226(MethodInvocation).invokeNext() line: 102	
> 	ClosedInterceptor.invoke(Invocation) line: 172	
> 	PerInstanceInterceptor.invoke(Invocation) line: 86	
> 	ClientConnectionDelegate$sendTransaction_N3268650789275322226(MethodInvocation).invokeNext() line: 102	
> 	ClientConnectionDelegate.sendTransaction(TransactionRequest, boolean) line: not available	
> 	ResourceManager.sendTransactionXA(TransactionRequest, ConnectionDelegate) line: 712	
> 	ResourceManager.commit(Xid, boolean, ConnectionDelegate) line: 392	
> 	MessagingXAResource.commit(Xid, boolean) line: 275	
> 	JmsXAResource.commit(Xid, boolean) line: 98	
> 	XAResourceRecord.topLevelOnePhaseCommit() line: 811	
> 	AtomicAction(BasicAction).onePhaseCommit(boolean) line: 2656	
> 	AtomicAction(BasicAction).End(boolean) line: 1784	
> 	AtomicAction(TwoPhaseCoordinator).end(boolean) line: 94	
> 	AtomicAction(AtomicAction).commit(boolean) line: 160	
> 	TransactionImple.commitAndDisassociate() line: 1431	
> 	TransactionManagerImple(BaseTransaction).commit() line: 137	
> 	TransactionManagerDelegate(BaseTransactionManagerDelegate).commit() line: 75	
> 	Ejb3TxPolicy(TxPolicy).endTransaction(TransactionManager, Transaction) line: 170	
> 	Ejb3TxPolicy(TxPolicy).invokeInOurTx(Invocation, TransactionManager) line: 87	
> 	TxInterceptor$Required.invoke(Invocation) line: 190	
> 	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
> 	TxPropagationInterceptor.invoke(Invocation) line: 76	
> 	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
> 	NullInterceptor.invoke(Invocation) line: 42	
> 	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
> 	Ejb3AuthenticationInterceptorv2.invoke(Invocation) line: 182	
> 	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
> 	ENCPropagationInterceptor.invoke(Invocation) line: 41	
> 	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
> 	BlockContainerShutdownInterceptor.invoke(Invocation) line: 67	
> 	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
> 	CurrentInvocationContextInterceptor.invoke(Invocation) line: 47	
> 	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
> 	CurrentInvocationInterceptor.invoke(Invocation) line: 67	
> 	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
> 	EJB3TCCLInterceptor.invoke(Invocation) line: 86	
> 	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
> 	StatelessContainer(SessionSpecContainer).invoke(Serializable, SerializableMethod, Object[]) line: 193	
> 	StatelessContainer(SessionSpecContainer).invoke(Object, SerializableMethod, Object[]) line: 250	
> 	SessionLocalProxyInvocationHandler(SessionProxyInvocationHandlerBase).invoke(Object, Method, Object[]) line: 188	
> 	$Proxy702.publishMessages(EventSet) line: not available	
> 	NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]	
> 	NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39	
> 	DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25	
> 	Method.invoke(Object, Object...) line: 597	
> 	ClusteredEJB3InvokerJob(EJB3InvokerJob).invokeEjb(Object, JobExecutionContext) line: 196	
> 	ClusteredEJB3InvokerJob(EJB3InvokerJob).doExecute(JobExecutionContext) line: 141	
> 	ClusteredEJB3InvokerJob(EJB3InvokerJob).execute(JobExecutionContext) line: 78	
> 	JobRunShell.run() line: 203	
> 	SimpleThreadPool$WorkerThread.run() line: 520
> Update
> ========
> After debugging the code to understand what is going on I'm pretty sure we have situation where it use an old ServerConnectionEndpoint with a old postoffice instance. In our case we have a bean(stateless) that inject the TopicConnectionFactory and and Topic as resource this could possible reuse an old connection?
> I can see that sometimes it get an instance of ServerConnectionEndpoint which contains a reference to the current server peer and to the old post office. The server peer instance actual holde the reference to the new post office, but because the postoffice variable is only set on constructor level this is never changed. 
> Furthermore I can see the start method in ConnectionFactory was creating a listener that listens for failed connections, but this was not removed when the service stopped. After I removed the listener when the ConnectionFactory is stopped,  and restarted i'm able to receive updates again and it does not fail with a  "java.lang.IllegalStateException: Destination queue.MyQueue not active"

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Thu Oct  3 08:39:02 2013
From: jira-events at lists.jboss.org (Richard Bourner (JIRA))
Date: Thu, 3 Oct 2013 08:39:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-276) Stream mode with CR4-Pre1
 generates rules looping
In-Reply-To: <JIRA.12501742.1380290941000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501742.1380290941000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501742.1380290941000.11982.1380803942737@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809162#comment-12809162 ] 

Richard Bourner commented on DROOLS-276:
----------------------------------------

A little precision: it appears that the problem occurs only with Phreak algo in Stream mode.
In the unit test I created, I had not included the reteoo JAR, so it was redirected to Phreak without my noticing.
Bottom line: out of 4 unit tests, only 1 fails now.
                
>  Stream mode with CR4-Pre1 generates rules looping
> --------------------------------------------------
>
>                 Key: DROOLS-276
>                 URL: https://issues.jboss.org/browse/DROOLS-276
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>         Environment: Drools 6.0.0.CR4-Pre1
>            Reporter: Richard Bourner
>            Assignee: Mark Proctor
>            Priority: Blocker
>         Attachments: Drools6Stream.zip
>
>
> When in STREAM mode, our rules are looping because of an update.
> The attached example doesn't demonstrate the looping but one rule is fired twice where it should only fire once. We are supposing that the issue is the same.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct  3 08:39:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 3 Oct 2013 08:39:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-276) Stream mode with CR4-Pre1
 generates rules looping
In-Reply-To: <JIRA.12501742.1380290941000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501742.1380290941000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501742.1380290941000.11989.1380803943059@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809163#comment-12809163 ] 

RH Bugzilla Integration commented on DROOLS-276:
------------------------------------------------

Richard Bourner <rbourner at redhat.com> made a comment on [bug 1012933|https://bugzilla.redhat.com/show_bug.cgi?id=1012933]

A little precision: it appears that the problem occurs only with Phreak algo in Stream mode.
In the unit tests I created, I had not included the reteoo JAR, so it was redirected to Phreak without my noticing.
Bottom line: out of 4 unit tests, only 1 fails now.
                
>  Stream mode with CR4-Pre1 generates rules looping
> --------------------------------------------------
>
>                 Key: DROOLS-276
>                 URL: https://issues.jboss.org/browse/DROOLS-276
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>         Environment: Drools 6.0.0.CR4-Pre1
>            Reporter: Richard Bourner
>            Assignee: Mark Proctor
>            Priority: Blocker
>         Attachments: Drools6Stream.zip
>
>
> When in STREAM mode, our rules are looping because of an update.
> The attached example doesn't demonstrate the looping but one rule is fired twice where it should only fire once. We are supposing that the issue is the same.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct  3 08:51:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 3 Oct 2013 08:51:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1714) Discovery: data in PingHeader
 might be too large in big clusters
In-Reply-To: <JIRA.12502090.1380796496000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502090.1380796496000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502090.1380796496000.12000.1380804662621@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1714:
---------------------------

    Fix Version/s: 3.5
                       (was: 3.4)

    
> Discovery: data in PingHeader might be too large in big clusters
> ----------------------------------------------------------------
>
>                 Key: JGRP-1714
>                 URL: https://issues.jboss.org/browse/JGRP-1714
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> Similar to JGRP-1710 and JGRP-1713, investigate {{PingHeader}}. Probable solution: move {{PingHeader.PingData}} from the header to the message body

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct  3 08:57:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 3 Oct 2013 08:57:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1714) Discovery: data in PingHeader
 might be too large in big clusters
In-Reply-To: <JIRA.12502090.1380796496000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502090.1380796496000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502090.1380796496000.12005.1380805022744@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809167#comment-12809167 ] 

Bela Ban commented on JGRP-1714:
--------------------------------

Investigate headers which might become too big, and move their contents into the message body. Check all headers which contain
* a view
* a digest
* a list of members
                
> Discovery: data in PingHeader might be too large in big clusters
> ----------------------------------------------------------------
>
>                 Key: JGRP-1714
>                 URL: https://issues.jboss.org/browse/JGRP-1714
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> Similar to JGRP-1710 and JGRP-1713, investigate {{PingHeader}}. Probable solution: move {{PingHeader.PingData}} from the header to the message body

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct  3 08:57:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 3 Oct 2013 08:57:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1714) Headers: data in some headers
 might be too large in big clusters
In-Reply-To: <JIRA.12502090.1380796496000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502090.1380796496000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502090.1380796496000.12010.1380805023036@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1714:
---------------------------

    Summary: Headers: data in some headers might be too large in big clusters  (was: Discovery: data in PingHeader might be too large in big clusters)

    
> Headers: data in some headers might be too large in big clusters
> ----------------------------------------------------------------
>
>                 Key: JGRP-1714
>                 URL: https://issues.jboss.org/browse/JGRP-1714
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> Similar to JGRP-1710 and JGRP-1713, investigate {{PingHeader}}. Probable solution: move {{PingHeader.PingData}} from the header to the message body

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct  3 08:59:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 3 Oct 2013 08:59:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1714) Headers: data in some headers
 might be too large in big clusters
In-Reply-To: <JIRA.12502090.1380796496000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502090.1380796496000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502090.1380796496000.12014.1380805142658@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1714:
---------------------------

    Description: 
Similar to JGRP-1710 and JGRP-1713, investigate headers which might become too big, and move their contents into the message body. Check all headers which contain
* a view
* a digest
* a list of members

Candidates:
* {{PingHeader}}. 

Probable solution: move {{PingHeader.PingData}} from the header to the message body

  was:Similar to JGRP-1710 and JGRP-1713, investigate {{PingHeader}}. Probable solution: move {{PingHeader.PingData}} from the header to the message body


    
> Headers: data in some headers might be too large in big clusters
> ----------------------------------------------------------------
>
>                 Key: JGRP-1714
>                 URL: https://issues.jboss.org/browse/JGRP-1714
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> Similar to JGRP-1710 and JGRP-1713, investigate headers which might become too big, and move their contents into the message body. Check all headers which contain
> * a view
> * a digest
> * a list of members
> Candidates:
> * {{PingHeader}}. 
> Probable solution: move {{PingHeader.PingData}} from the header to the message body

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct  3 08:59:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 3 Oct 2013 08:59:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1714) Headers: data in some headers
 might be too large in big clusters
In-Reply-To: <JIRA.12502090.1380796496000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502090.1380796496000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502090.1380796496000.12017.1380805142881@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1714:
---------------------------

    Comment: was deleted

(was: Investigate headers which might become too big, and move their contents into the message body. Check all headers which contain
* a view
* a digest
* a list of members)

    
> Headers: data in some headers might be too large in big clusters
> ----------------------------------------------------------------
>
>                 Key: JGRP-1714
>                 URL: https://issues.jboss.org/browse/JGRP-1714
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> Similar to JGRP-1710 and JGRP-1713, investigate headers which might become too big, and move their contents into the message body. Check all headers which contain
> * a view
> * a digest
> * a list of members
> Candidates:
> * {{PingHeader}}. 
> Probable solution: move {{PingHeader.PingData}} from the header to the message body

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct  3 09:06:02 2013
From: jira-events at lists.jboss.org (Richard Bourner (JIRA))
Date: Thu, 3 Oct 2013 09:06:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-281) no reevaluation of 'from
 collect' is performed
In-Reply-To: <JIRA.12502111.1380805492977@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502111.1380805492977@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502111.1380805492977.12028.1380805562724@jira02.app.mwc.hst.phx2.redhat.com>

Richard Bourner created DROOLS-281:
--------------------------------------

             Summary: no reevaluation of 'from collect' is performed
                 Key: DROOLS-281
                 URL: https://issues.jboss.org/browse/DROOLS-281
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  6.0.0.CR4
            Reporter: Richard Bourner
            Assignee: Mark Proctor
            Priority: Critical


Using Drools 6.0.0.CR4, a problem has been found related to reevaluation of a condition that contains a 'from collect' statement.
A unit test is provided demonstrating the issue using 2 rules.  This unit test works fine using 6.0.0.Beta2.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct  3 09:08:02 2013
From: jira-events at lists.jboss.org (Richard Bourner (JIRA))
Date: Thu, 3 Oct 2013 09:08:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-281) no reevaluation of 'from
 collect' is performed
In-Reply-To: <JIRA.12502111.1380805492000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502111.1380805492000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502111.1380805492000.12034.1380805682922@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Bourner updated DROOLS-281:
-----------------------------------

    Attachment: Drools6FromCollectIssue.zip


Maven Eclipse project demonstrating the issue with 2 rules and 1 unit test.
                
> no reevaluation of 'from collect' is performed
> ----------------------------------------------
>
>                 Key: DROOLS-281
>                 URL: https://issues.jboss.org/browse/DROOLS-281
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>            Reporter: Richard Bourner
>            Assignee: Mark Proctor
>            Priority: Critical
>         Attachments: Drools6FromCollectIssue.zip
>
>
> Using Drools 6.0.0.CR4, a problem has been found related to reevaluation of a condition that contains a 'from collect' statement.
> A unit test is provided demonstrating the issue using 2 rules.  This unit test works fine using 6.0.0.Beta2.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct  3 09:10:02 2013
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Thu, 3 Oct 2013 09:10:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2210) fix message endpoint
	isDeliveryTransacted
In-Reply-To: <JIRA.12502112.1380805704818@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502112.1380805704818@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502112.1380805704818.12043.1380805802597@jira02.app.mwc.hst.phx2.redhat.com>

Jeff Mesnil created WFLY-2210:
---------------------------------

             Summary: fix message endpoint isDeliveryTransacted
                 Key: WFLY-2210
                 URL: https://issues.jboss.org/browse/WFLY-2210
             Project: WildFly
          Issue Type: Bug
          Components: EJB
    Affects Versions: 8.0.0.Alpha4
            Reporter: Jeff Mesnil
            Assignee: Jeff Mesnil
            Priority: Blocker
             Fix For: 8.0.0.Beta1


The org.jboss.as.ejb3.inflow.MessageEndpointService#isDeliveryTransacted method is checking the transaction attribute of the method using the MethodIntf.BEAN while it should use the MethodIntf.MESSAGE_ENDPOINT type.



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct  3 09:10:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 3 Oct 2013 09:10:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1713) MERGE3: view in header is too
 big in large clusters
In-Reply-To: <JIRA.12502089.1380796181000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502089.1380796181000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502089.1380796181000.12046.1380805802741@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1713.
----------------------------

    Resolution: Done

    
> MERGE3: view in header is too big in large clusters
> ---------------------------------------------------
>
>                 Key: JGRP-1713
>                 URL: https://issues.jboss.org/browse/JGRP-1713
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> In MERGE3, as a response to a VIEW_REQ, a VIEW_RSP contains the entire view (not a delta view), and because this is returned in the header, we might run into the same issue as in https://issues.jboss.org/browse/JGRP-1710.
> SOLUTION:
> Move the view carried with a VIEW_RSP into the message body and add FRAG2 over the transport to fragment this message.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct  3 09:12:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 3 Oct 2013 09:12:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-281) no reevaluation of 'from
 collect' is performed
In-Reply-To: <JIRA.12502111.1380805492000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502111.1380805492000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502111.1380805492000.12058.1380805923044@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809172#comment-12809172 ] 

RH Bugzilla Integration commented on DROOLS-281:
------------------------------------------------

Richard Bourner <rbourner at redhat.com> made a comment on [bug 1015109|https://bugzilla.redhat.com/show_bug.cgi?id=1015109]

Description of problem:
Using Drools 6.0.0.CR4, a problem has been found related to reevaluation of a condition that contains a 'from collect' statement.
A unit test is provided demonstrating the issue using 2 rules. This unit test works fine using 6.0.0.Beta2.

Version-Release number of selected component (if applicable):
6.0.0.CR4

How reproducible:
Run the unit test in the attached project.
2 POM are provided:
- 1 for 6.0.0.Beta2 : no problem with this one
- 1 for 6.0.0.CR4 that reproduces the problem

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
                
> no reevaluation of 'from collect' is performed
> ----------------------------------------------
>
>                 Key: DROOLS-281
>                 URL: https://issues.jboss.org/browse/DROOLS-281
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>            Reporter: Richard Bourner
>            Assignee: Mark Proctor
>            Priority: Critical
>         Attachments: Drools6FromCollectIssue.zip
>
>
> Using Drools 6.0.0.CR4, a problem has been found related to reevaluation of a condition that contains a 'from collect' statement.
> A unit test is provided demonstrating the issue using 2 rules.  This unit test works fine using 6.0.0.Beta2.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct  3 09:12:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 3 Oct 2013 09:12:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-281) no reevaluation of 'from
 collect' is performed
In-Reply-To: <JIRA.12502111.1380805492000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502111.1380805492000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502111.1380805492000.12061.1380805923176@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated DROOLS-281:
-------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1015109

    
> no reevaluation of 'from collect' is performed
> ----------------------------------------------
>
>                 Key: DROOLS-281
>                 URL: https://issues.jboss.org/browse/DROOLS-281
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>            Reporter: Richard Bourner
>            Assignee: Mark Proctor
>            Priority: Critical
>         Attachments: Drools6FromCollectIssue.zip
>
>
> Using Drools 6.0.0.CR4, a problem has been found related to reevaluation of a condition that contains a 'from collect' statement.
> A unit test is provided demonstrating the issue using 2 rules.  This unit test works fine using 6.0.0.Beta2.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct  3 09:29:02 2013
From: jira-events at lists.jboss.org (Tanguy Leroux (JIRA))
Date: Thu, 3 Oct 2013 09:29:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-275) RuleEngine
 AfterEvaluator.evaluateCachedRight throws NPE on persisted Session reload
 (Phreak, Stream, PseudoClock)
In-Reply-To: <JIRA.12501735.1380283896000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501735.1380283896000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501735.1380283896000.12120.1380806942760@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809178#comment-12809178 ] 

Tanguy Leroux commented on DROOLS-275:
--------------------------------------

Hi,

Just to let you know, we encountered the same issue on 6.0.0.Beta2: 

java.lang.NullPointerException
	at org.drools.core.base.evaluators.BeforeEvaluatorDefinition$BeforeEvaluator.evaluateCachedLeft(BeforeEvaluatorDefinition.java:318)
	at org.drools.core.rule.constraint.EvaluatorConstraint.isAllowedCachedLeft(EvaluatorConstraint.java:67)
	at org.drools.core.common.TripleBetaConstraints.isAllowedCachedLeft(TripleBetaConstraints.java:91)
	at org.drools.core.reteoo.AccumulateNode.assertLeftTuple(AccumulateNode.java:183)
	at org.drools.core.reteoo.CompositeLeftTupleSinkAdapter.doPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:243)
	at org.drools.core.reteoo.CompositeLeftTupleSinkAdapter.createAndPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:125)
	at org.drools.core.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:230)
	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:498)
	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:383)
	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:365)
	at org.drools.core.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:296)
	at org.drools.core.reteoo.EntryPointNode.assertObject(EntryPointNode.java:265)
	at org.drools.core.marshalling.impl.ProtobufInputMarshaller.assertHandleIntoOTN(ProtobufInputMarshaller.java:469)
	at org.drools.core.marshalling.impl.ProtobufInputMarshaller.readFactHandles(ProtobufInputMarshaller.java:446)
	at org.drools.core.marshalling.impl.ProtobufInputMarshaller.readSession(ProtobufInputMarshaller.java:249)
	at org.drools.core.marshalling.impl.ProtobufInputMarshaller.readSession(ProtobufInputMarshaller.java:154)
	at org.drools.core.marshalling.impl.ProtobufMarshaller.unmarshall(ProtobufMarshaller.java:114)
	at org.drools.core.marshalling.impl.ProtobufMarshaller.unmarshall(ProtobufMarshaller.java:56)



                
> RuleEngine AfterEvaluator.evaluateCachedRight throws NPE on persisted Session reload (Phreak, Stream, PseudoClock)
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-275
>                 URL: https://issues.jboss.org/browse/DROOLS-275
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR3
>         Environment: Mac OS-X 10.8.5, Hotspot 1.7.0_40
>            Reporter: Duncan Doyle
>            Assignee: Mario Fusco
>             Fix For: 6.0.0.CR5
>
>
> I persist a KieSession via the Marshaller (serializable) with one fact/event inserted. On reload of the session, I can see that fact is still there (when I check the FactHandles) and the PseudoClock is at the correct time (the time when I persisted it). If I then insert another fact/event into this reloaded session which matches the following rule:
> rule "SimpleFactTimeWindow"
> when
> 	$s1: SimpleFact() from entry-point LinkyStream
> 	$s2: SimpleFact(this != $s1, this after [0s, 10s] $s1) from entry-point LinkyStream
> then
> 	System.out.println("Rule fired, found 2 Facts within the time window.");
> end
> I get a NPE (in both Phreak and ReteOO mode). Exception in Phreak:
> java.lang.reflect.InvocationTargetException
> 	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.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297)
> 	at java.lang.Thread.run(Thread.java:724)
> Caused by: java.lang.NullPointerException
> 	at org.drools.core.base.evaluators.AfterEvaluatorDefinition$AfterEvaluator.evaluateCachedRight(AfterEvaluatorDefinition.java:304)
> 	at org.drools.core.rule.constraint.EvaluatorConstraint.isAllowedCachedRight(EvaluatorConstraint.java:80)
> 	at org.drools.core.common.DoubleBetaConstraints.isAllowedCachedRight(DoubleBetaConstraints.java:117)
> 	at org.drools.core.phreak.PhreakJoinNode.doRightInserts(PhreakJoinNode.java:150)
> 	at org.drools.core.phreak.PhreakJoinNode.doNode(PhreakJoinNode.java:56)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:547)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:533)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:335)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:162)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:117)
> 	at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194)
> 	at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:65)
> 	at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:936)
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1183)
> 	at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:936)
> 	at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:910)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:233)
> 	at org.jboss.ddoyle.brms.cep.ha.management.TestScenarioRunner.secondRun(TestScenarioRunner.java:142)
> 	at org.jboss.ddoyle.brms.cep.ha.management.MainSecondRun.main(MainSecondRun.java:7)
> 	... 6 more
> Exception in ReteOO:
> java.lang.reflect.InvocationTargetException
> 	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.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297)
> 	at java.lang.Thread.run(Thread.java:724)
> Caused by: org.drools.core.RuntimeDroolsException: Unexpected exception executing action org.drools.core.reteoo.PropagationQueuingNode$PropagateAction at 2e3aeda
> 	at org.drools.core.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1225)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:371)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:278)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:131)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:56)
> 	at org.jboss.ddoyle.brms.cep.ha.management.TestScenarioRunner.secondRun(TestScenarioRunner.java:140)
> 	at org.jboss.ddoyle.brms.cep.ha.management.MainSecondRun.main(MainSecondRun.java:7)
> 	... 6 more
> Caused by: java.lang.NullPointerException
> 	at org.drools.core.base.evaluators.AfterEvaluatorDefinition$AfterEvaluator.evaluateCachedLeft(AfterEvaluatorDefinition.java:324)
> 	at org.drools.core.rule.constraint.EvaluatorConstraint.isAllowedCachedLeft(EvaluatorConstraint.java:67)
> 	at org.drools.core.common.DoubleBetaConstraints.isAllowedCachedLeft(DoubleBetaConstraints.java:108)
> 	at org.drools.reteoo.nodes.ReteJoinNode.propagateFromLeft(ReteJoinNode.java:147)
> 	at org.drools.reteoo.nodes.ReteJoinNode.assertLeftTuple(ReteJoinNode.java:99)
> 	at org.drools.core.reteoo.SingleLeftTupleSinkAdapter.doPropagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:213)
> 	at org.drools.core.reteoo.SingleLeftTupleSinkAdapter.propagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:73)
> 	at org.drools.reteoo.nodes.ReteJoinNode.propagateFromRight(ReteJoinNode.java:135)
> 	at org.drools.reteoo.nodes.ReteJoinNode.assertRightTuple(ReteJoinNode.java:125)
> 	at org.drools.reteoo.nodes.ReteBetaNodeUtils.assertObject(ReteBetaNodeUtils.java:47)
> 	at org.drools.reteoo.nodes.ReteJoinNode.assertObject(ReteJoinNode.java:39)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:502)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:387)
> 	at org.drools.core.reteoo.PropagationQueuingNode$AssertAction.execute(PropagationQueuingNode.java:430)
> 	at org.drools.core.reteoo.PropagationQueuingNode.propagateActions(PropagationQueuingNode.java:266)
> 	at org.drools.core.reteoo.PropagationQueuingNode$PropagateAction.execute(PropagationQueuingNode.java:592)
> 	at org.drools.core.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1223)
> 	... 12 more
> What I discovered is that this only happens when I save the KieSession to a file in one JVM and reload it in another. When I load the KieSession in the same JVM as the one in which I persisted it, there is no exception and the rule get's fired (as expected).
> I created a reproducer project for it: https://github.com/DuncanDoyle/DroolsSessionPersistenceNPE/
> I've added some Maven profiles so you can easily observe the behaviour:
> - mvn -PallRuns exec:java    : this runs both the persistence and the reload in the same JVM, no exception, everything works fine.
> - mvn -PfirstRun exec:java    : this runs the first part of the test, and saves the KieSession to a file.
> - mvn -PsecondRun exec:java   : this runs the second part of the test, which loads the previously saved KieSession from the file and inserts a new fact, resulting in the NPE.
> All three tests can also be run in ReteOO mode by adding "-Ddrools.ruleEngine=reteoo" at the end of the command.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct  3 09:31:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 3 Oct 2013 09:31:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-281) no reevaluation of 'from
 collect' is performed
In-Reply-To: <JIRA.12502111.1380805492000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502111.1380805492000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502111.1380805492000.12128.1380807062883@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809180#comment-12809180 ] 

RH Bugzilla Integration commented on DROOLS-281:
------------------------------------------------

Edson Tirelli <etirelli at redhat.com> changed the Status of [bug 1015109|https://bugzilla.redhat.com/show_bug.cgi?id=1015109] from NEW to ASSIGNED
                
> no reevaluation of 'from collect' is performed
> ----------------------------------------------
>
>                 Key: DROOLS-281
>                 URL: https://issues.jboss.org/browse/DROOLS-281
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>            Reporter: Richard Bourner
>            Assignee: Mark Proctor
>            Priority: Critical
>         Attachments: Drools6FromCollectIssue.zip
>
>
> Using Drools 6.0.0.CR4, a problem has been found related to reevaluation of a condition that contains a 'from collect' statement.
> A unit test is provided demonstrating the issue using 2 rules.  This unit test works fine using 6.0.0.Beta2.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct  3 09:42:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 3 Oct 2013 09:42:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1070) Memory leak if hashCode of
 Transaction isn't stable
In-Reply-To: <JIRA.12498669.1376567503000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498669.1376567503000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498669.1376567503000.12149.1380807722791@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBJCA-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809184#comment-12809184 ] 

RH Bugzilla Integration commented on JBJCA-1070:
------------------------------------------------

Ivo Studensky <istudens at redhat.com> made a comment on [bug 1007608|https://bugzilla.redhat.com/show_bug.cgi?id=1007608]

Fixed in EAP 6.2.0.ER1.
                
> Memory leak if hashCode of Transaction isn't stable
> ---------------------------------------------------
>
>                 Key: JBJCA-1070
>                 URL: https://issues.jboss.org/browse/JBJCA-1070
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0.19.Final, 1.1.0.Final
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>            Priority: Critical
>             Fix For: 1.0.20.Final, 1.1.1.Final
>
>
> Happens in TransactionSynchronizer

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct  3 09:42:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 3 Oct 2013 09:42:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1070) Memory leak if hashCode of
 Transaction isn't stable
In-Reply-To: <JIRA.12498669.1376567503000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498669.1376567503000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498669.1376567503000.12151.1380807722886@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBJCA-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809185#comment-12809185 ] 

RH Bugzilla Integration commented on JBJCA-1070:
------------------------------------------------

Ivo Studensky <istudens at redhat.com> changed the Status of [bug 1007608|https://bugzilla.redhat.com/show_bug.cgi?id=1007608] from NEW to ON_QA
                
> Memory leak if hashCode of Transaction isn't stable
> ---------------------------------------------------
>
>                 Key: JBJCA-1070
>                 URL: https://issues.jboss.org/browse/JBJCA-1070
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0.19.Final, 1.1.0.Final
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>            Priority: Critical
>             Fix For: 1.0.20.Final, 1.1.1.Final
>
>
> Happens in TransactionSynchronizer

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct  3 09:46:05 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 3 Oct 2013 09:46:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2207) CLI Unable to connect using
 https-remoting address.
In-Reply-To: <JIRA.12502036.1380735356000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502036.1380735356000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502036.1380735356000.12156.1380807965549@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809186#comment-12809186 ] 

Darran Lofthouse commented on WFLY-2207:
----------------------------------------

With TRACE logging enabled the CLI appears to be stuck in an infinate loop for 5 seconds repeating the following each time: -

{code}
14:41:37,014 TRACE [org.xnio.nio.selector] Beginning select on sun.nio.ch.EPollSelectorImpl at 474906b9
14:41:37,015 TRACE [org.xnio.nio.selector] Selected on sun.nio.ch.EPollSelectorImpl at 474906b9
14:41:37,015 TRACE [org.xnio.nio.selector] Selected key sun.nio.ch.SelectionKeyImpl at 187feca0 for java.nio.channels.SocketChannel[connected local=/127.0.0.1:50836 remote=localhost/127.0.0.1:9993]
14:41:37,015 TRACE [org.xnio.listener] Invoking listener org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener at 20a12d8f on channel org.xnio.conduits.ConduitStreamSourceChannel at 35b61805
{code}
                
> CLI Unable to connect using https-remoting address.
> ---------------------------------------------------
>
>                 Key: WFLY-2207
>                 URL: https://issues.jboss.org/browse/WFLY-2207
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>
> The CLI is failing to connect over https with the following: -
> {code}
> [disconnected /] connect https-remoting://localhost:9993
> The controller is not available at localhost:9993: java.net.ConnectException: JBAS012144: Could not connect to https-remoting://localhost:9993. The connection timed out: JBAS012144: Could not connect to https-remoting://localhost:9993. The connection timed out
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct  3 09:54:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 3 Oct 2013 09:54:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2211) NullPointerException in
 RemotingHttpUpgradeService is no http port.
In-Reply-To: <JIRA.12502120.1380808407791@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502120.1380808407791@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502120.1380808407791.12174.1380808443260@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-2211:
--------------------------------------

             Summary: NullPointerException in RemotingHttpUpgradeService is no http port.
                 Key: WFLY-2211
                 URL: https://issues.jboss.org/browse/WFLY-2211
             Project: WildFly
          Issue Type: Bug
          Components: Domain Management
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
            Priority: Critical
             Fix For: 8.0.0.Beta1


Starting with a HTTP port is not mandatory.

{code}
Caused by: java.lang.NullPointerException
	at org.jboss.as.remoting.RemotingHttpUpgradeService.start(RemotingHttpUpgradeService.java:107) [wildfly-remoting-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
{code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct  3 09:54:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 3 Oct 2013 09:54:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2211) NullPointerException in
 RemotingHttpUpgradeService if no http port.
In-Reply-To: <JIRA.12502120.1380808407000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502120.1380808407000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502120.1380808407000.12180.1380808443623@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2211:
-----------------------------------

    Summary: NullPointerException in RemotingHttpUpgradeService if no http port.  (was: NullPointerException in RemotingHttpUpgradeService is no http port.)

    
> NullPointerException in RemotingHttpUpgradeService if no http port.
> -------------------------------------------------------------------
>
>                 Key: WFLY-2211
>                 URL: https://issues.jboss.org/browse/WFLY-2211
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>
> Starting with a HTTP port is not mandatory.
> {code}
> Caused by: java.lang.NullPointerException
> 	at org.jboss.as.remoting.RemotingHttpUpgradeService.start(RemotingHttpUpgradeService.java:107) [wildfly-remoting-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct  3 10:38:02 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Thu, 3 Oct 2013 10:38:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2212) Update JPA subsystem to use
 default EE datasource binding
In-Reply-To: <JIRA.12502126.1380810972274@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502126.1380810972274@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502126.1380810972274.12256.1380811082591@jira02.app.mwc.hst.phx2.redhat.com>

Scott Marlow created WFLY-2212:
----------------------------------

             Summary: Update JPA subsystem to use default EE datasource binding
                 Key: WFLY-2212
                 URL: https://issues.jboss.org/browse/WFLY-2212
             Project: WildFly
          Issue Type: Task
          Components: JPA / Hibernate
            Reporter: Scott Marlow
            Assignee: Scott Marlow
             Fix For: 8.0.0.Beta1


JPA subsystem should check if a default EE datasource binding is available to use and default to that if a persistence unit doesn't specify a datasource.

Also add a persistence unit hint to not use a default datasource (might be helpful for OGM which fails the deployment if a datasource is specified).



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct  3 11:02:02 2013
From: jira-events at lists.jboss.org (Marco Rietveld (JIRA))
Date: Thu, 3 Oct 2013 11:02:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-282) Create a
 "CommandSessionCommandService" implementation that does not use an
 application-scoped persistence context
In-Reply-To: <JIRA.12502131.1380812412109@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502131.1380812412109@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502131.1380812412109.12282.1380812522578@jira02.app.mwc.hst.phx2.redhat.com>

Marco Rietveld created DROOLS-282:
-------------------------------------

             Summary: Create a "CommandSessionCommandService" implementation that does not use an application-scoped persistence context
                 Key: DROOLS-282
                 URL: https://issues.jboss.org/browse/DROOLS-282
             Project: Drools
          Issue Type: Enhancement
      Security Level: Public (Everyone can see)
    Affects Versions: 6.0.0.Final
            Reporter: Marco Rietveld
            Assignee: Marco Rietveld


The application scoped persistence context ({{EntityManager}}) causes a race-condition when a persistence KieSession is accessed by multiple threads in which the transaction is _*not*_ managed by the {{KieSession}} but by code outside of the drools/jbpm/kie code base. 

A "{{CommandSessionCommandService}}" implementation would work very similarly to the existing {{SingleSessionCommandService}} implementation: in both implementations, each thread would use it's own command scoped entity manager. 

However, the {{CommandSessionCommandService}} would *not* use an {{EntityManager}} that would be used by multiple threads. 

The race-condition that arises due to the use of an application scoped entity manager is due to the following: 
- The JPA spec clearly states that the {{EntityManager}} is not thread-safe. 
- As a result of this Hibernate (and probably other ORM frameworks) only has one internal object to represent whether or not the {{EntityManager(Impl)}} has joined a transaction or not. 
- For JTA, Hibernate uses the JTA Synchronization mechanism (normal, not interposed) in order to reset this status once a transaction has committed. 
- When one thread calls {{tx.commit()}} while another thread calls {{em.joinTransaction()}}, then a race-condition can happen in which the "joined transaction" status is first set by the {{EntityManager.joinTransaction()}} call _after which the status is reset to *not-joined*  by the Hibernate injected JTA Synchronization instance in it's {{afterCompletion(..)}} method)_. 

Occasionally, the call to {{EntityManager.joinTransaction()}} will fail because of this race-condtion, although the more dangerous situation is one in which {{.joinTransaction()}} does not throw an exception but where the race-condition does happen.

I've made a trivial effort to create this implementation and discovered that it's more difficult than I had initially expected. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct  3 11:04:02 2013
From: jira-events at lists.jboss.org (Farah Juma (JIRA))
Date: Thu, 3 Oct 2013 11:04:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2176) JSF should be able to access
 the CDI-enabled ValidatorFactory
In-Reply-To: <JIRA.12501764.1380319880000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501764.1380319880000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501764.1380319880000.12286.1380812642533@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809207#comment-12809207 ] 

Farah Juma commented on WFLY-2176:
----------------------------------

Created the following pull request:
https://github.com/wildfly/wildfly/pull/5212
                
> JSF should be able to access the CDI-enabled ValidatorFactory
> -------------------------------------------------------------
>
>                 Key: WFLY-2176
>                 URL: https://issues.jboss.org/browse/WFLY-2176
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JSF
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Farah Juma
>            Assignee: Farah Juma
>
> Currently, for every deployment that uses JSF, the JSF subsystem adds the org.hibernate.validator module to the deployment.  A ValidatorFactory is then obtained via the standard Bean Validation bootstrap strategy. However, a ValidatorFactory obtained this way isn't CDI-enabled. JSF needs to use the EE LazyValidatorFactory instead.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct  3 11:06:02 2013
From: jira-events at lists.jboss.org (Marco Rietveld (JIRA))
Date: Thu, 3 Oct 2013 11:06:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-282) Create a
 "CommandSessionCommandService" implementation that does not use an
 application-scoped persistence context
In-Reply-To: <JIRA.12502131.1380812412000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502131.1380812412000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502131.1380812412000.12292.1380812762517@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marco Rietveld updated DROOLS-282:
----------------------------------

    Attachment: app-scoped-em-race-condition-example.txt


Added a stack trace that illustrates the race-condition. 
                
> Create a "CommandSessionCommandService" implementation that does not use an application-scoped persistence context
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-282
>                 URL: https://issues.jboss.org/browse/DROOLS-282
>             Project: Drools
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>            Reporter: Marco Rietveld
>            Assignee: Marco Rietveld
>         Attachments: app-scoped-em-race-condition-example.txt
>
>
> The application scoped persistence context ({{EntityManager}}) causes a race-condition when a persistence KieSession is accessed by multiple threads in which the transaction is _*not*_ managed by the {{KieSession}} but by code outside of the drools/jbpm/kie code base. 
> A "{{CommandSessionCommandService}}" implementation would work very similarly to the existing {{SingleSessionCommandService}} implementation: in both implementations, each thread would use it's own command scoped entity manager. 
> However, the {{CommandSessionCommandService}} would *not* use an {{EntityManager}} that would be used by multiple threads. 
> The race-condition that arises due to the use of an application scoped entity manager is due to the following: 
> - The JPA spec clearly states that the {{EntityManager}} is not thread-safe. 
> - As a result of this Hibernate (and probably other ORM frameworks) only has one internal object to represent whether or not the {{EntityManager(Impl)}} has joined a transaction or not. 
> - For JTA, Hibernate uses the JTA Synchronization mechanism (normal, not interposed) in order to reset this status once a transaction has committed. 
> - When one thread calls {{tx.commit()}} while another thread calls {{em.joinTransaction()}}, then a race-condition can happen in which the "joined transaction" status is first set by the {{EntityManager.joinTransaction()}} call _after which the status is reset to *not-joined*  by the Hibernate injected JTA Synchronization instance in it's {{afterCompletion(..)}} method)_. 
> Occasionally, the call to {{EntityManager.joinTransaction()}} will fail because of this race-condtion, although the more dangerous situation is one in which {{.joinTransaction()}} does not throw an exception but where the race-condition does happen.
> I've made a trivial effort to create this implementation and discovered that it's more difficult than I had initially expected. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct  3 12:03:02 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 3 Oct 2013 12:03:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2206) Manualmode test suite copes
 the modules directory multiple times
In-Reply-To: <JIRA.12502031.1380731391000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502031.1380731391000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502031.1380731391000.12425.1380816182758@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar resolved WFLY-2206.
-------------------------------

         Assignee: Stuart Douglas  (was: Tomaz Cerar)
    Fix Version/s: 8.0.0.Beta1
       Resolution: Done

    
> Manualmode test suite copes the modules directory multiple times
> ----------------------------------------------------------------
>
>                 Key: WFLY-2206
>                 URL: https://issues.jboss.org/browse/WFLY-2206
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Beta1
>
>
> This uses lots of disk space for no good reason

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct  3 12:07:02 2013
From: jira-events at lists.jboss.org (Eduardo Martins (JIRA))
Date: Thu, 3 Oct 2013 12:07:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1979) Default EE default bindings
	per-deployment
In-Reply-To: <JIRA.12499747.1378117211000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499747.1378117211000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499747.1378117211000.12432.1380816422527@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Eduardo Martins updated WFLY-1979:
----------------------------------

    Summary: Default EE default bindings per-deployment  (was: Default EE Concurrent per-deployment)

    
> Default EE default bindings per-deployment
> ------------------------------------------
>
>                 Key: WFLY-1979
>                 URL: https://issues.jboss.org/browse/WFLY-1979
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EE
>            Reporter: Eduardo Martins
>            Assignee: Eduardo Martins
>
> Deployments/Components should have the possibility of overriding what EE Concurrent (JSR-236) default resources it has in JNDI, for instance, instead of having the globally shared managed executor service, a component could use its "jboss" deployment descriptor to have a different executor at java:comp/DefaultManagedExecutorService.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct  3 12:07:02 2013
From: jira-events at lists.jboss.org (Eduardo Martins (JIRA))
Date: Thu, 3 Oct 2013 12:07:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1979) Default EE default bindings
	per-deployment
In-Reply-To: <JIRA.12499747.1378117211000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499747.1378117211000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499747.1378117211000.12439.1380816422892@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Eduardo Martins updated WFLY-1979:
----------------------------------

    Description: 
Deployments/Components should have the possibility of overriding what EE default bindings, introduced by WFLY-2158.



  was:
Deployments/Components should have the possibility of overriding what EE Concurrent (JSR-236) default resources it has in JNDI, for instance, instead of having the globally shared managed executor service, a component could use its "jboss" deployment descriptor to have a different executor at java:comp/DefaultManagedExecutorService.




    
> Default EE default bindings per-deployment
> ------------------------------------------
>
>                 Key: WFLY-1979
>                 URL: https://issues.jboss.org/browse/WFLY-1979
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EE
>            Reporter: Eduardo Martins
>            Assignee: Eduardo Martins
>
> Deployments/Components should have the possibility of overriding what EE default bindings, introduced by WFLY-2158.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct  3 12:12:02 2013
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Thu, 3 Oct 2013 12:12:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-283) SegmentMemory staged
 LeftTuples not always accessed correctly
In-Reply-To: <JIRA.12502137.1380816662439@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502137.1380816662439@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502137.1380816662439.12443.1380816722542@jira02.app.mwc.hst.phx2.redhat.com>

Mark Proctor created DROOLS-283:
-----------------------------------

             Summary: SegmentMemory staged LeftTuples not always accessed correctly
                 Key: DROOLS-283
                 URL: https://issues.jboss.org/browse/DROOLS-283
             Project: Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Mark Proctor
            Assignee: Mark Proctor


Some times it accesses the current staging list, instead of the one in the segment memory.

The NotNode should use the passed staging list, and not retrieve it directly.

They should always use takeAll, to ensure they are thread safe.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct  3 13:47:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 3 Oct 2013 13:47:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2172) Resurrect the mixed domain
 testing and fix any problems
In-Reply-To: <JIRA.12501720.1380277458000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501720.1380277458000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501720.1380277458000.12538.1380822422717@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2172:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1015243

    
> Resurrect the mixed domain testing and fix any problems
> -------------------------------------------------------
>
>                 Key: WFLY-2172
>                 URL: https://issues.jboss.org/browse/WFLY-2172
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Brian Stansberry
>            Priority: Blocker
>             Fix For: 8.0.0.CR1
>
>
> THis has not been run for quite some time, and needs to be included in the general testing.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct  3 13:49:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 3 Oct 2013 13:49:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2185) Get core model test framework
 working with 7.2.0.Final legacy controller
In-Reply-To: <JIRA.12501848.1380553676000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501848.1380553676000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501848.1380553676000.12545.1380822542647@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2185:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1015245

    
> Get core model test framework working with 7.2.0.Final legacy controller
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2185
>                 URL: https://issues.jboss.org/browse/WFLY-2185
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct  3 14:39:03 2013
From: jira-events at lists.jboss.org (Eduardo Martins (JIRA))
Date: Thu, 3 Oct 2013 14:39:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2027) EE Default DataSource is not
	working
In-Reply-To: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500313.1378739268000.12602.1380825543148@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Eduardo Martins reassigned WFLY-2027:
-------------------------------------

    Assignee: Eduardo Martins

    
> EE Default DataSource is not working
> ------------------------------------
>
>                 Key: WFLY-2027
>                 URL: https://issues.jboss.org/browse/WFLY-2027
>             Project: WildFly
>          Issue Type: Bug
>          Components: ConfigAdmin, Domain Management, EE, JCA, JPA / Hibernate, Web Console
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Lincoln Baxter III
>            Assignee: Eduardo Martins
>
> The EE spec states that a default datasource must be supplied under: java:comp/DefaultDataSource, and if none is specified by the @Resource or persistence.xml, it must be assumed:
>  {code}EE 5.19
> The Java EE Platform requires that a Java EE Product Provider provide a database 
> in the operational environment (see Section EE.2.6, ?Database?). The Java EE 
> Product Provider must also provide a preconfigured, default data source for use by 
> the application in accessing this database.
> The Java EE Product Provider must make the default data source accessible to 
> the application under the JNDI name java:comp/DefaultDataSource.
> The Application Component Provider or Deployer may explicitly bind a 
> DataSource resource reference to the default data source using the lookup element 
> of the Resource annotation or the lookup-name element of the resource-ref
> deployment descriptor element. For example,
> @Resource(lookup="java:comp/DefaultDataSource")
> DataSource myDS;
> In the absence of such a binding, the mapping of the reference will default to 
> the product's default data source.
> For example, the following will map to a preconfigured data source for the 
> product's default database:
> @Resource
> DataSource myDS;{code}
> This, isn't working however:
> {code}
> <persistence version="2.1" xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>    xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/persistence/persistence_2_1.xsd">
>    <persistence-unit name="default" transaction-type="JTA">
>    </persistence-unit>
> </persistence>{code}
> Results in: 
> {code}
> 10:41:31,002 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 50) MSC000001: Failed to start service jboss.persistenceunit."jpa-standard.war#default": org.jboss.msc.service.StartException in service jboss.persistenceunit."jpa-standard.war#default": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:134) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.determineDialect(DialectFactoryImpl.java:98)
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.buildDialect(DialectFactoryImpl.java:66)
> 	at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:193)
> 	at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:88)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:159)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131)
> 	at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration.java:1844)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1802)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:844)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835)
> 	at org.jboss.as.jpa.hibernate4.management.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:115) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	... 4 more
> 10:41:31,010 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"jpa-standard.war#default\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"jpa-standard.war#default\": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
>     Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set"}}
> {code}
> Additionally, actually specifying the expected JDNI name of the default DS like this:
> {code}   <persistence-unit name="default" transaction-type="JTA">
>       <jta-data-source>java:comp/DefaultDataSource</jta-data-source>
>       <exclude-unlisted-classes>false</exclude-unlisted-classes>
>    </persistence-unit>{code}
> Results in this:
> {code}
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.naming.context.java.module.jpa-standard.jpa-standard.DefaultDataSource (missing) dependents: [service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__] 
>       service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__ (missing) dependents: [service jboss.deployment.unit."jpa-standard.war".POST_MODULE] 
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Thu Oct  3 14:41:02 2013
From: jira-events at lists.jboss.org (Eduardo Martins (JIRA))
Date: Thu, 3 Oct 2013 14:41:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2027) EE Default DataSource is not
	working
In-Reply-To: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500313.1378739268000.12608.1380825662701@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Eduardo Martins resolved WFLY-2027.
-----------------------------------

    Fix Version/s: 8.0.0.Beta1
       Resolution: Done


resolved by WFLY-2158
                
> EE Default DataSource is not working
> ------------------------------------
>
>                 Key: WFLY-2027
>                 URL: https://issues.jboss.org/browse/WFLY-2027
>             Project: WildFly
>          Issue Type: Bug
>          Components: ConfigAdmin, Domain Management, EE, JCA, JPA / Hibernate, Web Console
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Lincoln Baxter III
>            Assignee: Eduardo Martins
>             Fix For: 8.0.0.Beta1
>
>
> The EE spec states that a default datasource must be supplied under: java:comp/DefaultDataSource, and if none is specified by the @Resource or persistence.xml, it must be assumed:
>  {code}EE 5.19
> The Java EE Platform requires that a Java EE Product Provider provide a database 
> in the operational environment (see Section EE.2.6, ?Database?). The Java EE 
> Product Provider must also provide a preconfigured, default data source for use by 
> the application in accessing this database.
> The Java EE Product Provider must make the default data source accessible to 
> the application under the JNDI name java:comp/DefaultDataSource.
> The Application Component Provider or Deployer may explicitly bind a 
> DataSource resource reference to the default data source using the lookup element 
> of the Resource annotation or the lookup-name element of the resource-ref
> deployment descriptor element. For example,
> @Resource(lookup="java:comp/DefaultDataSource")
> DataSource myDS;
> In the absence of such a binding, the mapping of the reference will default to 
> the product's default data source.
> For example, the following will map to a preconfigured data source for the 
> product's default database:
> @Resource
> DataSource myDS;{code}
> This, isn't working however:
> {code}
> <persistence version="2.1" xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>    xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/persistence/persistence_2_1.xsd">
>    <persistence-unit name="default" transaction-type="JTA">
>    </persistence-unit>
> </persistence>{code}
> Results in: 
> {code}
> 10:41:31,002 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 50) MSC000001: Failed to start service jboss.persistenceunit."jpa-standard.war#default": org.jboss.msc.service.StartException in service jboss.persistenceunit."jpa-standard.war#default": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:134) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.determineDialect(DialectFactoryImpl.java:98)
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.buildDialect(DialectFactoryImpl.java:66)
> 	at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:193)
> 	at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:88)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:159)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131)
> 	at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration.java:1844)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1802)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:844)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835)
> 	at org.jboss.as.jpa.hibernate4.management.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:115) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	... 4 more
> 10:41:31,010 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"jpa-standard.war#default\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"jpa-standard.war#default\": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
>     Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set"}}
> {code}
> Additionally, actually specifying the expected JDNI name of the default DS like this:
> {code}   <persistence-unit name="default" transaction-type="JTA">
>       <jta-data-source>java:comp/DefaultDataSource</jta-data-source>
>       <exclude-unlisted-classes>false</exclude-unlisted-classes>
>    </persistence-unit>{code}
> Results in this:
> {code}
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.naming.context.java.module.jpa-standard.jpa-standard.DefaultDataSource (missing) dependents: [service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__] 
>       service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__ (missing) dependents: [service jboss.deployment.unit."jpa-standard.war".POST_MODULE] 
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Thu Oct  3 16:25:02 2013
From: jira-events at lists.jboss.org (=?UTF-8?Q?Thomas_Fr=C3=BChbeck_=28JIRA=29?=)
Date: Thu, 3 Oct 2013 16:25:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2213) UnsupportedOperationException
 in wildfly clustering web disrupts appliction access permanently
In-Reply-To: <JIRA.12502154.1380831891008@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502154.1380831891008@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502154.1380831891008.12704.1380831902681@jira02.app.mwc.hst.phx2.redhat.com>

Thomas Fr?hbeck created WFLY-2213:
-------------------------------------

             Summary: UnsupportedOperationException in wildfly clustering web disrupts appliction access permanently
                 Key: WFLY-2213
                 URL: https://issues.jboss.org/browse/WFLY-2213
             Project: WildFly
          Issue Type: Bug
          Components: Clustering, Web (Undertow)
    Affects Versions: 8.0.0.Beta1
            Reporter: Thomas Fr?hbeck
            Assignee: Paul Ferraro


a <distributable> struts application is working correctly, after session timeout an UnsupportedOperationException permanently prohibits access to the application.
I cannot find any possibility to access the app again else than redeploy the application.

2013-10-03 14:55:48,311 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-10) ISPN000136: Execution error: org.infinispan.commons.CacheException: Caught exception [java.lang.Unsuppor
tedOperationException] while invoking method [public void org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.removed(org.infinispan.notifications.cachelistener.event.CacheEntryRemovedEvent)] 
on listener instance: org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager at 56af236c
        at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation$1.run(AbstractListenerImpl.java:209)
        at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:22)
        at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation.invoke(AbstractListenerImpl.java:228)
        at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation.invoke(AbstractListenerImpl.java:191)
        at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyCacheEntryRemoved(CacheNotifierImpl.java:181)
        at org.infinispan.commands.write.RemoveCommand.notify(RemoveCommand.java:98)
        at org.infinispan.commands.write.RemoveCommand.performRemove(RemoveCommand.java:207)
        at org.infinispan.commands.write.RemoveCommand.perform(RemoveCommand.java:90)
        at org.infinispan.interceptors.CallInterceptor.handleDefault(CallInterceptor.java:91)
        at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:37)
        at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:51)
        at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
        at org.infinispan.interceptors.distribution.TxDistributionInterceptor.handleTxWriteCommand(TxDistributionInterceptor.java:268)
        at org.infinispan.interceptors.distribution.TxDistributionInterceptor.visitRemoveCommand(TxDistributionInterceptor.java:77)
        at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:51)
        at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
        at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
        at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:37)
        at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:51)
        at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
        at org.infinispan.interceptors.CacheLoaderInterceptor.visitRemoveCommand(CacheLoaderInterceptor.java:133)
        at org.infinispan.interceptors.ActivationInterceptor.visitRemoveCommand(ActivationInterceptor.java:60)
        at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:51)
        at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
        at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:292)
        at org.infinispan.interceptors.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:372)
        at org.infinispan.interceptors.EntryWrappingInterceptor.visitRemoveCommand(EntryWrappingInterceptor.java:205)
        at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:51)
        at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
        at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitRemoveCommand(PessimisticLockingInterceptor.java:142)
        at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:51)
        at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
        at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
        at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:37)
        at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:51)
        at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
        at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:247)
        at org.infinispan.interceptors.TxInterceptor.visitRemoveCommand(TxInterceptor.java:188)
        at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:51)
        at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
        at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
        at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:37)
        at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:51)
        at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
        at org.infinispan.statetransfer.StateTransferInterceptor.handleNonTxWriteCommand(StateTransferInterceptor.java:193)
        at org.infinispan.statetransfer.StateTransferInterceptor.visitRemoveCommand(StateTransferInterceptor.java:143)
        at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:51)
        at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
        at org.infinispan.interceptors.CacheMgmtInterceptor.visitRemoveCommand(CacheMgmtInterceptor.java:166)
        at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:51)
        at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
        at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:106)
        at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:70)
        at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:37)
        at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:51)
        at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
        at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:64)
        at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:37)
        at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:51)
        at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:321)
        at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1298)
        at org.infinispan.CacheImpl.removeInternal(CacheImpl.java:400)
        at org.infinispan.CacheImpl.remove(CacheImpl.java:393)
        at org.infinispan.DecoratedCache.remove(DecoratedCache.java:406)
        at org.infinispan.AbstractDelegatingCache.remove(AbstractDelegatingCache.java:281)
        at org.wildfly.clustering.web.infinispan.Remover$RemoveOperation.invoke(Remover.java:50)
        at org.jboss.as.clustering.infinispan.invoker.SimpleCacheInvoker.invoke(SimpleCacheInvoker.java:34)
        at org.jboss.as.clustering.infinispan.invoker.RetryingCacheInvoker.invoke(RetryingCacheInvoker.java:82)
        at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.remove(CoarseSessionFactory.java:116)
        at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.remove(CoarseSessionFactory.java:54)
        at org.wildfly.clustering.web.infinispan.session.InfinispanSession.invalidate(InfinispanSession.java:74)
        at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:218)
        at org.wildfly.clustering.web.undertow.session.SessionManagerAdapter.getSession(SessionManagerAdapter.java:124)
        at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:674) [undertow-servlet-1.0.0.Beta15-SNAPSHOT.jar:1.0.0.Beta17-SNAPSHOT]
        at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:688) [undertow-servlet-1.0.0.Beta15-SNAPSHOT.jar:1.0.0.Beta17-SNAPSHOT]
        at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:505) [undertow-servlet-1.0.0.Beta15-SNAPSHOT.jar:1.0.0.Beta17-SNAPSHOT]
        at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:255) [undertow-servlet-1.0.0.Beta15-SNAPSHOT.jar:1.0.0.Beta17-SNAPSHOT]
        at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:202) [undertow-servlet-1.0.0.Beta15-SNAPSHOT.jar:1.0.0.Beta17-SNAPSHOT]
        at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta15-SNAPSHOT.jar:1.0.0.Beta17-SNAPSHOT]
        at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:136) [undertow-servlet-1.0.0.Beta15-SNAPSHOT.jar:1.0.0.Beta17-SNAPSHOT]
        at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta15-SNAPSHOT.jar:1.0.0.Beta15-SNAPSHOT]
        at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:614) [undertow-core-1.0.0.Beta15-SNAPSHOT.jar:1.0.0.Beta15-SNAPSHOT]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
        at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
Caused by: java.lang.UnsupportedOperationException
        at org.wildfly.clustering.web.session.ImmutableHttpSessionAdapter.removeAttribute(ImmutableHttpSessionAdapter.java:90)
        at com.sun.faces.application.view.ViewScopeContextManager.sessionDestroyed(ViewScopeContextManager.java:298) [jsf-impl-2.2.3-jbossorg-1.jar:]
        at com.sun.faces.application.view.ViewScopeManager.sessionDestroyed(ViewScopeManager.java:348) [jsf-impl-2.2.3-jbossorg-1.jar:]
        at com.sun.faces.application.WebappLifecycleListener.sessionDestroyed(WebappLifecycleListener.java:176) [jsf-impl-2.2.3-jbossorg-1.jar:]
        at com.sun.faces.config.ConfigureListener.sessionDestroyed(ConfigureListener.java:368) [jsf-impl-2.2.3-jbossorg-1.jar:]
        at io.undertow.servlet.core.ApplicationListeners.sessionDestroyed(ApplicationListeners.java:264) [undertow-servlet-1.0.0.Beta15-SNAPSHOT.jar:1.0.0.Beta17-SNAPSHOT]
        at org.wildfly.clustering.web.undertow.session.SessionContextAdapter$1.sessionDestroyed(SessionContextAdapter.java:60)
        at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.removed(InfinispanSessionManager.java:297)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_25]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_25]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_25]
        at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_25]
        at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation$1.run(AbstractListenerImpl.java:205)
        ... 84 more



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Thu Oct  3 17:07:03 2013
From: jira-events at lists.jboss.org (Derek Horton (JIRA))
Date: Thu, 3 Oct 2013 17:07:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2214) LDAP security realm needs to
 have configurable timeouts
In-Reply-To: <JIRA.12502155.1380834418830@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502155.1380834418830@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502155.1380834418830.12764.1380834423144@jira02.app.mwc.hst.phx2.redhat.com>

Derek Horton created WFLY-2214:
----------------------------------

             Summary: LDAP security realm needs to have configurable timeouts
                 Key: WFLY-2214
                 URL: https://issues.jboss.org/browse/WFLY-2214
             Project: WildFly
          Issue Type: Bug
          Components: Domain Management
    Affects Versions: 8.0.0.Alpha4
            Reporter: Derek Horton
            Assignee: Brian Stansberry


LDAP security realm needs to have configurable timeouts.

The default LDAP connection timeout appears to be 2 minutes.  If the ldap server is down, it could take 2 minutes for the connection to timeout.  This can cause unneeded delay if you have configured multiple ldap servers for  failover / redundancy.

The following hack appears to work:

+++ domain-management/src/main/java/org/jboss/as/domain/management/connections/ldap/LdapConnectionManagerService.java
@@ -132,6 +132,7 @@ public class LdapConnectionManagerService implements Service<LdapConnectionManag
         result.put(Context.INITIAL_CONTEXT_FACTORY,initialContextFactory);
         String url = config.require(URL).asString();
         result.put(Context.PROVIDER_URL,url);
+        result.put("com.sun.jndi.ldap.connect.timeout", "500");
         return result;
     }


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct  3 17:09:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 3 Oct 2013 17:09:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2214) LDAP security realm needs to
 have configurable timeouts
In-Reply-To: <JIRA.12502155.1380834418000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502155.1380834418000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502155.1380834418000.12767.1380834542547@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2214:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1015303

    
> LDAP security realm needs to have configurable timeouts
> -------------------------------------------------------
>
>                 Key: WFLY-2214
>                 URL: https://issues.jboss.org/browse/WFLY-2214
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Derek Horton
>            Assignee: Brian Stansberry
>
> LDAP security realm needs to have configurable timeouts.
> The default LDAP connection timeout appears to be 2 minutes.  If the ldap server is down, it could take 2 minutes for the connection to timeout.  This can cause unneeded delay if you have configured multiple ldap servers for  failover / redundancy.
> The following hack appears to work:
> +++ domain-management/src/main/java/org/jboss/as/domain/management/connections/ldap/LdapConnectionManagerService.java
> @@ -132,6 +132,7 @@ public class LdapConnectionManagerService implements Service<LdapConnectionManag
>          result.put(Context.INITIAL_CONTEXT_FACTORY,initialContextFactory);
>          String url = config.require(URL).asString();
>          result.put(Context.PROVIDER_URL,url);
> +        result.put("com.sun.jndi.ldap.connect.timeout", "500");
>          return result;
>      }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct  3 18:20:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 3 Oct 2013 18:20:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2182) Significant slow down of
 testsuite execution
In-Reply-To: <JIRA.12501817.1380538653000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501817.1380538653000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501817.1380538653000.12789.1380838802940@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809274#comment-12809274 ] 

RH Bugzilla Integration commented on WFLY-2182:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1013698|https://bugzilla.redhat.com/show_bug.cgi?id=1013698] from NEW to MODIFIED
                
> Significant slow down of testsuite execution
> --------------------------------------------
>
>                 Key: WFLY-2182
>                 URL: https://issues.jboss.org/browse/WFLY-2182
>             Project: WildFly
>          Issue Type: Bug
>          Components: Remoting
>            Reporter: Jozef Hartinger
>            Assignee: Kabir Khan
>
> I am observing a significant slow down when running the Weld integration testsuite. I tracked this down to this commit:
> https://github.com/wildfly/wildfly/commit/13f09525717a089f8a524d086fd865798410f368
> Here are the observed execution times of the Weld integration testsuite:
> Before: Total time: 4:30.357s
> After: Total time: 11:05.547s
> I also tried running the WildFly's integration testsuite (testsuite/integration/basic) with and without the 13f09525717a089f8a524d086fd865798410f368 commit:
> Before: Total time: 13:04.412s
> After: Total time: 21:33.089s
> Note that the difference is not observed when using the arquillian servlet protocol

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct  3 18:51:02 2013
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Thu, 3 Oct 2013 18:51:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-284) Timer nullpointer due to
 race condition during update
In-Reply-To: <JIRA.12502157.1380840657465@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502157.1380840657465@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502157.1380840657465.12810.1380840662546@jira02.app.mwc.hst.phx2.redhat.com>

Mark Proctor created DROOLS-284:
-----------------------------------

             Summary: Timer nullpointer due to race condition during update
                 Key: DROOLS-284
                 URL: https://issues.jboss.org/browse/DROOLS-284
             Project: Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Mark Proctor
            Assignee: Mark Proctor


If the timer fires at the same time as an update it results in the child being propagated twice. We need to synchronize to ensure that this does not happen. The update should cancel the timer, so it doens't try and schedule a propagation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct  3 18:55:02 2013
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Thu, 3 Oct 2013 18:55:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-283) SegmentMemory staged
 LeftTuples not always accessed correctly
In-Reply-To: <JIRA.12502137.1380816662000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502137.1380816662000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502137.1380816662000.12813.1380840902588@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mark Proctor resolved DROOLS-283.
---------------------------------

    Fix Version/s: 6.0.0.CR5
       Resolution: Done

    
> SegmentMemory staged LeftTuples not always accessed correctly
> -------------------------------------------------------------
>
>                 Key: DROOLS-283
>                 URL: https://issues.jboss.org/browse/DROOLS-283
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>            Assignee: Mark Proctor
>             Fix For: 6.0.0.CR5
>
>
> Some times it accesses the current staging list, instead of the one in the segment memory.
> The NotNode should use the passed staging list, and not retrieve it directly.
> They should always use takeAll, to ensure they are thread safe.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct  3 18:57:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 3 Oct 2013 18:57:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-283) SegmentMemory staged
 LeftTuples not always accessed correctly
In-Reply-To: <JIRA.12502137.1380816662000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502137.1380816662000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502137.1380816662000.12818.1380841022798@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated DROOLS-283:
-------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1015208

    
> SegmentMemory staged LeftTuples not always accessed correctly
> -------------------------------------------------------------
>
>                 Key: DROOLS-283
>                 URL: https://issues.jboss.org/browse/DROOLS-283
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>            Assignee: Mark Proctor
>             Fix For: 6.0.0.CR5
>
>
> Some times it accesses the current staging list, instead of the one in the segment memory.
> The NotNode should use the passed staging list, and not retrieve it directly.
> They should always use takeAll, to ensure they are thread safe.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct  3 19:03:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 3 Oct 2013 19:03:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-284) Timer nullpointer due to
 race condition during update
In-Reply-To: <JIRA.12502157.1380840657000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502157.1380840657000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502157.1380840657000.12833.1380841382541@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated DROOLS-284:
-------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1015323

    
> Timer nullpointer due to race condition during update
> -----------------------------------------------------
>
>                 Key: DROOLS-284
>                 URL: https://issues.jboss.org/browse/DROOLS-284
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>            Assignee: Mark Proctor
>
> If the timer fires at the same time as an update it results in the child being propagated twice. We need to synchronize to ensure that this does not happen. The update should cancel the timer, so it doens't try and schedule a propagation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct  3 19:05:02 2013
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Thu, 3 Oct 2013 19:05:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-284) Timer nullpointer due to
 race condition during update
In-Reply-To: <JIRA.12502157.1380840657000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502157.1380840657000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502157.1380840657000.12835.1380841502573@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mark Proctor resolved DROOLS-284.
---------------------------------

    Fix Version/s: 6.0.0.CR5
       Resolution: Done

    
> Timer nullpointer due to race condition during update
> -----------------------------------------------------
>
>                 Key: DROOLS-284
>                 URL: https://issues.jboss.org/browse/DROOLS-284
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>            Assignee: Mark Proctor
>             Fix For: 6.0.0.CR5
>
>
> If the timer fires at the same time as an update it results in the child being propagated twice. We need to synchronize to ensure that this does not happen. The update should cancel the timer, so it doens't try and schedule a propagation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 02:31:02 2013
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Fri, 4 Oct 2013 02:31:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBBUILD-731) Nexus staging repo close
 validation for jboss.org should validate that no artifacts end with
 "-redhat-0" or "-redhat-1"
In-Reply-To: <JIRA.12502161.1380868224956@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502161.1380868224956@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502161.1380868224956.12989.1380868262950@jira02.app.mwc.hst.phx2.redhat.com>

Geoffrey De Smet created JBBUILD-731:
----------------------------------------

             Summary: Nexus staging repo close validation for jboss.org should validate that no artifacts end with "-redhat-0" or "-redhat-1"
                 Key: JBBUILD-731
                 URL: https://issues.jboss.org/browse/JBBUILD-731
             Project: JBoss Build System
          Issue Type: Task
          Components: Artifact Repositories
            Reporter: Geoffrey De Smet


All wolf artifacts will end with "-redhat-0", "-redhat-1", etc.
None of the jboss.org artifacts should end with that.

Otherwise a user/customer that has both repo's in his repository list, might find that a GAV is not unique.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 02:40:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Oct 2013 02:40:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1871) CLI module command doesn't
 allow cross platform resource paths
In-Reply-To: <JIRA.12498510.1376412050000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498510.1376412050000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498510.1376412050000.12994.1380868802718@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809295#comment-12809295 ] 

RH Bugzilla Integration commented on WFLY-1871:
-----------------------------------------------

Ivo Studensky <istudens at redhat.com> made a comment on [bug 1015400|https://bugzilla.redhat.com/show_bug.cgi?id=1015400]

Description of problem:
Backport of WFLY-1871 to EAP.

Original description:
The CLI module command has an argument called "resources". This argument allows you to specify one or more resources separated by the platform-specific path separator. The problem with this is that you can not create a platform-independent script that uses this resources argument.

I have not found a universal path separator character that would work. However, since the creator of the script knows the characters used in his path, we can allow him to specify his own separator.

As an enhancement, I propose to add an argument called "resourceDelimiter". If present, the ASModuleHandler class will use the user-defined delimiter instead of the platform-specific path separator character.

Example usage:

module add --name=org.foo --resources=firstResource.jar:secondResource.jar --resourceDelimiter=: --module-xml=foo-module.xml

The above command would work on Unix, Windows, or any other platform.
                
> CLI module command doesn't allow cross platform resource paths
> --------------------------------------------------------------
>
>                 Key: WFLY-1871
>                 URL: https://issues.jboss.org/browse/WFLY-1871
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Stan Silvert
>            Assignee: Stan Silvert
>             Fix For: 8.0.0.Beta1
>
>
> The CLI module command has an argument called "resources".  This argument allows you to specify one or more resources separated by the platform-specific path separator.  The problem with this is that you can not create a platform-independent script that uses this resources argument.
> I have not found a universal path separator character that would work.  However, since the creator of the script knows the characters used in his path, we can allow him to specify his own separator.
> As an enhancement, I propose to add an argument called "resourceDelimiter".  If present, the ASModuleHandler class will use the user-defined delimiter instead of the platform-specific path separator character.
> Example usage:
> {noformat}
> module add --name=org.foo --resources=firstResource.jar:secondResource.jar --resourceDelimiter=: --module-xml=foo-module.xml
> {noformat}
> The above command would work on Unix, Windows, or any other platform.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 02:40:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Oct 2013 02:40:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1871) CLI module command doesn't
 allow cross platform resource paths
In-Reply-To: <JIRA.12498510.1376412050000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498510.1376412050000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498510.1376412050000.12992.1380868802628@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-1871:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1015400

    
> CLI module command doesn't allow cross platform resource paths
> --------------------------------------------------------------
>
>                 Key: WFLY-1871
>                 URL: https://issues.jboss.org/browse/WFLY-1871
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Stan Silvert
>            Assignee: Stan Silvert
>             Fix For: 8.0.0.Beta1
>
>
> The CLI module command has an argument called "resources".  This argument allows you to specify one or more resources separated by the platform-specific path separator.  The problem with this is that you can not create a platform-independent script that uses this resources argument.
> I have not found a universal path separator character that would work.  However, since the creator of the script knows the characters used in his path, we can allow him to specify his own separator.
> As an enhancement, I propose to add an argument called "resourceDelimiter".  If present, the ASModuleHandler class will use the user-defined delimiter instead of the platform-specific path separator character.
> Example usage:
> {noformat}
> module add --name=org.foo --resources=firstResource.jar:secondResource.jar --resourceDelimiter=: --module-xml=foo-module.xml
> {noformat}
> The above command would work on Unix, Windows, or any other platform.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 02:42:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Oct 2013 02:42:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1871) CLI module command doesn't
 allow cross platform resource paths
In-Reply-To: <JIRA.12498510.1376412050000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498510.1376412050000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498510.1376412050000.12998.1380868922516@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809296#comment-12809296 ] 

RH Bugzilla Integration commented on WFLY-1871:
-----------------------------------------------

Ivo Studensky <istudens at redhat.com> changed the Status of [bug 1015400|https://bugzilla.redhat.com/show_bug.cgi?id=1015400] from NEW to ASSIGNED
                
> CLI module command doesn't allow cross platform resource paths
> --------------------------------------------------------------
>
>                 Key: WFLY-1871
>                 URL: https://issues.jboss.org/browse/WFLY-1871
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Stan Silvert
>            Assignee: Stan Silvert
>             Fix For: 8.0.0.Beta1
>
>
> The CLI module command has an argument called "resources".  This argument allows you to specify one or more resources separated by the platform-specific path separator.  The problem with this is that you can not create a platform-independent script that uses this resources argument.
> I have not found a universal path separator character that would work.  However, since the creator of the script knows the characters used in his path, we can allow him to specify his own separator.
> As an enhancement, I propose to add an argument called "resourceDelimiter".  If present, the ASModuleHandler class will use the user-defined delimiter instead of the platform-specific path separator character.
> Example usage:
> {noformat}
> module add --name=org.foo --resources=firstResource.jar:secondResource.jar --resourceDelimiter=: --module-xml=foo-module.xml
> {noformat}
> The above command would work on Unix, Windows, or any other platform.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 02:47:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Oct 2013 02:47:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2177) org.jboss.logmanager module
 needs dependency on javax.api for the SocketFactory
In-Reply-To: <JIRA.12501765.1380321136000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501765.1380321136000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501765.1380321136000.13003.1380869222571@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809299#comment-12809299 ] 

RH Bugzilla Integration commented on WFLY-2177:
-----------------------------------------------

Vladimir Dosoudil <dosoudil at redhat.com> changed the Status of [bug 1013169|https://bugzilla.redhat.com/show_bug.cgi?id=1013169] from MODIFIED to ON_QA
                
> org.jboss.logmanager module needs dependency on javax.api for the SocketFactory
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-2177
>                 URL: https://issues.jboss.org/browse/WFLY-2177
>             Project: WildFly
>          Issue Type: Bug
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 8.0.0.Beta1
>
>
> The {{javax.net.SocketFactory}} is part of the {{javax.api}} module. Since the {{org.jboss.logmanager}} uses this for the syslog handler on TCP and SSL connections, a dependency on the module is needed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 02:49:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Oct 2013 02:49:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2181) TempFileProviderService
 creates a static, non-daemon thread pool
In-Reply-To: <JIRA.12501805.1380532508000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501805.1380532508000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501805.1380532508000.13007.1380869342674@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809300#comment-12809300 ] 

RH Bugzilla Integration commented on WFLY-2181:
-----------------------------------------------

Vladimir Dosoudil <dosoudil at redhat.com> changed the Status of [bug 1012968|https://bugzilla.redhat.com/show_bug.cgi?id=1012968] from MODIFIED to ON_QA
                
> TempFileProviderService creates a static, non-daemon thread pool
> ----------------------------------------------------------------
>
>                 Key: WFLY-2181
>                 URL: https://issues.jboss.org/browse/WFLY-2181
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Beta1
>
>
> This can prevent the server from shutting down

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 02:51:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Oct 2013 02:51:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2139) ProxyStepHandler/Controller
 need to check access before attempting to read information
In-Reply-To: <JIRA.12501339.1379968181000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501339.1379968181000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501339.1379968181000.13014.1380869462799@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809303#comment-12809303 ] 

RH Bugzilla Integration commented on WFLY-2139:
-----------------------------------------------

Vladimir Dosoudil <dosoudil at redhat.com> changed the Status of [bug 1011994|https://bugzilla.redhat.com/show_bug.cgi?id=1011994] from MODIFIED to ON_QA
                
> ProxyStepHandler/Controller need to check access before attempting to read information
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-2139
>                 URL: https://issues.jboss.org/browse/WFLY-2139
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Beta1
>
>
> This affects things like recursive :read-resource(-description) :read-children-resources and so on. The problem as it stands is that if you have, say, a host scoped role scoped to host=master, and there is also a slave host controller, and you try to :read-resource(recursive=true,proxies=true), the master will list the slave host controller in its list of child addresses. It will then execute /host=slave:read-resource(recursive=true,proxies=true), which will fail and roll back the tx since the master host scoped role does not have access to that resource.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 02:51:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Oct 2013 02:51:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2155) Defining
 <outbound-connections> in <management> prevents the server to start
In-Reply-To: <JIRA.12501472.1380107992000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501472.1380107992000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501472.1380107992000.13018.1380869462996@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809304#comment-12809304 ] 

RH Bugzilla Integration commented on WFLY-2155:
-----------------------------------------------

Vladimir Dosoudil <dosoudil at redhat.com> changed the Status of [bug 1011911|https://bugzilla.redhat.com/show_bug.cgi?id=1011911] from MODIFIED to ON_QA
                
> Defining <outbound-connections> in <management> prevents the server to start
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-2155
>                 URL: https://issues.jboss.org/browse/WFLY-2155
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.Beta1
>
>
> If I want to authenticate against LDAP for management purposes, I have to define an LDAP outbound connection in the {{<management>}} section. But once I do this, the server fails to start with this error message:
> {code}
> 13:18:10,594 ERROR [org.jboss.as.server] (Controller Boot Thread) JBAS015956: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:112) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:331) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:252) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> Caused by: java.lang.UnsupportedOperationException
> 	at org.jboss.as.server.parsing.StandaloneXml$ManagementXmlDelegate.parseOutboundConnections(StandaloneXml.java:1314) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.domain.management.parsing.ManagementXml.parseManagement_2_0(ManagementXml.java:354) [wildfly-domain-management-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.domain.management.parsing.ManagementXml.parseManagement(ManagementXml.java:282) [wildfly-domain-management-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.parsing.StandaloneXml.readServerElement_1_4(StandaloneXml.java:453) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:145) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:107) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:104) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	... 3 more
> 13:18:10,598 FATAL [org.jboss.as.server] (Controller Boot Thread) JBAS015957: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> {code}
> To be precise: I take a freshly built WildFly server and add this into {{standalone.xml}} (into the {{<management>}} section):
> {code:xml}
> <outbound-connections>
>     <ldap name="ldap" url="ldap://localhost:10389"/>
> </outbound-connections>
> {code}
> Then I try to start the server (using plain old {{./bin/standalone.sh}}).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 02:57:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Oct 2013 02:57:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2135) Change distributed config on
 address settings to Page instead of Block
In-Reply-To: <JIRA.12501318.1379952235000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501318.1379952235000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501318.1379952235000.13027.1380869822576@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809307#comment-12809307 ] 

RH Bugzilla Integration commented on WFLY-2135:
-----------------------------------------------

Vladimir Dosoudil <dosoudil at redhat.com> changed the Status of [bug 1011074|https://bugzilla.redhat.com/show_bug.cgi?id=1011074] from MODIFIED to ON_QA
                
> Change distributed config on address settings to Page instead of Block
> ----------------------------------------------------------------------
>
>                 Key: WFLY-2135
>                 URL: https://issues.jboss.org/browse/WFLY-2135
>             Project: WildFly
>          Issue Type: Feature Request
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 8.0.0.Beta1
>
>
> We have had so many cases of questions about why the producing is blocked when not consuming.
> Users are expecting Page by default, so we should change the default.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 02:59:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Oct 2013 02:59:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1511)
 RemoteDomainConnection.close() will block forever if the master HC is not
 running
In-Reply-To: <JIRA.12494131.1371059684000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494131.1371059684000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494131.1371059684000.13038.1380869942747@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809310#comment-12809310 ] 

RH Bugzilla Integration commented on WFLY-1511:
-----------------------------------------------

Vladimir Dosoudil <dosoudil at redhat.com> changed the Status of [bug 1012850|https://bugzilla.redhat.com/show_bug.cgi?id=1012850] from MODIFIED to ON_QA
                
> RemoteDomainConnection.close() will block forever if the master HC is not running 
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-1511
>                 URL: https://issues.jboss.org/browse/WFLY-1511
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Brian Stansberry
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.Beta1
>
>
> RemoteDomainConnection.close() overrides FutureManagementChannel.close() to first send a "unregister" message to the master HC before calling the superclass functionality.
> Problem is this call tries to open a connection to the master and will block forever waiting for it to connect if the master isn't available, as seen at http://fpaste.org/18232/37105700/
> That example was from AutoIgnoredResourcesDomainTestCase which is concurrently shutting down the hosts in the domain, meaning the master can be shutting down in the middle of or prior to slave shutdown.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 03:09:02 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Fri, 4 Oct 2013 03:09:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2110) HTTPS Listener: Security
 realm needs to be flagged 'required'
In-Reply-To: <JIRA.12500993.1379583117000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500993.1379583117000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500993.1379583117000.13055.1380870542676@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun resolved WFLY-2110.
-------------------------------

    Fix Version/s:     (was: 8.0.0.CR1)
       Resolution: Rejected

    
> HTTPS Listener: Security realm needs to be flagged 'required'
> -------------------------------------------------------------
>
>                 Key: WFLY-2110
>                 URL: https://issues.jboss.org/browse/WFLY-2110
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>            Reporter: Heiko Braun
>            Assignee: Stuart Douglas
>
> It's required to add an https listeners. Otherwise the add dialogs doesn't work (See HTTP > Listeners HTTPS > Add)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 03:15:03 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Fri, 4 Oct 2013 03:15:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2118) PersistenceException breaks
 default error page
In-Reply-To: <JIRA.12501118.1379679983000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501118.1379679983000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501118.1379679983000.13058.1380870903268@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-2118.
----------------------------------

    Resolution: Rejected


The stack trace on error feature is working as expected. If we want this enabled by default or not is a question we can answer after the beta.
                
> PersistenceException breaks default error page
> ----------------------------------------------
>
>                 Key: WFLY-2118
>                 URL: https://issues.jboss.org/browse/WFLY-2118
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>            Reporter: Juergen Zimmermann
>            Assignee: Stuart Douglas
>         Attachments: mojarra-2.1.zip, testcase-WFLY-2118.zip
>
>
> I'm using the latest WildFly snapshot with Undertow 1.0.0.Beta13. When I get a PersistenceException caused by Hibernate due to an invalid entity (according to Bean Validation), then the webbrowser doesn't get the default error page. The stacktrace is shown below. I'll attach a testcase.
> {code}
> [com.arjuna.ats.arjuna] ARJUNA012125: TwoPhaseCoordinator.beforeCompletion - failed for SynchronizationImple< 0:ffffc0a8b801:4240ead4:523ac52c:15, org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization at 20cf7473 >: javax.persistence.PersistenceException: error during managed flush
> 	at org.hibernate.jpa.spi.AbstractEntityManagerImpl$CallbackExceptionMapperImpl.mapManagedFlushFailure(AbstractEntityManagerImpl.java:1785) [hibernate-entitymanager-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:118) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:53) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:273) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:93) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1170) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
> 	at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.endTransaction(TransactionalInterceptorBase.java:131) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.invokeInOurTx(TransactionalInterceptorBase.java:77) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired.intercept(TransactionalInterceptorRequired.java:52) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_40]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_40]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_40]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_40]
> 	at org.jboss.weld.interceptor.proxy.SimpleMethodInvocation.invoke(SimpleMethodInvocation.java:30) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNext(AbstractInterceptionChain.java:90) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNextInterceptor(AbstractInterceptionChain.java:75) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:48) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:41) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:53) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at testcase.web.CustomerModel$Proxy$_$$_WeldSubclass.create(Unknown Source) [classes:]
> 	at testcase.web.CustomerModel$Proxy$_$$_WeldClientProxy.create(Unknown Source) [classes:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_40]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_40]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_40]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_40]
> 	at javax.el.ELUtil.invokeMethod(ELUtil.java:326) [javax.el-3.0-b07.jar:3.0-b07]
> 	at javax.el.BeanELResolver.invoke(BeanELResolver.java:536) [javax.el-3.0-b07.jar:3.0-b07]
> 	at javax.el.CompositeELResolver.invoke(CompositeELResolver.java:256) [javax.el-3.0-b07.jar:3.0-b07]
> 	at com.sun.el.parser.AstValue.invoke(AstValue.java:269) [javax.el-3.0-b07.jar:3.0-b07]
> 	at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:304) [javax.el-3.0-b07.jar:3.0-b07]
> 	at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105) [jsf-impl-2.1.26.jar:2.1.26]
> 	at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:87) [jsf-api-2.1.26.jar:2.1]
> 	at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:101) [jsf-impl-2.1.26.jar:2.1.26]
> 	at javax.faces.component.UICommand.broadcast(UICommand.java:315) [jsf-api-2.1.26.jar:2.1]
> 	at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:786) [jsf-api-2.1.26.jar:2.1]
> 	at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1251) [jsf-api-2.1.26.jar:2.1]
> 	at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) [jsf-impl-2.1.26.jar:2.1.26]
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593) [jsf-api-2.1.26.jar:2.1]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:59) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:209) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:196) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:130) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:614) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> Caused by: javax.validation.ConstraintViolationException: Validation failed for classes [testcase.domain.Customer] during persist time for groups [javax.validation.groups.Default, ]
> List of constraint violations:[
> 	ConstraintViolationImpl{interpolatedMessage='Min length = 2, max length = 32', propertyPath=name, rootBeanClass=class testcase.domain.Customer, messageTemplate='Min length = {min}, max length = {max}'}
> 	ConstraintViolationImpl{interpolatedMessage='Zip code is 5 digits', propertyPath=zip, rootBeanClass=class testcase.domain.Customer, messageTemplate='Zip code is 5 digits'}
> 	ConstraintViolationImpl{interpolatedMessage='A name must have one capital letter, followed by small letters', propertyPath=name, rootBeanClass=class testcase.domain.Customer, messageTemplate='A name must have one capital letter, followed by small letters'}
> ]
> 	at org.hibernate.cfg.beanvalidation.BeanValidationEventListener.validate(BeanValidationEventListener.java:159) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.cfg.beanvalidation.BeanValidationEventListener.onPreInsert(BeanValidationEventListener.java:94) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.action.internal.EntityInsertAction.preInsert(EntityInsertAction.java:196) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.action.internal.EntityInsertAction.execute(EntityInsertAction.java:96) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:377) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:369) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:286) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:340) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:52) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1235) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:405) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:113) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	... 68 more
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 03:55:04 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 4 Oct 2013 03:55:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1714) Headers: data in some headers
 might be too large in big clusters
In-Reply-To: <JIRA.12502090.1380796496000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502090.1380796496000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502090.1380796496000.13122.1380873304391@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1714:
---------------------------

    Fix Version/s: 3.4
                       (was: 3.5)

    
> Headers: data in some headers might be too large in big clusters
> ----------------------------------------------------------------
>
>                 Key: JGRP-1714
>                 URL: https://issues.jboss.org/browse/JGRP-1714
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> Similar to JGRP-1710 and JGRP-1713, investigate headers which might become too big, and move their contents into the message body. Check all headers which contain
> * a view
> * a digest
> * a list of members
> Candidates:
> * {{PingHeader}}. 
> Probable solution: move {{PingHeader.PingData}} from the header to the message body

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 03:55:04 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 4 Oct 2013 03:55:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1714) Headers: data in some headers
 might be too large in big clusters
In-Reply-To: <JIRA.12502090.1380796496000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502090.1380796496000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502090.1380796496000.13125.1380873304567@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809325#comment-12809325 ] 

Bela Ban commented on JGRP-1714:
--------------------------------

* {{PingHeader}}: DONE
* {{FD_SOCK.FdHeader}}: DONE
                
> Headers: data in some headers might be too large in big clusters
> ----------------------------------------------------------------
>
>                 Key: JGRP-1714
>                 URL: https://issues.jboss.org/browse/JGRP-1714
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> Similar to JGRP-1710 and JGRP-1713, investigate headers which might become too big, and move their contents into the message body. Check all headers which contain
> * a view
> * a digest
> * a list of members
> Candidates:
> * {{PingHeader}}. 
> Probable solution: move {{PingHeader.PingData}} from the header to the message body

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 04:02:21 2013
From: jira-events at lists.jboss.org (Anthony Patricio (JIRA))
Date: Fri, 4 Oct 2013 04:02:21 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-280) lock-on-active broken
In-Reply-To: <JIRA.12501976.1380702873000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501976.1380702873000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501976.1380702873000.13139.1380873741184@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anthony Patricio updated DROOLS-280:
------------------------------------

    Affects Version/s:  6.0.0.CR4

    
> lock-on-active broken
> ---------------------
>
>                 Key: DROOLS-280
>                 URL: https://issues.jboss.org/browse/DROOLS-280
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>            Reporter: Anthony Patricio
>
> Hi,
> lock-on-active is not working as expected.
> I seems to work as activation-group.
> Works fine with 5.x
> Fails with 6.0.0 CR3 and CR4
> Fact:
> public class Poc implements Serializable {
> 	private static final long serialVersionUID = 1L;
> 	private long id = 1;
> 	private boolean test1 = false;
> 	private boolean test2 = false;
> 	private int foundTest = 0;
> ...
> }
> Rule:
> rule "test1"
> lock-on-active 
> dialect "mvel"
>     when
>     	$poc:Poc( isTest1() )
>     then
>     	System.out.println("test1 found");
>     	modify($poc) { setFoundTest($poc.getFoundTest() + 1) }    	
> end
> rule "test2"
> lock-on-active 
> dialect "mvel"
>     when
>     	$poc:Poc( isTest2() )
>     then
>     	System.out.println("test2 found");
>     	modify($poc) { setFoundTest($poc.getFoundTest() + 1) }    	
> end
> Test:
> @Test
> public void lockOnActiveTest() {
> 	// Get the Knowledge base from the DRL file 
> 	KieSession kSession = getSF();
> 			
> 	Poc poc = new Poc();
> 	poc.setTest1(true);
> 	poc.setTest2(true);
> 	
> 	kSession.insert(poc);
> 	
> 	// Fire the rules
> 	kSession.fireAllRules();
> 	
> 	assertTrue("broken",poc.getFoundTest()==2);
> 	
> 	// Clean up
> 	kSession.dispose();
> }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 04:02:22 2013
From: jira-events at lists.jboss.org (Eduardo Martins (JIRA))
Date: Fri, 4 Oct 2013 04:02:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2164) Read only App,
 Module and Comp Naming Contexts
In-Reply-To: <JIRA.12501609.1380195647000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501609.1380195647000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501609.1380195647000.13146.1380873742113@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Eduardo Martins updated WFLY-2164:
----------------------------------

    Summary: Read only App, Module and Comp Naming Contexts  (was: EE subsystem config to define if EE naming contexts are modifiable by EE components)

    
> Read only App, Module and Comp Naming Contexts
> ----------------------------------------------
>
>                 Key: WFLY-2164
>                 URL: https://issues.jboss.org/browse/WFLY-2164
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EE, Naming
>            Reporter: Eduardo Martins
>            Assignee: Eduardo Martins
>
> Wildfly allows EE components to modify their naming environment (and every other naming context too), and such behaviour may be undesirable, thus the EE subsystem configuration should include an attribute to globally turn on or off such functionality.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 04:04:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Oct 2013 04:04:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-283) SegmentMemory staged
 LeftTuples not always accessed correctly
In-Reply-To: <JIRA.12502137.1380816662000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502137.1380816662000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502137.1380816662000.13154.1380873843000@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated DROOLS-283:
-------------------------------------------

    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1015208, https://bugzilla.redhat.com/show_bug.cgi?id=999851  (was: https://bugzilla.redhat.com/show_bug.cgi?id=1015208)

    
> SegmentMemory staged LeftTuples not always accessed correctly
> -------------------------------------------------------------
>
>                 Key: DROOLS-283
>                 URL: https://issues.jboss.org/browse/DROOLS-283
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>            Assignee: Mark Proctor
>             Fix For: 6.0.0.CR5
>
>
> Some times it accesses the current staging list, instead of the one in the segment memory.
> The NotNode should use the passed staging list, and not retrieve it directly.
> They should always use takeAll, to ensure they are thread safe.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 04:04:03 2013
From: jira-events at lists.jboss.org (Anthony Patricio (JIRA))
Date: Fri, 4 Oct 2013 04:04:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-280) lock-on-active broken
In-Reply-To: <JIRA.12501976.1380702873000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501976.1380702873000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501976.1380702873000.13156.1380873843147@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anthony Patricio updated DROOLS-280:
------------------------------------

    Description: 
Hi,
lock-on-active is not working as expected.
I seems to work as activation-group.

Works fine with 5.x
Fails with 6.0.0 CR3 and CR4

Fact:
{code:java}
public class Poc implements Serializable {

	private static final long serialVersionUID = 1L;

	private long id = 1;
	private boolean test1 = false;
	private boolean test2 = false;
	private int foundTest = 0;
...
}
{code}

Rule:
{code:java}
rule "test1"
lock-on-active 
dialect "mvel"
    when
    	$poc:Poc( isTest1() )
    then
    	System.out.println("test1 found");
    	modify($poc) { setFoundTest($poc.getFoundTest() + 1) }    	
end


rule "test2"
lock-on-active 
dialect "mvel"
    when
    	$poc:Poc( isTest2() )
    then
    	System.out.println("test2 found");
    	modify($poc) { setFoundTest($poc.getFoundTest() + 1) }    	
end
{code}

Test:

{code:java}
@Test
public void lockOnActiveTest() {
	// Get the Knowledge base from the DRL file 
	KieSession kSession = getSF();
			
	Poc poc = new Poc();
	poc.setTest1(true);
	poc.setTest2(true);
	
	kSession.insert(poc);
	
	// Fire the rules
	kSession.fireAllRules();
	
	assertTrue("broken",poc.getFoundTest()==2);
	
	// Clean up
	kSession.dispose();
}
{code}


  was:
Hi,
lock-on-active is not working as expected.
I seems to work as activation-group.

Works fine with 5.x
Fails with 6.0.0 CR3 and CR4

Fact:
public class Poc implements Serializable {

	private static final long serialVersionUID = 1L;

	private long id = 1;
	private boolean test1 = false;
	private boolean test2 = false;
	private int foundTest = 0;
...
}

Rule:
rule "test1"
lock-on-active 
dialect "mvel"
    when
    	$poc:Poc( isTest1() )
    then
    	System.out.println("test1 found");
    	modify($poc) { setFoundTest($poc.getFoundTest() + 1) }    	
end


rule "test2"
lock-on-active 
dialect "mvel"
    when
    	$poc:Poc( isTest2() )
    then
    	System.out.println("test2 found");
    	modify($poc) { setFoundTest($poc.getFoundTest() + 1) }    	
end

Test:
@Test
public void lockOnActiveTest() {
	// Get the Knowledge base from the DRL file 
	KieSession kSession = getSF();
			
	Poc poc = new Poc();
	poc.setTest1(true);
	poc.setTest2(true);
	
	kSession.insert(poc);
	
	// Fire the rules
	kSession.fireAllRules();
	
	assertTrue("broken",poc.getFoundTest()==2);
	
	// Clean up
	kSession.dispose();
}




    
> lock-on-active broken
> ---------------------
>
>                 Key: DROOLS-280
>                 URL: https://issues.jboss.org/browse/DROOLS-280
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>            Reporter: Anthony Patricio
>
> Hi,
> lock-on-active is not working as expected.
> I seems to work as activation-group.
> Works fine with 5.x
> Fails with 6.0.0 CR3 and CR4
> Fact:
> {code:java}
> public class Poc implements Serializable {
> 	private static final long serialVersionUID = 1L;
> 	private long id = 1;
> 	private boolean test1 = false;
> 	private boolean test2 = false;
> 	private int foundTest = 0;
> ...
> }
> {code}
> Rule:
> {code:java}
> rule "test1"
> lock-on-active 
> dialect "mvel"
>     when
>     	$poc:Poc( isTest1() )
>     then
>     	System.out.println("test1 found");
>     	modify($poc) { setFoundTest($poc.getFoundTest() + 1) }    	
> end
> rule "test2"
> lock-on-active 
> dialect "mvel"
>     when
>     	$poc:Poc( isTest2() )
>     then
>     	System.out.println("test2 found");
>     	modify($poc) { setFoundTest($poc.getFoundTest() + 1) }    	
> end
> {code}
> Test:
> {code:java}
> @Test
> public void lockOnActiveTest() {
> 	// Get the Knowledge base from the DRL file 
> 	KieSession kSession = getSF();
> 			
> 	Poc poc = new Poc();
> 	poc.setTest1(true);
> 	poc.setTest2(true);
> 	
> 	kSession.insert(poc);
> 	
> 	// Fire the rules
> 	kSession.fireAllRules();
> 	
> 	assertTrue("broken",poc.getFoundTest()==2);
> 	
> 	// Clean up
> 	kSession.dispose();
> }
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 04:06:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Fri, 4 Oct 2013 04:06:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-283) SegmentMemory staged
 LeftTuples not always accessed correctly
In-Reply-To: <JIRA.12502137.1380816662000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502137.1380816662000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502137.1380816662000.13160.1380873962685@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco updated DROOLS-283:
-------------------------------

    Issue Type: Bug  (was: Feature Request)

    
> SegmentMemory staged LeftTuples not always accessed correctly
> -------------------------------------------------------------
>
>                 Key: DROOLS-283
>                 URL: https://issues.jboss.org/browse/DROOLS-283
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>            Assignee: Mark Proctor
>             Fix For: 6.0.0.CR5
>
>
> Some times it accesses the current staging list, instead of the one in the segment memory.
> The NotNode should use the passed staging list, and not retrieve it directly.
> They should always use takeAll, to ensure they are thread safe.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 04:06:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Fri, 4 Oct 2013 04:06:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-284) Timer nullpointer due to
 race condition during update
In-Reply-To: <JIRA.12502157.1380840657000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502157.1380840657000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502157.1380840657000.13162.1380873962824@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco updated DROOLS-284:
-------------------------------

    Issue Type: Bug  (was: Feature Request)

    
> Timer nullpointer due to race condition during update
> -----------------------------------------------------
>
>                 Key: DROOLS-284
>                 URL: https://issues.jboss.org/browse/DROOLS-284
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>            Assignee: Mark Proctor
>             Fix For: 6.0.0.CR5
>
>
> If the timer fires at the same time as an update it results in the child being propagated twice. We need to synchronize to ensure that this does not happen. The update should cancel the timer, so it doens't try and schedule a propagation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 04:08:02 2013
From: jira-events at lists.jboss.org (Eduardo Martins (JIRA))
Date: Fri, 4 Oct 2013 04:08:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2164) Read only App,
 Module and Comp Naming Contexts
In-Reply-To: <JIRA.12501609.1380195647000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501609.1380195647000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501609.1380195647000.13166.1380874082521@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Eduardo Martins updated WFLY-2164:
----------------------------------

    Description: 
Java EE 7 (and its TCK) mandates that java:app, java:module and java:comp contexts to be read only. 


  was:Wildfly allows EE components to modify their naming environment (and every other naming context too), and such behaviour may be undesirable, thus the EE subsystem configuration should include an attribute to globally turn on or off such functionality.


    
> Read only App, Module and Comp Naming Contexts
> ----------------------------------------------
>
>                 Key: WFLY-2164
>                 URL: https://issues.jboss.org/browse/WFLY-2164
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EE, Naming
>            Reporter: Eduardo Martins
>            Assignee: Eduardo Martins
>
> Java EE 7 (and its TCK) mandates that java:app, java:module and java:comp contexts to be read only. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 04:10:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Oct 2013 04:10:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-284) Timer nullpointer due to
 race condition during update
In-Reply-To: <JIRA.12502157.1380840657000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502157.1380840657000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502157.1380840657000.13169.1380874204311@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809331#comment-12809331 ] 

RH Bugzilla Integration commented on DROOLS-284:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> made a comment on [bug 1015323|https://bugzilla.redhat.com/show_bug.cgi?id=1015323]

Fixed by Mark with this commit: https://github.com/droolsjbpm/drools/commit/859b1a5915fe89ba37483afc84c6dd00fe07878a
                
> Timer nullpointer due to race condition during update
> -----------------------------------------------------
>
>                 Key: DROOLS-284
>                 URL: https://issues.jboss.org/browse/DROOLS-284
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>            Assignee: Mark Proctor
>             Fix For: 6.0.0.CR5
>
>
> If the timer fires at the same time as an update it results in the child being propagated twice. We need to synchronize to ensure that this does not happen. The update should cancel the timer, so it doens't try and schedule a propagation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 04:10:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Oct 2013 04:10:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-284) Timer nullpointer due to
 race condition during update
In-Reply-To: <JIRA.12502157.1380840657000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502157.1380840657000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502157.1380840657000.13172.1380874204554@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809332#comment-12809332 ] 

RH Bugzilla Integration commented on DROOLS-284:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> changed the Status of [bug 1015323|https://bugzilla.redhat.com/show_bug.cgi?id=1015323] from NEW to MODIFIED
                
> Timer nullpointer due to race condition during update
> -----------------------------------------------------
>
>                 Key: DROOLS-284
>                 URL: https://issues.jboss.org/browse/DROOLS-284
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>            Assignee: Mark Proctor
>             Fix For: 6.0.0.CR5
>
>
> If the timer fires at the same time as an update it results in the child being propagated twice. We need to synchronize to ensure that this does not happen. The update should cancel the timer, so it doens't try and schedule a propagation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 04:12:02 2013
From: jira-events at lists.jboss.org (Alessio Soldano (JIRA))
Date: Fri, 4 Oct 2013 04:12:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-263) JASPI Support for Web Services
In-Reply-To: <JIRA.12457542.1327505819000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12457542.1327505819000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12457542.1327505819000.13178.1380874322790@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alessio Soldano updated WFLY-263:
---------------------------------

    Assignee: Jim Ma  (was: Alessio Soldano)

    
> JASPI Support for Web Services
> ------------------------------
>
>                 Key: WFLY-263
>                 URL: https://issues.jboss.org/browse/WFLY-263
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Security, Web Services
>            Reporter: Anil Saldhana
>            Assignee: Jim Ma
>             Fix For: 8.0.0.Beta1
>
>
> Take care of the JASPI requirements for SOAP layer.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 04:31:03 2013
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Fri, 4 Oct 2013 04:31:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2128) Support one-port connection
	for JMS
In-Reply-To: <JIRA.12501177.1379926949000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501177.1379926949000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501177.1379926949000.13203.1380875463426@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil updated WFLY-2128:
------------------------------

    Priority: Critical  (was: Major)

    
> Support one-port connection for JMS
> -----------------------------------
>
>                 Key: WFLY-2128
>                 URL: https://issues.jboss.org/browse/WFLY-2128
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JMS
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>
> WildFly 8 needs to support one-port where all the remote connections goes through HTTP with Upgrade header.
> A JMS client will be able to connect to WildFly's HTTP port to access its JMS resources instead of connecting to the TCP socket on HornetQ remote port (5445).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 04:35:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 4 Oct 2013 04:35:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1714) Headers: data in some headers
 might be too large in big clusters
In-Reply-To: <JIRA.12502090.1380796496000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502090.1380796496000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502090.1380796496000.13210.1380875702642@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809325#comment-12809325 ] 

Bela Ban edited comment on JGRP-1714 at 10/4/13 4:34 AM:
---------------------------------------------------------

* {{PingHeader}}: DONE
* {{FD_SOCK.FdHeader}}: DONE
* {{STABLE.StableHeader}}: DONE
                
      was (Author: belaban):
    * {{PingHeader}}: DONE
* {{FD_SOCK.FdHeader}}: DONE
                  
> Headers: data in some headers might be too large in big clusters
> ----------------------------------------------------------------
>
>                 Key: JGRP-1714
>                 URL: https://issues.jboss.org/browse/JGRP-1714
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> Similar to JGRP-1710 and JGRP-1713, investigate headers which might become too big, and move their contents into the message body. Check all headers which contain
> * a view
> * a digest
> * a list of members
> Candidates:
> * {{PingHeader}}. 
> Probable solution: move {{PingHeader.PingData}} from the header to the message body

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 04:39:02 2013
From: jira-events at lists.jboss.org (Juergen Zimmermann (JIRA))
Date: Fri, 4 Oct 2013 04:39:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2118) PersistenceException breaks
 default error page
In-Reply-To: <JIRA.12501118.1379679983000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501118.1379679983000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501118.1379679983000.13220.1380875942918@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809340#comment-12809340 ] 

Juergen Zimmermann commented on WFLY-2118:
------------------------------------------

Stuart, are you saying that I should re-open this issue, *after* the beta.
                
> PersistenceException breaks default error page
> ----------------------------------------------
>
>                 Key: WFLY-2118
>                 URL: https://issues.jboss.org/browse/WFLY-2118
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>            Reporter: Juergen Zimmermann
>            Assignee: Stuart Douglas
>         Attachments: mojarra-2.1.zip, testcase-WFLY-2118.zip
>
>
> I'm using the latest WildFly snapshot with Undertow 1.0.0.Beta13. When I get a PersistenceException caused by Hibernate due to an invalid entity (according to Bean Validation), then the webbrowser doesn't get the default error page. The stacktrace is shown below. I'll attach a testcase.
> {code}
> [com.arjuna.ats.arjuna] ARJUNA012125: TwoPhaseCoordinator.beforeCompletion - failed for SynchronizationImple< 0:ffffc0a8b801:4240ead4:523ac52c:15, org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization at 20cf7473 >: javax.persistence.PersistenceException: error during managed flush
> 	at org.hibernate.jpa.spi.AbstractEntityManagerImpl$CallbackExceptionMapperImpl.mapManagedFlushFailure(AbstractEntityManagerImpl.java:1785) [hibernate-entitymanager-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:118) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:53) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:273) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:93) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1170) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
> 	at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.endTransaction(TransactionalInterceptorBase.java:131) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.invokeInOurTx(TransactionalInterceptorBase.java:77) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired.intercept(TransactionalInterceptorRequired.java:52) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_40]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_40]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_40]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_40]
> 	at org.jboss.weld.interceptor.proxy.SimpleMethodInvocation.invoke(SimpleMethodInvocation.java:30) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNext(AbstractInterceptionChain.java:90) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNextInterceptor(AbstractInterceptionChain.java:75) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:48) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:41) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:53) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at testcase.web.CustomerModel$Proxy$_$$_WeldSubclass.create(Unknown Source) [classes:]
> 	at testcase.web.CustomerModel$Proxy$_$$_WeldClientProxy.create(Unknown Source) [classes:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_40]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_40]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_40]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_40]
> 	at javax.el.ELUtil.invokeMethod(ELUtil.java:326) [javax.el-3.0-b07.jar:3.0-b07]
> 	at javax.el.BeanELResolver.invoke(BeanELResolver.java:536) [javax.el-3.0-b07.jar:3.0-b07]
> 	at javax.el.CompositeELResolver.invoke(CompositeELResolver.java:256) [javax.el-3.0-b07.jar:3.0-b07]
> 	at com.sun.el.parser.AstValue.invoke(AstValue.java:269) [javax.el-3.0-b07.jar:3.0-b07]
> 	at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:304) [javax.el-3.0-b07.jar:3.0-b07]
> 	at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105) [jsf-impl-2.1.26.jar:2.1.26]
> 	at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:87) [jsf-api-2.1.26.jar:2.1]
> 	at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:101) [jsf-impl-2.1.26.jar:2.1.26]
> 	at javax.faces.component.UICommand.broadcast(UICommand.java:315) [jsf-api-2.1.26.jar:2.1]
> 	at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:786) [jsf-api-2.1.26.jar:2.1]
> 	at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1251) [jsf-api-2.1.26.jar:2.1]
> 	at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) [jsf-impl-2.1.26.jar:2.1.26]
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593) [jsf-api-2.1.26.jar:2.1]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:59) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:209) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:196) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:130) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:614) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> Caused by: javax.validation.ConstraintViolationException: Validation failed for classes [testcase.domain.Customer] during persist time for groups [javax.validation.groups.Default, ]
> List of constraint violations:[
> 	ConstraintViolationImpl{interpolatedMessage='Min length = 2, max length = 32', propertyPath=name, rootBeanClass=class testcase.domain.Customer, messageTemplate='Min length = {min}, max length = {max}'}
> 	ConstraintViolationImpl{interpolatedMessage='Zip code is 5 digits', propertyPath=zip, rootBeanClass=class testcase.domain.Customer, messageTemplate='Zip code is 5 digits'}
> 	ConstraintViolationImpl{interpolatedMessage='A name must have one capital letter, followed by small letters', propertyPath=name, rootBeanClass=class testcase.domain.Customer, messageTemplate='A name must have one capital letter, followed by small letters'}
> ]
> 	at org.hibernate.cfg.beanvalidation.BeanValidationEventListener.validate(BeanValidationEventListener.java:159) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.cfg.beanvalidation.BeanValidationEventListener.onPreInsert(BeanValidationEventListener.java:94) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.action.internal.EntityInsertAction.preInsert(EntityInsertAction.java:196) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.action.internal.EntityInsertAction.execute(EntityInsertAction.java:96) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:377) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:369) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:286) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:340) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:52) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1235) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:405) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:113) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	... 68 more
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 05:09:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Oct 2013 05:09:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2057)
 org.jboss.as.server.deployment.RegisteredDeploymentUnitProcessor has
 unstable compareTo()
In-Reply-To: <JIRA.12500645.1379015464000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500645.1379015464000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500645.1379015464000.13268.1380877743070@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809345#comment-12809345 ] 

RH Bugzilla Integration commented on WFLY-2057:
-----------------------------------------------

Ivo Studensky <istudens at redhat.com> changed the Status of [bug 1013470|https://bugzilla.redhat.com/show_bug.cgi?id=1013470] from NEW to POST
                
> org.jboss.as.server.deployment.RegisteredDeploymentUnitProcessor has unstable compareTo()
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-2057
>                 URL: https://issues.jboss.org/browse/WFLY-2057
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>            Reporter: David Lloyd
>            Assignee: Stuart Douglas
>            Priority: Blocker
>             Fix For: 8.0.0.Beta1
>
>
> As the description says, org.jboss.as.server.deployment.RegisteredDeploymentUnitProcessor's compareTo is wrong.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 05:15:04 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Fri, 4 Oct 2013 05:15:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2183) Module and ClassName fields
 are disabled in new Custom handler dialog
In-Reply-To: <JIRA.12501821.1380539274000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501821.1380539274000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501821.1380539274000.13290.1380878104778@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun reassigned WFLY-2183:
---------------------------------

    Assignee: James Perkins  (was: Heiko Braun)

    
> Module and ClassName fields are disabled in new Custom handler dialog
> ---------------------------------------------------------------------
>
>                 Key: WFLY-2183
>                 URL: https://issues.jboss.org/browse/WFLY-2183
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, Logging
>            Reporter: Heiko Braun
>            Assignee: James Perkins
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 05:19:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Oct 2013 05:19:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2172) Resurrect the mixed domain
 testing and fix any problems
In-Reply-To: <JIRA.12501720.1380277458000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501720.1380277458000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501720.1380277458000.13309.1380878343099@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809353#comment-12809353 ] 

RH Bugzilla Integration commented on WFLY-2172:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> made a comment on [bug 1015243|https://bugzilla.redhat.com/show_bug.cgi?id=1015243]

This is necessary to be able to test interoperatbility of a EAP 6.2 DC running EAP 6.0.x and 6.1.x slaves.
                
> Resurrect the mixed domain testing and fix any problems
> -------------------------------------------------------
>
>                 Key: WFLY-2172
>                 URL: https://issues.jboss.org/browse/WFLY-2172
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Brian Stansberry
>            Priority: Blocker
>             Fix For: 8.0.0.CR1
>
>
> THis has not been run for quite some time, and needs to be included in the general testing.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 05:21:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 4 Oct 2013 05:21:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2214) LDAP security realm needs to
 have configurable timeouts
In-Reply-To: <JIRA.12502155.1380834418000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502155.1380834418000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502155.1380834418000.13320.1380878462958@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse reassigned WFLY-2214:
--------------------------------------

    Assignee: Darran Lofthouse  (was: Brian Stansberry)

    
> LDAP security realm needs to have configurable timeouts
> -------------------------------------------------------
>
>                 Key: WFLY-2214
>                 URL: https://issues.jboss.org/browse/WFLY-2214
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Derek Horton
>            Assignee: Darran Lofthouse
>
> LDAP security realm needs to have configurable timeouts.
> The default LDAP connection timeout appears to be 2 minutes.  If the ldap server is down, it could take 2 minutes for the connection to timeout.  This can cause unneeded delay if you have configured multiple ldap servers for  failover / redundancy.
> The following hack appears to work:
> +++ domain-management/src/main/java/org/jboss/as/domain/management/connections/ldap/LdapConnectionManagerService.java
> @@ -132,6 +132,7 @@ public class LdapConnectionManagerService implements Service<LdapConnectionManag
>          result.put(Context.INITIAL_CONTEXT_FACTORY,initialContextFactory);
>          String url = config.require(URL).asString();
>          result.put(Context.PROVIDER_URL,url);
> +        result.put("com.sun.jndi.ldap.connect.timeout", "500");
>          return result;
>      }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 05:21:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 4 Oct 2013 05:21:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2214) LDAP security realm needs to
 have configurable timeouts
In-Reply-To: <JIRA.12502155.1380834418000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502155.1380834418000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502155.1380834418000.13323.1380878463160@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2214:
-----------------------------------

    Fix Version/s: 8.0.0.Beta1

    
> LDAP security realm needs to have configurable timeouts
> -------------------------------------------------------
>
>                 Key: WFLY-2214
>                 URL: https://issues.jboss.org/browse/WFLY-2214
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Derek Horton
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Beta1
>
>
> LDAP security realm needs to have configurable timeouts.
> The default LDAP connection timeout appears to be 2 minutes.  If the ldap server is down, it could take 2 minutes for the connection to timeout.  This can cause unneeded delay if you have configured multiple ldap servers for  failover / redundancy.
> The following hack appears to work:
> +++ domain-management/src/main/java/org/jboss/as/domain/management/connections/ldap/LdapConnectionManagerService.java
> @@ -132,6 +132,7 @@ public class LdapConnectionManagerService implements Service<LdapConnectionManag
>          result.put(Context.INITIAL_CONTEXT_FACTORY,initialContextFactory);
>          String url = config.require(URL).asString();
>          result.put(Context.PROVIDER_URL,url);
> +        result.put("com.sun.jndi.ldap.connect.timeout", "500");
>          return result;
>      }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 05:23:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Fri, 4 Oct 2013 05:23:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2118) PersistenceException breaks
 default error page
In-Reply-To: <JIRA.12501118.1379679983000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501118.1379679983000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501118.1379679983000.13327.1380878582688@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reopened WFLY-2118:
----------------------------------



I was saying local only stack traces feature works as expected, however it can be confusing, so we should wait for more feedback after the beta to decide if we want to keep it enabled by default. 

After thinking about it a bit more however I think we should probably have this disabled by default, so I have re-opened.
                
> PersistenceException breaks default error page
> ----------------------------------------------
>
>                 Key: WFLY-2118
>                 URL: https://issues.jboss.org/browse/WFLY-2118
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>            Reporter: Juergen Zimmermann
>            Assignee: Stuart Douglas
>         Attachments: mojarra-2.1.zip, testcase-WFLY-2118.zip
>
>
> I'm using the latest WildFly snapshot with Undertow 1.0.0.Beta13. When I get a PersistenceException caused by Hibernate due to an invalid entity (according to Bean Validation), then the webbrowser doesn't get the default error page. The stacktrace is shown below. I'll attach a testcase.
> {code}
> [com.arjuna.ats.arjuna] ARJUNA012125: TwoPhaseCoordinator.beforeCompletion - failed for SynchronizationImple< 0:ffffc0a8b801:4240ead4:523ac52c:15, org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization at 20cf7473 >: javax.persistence.PersistenceException: error during managed flush
> 	at org.hibernate.jpa.spi.AbstractEntityManagerImpl$CallbackExceptionMapperImpl.mapManagedFlushFailure(AbstractEntityManagerImpl.java:1785) [hibernate-entitymanager-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:118) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:53) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:273) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:93) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1170) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
> 	at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.endTransaction(TransactionalInterceptorBase.java:131) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.invokeInOurTx(TransactionalInterceptorBase.java:77) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired.intercept(TransactionalInterceptorRequired.java:52) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_40]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_40]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_40]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_40]
> 	at org.jboss.weld.interceptor.proxy.SimpleMethodInvocation.invoke(SimpleMethodInvocation.java:30) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNext(AbstractInterceptionChain.java:90) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNextInterceptor(AbstractInterceptionChain.java:75) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:48) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:41) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:53) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at testcase.web.CustomerModel$Proxy$_$$_WeldSubclass.create(Unknown Source) [classes:]
> 	at testcase.web.CustomerModel$Proxy$_$$_WeldClientProxy.create(Unknown Source) [classes:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_40]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_40]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_40]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_40]
> 	at javax.el.ELUtil.invokeMethod(ELUtil.java:326) [javax.el-3.0-b07.jar:3.0-b07]
> 	at javax.el.BeanELResolver.invoke(BeanELResolver.java:536) [javax.el-3.0-b07.jar:3.0-b07]
> 	at javax.el.CompositeELResolver.invoke(CompositeELResolver.java:256) [javax.el-3.0-b07.jar:3.0-b07]
> 	at com.sun.el.parser.AstValue.invoke(AstValue.java:269) [javax.el-3.0-b07.jar:3.0-b07]
> 	at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:304) [javax.el-3.0-b07.jar:3.0-b07]
> 	at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105) [jsf-impl-2.1.26.jar:2.1.26]
> 	at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:87) [jsf-api-2.1.26.jar:2.1]
> 	at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:101) [jsf-impl-2.1.26.jar:2.1.26]
> 	at javax.faces.component.UICommand.broadcast(UICommand.java:315) [jsf-api-2.1.26.jar:2.1]
> 	at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:786) [jsf-api-2.1.26.jar:2.1]
> 	at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1251) [jsf-api-2.1.26.jar:2.1]
> 	at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) [jsf-impl-2.1.26.jar:2.1.26]
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593) [jsf-api-2.1.26.jar:2.1]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:59) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:209) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:196) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:130) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:614) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> Caused by: javax.validation.ConstraintViolationException: Validation failed for classes [testcase.domain.Customer] during persist time for groups [javax.validation.groups.Default, ]
> List of constraint violations:[
> 	ConstraintViolationImpl{interpolatedMessage='Min length = 2, max length = 32', propertyPath=name, rootBeanClass=class testcase.domain.Customer, messageTemplate='Min length = {min}, max length = {max}'}
> 	ConstraintViolationImpl{interpolatedMessage='Zip code is 5 digits', propertyPath=zip, rootBeanClass=class testcase.domain.Customer, messageTemplate='Zip code is 5 digits'}
> 	ConstraintViolationImpl{interpolatedMessage='A name must have one capital letter, followed by small letters', propertyPath=name, rootBeanClass=class testcase.domain.Customer, messageTemplate='A name must have one capital letter, followed by small letters'}
> ]
> 	at org.hibernate.cfg.beanvalidation.BeanValidationEventListener.validate(BeanValidationEventListener.java:159) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.cfg.beanvalidation.BeanValidationEventListener.onPreInsert(BeanValidationEventListener.java:94) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.action.internal.EntityInsertAction.preInsert(EntityInsertAction.java:196) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.action.internal.EntityInsertAction.execute(EntityInsertAction.java:96) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:377) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:369) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:286) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:340) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:52) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1235) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:405) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:113) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	... 68 more
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 05:23:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Oct 2013 05:23:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2185) Get core model test framework
 working with 7.2.0.Final legacy controller
In-Reply-To: <JIRA.12501848.1380553676000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501848.1380553676000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501848.1380553676000.13330.1380878582883@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809356#comment-12809356 ] 

RH Bugzilla Integration commented on WFLY-2185:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> made a comment on [bug 1015245|https://bugzilla.redhat.com/show_bug.cgi?id=1015245]

This is necessary to be able to test backward compatibility of EAP 6.2 against EAP 6.1, specifically the core model and subsystem transformers.
                
> Get core model test framework working with 7.2.0.Final legacy controller
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2185
>                 URL: https://issues.jboss.org/browse/WFLY-2185
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 05:23:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Oct 2013 05:23:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2173) Get subsystem test framework
 working with AS 7.2.0 legacy controller
In-Reply-To: <JIRA.12501755.1380296954000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501755.1380296954000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501755.1380296954000.13332.1380878583051@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809357#comment-12809357 ] 

RH Bugzilla Integration commented on WFLY-2173:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> made a comment on [bug 1015245|https://bugzilla.redhat.com/show_bug.cgi?id=1015245]

This is necessary to be able to test backward compatibility of EAP 6.2 against EAP 6.1, specifically the core model and subsystem transformers.
                
> Get subsystem test framework working with AS 7.2.0 legacy controller
> --------------------------------------------------------------------
>
>                 Key: WFLY-2173
>                 URL: https://issues.jboss.org/browse/WFLY-2173
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 05:39:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Fri, 4 Oct 2013 05:39:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2157) JSF ViewExpiredException
	without cookies.
In-Reply-To: <JIRA.12501535.1380124956000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501535.1380124956000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501535.1380124956000.13385.1380879542976@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-2157.
----------------------------------

    Fix Version/s: 8.0.0.Beta1
       Resolution: Done

    
> JSF ViewExpiredException without cookies.
> -----------------------------------------
>
>                 Key: WFLY-2157
>                 URL: https://issues.jboss.org/browse/WFLY-2157
>             Project: WildFly
>          Issue Type: Bug
>          Components: JSF, Web (Undertow)
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Marek Schmidt
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Beta1
>
>         Attachments: weld-numberguess.war
>
>
> On a Firefox browser with cookies disabled, a simple CDI/JSF application (Weld Numberguess example) shows the following exception (same WAR works fine on EAP 6.1 with cookies disabled)
> {noformat}
> 14:17:27,508 ERROR [io.undertow.request] (default task-5) Servlet request failed HttpServerExchange{ POST /weld-numberguess/home.jsf}: javax.servlet.ServletException: viewId:/home.jsf - View /home.jsf could not be restored.
>         at javax.faces.webapp.FacesServlet.service(FacesServlet.java:659) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
>         at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
>         at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at org.wildfly.extension.undertow.security.SecurityContextCreationHandler.handleRequest(SecurityContextCreationHandler.java:54)
>         at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:207) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:194) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:72) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:128) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:628) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
>         at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> Caused by: javax.faces.application.ViewExpiredException: viewId:/home.jsf - View /home.jsf could not be restored.
>         at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:210) [jsf-impl-2.2.1-jbossorg-1.jar:]
>         at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.1-jbossorg-1.jar:]
>         at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:121) [jsf-impl-2.2.1-jbossorg-1.jar:]
>         at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) [jsf-impl-2.2.1-jbossorg-1.jar:]
>         at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
>         ... 29 more
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 05:43:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 4 Oct 2013 05:43:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2214) LDAP security realm needs to
 have configurable timeouts
In-Reply-To: <JIRA.12502155.1380834418000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502155.1380834418000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502155.1380834418000.13394.1380879782575@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809365#comment-12809365 ] 

Darran Lofthouse commented on WFLY-2214:
----------------------------------------

This actually raises an interesting point to also consider - if we can detect that the first server was not used maybe for a short period of time we should re-order the server list to give a higher priority to the server we know does exist.

As authentication also establishes a connection to the server to verify the password it would be beneficial to lower the priority of the missing server.
                
> LDAP security realm needs to have configurable timeouts
> -------------------------------------------------------
>
>                 Key: WFLY-2214
>                 URL: https://issues.jboss.org/browse/WFLY-2214
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Derek Horton
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Beta1
>
>
> LDAP security realm needs to have configurable timeouts.
> The default LDAP connection timeout appears to be 2 minutes.  If the ldap server is down, it could take 2 minutes for the connection to timeout.  This can cause unneeded delay if you have configured multiple ldap servers for  failover / redundancy.
> The following hack appears to work:
> +++ domain-management/src/main/java/org/jboss/as/domain/management/connections/ldap/LdapConnectionManagerService.java
> @@ -132,6 +132,7 @@ public class LdapConnectionManagerService implements Service<LdapConnectionManag
>          result.put(Context.INITIAL_CONTEXT_FACTORY,initialContextFactory);
>          String url = config.require(URL).asString();
>          result.put(Context.PROVIDER_URL,url);
> +        result.put("com.sun.jndi.ldap.connect.timeout", "500");
>          return result;
>      }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 05:53:02 2013
From: jira-events at lists.jboss.org (Richard Bourner (JIRA))
Date: Fri, 4 Oct 2013 05:53:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-281) no reevaluation of 'from
 collect' is performed
In-Reply-To: <JIRA.12502111.1380805492000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502111.1380805492000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502111.1380805492000.13415.1380880382589@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809367#comment-12809367 ] 

Richard Bourner commented on DROOLS-281:
----------------------------------------

Additional information: it seems like the problem starts occuring for Beta3.
                
> no reevaluation of 'from collect' is performed
> ----------------------------------------------
>
>                 Key: DROOLS-281
>                 URL: https://issues.jboss.org/browse/DROOLS-281
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>            Reporter: Richard Bourner
>            Assignee: Mark Proctor
>            Priority: Critical
>         Attachments: Drools6FromCollectIssue.zip
>
>
> Using Drools 6.0.0.CR4, a problem has been found related to reevaluation of a condition that contains a 'from collect' statement.
> A unit test is provided demonstrating the issue using 2 rules.  This unit test works fine using 6.0.0.Beta2.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 06:32:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Oct 2013 06:32:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1913) CLI 'module add' command fail
 if a drive letter is specified in its resource path
In-Reply-To: <JIRA.12499050.1377075768000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499050.1377075768000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499050.1377075768000.13491.1380882722879@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809386#comment-12809386 ] 

RH Bugzilla Integration commented on WFLY-1913:
-----------------------------------------------

Ivo Studensky <istudens at redhat.com> changed the Status of [bug 1014921|https://bugzilla.redhat.com/show_bug.cgi?id=1014921] from ASSIGNED to POST
                
> CLI 'module add' command fail if a drive letter is specified in its resource path
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-1913
>                 URL: https://issues.jboss.org/browse/WFLY-1913
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>             Fix For: 8.0.0.Beta1
>
>         Attachments: install-mojarra-2.0.0.cli
>
>
> If a drive letter is specified in the resource path the module add command fails on MS Windows. It cannot locate such a resource because of doubled drive letter in the translated path.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 06:32:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Oct 2013 06:32:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1913) CLI 'module add' command fail
 if a drive letter is specified in its resource path
In-Reply-To: <JIRA.12499050.1377075768000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499050.1377075768000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499050.1377075768000.13494.1380882722972@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809387#comment-12809387 ] 

RH Bugzilla Integration commented on WFLY-1913:
-----------------------------------------------

Ivo Studensky <istudens at redhat.com> made a comment on [bug 1014921|https://bugzilla.redhat.com/show_bug.cgi?id=1014921]

Relevant PR:

https://github.com/jbossas/jboss-eap/pull/509
                
> CLI 'module add' command fail if a drive letter is specified in its resource path
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-1913
>                 URL: https://issues.jboss.org/browse/WFLY-1913
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>             Fix For: 8.0.0.Beta1
>
>         Attachments: install-mojarra-2.0.0.cli
>
>
> If a drive letter is specified in the resource path the module add command fails on MS Windows. It cannot locate such a resource because of doubled drive letter in the translated path.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 07:02:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Oct 2013 07:02:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2139) ProxyStepHandler/Controller
 need to check access before attempting to read information
In-Reply-To: <JIRA.12501339.1379968181000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501339.1379968181000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501339.1379968181000.13519.1380884522625@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809394#comment-12809394 ] 

RH Bugzilla Integration commented on WFLY-2139:
-----------------------------------------------

Jakub Cechacek <jcechace at redhat.com> changed the Status of [bug 1011994|https://bugzilla.redhat.com/show_bug.cgi?id=1011994] from ON_QA to VERIFIED
                
> ProxyStepHandler/Controller need to check access before attempting to read information
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-2139
>                 URL: https://issues.jboss.org/browse/WFLY-2139
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Beta1
>
>
> This affects things like recursive :read-resource(-description) :read-children-resources and so on. The problem as it stands is that if you have, say, a host scoped role scoped to host=master, and there is also a slave host controller, and you try to :read-resource(recursive=true,proxies=true), the master will list the slave host controller in its list of child addresses. It will then execute /host=slave:read-resource(recursive=true,proxies=true), which will fail and roll back the tx since the master host scoped role does not have access to that resource.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 07:02:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Oct 2013 07:02:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2139) ProxyStepHandler/Controller
 need to check access before attempting to read information
In-Reply-To: <JIRA.12501339.1379968181000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501339.1379968181000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501339.1379968181000.13522.1380884522777@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809395#comment-12809395 ] 

RH Bugzilla Integration commented on WFLY-2139:
-----------------------------------------------

Jakub Cechacek <jcechace at redhat.com> made a comment on [bug 1011994|https://bugzilla.redhat.com/show_bug.cgi?id=1011994]

Verified for 6.2.0.ER4

Tests previously failing due to this issue passed. After looking at threads through visual vm I consider this fixed.
                
> ProxyStepHandler/Controller need to check access before attempting to read information
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-2139
>                 URL: https://issues.jboss.org/browse/WFLY-2139
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Beta1
>
>
> This affects things like recursive :read-resource(-description) :read-children-resources and so on. The problem as it stands is that if you have, say, a host scoped role scoped to host=master, and there is also a slave host controller, and you try to :read-resource(recursive=true,proxies=true), the master will list the slave host controller in its list of child addresses. It will then execute /host=slave:read-resource(recursive=true,proxies=true), which will fail and roll back the tx since the master host scoped role does not have access to that resource.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 07:33:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Oct 2013 07:33:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-327) Remote JNDI is not working
 with a HornetQ-only JMS bridge
In-Reply-To: <JIRA.12485139.1361266488000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485139.1361266488000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485139.1361266488000.13579.1380886382629@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809406#comment-12809406 ] 

RH Bugzilla Integration commented on WFLY-327:
----------------------------------------------

Martin Svehla <msvehla at redhat.com> made a comment on [bug 912653|https://bugzilla.redhat.com/show_bug.cgi?id=912653]

No NotSerializableExceptions anymore. Good job.
                
> Remote JNDI is not working with a HornetQ-only JMS bridge
> ---------------------------------------------------------
>
>                 Key: WFLY-327
>                 URL: https://issues.jboss.org/browse/WFLY-327
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.Alpha1
>
>
> The jms-bridge can be used to bridge a hornetq server to another and should work by specifying to use the org.hornetq.module to load the JMS implementation classes.
> However, this fails because this module does not have access to the JBoss remote-naming module that is required to connect to remote JBoss JNDI server.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 07:33:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Oct 2013 07:33:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-327) Remote JNDI is not working
 with a HornetQ-only JMS bridge
In-Reply-To: <JIRA.12485139.1361266488000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485139.1361266488000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485139.1361266488000.13581.1380886382710@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809407#comment-12809407 ] 

RH Bugzilla Integration commented on WFLY-327:
----------------------------------------------

Martin Svehla <msvehla at redhat.com> changed the Status of [bug 912653|https://bugzilla.redhat.com/show_bug.cgi?id=912653] from ON_QA to VERIFIED
                
> Remote JNDI is not working with a HornetQ-only JMS bridge
> ---------------------------------------------------------
>
>                 Key: WFLY-327
>                 URL: https://issues.jboss.org/browse/WFLY-327
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.Alpha1
>
>
> The jms-bridge can be used to bridge a hornetq server to another and should work by specifying to use the org.hornetq.module to load the JMS implementation classes.
> However, this fails because this module does not have access to the JBoss remote-naming module that is required to connect to remote JBoss JNDI server.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 07:37:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Oct 2013 07:37:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2181) TempFileProviderService
 creates a static, non-daemon thread pool
In-Reply-To: <JIRA.12501805.1380532508000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501805.1380532508000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501805.1380532508000.13594.1380886622714@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809410#comment-12809410 ] 

RH Bugzilla Integration commented on WFLY-2181:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> made a comment on [bug 1012968|https://bugzilla.redhat.com/show_bug.cgi?id=1012968]

Verified on EAP 6.2.0.ER4
                
> TempFileProviderService creates a static, non-daemon thread pool
> ----------------------------------------------------------------
>
>                 Key: WFLY-2181
>                 URL: https://issues.jboss.org/browse/WFLY-2181
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Beta1
>
>
> This can prevent the server from shutting down

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 07:37:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Oct 2013 07:37:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2181) TempFileProviderService
 creates a static, non-daemon thread pool
In-Reply-To: <JIRA.12501805.1380532508000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501805.1380532508000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501805.1380532508000.13596.1380886622832@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809411#comment-12809411 ] 

RH Bugzilla Integration commented on WFLY-2181:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> changed the Status of [bug 1012968|https://bugzilla.redhat.com/show_bug.cgi?id=1012968] from ON_QA to VERIFIED
                
> TempFileProviderService creates a static, non-daemon thread pool
> ----------------------------------------------------------------
>
>                 Key: WFLY-2181
>                 URL: https://issues.jboss.org/browse/WFLY-2181
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Beta1
>
>
> This can prevent the server from shutting down

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 07:39:02 2013
From: jira-events at lists.jboss.org (Bartosz Baranowski (JIRA))
Date: Fri, 4 Oct 2013 07:39:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2215) WorkManagerService does not
 start work manager
In-Reply-To: <JIRA.12502196.1380886644405@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502196.1380886644405@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502196.1380886644405.13600.1380886742543@jira02.app.mwc.hst.phx2.redhat.com>

Bartosz Baranowski created WFLY-2215:
----------------------------------------

             Summary: WorkManagerService does not start work manager
                 Key: WFLY-2215
                 URL: https://issues.jboss.org/browse/WFLY-2215
             Project: WildFly
          Issue Type: Enhancement
          Components: JCA
    Affects Versions: 8.0.0.Beta1
            Reporter: Bartosz Baranowski
            Assignee: Stefano Maestri
             Fix For: 8.0.0.Beta1


WorkManagerService does not start/restart WorkManager

https://github.com/wildfly/wildfly/blob/master/connector/src/main/java/org/jboss/as/connector/services/workmanager/WorkManagerService.java#L76

WorkManager is set in constructor. In stop method, WorkManager.shutdown() is called. start() should invoke WorkManager.cancelShutdown().

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 07:41:02 2013
From: jira-events at lists.jboss.org (Nils Miehe (JIRA))
Date: Fri, 4 Oct 2013 07:41:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-285)
 JtaTransactionSynchronizationAdapter contains infite loop
In-Reply-To: <JIRA.12502197.1380886759579@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502197.1380886759579@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502197.1380886759579.13607.1380886862749@jira02.app.mwc.hst.phx2.redhat.com>

Nils Miehe created DROOLS-285:
---------------------------------

             Summary: JtaTransactionSynchronizationAdapter contains infite loop
                 Key: DROOLS-285
                 URL: https://issues.jboss.org/browse/DROOLS-285
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 5.5.0.Final
            Reporter: Nils Miehe
            Assignee: Mark Proctor
             Fix For: 6.0.0.CR5


I stumbled upon this while searching for a potential cause of JBPM-4132 .

In the method afterCompletion of JtaTransactionSynchronizationAdapter a call with STATUS_ACTIVE would cause an infinite loop. As this value in itself indicates an inconsistent state the error probably wasn't noticed earlier.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 07:45:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 4 Oct 2013 07:45:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1714) Headers: data in some headers
 might be too large in big clusters
In-Reply-To: <JIRA.12502090.1380796496000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502090.1380796496000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502090.1380796496000.13619.1380887102609@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809325#comment-12809325 ] 

Bela Ban edited comment on JGRP-1714 at 10/4/13 7:43 AM:
---------------------------------------------------------

* {{PingHeader}}: DONE
* {{FD_SOCK.FdHeader}}: DONE
* {{STABLE.StableHeader}}: DONE
* {{FLUSH.FlushHeader}}: DONE
                
      was (Author: belaban):
    * {{PingHeader}}: DONE
* {{FD_SOCK.FdHeader}}: DONE
* {{STABLE.StableHeader}}: DONE
                  
> Headers: data in some headers might be too large in big clusters
> ----------------------------------------------------------------
>
>                 Key: JGRP-1714
>                 URL: https://issues.jboss.org/browse/JGRP-1714
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> Similar to JGRP-1710 and JGRP-1713, investigate headers which might become too big, and move their contents into the message body. Check all headers which contain
> * a view
> * a digest
> * a list of members
> Candidates:
> * {{PingHeader}}. 
> Probable solution: move {{PingHeader.PingData}} from the header to the message body

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 07:45:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 4 Oct 2013 07:45:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1711) DELAY2: Do not keep the
	thread waiting
In-Reply-To: <JIRA.12501933.1380638415000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501933.1380638415000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501933.1380638415000.13624.1380887102889@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1711:
---------------------------

    Fix Version/s: 3.5
                       (was: 3.4)

    
> DELAY2: Do not keep the thread waiting
> --------------------------------------
>
>                 Key: JGRP-1711
>                 URL: https://issues.jboss.org/browse/JGRP-1711
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 3.4
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.5
>
>
> Current version of the DELAY protocol is rather simplistic - the thread is just put to sleep for some period of time. However, this does not reflect the network delay very well as it consumes the thread during the latency period.
> As the protocol should be usually placed just above TP, I'd suggest that for outcoming delay, the message/event should be placed into priority queue and another dedicated thread should pass it down after the latency period.
> For the incoming messages, we'd probably need a way to access TP's threadpools, and to find out where the currently executing thread belongs. Then, the message/event would also use priority queue and take a thread from the same threadpool in order to deliver it to upper layers.
> Another feature of this new implementation of delay protocol would be to allow constant latency, or rather specify the latency interval (from - to: currently from is always 0).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 07:49:02 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Fri, 4 Oct 2013 07:49:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2216) include-all role mappings
 don't work in domain
In-Reply-To: <JIRA.12502198.1380887272253@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502198.1380887272253@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502198.1380887272253.13628.1380887342631@jira02.app.mwc.hst.phx2.redhat.com>

Ladislav Thon created WFLY-2216:
-----------------------------------

             Summary: include-all role mappings don't work in domain
                 Key: WFLY-2216
                 URL: https://issues.jboss.org/browse/WFLY-2216
             Project: WildFly
          Issue Type: Bug
          Components: Domain Management, Security
            Reporter: Ladislav Thon
            Assignee: Darran Lofthouse


If I understand correctly, roles that have {{include-all=true}} in their role mappings should be added to all authenticated users. In my tests, though, this only works in standalone mode.

In domain mode, if I set a role mapping to {{include-all}}, this setting is not reflected (at least not immediately; maybe it would work after restart, but that's wrong anyway). It doesn't matter which role is set to be {{include-all}} -- in my tests, I use both standard roles and scoped roles and it consistently doesn't work. There's probably some wrong caching going on.

The failing test case is in my pull request https://github.com/wildfly/wildfly/pull/5166 (it's the _RBAC tests for include-all role mappings in domain_ commit). If it's more convenient, the pull request is the same as my _rbac_ branch (https://github.com/Ladicek/wildfly/commits/rbac).

Darran, I'm not sure if you are the right assignee -- please reassign if needed. Thanks.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 07:49:02 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Fri, 4 Oct 2013 07:49:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2216) include-all role mappings
 don't work in domain
In-Reply-To: <JIRA.12502198.1380887272000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502198.1380887272000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502198.1380887272000.13630.1380887342723@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ladislav Thon updated WFLY-2216:
--------------------------------

        Parent: WFLY-490
    Issue Type: Sub-task  (was: Bug)

    
> include-all role mappings don't work in domain
> ----------------------------------------------
>
>                 Key: WFLY-2216
>                 URL: https://issues.jboss.org/browse/WFLY-2216
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Ladislav Thon
>            Assignee: Darran Lofthouse
>              Labels: rbac-filed-by-qa
>
> If I understand correctly, roles that have {{include-all=true}} in their role mappings should be added to all authenticated users. In my tests, though, this only works in standalone mode.
> In domain mode, if I set a role mapping to {{include-all}}, this setting is not reflected (at least not immediately; maybe it would work after restart, but that's wrong anyway). It doesn't matter which role is set to be {{include-all}} -- in my tests, I use both standard roles and scoped roles and it consistently doesn't work. There's probably some wrong caching going on.
> The failing test case is in my pull request https://github.com/wildfly/wildfly/pull/5166 (it's the _RBAC tests for include-all role mappings in domain_ commit). If it's more convenient, the pull request is the same as my _rbac_ branch (https://github.com/Ladicek/wildfly/commits/rbac).
> Darran, I'm not sure if you are the right assignee -- please reassign if needed. Thanks.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 07:51:02 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Fri, 4 Oct 2013 07:51:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-285)
 JtaTransactionSynchronizationAdapter contains infite loop
In-Reply-To: <JIRA.12502197.1380886759000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502197.1380886759000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502197.1380886759000.13634.1380887462563@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809415#comment-12809415 ] 

Davide Sottara commented on DROOLS-285:
---------------------------------------

Good catch! Patched
                
> JtaTransactionSynchronizationAdapter contains infite loop
> ---------------------------------------------------------
>
>                 Key: DROOLS-285
>                 URL: https://issues.jboss.org/browse/DROOLS-285
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Nils Miehe
>            Assignee: Mark Proctor
>             Fix For: 6.0.0.CR5
>
>
> I stumbled upon this while searching for a potential cause of JBPM-4132 .
> In the method afterCompletion of JtaTransactionSynchronizationAdapter a call with STATUS_ACTIVE would cause an infinite loop. As this value in itself indicates an inconsistent state the error probably wasn't noticed earlier.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 07:55:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Oct 2013 07:55:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2216) include-all role mappings
 don't work in domain
In-Reply-To: <JIRA.12502198.1380887272000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502198.1380887272000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502198.1380887272000.13646.1380887702709@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2216:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1015493

    
> include-all role mappings don't work in domain
> ----------------------------------------------
>
>                 Key: WFLY-2216
>                 URL: https://issues.jboss.org/browse/WFLY-2216
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Ladislav Thon
>            Assignee: Darran Lofthouse
>              Labels: rbac-filed-by-qa
>
> If I understand correctly, roles that have {{include-all=true}} in their role mappings should be added to all authenticated users. In my tests, though, this only works in standalone mode.
> In domain mode, if I set a role mapping to {{include-all}}, this setting is not reflected (at least not immediately; maybe it would work after restart, but that's wrong anyway). It doesn't matter which role is set to be {{include-all}} -- in my tests, I use both standard roles and scoped roles and it consistently doesn't work. There's probably some wrong caching going on.
> The failing test case is in my pull request https://github.com/wildfly/wildfly/pull/5166 (it's the _RBAC tests for include-all role mappings in domain_ commit). If it's more convenient, the pull request is the same as my _rbac_ branch (https://github.com/Ladicek/wildfly/commits/rbac).
> Darran, I'm not sure if you are the right assignee -- please reassign if needed. Thanks.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 07:55:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Oct 2013 07:55:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2216) include-all role mappings
 don't work in domain
In-Reply-To: <JIRA.12502198.1380887272000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502198.1380887272000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502198.1380887272000.13649.1380887702881@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809419#comment-12809419 ] 

RH Bugzilla Integration commented on WFLY-2216:
-----------------------------------------------

Ladislav Thon <lthon at redhat.com> made a comment on [bug 1015493|https://bugzilla.redhat.com/show_bug.cgi?id=1015493]

If I understand correctly, roles that have include-all=true in their role mappings should be added to all authenticated users. In my tests, though, this only works in standalone mode.

In domain mode, if I set a role mapping to include-all, this setting is not reflected (at least not immediately; maybe it would work after restart, but that's wrong anyway). It doesn't matter which role is set to be include-all -- in my tests, I use both standard roles and scoped roles and it consistently doesn't work. There's probably some wrong caching going on.

The failing test case is in my pull request https://github.com/wildfly/wildfly/pull/5166 (it's the "RBAC tests for include-all role mappings in domain" commit). If it's more convenient, the pull request is the same as my rbac branch (https://github.com/Ladicek/wildfly/commits/rbac).

This might be related to bug 1014271.
                
> include-all role mappings don't work in domain
> ----------------------------------------------
>
>                 Key: WFLY-2216
>                 URL: https://issues.jboss.org/browse/WFLY-2216
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Ladislav Thon
>            Assignee: Darran Lofthouse
>              Labels: rbac-filed-by-qa
>
> If I understand correctly, roles that have {{include-all=true}} in their role mappings should be added to all authenticated users. In my tests, though, this only works in standalone mode.
> In domain mode, if I set a role mapping to {{include-all}}, this setting is not reflected (at least not immediately; maybe it would work after restart, but that's wrong anyway). It doesn't matter which role is set to be {{include-all}} -- in my tests, I use both standard roles and scoped roles and it consistently doesn't work. There's probably some wrong caching going on.
> The failing test case is in my pull request https://github.com/wildfly/wildfly/pull/5166 (it's the _RBAC tests for include-all role mappings in domain_ commit). If it's more convenient, the pull request is the same as my _rbac_ branch (https://github.com/Ladicek/wildfly/commits/rbac).
> Darran, I'm not sure if you are the right assignee -- please reassign if needed. Thanks.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 08:13:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 4 Oct 2013 08:13:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1714) Headers: data in some headers
 might be too large in big clusters
In-Reply-To: <JIRA.12502090.1380796496000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502090.1380796496000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502090.1380796496000.13689.1380888783174@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1714.
----------------------------

    Resolution: Done

    
> Headers: data in some headers might be too large in big clusters
> ----------------------------------------------------------------
>
>                 Key: JGRP-1714
>                 URL: https://issues.jboss.org/browse/JGRP-1714
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> Similar to JGRP-1710 and JGRP-1713, investigate headers which might become too big, and move their contents into the message body. Check all headers which contain
> * a view
> * a digest
> * a list of members
> Candidates:
> * {{PingHeader}}. 
> Probable solution: move {{PingHeader.PingData}} from the header to the message body

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 08:15:03 2013
From: jira-events at lists.jboss.org (Bartosz Baranowski (JIRA))
Date: Fri, 4 Oct 2013 08:15:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2217) Enable reload tests
In-Reply-To: <JIRA.12502203.1380888864921@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502203.1380888864921@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502203.1380888864921.13695.1380888903302@jira02.app.mwc.hst.phx2.redhat.com>

Bartosz Baranowski created WFLY-2217:
----------------------------------------

             Summary: Enable reload tests
                 Key: WFLY-2217
                 URL: https://issues.jboss.org/browse/WFLY-2217
             Project: WildFly
          Issue Type: Enhancement
          Components: Test Suite
    Affects Versions: 8.0.0.Beta1
            Reporter: Bartosz Baranowski
            Assignee: Ondrej Zizka


Tests need not stay ignored any longer!


Some tests which :reload are still ignored, even though :reload has been fixed ( well, it seems there is more to it due to other code changes )

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 08:29:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 4 Oct 2013 08:29:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1709) Logging: convert the most
 important WARN and ERROR messages to use IDs and resource bundles
In-Reply-To: <JIRA.12501808.1380533726000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501808.1380533726000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501808.1380533726000.13722.1380889742609@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808947#comment-12808947 ] 

Bela Ban edited comment on JGRP-1709 at 10/4/13 8:28 AM:
---------------------------------------------------------

The following classes below still need to be converted, excluding
- classes that are not officially supported (STOMP, PRIO)
- classes that are not used anymore (e.g. NAKACK, NakReceiverWindow, Retransmitter, DefaultRetransmitter, RangeBasedRetransmitter etc)
- test code (StateTransferTest)
- demos (Whiteboard, GraphPanel, Draw, QuoteServer)

{panel}
-src/org/jgroups/stack/Configurator.java-
-src/org/jgroups/conf/XmlConfigurator.java-
-src/org/jgroups/conf/PropertyHelper.java-
-src/org/jgroups/conf/ProtocolConfiguration.java-
-src/org/jgroups/conf/ClassConfigurator.java-
src/org/jgroups/protocols/FILE_PING.java
src/org/jgroups/protocols/FD_SOCK.java
src/org/jgroups/protocols/RSVP.java
src/org/jgroups/protocols/UDP.java
src/org/jgroups/protocols/FD_PING.java
src/org/jgroups/protocols/COMPRESS.java
src/org/jgroups/protocols/VERIFY_SUSPECT.java
src/org/jgroups/protocols/MFC.java
src/org/jgroups/protocols/MERGE3.java
src/org/jgroups/protocols/FRAG2.java
src/org/jgroups/protocols/FlowControl.java
src/org/jgroups/protocols/ENCRYPT.java
src/org/jgroups/protocols/FORWARD_TO_COORD.java
src/org/jgroups/protocols/S3_PING.java
src/org/jgroups/protocols/FD.java
src/org/jgroups/protocols/UNICAST2.java
src/org/jgroups/protocols/Discovery.java
src/org/jgroups/protocols/JDBC_PING.java
src/org/jgroups/protocols/TCP.java
src/org/jgroups/protocols/UFC.java
src/org/jgroups/protocols/SEQUENCER.java
src/org/jgroups/protocols/AUTH.java
src/org/jgroups/protocols/TP.java
src/org/jgroups/protocols/TCPGOSSIP.java
src/org/jgroups/protocols/MPING.java
src/org/jgroups/protocols/pbcast/GMS.java
src/org/jgroups/protocols/pbcast/GmsImpl.java
src/org/jgroups/protocols/pbcast/STATE_TRANSFER.java
src/org/jgroups/protocols/pbcast/ClientGmsImpl.java
src/org/jgroups/protocols/pbcast/StreamingStateTransfer.java
src/org/jgroups/protocols/pbcast/Merger.java
src/org/jgroups/protocols/pbcast/CoordGmsImpl.java
src/org/jgroups/protocols/pbcast/STABLE.java
src/org/jgroups/protocols/pbcast/FLUSH.java
src/org/jgroups/protocols/pbcast/STATE_SOCK.java
-src/org/jgroups/protocols/pbcast/NAKACK2.java-
src/org/jgroups/protocols/relay/RELAY2.java
src/org/jgroups/protocols/relay/Relayer.java
src/org/jgroups/protocols/tom/TOA.java
src/org/jgroups/util/TimeScheduler2.java
src/org/jgroups/util/Util.java
src/org/jgroups/util/ForwardQueue.java
src/org/jgroups/util/Queue.java
src/org/jgroups/jmx/ResourceDMBean.java
src/org/jgroups/jmx/JmxConfigurator.java
src/org/jgroups/blocks/RequestCorrelator.java
src/org/jgroups/blocks/GroupRequest.java
src/org/jgroups/blocks/TCPConnectionMap.java
src/org/jgroups/blocks/Request.java
src/org/jgroups/blocks/RpcDispatcher.java
src/org/jgroups/blocks/MethodCall.java
src/org/jgroups/blocks/MessageDispatcher.java
src/org/jgroups/auth/MD5Token.java
src/org/jgroups/auth/FixedMembershipToken.java
src/org/jgroups/auth/SimpleToken.java
src/org/jgroups/auth/X509Token.java
{panel}
                
      was (Author: belaban):
    The following classes below still need to be converted, excluding
- classes that are not officially supported (STOMP, PRIO)
- classes that are not used anymore (e.g. NAKACK, NakReceiverWindow, Retransmitter, DefaultRetransmitter, RangeBasedRetransmitter etc)
- test code (StateTransferTest)
- demos (Whiteboard, GraphPanel, Draw, QuoteServer)

{panel}
-src/org/jgroups/stack/Configurator.java-
-src/org/jgroups/conf/XmlConfigurator.java-
-src/org/jgroups/conf/PropertyHelper.java-
-src/org/jgroups/conf/ProtocolConfiguration.java-
-src/org/jgroups/conf/ClassConfigurator.java-
src/org/jgroups/protocols/FILE_PING.java
src/org/jgroups/protocols/FD_SOCK.java
src/org/jgroups/protocols/RSVP.java
src/org/jgroups/protocols/UDP.java
src/org/jgroups/protocols/FD_PING.java
src/org/jgroups/protocols/COMPRESS.java
src/org/jgroups/protocols/VERIFY_SUSPECT.java
src/org/jgroups/protocols/MFC.java
src/org/jgroups/protocols/MERGE3.java
src/org/jgroups/protocols/FRAG2.java
src/org/jgroups/protocols/FlowControl.java
src/org/jgroups/protocols/ENCRYPT.java
src/org/jgroups/protocols/FORWARD_TO_COORD.java
src/org/jgroups/protocols/S3_PING.java
src/org/jgroups/protocols/FD.java
src/org/jgroups/protocols/UNICAST2.java
src/org/jgroups/protocols/Discovery.java
src/org/jgroups/protocols/JDBC_PING.java
src/org/jgroups/protocols/TCP.java
src/org/jgroups/protocols/UFC.java
src/org/jgroups/protocols/SEQUENCER.java
src/org/jgroups/protocols/AUTH.java
src/org/jgroups/protocols/TP.java
src/org/jgroups/protocols/TCPGOSSIP.java
src/org/jgroups/protocols/MPING.java
src/org/jgroups/protocols/pbcast/GMS.java
src/org/jgroups/protocols/pbcast/GmsImpl.java
src/org/jgroups/protocols/pbcast/STATE_TRANSFER.java
src/org/jgroups/protocols/pbcast/ClientGmsImpl.java
src/org/jgroups/protocols/pbcast/StreamingStateTransfer.java
src/org/jgroups/protocols/pbcast/Merger.java
src/org/jgroups/protocols/pbcast/CoordGmsImpl.java
src/org/jgroups/protocols/pbcast/STABLE.java
src/org/jgroups/protocols/pbcast/FLUSH.java
src/org/jgroups/protocols/pbcast/STATE_SOCK.java
src/org/jgroups/protocols/pbcast/NAKACK2.java
src/org/jgroups/protocols/relay/RELAY2.java
src/org/jgroups/protocols/relay/Relayer.java
src/org/jgroups/protocols/tom/TOA.java
src/org/jgroups/util/TimeScheduler2.java
src/org/jgroups/util/Util.java
src/org/jgroups/util/ForwardQueue.java
src/org/jgroups/util/Queue.java
src/org/jgroups/jmx/ResourceDMBean.java
src/org/jgroups/jmx/JmxConfigurator.java
src/org/jgroups/blocks/RequestCorrelator.java
src/org/jgroups/blocks/GroupRequest.java
src/org/jgroups/blocks/TCPConnectionMap.java
src/org/jgroups/blocks/Request.java
src/org/jgroups/blocks/RpcDispatcher.java
src/org/jgroups/blocks/MethodCall.java
src/org/jgroups/blocks/MessageDispatcher.java
src/org/jgroups/auth/MD5Token.java
src/org/jgroups/auth/FixedMembershipToken.java
src/org/jgroups/auth/SimpleToken.java
src/org/jgroups/auth/X509Token.java
{panel}
                  
> Logging: convert the most important WARN and ERROR messages to use IDs and resource bundles
> -------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1709
>                 URL: https://issues.jboss.org/browse/JGRP-1709
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.4
>
>
> Convert WARN and ERROR messages that might be seen by users to use a resource bundle (conf/jg-messages*.properties) and assign unique IDs the those messages.
> Link in BZ: https://bugzilla.redhat.com/show_bug.cgi?id=999671

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 08:29:02 2013
From: jira-events at lists.jboss.org (Bartosz Baranowski (JIRA))
Date: Fri, 4 Oct 2013 08:29:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2217) Enable reload tests
In-Reply-To: <JIRA.12502203.1380888864000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502203.1380888864000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502203.1380888864000.13728.1380889742867@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bartosz Baranowski reassigned WFLY-2217:
----------------------------------------

    Assignee: Bartosz Baranowski  (was: Ondrej Zizka)

    
> Enable reload tests
> -------------------
>
>                 Key: WFLY-2217
>                 URL: https://issues.jboss.org/browse/WFLY-2217
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Test Suite
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Bartosz Baranowski
>            Assignee: Bartosz Baranowski
>
> Tests need not stay ignored any longer!
> Some tests which :reload are still ignored, even though :reload has been fixed ( well, it seems there is more to it due to other code changes )

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 08:31:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Oct 2013 08:31:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2177) org.jboss.logmanager module
 needs dependency on javax.api for the SocketFactory
In-Reply-To: <JIRA.12501765.1380321136000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501765.1380321136000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501765.1380321136000.13733.1380889862647@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809427#comment-12809427 ] 

RH Bugzilla Integration commented on WFLY-2177:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> made a comment on [bug 1013169|https://bugzilla.redhat.com/show_bug.cgi?id=1013169]

Verified on EAP 6.2.0.ER4
                
> org.jboss.logmanager module needs dependency on javax.api for the SocketFactory
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-2177
>                 URL: https://issues.jboss.org/browse/WFLY-2177
>             Project: WildFly
>          Issue Type: Bug
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 8.0.0.Beta1
>
>
> The {{javax.net.SocketFactory}} is part of the {{javax.api}} module. Since the {{org.jboss.logmanager}} uses this for the syslog handler on TCP and SSL connections, a dependency on the module is needed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 08:31:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Oct 2013 08:31:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2177) org.jboss.logmanager module
 needs dependency on javax.api for the SocketFactory
In-Reply-To: <JIRA.12501765.1380321136000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501765.1380321136000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501765.1380321136000.13736.1380889862833@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809428#comment-12809428 ] 

RH Bugzilla Integration commented on WFLY-2177:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> changed the Status of [bug 1013169|https://bugzilla.redhat.com/show_bug.cgi?id=1013169] from ON_QA to VERIFIED
                
> org.jboss.logmanager module needs dependency on javax.api for the SocketFactory
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-2177
>                 URL: https://issues.jboss.org/browse/WFLY-2177
>             Project: WildFly
>          Issue Type: Bug
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 8.0.0.Beta1
>
>
> The {{javax.net.SocketFactory}} is part of the {{javax.api}} module. Since the {{org.jboss.logmanager}} uses this for the syslog handler on TCP and SSL connections, a dependency on the module is needed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 08:42:02 2013
From: jira-events at lists.jboss.org (Ben Romberg (JIRA))
Date: Fri, 4 Oct 2013 08:42:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-209) Nested classes read from
 ClassMemberValue cannot be loaded
In-Reply-To: <JIRA.12501979.1380703145000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501979.1380703145000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501979.1380703145000.13749.1380890522577@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JASSIST-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ben Romberg updated JASSIST-209:
--------------------------------

    Affects Version/s: 3.18.1-GA

    
> Nested classes read from ClassMemberValue cannot be loaded
> ----------------------------------------------------------
>
>                 Key: JASSIST-209
>                 URL: https://issues.jboss.org/browse/JASSIST-209
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.18.0-GA, 3.18.1-GA
>            Reporter: Ben Romberg
>            Assignee: Shigeru Chiba
>
> I'm trying to upgrade Javassist in my project from version 3.16.1 to 3.18.0. I'm using the ClassMemberValue to load the (String) class-name of an annotation value, in order to load the class with Javassist using ClassPool.get(...).
> In 3.16.1, the returned class-name String for nested classes contained the $-sign, as in package.ParentClass$NestedClass, which didn't have any issues using the String with ClassPool.get(...).
> In 3.18.0 however, the returned class-name String for nested classes changed to a pure dot-notation, as in package.ParentClass.NestedClass, which cannot be used with ClassPool.get(...) anymore, as Javassist tries to load the class-file from package/ParentClass/NestedClass.class instead of package/ParentClass$NestedClass.class.
> I don't see any way to work around the issue without hacking into internal API, as the class-name String is the only way to get the annotation value. As this is a generic class (and not always a nested class), I also cannot simply replace the last dot with a $-sign.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 08:56:03 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 4 Oct 2013 08:56:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2215) WorkManagerService does not
 start work manager
In-Reply-To: <JIRA.12502196.1380886644000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502196.1380886644000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502196.1380886644000.13805.1380891363120@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809437#comment-12809437 ] 

David Lloyd commented on WFLY-2215:
-----------------------------------

Every service in the container *must* be symmetrical.  This means that if you stop and start the service again, when start completes, the service will be at exactly the same level of usability that it was before it was stopped.  In other words, all work done in stop must undo the work done in start (nothing more, nothing less).

Furthermore, your requirement "start() should invoke WorkManager.cancelShutdown()" is wrong.  The stop() method should not complete until the work manager has completed shutdown.  Use asynchronous stop for this if necessary.
                
> WorkManagerService does not start work manager
> ----------------------------------------------
>
>                 Key: WFLY-2215
>                 URL: https://issues.jboss.org/browse/WFLY-2215
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: JCA
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Bartosz Baranowski
>            Assignee: Stefano Maestri
>             Fix For: 8.0.0.Beta1
>
>
> WorkManagerService does not start/restart WorkManager
> https://github.com/wildfly/wildfly/blob/master/connector/src/main/java/org/jboss/as/connector/services/workmanager/WorkManagerService.java#L76
> WorkManager is set in constructor. In stop method, WorkManager.shutdown() is called. start() should invoke WorkManager.cancelShutdown().

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 08:56:03 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 4 Oct 2013 08:56:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2215) WorkManagerService does not
 start work manager
In-Reply-To: <JIRA.12502196.1380886644000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502196.1380886644000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502196.1380886644000.13812.1380891363630@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809438#comment-12809438 ] 

David Lloyd commented on WFLY-2215:
-----------------------------------

It is *always* wrong to perform service start tasks in the constructor of the service.
                
> WorkManagerService does not start work manager
> ----------------------------------------------
>
>                 Key: WFLY-2215
>                 URL: https://issues.jboss.org/browse/WFLY-2215
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: JCA
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Bartosz Baranowski
>            Assignee: Stefano Maestri
>             Fix For: 8.0.0.Beta1
>
>
> WorkManagerService does not start/restart WorkManager
> https://github.com/wildfly/wildfly/blob/master/connector/src/main/java/org/jboss/as/connector/services/workmanager/WorkManagerService.java#L76
> WorkManager is set in constructor. In stop method, WorkManager.shutdown() is called. start() should invoke WorkManager.cancelShutdown().

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 08:58:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 4 Oct 2013 08:58:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1709) Logging: convert the most
 important WARN and ERROR messages to use IDs and resource bundles
In-Reply-To: <JIRA.12501808.1380533726000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501808.1380533726000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501808.1380533726000.13816.1380891482618@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808947#comment-12808947 ] 

Bela Ban edited comment on JGRP-1709 at 10/4/13 8:56 AM:
---------------------------------------------------------

The following classes below still need to be converted, excluding
- classes that are not officially supported (STOMP, PRIO)
- classes that are not used anymore (e.g. NAKACK, NakReceiverWindow, Retransmitter, DefaultRetransmitter, RangeBasedRetransmitter etc)
- test code (StateTransferTest)
- demos (Whiteboard, GraphPanel, Draw, QuoteServer)

{panel}
-src/org/jgroups/stack/Configurator.java-
-src/org/jgroups/conf/XmlConfigurator.java-
-src/org/jgroups/conf/PropertyHelper.java-
-src/org/jgroups/conf/ProtocolConfiguration.java-
-src/org/jgroups/conf/ClassConfigurator.java-
src/org/jgroups/protocols/FILE_PING.java
src/org/jgroups/protocols/FD_SOCK.java
src/org/jgroups/protocols/RSVP.java
src/org/jgroups/protocols/UDP.java
src/org/jgroups/protocols/FD_PING.java
src/org/jgroups/protocols/COMPRESS.java
src/org/jgroups/protocols/VERIFY_SUSPECT.java
src/org/jgroups/protocols/MFC.java
src/org/jgroups/protocols/MERGE3.java
src/org/jgroups/protocols/FRAG2.java
src/org/jgroups/protocols/FlowControl.java
src/org/jgroups/protocols/ENCRYPT.java
src/org/jgroups/protocols/FORWARD_TO_COORD.java
src/org/jgroups/protocols/S3_PING.java
src/org/jgroups/protocols/FD.java
-src/org/jgroups/protocols/UNICAST3.java-
src/org/jgroups/protocols/Discovery.java
src/org/jgroups/protocols/JDBC_PING.java
src/org/jgroups/protocols/TCP.java
src/org/jgroups/protocols/UFC.java
src/org/jgroups/protocols/SEQUENCER.java
src/org/jgroups/protocols/AUTH.java
src/org/jgroups/protocols/TP.java
src/org/jgroups/protocols/TCPGOSSIP.java
src/org/jgroups/protocols/MPING.java
src/org/jgroups/protocols/pbcast/GMS.java
src/org/jgroups/protocols/pbcast/GmsImpl.java
src/org/jgroups/protocols/pbcast/STATE_TRANSFER.java
src/org/jgroups/protocols/pbcast/ClientGmsImpl.java
src/org/jgroups/protocols/pbcast/StreamingStateTransfer.java
src/org/jgroups/protocols/pbcast/Merger.java
src/org/jgroups/protocols/pbcast/CoordGmsImpl.java
src/org/jgroups/protocols/pbcast/STABLE.java
src/org/jgroups/protocols/pbcast/FLUSH.java
src/org/jgroups/protocols/pbcast/STATE_SOCK.java
-src/org/jgroups/protocols/pbcast/NAKACK2.java-
src/org/jgroups/protocols/relay/RELAY2.java
src/org/jgroups/protocols/relay/Relayer.java
src/org/jgroups/protocols/tom/TOA.java
src/org/jgroups/util/TimeScheduler2.java
src/org/jgroups/util/Util.java
src/org/jgroups/util/ForwardQueue.java
src/org/jgroups/util/Queue.java
src/org/jgroups/jmx/ResourceDMBean.java
src/org/jgroups/jmx/JmxConfigurator.java
src/org/jgroups/blocks/RequestCorrelator.java
src/org/jgroups/blocks/GroupRequest.java
src/org/jgroups/blocks/TCPConnectionMap.java
src/org/jgroups/blocks/Request.java
src/org/jgroups/blocks/RpcDispatcher.java
src/org/jgroups/blocks/MethodCall.java
src/org/jgroups/blocks/MessageDispatcher.java
src/org/jgroups/auth/MD5Token.java
src/org/jgroups/auth/FixedMembershipToken.java
src/org/jgroups/auth/SimpleToken.java
src/org/jgroups/auth/X509Token.java
{panel}
                
      was (Author: belaban):
    The following classes below still need to be converted, excluding
- classes that are not officially supported (STOMP, PRIO)
- classes that are not used anymore (e.g. NAKACK, NakReceiverWindow, Retransmitter, DefaultRetransmitter, RangeBasedRetransmitter etc)
- test code (StateTransferTest)
- demos (Whiteboard, GraphPanel, Draw, QuoteServer)

{panel}
-src/org/jgroups/stack/Configurator.java-
-src/org/jgroups/conf/XmlConfigurator.java-
-src/org/jgroups/conf/PropertyHelper.java-
-src/org/jgroups/conf/ProtocolConfiguration.java-
-src/org/jgroups/conf/ClassConfigurator.java-
src/org/jgroups/protocols/FILE_PING.java
src/org/jgroups/protocols/FD_SOCK.java
src/org/jgroups/protocols/RSVP.java
src/org/jgroups/protocols/UDP.java
src/org/jgroups/protocols/FD_PING.java
src/org/jgroups/protocols/COMPRESS.java
src/org/jgroups/protocols/VERIFY_SUSPECT.java
src/org/jgroups/protocols/MFC.java
src/org/jgroups/protocols/MERGE3.java
src/org/jgroups/protocols/FRAG2.java
src/org/jgroups/protocols/FlowControl.java
src/org/jgroups/protocols/ENCRYPT.java
src/org/jgroups/protocols/FORWARD_TO_COORD.java
src/org/jgroups/protocols/S3_PING.java
src/org/jgroups/protocols/FD.java
src/org/jgroups/protocols/UNICAST2.java
src/org/jgroups/protocols/Discovery.java
src/org/jgroups/protocols/JDBC_PING.java
src/org/jgroups/protocols/TCP.java
src/org/jgroups/protocols/UFC.java
src/org/jgroups/protocols/SEQUENCER.java
src/org/jgroups/protocols/AUTH.java
src/org/jgroups/protocols/TP.java
src/org/jgroups/protocols/TCPGOSSIP.java
src/org/jgroups/protocols/MPING.java
src/org/jgroups/protocols/pbcast/GMS.java
src/org/jgroups/protocols/pbcast/GmsImpl.java
src/org/jgroups/protocols/pbcast/STATE_TRANSFER.java
src/org/jgroups/protocols/pbcast/ClientGmsImpl.java
src/org/jgroups/protocols/pbcast/StreamingStateTransfer.java
src/org/jgroups/protocols/pbcast/Merger.java
src/org/jgroups/protocols/pbcast/CoordGmsImpl.java
src/org/jgroups/protocols/pbcast/STABLE.java
src/org/jgroups/protocols/pbcast/FLUSH.java
src/org/jgroups/protocols/pbcast/STATE_SOCK.java
-src/org/jgroups/protocols/pbcast/NAKACK2.java-
src/org/jgroups/protocols/relay/RELAY2.java
src/org/jgroups/protocols/relay/Relayer.java
src/org/jgroups/protocols/tom/TOA.java
src/org/jgroups/util/TimeScheduler2.java
src/org/jgroups/util/Util.java
src/org/jgroups/util/ForwardQueue.java
src/org/jgroups/util/Queue.java
src/org/jgroups/jmx/ResourceDMBean.java
src/org/jgroups/jmx/JmxConfigurator.java
src/org/jgroups/blocks/RequestCorrelator.java
src/org/jgroups/blocks/GroupRequest.java
src/org/jgroups/blocks/TCPConnectionMap.java
src/org/jgroups/blocks/Request.java
src/org/jgroups/blocks/RpcDispatcher.java
src/org/jgroups/blocks/MethodCall.java
src/org/jgroups/blocks/MessageDispatcher.java
src/org/jgroups/auth/MD5Token.java
src/org/jgroups/auth/FixedMembershipToken.java
src/org/jgroups/auth/SimpleToken.java
src/org/jgroups/auth/X509Token.java
{panel}
                  
> Logging: convert the most important WARN and ERROR messages to use IDs and resource bundles
> -------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1709
>                 URL: https://issues.jboss.org/browse/JGRP-1709
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.4
>
>
> Convert WARN and ERROR messages that might be seen by users to use a resource bundle (conf/jg-messages*.properties) and assign unique IDs the those messages.
> Link in BZ: https://bugzilla.redhat.com/show_bug.cgi?id=999671

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 08:58:02 2013
From: jira-events at lists.jboss.org (Bartosz Baranowski (JIRA))
Date: Fri, 4 Oct 2013 08:58:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1087) Leak of WorkManager and
	BootstrapContext
In-Reply-To: <JIRA.12502210.1380891451763@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502210.1380891451763@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502210.1380891451763.13820.1380891482775@jira02.app.mwc.hst.phx2.redhat.com>

Bartosz Baranowski created JBJCA-1087:
-----------------------------------------

             Summary: Leak of WorkManager and BootstrapContext
                 Key: JBJCA-1087
                 URL: https://issues.jboss.org/browse/JBJCA-1087
             Project: IronJacamar
          Issue Type: Bug
          Components: Core
    Affects Versions: 1.1.0.Final
            Reporter: Bartosz Baranowski
            Assignee: Jesper Pedersen


There seems to be a leak of WorkManager and BootstrapContext clones. 
NOTE: The clones are not standalone, for instance WorkManagerImpl.shutdown reference is shared among all clones, if one is shutdown, all of them are.

The coordinators have an internal map of name/id -> [ BootstrapContext | WorkManager ]. They keep clones of default instance in it. In IJ code, deployers invoke coordinator.remove() method to keep it clean. However this does not happen in WFLY/AS7 ( only create is called ). 
Here is a step by step scenario( more or less ):
1. WFLY boots
2. WorkManagerService is created( along with WorkManager instance, the default used in WMCoordinator )
3. RA is deployed/activated
4. IJ checks if there is BootstrapContext/WorkManager under "X", there is none, IJ creates clone of WM from #2 and BootstrapContext,  its stored under "X" in coordinators
5. Normal operations, msgs exchange, etc.
6. WFLY reload is called
7. WM from #2 shutdown() is called, this renders the clone stored under "X" as shutdown as well.
8. WFLY boots again
9. new WorkManagerService is created( along with WorkManager instance, the default used in WMCoordinator )
10. RA is deployed/activate
11. IJ checks if there is BootstrapContext/WorkManager under "X", there is, this instance is returned. 

#11 old instance, which is shutdown since #7, is passed as WorkManager. This explodes:

{noformat}
ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 29) MSC000001: Failed to start service jboss.deployment.unit."mdb.jar".component.MDBLifecycleCallback.START: org.jboss.msc.service.StartException in service jboss.deployment.unit."mdb.jar".component.MDBLifecycleCallback.START: java.lang.RuntimeException: javax.resource.spi.work.WorkRejectedException: IJ000263: WorkManager is shutting down
	at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:57)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_25]
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_25]
	at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_25]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
Caused by: java.lang.RuntimeException: javax.resource.spi.work.WorkRejectedException: IJ000263: WorkManager is shutting down
	at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent.activate(MessageDrivenComponent.java:218)
	at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent.start(MessageDrivenComponent.java:189)
	at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
	... 7 more
Caused by: javax.resource.spi.work.WorkRejectedException: IJ000263: WorkManager is shutting down
	at org.jboss.jca.core.workmanager.WorkManagerImpl.doFirstChecks(WorkManagerImpl.java:776)
	at org.jboss.jca.core.workmanager.WorkManagerImpl.scheduleWork(WorkManagerImpl.java:617)
	at org.jboss.jca.core.workmanager.WorkManagerImpl.scheduleWork(WorkManagerImpl.java:602)
	at org.hornetq.ra.inflow.HornetQActivation.start(HornetQActivation.java:259)
	at org.hornetq.ra.HornetQResourceAdapter.endpointActivation(HornetQResourceAdapter.java:167)
	at org.jboss.jca.core.rar.EndpointImpl.activate(EndpointImpl.java:191)
	at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent.activate(MessageDrivenComponent.java:216)
	... 9 more
{noformat}


Steps to reproduce:
1. Setup an adapter deployment
2. reload
3. deploy MDB

The reload OP has small bug, this branch (https://github.com/baranowb/wildfly/tree/WFLY-2217) has it fixed.
Example test set: 
{noformat}
mvn clean install -DallTest -Dtest=CustomBootstrapContextTestCase,GetCallerPrincipalTestCase
{noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 09:02:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Oct 2013 09:02:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2217) Enable reload tests
In-Reply-To: <JIRA.12502203.1380888864000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502203.1380888864000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502203.1380888864000.13841.1380891723117@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2217:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=900065

    
> Enable reload tests
> -------------------
>
>                 Key: WFLY-2217
>                 URL: https://issues.jboss.org/browse/WFLY-2217
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Test Suite
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Bartosz Baranowski
>            Assignee: Bartosz Baranowski
>
> Tests need not stay ignored any longer!
> Some tests which :reload are still ignored, even though :reload has been fixed ( well, it seems there is more to it due to other code changes )

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 09:06:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 4 Oct 2013 09:06:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1709) Logging: convert the most
 important WARN and ERROR messages to use IDs and resource bundles
In-Reply-To: <JIRA.12501808.1380533726000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501808.1380533726000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501808.1380533726000.13855.1380891962806@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808947#comment-12808947 ] 

Bela Ban edited comment on JGRP-1709 at 10/4/13 9:05 AM:
---------------------------------------------------------

The following classes below still need to be converted, excluding
- classes that are not officially supported (STOMP, PRIO)
- classes that are not used anymore (e.g. NAKACK, NakReceiverWindow, Retransmitter, DefaultRetransmitter, RangeBasedRetransmitter etc)
- test code (StateTransferTest)
- demos (Whiteboard, GraphPanel, Draw, QuoteServer)

{panel}
-src/org/jgroups/stack/Configurator.java-
-src/org/jgroups/conf/XmlConfigurator.java-
-src/org/jgroups/conf/PropertyHelper.java-
-src/org/jgroups/conf/ProtocolConfiguration.java-
-src/org/jgroups/conf/ClassConfigurator.java-
src/org/jgroups/protocols/FILE_PING.java
src/org/jgroups/protocols/FD_SOCK.java
src/org/jgroups/protocols/RSVP.java
src/org/jgroups/protocols/UDP.java
src/org/jgroups/protocols/FD_PING.java
src/org/jgroups/protocols/COMPRESS.java
src/org/jgroups/protocols/VERIFY_SUSPECT.java
src/org/jgroups/protocols/MFC.java
src/org/jgroups/protocols/MERGE3.java
src/org/jgroups/protocols/FRAG2.java
src/org/jgroups/protocols/FlowControl.java
src/org/jgroups/protocols/ENCRYPT.java
src/org/jgroups/protocols/FORWARD_TO_COORD.java
src/org/jgroups/protocols/S3_PING.java
src/org/jgroups/protocols/FD.java
-src/org/jgroups/protocols/UNICAST3.java-
src/org/jgroups/protocols/Discovery.java
src/org/jgroups/protocols/JDBC_PING.java
src/org/jgroups/protocols/TCP.java
src/org/jgroups/protocols/UFC.java
src/org/jgroups/protocols/SEQUENCER.java
src/org/jgroups/protocols/AUTH.java
-src/org/jgroups/protocols/TP.java-
src/org/jgroups/protocols/TCPGOSSIP.java
src/org/jgroups/protocols/MPING.java
src/org/jgroups/protocols/pbcast/GMS.java
src/org/jgroups/protocols/pbcast/GmsImpl.java
src/org/jgroups/protocols/pbcast/STATE_TRANSFER.java
src/org/jgroups/protocols/pbcast/ClientGmsImpl.java
src/org/jgroups/protocols/pbcast/StreamingStateTransfer.java
src/org/jgroups/protocols/pbcast/Merger.java
src/org/jgroups/protocols/pbcast/CoordGmsImpl.java
src/org/jgroups/protocols/pbcast/STABLE.java
src/org/jgroups/protocols/pbcast/FLUSH.java
src/org/jgroups/protocols/pbcast/STATE_SOCK.java
-src/org/jgroups/protocols/pbcast/NAKACK2.java-
src/org/jgroups/protocols/relay/RELAY2.java
src/org/jgroups/protocols/relay/Relayer.java
src/org/jgroups/protocols/tom/TOA.java
src/org/jgroups/util/TimeScheduler2.java
src/org/jgroups/util/Util.java
src/org/jgroups/util/ForwardQueue.java
src/org/jgroups/util/Queue.java
src/org/jgroups/jmx/ResourceDMBean.java
src/org/jgroups/jmx/JmxConfigurator.java
src/org/jgroups/blocks/RequestCorrelator.java
src/org/jgroups/blocks/GroupRequest.java
src/org/jgroups/blocks/TCPConnectionMap.java
src/org/jgroups/blocks/Request.java
src/org/jgroups/blocks/RpcDispatcher.java
src/org/jgroups/blocks/MethodCall.java
src/org/jgroups/blocks/MessageDispatcher.java
src/org/jgroups/auth/MD5Token.java
src/org/jgroups/auth/FixedMembershipToken.java
src/org/jgroups/auth/SimpleToken.java
src/org/jgroups/auth/X509Token.java
{panel}
                
      was (Author: belaban):
    The following classes below still need to be converted, excluding
- classes that are not officially supported (STOMP, PRIO)
- classes that are not used anymore (e.g. NAKACK, NakReceiverWindow, Retransmitter, DefaultRetransmitter, RangeBasedRetransmitter etc)
- test code (StateTransferTest)
- demos (Whiteboard, GraphPanel, Draw, QuoteServer)

{panel}
-src/org/jgroups/stack/Configurator.java-
-src/org/jgroups/conf/XmlConfigurator.java-
-src/org/jgroups/conf/PropertyHelper.java-
-src/org/jgroups/conf/ProtocolConfiguration.java-
-src/org/jgroups/conf/ClassConfigurator.java-
src/org/jgroups/protocols/FILE_PING.java
src/org/jgroups/protocols/FD_SOCK.java
src/org/jgroups/protocols/RSVP.java
src/org/jgroups/protocols/UDP.java
src/org/jgroups/protocols/FD_PING.java
src/org/jgroups/protocols/COMPRESS.java
src/org/jgroups/protocols/VERIFY_SUSPECT.java
src/org/jgroups/protocols/MFC.java
src/org/jgroups/protocols/MERGE3.java
src/org/jgroups/protocols/FRAG2.java
src/org/jgroups/protocols/FlowControl.java
src/org/jgroups/protocols/ENCRYPT.java
src/org/jgroups/protocols/FORWARD_TO_COORD.java
src/org/jgroups/protocols/S3_PING.java
src/org/jgroups/protocols/FD.java
-src/org/jgroups/protocols/UNICAST3.java-
src/org/jgroups/protocols/Discovery.java
src/org/jgroups/protocols/JDBC_PING.java
src/org/jgroups/protocols/TCP.java
src/org/jgroups/protocols/UFC.java
src/org/jgroups/protocols/SEQUENCER.java
src/org/jgroups/protocols/AUTH.java
src/org/jgroups/protocols/TP.java
src/org/jgroups/protocols/TCPGOSSIP.java
src/org/jgroups/protocols/MPING.java
src/org/jgroups/protocols/pbcast/GMS.java
src/org/jgroups/protocols/pbcast/GmsImpl.java
src/org/jgroups/protocols/pbcast/STATE_TRANSFER.java
src/org/jgroups/protocols/pbcast/ClientGmsImpl.java
src/org/jgroups/protocols/pbcast/StreamingStateTransfer.java
src/org/jgroups/protocols/pbcast/Merger.java
src/org/jgroups/protocols/pbcast/CoordGmsImpl.java
src/org/jgroups/protocols/pbcast/STABLE.java
src/org/jgroups/protocols/pbcast/FLUSH.java
src/org/jgroups/protocols/pbcast/STATE_SOCK.java
-src/org/jgroups/protocols/pbcast/NAKACK2.java-
src/org/jgroups/protocols/relay/RELAY2.java
src/org/jgroups/protocols/relay/Relayer.java
src/org/jgroups/protocols/tom/TOA.java
src/org/jgroups/util/TimeScheduler2.java
src/org/jgroups/util/Util.java
src/org/jgroups/util/ForwardQueue.java
src/org/jgroups/util/Queue.java
src/org/jgroups/jmx/ResourceDMBean.java
src/org/jgroups/jmx/JmxConfigurator.java
src/org/jgroups/blocks/RequestCorrelator.java
src/org/jgroups/blocks/GroupRequest.java
src/org/jgroups/blocks/TCPConnectionMap.java
src/org/jgroups/blocks/Request.java
src/org/jgroups/blocks/RpcDispatcher.java
src/org/jgroups/blocks/MethodCall.java
src/org/jgroups/blocks/MessageDispatcher.java
src/org/jgroups/auth/MD5Token.java
src/org/jgroups/auth/FixedMembershipToken.java
src/org/jgroups/auth/SimpleToken.java
src/org/jgroups/auth/X509Token.java
{panel}
                  
> Logging: convert the most important WARN and ERROR messages to use IDs and resource bundles
> -------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1709
>                 URL: https://issues.jboss.org/browse/JGRP-1709
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.4
>
>
> Convert WARN and ERROR messages that might be seen by users to use a resource bundle (conf/jg-messages*.properties) and assign unique IDs the those messages.
> Link in BZ: https://bugzilla.redhat.com/show_bug.cgi?id=999671

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 09:13:02 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Fri, 4 Oct 2013 09:13:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2218) Subsystem transformers
	against 7.2.0
In-Reply-To: <JIRA.12502213.1380892269037@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502213.1380892269037@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502213.1380892269037.13864.1380892382647@jira02.app.mwc.hst.phx2.redhat.com>

Kabir Khan created WFLY-2218:
--------------------------------

             Summary: Subsystem transformers against 7.2.0
                 Key: WFLY-2218
                 URL: https://issues.jboss.org/browse/WFLY-2218
             Project: WildFly
          Issue Type: Feature Request
          Components: Domain Management
    Affects Versions: 8.0.0.CR1
            Reporter: Kabir Khan
            Assignee: Brian Stansberry




We have not tested the majority of subsystem transformers against AS 7.2.0. I have attempted to document why we need subsystem transformation here, and also how to use the framework: https://docs.jboss.org/author/display/WFLY8/Domain+Mode+Subsystem+https://docs.jboss.org/author/display/WFLY8/Domain+Mode+Subsystem+Transformers. This document is WIP, and I will be updating it a bit more over the next few days.

https://gist.github.com/kabir/6825607 contains the difference of a running WildFly instance against AS 7.2.0 in domain mode (for subsystems you don't really need to bother about this one)

https://gist.github.com/kabir/6825559 contains the difference of a running WildFly instance against AS 7.2.0 in standalone mode, here you can see what has changed in the subsystems.

When creating a new subsystem transformers test against 7.2.0, you will need the resource definition for the ModelVersion your subsystem uses in 7.2.0. If this is not found, you need to add a test to your subsystem, which you can delete once you have the .dmr file containing the resource defintion. Here is what I did to generate the file for JMX
{code}
    @Test
    public void deleteMeWhenDone() throws Exception {
        ModelTestControllerVersion controllerVersion = ModelTestControllerVersion.V7_2_0_FINAL;
        ModelVersion modelVersion = ModelVersion.create(1, 1, 0); //Whatever version of your subsystem 7.2.0.Final has
        KernelServicesBuilder builder = createKernelServicesBuilder(null);

        builder.createLegacyKernelServicesBuilder(null, controllerVersion, modelVersion)
            .addMavenResourceURL("org.jboss.as:jboss-as-jmx:" + controllerVersion.getMavenGavVersion());
        KernelServices services = builder.build();

        generateLegacySubsystemResourceRegistrationDmr(services, modelVersion);
    }
{code}
Now run the test and delete it. The legacy .dmr file should be in {{target/test-classes/org/jboss/as/subsystem/test/<your-subsystem-name>-<your-version>.dmr}}. Copy this .dmr file to {{subsystem-test/framework/src/main/resources/org/jboss/as/subsystem/test}}.

You will likely also need to update org.jboss.as.subsystem.test.KnownVersions to include your latest subsystem version, once you start doing real testing.

Bear in mind that if you need to add some transformation to 7.2.0 due to some new feature in WildFly 8, you will probably also need to add the same transformation to 7.1.x as well!


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 09:13:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Oct 2013 09:13:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-283) SegmentMemory staged
 LeftTuples not always accessed correctly
In-Reply-To: <JIRA.12502137.1380816662000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502137.1380816662000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502137.1380816662000.13868.1380892382923@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809446#comment-12809446 ] 

RH Bugzilla Integration commented on DROOLS-283:
------------------------------------------------

Edson Tirelli <etirelli at redhat.com> changed the Status of [bug 1015208|https://bugzilla.redhat.com/show_bug.cgi?id=1015208] from NEW to ASSIGNED
                
> SegmentMemory staged LeftTuples not always accessed correctly
> -------------------------------------------------------------
>
>                 Key: DROOLS-283
>                 URL: https://issues.jboss.org/browse/DROOLS-283
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>            Assignee: Mark Proctor
>             Fix For: 6.0.0.CR5
>
>
> Some times it accesses the current staging list, instead of the one in the segment memory.
> The NotNode should use the passed staging list, and not retrieve it directly.
> They should always use takeAll, to ensure they are thread safe.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 09:17:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 4 Oct 2013 09:17:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1709) Logging: convert the most
 important WARN and ERROR messages to use IDs and resource bundles
In-Reply-To: <JIRA.12501808.1380533726000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501808.1380533726000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501808.1380533726000.13875.1380892622633@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808947#comment-12808947 ] 

Bela Ban edited comment on JGRP-1709 at 10/4/13 9:15 AM:
---------------------------------------------------------

The following classes below still need to be converted, excluding
- classes that are not officially supported (STOMP, PRIO)
- classes that are not used anymore (e.g. NAKACK, NakReceiverWindow, Retransmitter, DefaultRetransmitter, RangeBasedRetransmitter etc)
- test code (StateTransferTest)
- demos (Whiteboard, GraphPanel, Draw, QuoteServer)

{panel}
-src/org/jgroups/stack/Configurator.java-
-src/org/jgroups/conf/XmlConfigurator.java-
-src/org/jgroups/conf/PropertyHelper.java-
-src/org/jgroups/conf/ProtocolConfiguration.java-
-src/org/jgroups/conf/ClassConfigurator.java-
src/org/jgroups/protocols/FILE_PING.java
src/org/jgroups/protocols/FD_SOCK.java
src/org/jgroups/protocols/RSVP.java
-src/org/jgroups/protocols/UDP.java-
src/org/jgroups/protocols/FD_PING.java
src/org/jgroups/protocols/COMPRESS.java
src/org/jgroups/protocols/VERIFY_SUSPECT.java
src/org/jgroups/protocols/MFC.java
src/org/jgroups/protocols/MERGE3.java
src/org/jgroups/protocols/FRAG2.java
src/org/jgroups/protocols/FlowControl.java
src/org/jgroups/protocols/ENCRYPT.java
src/org/jgroups/protocols/FORWARD_TO_COORD.java
src/org/jgroups/protocols/S3_PING.java
src/org/jgroups/protocols/FD.java
-src/org/jgroups/protocols/UNICAST3.java-
src/org/jgroups/protocols/Discovery.java
src/org/jgroups/protocols/JDBC_PING.java
src/org/jgroups/protocols/TCP.java
src/org/jgroups/protocols/UFC.java
src/org/jgroups/protocols/SEQUENCER.java
src/org/jgroups/protocols/AUTH.java
-src/org/jgroups/protocols/TP.java-
src/org/jgroups/protocols/TCPGOSSIP.java
src/org/jgroups/protocols/MPING.java
src/org/jgroups/protocols/pbcast/GMS.java
src/org/jgroups/protocols/pbcast/GmsImpl.java
src/org/jgroups/protocols/pbcast/STATE_TRANSFER.java
src/org/jgroups/protocols/pbcast/ClientGmsImpl.java
src/org/jgroups/protocols/pbcast/StreamingStateTransfer.java
src/org/jgroups/protocols/pbcast/Merger.java
src/org/jgroups/protocols/pbcast/CoordGmsImpl.java
src/org/jgroups/protocols/pbcast/STABLE.java
src/org/jgroups/protocols/pbcast/FLUSH.java
src/org/jgroups/protocols/pbcast/STATE_SOCK.java
-src/org/jgroups/protocols/pbcast/NAKACK2.java-
src/org/jgroups/protocols/relay/RELAY2.java
src/org/jgroups/protocols/relay/Relayer.java
src/org/jgroups/protocols/tom/TOA.java
src/org/jgroups/util/TimeScheduler2.java
src/org/jgroups/util/Util.java
src/org/jgroups/util/ForwardQueue.java
src/org/jgroups/util/Queue.java
src/org/jgroups/jmx/ResourceDMBean.java
src/org/jgroups/jmx/JmxConfigurator.java
src/org/jgroups/blocks/RequestCorrelator.java
src/org/jgroups/blocks/GroupRequest.java
src/org/jgroups/blocks/TCPConnectionMap.java
src/org/jgroups/blocks/Request.java
src/org/jgroups/blocks/RpcDispatcher.java
src/org/jgroups/blocks/MethodCall.java
src/org/jgroups/blocks/MessageDispatcher.java
src/org/jgroups/auth/MD5Token.java
src/org/jgroups/auth/FixedMembershipToken.java
src/org/jgroups/auth/SimpleToken.java
src/org/jgroups/auth/X509Token.java
{panel}
                
      was (Author: belaban):
    The following classes below still need to be converted, excluding
- classes that are not officially supported (STOMP, PRIO)
- classes that are not used anymore (e.g. NAKACK, NakReceiverWindow, Retransmitter, DefaultRetransmitter, RangeBasedRetransmitter etc)
- test code (StateTransferTest)
- demos (Whiteboard, GraphPanel, Draw, QuoteServer)

{panel}
-src/org/jgroups/stack/Configurator.java-
-src/org/jgroups/conf/XmlConfigurator.java-
-src/org/jgroups/conf/PropertyHelper.java-
-src/org/jgroups/conf/ProtocolConfiguration.java-
-src/org/jgroups/conf/ClassConfigurator.java-
src/org/jgroups/protocols/FILE_PING.java
src/org/jgroups/protocols/FD_SOCK.java
src/org/jgroups/protocols/RSVP.java
src/org/jgroups/protocols/UDP.java
src/org/jgroups/protocols/FD_PING.java
src/org/jgroups/protocols/COMPRESS.java
src/org/jgroups/protocols/VERIFY_SUSPECT.java
src/org/jgroups/protocols/MFC.java
src/org/jgroups/protocols/MERGE3.java
src/org/jgroups/protocols/FRAG2.java
src/org/jgroups/protocols/FlowControl.java
src/org/jgroups/protocols/ENCRYPT.java
src/org/jgroups/protocols/FORWARD_TO_COORD.java
src/org/jgroups/protocols/S3_PING.java
src/org/jgroups/protocols/FD.java
-src/org/jgroups/protocols/UNICAST3.java-
src/org/jgroups/protocols/Discovery.java
src/org/jgroups/protocols/JDBC_PING.java
src/org/jgroups/protocols/TCP.java
src/org/jgroups/protocols/UFC.java
src/org/jgroups/protocols/SEQUENCER.java
src/org/jgroups/protocols/AUTH.java
-src/org/jgroups/protocols/TP.java-
src/org/jgroups/protocols/TCPGOSSIP.java
src/org/jgroups/protocols/MPING.java
src/org/jgroups/protocols/pbcast/GMS.java
src/org/jgroups/protocols/pbcast/GmsImpl.java
src/org/jgroups/protocols/pbcast/STATE_TRANSFER.java
src/org/jgroups/protocols/pbcast/ClientGmsImpl.java
src/org/jgroups/protocols/pbcast/StreamingStateTransfer.java
src/org/jgroups/protocols/pbcast/Merger.java
src/org/jgroups/protocols/pbcast/CoordGmsImpl.java
src/org/jgroups/protocols/pbcast/STABLE.java
src/org/jgroups/protocols/pbcast/FLUSH.java
src/org/jgroups/protocols/pbcast/STATE_SOCK.java
-src/org/jgroups/protocols/pbcast/NAKACK2.java-
src/org/jgroups/protocols/relay/RELAY2.java
src/org/jgroups/protocols/relay/Relayer.java
src/org/jgroups/protocols/tom/TOA.java
src/org/jgroups/util/TimeScheduler2.java
src/org/jgroups/util/Util.java
src/org/jgroups/util/ForwardQueue.java
src/org/jgroups/util/Queue.java
src/org/jgroups/jmx/ResourceDMBean.java
src/org/jgroups/jmx/JmxConfigurator.java
src/org/jgroups/blocks/RequestCorrelator.java
src/org/jgroups/blocks/GroupRequest.java
src/org/jgroups/blocks/TCPConnectionMap.java
src/org/jgroups/blocks/Request.java
src/org/jgroups/blocks/RpcDispatcher.java
src/org/jgroups/blocks/MethodCall.java
src/org/jgroups/blocks/MessageDispatcher.java
src/org/jgroups/auth/MD5Token.java
src/org/jgroups/auth/FixedMembershipToken.java
src/org/jgroups/auth/SimpleToken.java
src/org/jgroups/auth/X509Token.java
{panel}
                  
> Logging: convert the most important WARN and ERROR messages to use IDs and resource bundles
> -------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1709
>                 URL: https://issues.jboss.org/browse/JGRP-1709
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.4
>
>
> Convert WARN and ERROR messages that might be seen by users to use a resource bundle (conf/jg-messages*.properties) and assign unique IDs the those messages.
> Link in BZ: https://bugzilla.redhat.com/show_bug.cgi?id=999671

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 09:21:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 4 Oct 2013 09:21:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1709) Logging: convert the most
 important WARN and ERROR messages to use IDs and resource bundles
In-Reply-To: <JIRA.12501808.1380533726000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501808.1380533726000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501808.1380533726000.13882.1380892862611@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808947#comment-12808947 ] 

Bela Ban edited comment on JGRP-1709 at 10/4/13 9:19 AM:
---------------------------------------------------------

The following classes below still need to be converted, excluding
- classes that are not officially supported (STOMP, PRIO)
- classes that are not used anymore (e.g. NAKACK, NakReceiverWindow, Retransmitter, DefaultRetransmitter, RangeBasedRetransmitter etc)
- test code (StateTransferTest)
- demos (Whiteboard, GraphPanel, Draw, QuoteServer)

{panel}
-src/org/jgroups/stack/Configurator.java-
-src/org/jgroups/conf/XmlConfigurator.java-
-src/org/jgroups/conf/PropertyHelper.java-
-src/org/jgroups/conf/ProtocolConfiguration.java-
-src/org/jgroups/conf/ClassConfigurator.java-
src/org/jgroups/protocols/FILE_PING.java
src/org/jgroups/protocols/FD_SOCK.java
src/org/jgroups/protocols/RSVP.java
-src/org/jgroups/protocols/UDP.java-
src/org/jgroups/protocols/FD_PING.java
-src/org/jgroups/protocols/COMPRESS.java-
src/org/jgroups/protocols/VERIFY_SUSPECT.java
src/org/jgroups/protocols/MFC.java
src/org/jgroups/protocols/MERGE3.java
src/org/jgroups/protocols/FRAG2.java
src/org/jgroups/protocols/FlowControl.java
src/org/jgroups/protocols/ENCRYPT.java
src/org/jgroups/protocols/FORWARD_TO_COORD.java
src/org/jgroups/protocols/S3_PING.java
src/org/jgroups/protocols/FD.java
-src/org/jgroups/protocols/UNICAST3.java-
src/org/jgroups/protocols/Discovery.java
src/org/jgroups/protocols/JDBC_PING.java
src/org/jgroups/protocols/TCP.java
src/org/jgroups/protocols/UFC.java
src/org/jgroups/protocols/SEQUENCER.java
src/org/jgroups/protocols/AUTH.java
-src/org/jgroups/protocols/TP.java-
src/org/jgroups/protocols/TCPGOSSIP.java
src/org/jgroups/protocols/MPING.java
src/org/jgroups/protocols/pbcast/GMS.java
src/org/jgroups/protocols/pbcast/GmsImpl.java
src/org/jgroups/protocols/pbcast/STATE_TRANSFER.java
src/org/jgroups/protocols/pbcast/ClientGmsImpl.java
src/org/jgroups/protocols/pbcast/StreamingStateTransfer.java
src/org/jgroups/protocols/pbcast/Merger.java
src/org/jgroups/protocols/pbcast/CoordGmsImpl.java
src/org/jgroups/protocols/pbcast/STABLE.java
src/org/jgroups/protocols/pbcast/FLUSH.java
src/org/jgroups/protocols/pbcast/STATE_SOCK.java
-src/org/jgroups/protocols/pbcast/NAKACK2.java-
src/org/jgroups/protocols/relay/RELAY2.java
src/org/jgroups/protocols/relay/Relayer.java
src/org/jgroups/protocols/tom/TOA.java
src/org/jgroups/util/TimeScheduler2.java
src/org/jgroups/util/Util.java
src/org/jgroups/util/ForwardQueue.java
src/org/jgroups/util/Queue.java
src/org/jgroups/jmx/ResourceDMBean.java
src/org/jgroups/jmx/JmxConfigurator.java
src/org/jgroups/blocks/RequestCorrelator.java
src/org/jgroups/blocks/GroupRequest.java
src/org/jgroups/blocks/TCPConnectionMap.java
src/org/jgroups/blocks/Request.java
src/org/jgroups/blocks/RpcDispatcher.java
src/org/jgroups/blocks/MethodCall.java
src/org/jgroups/blocks/MessageDispatcher.java
src/org/jgroups/auth/MD5Token.java
src/org/jgroups/auth/FixedMembershipToken.java
src/org/jgroups/auth/SimpleToken.java
src/org/jgroups/auth/X509Token.java
{panel}
                
      was (Author: belaban):
    The following classes below still need to be converted, excluding
- classes that are not officially supported (STOMP, PRIO)
- classes that are not used anymore (e.g. NAKACK, NakReceiverWindow, Retransmitter, DefaultRetransmitter, RangeBasedRetransmitter etc)
- test code (StateTransferTest)
- demos (Whiteboard, GraphPanel, Draw, QuoteServer)

{panel}
-src/org/jgroups/stack/Configurator.java-
-src/org/jgroups/conf/XmlConfigurator.java-
-src/org/jgroups/conf/PropertyHelper.java-
-src/org/jgroups/conf/ProtocolConfiguration.java-
-src/org/jgroups/conf/ClassConfigurator.java-
src/org/jgroups/protocols/FILE_PING.java
src/org/jgroups/protocols/FD_SOCK.java
src/org/jgroups/protocols/RSVP.java
-src/org/jgroups/protocols/UDP.java-
src/org/jgroups/protocols/FD_PING.java
src/org/jgroups/protocols/COMPRESS.java
src/org/jgroups/protocols/VERIFY_SUSPECT.java
src/org/jgroups/protocols/MFC.java
src/org/jgroups/protocols/MERGE3.java
src/org/jgroups/protocols/FRAG2.java
src/org/jgroups/protocols/FlowControl.java
src/org/jgroups/protocols/ENCRYPT.java
src/org/jgroups/protocols/FORWARD_TO_COORD.java
src/org/jgroups/protocols/S3_PING.java
src/org/jgroups/protocols/FD.java
-src/org/jgroups/protocols/UNICAST3.java-
src/org/jgroups/protocols/Discovery.java
src/org/jgroups/protocols/JDBC_PING.java
src/org/jgroups/protocols/TCP.java
src/org/jgroups/protocols/UFC.java
src/org/jgroups/protocols/SEQUENCER.java
src/org/jgroups/protocols/AUTH.java
-src/org/jgroups/protocols/TP.java-
src/org/jgroups/protocols/TCPGOSSIP.java
src/org/jgroups/protocols/MPING.java
src/org/jgroups/protocols/pbcast/GMS.java
src/org/jgroups/protocols/pbcast/GmsImpl.java
src/org/jgroups/protocols/pbcast/STATE_TRANSFER.java
src/org/jgroups/protocols/pbcast/ClientGmsImpl.java
src/org/jgroups/protocols/pbcast/StreamingStateTransfer.java
src/org/jgroups/protocols/pbcast/Merger.java
src/org/jgroups/protocols/pbcast/CoordGmsImpl.java
src/org/jgroups/protocols/pbcast/STABLE.java
src/org/jgroups/protocols/pbcast/FLUSH.java
src/org/jgroups/protocols/pbcast/STATE_SOCK.java
-src/org/jgroups/protocols/pbcast/NAKACK2.java-
src/org/jgroups/protocols/relay/RELAY2.java
src/org/jgroups/protocols/relay/Relayer.java
src/org/jgroups/protocols/tom/TOA.java
src/org/jgroups/util/TimeScheduler2.java
src/org/jgroups/util/Util.java
src/org/jgroups/util/ForwardQueue.java
src/org/jgroups/util/Queue.java
src/org/jgroups/jmx/ResourceDMBean.java
src/org/jgroups/jmx/JmxConfigurator.java
src/org/jgroups/blocks/RequestCorrelator.java
src/org/jgroups/blocks/GroupRequest.java
src/org/jgroups/blocks/TCPConnectionMap.java
src/org/jgroups/blocks/Request.java
src/org/jgroups/blocks/RpcDispatcher.java
src/org/jgroups/blocks/MethodCall.java
src/org/jgroups/blocks/MessageDispatcher.java
src/org/jgroups/auth/MD5Token.java
src/org/jgroups/auth/FixedMembershipToken.java
src/org/jgroups/auth/SimpleToken.java
src/org/jgroups/auth/X509Token.java
{panel}
                  
> Logging: convert the most important WARN and ERROR messages to use IDs and resource bundles
> -------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1709
>                 URL: https://issues.jboss.org/browse/JGRP-1709
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.4
>
>
> Convert WARN and ERROR messages that might be seen by users to use a resource bundle (conf/jg-messages*.properties) and assign unique IDs the those messages.
> Link in BZ: https://bugzilla.redhat.com/show_bug.cgi?id=999671

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 09:25:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 4 Oct 2013 09:25:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1709) Logging: convert the most
 important WARN and ERROR messages to use IDs and resource bundles
In-Reply-To: <JIRA.12501808.1380533726000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501808.1380533726000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501808.1380533726000.13897.1380893102733@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808947#comment-12808947 ] 

Bela Ban edited comment on JGRP-1709 at 10/4/13 9:23 AM:
---------------------------------------------------------

The following classes below still need to be converted, excluding
- classes that are not officially supported (STOMP, PRIO)
- classes that are not used anymore (e.g. NAKACK, NakReceiverWindow, Retransmitter, DefaultRetransmitter, RangeBasedRetransmitter etc)
- test code (StateTransferTest)
- demos (Whiteboard, GraphPanel, Draw, QuoteServer)

{panel}
-src/org/jgroups/stack/Configurator.java-
-src/org/jgroups/conf/XmlConfigurator.java-
-src/org/jgroups/conf/PropertyHelper.java-
-src/org/jgroups/conf/ProtocolConfiguration.java-
-src/org/jgroups/conf/ClassConfigurator.java-
src/org/jgroups/protocols/FILE_PING.java
src/org/jgroups/protocols/FD_SOCK.java
-src/org/jgroups/protocols/RSVP.java-
-src/org/jgroups/protocols/UDP.java-
src/org/jgroups/protocols/FD_PING.java
-src/org/jgroups/protocols/COMPRESS.java-
src/org/jgroups/protocols/VERIFY_SUSPECT.java
src/org/jgroups/protocols/MFC.java
src/org/jgroups/protocols/MERGE3.java
src/org/jgroups/protocols/FRAG2.java
src/org/jgroups/protocols/FlowControl.java
src/org/jgroups/protocols/ENCRYPT.java
src/org/jgroups/protocols/FORWARD_TO_COORD.java
src/org/jgroups/protocols/S3_PING.java
src/org/jgroups/protocols/FD.java
-src/org/jgroups/protocols/UNICAST3.java-
src/org/jgroups/protocols/Discovery.java
src/org/jgroups/protocols/JDBC_PING.java
src/org/jgroups/protocols/TCP.java
src/org/jgroups/protocols/UFC.java
src/org/jgroups/protocols/SEQUENCER.java
src/org/jgroups/protocols/AUTH.java
-src/org/jgroups/protocols/TP.java-
src/org/jgroups/protocols/TCPGOSSIP.java
src/org/jgroups/protocols/MPING.java
src/org/jgroups/protocols/pbcast/GMS.java
src/org/jgroups/protocols/pbcast/GmsImpl.java
src/org/jgroups/protocols/pbcast/STATE_TRANSFER.java
src/org/jgroups/protocols/pbcast/ClientGmsImpl.java
src/org/jgroups/protocols/pbcast/StreamingStateTransfer.java
src/org/jgroups/protocols/pbcast/Merger.java
src/org/jgroups/protocols/pbcast/CoordGmsImpl.java
src/org/jgroups/protocols/pbcast/STABLE.java
src/org/jgroups/protocols/pbcast/FLUSH.java
src/org/jgroups/protocols/pbcast/STATE_SOCK.java
-src/org/jgroups/protocols/pbcast/NAKACK2.java-
src/org/jgroups/protocols/relay/RELAY2.java
src/org/jgroups/protocols/relay/Relayer.java
src/org/jgroups/protocols/tom/TOA.java
src/org/jgroups/util/TimeScheduler2.java
src/org/jgroups/util/Util.java
src/org/jgroups/util/ForwardQueue.java
src/org/jgroups/util/Queue.java
src/org/jgroups/jmx/ResourceDMBean.java
src/org/jgroups/jmx/JmxConfigurator.java
src/org/jgroups/blocks/RequestCorrelator.java
src/org/jgroups/blocks/GroupRequest.java
src/org/jgroups/blocks/TCPConnectionMap.java
src/org/jgroups/blocks/Request.java
src/org/jgroups/blocks/RpcDispatcher.java
src/org/jgroups/blocks/MethodCall.java
src/org/jgroups/blocks/MessageDispatcher.java
src/org/jgroups/auth/MD5Token.java
src/org/jgroups/auth/FixedMembershipToken.java
src/org/jgroups/auth/SimpleToken.java
src/org/jgroups/auth/X509Token.java
{panel}
                
      was (Author: belaban):
    The following classes below still need to be converted, excluding
- classes that are not officially supported (STOMP, PRIO)
- classes that are not used anymore (e.g. NAKACK, NakReceiverWindow, Retransmitter, DefaultRetransmitter, RangeBasedRetransmitter etc)
- test code (StateTransferTest)
- demos (Whiteboard, GraphPanel, Draw, QuoteServer)

{panel}
-src/org/jgroups/stack/Configurator.java-
-src/org/jgroups/conf/XmlConfigurator.java-
-src/org/jgroups/conf/PropertyHelper.java-
-src/org/jgroups/conf/ProtocolConfiguration.java-
-src/org/jgroups/conf/ClassConfigurator.java-
src/org/jgroups/protocols/FILE_PING.java
src/org/jgroups/protocols/FD_SOCK.java
src/org/jgroups/protocols/RSVP.java
-src/org/jgroups/protocols/UDP.java-
src/org/jgroups/protocols/FD_PING.java
-src/org/jgroups/protocols/COMPRESS.java-
src/org/jgroups/protocols/VERIFY_SUSPECT.java
src/org/jgroups/protocols/MFC.java
src/org/jgroups/protocols/MERGE3.java
src/org/jgroups/protocols/FRAG2.java
src/org/jgroups/protocols/FlowControl.java
src/org/jgroups/protocols/ENCRYPT.java
src/org/jgroups/protocols/FORWARD_TO_COORD.java
src/org/jgroups/protocols/S3_PING.java
src/org/jgroups/protocols/FD.java
-src/org/jgroups/protocols/UNICAST3.java-
src/org/jgroups/protocols/Discovery.java
src/org/jgroups/protocols/JDBC_PING.java
src/org/jgroups/protocols/TCP.java
src/org/jgroups/protocols/UFC.java
src/org/jgroups/protocols/SEQUENCER.java
src/org/jgroups/protocols/AUTH.java
-src/org/jgroups/protocols/TP.java-
src/org/jgroups/protocols/TCPGOSSIP.java
src/org/jgroups/protocols/MPING.java
src/org/jgroups/protocols/pbcast/GMS.java
src/org/jgroups/protocols/pbcast/GmsImpl.java
src/org/jgroups/protocols/pbcast/STATE_TRANSFER.java
src/org/jgroups/protocols/pbcast/ClientGmsImpl.java
src/org/jgroups/protocols/pbcast/StreamingStateTransfer.java
src/org/jgroups/protocols/pbcast/Merger.java
src/org/jgroups/protocols/pbcast/CoordGmsImpl.java
src/org/jgroups/protocols/pbcast/STABLE.java
src/org/jgroups/protocols/pbcast/FLUSH.java
src/org/jgroups/protocols/pbcast/STATE_SOCK.java
-src/org/jgroups/protocols/pbcast/NAKACK2.java-
src/org/jgroups/protocols/relay/RELAY2.java
src/org/jgroups/protocols/relay/Relayer.java
src/org/jgroups/protocols/tom/TOA.java
src/org/jgroups/util/TimeScheduler2.java
src/org/jgroups/util/Util.java
src/org/jgroups/util/ForwardQueue.java
src/org/jgroups/util/Queue.java
src/org/jgroups/jmx/ResourceDMBean.java
src/org/jgroups/jmx/JmxConfigurator.java
src/org/jgroups/blocks/RequestCorrelator.java
src/org/jgroups/blocks/GroupRequest.java
src/org/jgroups/blocks/TCPConnectionMap.java
src/org/jgroups/blocks/Request.java
src/org/jgroups/blocks/RpcDispatcher.java
src/org/jgroups/blocks/MethodCall.java
src/org/jgroups/blocks/MessageDispatcher.java
src/org/jgroups/auth/MD5Token.java
src/org/jgroups/auth/FixedMembershipToken.java
src/org/jgroups/auth/SimpleToken.java
src/org/jgroups/auth/X509Token.java
{panel}
                  
> Logging: convert the most important WARN and ERROR messages to use IDs and resource bundles
> -------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1709
>                 URL: https://issues.jboss.org/browse/JGRP-1709
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.4
>
>
> Convert WARN and ERROR messages that might be seen by users to use a resource bundle (conf/jg-messages*.properties) and assign unique IDs the those messages.
> Link in BZ: https://bugzilla.redhat.com/show_bug.cgi?id=999671

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 09:25:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 4 Oct 2013 09:25:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1709) Logging: convert the most
 important WARN and ERROR messages to use IDs and resource bundles
In-Reply-To: <JIRA.12501808.1380533726000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501808.1380533726000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501808.1380533726000.13907.1380893103328@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808947#comment-12808947 ] 

Bela Ban edited comment on JGRP-1709 at 10/4/13 9:24 AM:
---------------------------------------------------------

The following classes below still need to be converted, excluding
- classes that are not officially supported (STOMP, PRIO)
- classes that are not used anymore (e.g. NAKACK, NakReceiverWindow, Retransmitter, DefaultRetransmitter, RangeBasedRetransmitter etc)
- test code (StateTransferTest)
- demos (Whiteboard, GraphPanel, Draw, QuoteServer)

{panel}
-src/org/jgroups/stack/Configurator.java-
-src/org/jgroups/conf/XmlConfigurator.java-
-src/org/jgroups/conf/PropertyHelper.java-
-src/org/jgroups/conf/ProtocolConfiguration.java-
-src/org/jgroups/conf/ClassConfigurator.java-
src/org/jgroups/protocols/FILE_PING.java
src/org/jgroups/protocols/FD_SOCK.java
-src/org/jgroups/protocols/RSVP.java-
-src/org/jgroups/protocols/UDP.java-
-src/org/jgroups/protocols/COMPRESS.java-
src/org/jgroups/protocols/VERIFY_SUSPECT.java
src/org/jgroups/protocols/MFC.java
src/org/jgroups/protocols/MERGE3.java
src/org/jgroups/protocols/FRAG2.java
src/org/jgroups/protocols/FlowControl.java
src/org/jgroups/protocols/ENCRYPT.java
src/org/jgroups/protocols/FORWARD_TO_COORD.java
src/org/jgroups/protocols/S3_PING.java
src/org/jgroups/protocols/FD.java
-src/org/jgroups/protocols/UNICAST3.java-
src/org/jgroups/protocols/Discovery.java
src/org/jgroups/protocols/JDBC_PING.java
src/org/jgroups/protocols/TCP.java
src/org/jgroups/protocols/UFC.java
src/org/jgroups/protocols/SEQUENCER.java
src/org/jgroups/protocols/AUTH.java
-src/org/jgroups/protocols/TP.java-
src/org/jgroups/protocols/TCPGOSSIP.java
src/org/jgroups/protocols/MPING.java
src/org/jgroups/protocols/pbcast/GMS.java
src/org/jgroups/protocols/pbcast/GmsImpl.java
src/org/jgroups/protocols/pbcast/STATE_TRANSFER.java
src/org/jgroups/protocols/pbcast/ClientGmsImpl.java
src/org/jgroups/protocols/pbcast/StreamingStateTransfer.java
src/org/jgroups/protocols/pbcast/Merger.java
src/org/jgroups/protocols/pbcast/CoordGmsImpl.java
src/org/jgroups/protocols/pbcast/STABLE.java
src/org/jgroups/protocols/pbcast/FLUSH.java
src/org/jgroups/protocols/pbcast/STATE_SOCK.java
-src/org/jgroups/protocols/pbcast/NAKACK2.java-
src/org/jgroups/protocols/relay/RELAY2.java
src/org/jgroups/protocols/relay/Relayer.java
src/org/jgroups/protocols/tom/TOA.java
src/org/jgroups/util/TimeScheduler2.java
src/org/jgroups/util/Util.java
src/org/jgroups/util/ForwardQueue.java
src/org/jgroups/util/Queue.java
src/org/jgroups/jmx/ResourceDMBean.java
src/org/jgroups/jmx/JmxConfigurator.java
src/org/jgroups/blocks/RequestCorrelator.java
src/org/jgroups/blocks/GroupRequest.java
src/org/jgroups/blocks/TCPConnectionMap.java
src/org/jgroups/blocks/Request.java
src/org/jgroups/blocks/RpcDispatcher.java
src/org/jgroups/blocks/MethodCall.java
src/org/jgroups/blocks/MessageDispatcher.java
src/org/jgroups/auth/MD5Token.java
src/org/jgroups/auth/FixedMembershipToken.java
src/org/jgroups/auth/SimpleToken.java
src/org/jgroups/auth/X509Token.java
{panel}
                
      was (Author: belaban):
    The following classes below still need to be converted, excluding
- classes that are not officially supported (STOMP, PRIO)
- classes that are not used anymore (e.g. NAKACK, NakReceiverWindow, Retransmitter, DefaultRetransmitter, RangeBasedRetransmitter etc)
- test code (StateTransferTest)
- demos (Whiteboard, GraphPanel, Draw, QuoteServer)

{panel}
-src/org/jgroups/stack/Configurator.java-
-src/org/jgroups/conf/XmlConfigurator.java-
-src/org/jgroups/conf/PropertyHelper.java-
-src/org/jgroups/conf/ProtocolConfiguration.java-
-src/org/jgroups/conf/ClassConfigurator.java-
src/org/jgroups/protocols/FILE_PING.java
src/org/jgroups/protocols/FD_SOCK.java
-src/org/jgroups/protocols/RSVP.java-
-src/org/jgroups/protocols/UDP.java-
src/org/jgroups/protocols/FD_PING.java
-src/org/jgroups/protocols/COMPRESS.java-
src/org/jgroups/protocols/VERIFY_SUSPECT.java
src/org/jgroups/protocols/MFC.java
src/org/jgroups/protocols/MERGE3.java
src/org/jgroups/protocols/FRAG2.java
src/org/jgroups/protocols/FlowControl.java
src/org/jgroups/protocols/ENCRYPT.java
src/org/jgroups/protocols/FORWARD_TO_COORD.java
src/org/jgroups/protocols/S3_PING.java
src/org/jgroups/protocols/FD.java
-src/org/jgroups/protocols/UNICAST3.java-
src/org/jgroups/protocols/Discovery.java
src/org/jgroups/protocols/JDBC_PING.java
src/org/jgroups/protocols/TCP.java
src/org/jgroups/protocols/UFC.java
src/org/jgroups/protocols/SEQUENCER.java
src/org/jgroups/protocols/AUTH.java
-src/org/jgroups/protocols/TP.java-
src/org/jgroups/protocols/TCPGOSSIP.java
src/org/jgroups/protocols/MPING.java
src/org/jgroups/protocols/pbcast/GMS.java
src/org/jgroups/protocols/pbcast/GmsImpl.java
src/org/jgroups/protocols/pbcast/STATE_TRANSFER.java
src/org/jgroups/protocols/pbcast/ClientGmsImpl.java
src/org/jgroups/protocols/pbcast/StreamingStateTransfer.java
src/org/jgroups/protocols/pbcast/Merger.java
src/org/jgroups/protocols/pbcast/CoordGmsImpl.java
src/org/jgroups/protocols/pbcast/STABLE.java
src/org/jgroups/protocols/pbcast/FLUSH.java
src/org/jgroups/protocols/pbcast/STATE_SOCK.java
-src/org/jgroups/protocols/pbcast/NAKACK2.java-
src/org/jgroups/protocols/relay/RELAY2.java
src/org/jgroups/protocols/relay/Relayer.java
src/org/jgroups/protocols/tom/TOA.java
src/org/jgroups/util/TimeScheduler2.java
src/org/jgroups/util/Util.java
src/org/jgroups/util/ForwardQueue.java
src/org/jgroups/util/Queue.java
src/org/jgroups/jmx/ResourceDMBean.java
src/org/jgroups/jmx/JmxConfigurator.java
src/org/jgroups/blocks/RequestCorrelator.java
src/org/jgroups/blocks/GroupRequest.java
src/org/jgroups/blocks/TCPConnectionMap.java
src/org/jgroups/blocks/Request.java
src/org/jgroups/blocks/RpcDispatcher.java
src/org/jgroups/blocks/MethodCall.java
src/org/jgroups/blocks/MessageDispatcher.java
src/org/jgroups/auth/MD5Token.java
src/org/jgroups/auth/FixedMembershipToken.java
src/org/jgroups/auth/SimpleToken.java
src/org/jgroups/auth/X509Token.java
{panel}
                  
> Logging: convert the most important WARN and ERROR messages to use IDs and resource bundles
> -------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1709
>                 URL: https://issues.jboss.org/browse/JGRP-1709
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.4
>
>
> Convert WARN and ERROR messages that might be seen by users to use a resource bundle (conf/jg-messages*.properties) and assign unique IDs the those messages.
> Link in BZ: https://bugzilla.redhat.com/show_bug.cgi?id=999671

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 09:29:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 4 Oct 2013 09:29:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1709) Logging: convert the most
 important WARN and ERROR messages to use IDs and resource bundles
In-Reply-To: <JIRA.12501808.1380533726000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501808.1380533726000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501808.1380533726000.13909.1380893342599@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808947#comment-12808947 ] 

Bela Ban edited comment on JGRP-1709 at 10/4/13 9:27 AM:
---------------------------------------------------------

The following classes below still need to be converted, excluding
- classes that are not officially supported (STOMP, PRIO)
- classes that are not used anymore (e.g. NAKACK, NakReceiverWindow, Retransmitter, DefaultRetransmitter, RangeBasedRetransmitter etc)
- test code (StateTransferTest)
- demos (Whiteboard, GraphPanel, Draw, QuoteServer)

{panel}
-src/org/jgroups/stack/Configurator.java-
-src/org/jgroups/conf/XmlConfigurator.java-
-src/org/jgroups/conf/PropertyHelper.java-
-src/org/jgroups/conf/ProtocolConfiguration.java-
-src/org/jgroups/conf/ClassConfigurator.java-
src/org/jgroups/protocols/FILE_PING.java
src/org/jgroups/protocols/FD_SOCK.java
-src/org/jgroups/protocols/RSVP.java-
-src/org/jgroups/protocols/UDP.java-
-src/org/jgroups/protocols/COMPRESS.java-
src/org/jgroups/protocols/VERIFY_SUSPECT.java
src/org/jgroups/protocols/MFC.java
src/org/jgroups/protocols/MERGE3.java
src/org/jgroups/protocols/FRAG2.java
src/org/jgroups/protocols/FlowControl.java
src/org/jgroups/protocols/ENCRYPT.java
src/org/jgroups/protocols/FORWARD_TO_COORD.java
src/org/jgroups/protocols/S3_PING.java
src/org/jgroups/protocols/FD.java
-src/org/jgroups/protocols/UNICAST3.java-
src/org/jgroups/protocols/Discovery.java
src/org/jgroups/protocols/JDBC_PING.java
src/org/jgroups/protocols/TCP.java
src/org/jgroups/protocols/UFC.java
src/org/jgroups/protocols/SEQUENCER.java
src/org/jgroups/protocols/AUTH.java
-src/org/jgroups/protocols/TP.java-
src/org/jgroups/protocols/TCPGOSSIP.java
src/org/jgroups/protocols/MPING.java
src/org/jgroups/protocols/pbcast/GMS.java
src/org/jgroups/protocols/pbcast/GmsImpl.java
src/org/jgroups/protocols/pbcast/STATE_TRANSFER.java
src/org/jgroups/protocols/pbcast/ClientGmsImpl.java
src/org/jgroups/protocols/pbcast/StreamingStateTransfer.java
src/org/jgroups/protocols/pbcast/Merger.java
src/org/jgroups/protocols/pbcast/CoordGmsImpl.java
src/org/jgroups/protocols/pbcast/STABLE.java
src/org/jgroups/protocols/pbcast/FLUSH.java
src/org/jgroups/protocols/pbcast/STATE_SOCK.java
-src/org/jgroups/protocols/pbcast/NAKACK2.java-
src/org/jgroups/protocols/relay/RELAY2.java
src/org/jgroups/protocols/relay/Relayer.java
src/org/jgroups/protocols/tom/TOA.java
src/org/jgroups/util/TimeScheduler2.java
src/org/jgroups/util/Util.java
src/org/jgroups/util/ForwardQueue.java
src/org/jgroups/util/Queue.java
src/org/jgroups/jmx/ResourceDMBean.java
src/org/jgroups/blocks/RequestCorrelator.java
src/org/jgroups/blocks/GroupRequest.java
src/org/jgroups/blocks/TCPConnectionMap.java
src/org/jgroups/blocks/Request.java
src/org/jgroups/blocks/RpcDispatcher.java
src/org/jgroups/blocks/MethodCall.java
src/org/jgroups/blocks/MessageDispatcher.java
src/org/jgroups/auth/MD5Token.java
src/org/jgroups/auth/FixedMembershipToken.java
src/org/jgroups/auth/SimpleToken.java
src/org/jgroups/auth/X509Token.java
{panel}
                
      was (Author: belaban):
    The following classes below still need to be converted, excluding
- classes that are not officially supported (STOMP, PRIO)
- classes that are not used anymore (e.g. NAKACK, NakReceiverWindow, Retransmitter, DefaultRetransmitter, RangeBasedRetransmitter etc)
- test code (StateTransferTest)
- demos (Whiteboard, GraphPanel, Draw, QuoteServer)

{panel}
-src/org/jgroups/stack/Configurator.java-
-src/org/jgroups/conf/XmlConfigurator.java-
-src/org/jgroups/conf/PropertyHelper.java-
-src/org/jgroups/conf/ProtocolConfiguration.java-
-src/org/jgroups/conf/ClassConfigurator.java-
src/org/jgroups/protocols/FILE_PING.java
src/org/jgroups/protocols/FD_SOCK.java
-src/org/jgroups/protocols/RSVP.java-
-src/org/jgroups/protocols/UDP.java-
-src/org/jgroups/protocols/COMPRESS.java-
src/org/jgroups/protocols/VERIFY_SUSPECT.java
src/org/jgroups/protocols/MFC.java
src/org/jgroups/protocols/MERGE3.java
src/org/jgroups/protocols/FRAG2.java
src/org/jgroups/protocols/FlowControl.java
src/org/jgroups/protocols/ENCRYPT.java
src/org/jgroups/protocols/FORWARD_TO_COORD.java
src/org/jgroups/protocols/S3_PING.java
src/org/jgroups/protocols/FD.java
-src/org/jgroups/protocols/UNICAST3.java-
src/org/jgroups/protocols/Discovery.java
src/org/jgroups/protocols/JDBC_PING.java
src/org/jgroups/protocols/TCP.java
src/org/jgroups/protocols/UFC.java
src/org/jgroups/protocols/SEQUENCER.java
src/org/jgroups/protocols/AUTH.java
-src/org/jgroups/protocols/TP.java-
src/org/jgroups/protocols/TCPGOSSIP.java
src/org/jgroups/protocols/MPING.java
src/org/jgroups/protocols/pbcast/GMS.java
src/org/jgroups/protocols/pbcast/GmsImpl.java
src/org/jgroups/protocols/pbcast/STATE_TRANSFER.java
src/org/jgroups/protocols/pbcast/ClientGmsImpl.java
src/org/jgroups/protocols/pbcast/StreamingStateTransfer.java
src/org/jgroups/protocols/pbcast/Merger.java
src/org/jgroups/protocols/pbcast/CoordGmsImpl.java
src/org/jgroups/protocols/pbcast/STABLE.java
src/org/jgroups/protocols/pbcast/FLUSH.java
src/org/jgroups/protocols/pbcast/STATE_SOCK.java
-src/org/jgroups/protocols/pbcast/NAKACK2.java-
src/org/jgroups/protocols/relay/RELAY2.java
src/org/jgroups/protocols/relay/Relayer.java
src/org/jgroups/protocols/tom/TOA.java
src/org/jgroups/util/TimeScheduler2.java
src/org/jgroups/util/Util.java
src/org/jgroups/util/ForwardQueue.java
src/org/jgroups/util/Queue.java
src/org/jgroups/jmx/ResourceDMBean.java
src/org/jgroups/jmx/JmxConfigurator.java
src/org/jgroups/blocks/RequestCorrelator.java
src/org/jgroups/blocks/GroupRequest.java
src/org/jgroups/blocks/TCPConnectionMap.java
src/org/jgroups/blocks/Request.java
src/org/jgroups/blocks/RpcDispatcher.java
src/org/jgroups/blocks/MethodCall.java
src/org/jgroups/blocks/MessageDispatcher.java
src/org/jgroups/auth/MD5Token.java
src/org/jgroups/auth/FixedMembershipToken.java
src/org/jgroups/auth/SimpleToken.java
src/org/jgroups/auth/X509Token.java
{panel}
                  
> Logging: convert the most important WARN and ERROR messages to use IDs and resource bundles
> -------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1709
>                 URL: https://issues.jboss.org/browse/JGRP-1709
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.4
>
>
> Convert WARN and ERROR messages that might be seen by users to use a resource bundle (conf/jg-messages*.properties) and assign unique IDs the those messages.
> Link in BZ: https://bugzilla.redhat.com/show_bug.cgi?id=999671

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 09:31:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 4 Oct 2013 09:31:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1709) Logging: convert the most
 important WARN and ERROR messages to use IDs and resource bundles
In-Reply-To: <JIRA.12501808.1380533726000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501808.1380533726000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501808.1380533726000.13913.1380893462634@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1709:
---------------------------

    Fix Version/s: 3.5
                       (was: 3.4)


Need to release 3.4, the rest is done in 3.5
                
> Logging: convert the most important WARN and ERROR messages to use IDs and resource bundles
> -------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1709
>                 URL: https://issues.jboss.org/browse/JGRP-1709
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.5
>
>
> Convert WARN and ERROR messages that might be seen by users to use a resource bundle (conf/jg-messages*.properties) and assign unique IDs the those messages.
> Link in BZ: https://bugzilla.redhat.com/show_bug.cgi?id=999671

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 09:31:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 4 Oct 2013 09:31:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2216) include-all role mappings
 don't work in domain
In-Reply-To: <JIRA.12502198.1380887272000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502198.1380887272000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502198.1380887272000.13916.1380893462937@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809456#comment-12809456 ] 

Darran Lofthouse commented on WFLY-2216:
----------------------------------------

Let me reproduce, once I can see what is happening I can better confirm which area this is in.
                
> include-all role mappings don't work in domain
> ----------------------------------------------
>
>                 Key: WFLY-2216
>                 URL: https://issues.jboss.org/browse/WFLY-2216
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Ladislav Thon
>            Assignee: Darran Lofthouse
>              Labels: rbac-filed-by-qa
>
> If I understand correctly, roles that have {{include-all=true}} in their role mappings should be added to all authenticated users. In my tests, though, this only works in standalone mode.
> In domain mode, if I set a role mapping to {{include-all}}, this setting is not reflected (at least not immediately; maybe it would work after restart, but that's wrong anyway). It doesn't matter which role is set to be {{include-all}} -- in my tests, I use both standard roles and scoped roles and it consistently doesn't work. There's probably some wrong caching going on.
> The failing test case is in my pull request https://github.com/wildfly/wildfly/pull/5166 (it's the _RBAC tests for include-all role mappings in domain_ commit). If it's more convenient, the pull request is the same as my _rbac_ branch (https://github.com/Ladicek/wildfly/commits/rbac).
> Darran, I'm not sure if you are the right assignee -- please reassign if needed. Thanks.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 09:35:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Fri, 4 Oct 2013 09:35:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-276) Stream mode with CR4-Pre1
 generates rules looping
In-Reply-To: <JIRA.12501742.1380290941000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501742.1380290941000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501742.1380290941000.13927.1380893702711@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-276:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
>  Stream mode with CR4-Pre1 generates rules looping
> --------------------------------------------------
>
>                 Key: DROOLS-276
>                 URL: https://issues.jboss.org/browse/DROOLS-276
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>         Environment: Drools 6.0.0.CR4-Pre1
>            Reporter: Richard Bourner
>            Assignee: Mario Fusco
>            Priority: Blocker
>         Attachments: Drools6Stream.zip
>
>
> When in STREAM mode, our rules are looping because of an update.
> The attached example doesn't demonstrate the looping but one rule is fired twice where it should only fire once. We are supposing that the issue is the same.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 09:39:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Oct 2013 09:39:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-276) Stream mode with CR4-Pre1
 generates rules looping
In-Reply-To: <JIRA.12501742.1380290941000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501742.1380290941000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501742.1380290941000.13932.1380893942636@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809460#comment-12809460 ] 

RH Bugzilla Integration commented on DROOLS-276:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> made a comment on [bug 1012933|https://bugzilla.redhat.com/show_bug.cgi?id=1012933]

Fixed by https://github.com/droolsjbpm/drools/commit/14387151e
                
>  Stream mode with CR4-Pre1 generates rules looping
> --------------------------------------------------
>
>                 Key: DROOLS-276
>                 URL: https://issues.jboss.org/browse/DROOLS-276
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>         Environment: Drools 6.0.0.CR4-Pre1
>            Reporter: Richard Bourner
>            Assignee: Mario Fusco
>            Priority: Blocker
>         Attachments: Drools6Stream.zip
>
>
> When in STREAM mode, our rules are looping because of an update.
> The attached example doesn't demonstrate the looping but one rule is fired twice where it should only fire once. We are supposing that the issue is the same.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 09:39:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Oct 2013 09:39:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-276) Stream mode with CR4-Pre1
 generates rules looping
In-Reply-To: <JIRA.12501742.1380290941000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501742.1380290941000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501742.1380290941000.13936.1380893942806@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809461#comment-12809461 ] 

RH Bugzilla Integration commented on DROOLS-276:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> changed the Status of [bug 1012933|https://bugzilla.redhat.com/show_bug.cgi?id=1012933] from ASSIGNED to MODIFIED
                
>  Stream mode with CR4-Pre1 generates rules looping
> --------------------------------------------------
>
>                 Key: DROOLS-276
>                 URL: https://issues.jboss.org/browse/DROOLS-276
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>         Environment: Drools 6.0.0.CR4-Pre1
>            Reporter: Richard Bourner
>            Assignee: Mario Fusco
>            Priority: Blocker
>         Attachments: Drools6Stream.zip
>
>
> When in STREAM mode, our rules are looping because of an update.
> The attached example doesn't demonstrate the looping but one rule is fired twice where it should only fire once. We are supposing that the issue is the same.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 09:39:03 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Fri, 4 Oct 2013 09:39:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-276) Stream mode with CR4-Pre1
 generates rules looping
In-Reply-To: <JIRA.12501742.1380290941000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501742.1380290941000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501742.1380290941000.13942.1380893943087@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-276.
--------------------------------

    Fix Version/s: 6.0.0.CR5
       Resolution: Done

    
>  Stream mode with CR4-Pre1 generates rules looping
> --------------------------------------------------
>
>                 Key: DROOLS-276
>                 URL: https://issues.jboss.org/browse/DROOLS-276
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>         Environment: Drools 6.0.0.CR4-Pre1
>            Reporter: Richard Bourner
>            Assignee: Mario Fusco
>            Priority: Blocker
>             Fix For: 6.0.0.CR5
>
>         Attachments: Drools6Stream.zip
>
>
> When in STREAM mode, our rules are looping because of an update.
> The attached example doesn't demonstrate the looping but one rule is fired twice where it should only fire once. We are supposing that the issue is the same.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 09:57:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Oct 2013 09:57:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2172) Resurrect the mixed domain
 testing and fix any problems
In-Reply-To: <JIRA.12501720.1380277458000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501720.1380277458000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501720.1380277458000.13995.1380895022644@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809469#comment-12809469 ] 

RH Bugzilla Integration commented on WFLY-2172:
-----------------------------------------------

Emanuel Muckenhuber <emuckenh at redhat.com> changed the Status of [bug 1015243|https://bugzilla.redhat.com/show_bug.cgi?id=1015243] from NEW to ASSIGNED
                
> Resurrect the mixed domain testing and fix any problems
> -------------------------------------------------------
>
>                 Key: WFLY-2172
>                 URL: https://issues.jboss.org/browse/WFLY-2172
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Brian Stansberry
>            Priority: Blocker
>             Fix For: 8.0.0.CR1
>
>
> THis has not been run for quite some time, and needs to be included in the general testing.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 09:59:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Oct 2013 09:59:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2185) Get core model test framework
 working with 7.2.0.Final legacy controller
In-Reply-To: <JIRA.12501848.1380553676000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501848.1380553676000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501848.1380553676000.14019.1380895143609@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809471#comment-12809471 ] 

RH Bugzilla Integration commented on WFLY-2185:
-----------------------------------------------

Emanuel Muckenhuber <emuckenh at redhat.com> changed the Status of [bug 1015245|https://bugzilla.redhat.com/show_bug.cgi?id=1015245] from NEW to ASSIGNED
                
> Get core model test framework working with 7.2.0.Final legacy controller
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2185
>                 URL: https://issues.jboss.org/browse/WFLY-2185
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 09:59:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Oct 2013 09:59:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2173) Get subsystem test framework
 working with AS 7.2.0 legacy controller
In-Reply-To: <JIRA.12501755.1380296954000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501755.1380296954000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501755.1380296954000.14021.1380895143673@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809472#comment-12809472 ] 

RH Bugzilla Integration commented on WFLY-2173:
-----------------------------------------------

Emanuel Muckenhuber <emuckenh at redhat.com> changed the Status of [bug 1015245|https://bugzilla.redhat.com/show_bug.cgi?id=1015245] from NEW to ASSIGNED
                
> Get subsystem test framework working with AS 7.2.0 legacy controller
> --------------------------------------------------------------------
>
>                 Key: WFLY-2173
>                 URL: https://issues.jboss.org/browse/WFLY-2173
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 10:05:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Oct 2013 10:05:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2155) Defining
 <outbound-connections> in <management> prevents the server to start
In-Reply-To: <JIRA.12501472.1380107992000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501472.1380107992000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501472.1380107992000.14051.1380895503276@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809476#comment-12809476 ] 

RH Bugzilla Integration commented on WFLY-2155:
-----------------------------------------------

Ladislav Thon <lthon at redhat.com> changed the Status of [bug 1011911|https://bugzilla.redhat.com/show_bug.cgi?id=1011911] from ON_QA to VERIFIED
                
> Defining <outbound-connections> in <management> prevents the server to start
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-2155
>                 URL: https://issues.jboss.org/browse/WFLY-2155
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.Beta1
>
>
> If I want to authenticate against LDAP for management purposes, I have to define an LDAP outbound connection in the {{<management>}} section. But once I do this, the server fails to start with this error message:
> {code}
> 13:18:10,594 ERROR [org.jboss.as.server] (Controller Boot Thread) JBAS015956: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:112) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:331) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:252) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> Caused by: java.lang.UnsupportedOperationException
> 	at org.jboss.as.server.parsing.StandaloneXml$ManagementXmlDelegate.parseOutboundConnections(StandaloneXml.java:1314) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.domain.management.parsing.ManagementXml.parseManagement_2_0(ManagementXml.java:354) [wildfly-domain-management-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.domain.management.parsing.ManagementXml.parseManagement(ManagementXml.java:282) [wildfly-domain-management-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.parsing.StandaloneXml.readServerElement_1_4(StandaloneXml.java:453) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:145) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:107) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:104) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	... 3 more
> 13:18:10,598 FATAL [org.jboss.as.server] (Controller Boot Thread) JBAS015957: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> {code}
> To be precise: I take a freshly built WildFly server and add this into {{standalone.xml}} (into the {{<management>}} section):
> {code:xml}
> <outbound-connections>
>     <ldap name="ldap" url="ldap://localhost:10389"/>
> </outbound-connections>
> {code}
> Then I try to start the server (using plain old {{./bin/standalone.sh}}).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 10:05:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Oct 2013 10:05:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2155) Defining
 <outbound-connections> in <management> prevents the server to start
In-Reply-To: <JIRA.12501472.1380107992000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501472.1380107992000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501472.1380107992000.14054.1380895503484@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809477#comment-12809477 ] 

RH Bugzilla Integration commented on WFLY-2155:
-----------------------------------------------

Ladislav Thon <lthon at redhat.com> made a comment on [bug 1011911|https://bugzilla.redhat.com/show_bug.cgi?id=1011911]

Verified with EAP 6.2.0.ER4.
                
> Defining <outbound-connections> in <management> prevents the server to start
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-2155
>                 URL: https://issues.jboss.org/browse/WFLY-2155
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.Beta1
>
>
> If I want to authenticate against LDAP for management purposes, I have to define an LDAP outbound connection in the {{<management>}} section. But once I do this, the server fails to start with this error message:
> {code}
> 13:18:10,594 ERROR [org.jboss.as.server] (Controller Boot Thread) JBAS015956: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:112) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:331) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:252) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> Caused by: java.lang.UnsupportedOperationException
> 	at org.jboss.as.server.parsing.StandaloneXml$ManagementXmlDelegate.parseOutboundConnections(StandaloneXml.java:1314) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.domain.management.parsing.ManagementXml.parseManagement_2_0(ManagementXml.java:354) [wildfly-domain-management-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.domain.management.parsing.ManagementXml.parseManagement(ManagementXml.java:282) [wildfly-domain-management-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.parsing.StandaloneXml.readServerElement_1_4(StandaloneXml.java:453) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:145) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:107) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:104) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	... 3 more
> 13:18:10,598 FATAL [org.jboss.as.server] (Controller Boot Thread) JBAS015957: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> {code}
> To be precise: I take a freshly built WildFly server and add this into {{standalone.xml}} (into the {{<management>}} section):
> {code:xml}
> <outbound-connections>
>     <ldap name="ldap" url="ldap://localhost:10389"/>
> </outbound-connections>
> {code}
> Then I try to start the server (using plain old {{./bin/standalone.sh}}).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 10:16:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Fri, 4 Oct 2013 10:16:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2219) Update to console 2.0.3.Final
In-Reply-To: <JIRA.12502220.1380896072251@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502220.1380896072251@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502220.1380896072251.14069.1380896163381@jira02.app.mwc.hst.phx2.redhat.com>

Heiko Braun created WFLY-2219:
---------------------------------

             Summary: Update to console 2.0.3.Final
                 Key: WFLY-2219
                 URL: https://issues.jboss.org/browse/WFLY-2219
             Project: WildFly
          Issue Type: Task
          Components: Web Console
            Reporter: Heiko Braun
            Assignee: Heiko Braun
             Fix For: 8.0.0.Beta1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 10:22:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 4 Oct 2013 10:22:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2220) Unable to reload server after
 adding role and enabling RBAC
In-Reply-To: <JIRA.12502221.1380896422566@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502221.1380896422566@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502221.1380896422566.14072.1380896522542@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-2220:
--------------------------------------

             Summary: Unable to reload server after adding role and enabling RBAC
                 Key: WFLY-2220
                 URL: https://issues.jboss.org/browse/WFLY-2220
             Project: WildFly
          Issue Type: Bug
          Components: Domain Management
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
            Priority: Critical
             Fix For: 8.0.0.Beta1


Start a clean build of WildFly 8 and execute the following commands in the CLI: -

{code}
[standalone at localhost:9990 /connect
[standalone at localhost:9990 /] ./core-service=management/access=authorization/role-mapping=Operator:add
{"outcome" => "success"}
[standalone at localhost:9990 /] ./core-service=management/access=authorization/role-mapping=Operator:write-attribute(name=include-all, value=true)
{"outcome" => "success"}
[standalone at localhost:9990 /] ./core-service=management/access=authorization:write-attribute(name=provider, value=rbac)
{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    }
}
[standalone at localhost:9990 /] :reload
{
    "outcome" => "success",
    "result" => undefined
}
[standalone at localhost:9990 /] 
{code}

Results in the following error and the server shuts down: -

{code}
15:15:02,275 INFO  [org.jboss.as.server] (Controller Boot Thread) JBAS015888: Creating http management service using socket-binding (management-http)
15:15:02,278 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014612: Operation ("add") failed - address: ([
    ("core-service" => "management"),
    ("access" => "authorization"),
    ("role-mapping" => "SuperUser")
]): java.lang.UnsupportedOperationException
	at java.util.Collections$UnmodifiableMap.put(Collections.java:1342) [rt.jar:1.7.0_17]
	at org.jboss.as.controller.access.management.WritableAuthorizerConfiguration.addRoleMappingImmediate(WritableAuthorizerConfiguration.java:163) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.domain.management.access.RoleMappingAdd$1.execute(RoleMappingAdd.java:76) [wildfly-domain-management-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:609) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:487) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:321) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:290) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.server.ServerService.boot(ServerService.java:356) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.server.ServerService.boot(ServerService.java:331) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:252) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]

15:15:02,287 INFO  [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
JBAS014775:    New missing/unsatisfied dependencies:
      service jboss.remoting.endpoint.management (missing) dependents: [service jboss.remoting.management.channel.registry] 

15:15:02,290 FATAL [org.jboss.as.server] (Controller Boot Thread) JBAS015957: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
15:15:02,297 INFO  [org.jboss.as] (MSC service thread 1-1) JBAS015950: WildFly 8.0.0.Beta1-SNAPSHOT "WildFly" stopped in 2ms
{code}

What is interesting is that the server is manually startable to something has gone wrong regarding resetting the runtime state of RBAC at the time of the reload.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 10:24:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Fri, 4 Oct 2013 10:24:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1166) Security annotations should
 not be required on abstract session beans
In-Reply-To: <JIRA.12486749.1362681848000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12486749.1362681848000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12486749.1362681848000.14078.1380896642702@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-1166.
----------------------------------

    Resolution: Rejected


I don't think it is worth adding in any more settings to make this configurable. It can already be accomplished by changing the default, and it would not really be consistent, as class level security annotation only affect methods declared in the class, not super class methods. 

Adding settings to change the way these annotations would just be confusing IMHO, and increase the chances of mis-configuration that could inadvertently expose some methods. 
                
> Security annotations should not be required on abstract session beans
> ---------------------------------------------------------------------
>
>                 Key: WFLY-1166
>                 URL: https://issues.jboss.org/browse/WFLY-1166
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EJB
>            Reporter: Samuel Santos
>            Assignee: Stuart Douglas
>
> Example project structure:
> {code:java}
> @Stateless
> @RunAs("private")
> @RolesAllowed("simpleuser")
> @SecurityDomain("myRealm")
> @TransactionAttribute(TransactionAttributeType.REQUIRED)
> public class ExampleServiceBean implements ExampleService {}
> @Stateless
> @RolesAllowed("private")
> @SecurityDomain("myRealm")
> @TransactionAttribute(TransactionAttributeType.SUPPORTS)
> public class ExampleDAOBean extends GenericDAOImpl<ExampleEntity, Long> implements ExampleDAO {}
> @RolesAllowed("private")
> @SecurityDomain("myRealm")
> public abstract class GenericDAOImpl<T, PK extends Serializable> implements GenericDAO<T, PK> {}
> {code}
> If you remove the annotations {{@RolesAllowed("private")}} and {{@SecurityDomain("myRealm")}} from {{GenericDAOImpl}} you will get an "Access Denied" error when invoking {{ExampleDAOBean}}  from {{ExampleServiceBean}}.
> This does not make sense. The annotations available on {{ExampleDAOBean}} should override any security constrains in the class that it extends.
> Moreover, the documentation on https://docs.jboss.org/author/display/AS72/Securing+EJBs does not state that abstracts classes should be annotated.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 10:24:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 4 Oct 2013 10:24:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2220) Unable to reload server after
 adding role and executing :reload
In-Reply-To: <JIRA.12502221.1380896422000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502221.1380896422000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502221.1380896422000.14081.1380896642823@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2220:
-----------------------------------

    Summary: Unable to reload server after adding role and executing :reload  (was: Unable to reload server after adding role and enabling RBAC)

    
> Unable to reload server after adding role and executing :reload
> ---------------------------------------------------------------
>
>                 Key: WFLY-2220
>                 URL: https://issues.jboss.org/browse/WFLY-2220
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>
> Start a clean build of WildFly 8 and execute the following commands in the CLI: -
> {code}
> [standalone at localhost:9990 /connect
> [standalone at localhost:9990 /] ./core-service=management/access=authorization/role-mapping=Operator:add
> {"outcome" => "success"}
> [standalone at localhost:9990 /] ./core-service=management/access=authorization/role-mapping=Operator:write-attribute(name=include-all, value=true)
> {"outcome" => "success"}
> [standalone at localhost:9990 /] ./core-service=management/access=authorization:write-attribute(name=provider, value=rbac)
> {
>     "outcome" => "success",
>     "response-headers" => {
>         "operation-requires-reload" => true,
>         "process-state" => "reload-required"
>     }
> }
> [standalone at localhost:9990 /] :reload
> {
>     "outcome" => "success",
>     "result" => undefined
> }
> [standalone at localhost:9990 /] 
> {code}
> Results in the following error and the server shuts down: -
> {code}
> 15:15:02,275 INFO  [org.jboss.as.server] (Controller Boot Thread) JBAS015888: Creating http management service using socket-binding (management-http)
> 15:15:02,278 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014612: Operation ("add") failed - address: ([
>     ("core-service" => "management"),
>     ("access" => "authorization"),
>     ("role-mapping" => "SuperUser")
> ]): java.lang.UnsupportedOperationException
> 	at java.util.Collections$UnmodifiableMap.put(Collections.java:1342) [rt.jar:1.7.0_17]
> 	at org.jboss.as.controller.access.management.WritableAuthorizerConfiguration.addRoleMappingImmediate(WritableAuthorizerConfiguration.java:163) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.domain.management.access.RoleMappingAdd$1.execute(RoleMappingAdd.java:76) [wildfly-domain-management-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:609) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:487) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:321) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:290) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:356) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:331) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:252) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> 15:15:02,287 INFO  [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.remoting.endpoint.management (missing) dependents: [service jboss.remoting.management.channel.registry] 
> 15:15:02,290 FATAL [org.jboss.as.server] (Controller Boot Thread) JBAS015957: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> 15:15:02,297 INFO  [org.jboss.as] (MSC service thread 1-1) JBAS015950: WildFly 8.0.0.Beta1-SNAPSHOT "WildFly" stopped in 2ms
> {code}
> What is interesting is that the server is manually startable to something has gone wrong regarding resetting the runtime state of RBAC at the time of the reload.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 10:24:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 4 Oct 2013 10:24:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2220) Unable to reload server after
 adding role and executing :reload
In-Reply-To: <JIRA.12502221.1380896422000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502221.1380896422000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502221.1380896422000.14083.1380896642913@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2220:
-----------------------------------

    Description: 
Start a clean build of WildFly 8 and execute the following commands in the CLI: -

{code}
[standalone at localhost:9990 /connect
[standalone at localhost:9990 /] ./core-service=management/access=authorization/role-mapping=Operator:add
{"outcome" => "success"}
[standalone at localhost:9990 /] :reload
{
    "outcome" => "success",
    "result" => undefined
}
[standalone at localhost:9990 /] 
{code}

Results in the following error and the server shuts down: -

{code}
15:15:02,275 INFO  [org.jboss.as.server] (Controller Boot Thread) JBAS015888: Creating http management service using socket-binding (management-http)
15:15:02,278 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014612: Operation ("add") failed - address: ([
    ("core-service" => "management"),
    ("access" => "authorization"),
    ("role-mapping" => "SuperUser")
]): java.lang.UnsupportedOperationException
	at java.util.Collections$UnmodifiableMap.put(Collections.java:1342) [rt.jar:1.7.0_17]
	at org.jboss.as.controller.access.management.WritableAuthorizerConfiguration.addRoleMappingImmediate(WritableAuthorizerConfiguration.java:163) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.domain.management.access.RoleMappingAdd$1.execute(RoleMappingAdd.java:76) [wildfly-domain-management-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:609) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:487) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:321) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:290) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.server.ServerService.boot(ServerService.java:356) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.server.ServerService.boot(ServerService.java:331) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:252) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]

15:15:02,287 INFO  [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
JBAS014775:    New missing/unsatisfied dependencies:
      service jboss.remoting.endpoint.management (missing) dependents: [service jboss.remoting.management.channel.registry] 

15:15:02,290 FATAL [org.jboss.as.server] (Controller Boot Thread) JBAS015957: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
15:15:02,297 INFO  [org.jboss.as] (MSC service thread 1-1) JBAS015950: WildFly 8.0.0.Beta1-SNAPSHOT "WildFly" stopped in 2ms
{code}

What is interesting is that the server is manually startable to something has gone wrong regarding resetting the runtime state of RBAC at the time of the reload.


  was:
Start a clean build of WildFly 8 and execute the following commands in the CLI: -

{code}
[standalone at localhost:9990 /connect
[standalone at localhost:9990 /] ./core-service=management/access=authorization/role-mapping=Operator:add
{"outcome" => "success"}
[standalone at localhost:9990 /] ./core-service=management/access=authorization/role-mapping=Operator:write-attribute(name=include-all, value=true)
{"outcome" => "success"}
[standalone at localhost:9990 /] ./core-service=management/access=authorization:write-attribute(name=provider, value=rbac)
{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    }
}
[standalone at localhost:9990 /] :reload
{
    "outcome" => "success",
    "result" => undefined
}
[standalone at localhost:9990 /] 
{code}

Results in the following error and the server shuts down: -

{code}
15:15:02,275 INFO  [org.jboss.as.server] (Controller Boot Thread) JBAS015888: Creating http management service using socket-binding (management-http)
15:15:02,278 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014612: Operation ("add") failed - address: ([
    ("core-service" => "management"),
    ("access" => "authorization"),
    ("role-mapping" => "SuperUser")
]): java.lang.UnsupportedOperationException
	at java.util.Collections$UnmodifiableMap.put(Collections.java:1342) [rt.jar:1.7.0_17]
	at org.jboss.as.controller.access.management.WritableAuthorizerConfiguration.addRoleMappingImmediate(WritableAuthorizerConfiguration.java:163) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.domain.management.access.RoleMappingAdd$1.execute(RoleMappingAdd.java:76) [wildfly-domain-management-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:609) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:487) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:321) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:290) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.server.ServerService.boot(ServerService.java:356) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.server.ServerService.boot(ServerService.java:331) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:252) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]

15:15:02,287 INFO  [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
JBAS014775:    New missing/unsatisfied dependencies:
      service jboss.remoting.endpoint.management (missing) dependents: [service jboss.remoting.management.channel.registry] 

15:15:02,290 FATAL [org.jboss.as.server] (Controller Boot Thread) JBAS015957: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
15:15:02,297 INFO  [org.jboss.as] (MSC service thread 1-1) JBAS015950: WildFly 8.0.0.Beta1-SNAPSHOT "WildFly" stopped in 2ms
{code}

What is interesting is that the server is manually startable to something has gone wrong regarding resetting the runtime state of RBAC at the time of the reload.



    
> Unable to reload server after adding role and executing :reload
> ---------------------------------------------------------------
>
>                 Key: WFLY-2220
>                 URL: https://issues.jboss.org/browse/WFLY-2220
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>
> Start a clean build of WildFly 8 and execute the following commands in the CLI: -
> {code}
> [standalone at localhost:9990 /connect
> [standalone at localhost:9990 /] ./core-service=management/access=authorization/role-mapping=Operator:add
> {"outcome" => "success"}
> [standalone at localhost:9990 /] :reload
> {
>     "outcome" => "success",
>     "result" => undefined
> }
> [standalone at localhost:9990 /] 
> {code}
> Results in the following error and the server shuts down: -
> {code}
> 15:15:02,275 INFO  [org.jboss.as.server] (Controller Boot Thread) JBAS015888: Creating http management service using socket-binding (management-http)
> 15:15:02,278 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014612: Operation ("add") failed - address: ([
>     ("core-service" => "management"),
>     ("access" => "authorization"),
>     ("role-mapping" => "SuperUser")
> ]): java.lang.UnsupportedOperationException
> 	at java.util.Collections$UnmodifiableMap.put(Collections.java:1342) [rt.jar:1.7.0_17]
> 	at org.jboss.as.controller.access.management.WritableAuthorizerConfiguration.addRoleMappingImmediate(WritableAuthorizerConfiguration.java:163) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.domain.management.access.RoleMappingAdd$1.execute(RoleMappingAdd.java:76) [wildfly-domain-management-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:609) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:487) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:321) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:290) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:356) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:331) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:252) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> 15:15:02,287 INFO  [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.remoting.endpoint.management (missing) dependents: [service jboss.remoting.management.channel.registry] 
> 15:15:02,290 FATAL [org.jboss.as.server] (Controller Boot Thread) JBAS015957: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> 15:15:02,297 INFO  [org.jboss.as] (MSC service thread 1-1) JBAS015950: WildFly 8.0.0.Beta1-SNAPSHOT "WildFly" stopped in 2ms
> {code}
> What is interesting is that the server is manually startable to something has gone wrong regarding resetting the runtime state of RBAC at the time of the reload.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 10:30:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Oct 2013 10:30:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2220) Unable to reload server after
 adding role and executing :reload
In-Reply-To: <JIRA.12502221.1380896422000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502221.1380896422000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502221.1380896422000.14091.1380897002608@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809479#comment-12809479 ] 

RH Bugzilla Integration commented on WFLY-2220:
-----------------------------------------------

Ladislav Thon <lthon at redhat.com> made a comment on [bug 1015585|https://bugzilla.redhat.com/show_bug.cgi?id=1015585]

Description of problem:

When you add a new role mapping and then request a server restart via the management interface, your server will crash.

Version-Release number of selected component (if applicable):

EAP 6.2.0.ER4

How reproducible:

Always

Steps to Reproduce:
1. start a new server
   ./bin/standalone.sh
2. run CLI
   ./bin/jboss-cli.sh -c
3. add a new role mapping
   /core-service=management/access=authorization/role-mapping=Operator:add()
4. restart the server
   :reload

Actual results:

The server restarts fine with no error message.

Expected results:

The server "crashes" with an error message:

16:24:48,601 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014612: Operation ("add") failed - address: ([
    ("core-service" => "management"),
    ("access" => "authorization"),
    ("role-mapping" => "SuperUser")
]): java.lang.UnsupportedOperationException
	at java.util.Collections$UnmodifiableMap.put(Collections.java:1283) [rt.jar:1.6.0_45]
	at org.jboss.as.controller.access.management.WritableAuthorizerConfiguration.addRoleMappingImmediate(WritableAuthorizerConfiguration.java:163) [jboss-as-controller-7.3.0.Final-redhat-7.jar:7.3.0.Final-redhat-7]
	at org.jboss.as.domain.management.access.RoleMappingAdd$1.execute(RoleMappingAdd.java:76) [jboss-as-domain-management-7.3.0.Final-redhat-7.jar:7.3.0.Final-redhat-7]
	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:624) [jboss-as-controller-7.3.0.Final-redhat-7.jar:7.3.0.Final-redhat-7]
	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:502) [jboss-as-controller-7.3.0.Final-redhat-7.jar:7.3.0.Final-redhat-7]
	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:285) [jboss-as-controller-7.3.0.Final-redhat-7.jar:7.3.0.Final-redhat-7]
	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:280) [jboss-as-controller-7.3.0.Final-redhat-7.jar:7.3.0.Final-redhat-7]
	at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:277) [jboss-as-controller-7.3.0.Final-redhat-7.jar:7.3.0.Final-redhat-7]
	at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:288) [jboss-as-controller-7.3.0.Final-redhat-7.jar:7.3.0.Final-redhat-7]
	at org.jboss.as.server.ServerService.boot(ServerService.java:349) [jboss-as-server-7.3.0.Final-redhat-7.jar:7.3.0.Final-redhat-7]
	at org.jboss.as.server.ServerService.boot(ServerService.java:324) [jboss-as-server-7.3.0.Final-redhat-7.jar:7.3.0.Final-redhat-7]
	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:250) [jboss-as-controller-7.3.0.Final-redhat-7.jar:7.3.0.Final-redhat-7]
	at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_45]

16:24:48,609 INFO  [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
JBAS014775:    New missing/unsatisfied dependencies:
      service jboss.remoting.endpoint.management (missing) dependents: [service jboss.remoting.management.channel.registry] 

16:24:48,611 FATAL [org.jboss.as.server] (Controller Boot Thread) JBAS015957: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
16:24:48,617 INFO  [org.jboss.as.controller] (MSC service thread 1-6) JBAS014774: Service status report
JBAS014776:    Newly corrected services:
      service jboss.remoting.endpoint.management (no longer required)

16:24:48,619 INFO  [org.jboss.as] (MSC service thread 1-1) JBAS015950: JBoss EAP 6.2.0.Beta1 (AS 7.3.0.Final-redhat-7) stopped in 4ms

Additional info:

Note that it's not even necessary to enable the "rbac" provider. Also note that after the server crashes, it can be started just fine, suggesting that there's probably something wrong in the runtime model.
                
> Unable to reload server after adding role and executing :reload
> ---------------------------------------------------------------
>
>                 Key: WFLY-2220
>                 URL: https://issues.jboss.org/browse/WFLY-2220
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>
> Start a clean build of WildFly 8 and execute the following commands in the CLI: -
> {code}
> [standalone at localhost:9990 /connect
> [standalone at localhost:9990 /] ./core-service=management/access=authorization/role-mapping=Operator:add
> {"outcome" => "success"}
> [standalone at localhost:9990 /] :reload
> {
>     "outcome" => "success",
>     "result" => undefined
> }
> [standalone at localhost:9990 /] 
> {code}
> Results in the following error and the server shuts down: -
> {code}
> 15:15:02,275 INFO  [org.jboss.as.server] (Controller Boot Thread) JBAS015888: Creating http management service using socket-binding (management-http)
> 15:15:02,278 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014612: Operation ("add") failed - address: ([
>     ("core-service" => "management"),
>     ("access" => "authorization"),
>     ("role-mapping" => "SuperUser")
> ]): java.lang.UnsupportedOperationException
> 	at java.util.Collections$UnmodifiableMap.put(Collections.java:1342) [rt.jar:1.7.0_17]
> 	at org.jboss.as.controller.access.management.WritableAuthorizerConfiguration.addRoleMappingImmediate(WritableAuthorizerConfiguration.java:163) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.domain.management.access.RoleMappingAdd$1.execute(RoleMappingAdd.java:76) [wildfly-domain-management-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:609) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:487) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:321) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:290) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:356) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:331) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:252) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> 15:15:02,287 INFO  [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.remoting.endpoint.management (missing) dependents: [service jboss.remoting.management.channel.registry] 
> 15:15:02,290 FATAL [org.jboss.as.server] (Controller Boot Thread) JBAS015957: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> 15:15:02,297 INFO  [org.jboss.as] (MSC service thread 1-1) JBAS015950: WildFly 8.0.0.Beta1-SNAPSHOT "WildFly" stopped in 2ms
> {code}
> What is interesting is that the server is manually startable to something has gone wrong regarding resetting the runtime state of RBAC at the time of the reload.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 10:30:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Oct 2013 10:30:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2220) Unable to reload server after
 adding role and executing :reload
In-Reply-To: <JIRA.12502221.1380896422000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502221.1380896422000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502221.1380896422000.14093.1380897002696@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2220:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1015585

    
> Unable to reload server after adding role and executing :reload
> ---------------------------------------------------------------
>
>                 Key: WFLY-2220
>                 URL: https://issues.jboss.org/browse/WFLY-2220
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>
> Start a clean build of WildFly 8 and execute the following commands in the CLI: -
> {code}
> [standalone at localhost:9990 /connect
> [standalone at localhost:9990 /] ./core-service=management/access=authorization/role-mapping=Operator:add
> {"outcome" => "success"}
> [standalone at localhost:9990 /] :reload
> {
>     "outcome" => "success",
>     "result" => undefined
> }
> [standalone at localhost:9990 /] 
> {code}
> Results in the following error and the server shuts down: -
> {code}
> 15:15:02,275 INFO  [org.jboss.as.server] (Controller Boot Thread) JBAS015888: Creating http management service using socket-binding (management-http)
> 15:15:02,278 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014612: Operation ("add") failed - address: ([
>     ("core-service" => "management"),
>     ("access" => "authorization"),
>     ("role-mapping" => "SuperUser")
> ]): java.lang.UnsupportedOperationException
> 	at java.util.Collections$UnmodifiableMap.put(Collections.java:1342) [rt.jar:1.7.0_17]
> 	at org.jboss.as.controller.access.management.WritableAuthorizerConfiguration.addRoleMappingImmediate(WritableAuthorizerConfiguration.java:163) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.domain.management.access.RoleMappingAdd$1.execute(RoleMappingAdd.java:76) [wildfly-domain-management-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:609) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:487) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:321) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:290) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:356) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:331) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:252) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> 15:15:02,287 INFO  [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.remoting.endpoint.management (missing) dependents: [service jboss.remoting.management.channel.registry] 
> 15:15:02,290 FATAL [org.jboss.as.server] (Controller Boot Thread) JBAS015957: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> 15:15:02,297 INFO  [org.jboss.as] (MSC service thread 1-1) JBAS015950: WildFly 8.0.0.Beta1-SNAPSHOT "WildFly" stopped in 2ms
> {code}
> What is interesting is that the server is manually startable to something has gone wrong regarding resetting the runtime state of RBAC at the time of the reload.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 10:32:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Oct 2013 10:32:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2220) Unable to reload server after
 adding role and executing :reload
In-Reply-To: <JIRA.12502221.1380896422000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502221.1380896422000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502221.1380896422000.14099.1380897122812@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809480#comment-12809480 ] 

RH Bugzilla Integration commented on WFLY-2220:
-----------------------------------------------

Ladislav Thon <lthon at redhat.com> made a comment on [bug 1015585|https://bugzilla.redhat.com/show_bug.cgi?id=1015585]

Meh, once again I swapped the "actual" and "expected" results :-(
                
> Unable to reload server after adding role and executing :reload
> ---------------------------------------------------------------
>
>                 Key: WFLY-2220
>                 URL: https://issues.jboss.org/browse/WFLY-2220
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>
> Start a clean build of WildFly 8 and execute the following commands in the CLI: -
> {code}
> [standalone at localhost:9990 /connect
> [standalone at localhost:9990 /] ./core-service=management/access=authorization/role-mapping=Operator:add
> {"outcome" => "success"}
> [standalone at localhost:9990 /] :reload
> {
>     "outcome" => "success",
>     "result" => undefined
> }
> [standalone at localhost:9990 /] 
> {code}
> Results in the following error and the server shuts down: -
> {code}
> 15:15:02,275 INFO  [org.jboss.as.server] (Controller Boot Thread) JBAS015888: Creating http management service using socket-binding (management-http)
> 15:15:02,278 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014612: Operation ("add") failed - address: ([
>     ("core-service" => "management"),
>     ("access" => "authorization"),
>     ("role-mapping" => "SuperUser")
> ]): java.lang.UnsupportedOperationException
> 	at java.util.Collections$UnmodifiableMap.put(Collections.java:1342) [rt.jar:1.7.0_17]
> 	at org.jboss.as.controller.access.management.WritableAuthorizerConfiguration.addRoleMappingImmediate(WritableAuthorizerConfiguration.java:163) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.domain.management.access.RoleMappingAdd$1.execute(RoleMappingAdd.java:76) [wildfly-domain-management-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:609) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:487) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:321) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:290) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:356) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:331) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:252) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> 15:15:02,287 INFO  [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.remoting.endpoint.management (missing) dependents: [service jboss.remoting.management.channel.registry] 
> 15:15:02,290 FATAL [org.jboss.as.server] (Controller Boot Thread) JBAS015957: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> 15:15:02,297 INFO  [org.jboss.as] (MSC service thread 1-1) JBAS015950: WildFly 8.0.0.Beta1-SNAPSHOT "WildFly" stopped in 2ms
> {code}
> What is interesting is that the server is manually startable to something has gone wrong regarding resetting the runtime state of RBAC at the time of the reload.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 10:34:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Oct 2013 10:34:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2220) Unable to reload server after
 adding role and executing :reload
In-Reply-To: <JIRA.12502221.1380896422000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502221.1380896422000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502221.1380896422000.14105.1380897242609@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809482#comment-12809482 ] 

RH Bugzilla Integration commented on WFLY-2220:
-----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> changed the Status of [bug 1015585|https://bugzilla.redhat.com/show_bug.cgi?id=1015585] from NEW to ASSIGNED
                
> Unable to reload server after adding role and executing :reload
> ---------------------------------------------------------------
>
>                 Key: WFLY-2220
>                 URL: https://issues.jboss.org/browse/WFLY-2220
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>
> Start a clean build of WildFly 8 and execute the following commands in the CLI: -
> {code}
> [standalone at localhost:9990 /connect
> [standalone at localhost:9990 /] ./core-service=management/access=authorization/role-mapping=Operator:add
> {"outcome" => "success"}
> [standalone at localhost:9990 /] :reload
> {
>     "outcome" => "success",
>     "result" => undefined
> }
> [standalone at localhost:9990 /] 
> {code}
> Results in the following error and the server shuts down: -
> {code}
> 15:15:02,275 INFO  [org.jboss.as.server] (Controller Boot Thread) JBAS015888: Creating http management service using socket-binding (management-http)
> 15:15:02,278 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014612: Operation ("add") failed - address: ([
>     ("core-service" => "management"),
>     ("access" => "authorization"),
>     ("role-mapping" => "SuperUser")
> ]): java.lang.UnsupportedOperationException
> 	at java.util.Collections$UnmodifiableMap.put(Collections.java:1342) [rt.jar:1.7.0_17]
> 	at org.jboss.as.controller.access.management.WritableAuthorizerConfiguration.addRoleMappingImmediate(WritableAuthorizerConfiguration.java:163) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.domain.management.access.RoleMappingAdd$1.execute(RoleMappingAdd.java:76) [wildfly-domain-management-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:609) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:487) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:321) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:290) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:356) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:331) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:252) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> 15:15:02,287 INFO  [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.remoting.endpoint.management (missing) dependents: [service jboss.remoting.management.channel.registry] 
> 15:15:02,290 FATAL [org.jboss.as.server] (Controller Boot Thread) JBAS015957: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> 15:15:02,297 INFO  [org.jboss.as] (MSC service thread 1-1) JBAS015950: WildFly 8.0.0.Beta1-SNAPSHOT "WildFly" stopped in 2ms
> {code}
> What is interesting is that the server is manually startable to something has gone wrong regarding resetting the runtime state of RBAC at the time of the reload.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 10:44:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Fri, 4 Oct 2013 10:44:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-281) no reevaluation of 'from
 collect' is performed
In-Reply-To: <JIRA.12502111.1380805492000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502111.1380805492000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502111.1380805492000.14130.1380897842731@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-281:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> no reevaluation of 'from collect' is performed
> ----------------------------------------------
>
>                 Key: DROOLS-281
>                 URL: https://issues.jboss.org/browse/DROOLS-281
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>            Reporter: Richard Bourner
>            Assignee: Mario Fusco
>            Priority: Critical
>         Attachments: Drools6FromCollectIssue.zip
>
>
> Using Drools 6.0.0.CR4, a problem has been found related to reevaluation of a condition that contains a 'from collect' statement.
> A unit test is provided demonstrating the issue using 2 rules.  This unit test works fine using 6.0.0.Beta2.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 10:46:03 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Fri, 4 Oct 2013 10:46:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-281) no reevaluation of 'from
 collect' is performed
In-Reply-To: <JIRA.12502111.1380805492000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502111.1380805492000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502111.1380805492000.14141.1380897963485@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809487#comment-12809487 ] 

Mario Fusco commented on DROOLS-281:
------------------------------------

I found that this problem is reproducible with rete but it works as expected with phreak.
I also suspect this is not a regression, but more likely you were using phreak when you tested this issue with the Beta2. Please confirm.
                
> no reevaluation of 'from collect' is performed
> ----------------------------------------------
>
>                 Key: DROOLS-281
>                 URL: https://issues.jboss.org/browse/DROOLS-281
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>            Reporter: Richard Bourner
>            Assignee: Mario Fusco
>            Priority: Critical
>         Attachments: Drools6FromCollectIssue.zip
>
>
> Using Drools 6.0.0.CR4, a problem has been found related to reevaluation of a condition that contains a 'from collect' statement.
> A unit test is provided demonstrating the issue using 2 rules.  This unit test works fine using 6.0.0.Beta2.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 10:48:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Oct 2013 10:48:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1871) CLI module command doesn't
 allow cross platform resource paths
In-Reply-To: <JIRA.12498510.1376412050000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498510.1376412050000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498510.1376412050000.14149.1380898082775@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809488#comment-12809488 ] 

RH Bugzilla Integration commented on WFLY-1871:
-----------------------------------------------

Alexey Loubyansky <olubyans at redhat.com> made a comment on [bug 1015400|https://bugzilla.redhat.com/show_bug.cgi?id=1015400]

ok, just, please, follow the argument naming convention, i.e. --resource-delimiter
                
> CLI module command doesn't allow cross platform resource paths
> --------------------------------------------------------------
>
>                 Key: WFLY-1871
>                 URL: https://issues.jboss.org/browse/WFLY-1871
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Stan Silvert
>            Assignee: Stan Silvert
>             Fix For: 8.0.0.Beta1
>
>
> The CLI module command has an argument called "resources".  This argument allows you to specify one or more resources separated by the platform-specific path separator.  The problem with this is that you can not create a platform-independent script that uses this resources argument.
> I have not found a universal path separator character that would work.  However, since the creator of the script knows the characters used in his path, we can allow him to specify his own separator.
> As an enhancement, I propose to add an argument called "resourceDelimiter".  If present, the ASModuleHandler class will use the user-defined delimiter instead of the platform-specific path separator character.
> Example usage:
> {noformat}
> module add --name=org.foo --resources=firstResource.jar:secondResource.jar --resourceDelimiter=: --module-xml=foo-module.xml
> {noformat}
> The above command would work on Unix, Windows, or any other platform.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 11:10:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Oct 2013 11:10:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1871) CLI module command doesn't
 allow cross platform resource paths
In-Reply-To: <JIRA.12498510.1376412050000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498510.1376412050000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498510.1376412050000.14191.1380899402709@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809497#comment-12809497 ] 

RH Bugzilla Integration commented on WFLY-1871:
-----------------------------------------------

Ivo Studensky <istudens at redhat.com> made a comment on [bug 1015400|https://bugzilla.redhat.com/show_bug.cgi?id=1015400]

Changed to Enhancement.
                
> CLI module command doesn't allow cross platform resource paths
> --------------------------------------------------------------
>
>                 Key: WFLY-1871
>                 URL: https://issues.jboss.org/browse/WFLY-1871
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Stan Silvert
>            Assignee: Stan Silvert
>             Fix For: 8.0.0.Beta1
>
>
> The CLI module command has an argument called "resources".  This argument allows you to specify one or more resources separated by the platform-specific path separator.  The problem with this is that you can not create a platform-independent script that uses this resources argument.
> I have not found a universal path separator character that would work.  However, since the creator of the script knows the characters used in his path, we can allow him to specify his own separator.
> As an enhancement, I propose to add an argument called "resourceDelimiter".  If present, the ASModuleHandler class will use the user-defined delimiter instead of the platform-specific path separator character.
> Example usage:
> {noformat}
> module add --name=org.foo --resources=firstResource.jar:secondResource.jar --resourceDelimiter=: --module-xml=foo-module.xml
> {noformat}
> The above command would work on Unix, Windows, or any other platform.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 11:12:02 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 4 Oct 2013 11:12:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2221) NPE in BinderService
In-Reply-To: <JIRA.12502237.1380899464354@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502237.1380899464354@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502237.1380899464354.14196.1380899522689@jira02.app.mwc.hst.phx2.redhat.com>

Jesper Pedersen created WFLY-2221:
-------------------------------------

             Summary: NPE in BinderService
                 Key: WFLY-2221
                 URL: https://issues.jboss.org/browse/WFLY-2221
             Project: WildFly
          Issue Type: Bug
          Components: Naming
    Affects Versions: 8.0.0.Beta1
            Reporter: Jesper Pedersen
            Assignee: Eduardo Martins


{noformat}
11:03:33,766 ERROR [org.jboss.msc.service] (MSC service thread 1-4) MSC000002: Invocation of listener "org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor$BinderReleaseListener at 2d6f9ce1" failed: java.lang.NullPointerException
        at org.jboss.as.naming.service.BinderService.release(BinderService.java:100) [wildfly-naming-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
        at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor$BinderReleaseListener.transition(ModuleJndiBindingProcessor.java:302) [wildfly-ee-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
        at org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1533) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
        at org.jboss.msc.service.ServiceControllerImpl.access$2800(ServiceControllerImpl.java:51) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
        at org.jboss.msc.service.ServiceControllerImpl$ListenerTask.run(ServiceControllerImpl.java:2095) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
        at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
{noformat}

Master from 3 days ago

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 11:39:02 2013
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Fri, 4 Oct 2013 11:39:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1871) CLI module command doesn't
 allow cross platform resource paths
In-Reply-To: <JIRA.12498510.1376412050000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498510.1376412050000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498510.1376412050000.14223.1380901142621@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stan Silvert reopened WFLY-1871:
--------------------------------



Reopening.  The naming convention issue on the resource delimiter was missed the first time around.
                
> CLI module command doesn't allow cross platform resource paths
> --------------------------------------------------------------
>
>                 Key: WFLY-1871
>                 URL: https://issues.jboss.org/browse/WFLY-1871
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Stan Silvert
>            Assignee: Stan Silvert
>             Fix For: 8.0.0.Beta1
>
>
> The CLI module command has an argument called "resources".  This argument allows you to specify one or more resources separated by the platform-specific path separator.  The problem with this is that you can not create a platform-independent script that uses this resources argument.
> I have not found a universal path separator character that would work.  However, since the creator of the script knows the characters used in his path, we can allow him to specify his own separator.
> As an enhancement, I propose to add an argument called "resourceDelimiter".  If present, the ASModuleHandler class will use the user-defined delimiter instead of the platform-specific path separator character.
> Example usage:
> {noformat}
> module add --name=org.foo --resources=firstResource.jar:secondResource.jar --resourceDelimiter=: --module-xml=foo-module.xml
> {noformat}
> The above command would work on Unix, Windows, or any other platform.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 11:59:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Oct 2013 11:59:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-281) no reevaluation of 'from
 collect' is performed
In-Reply-To: <JIRA.12502111.1380805492000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502111.1380805492000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502111.1380805492000.14274.1380902342711@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809517#comment-12809517 ] 

RH Bugzilla Integration commented on DROOLS-281:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> made a comment on [bug 1015109|https://bugzilla.redhat.com/show_bug.cgi?id=1015109]

Fixed by https://github.com/droolsjbpm/drools/commit/d1a1fa06a
                
> no reevaluation of 'from collect' is performed
> ----------------------------------------------
>
>                 Key: DROOLS-281
>                 URL: https://issues.jboss.org/browse/DROOLS-281
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>            Reporter: Richard Bourner
>            Assignee: Mario Fusco
>            Priority: Critical
>         Attachments: Drools6FromCollectIssue.zip
>
>
> Using Drools 6.0.0.CR4, a problem has been found related to reevaluation of a condition that contains a 'from collect' statement.
> A unit test is provided demonstrating the issue using 2 rules.  This unit test works fine using 6.0.0.Beta2.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 11:59:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Oct 2013 11:59:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-281) no reevaluation of 'from
 collect' is performed
In-Reply-To: <JIRA.12502111.1380805492000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502111.1380805492000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502111.1380805492000.14277.1380902342855@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809518#comment-12809518 ] 

RH Bugzilla Integration commented on DROOLS-281:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> changed the Status of [bug 1015109|https://bugzilla.redhat.com/show_bug.cgi?id=1015109] from ASSIGNED to MODIFIED
                
> no reevaluation of 'from collect' is performed
> ----------------------------------------------
>
>                 Key: DROOLS-281
>                 URL: https://issues.jboss.org/browse/DROOLS-281
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>            Reporter: Richard Bourner
>            Assignee: Mario Fusco
>            Priority: Critical
>         Attachments: Drools6FromCollectIssue.zip
>
>
> Using Drools 6.0.0.CR4, a problem has been found related to reevaluation of a condition that contains a 'from collect' statement.
> A unit test is provided demonstrating the issue using 2 rules.  This unit test works fine using 6.0.0.Beta2.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 11:59:03 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Fri, 4 Oct 2013 11:59:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-281) no reevaluation of 'from
 collect' is performed
In-Reply-To: <JIRA.12502111.1380805492000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502111.1380805492000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502111.1380805492000.14281.1380902343075@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-281.
--------------------------------

    Fix Version/s: 6.0.0.CR5
       Resolution: Done

    
> no reevaluation of 'from collect' is performed
> ----------------------------------------------
>
>                 Key: DROOLS-281
>                 URL: https://issues.jboss.org/browse/DROOLS-281
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>            Reporter: Richard Bourner
>            Assignee: Mario Fusco
>            Priority: Critical
>             Fix For: 6.0.0.CR5
>
>         Attachments: Drools6FromCollectIssue.zip
>
>
> Using Drools 6.0.0.CR4, a problem has been found related to reevaluation of a condition that contains a 'from collect' statement.
> A unit test is provided demonstrating the issue using 2 rules.  This unit test works fine using 6.0.0.Beta2.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 12:09:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Oct 2013 12:09:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2220) Unable to reload server after
 adding role and executing :reload
In-Reply-To: <JIRA.12502221.1380896422000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502221.1380896422000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502221.1380896422000.14294.1380902942725@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809519#comment-12809519 ] 

RH Bugzilla Integration commented on WFLY-2220:
-----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> changed the Status of [bug 1015585|https://bugzilla.redhat.com/show_bug.cgi?id=1015585] from ASSIGNED to POST
                
> Unable to reload server after adding role and executing :reload
> ---------------------------------------------------------------
>
>                 Key: WFLY-2220
>                 URL: https://issues.jboss.org/browse/WFLY-2220
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>
> Start a clean build of WildFly 8 and execute the following commands in the CLI: -
> {code}
> [standalone at localhost:9990 /connect
> [standalone at localhost:9990 /] ./core-service=management/access=authorization/role-mapping=Operator:add
> {"outcome" => "success"}
> [standalone at localhost:9990 /] :reload
> {
>     "outcome" => "success",
>     "result" => undefined
> }
> [standalone at localhost:9990 /] 
> {code}
> Results in the following error and the server shuts down: -
> {code}
> 15:15:02,275 INFO  [org.jboss.as.server] (Controller Boot Thread) JBAS015888: Creating http management service using socket-binding (management-http)
> 15:15:02,278 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014612: Operation ("add") failed - address: ([
>     ("core-service" => "management"),
>     ("access" => "authorization"),
>     ("role-mapping" => "SuperUser")
> ]): java.lang.UnsupportedOperationException
> 	at java.util.Collections$UnmodifiableMap.put(Collections.java:1342) [rt.jar:1.7.0_17]
> 	at org.jboss.as.controller.access.management.WritableAuthorizerConfiguration.addRoleMappingImmediate(WritableAuthorizerConfiguration.java:163) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.domain.management.access.RoleMappingAdd$1.execute(RoleMappingAdd.java:76) [wildfly-domain-management-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:609) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:487) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:321) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:290) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:356) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:331) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:252) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> 15:15:02,287 INFO  [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.remoting.endpoint.management (missing) dependents: [service jboss.remoting.management.channel.registry] 
> 15:15:02,290 FATAL [org.jboss.as.server] (Controller Boot Thread) JBAS015957: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> 15:15:02,297 INFO  [org.jboss.as] (MSC service thread 1-1) JBAS015950: WildFly 8.0.0.Beta1-SNAPSHOT "WildFly" stopped in 2ms
> {code}
> What is interesting is that the server is manually startable to something has gone wrong regarding resetting the runtime state of RBAC at the time of the reload.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 12:15:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 4 Oct 2013 12:15:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2216) include-all role mappings
 don't work in domain
In-Reply-To: <JIRA.12502198.1380887272000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502198.1380887272000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502198.1380887272000.14301.1380903303968@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2216:
-----------------------------------

    Fix Version/s: 8.0.0.Beta1

    
> include-all role mappings don't work in domain
> ----------------------------------------------
>
>                 Key: WFLY-2216
>                 URL: https://issues.jboss.org/browse/WFLY-2216
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Ladislav Thon
>            Assignee: Darran Lofthouse
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.Beta1
>
>
> If I understand correctly, roles that have {{include-all=true}} in their role mappings should be added to all authenticated users. In my tests, though, this only works in standalone mode.
> In domain mode, if I set a role mapping to {{include-all}}, this setting is not reflected (at least not immediately; maybe it would work after restart, but that's wrong anyway). It doesn't matter which role is set to be {{include-all}} -- in my tests, I use both standard roles and scoped roles and it consistently doesn't work. There's probably some wrong caching going on.
> The failing test case is in my pull request https://github.com/wildfly/wildfly/pull/5166 (it's the _RBAC tests for include-all role mappings in domain_ commit). If it's more convenient, the pull request is the same as my _rbac_ branch (https://github.com/Ladicek/wildfly/commits/rbac).
> Darran, I'm not sure if you are the right assignee -- please reassign if needed. Thanks.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 12:19:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 4 Oct 2013 12:19:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2216) include-all role mappings
 don't work in domain
In-Reply-To: <JIRA.12502198.1380887272000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502198.1380887272000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502198.1380887272000.14320.1380903542664@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809524#comment-12809524 ] 

Darran Lofthouse commented on WFLY-2216:
----------------------------------------

The following commands are sufficient to reproduce this (ensure the provider is set to rbac before starting the server): -

{code}
[domain at localhost:9990 /] ./core-service=management/access=authorization/role-mapping=Operator:add
{
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => {"main-server-group" => {"host" => {"master" => {
        "server-one" => {"response" => {"outcome" => "success"}},
        "server-two" => {"response" => {"outcome" => "success"}}
    }}}}
}
[domain at localhost:9990 /] ./core-service=management/access=authorization/role-mapping=Operator:write-attribute(name=include-all, value=true)
{
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => {"main-server-group" => {"host" => {"master" => {
        "server-one" => {"response" => {"outcome" => "success"}},
        "server-two" => {"response" => {"outcome" => "success"}}
    }}}}
}
[domain at localhost:9990 /] :whoami(verbose=true)
{
    "outcome" => "success",
    "result" => {
        "identity" => {
            "username" => "$local",
            "realm" => "ManagementRealm"
        },
        "mapped-roles" => ["SUPERUSER"]
    }
}
{code}
                
> include-all role mappings don't work in domain
> ----------------------------------------------
>
>                 Key: WFLY-2216
>                 URL: https://issues.jboss.org/browse/WFLY-2216
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Ladislav Thon
>            Assignee: Darran Lofthouse
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.Beta1
>
>
> If I understand correctly, roles that have {{include-all=true}} in their role mappings should be added to all authenticated users. In my tests, though, this only works in standalone mode.
> In domain mode, if I set a role mapping to {{include-all}}, this setting is not reflected (at least not immediately; maybe it would work after restart, but that's wrong anyway). It doesn't matter which role is set to be {{include-all}} -- in my tests, I use both standard roles and scoped roles and it consistently doesn't work. There's probably some wrong caching going on.
> The failing test case is in my pull request https://github.com/wildfly/wildfly/pull/5166 (it's the _RBAC tests for include-all role mappings in domain_ commit). If it's more convenient, the pull request is the same as my _rbac_ branch (https://github.com/Ladicek/wildfly/commits/rbac).
> Darran, I'm not sure if you are the right assignee -- please reassign if needed. Thanks.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 12:23:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 4 Oct 2013 12:23:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2216) include-all role mappings
 don't work in domain
In-Reply-To: <JIRA.12502198.1380887272000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502198.1380887272000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502198.1380887272000.14341.1380903782606@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809525#comment-12809525 ] 

Darran Lofthouse commented on WFLY-2216:
----------------------------------------

Manually restarting the domain leads to the expected result being output: -

{code}
[domain at localhost:9990 /] :whoami(verbose=true)
{
    "outcome" => "success",
    "result" => {
        "identity" => {
            "username" => "$local",
            "realm" => "ManagementRealm"
        },
        "mapped-roles" => [
            "SUPERUSER",
            "OPERATOR"
        ]
    }
}
{code}

This indicates something messed up regarding the shared config in domain mode.
                
> include-all role mappings don't work in domain
> ----------------------------------------------
>
>                 Key: WFLY-2216
>                 URL: https://issues.jboss.org/browse/WFLY-2216
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Ladislav Thon
>            Assignee: Darran Lofthouse
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.Beta1
>
>
> If I understand correctly, roles that have {{include-all=true}} in their role mappings should be added to all authenticated users. In my tests, though, this only works in standalone mode.
> In domain mode, if I set a role mapping to {{include-all}}, this setting is not reflected (at least not immediately; maybe it would work after restart, but that's wrong anyway). It doesn't matter which role is set to be {{include-all}} -- in my tests, I use both standard roles and scoped roles and it consistently doesn't work. There's probably some wrong caching going on.
> The failing test case is in my pull request https://github.com/wildfly/wildfly/pull/5166 (it's the _RBAC tests for include-all role mappings in domain_ commit). If it's more convenient, the pull request is the same as my _rbac_ branch (https://github.com/Ladicek/wildfly/commits/rbac).
> Darran, I'm not sure if you are the right assignee -- please reassign if needed. Thanks.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 12:25:02 2013
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Fri, 4 Oct 2013 12:25:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1948)
 java.lang.IllegalStateException: Destination queue.ISXO_AuditLogQueue_01
 not active after MessagingClusterHealthMBean restart JMS service
In-Reply-To: <JIRA.12502101.1380799169000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502101.1380799169000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502101.1380799169000.14347.1380903902627@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated JBMESSAGING-1948:
-----------------------------------------

    Assignee: Yong Hao Gao

    
> java.lang.IllegalStateException: Destination queue.ISXO_AuditLogQueue_01 not active after MessagingClusterHealthMBean restart JMS service
> -----------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1948
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1948
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.8.SP9
>            Reporter: Flemming Harms
>            Assignee: Yong Hao Gao
>         Attachments: ConnectionFactory-diff.patch, postoffice-patch.diff
>
>
> I get this error ?java.lang.IllegalStateException: Destination queue.ISXO_AuditLogQueue_01 not active? after MessagingClusterHealthMBean restarts the JMS service with JBoss Messaging 1.4.8.SP9. 
> I have 2 node JBoss5 cluster with JBoss Messaging and I have enabled the new failover model and setup the MessagingClusterHealthMBean to monitor split brain.
> I disconnect the cable from one of the servers MessagingClusterHealthMBean discover it?s alone and shut down the JMS service as expected. After a while I connect the server again and the server discover the other server and MessagingClusterHealthMBean starts the JMS service also as expected.
> But when I connect a client it fails with ?java.lang.IllegalStateException: Destination queue.ISXO_AuditLogQueue_01 not active? and what I can see in the debugger ServerConnectionEndpoint have reference to the old post office where the queue is still exits in the inactiveConditions Set.
> Log from the server when it discover it?s alone and it restart the service again
> 2013-09-07 21:29:06,381 ERROR [org.jboss.messaging.core.impl.postoffice.MessagingPostOffice] (Thread-32) I'm orphaned and now I can't tell others that I'm alive. Shutdown node: 102
> 2013-09-07 21:29:09,728 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-32) Stopping JBM node on DB failure...
> 2013-09-07 21:29:09,731 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-32) Queue[/queue/ExpiryQueue] stopped
> 2013-09-07 21:29:09,732 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-32) Queue[/queue/DLQ] stopped
> 2013-09-07 21:29:09,733 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-32) Queue[/ISXO/AuditLogQueue, name=ISXO_AuditLogQueue_01] stopped
> 2013-09-07 21:29:09,733 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-32) Queue[/ISXO/CiscoUCSEventQueue, name=ISXO_CiscoUCSEventQueue_01] stopped
> 2013-09-07 21:29:09,738 INFO  [org.jboss.jms.server.destination.TopicService] (Thread-32) Topic[/ISXO/RemoteEventTopic, name=ISXO_RemoteEventQueue_01] stopped
> 2013-09-07 21:29:09,739 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-32) Queue[/ISXO/ScheduledJobQueue, name=ISXO_ScheduledJobQueue_01] stopped
> 2013-09-07 21:29:11,210 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-32) org.jboss.jms.server.connectionfactory.ConnectionFactory at 366480d7 undeployed
> 2013-09-07 21:29:11,216 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-32) org.jboss.jms.server.connectionfactory.ConnectionFactory at 467463b3 undeployed
> 2013-09-07 21:29:11,216 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-32) org.jboss.jms.server.connectionfactory.ConnectionFactory at 21fdb35f undeployed
> 2013-09-07 21:29:11,216 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-32) org.jboss.jms.server.connectionfactory.ConnectionFactory at 443578f2 undeployed
> 2013-09-07 21:29:11,235 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-32) org.jboss.jms.server.connectionfactory.ConnectionFactory at ecdede5 undeployed
> 2013-09-07 21:29:11,298 ERROR [org.jgroups.blocks.ConnectionTable] (OOB-43,192.168.56.102:7900) failed sending data to 192.168.56.101:7900: java.net.SocketException: Socket closed
> 2013-09-07 21:29:14,413 WARN  [org.jgroups.protocols.pbcast.NAKACK] (OOB-19,192.168.56.102:55200) 192.168.56.102:55200] discarded message from non-member 192.168.56.101:55200, my view is [192.168.56.102
> 2013-09-07 21:29:14,863 WARN  [org.jgroups.protocols.pbcast.NAKACK] (OOB-19,192.168.56.102:55200) 192.168.56.102:55200] discarded message from non-member 192.168.56.101:55200, my view is [192.168.56.102
> 2013-09-07 21:29:21,080 INFO  [org.jboss.jms.server.ServerPeer] (Thread-32) JMS ServerPeer[102] stopped
> 2013-09-07 21:29:21,090 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-32) JBM node is stopped.
> 2013-09-07 21:29:21,090 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] (Incoming-2,192.168.56.102:55200) Dead members: 1 ([192.168.56.101:55200])
> 2013-09-07 21:29:21,090 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] (Incoming-2,192.168.56.102:55200) All Members : 1 ([192.168.56.102:55200])
> 2013-09-07 21:30:24,666 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Restarting JBM node...
> 2013-09-07 21:30:33,369 INFO  [org.jboss.jms.server.ServerPeer] (Thread-75) JBoss Messaging 1.4.8.SP9 server [102] started
> 2013-09-07 21:30:33,459 INFO  [STDOUT] (Thread-75) 
> ---------------------------------------------------------
> GMS: address is 192.168.56.102:55200 (cluster=DefaultPartition-JMS-CTRL)
> ---------------------------------------------------------
> 2013-09-07 21:30:33,524 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] (Thread-75) org.jboss.messaging.core.impl.postoffice.GroupMember$ControlMembershipListener at 6a500238 got new view [192
> 2013-09-07 21:30:33,525 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] (Thread-75) I am (192.168.56.102:55200)
> 2013-09-07 21:30:33,525 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] (Thread-75) New Members : 2 ([192.168.56.101:55200, 192.168.56.102:55200])
> 2013-09-07 21:30:33,525 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] (Thread-75) All Members : 2 ([192.168.56.101:55200, 192.168.56.102:55200])
> 2013-09-07 21:30:33,570 INFO  [STDOUT] (pool-151-thread-1) 
> ---------------------------------------------------------
> GMS: address is 192.168.56.102:7900 (cluster=DefaultPartition-JMS-DATA)
> ---------------------------------------------------------
> 2013-09-07 21:30:33,779 INFO  [org.jboss.messaging.core.impl.postoffice.MessagingPostOffice] (Thread-75) Waiting for JGroups...
> 2013-09-07 21:30:33,784 INFO  [org.jboss.messaging.core.impl.postoffice.MessagingPostOffice] (Thread-75) JGroups starts to work again, initializing state
> 2013-09-07 21:30:33,785 INFO  [org.jboss.messaging.core.impl.postoffice.MessagingPostOffice] (Thread-75) Now node is ready for work.
> 2013-09-07 21:30:34,896 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) Connector sslbisocket://192.168.56.102:4459 has leasing enabled, lease period 25000 milliseconds
> 2013-09-07 21:30:34,896 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered connection factory jboss.messaging.connectionfactory:service=SSLConnectionFactory
> 2013-09-07 21:30:34,896 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) org.jboss.jms.server.connectionfactory.ConnectionFactory at 366480d7 started
> 2013-09-07 21:30:36,797 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) Connector bisocket://192.168.56.102:4457 has leasing enabled, lease period 25000 milliseconds
> 2013-09-07 21:30:36,797 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered connection factory jboss.messaging.connectionfactory:service=ConnectionFactory
> 2013-09-07 21:30:36,797 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) org.jboss.jms.server.connectionfactory.ConnectionFactory at 467463b3 started
> 2013-09-07 21:30:37,207 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) Connector servlet://192.168.56.102:8080 has leasing enabled, lease period 25000 milliseconds
> 2013-09-07 21:30:37,207 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered connection factory jboss.messaging.connectionfactory:service=ServletConnectionFactory
> 2013-09-07 21:30:37,207 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) org.jboss.jms.server.connectionfactory.ConnectionFactory at 21fdb35f started
> 2013-09-07 21:30:37,440 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) Connector bisocket://192.168.56.102:4457 has leasing enabled, lease period 25000 milliseconds
> 2013-09-07 21:30:37,441 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered connection factory jboss.messaging.connectionfactory:service=ClusteredConnectionFactory
> 2013-09-07 21:30:37,441 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) org.jboss.jms.server.connectionfactory.ConnectionFactory at 443578f2 started
> 2013-09-07 21:30:41,483 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) Connector bisocket://192.168.56.102:4457 has leasing enabled, lease period 25000 milliseconds
> 2013-09-07 21:30:41,483 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered connection factory jboss.messaging.connectionfactory:service=ClusterPullConnectionFactory
> 2013-09-07 21:30:41,483 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) org.jboss.jms.server.connectionfactory.ConnectionFactory at ecdede5 started
> 2013-09-07 21:30:41,483 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered destination jboss.messaging.destination:service=Queue,name=ExpiryQueue
> 2013-09-07 21:30:41,715 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-75) Queue[/queue/ExpiryQueue] started, fullSize=200000, pageSize=2000, downCacheSize=2000
> 2013-09-07 21:30:41,715 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered destination jboss.messaging.destination:service=Queue,name=DLQ
> 2013-09-07 21:30:42,259 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-75) Queue[/queue/DLQ] started, fullSize=200000, pageSize=2000, downCacheSize=2000
> 2013-09-07 21:30:42,259 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered destination jboss.messaging.destination:service=Queue,name=ISXO_AuditLogQueue_01
> 2013-09-07 21:30:42,495 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-75) Queue[/ISXO/AuditLogQueue, name=ISXO_AuditLogQueue_01] started, fullSize=200000, pageSize=2000, downCacheSize=20
> 2013-09-07 21:30:42,495 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered destination jboss.messaging.destination:service=Queue,name=ISXO_CiscoUCSEventQueue_01
> 2013-09-07 21:30:42,923 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-75) Queue[/ISXO/CiscoUCSEventQueue, name=ISXO_CiscoUCSEventQueue_01] started, fullSize=200000, pageSize=2000, downCa
> 2013-09-07 21:30:42,923 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered destination jboss.messaging.destination:service=Topic,name=ISXO_RemoteEventQueue_01
> 2013-09-07 21:30:43,122 INFO  [org.jboss.jms.server.destination.TopicService] (Thread-75) Topic[/ISXO/RemoteEventTopic, name=ISXO_RemoteEventQueue_01] started, fullSize=200000, pageSize=2000, downCacheS
> 2013-09-07 21:30:43,122 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered destination jboss.messaging.destination:service=Queue,name=ISXO_ScheduledJobQueue_01
> 2013-09-07 21:30:43,559 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-75) Queue[/ISXO/ScheduledJobQueue, name=ISXO_ScheduledJobQueue_01] started, fullSize=200000, pageSize=2000, downCach
> 2013-09-07 21:30:43,559 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) JBM node restarted.
> Stack trace the ?java.lang.IllegalStateException: Destination queue.ISXO_AuditLogQueue_01 not active?
> Daemon Thread [ISXOSchedulerPrioritized_Worker-1] (Suspended (breakpoint at line 3046 in MessagingPostOffice))	
> 	owns: AtomicAction  (id=519)	
> 	MessagingPostOffice.routeInternal(MessageReference, Condition, Transaction, boolean, Set) line: 3046	
> 	MessagingPostOffice.route(MessageReference, Condition, Transaction) line: 983	
> 	ServerConnectionEndpoint.sendMessage(JBossMessage, Transaction, boolean) line: 796	
> 	ServerConnectionEndpoint.processTransaction(ClientTransaction, Transaction, boolean) line: 852	
> 	ServerConnectionEndpoint.sendTransaction(TransactionRequest, boolean) line: 516	
> 	ConnectionAdvised.org$jboss$jms$server$endpoint$advised$ConnectionAdvised$sendTransaction$aop(TransactionRequest, boolean) line: 106	
> 	ConnectionAdvised$sendTransaction_N3268650789275322226.invokeTarget() line: not available	
> 	ConnectionAdvised$sendTransaction_N3268650789275322226(MethodInvocation).invokeNext() line: 111	
> 	SecurityAspect.handleSendTransaction(Invocation) line: 200	
> 	NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]	
> 	NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39	
> 	DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25	
> 	Method.invoke(Object, Object...) line: 597	
> 	PerInstanceAdvice.invoke(Invocation) line: 122	
> 	ConnectionAdvised$sendTransaction_N3268650789275322226(MethodInvocation).invokeNext() line: 102	
> 	ServerLogInterceptor.invoke(Invocation) line: 105	
> 	ConnectionAdvised$sendTransaction_N3268650789275322226(MethodInvocation).invokeNext() line: 102	
> 	ConnectionAdvised.sendTransaction(TransactionRequest, boolean) line: not available	
> 	ConnectionSendTransactionRequest.serverInvoke() line: 86	
> 	JMSServerInvocationHandler.invoke(InvocationRequest) line: 165	
> 	BisocketServerInvoker(ServerInvoker).invoke(InvocationRequest) line: 930	
> 	LocalClientInvoker.invoke(InvocationRequest) line: 106	
> 	Client.invoke(Object, Map, InvokerLocator) line: 2034	
> 	Client.invoke(Object, Map) line: 877	
> 	Client.invoke(Object) line: 865	
> 	ClientConnectionDelegate(DelegateSupport).doInvoke(Client, RequestSupport, boolean) line: 189	
> 	ClientConnectionDelegate(DelegateSupport).doInvoke(Client, RequestSupport) line: 160	
> 	ClientConnectionDelegate.org$jboss$jms$client$delegate$ClientConnectionDelegate$sendTransaction$aop(TransactionRequest, boolean) line: 241	
> 	ClientConnectionDelegate$sendTransaction_N3268650789275322226.invokeTarget() line: not available	
> 	ClientConnectionDelegate$sendTransaction_N3268650789275322226(MethodInvocation).invokeNext() line: 111	
> 	FailoverValveInterceptor.invoke(Invocation) line: 92	
> 	PerInstanceInterceptor.invoke(Invocation) line: 86	
> 	ClientConnectionDelegate$sendTransaction_N3268650789275322226(MethodInvocation).invokeNext() line: 102	
> 	ClosedInterceptor.invoke(Invocation) line: 172	
> 	PerInstanceInterceptor.invoke(Invocation) line: 86	
> 	ClientConnectionDelegate$sendTransaction_N3268650789275322226(MethodInvocation).invokeNext() line: 102	
> 	ClientConnectionDelegate.sendTransaction(TransactionRequest, boolean) line: not available	
> 	ResourceManager.sendTransactionXA(TransactionRequest, ConnectionDelegate) line: 712	
> 	ResourceManager.commit(Xid, boolean, ConnectionDelegate) line: 392	
> 	MessagingXAResource.commit(Xid, boolean) line: 275	
> 	JmsXAResource.commit(Xid, boolean) line: 98	
> 	XAResourceRecord.topLevelOnePhaseCommit() line: 811	
> 	AtomicAction(BasicAction).onePhaseCommit(boolean) line: 2656	
> 	AtomicAction(BasicAction).End(boolean) line: 1784	
> 	AtomicAction(TwoPhaseCoordinator).end(boolean) line: 94	
> 	AtomicAction(AtomicAction).commit(boolean) line: 160	
> 	TransactionImple.commitAndDisassociate() line: 1431	
> 	TransactionManagerImple(BaseTransaction).commit() line: 137	
> 	TransactionManagerDelegate(BaseTransactionManagerDelegate).commit() line: 75	
> 	Ejb3TxPolicy(TxPolicy).endTransaction(TransactionManager, Transaction) line: 170	
> 	Ejb3TxPolicy(TxPolicy).invokeInOurTx(Invocation, TransactionManager) line: 87	
> 	TxInterceptor$Required.invoke(Invocation) line: 190	
> 	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
> 	TxPropagationInterceptor.invoke(Invocation) line: 76	
> 	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
> 	NullInterceptor.invoke(Invocation) line: 42	
> 	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
> 	Ejb3AuthenticationInterceptorv2.invoke(Invocation) line: 182	
> 	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
> 	ENCPropagationInterceptor.invoke(Invocation) line: 41	
> 	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
> 	BlockContainerShutdownInterceptor.invoke(Invocation) line: 67	
> 	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
> 	CurrentInvocationContextInterceptor.invoke(Invocation) line: 47	
> 	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
> 	CurrentInvocationInterceptor.invoke(Invocation) line: 67	
> 	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
> 	EJB3TCCLInterceptor.invoke(Invocation) line: 86	
> 	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
> 	StatelessContainer(SessionSpecContainer).invoke(Serializable, SerializableMethod, Object[]) line: 193	
> 	StatelessContainer(SessionSpecContainer).invoke(Object, SerializableMethod, Object[]) line: 250	
> 	SessionLocalProxyInvocationHandler(SessionProxyInvocationHandlerBase).invoke(Object, Method, Object[]) line: 188	
> 	$Proxy702.publishMessages(EventSet) line: not available	
> 	NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]	
> 	NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39	
> 	DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25	
> 	Method.invoke(Object, Object...) line: 597	
> 	ClusteredEJB3InvokerJob(EJB3InvokerJob).invokeEjb(Object, JobExecutionContext) line: 196	
> 	ClusteredEJB3InvokerJob(EJB3InvokerJob).doExecute(JobExecutionContext) line: 141	
> 	ClusteredEJB3InvokerJob(EJB3InvokerJob).execute(JobExecutionContext) line: 78	
> 	JobRunShell.run() line: 203	
> 	SimpleThreadPool$WorkerThread.run() line: 520
> Update
> ========
> After debugging the code to understand what is going on I'm pretty sure we have situation where it use an old ServerConnectionEndpoint with a old postoffice instance. In our case we have a bean(stateless) that inject the TopicConnectionFactory and and Topic as resource this could possible reuse an old connection?
> I can see that sometimes it get an instance of ServerConnectionEndpoint which contains a reference to the current server peer and to the old post office. The server peer instance actual holde the reference to the new post office, but because the postoffice variable is only set on constructor level this is never changed. 
> Furthermore I can see the start method in ConnectionFactory was creating a listener that listens for failed connections, but this was not removed when the service stopped. After I removed the listener when the ConnectionFactory is stopped,  and restarted i'm able to receive updates again and it does not fail with a  "java.lang.IllegalStateException: Destination queue.MyQueue not active"

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Fri Oct  4 12:34:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Oct 2013 12:34:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2216) include-all role mappings
 don't work in domain
In-Reply-To: <JIRA.12502198.1380887272000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502198.1380887272000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502198.1380887272000.14357.1380904442951@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809528#comment-12809528 ] 

RH Bugzilla Integration commented on WFLY-2216:
-----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> changed the Status of [bug 1015493|https://bugzilla.redhat.com/show_bug.cgi?id=1015493] from NEW to ASSIGNED
                
> include-all role mappings don't work in domain
> ----------------------------------------------
>
>                 Key: WFLY-2216
>                 URL: https://issues.jboss.org/browse/WFLY-2216
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Ladislav Thon
>            Assignee: Darran Lofthouse
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.Beta1
>
>
> If I understand correctly, roles that have {{include-all=true}} in their role mappings should be added to all authenticated users. In my tests, though, this only works in standalone mode.
> In domain mode, if I set a role mapping to {{include-all}}, this setting is not reflected (at least not immediately; maybe it would work after restart, but that's wrong anyway). It doesn't matter which role is set to be {{include-all}} -- in my tests, I use both standard roles and scoped roles and it consistently doesn't work. There's probably some wrong caching going on.
> The failing test case is in my pull request https://github.com/wildfly/wildfly/pull/5166 (it's the _RBAC tests for include-all role mappings in domain_ commit). If it's more convenient, the pull request is the same as my _rbac_ branch (https://github.com/Ladicek/wildfly/commits/rbac).
> Darran, I'm not sure if you are the right assignee -- please reassign if needed. Thanks.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 12:38:02 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Fri, 4 Oct 2013 12:38:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-286) Sliding Windows do not
 discard events correctly when used with entry-points
In-Reply-To: <JIRA.12502243.1380904617621@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502243.1380904617621@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502243.1380904617621.14362.1380904682633@jira02.app.mwc.hst.phx2.redhat.com>

Davide Sottara created DROOLS-286:
-------------------------------------

             Summary: Sliding Windows do not discard events correctly when used with entry-points
                 Key: DROOLS-286
                 URL: https://issues.jboss.org/browse/DROOLS-286
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 5.5.0.Final
            Reporter: Davide Sottara
            Assignee: Mark Proctor
            Priority: Critical
             Fix For: 5.5.1.Final




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 12:38:02 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Fri, 4 Oct 2013 12:38:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-286) Sliding Windows do not
 discard events correctly when used with entry-points
In-Reply-To: <JIRA.12502243.1380904617000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502243.1380904617000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502243.1380904617000.14367.1380904682912@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809529#comment-12809529 ] 

Davide Sottara commented on DROOLS-286:
---------------------------------------

Already fixed in 5.6
                
> Sliding Windows do not discard events correctly when used with entry-points
> ---------------------------------------------------------------------------
>
>                 Key: DROOLS-286
>                 URL: https://issues.jboss.org/browse/DROOLS-286
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Davide Sottara
>            Assignee: Mark Proctor
>            Priority: Critical
>             Fix For: 5.5.1.Final
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 12:51:02 2013
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Fri, 4 Oct 2013 12:51:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1871) CLI module command doesn't
 allow cross platform resource paths
In-Reply-To: <JIRA.12498510.1376412050000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498510.1376412050000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498510.1376412050000.14373.1380905462602@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stan Silvert updated WFLY-1871:
-------------------------------

    Git Pull Request: https://github.com/wildfly/wildfly/pull/4915, https://github.com/wildfly/wildfly/pull/5219  (was: https://github.com/wildfly/wildfly/pull/4915)

    
> CLI module command doesn't allow cross platform resource paths
> --------------------------------------------------------------
>
>                 Key: WFLY-1871
>                 URL: https://issues.jboss.org/browse/WFLY-1871
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Stan Silvert
>            Assignee: Stan Silvert
>             Fix For: 8.0.0.Beta1
>
>
> The CLI module command has an argument called "resources".  This argument allows you to specify one or more resources separated by the platform-specific path separator.  The problem with this is that you can not create a platform-independent script that uses this resources argument.
> I have not found a universal path separator character that would work.  However, since the creator of the script knows the characters used in his path, we can allow him to specify his own separator.
> As an enhancement, I propose to add an argument called "resourceDelimiter".  If present, the ASModuleHandler class will use the user-defined delimiter instead of the platform-specific path separator character.
> Example usage:
> {noformat}
> module add --name=org.foo --resources=firstResource.jar:secondResource.jar --resourceDelimiter=: --module-xml=foo-module.xml
> {noformat}
> The above command would work on Unix, Windows, or any other platform.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 12:59:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Fri, 4 Oct 2013 12:59:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-260) Drools not writing calendars
 when marshalling
In-Reply-To: <JIRA.12500709.1379130683000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500709.1379130683000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500709.1379130683000.14394.1380905942768@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-260.
--------------------------------

    Fix Version/s: 6.0.0.CR5
       Resolution: Done

    
> Drools not writing calendars when marshalling
> ---------------------------------------------
>
>                 Key: DROOLS-260
>                 URL: https://issues.jboss.org/browse/DROOLS-260
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Demian Calcaprina
>            Assignee: Mario Fusco
>             Fix For: 6.0.0.CR5
>
>
> When serializing Rule class, https://github.com/droolsjbpm/drools/blob/5.5.x/drools-core/src/main/java/org/drools/rule/Rule.java#L122, the write and read external methods does not write and read calendars properties.
> This causes that, if there is a rule which has a calendar in guvnor, for example,
> rule "CalendarTest"
> 		calendars "my cal"
> 		no-loop true
> 		dialect "mvel"
> 		when
> 		then
> 	    	System.out.println("CALENDAR IS FIRIUNG!!!");
> 	end
> when rule is retrieved, calendars are not took into account.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 12:59:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Oct 2013 12:59:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-260) Drools not writing calendars
 when marshalling
In-Reply-To: <JIRA.12500709.1379130683000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500709.1379130683000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500709.1379130683000.14406.1380905943273@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated DROOLS-260:
-------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1007385

    
> Drools not writing calendars when marshalling
> ---------------------------------------------
>
>                 Key: DROOLS-260
>                 URL: https://issues.jboss.org/browse/DROOLS-260
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Demian Calcaprina
>            Assignee: Mario Fusco
>             Fix For: 6.0.0.CR5
>
>
> When serializing Rule class, https://github.com/droolsjbpm/drools/blob/5.5.x/drools-core/src/main/java/org/drools/rule/Rule.java#L122, the write and read external methods does not write and read calendars properties.
> This causes that, if there is a rule which has a calendar in guvnor, for example,
> rule "CalendarTest"
> 		calendars "my cal"
> 		no-loop true
> 		dialect "mvel"
> 		when
> 		then
> 	    	System.out.println("CALENDAR IS FIRIUNG!!!");
> 	end
> when rule is retrieved, calendars are not took into account.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 13:01:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Oct 2013 13:01:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-260) Drools not writing calendars
 when marshalling
In-Reply-To: <JIRA.12500709.1379130683000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500709.1379130683000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500709.1379130683000.14410.1380906062537@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809536#comment-12809536 ] 

RH Bugzilla Integration commented on DROOLS-260:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> made a comment on [bug 1007385|https://bugzilla.redhat.com/show_bug.cgi?id=1007385]

I couldn't reproduce this issue on the master. Very likely it was related by this issue:

https://issues.jboss.org/browse/DROOLS-260

that has been fixed with this commit:

https://github.com/droolsjbpm/drools/commit/39276fea9209353bf3704663da0b03ef934cc908
                
> Drools not writing calendars when marshalling
> ---------------------------------------------
>
>                 Key: DROOLS-260
>                 URL: https://issues.jboss.org/browse/DROOLS-260
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Demian Calcaprina
>            Assignee: Mario Fusco
>             Fix For: 6.0.0.CR5
>
>
> When serializing Rule class, https://github.com/droolsjbpm/drools/blob/5.5.x/drools-core/src/main/java/org/drools/rule/Rule.java#L122, the write and read external methods does not write and read calendars properties.
> This causes that, if there is a rule which has a calendar in guvnor, for example,
> rule "CalendarTest"
> 		calendars "my cal"
> 		no-loop true
> 		dialect "mvel"
> 		when
> 		then
> 	    	System.out.println("CALENDAR IS FIRIUNG!!!");
> 	end
> when rule is retrieved, calendars are not took into account.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 13:01:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Oct 2013 13:01:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-260) Drools not writing calendars
 when marshalling
In-Reply-To: <JIRA.12500709.1379130683000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500709.1379130683000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500709.1379130683000.14414.1380906062734@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809537#comment-12809537 ] 

RH Bugzilla Integration commented on DROOLS-260:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> changed the Status of [bug 1007385|https://bugzilla.redhat.com/show_bug.cgi?id=1007385] from ASSIGNED to MODIFIED
                
> Drools not writing calendars when marshalling
> ---------------------------------------------
>
>                 Key: DROOLS-260
>                 URL: https://issues.jboss.org/browse/DROOLS-260
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Demian Calcaprina
>            Assignee: Mario Fusco
>             Fix For: 6.0.0.CR5
>
>
> When serializing Rule class, https://github.com/droolsjbpm/drools/blob/5.5.x/drools-core/src/main/java/org/drools/rule/Rule.java#L122, the write and read external methods does not write and read calendars properties.
> This causes that, if there is a rule which has a calendar in guvnor, for example,
> rule "CalendarTest"
> 		calendars "my cal"
> 		no-loop true
> 		dialect "mvel"
> 		when
> 		then
> 	    	System.out.println("CALENDAR IS FIRIUNG!!!");
> 	end
> when rule is retrieved, calendars are not took into account.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 13:03:03 2013
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Fri, 4 Oct 2013 13:03:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (LOGTOOL-76) JBoss Logging Processor
 should support WSDLException
In-Reply-To: <JIRA.12501542.1380131461000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501542.1380131461000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501542.1380131461000.14420.1380906183040@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/LOGTOOL-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809539#comment-12809539 ] 

James Perkins commented on LOGTOOL-76:
--------------------------------------

Looking at the code this won't quite work. Mainly because of the way the exception constructor signature is defined. The code generator assumes the first string type in the constructor is the message. In the case of a {{WSDLException}} the first constructor parameter seems to be the code. I'm not sure whether it's worth exploring the ability to express more meta data about a constructor or now.

For now the only solution would be for the message to be returned as a string type then create the exception manually.

{code:java}
/**
 * couldNotFindServiceInTheWSDL method definition.
 * @param portName the portName
 * @param definitionDocumentBaseURI definitionDocumentBaseURI
 * @return the error message
 */
@Message(id = 35436, value = "Could not find service %s in the WSDL %s")
String couldNotFindServiceInTheWSDL(String portName, String definitionDocumentBaseURI);
{code}

Then create the exception something like:

{code:java}
throw new WSDLException(faultCode, MESSAGES.couldNotFindServiceInTheWSDL(portName, definitionDocumentBaseURI);
{code}
                
> JBoss Logging Processor should support WSDLException
> ----------------------------------------------------
>
>                 Key: LOGTOOL-76
>                 URL: https://issues.jboss.org/browse/LOGTOOL-76
>             Project: Log Tool
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Tom Cunningham
>            Assignee: David Lloyd
>
> This is a jboss-logging-processor issue - javax.wsdl.WSDLException has constructors :
> public WSDLException(java.lang.String faultCode,
>                      java.lang.String msg,
>                      java.lang.Throwable t)
> public WSDLException(java.lang.String faultCode,
>                      java.lang.String msg)
> When I try to localize with this :
>     /**
>      * couldNotFindServiceInTheWSDL method definition.
>      * @param portName the portName
>      * @param definitionDocumentBaseURI definitionDocumentBaseURI
>      * @return WSDLException
>      */
>     @Message(id = 35436, value = "Could not find service %s in the WSDL %s")
>     WSDLException couldNotFindServiceInTheWSDL(String portName, String definitionDocumentBaseURI);
> I see compilation errors because jboss-logging-processor doesn't know how to support the WSDLException constructors.    We should support them.
> Failure:
> [ERROR] /Users/tcunning/src/switchyard/cunningt/components/soap/src/main/java/org/switchyard/component/soap/SOAPMessages.java:[189,18] MessageMethod does not have an usable constructor for the return type javax.wsdl.WSDLException.
> [ERROR] /Users/tcunning/src/switchyard/cunningt/components/soap/src/main/java/org/switchyard/component/soap/SOAPMessages.java:[197,18] MessageMethod does not have an usable constructor for the return type javax.wsdl.WSDLException.
> [ERROR] /Users/tcunning/src/switchyard/cunningt/components/soap/src/main/java/org/switchyard/component/soap/SOAPMessages.java:[206,18] MessageMethod does not have an usable constructor for the return type javax.wsdl.WSDLException.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 13:32:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Oct 2013 13:32:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2216) include-all role mappings
 don't work in domain
In-Reply-To: <JIRA.12502198.1380887272000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502198.1380887272000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502198.1380887272000.14450.1380907922801@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809545#comment-12809545 ] 

RH Bugzilla Integration commented on WFLY-2216:
-----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> changed the Status of [bug 1015493|https://bugzilla.redhat.com/show_bug.cgi?id=1015493] from ASSIGNED to POST
                
> include-all role mappings don't work in domain
> ----------------------------------------------
>
>                 Key: WFLY-2216
>                 URL: https://issues.jboss.org/browse/WFLY-2216
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Ladislav Thon
>            Assignee: Darran Lofthouse
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.Beta1
>
>
> If I understand correctly, roles that have {{include-all=true}} in their role mappings should be added to all authenticated users. In my tests, though, this only works in standalone mode.
> In domain mode, if I set a role mapping to {{include-all}}, this setting is not reflected (at least not immediately; maybe it would work after restart, but that's wrong anyway). It doesn't matter which role is set to be {{include-all}} -- in my tests, I use both standard roles and scoped roles and it consistently doesn't work. There's probably some wrong caching going on.
> The failing test case is in my pull request https://github.com/wildfly/wildfly/pull/5166 (it's the _RBAC tests for include-all role mappings in domain_ commit). If it's more convenient, the pull request is the same as my _rbac_ branch (https://github.com/Ladicek/wildfly/commits/rbac).
> Darran, I'm not sure if you are the right assignee -- please reassign if needed. Thanks.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 13:50:02 2013
From: jira-events at lists.jboss.org (Matt Fluet (JIRA))
Date: Fri, 4 Oct 2013 13:50:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2222) SecurityExceptions when
 starting server with signed jars in an exploded app deployment
In-Reply-To: <JIRA.12502248.1380908971224@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502248.1380908971224@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502248.1380908971224.14463.1380909002883@jira02.app.mwc.hst.phx2.redhat.com>

Matt Fluet created WFLY-2222:
--------------------------------

             Summary: SecurityExceptions when starting server with signed jars in an exploded app deployment
                 Key: WFLY-2222
                 URL: https://issues.jboss.org/browse/WFLY-2222
             Project: WildFly
          Issue Type: Bug
          Components: Class Loading
            Reporter: Matt Fluet
            Assignee: David Lloyd
            Priority: Critical


This issue is directly related to https://issues.jboss.org/browse/AS7-2724, where signed jars are sometimes throwing a security exception when the server starts up and then classes cannot be loaded out of certain packages (appears to be some sort of a concurrency issue).  

The fix for that issue was applied to JarFileResourceLoader here:  https://github.com/jboss-modules/jboss-modules/commit/8cf33f5c02c0c4bf6f96d04efa8845762bbc90ae

However, our application is exploded, so the VFSResourceLoader needs a similar fix.  I will attach a git patch file with the change we're proposing.

To test the theory, we applied the patch to one server and left another as is as a control...we then left a process running that continually restarted the server for 3 days.  The control server hit the SecurityException problem 5 times, and the patched server didn't show it at all.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 13:52:02 2013
From: jira-events at lists.jboss.org (Matt Fluet (JIRA))
Date: Fri, 4 Oct 2013 13:52:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2222) SecurityExceptions when
 starting server with signed jars in an exploded app deployment
In-Reply-To: <JIRA.12502248.1380908971000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502248.1380908971000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502248.1380908971000.14466.1380909122584@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Fluet updated WFLY-2222:
-----------------------------

    Attachment: 0001-Fix-ClassLoader-SecurityException-with-jar-certifica.patch


Attaching a patch file with the fix for the VFSResourceLoader problem
                
> SecurityExceptions when starting server with signed jars in an exploded app deployment
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-2222
>                 URL: https://issues.jboss.org/browse/WFLY-2222
>             Project: WildFly
>          Issue Type: Bug
>          Components: Class Loading
>            Reporter: Matt Fluet
>            Assignee: David Lloyd
>            Priority: Critical
>         Attachments: 0001-Fix-ClassLoader-SecurityException-with-jar-certifica.patch
>
>
> This issue is directly related to https://issues.jboss.org/browse/AS7-2724, where signed jars are sometimes throwing a security exception when the server starts up and then classes cannot be loaded out of certain packages (appears to be some sort of a concurrency issue).  
> The fix for that issue was applied to JarFileResourceLoader here:  https://github.com/jboss-modules/jboss-modules/commit/8cf33f5c02c0c4bf6f96d04efa8845762bbc90ae
> However, our application is exploded, so the VFSResourceLoader needs a similar fix.  I will attach a git patch file with the change we're proposing.
> To test the theory, we applied the patch to one server and left another as is as a control...we then left a process running that continually restarted the server for 3 days.  The control server hit the SecurityException problem 5 times, and the patched server didn't show it at all.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 14:15:03 2013
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Fri, 4 Oct 2013 14:15:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBASMP-52) jboss-as:deploy deploys ear
 but doesn't deploy contained ejb module
In-Reply-To: <JIRA.12502059.1380753826000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502059.1380753826000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502059.1380753826000.14507.1380910503714@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBASMP-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809558#comment-12809558 ] 

James Perkins commented on JBASMP-52:
-------------------------------------

Where do you have the jboss-as-maven-plugin defined? In the EAR POM?
                
> jboss-as:deploy deploys ear but doesn't deploy contained ejb module
> -------------------------------------------------------------------
>
>                 Key: JBASMP-52
>                 URL: https://issues.jboss.org/browse/JBASMP-52
>             Project: JBoss AS Maven Plugins
>          Issue Type: Bug
>          Components: deploy
>    Affects Versions: 7.4.Final
>         Environment: Linux hostname 3.7.10-gentoo #1 SMP Fri Aug 30 17:01:59 ART 2013 x86_64 Intel(R) Core(TM) i5-2467M CPU @ 1.60GHz GenuineIntel GNU/Linux
>            Reporter: Mat?as Blasi
>            Assignee: James Perkins
>
> I have a simple ear application (build with maven-ear-plugin).
> This application contains just a persistence-unit definition (persistence.xml) and a ejb-module.
> The ejb module is another maven build, containing some ejb3, handled with maven-ejb-plugin.
> The ear file is correctly built:
> myapp.ear
> |
> + META-INF/application.xml
> + lib/allmylibs.jar
> + myejb.jar
> When trying to deploy the ear with the jboss-as:deploy, the application is deployed (the persistence unit deployment logs in server.log), but no ejb is registered, anyway, no errors in log, and BUILD SUCCESFUL after mvn command.
> Finally, an ear file is present under $JBOSS_HOME/standalone/data/content
> The strange thing is that if I get that generated ear file, I can succesfully deploy it through the management console, or by copying it to a folder scanned by a deployment-scanner (in both cases the ejbs are correctly deployed)
> Nothing found in google! :(
> I tried with all the plugin version from 7.1.1 to 7.4.
> Also a lot of tries with different maven-ear-plugin and maven-jboss-as-plugin configuration options.... no lucky after two days of work.
> Regards,
> Mat?as.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Fri Oct  4 14:40:02 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 4 Oct 2013 14:40:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2222) SecurityExceptions when
 starting server with signed jars in an exploded app deployment
In-Reply-To: <JIRA.12502248.1380908971000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502248.1380908971000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502248.1380908971000.14540.1380912002649@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809562#comment-12809562 ] 

David Lloyd commented on WFLY-2222:
-----------------------------------

Can you try the alternative fix in the last commit of https://github.com/dmlloyd/wildfly/tree/WFLY-2222 which hopefully will solve the same problem but without holding the synch over the duration of the doPrivileged?

Thanks.
                
> SecurityExceptions when starting server with signed jars in an exploded app deployment
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-2222
>                 URL: https://issues.jboss.org/browse/WFLY-2222
>             Project: WildFly
>          Issue Type: Bug
>          Components: Class Loading
>            Reporter: Matt Fluet
>            Assignee: David Lloyd
>            Priority: Critical
>         Attachments: 0001-Fix-ClassLoader-SecurityException-with-jar-certifica.patch
>
>
> This issue is directly related to https://issues.jboss.org/browse/AS7-2724, where signed jars are sometimes throwing a security exception when the server starts up and then classes cannot be loaded out of certain packages (appears to be some sort of a concurrency issue).  
> The fix for that issue was applied to JarFileResourceLoader here:  https://github.com/jboss-modules/jboss-modules/commit/8cf33f5c02c0c4bf6f96d04efa8845762bbc90ae
> However, our application is exploded, so the VFSResourceLoader needs a similar fix.  I will attach a git patch file with the change we're proposing.
> To test the theory, we applied the patch to one server and left another as is as a control...we then left a process running that continually restarted the server for 3 days.  The control server hit the SecurityException problem 5 times, and the patched server didn't show it at all.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 14:49:02 2013
From: jira-events at lists.jboss.org (Eduardo Martins (JIRA))
Date: Fri, 4 Oct 2013 14:49:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2223) Duplicated EE
	ConcurrentContextService
In-Reply-To: <JIRA.12502252.1380912509736@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502252.1380912509736@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502252.1380912509736.14543.1380912542477@jira02.app.mwc.hst.phx2.redhat.com>

Eduardo Martins created WFLY-2223:
-------------------------------------

             Summary: Duplicated EE ConcurrentContextService
                 Key: WFLY-2223
                 URL: https://issues.jboss.org/browse/WFLY-2223
             Project: WildFly
          Issue Type: Feature Request
          Components: EE
            Reporter: Eduardo Martins
            Assignee: Eduardo Martins


When there is a conflict between modules wrt their names, there is a DUP that solves the conflict and sets new name(s) in the EE Module Description, but the problem is that such change is not propagated into ConcurrentContexts, which use such name to compute their MSC service name, meaning the modules in conflict will try to install services with same name, failing the deploy.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 14:51:02 2013
From: jira-events at lists.jboss.org (Eduardo Martins (JIRA))
Date: Fri, 4 Oct 2013 14:51:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2223) EE ConcurrentContextService
	name conflict
In-Reply-To: <JIRA.12502252.1380912509000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502252.1380912509000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502252.1380912509000.14545.1380912662550@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Eduardo Martins updated WFLY-2223:
----------------------------------

    Summary: EE ConcurrentContextService name conflict  (was: Duplicated EE ConcurrentContextService)

    
> EE ConcurrentContextService name conflict
> -----------------------------------------
>
>                 Key: WFLY-2223
>                 URL: https://issues.jboss.org/browse/WFLY-2223
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EE
>            Reporter: Eduardo Martins
>            Assignee: Eduardo Martins
>
> When there is a conflict between modules wrt their names, there is a DUP that solves the conflict and sets new name(s) in the EE Module Description, but the problem is that such change is not propagated into ConcurrentContexts, which use such name to compute their MSC service name, meaning the modules in conflict will try to install services with same name, failing the deploy.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 14:58:02 2013
From: jira-events at lists.jboss.org (Matt Fluet (JIRA))
Date: Fri, 4 Oct 2013 14:58:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2222) SecurityExceptions when
 starting server with signed jars in an exploded app deployment
In-Reply-To: <JIRA.12502248.1380908971000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502248.1380908971000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502248.1380908971000.14548.1380913082562@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809564#comment-12809564 ] 

Matt Fluet commented on WFLY-2222:
----------------------------------

Sure...we will setup our patched server with this alternative fix and let the automated restarts continue over the weekend.  Will report status back here on Monday.
                
> SecurityExceptions when starting server with signed jars in an exploded app deployment
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-2222
>                 URL: https://issues.jboss.org/browse/WFLY-2222
>             Project: WildFly
>          Issue Type: Bug
>          Components: Class Loading
>            Reporter: Matt Fluet
>            Assignee: David Lloyd
>            Priority: Critical
>         Attachments: 0001-Fix-ClassLoader-SecurityException-with-jar-certifica.patch
>
>
> This issue is directly related to https://issues.jboss.org/browse/AS7-2724, where signed jars are sometimes throwing a security exception when the server starts up and then classes cannot be loaded out of certain packages (appears to be some sort of a concurrency issue).  
> The fix for that issue was applied to JarFileResourceLoader here:  https://github.com/jboss-modules/jboss-modules/commit/8cf33f5c02c0c4bf6f96d04efa8845762bbc90ae
> However, our application is exploded, so the VFSResourceLoader needs a similar fix.  I will attach a git patch file with the change we're proposing.
> To test the theory, we applied the patch to one server and left another as is as a control...we then left a process running that continually restarted the server for 3 days.  The control server hit the SecurityException problem 5 times, and the patched server didn't show it at all.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 15:10:02 2013
From: jira-events at lists.jboss.org (=?UTF-8?Q?Mat=C3=ADas_Blasi_=28JIRA=29?=)
Date: Fri, 4 Oct 2013 15:10:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBASMP-52) jboss-as:deploy deploys ear
 but doesn't deploy contained ejb module
In-Reply-To: <JIRA.12502059.1380753826000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502059.1380753826000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502059.1380753826000.14566.1380913802606@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBASMP-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809569#comment-12809569 ] 

Mat?as Blasi commented on JBASMP-52:
------------------------------------

Hi James.
First of all thank you for your support.

The answer is YES.
My ear pom has the jbss-as-maven-plugin defined as follows:

         <plugin>
                <groupId>org.jboss.as.plugins</groupId>
                <artifactId>jboss-as-maven-plugin</artifactId>
                <version>7.4.Final</version>
                <configuration>
                        <name>mercury-ear</name>
                        <force>true</force>
                </configuration>
            </plugin>

And finally, I run:

# mvn jboss-as:deploy in that ear project.
The ear deploy process succeses:

Maven console:

[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
...
[INFO]    task-segment: [jboss-as:deploy]
[INFO] ------------------------------------------------------------------------
...
[INFO] [jboss-as:deploy {execution: default-cli}]
oct 02, 2013 10:57:30 AM org.xnio.Xnio <clinit>
INFO: XNIO Version 3.0.3.GA
oct 02, 2013 10:57:30 AM org.xnio.nio.NioXnio <clinit>
INFO: XNIO NIO Implementation Version 3.0.3.GA
oct 02, 2013 10:57:30 AM org.jboss.remoting3.EndpointImpl <clinit>
INFO: JBoss Remoting version 3.2.3.GA
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 15 seconds
[INFO] Finished at: Wed Oct 02 10:57:35 ART 2013
[INFO] Final Memory: 23M/246M
[INFO] ------------------------------------------------------------------------

Jboss server log:

INFO  [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS018559: Deployed "mercury.ear"
and later executions:
INFO  [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS018565: Replaced deployment "mercury.ear" with deployment "mercury.ear"

But no EJB deployment is triggered in JBoss.

Regards,
Mat?as.
                
> jboss-as:deploy deploys ear but doesn't deploy contained ejb module
> -------------------------------------------------------------------
>
>                 Key: JBASMP-52
>                 URL: https://issues.jboss.org/browse/JBASMP-52
>             Project: JBoss AS Maven Plugins
>          Issue Type: Bug
>          Components: deploy
>    Affects Versions: 7.4.Final
>         Environment: Linux hostname 3.7.10-gentoo #1 SMP Fri Aug 30 17:01:59 ART 2013 x86_64 Intel(R) Core(TM) i5-2467M CPU @ 1.60GHz GenuineIntel GNU/Linux
>            Reporter: Mat?as Blasi
>            Assignee: James Perkins
>
> I have a simple ear application (build with maven-ear-plugin).
> This application contains just a persistence-unit definition (persistence.xml) and a ejb-module.
> The ejb module is another maven build, containing some ejb3, handled with maven-ejb-plugin.
> The ear file is correctly built:
> myapp.ear
> |
> + META-INF/application.xml
> + lib/allmylibs.jar
> + myejb.jar
> When trying to deploy the ear with the jboss-as:deploy, the application is deployed (the persistence unit deployment logs in server.log), but no ejb is registered, anyway, no errors in log, and BUILD SUCCESFUL after mvn command.
> Finally, an ear file is present under $JBOSS_HOME/standalone/data/content
> The strange thing is that if I get that generated ear file, I can succesfully deploy it through the management console, or by copying it to a folder scanned by a deployment-scanner (in both cases the ejbs are correctly deployed)
> Nothing found in google! :(
> I tried with all the plugin version from 7.1.1 to 7.4.
> Also a lot of tries with different maven-ear-plugin and maven-jboss-as-plugin configuration options.... no lucky after two days of work.
> Regards,
> Mat?as.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Fri Oct  4 15:27:02 2013
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Fri, 4 Oct 2013 15:27:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBASMP-52) jboss-as:deploy deploys ear
 but doesn't deploy contained ejb module
In-Reply-To: <JIRA.12502059.1380753826000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502059.1380753826000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502059.1380753826000.14577.1380914822838@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBASMP-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809574#comment-12809574 ] 

James Perkins commented on JBASMP-52:
-------------------------------------

What is the target runtime, JBoss AS 7.x, WildFly or EAP? Also which version of the runtime? The quick start example seems to work okay, maybe you could try deploying it just to see if it works https://github.com/jboss-developer/jboss-eap-quickstarts/tree/master/ejb-in-ear
                
> jboss-as:deploy deploys ear but doesn't deploy contained ejb module
> -------------------------------------------------------------------
>
>                 Key: JBASMP-52
>                 URL: https://issues.jboss.org/browse/JBASMP-52
>             Project: JBoss AS Maven Plugins
>          Issue Type: Bug
>          Components: deploy
>    Affects Versions: 7.4.Final
>         Environment: Linux hostname 3.7.10-gentoo #1 SMP Fri Aug 30 17:01:59 ART 2013 x86_64 Intel(R) Core(TM) i5-2467M CPU @ 1.60GHz GenuineIntel GNU/Linux
>            Reporter: Mat?as Blasi
>            Assignee: James Perkins
>
> I have a simple ear application (build with maven-ear-plugin).
> This application contains just a persistence-unit definition (persistence.xml) and a ejb-module.
> The ejb module is another maven build, containing some ejb3, handled with maven-ejb-plugin.
> The ear file is correctly built:
> myapp.ear
> |
> + META-INF/application.xml
> + lib/allmylibs.jar
> + myejb.jar
> When trying to deploy the ear with the jboss-as:deploy, the application is deployed (the persistence unit deployment logs in server.log), but no ejb is registered, anyway, no errors in log, and BUILD SUCCESFUL after mvn command.
> Finally, an ear file is present under $JBOSS_HOME/standalone/data/content
> The strange thing is that if I get that generated ear file, I can succesfully deploy it through the management console, or by copying it to a folder scanned by a deployment-scanner (in both cases the ejbs are correctly deployed)
> Nothing found in google! :(
> I tried with all the plugin version from 7.1.1 to 7.4.
> Also a lot of tries with different maven-ear-plugin and maven-jboss-as-plugin configuration options.... no lucky after two days of work.
> Regards,
> Mat?as.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Fri Oct  4 15:36:02 2013
From: jira-events at lists.jboss.org (=?UTF-8?Q?Mat=C3=ADas_Blasi_=28JIRA=29?=)
Date: Fri, 4 Oct 2013 15:36:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBASMP-52) jboss-as:deploy deploys ear
 but doesn't deploy contained ejb module
In-Reply-To: <JIRA.12502059.1380753826000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502059.1380753826000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502059.1380753826000.14585.1380915362606@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBASMP-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809581#comment-12809581 ] 

Mat?as Blasi commented on JBASMP-52:
------------------------------------

Perfect! I'll try with that.
I'm deploying on JBoss AS 7.1.1-Final.

Let you know any news.

Regards,
Mat?as.
                
> jboss-as:deploy deploys ear but doesn't deploy contained ejb module
> -------------------------------------------------------------------
>
>                 Key: JBASMP-52
>                 URL: https://issues.jboss.org/browse/JBASMP-52
>             Project: JBoss AS Maven Plugins
>          Issue Type: Bug
>          Components: deploy
>    Affects Versions: 7.4.Final
>         Environment: Linux hostname 3.7.10-gentoo #1 SMP Fri Aug 30 17:01:59 ART 2013 x86_64 Intel(R) Core(TM) i5-2467M CPU @ 1.60GHz GenuineIntel GNU/Linux
>            Reporter: Mat?as Blasi
>            Assignee: James Perkins
>
> I have a simple ear application (build with maven-ear-plugin).
> This application contains just a persistence-unit definition (persistence.xml) and a ejb-module.
> The ejb module is another maven build, containing some ejb3, handled with maven-ejb-plugin.
> The ear file is correctly built:
> myapp.ear
> |
> + META-INF/application.xml
> + lib/allmylibs.jar
> + myejb.jar
> When trying to deploy the ear with the jboss-as:deploy, the application is deployed (the persistence unit deployment logs in server.log), but no ejb is registered, anyway, no errors in log, and BUILD SUCCESFUL after mvn command.
> Finally, an ear file is present under $JBOSS_HOME/standalone/data/content
> The strange thing is that if I get that generated ear file, I can succesfully deploy it through the management console, or by copying it to a folder scanned by a deployment-scanner (in both cases the ejbs are correctly deployed)
> Nothing found in google! :(
> I tried with all the plugin version from 7.1.1 to 7.4.
> Also a lot of tries with different maven-ear-plugin and maven-jboss-as-plugin configuration options.... no lucky after two days of work.
> Regards,
> Mat?as.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Fri Oct  4 15:47:02 2013
From: jira-events at lists.jboss.org (Eduardo Martins (JIRA))
Date: Fri, 4 Oct 2013 15:47:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2221) NPE in BinderService
In-Reply-To: <JIRA.12502237.1380899464000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502237.1380899464000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502237.1380899464000.14593.1380916022667@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809582#comment-12809582 ] 

Eduardo Martins commented on WFLY-2221:
---------------------------------------

Jesper, this error should be masking another issue, probably as result of the resource binding logic changes, wrt default EE bindings, but no harm in BinderService being prepared for such case. Thanks.
                
> NPE in BinderService
> --------------------
>
>                 Key: WFLY-2221
>                 URL: https://issues.jboss.org/browse/WFLY-2221
>             Project: WildFly
>          Issue Type: Bug
>          Components: Naming
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Jesper Pedersen
>            Assignee: Eduardo Martins
>
> {noformat}
> 11:03:33,766 ERROR [org.jboss.msc.service] (MSC service thread 1-4) MSC000002: Invocation of listener "org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor$BinderReleaseListener at 2d6f9ce1" failed: java.lang.NullPointerException
>         at org.jboss.as.naming.service.BinderService.release(BinderService.java:100) [wildfly-naming-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
>         at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor$BinderReleaseListener.transition(ModuleJndiBindingProcessor.java:302) [wildfly-ee-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
>         at org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1533) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>         at org.jboss.msc.service.ServiceControllerImpl.access$2800(ServiceControllerImpl.java:51) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>         at org.jboss.msc.service.ServiceControllerImpl$ListenerTask.run(ServiceControllerImpl.java:2095) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
>         at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> {noformat}
> Master from 3 days ago

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 15:52:02 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 4 Oct 2013 15:52:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2221) NPE in BinderService
In-Reply-To: <JIRA.12502237.1380899464000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502237.1380899464000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502237.1380899464000.14598.1380916322653@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809584#comment-12809584 ] 

Jesper Pedersen commented on WFLY-2221:
---------------------------------------

Should probably throw an IllegalStateException or add a guard for the possible NPE.
                
> NPE in BinderService
> --------------------
>
>                 Key: WFLY-2221
>                 URL: https://issues.jboss.org/browse/WFLY-2221
>             Project: WildFly
>          Issue Type: Bug
>          Components: Naming
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Jesper Pedersen
>            Assignee: Eduardo Martins
>
> {noformat}
> 11:03:33,766 ERROR [org.jboss.msc.service] (MSC service thread 1-4) MSC000002: Invocation of listener "org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor$BinderReleaseListener at 2d6f9ce1" failed: java.lang.NullPointerException
>         at org.jboss.as.naming.service.BinderService.release(BinderService.java:100) [wildfly-naming-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
>         at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor$BinderReleaseListener.transition(ModuleJndiBindingProcessor.java:302) [wildfly-ee-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
>         at org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1533) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>         at org.jboss.msc.service.ServiceControllerImpl.access$2800(ServiceControllerImpl.java:51) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>         at org.jboss.msc.service.ServiceControllerImpl$ListenerTask.run(ServiceControllerImpl.java:2095) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
>         at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> {noformat}
> Master from 3 days ago

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:18:02 2013
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Fri, 4 Oct 2013 17:18:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2183) Module and ClassName fields
 are disabled in new Custom handler dialog
In-Reply-To: <JIRA.12501821.1380539274000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501821.1380539274000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501821.1380539274000.14659.1380921482651@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809599#comment-12809599 ] 

James Perkins commented on WFLY-2183:
-------------------------------------

[~heiko.braun] This is not an issue with the logging subsystem. While the attributes are not writable and should be locked during an update, they are required by the add operation. I'm attaching the screen shot of an add operation. AFAIK there is no requirement that all attributes be writable.
                
> Module and ClassName fields are disabled in new Custom handler dialog
> ---------------------------------------------------------------------
>
>                 Key: WFLY-2183
>                 URL: https://issues.jboss.org/browse/WFLY-2183
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, Logging
>            Reporter: Heiko Braun
>            Assignee: James Perkins
>             Fix For: 8.0.0.CR1
>
>         Attachments: add-custom-handler.png
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:18:02 2013
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Fri, 4 Oct 2013 17:18:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2183) Module and ClassName fields
 are disabled in new Custom handler dialog
In-Reply-To: <JIRA.12501821.1380539274000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501821.1380539274000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501821.1380539274000.14663.1380921482838@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins updated WFLY-2183:
--------------------------------

    Assignee: Heiko Braun  (was: James Perkins)

    
> Module and ClassName fields are disabled in new Custom handler dialog
> ---------------------------------------------------------------------
>
>                 Key: WFLY-2183
>                 URL: https://issues.jboss.org/browse/WFLY-2183
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, Logging
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>             Fix For: 8.0.0.CR1
>
>         Attachments: add-custom-handler.png
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:18:03 2013
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Fri, 4 Oct 2013 17:18:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2183) Module and ClassName fields
 are disabled in new Custom handler dialog
In-Reply-To: <JIRA.12501821.1380539274000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501821.1380539274000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501821.1380539274000.14666.1380921483098@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins updated WFLY-2183:
--------------------------------

    Attachment: add-custom-handler.png

    
> Module and ClassName fields are disabled in new Custom handler dialog
> ---------------------------------------------------------------------
>
>                 Key: WFLY-2183
>                 URL: https://issues.jboss.org/browse/WFLY-2183
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, Logging
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>             Fix For: 8.0.0.CR1
>
>         Attachments: add-custom-handler.png
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:07 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2214) LDAP security realm needs to
 have configurable timeouts
In-Reply-To: <JIRA.12502155.1380834418000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502155.1380834418000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502155.1380834418000.14692.1380922927355@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2214:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> LDAP security realm needs to have configurable timeouts
> -------------------------------------------------------
>
>                 Key: WFLY-2214
>                 URL: https://issues.jboss.org/browse/WFLY-2214
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Derek Horton
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> LDAP security realm needs to have configurable timeouts.
> The default LDAP connection timeout appears to be 2 minutes.  If the ldap server is down, it could take 2 minutes for the connection to timeout.  This can cause unneeded delay if you have configured multiple ldap servers for  failover / redundancy.
> The following hack appears to work:
> +++ domain-management/src/main/java/org/jboss/as/domain/management/connections/ldap/LdapConnectionManagerService.java
> @@ -132,6 +132,7 @@ public class LdapConnectionManagerService implements Service<LdapConnectionManag
>          result.put(Context.INITIAL_CONTEXT_FACTORY,initialContextFactory);
>          String url = config.require(URL).asString();
>          result.put(Context.PROVIDER_URL,url);
> +        result.put("com.sun.jndi.ldap.connect.timeout", "500");
>          return result;
>      }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:07 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2212) Update JPA subsystem to use
 default EE datasource binding
In-Reply-To: <JIRA.12502126.1380810972000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502126.1380810972000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502126.1380810972000.14695.1380922927498@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2212:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Update JPA subsystem to use default EE datasource binding
> ---------------------------------------------------------
>
>                 Key: WFLY-2212
>                 URL: https://issues.jboss.org/browse/WFLY-2212
>             Project: WildFly
>          Issue Type: Task
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 8.0.0.CR1
>
>
> JPA subsystem should check if a default EE datasource binding is available to use and default to that if a persistence unit doesn't specify a datasource.
> Also add a persistence unit hint to not use a default datasource (might be helpful for OGM which fails the deployment if a datasource is specified).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:07 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2211) NullPointerException in
 RemotingHttpUpgradeService if no http port.
In-Reply-To: <JIRA.12502120.1380808407000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502120.1380808407000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502120.1380808407000.14698.1380922927631@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2211:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> NullPointerException in RemotingHttpUpgradeService if no http port.
> -------------------------------------------------------------------
>
>                 Key: WFLY-2211
>                 URL: https://issues.jboss.org/browse/WFLY-2211
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.CR1
>
>
> Starting with a HTTP port is not mandatory.
> {code}
> Caused by: java.lang.NullPointerException
> 	at org.jboss.as.remoting.RemotingHttpUpgradeService.start(RemotingHttpUpgradeService.java:107) [wildfly-remoting-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:07 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2210) fix message endpoint
	isDeliveryTransacted
In-Reply-To: <JIRA.12502112.1380805704000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502112.1380805704000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502112.1380805704000.14701.1380922927799@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2210:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> fix message endpoint isDeliveryTransacted
> -----------------------------------------
>
>                 Key: WFLY-2210
>                 URL: https://issues.jboss.org/browse/WFLY-2210
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>            Priority: Blocker
>             Fix For: 8.0.0.CR1
>
>
> The org.jboss.as.ejb3.inflow.MessageEndpointService#isDeliveryTransacted method is checking the transaction attribute of the method using the MethodIntf.BEAN while it should use the MethodIntf.MESSAGE_ENDPOINT type.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:07 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2208) CLI over HTTP should switch
 to / be redirected to https automatically.
In-Reply-To: <JIRA.12502037.1380736411000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502037.1380736411000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502037.1380736411000.14704.1380922927900@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2208:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> CLI over HTTP should switch to / be redirected to https automatically.
> ----------------------------------------------------------------------
>
>                 Key: WFLY-2208
>                 URL: https://issues.jboss.org/browse/WFLY-2208
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: CLI, Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> When using the native interface a TLS upgrade was already automatically in place once a keystore was added to the linked realm.
> With the switch to http with an upgrade there is no automatic switch to https.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:08 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2207) CLI Unable to connect using
 https-remoting address.
In-Reply-To: <JIRA.12502036.1380735356000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502036.1380735356000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502036.1380735356000.14707.1380922928039@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2207:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> CLI Unable to connect using https-remoting address.
> ---------------------------------------------------
>
>                 Key: WFLY-2207
>                 URL: https://issues.jboss.org/browse/WFLY-2207
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.CR1
>
>
> The CLI is failing to connect over https with the following: -
> {code}
> [disconnected /] connect https-remoting://localhost:9993
> The controller is not available at localhost:9993: java.net.ConnectException: JBAS012144: Could not connect to https-remoting://localhost:9993. The connection timed out: JBAS012144: Could not connect to https-remoting://localhost:9993. The connection timed out
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:08 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2202) Update to HAL 2.0.2.Final
In-Reply-To: <JIRA.12501998.1380715953000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501998.1380715953000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501998.1380715953000.14710.1380922928169@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2202:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Update to HAL 2.0.2.Final
> -------------------------
>
>                 Key: WFLY-2202
>                 URL: https://issues.jboss.org/browse/WFLY-2202
>             Project: WildFly
>          Issue Type: Task
>          Components: Web Console
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:08 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2201) Server-side XTS handlers not
 added if @WebService#portName is missing
In-Reply-To: <JIRA.12501360.1380015769000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501360.1380015769000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501360.1380015769000.14714.1380922928338@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2201:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Server-side XTS handlers not added if @WebService#portName is missing
> ---------------------------------------------------------------------
>
>                 Key: WFLY-2201
>                 URL: https://issues.jboss.org/browse/WFLY-2201
>             Project: WildFly
>          Issue Type: Bug
>          Components: XTS
>            Reporter: Paul Robinson
>            Assignee: Gytis Trikleris
>            Priority: Minor
>             Fix For: 8.0.0.CR1
>
>
> To reproduce, remove portName or targetNameSpace attributes from org.jboss.narayana.compensations.functional.distributed.DistributedTest in the TXFramework suite. You will see that the test fails with:
> {code}
> "MustUnderstand headers: [{http://docs.oasis-open.org/ws-tx/wscoor/2006/06}CoordinationContext] are not understood"
> {code}
> The problem is that the Endpoint is not recognised, by the XTS subsytem, as having a valid @WebService annotation if these attributes are missing. In reality they are optional and an application should be allowed to leave them off. However, these attribute values are used by the XTS subsytem, so we would need to find a way of using the defaults if they are missing from the annotation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:08 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2194) Difficulty Enabling SSL for
 Management Interfaces Using CLI
In-Reply-To: <JIRA.12501945.1380647585000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501945.1380647585000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501945.1380647585000.14717.1380922928473@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2194:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Difficulty Enabling SSL for Management Interfaces Using CLI
> -----------------------------------------------------------
>
>                 Key: WFLY-2194
>                 URL: https://issues.jboss.org/browse/WFLY-2194
>             Project: WildFly
>          Issue Type: Task
>          Components: CLI, Domain Management, Security
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Trying to enable the HTTPS port for the HTTP management interface using the CLI results in the following: -
> {code}
> [standalone at localhost:9990 /] ./core-service=management/management-interface=http-interface:write-attribute(name=secure-socket-binding, value=management-https)
> Communication error: java.util.concurrent.ExecutionException: Operation failed: Operation failed: Channel closed
> {code}
> Server side the following is logged: -
> {code}
> 17:59:54,193 INFO  [org.jboss.as.server] (management-handler-thread - 4) JBAS015890: Creating http management service using socket-binding (management-http) and secure-socket-binding (management-https)
> 17:59:54,212 INFO  [org.jboss.as.server] (management-handler-thread - 4) JBAS015888: Creating http management service using socket-binding (management-http)
> 17:59:54,236 WARN  [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014626: Operation was interrupted before stability could be reached
> {code}
> i.e. What appears to be happening is that as communication is lost with the client the update is being detected as a failure.
> As interface updates do result in restarting the services used to make the updates it may be better to switch these to reload required updates instead of being immediate - also the chances are that security realm updates would be made simultaneously and those also require a reload.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:08 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2192) MessageEndpointFactory should
 use unique RA id
In-Reply-To: <JIRA.12501926.1380633231000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501926.1380633231000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501926.1380633231000.14720.1380922928627@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2192:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> MessageEndpointFactory should use unique RA id
> ----------------------------------------------
>
>                 Key: WFLY-2192
>                 URL: https://issues.jboss.org/browse/WFLY-2192
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Stefano Maestri
>            Assignee: Stefano Maestri
>            Priority: Blocker
>             Fix For: 8.0.0.CR1
>
>
> This is causing a regression in TCK

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:08 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2171) Use deployment unit
 processors to register mod_cluster metrics
In-Reply-To: <JIRA.12501718.1380276630000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501718.1380276630000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501718.1380276630000.14723.1380922928746@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2171:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Use deployment unit processors to register mod_cluster metrics
> --------------------------------------------------------------
>
>                 Key: WFLY-2171
>                 URL: https://issues.jboss.org/browse/WFLY-2171
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>            Priority: Critical
>             Fix For: 8.0.0.CR1
>
>
> Remove static dependency and make it runtime using DUPs.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:08 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2170) Intermittent failure in
 ReloadWSDLPublisherTestCase
In-Reply-To: <JIRA.12501697.1380264273000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501697.1380264273000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501697.1380264273000.14726.1380922928895@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2170:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Intermittent failure in ReloadWSDLPublisherTestCase
> ---------------------------------------------------
>
>                 Key: WFLY-2170
>                 URL: https://issues.jboss.org/browse/WFLY-2170
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Joe Wertz
>            Assignee: Joe Wertz
>            Priority: Minor
>             Fix For: 8.0.0.CR1
>
>
> Intermittent failure reconnecting to the server after it is restarted.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:08 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2159) Consolidate REPL and DIST
 cache configurations
In-Reply-To: <JIRA.12501554.1380139905000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501554.1380139905000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501554.1380139905000.14729.1380922928988@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2159:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Consolidate REPL and DIST cache configurations
> ----------------------------------------------
>
>                 Key: WFLY-2159
>                 URL: https://issues.jboss.org/browse/WFLY-2159
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Clustering
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 8.0.0.CR1
>
>
> Since Infinispan now implements REPL as a special case of DIST (i.e. where owners == cache view size), we can use DIST as default cache mode for our clustered caches, with owners="4" (or similar).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:09 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2151) don't deploy persistence unit
 in EE client container unless its part of an application client jar
In-Reply-To: <JIRA.12501447.1380071620000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501447.1380071620000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501447.1380071620000.14732.1380922929143@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2151:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> don't deploy persistence unit in EE client container unless its part of an application client jar
> -------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2151
>                 URL: https://issues.jboss.org/browse/WFLY-2151
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:09 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2145) Automatically add XTS and
 TXBridge handlers to Web Services that use JTA annotations
In-Reply-To: <JIRA.12500584.1378979979000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500584.1378979979000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500584.1378979979000.14737.1380922929413@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2145:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Automatically add XTS and TXBridge handlers to Web Services that use JTA annotations
> ------------------------------------------------------------------------------------
>
>                 Key: WFLY-2145
>                 URL: https://issues.jboss.org/browse/WFLY-2145
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: XTS
>            Reporter: Paul Robinson
>            Assignee: Gytis Trikleris
>             Fix For: 8.0.0.CR1
>
>
> Currently the developer needs to specify the XTS and Bridge handlers on the Web Service that wishes inflow a WS-AT transaction. This is cumbersome and error prone.
> It is quite easy to infer if the user needs these handlers by checking to see if the Web Service uses @Transactional or @TransactionAtttibute and by looking for a WS-AT transaction context on the inbound message.
> The same can also be done for the Compensations API, by looking for @Compensatable annotations on the Web Service. In which case, only the XTS handler should be added as no bridging is required.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:09 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2138) Cannot add security realm
 child resources in a domain
In-Reply-To: <JIRA.12501333.1379967150000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501333.1379967150000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501333.1379967150000.14741.1380922929557@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2138:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Cannot add security realm child resources in a domain
> -----------------------------------------------------
>
>                 Key: WFLY-2138
>                 URL: https://issues.jboss.org/browse/WFLY-2138
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: 8.0.0.CR1
>
>
> /] /host=master/core-service=management/security-realm=JBossTest:add
> {
>     "outcome" => "success",
>     "result" => undefined,
>     "server-groups" => undefined
> }
> [domain at localhost:9990 /] /host=master/core-service=management/security-realm=JBossTest/authentication=properties:add(path=application-users.properties, relative-to=jboss.server.config.dir)
> {
>     "outcome" => "failed",
>     "result" => undefined,
>     "failure-description" => "JBAS010839: Operation failed or was rolled back on all servers.",
>     "rolled-back" => true,
>     "server-groups" => {"main-server-group" => {"host" => {"master" => {
>         "server-one" => {"response" => {
>             "outcome" => "failed",
>             "failure-description" => "JBAS014883: No resource definition is registered for address [
>     (\"host\" => \"master\"),
>     (\"core-service\" => \"management\"),
>     (\"security-realm\" => \"JBossTest\"),
>     (\"authentication\" => \"properties\")
> ]",
>             "rolled-back" => true
>         }},
>         "server-two" => {"response" => {
>             "outcome" => "failed",
>             "failure-description" => "JBAS014883: No resource definition is registered for address [
>     (\"host\" => \"master\"),
>     (\"core-service\" => \"management\"),
>     (\"security-realm\" => \"JBossTest\"),
>     (\"authentication\" => \"properties\")
> ]",
>             "rolled-back" => true
>         }}
>     }}}}
> }
> Note the addresses in the server level failure messages. It appears the /host=master level is not being stripped from the request to the server.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:09 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2128) Support one-port connection
	for JMS
In-Reply-To: <JIRA.12501177.1379926949000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501177.1379926949000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501177.1379926949000.14744.1380922929663@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2128:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Support one-port connection for JMS
> -----------------------------------
>
>                 Key: WFLY-2128
>                 URL: https://issues.jboss.org/browse/WFLY-2128
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JMS
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>            Priority: Critical
>             Fix For: 8.0.0.CR1
>
>
> WildFly 8 needs to support one-port where all the remote connections goes through HTTP with Upgrade header.
> A JMS client will be able to connect to WildFly's HTTP port to access its JMS resources instead of connecting to the TCP socket on HornetQ remote port (5445).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:09 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2119) RBAC-based tab completion for
 the CLI commands
In-Reply-To: <JIRA.12501124.1379690777000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501124.1379690777000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501124.1379690777000.14747.1380922929818@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2119:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> RBAC-based tab completion for the CLI commands
> ----------------------------------------------
>
>                 Key: WFLY-2119
>                 URL: https://issues.jboss.org/browse/WFLY-2119
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: CLI
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>              Labels: RBAC-WF-only
>             Fix For: 8.0.0.CR1
>
>
> With the RBAC in place, the CLI tab-completion should take the advantage (where possible and reasonable) and suggest only the commands, arguments and argument values that are available and allowed to be executed by the current user.
> Since performing access control checks may be time consuming (especially in the domain mode) this feature should be optional and exposed through CLI configuration.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:10 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2112) Test that validate-address
 and validate-operation do not leak non-addressable addresses
In-Reply-To: <JIRA.12501018.1379598157000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501018.1379598157000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501018.1379598157000.14751.1380922930005@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2112:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Test that validate-address and validate-operation do not leak non-addressable addresses
> ---------------------------------------------------------------------------------------
>
>                 Key: WFLY-2112
>                 URL: https://issues.jboss.org/browse/WFLY-2112
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Ladislav Thon
>             Fix For: 8.0.0.CR1
>
>
> basically those operations check that an address is valid, or that an operation is valid
> 14:18
> the operation has an address
> 14:18
> So you do :validate-address(value="/some=where")
> 14:18
> I made up the syntax for the value thing, it needs a ModelNode
> 14:19 bstans_afk
> Ladicek: the CLI uses that behind the scenes
> 14:19 kkhan
> So the way it worked until now is that if the address is valid, it returns that it is valid
> 14:19
> and if it is not valid it returns that it is not valid
> 14:20 Ladicek
> wow, never heard of that 
> 14:20 kkhan
> however, if /some=where is not addressable for the current user, we want to return that it is invalid
> 14:20 Ladicek
> souns sensible to me
> 14:20 kkhan
> i.e. to hide the non-addressable addresses

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:10 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2090) CXF fails with
 IllegalStateException: UT000005: getRequestChannel() has already been
 called
In-Reply-To: <JIRA.12500798.1379354277000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500798.1379354277000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500798.1379354277000.14757.1380922930219@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2090:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> CXF fails with IllegalStateException: UT000005: getRequestChannel() has already been called
> -------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2090
>                 URL: https://issues.jboss.org/browse/WFLY-2090
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.CR1
>
>
> asoldano is seeing CXF problems with the latest modcluster undertow integration:
> 18:40:41,678 ERROR [io.undertow.request] (default task-10) Blocking request failed HttpServerExchange{ POST /jaxws-samples-asynch}: java.lang.IllegalStateException: UT000005: getRequestChannel() has already been called
> 	at io.undertow.server.HttpServerExchange.addRequestWrapper(HttpServerExchange.java:1052) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at org.wildfly.mod_cluster.undertow.metric.BytesReceivedThreadSetupAction.setup(BytesReceivedThreadSetupAction.java:46) [wildfly-mod_cluster-undertow-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at io.undertow.servlet.core.CompositeThreadSetupAction.setup(CompositeThreadSetupAction.java:42) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:204) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:196) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:141) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.spec.AsyncContextImpl$2$1.handleRequest(AsyncContextImpl.java:189) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.spec.AsyncContextImpl$2.run(AsyncContextImpl.java:186) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.spec.AsyncContextImpl$5.run(AsyncContextImpl.java:411) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.spec.AsyncContextImpl$TaskDispatchRunnable.run(AsyncContextImpl.java:496) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:10 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2088) Error creating server group
 as scoped role user
In-Reply-To: <JIRA.12500789.1379349208000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500789.1379349208000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500789.1379349208000.14762.1380922930533@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2088:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Error creating server group as scoped role user
> -----------------------------------------------
>
>                 Key: WFLY-2088
>                 URL: https://issues.jboss.org/browse/WFLY-2088
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.CR1
>
>
> I've got a scoped role
> {noformat}
> [domain at localhost:9999 /] /core-service=management/access=authorization/server-group-scoped-role=main-MAINTAINER:read-resource
> {
>     "outcome" => "success",
>     "result" => {
>         "base-role" => "MAINTAINER",
>         "server-groups" => ["main-server-group"]
>     }
> }
> {noformat}
> and try to create a server group, which leads to an exception:
> {noformat}
> [domain at localhost:9999 /] /server-group=fooBar:add(){roles=MAIN-MAINTAINER}
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014807: Management resource '[(\"server-group\" => \"fooBar\")]' not found",
>     "rolled-back" => true
> }
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:10 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2085) Prevent server group scoped
 roles modifying the master HC if it has no servers
In-Reply-To: <JIRA.12500772.1379340528000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500772.1379340528000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500772.1379340528000.14765.1380922930691@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2085:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Prevent server group scoped roles modifying the master HC if it has no servers
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-2085
>                 URL: https://issues.jboss.org/browse/WFLY-2085
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> Currently server group scoped roles with write or security-sensitive-read privileges are able to use those privileges with any HC that has no servers defined. This allows the role to do things like add a server in the group to a newly spun up host.
> The master HC should be excluded from this ability. The master would typically not have servers, but not because it is a newly spun-up host.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:10 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2055) Centralize and organize
 I/O-related options into I/O subsystem
In-Reply-To: <JIRA.12500632.1379000746000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500632.1379000746000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500632.1379000746000.14769.1380922930964@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2055:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Centralize and organize I/O-related options into I/O subsystem
> --------------------------------------------------------------
>
>                 Key: WFLY-2055
>                 URL: https://issues.jboss.org/browse/WFLY-2055
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Remoting, Web (Undertow)
>            Reporter: David Lloyd
>            Assignee: Tomaz Cerar
>             Fix For: 8.0.0.CR1
>
>
> Centralize all the I/O related options into the I/O subsystem schema.  This includes all XNIO Options, and also includes moving all XNIO worker configuration into the I/O subsystem to be referenced.
> The I/O subsystem should define types for each I/O option including (but not limited to):
> * send and receive buffer sizes
> * TCP nodelay setting
> * TCP keepalive
> * IP TOS
> * Server socket backlog
> * Server connection limit low/high water mark
> * etc.
> Also there should be types defined for:
> * XNIO worker thread count
> * XNIO worker thread stack size
> * XNIO worker thread priority
> * etc.
> Systems which define I/O entities will reference these types by including the allowed/relevant option types into their schema like the threads subsystem does for thread pool types.
> Systems presently defining workers should instead reference a worker defined in the I/O subsystem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:11 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2004) Formatter "COLOR-PATTERN" is
	not found
In-Reply-To: <JIRA.12500018.1378366639000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500018.1378366639000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500018.1378366639000.14774.1380922931206@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2004:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Formatter "COLOR-PATTERN" is not found
> --------------------------------------
>
>                 Key: WFLY-2004
>                 URL: https://issues.jboss.org/browse/WFLY-2004
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, Logging
>            Reporter: Heiko Braun
>            Assignee: James Perkins
>             Fix For: 8.0.0.CR1
>
>         Attachments: domain.xml, host.xml
>
>
> Failed to start a server on a second host:
> {noformat}
> [Host Controller] INFO  [org.jboss.as.host.controller] JBAS010919: Registering server stage1
> [Server:stage1] ERROR [org.jboss.as.controller.management-operation] JBAS014612: Operation ("add") failed - address: ([
> [Server:stage1]     ("subsystem" => "logging"),
> [Server:stage1]     ("console-handler" => "CONSOLE")
> [Server:stage1] ]): java.lang.IllegalArgumentException: Formatter "COLOR-PATTERN" is not found
> [Server:stage1] 	at org.jboss.logmanager.config.HandlerConfigurationImpl$1.validate(HandlerConfigurationImpl.java:83) [jboss-logmanager-1.5.0.Final.jar:1.5.0.Final]
> [Server:stage1] 	at org.jboss.logmanager.config.HandlerConfigurationImpl$1.validate(HandlerConfigurationImpl.java:80) [jboss-logmanager-1.5.0.Final.jar:1.5.0.Final]
> [Server:stage1] 	at org.jboss.logmanager.config.LogContextConfigurationImpl.doPrepare(LogContextConfigurationImpl.java:338) [jboss-logmanager-1.5.0.Final.jar:1.5.0.Final]
> [Server:stage1] 	at org.jboss.logmanager.config.LogContextConfigurationImpl.prepare(LogContextConfigurationImpl.java:291) [jboss-logmanager-1.5.0.Final.jar:1.5.0.Final]
> [Server:stage1] 	at org.jboss.as.logging.logmanager.ConfigurationPersistence.prepare(ConfigurationPersistence.java:303)
> [Server:stage1] 	at org.jboss.as.logging.LoggingOperations$CommitOperationStepHandler.execute(LoggingOperations.java:97)
> [Server:stage1] 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:610) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:488) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] 	at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:320) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] 	at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:288) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] 	at org.jboss.as.server.ServerService.boot(ServerService.java:356) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:11 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1988) SaslException at startup in
 domain mode using JAAS for ManagementRealm
In-Reply-To: <JIRA.12499810.1378201935000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499810.1378201935000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499810.1378201935000.14778.1380922931417@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1988:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
>  SaslException at startup in domain mode using JAAS for ManagementRealm
> -----------------------------------------------------------------------
>
>                 Key: WFLY-1988
>                 URL: https://issues.jboss.org/browse/WFLY-1988
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:11 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1966) Hangs in
	DomainControllerMigrationTestCase
In-Reply-To: <JIRA.12499532.1377720945000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499532.1377720945000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499532.1377720945000.14785.1380922931733@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1966:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Hangs in DomainControllerMigrationTestCase
> ------------------------------------------
>
>                 Key: WFLY-1966
>                 URL: https://issues.jboss.org/browse/WFLY-1966
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>         Attachments: thread-dump.txt
>
>
> DomainControllerMigrationTestCase is intermittently hanging recently.
> I will attach thread dumps from a recent hang.
> The test driver is hanging here:
> "main" prio=10 tid=0xb7605c00 nid=0x7656 in Object.wait() [0xb7786000]
>    java.lang.Thread.State: WAITING (on object monitor)
> 	at java.lang.Object.wait(Native Method)
> 	- waiting on <0xa99833f8> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> 	at java.lang.Object.wait(Object.java:503)
> 	at org.jboss.threads.AsyncFutureTask.await(AsyncFutureTask.java:192)
> 	- eliminated <0xa99833f8> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> 	at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:266)
> 	- locked <0xa99833f8> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> 	at org.jboss.as.controller.client.impl.AbstractDelegatingAsyncFuture.get(AbstractDelegatingAsyncFuture.java:100)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:76)
> 	at org.jboss.as.controller.client.helpers.domain.impl.DomainClientImpl.execute(DomainClientImpl.java:86)
> 	at org.jboss.as.test.integration.domain.management.util.DomainLifecycleUtil.executeForResult(DomainLifecycleUtil.java:580)
> 	at org.jboss.as.test.integration.domain.DomainControllerMigrationTestCase.testDCFailover(DomainControllerMigrationTestCase.java:206)
> The master HC process is stuck here:
> "management-handler-thread - 2" prio=10 tid=0x8be50400 nid=0x1a92 waiting on condition [0x87604000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0xaa032fd0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at org.jboss.as.controller.remote.BlockingQueueOperationListener.retrievePreparedOperation(BlockingQueueOperationListener.java:84)
> 	at org.jboss.as.domain.controller.operations.coordination.DomainSlaveHandler.execute(DomainSlaveHandler.java:117)
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:608)
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:486)
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:275)
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:270)
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:257)
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:142)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:205)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:110)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:157)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:153)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:415)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296)
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> 	at java.lang.Thread.run(Thread.java:724)
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> I see nothing relevant in the other thread dumps.
> The master HC is blocking waiting for a response from the slave HC.
> Just before the client makes the request that triggers this, it has reloaded the slave HC. The test is not robust in terms of how it checks that the slave is ready before continuing on with the test; it merely connects directly to the slave checks that the slave's root resource can be read. That can succeed relatively early in boot even before the slave has registered with the master.
> Fixing that may prevent the hangs, but it would likely paper over whatever problem is causing the hangs. A client invoking multi-host operations while a slave is booting and registering is a use case that can't hang.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:11 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1970) Make mod_cluster status
	configurable
In-Reply-To: <JIRA.12499638.1377789630000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499638.1377789630000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499638.1377789630000.14782.1380922931584@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1970:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Make mod_cluster status configurable
> ------------------------------------
>
>                 Key: WFLY-1970
>                 URL: https://issues.jboss.org/browse/WFLY-1970
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.CR1
>
>
> There is a TODO in UndertowEventHandlerAdapter.start(StartContext)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:11 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1959) Annotation and DD metadata
 needs to be merged at a finer level that what currently occurs
In-Reply-To: <JIRA.12499424.1377599814000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499424.1377599814000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499424.1377599814000.14788.1380922931872@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1959:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Annotation and DD metadata needs to be merged at a finer level that what currently occurs
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-1959
>                 URL: https://issues.jboss.org/browse/WFLY-1959
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EE
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.CR1
>
>
> Currently DD JNDI bindings completely replace annotation based bindings, however we need to actually merge some of this info. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:12 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1957) Upgrade Narayana to 5.0.0.M5
In-Reply-To: <JIRA.12499415.1377592323000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499415.1377592323000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499415.1377592323000.14792.1380922932019@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1957:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Upgrade Narayana to 5.0.0.M5
> ----------------------------
>
>                 Key: WFLY-1957
>                 URL: https://issues.jboss.org/browse/WFLY-1957
>             Project: WildFly
>          Issue Type: Component  Upgrade
>          Components: Transactions
>            Reporter: Paul Robinson
>            Assignee: Michael Musgrove
>             Fix For: 8.0.0.CR1
>
>
> In particular, needed for the fix to WFLY-1929.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:12 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1928) jboss-as-standalone.sh does
 not work on MacOS
In-Reply-To: <JIRA.12499212.1377185444000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499212.1377185444000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499212.1377185444000.14801.1380922932531@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1928:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> jboss-as-standalone.sh does not work on MacOS
> ---------------------------------------------
>
>                 Key: WFLY-1928
>                 URL: https://issues.jboss.org/browse/WFLY-1928
>             Project: WildFly
>          Issue Type: Bug
>          Components: Scripts
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Thomas Diesler
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.CR1
>
>
> {code}
> FuseFabric:karaf at root> process-start root 3
> bin/init.d/jboss-as-standalone.sh: line 12: /etc/init.d/functions: No such file or directory
> Error executing command: [bin/init.d/jboss-as-standalone.sh, start] exited with 1
> bin/init.d/jboss-as-standalone.sh: line 12: /etc/init.d/functions: No such file or directory
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:12 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1955) Failed to read hosts
In-Reply-To: <JIRA.12499345.1377514114000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499345.1377514114000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499345.1377514114000.14796.1380922932215@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1955:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Failed to read hosts
> --------------------
>
>                 Key: WFLY-1955
>                 URL: https://issues.jboss.org/browse/WFLY-1955
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>              Labels: eap6.x
>             Fix For: 8.0.0.CR1
>
>         Attachments: WFLY-1955-reproduce.txt
>
>
> Steps top reproduce:
> 1) Start domain
> 2) set server into reload state (transactions > statistics=true)
> 3) stop server from CLI (or web console) 
> 4) execute CLI command:
> {noformat}
> [domain at localhost:9999 /] :read-children-resources(child-type=host)
> {
>     "outcome" => "failed",
>     "rolled-back" => true
> }
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:12 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1919) PicketBox 4.0.18.Final
In-Reply-To: <JIRA.12499106.1377100373000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499106.1377100373000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499106.1377100373000.14805.1380922932722@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1919:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> PicketBox 4.0.18.Final
> ----------------------
>
>                 Key: WFLY-1919
>                 URL: https://issues.jboss.org/browse/WFLY-1919
>             Project: WildFly
>          Issue Type: Component  Upgrade
>          Components: Build System
>            Reporter: Jesper Pedersen
>            Assignee: Stefan Guilhen
>            Priority: Critical
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:12 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:12 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1913) CLI 'module add' command fail
 if a drive letter is specified in its resource path
In-Reply-To: <JIRA.12499050.1377075768000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499050.1377075768000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499050.1377075768000.14810.1380922932940@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1913:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> CLI 'module add' command fail if a drive letter is specified in its resource path
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-1913
>                 URL: https://issues.jboss.org/browse/WFLY-1913
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>             Fix For: 8.0.0.CR1
>
>         Attachments: install-mojarra-2.0.0.cli
>
>
> If a drive letter is specified in the resource path the module add command fails on MS Windows. It cannot locate such a resource because of doubled drive letter in the translated path.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:13 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1873) mod_cluster ISE on shutdown
In-Reply-To: <JIRA.12498516.1376424073000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498516.1376424073000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498516.1376424073000.14824.1380922933557@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1873:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> mod_cluster ISE on shutdown
> ---------------------------
>
>                 Key: WFLY-1873
>                 URL: https://issues.jboss.org/browse/WFLY-1873
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.CR1
>
>
> 16:45:28,305 ERROR [org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler] (MSC service thread 1-2) Error [MEM: MEM: Can't read node: {4}] sending command DISABLE-APP to proxy localhost/127.0.0.1:6666, configuration will be reset
> 16:45:28,315 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) JBAS017521: Undertow AJP listener ajp suspending
> 16:45:28,319 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) JBAS017520: Undertow AJP listener ajp stopped, was bound to /127.0.0.1:8009
> 16:45:28,336 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-4) JBAS010418: Stopped Driver service with driver-name = h2
> 16:45:28,344 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) JBAS017521: Undertow HTTP listener default suspending
> 16:45:28,349 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) JBAS017520: Undertow HTTP listener default stopped, was bound to /127.0.0.1:8080
> 16:45:38,307 WARN  [org.jboss.modcluster.ModClusterService] (MSC service thread 1-2) Failed to drain pending requests from context [org.wildfly.mod_cluster.undertow.UndertowContext at 1906d941] within specified timeout: 10 seconds
> 16:45:38,308 WARN  [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000004: Failure during stop of service jboss.undertow.deployment.default-host./clusterbench-ee6-web: java.lang.IllegalStateException
> 	at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:47) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at org.wildfly.mod_cluster.undertow.UndertowEventHandlerAdapter.onDeploymentStop(UndertowEventHandlerAdapter.java:137)
> 	at org.wildfly.extension.undertow.Host$2.invoke(Host.java:138)
> 	at org.wildfly.extension.undertow.UndertowService.fireEvent(UndertowService.java:168)
> 	at org.wildfly.extension.undertow.Host.unregisterDeployment(Host.java:135)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stopContext(UndertowDeploymentService.java:104)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stop(UndertowDeploymentService.java:94)
> 	at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2052) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2013) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:13 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1902) jconsole.sh fails when
 JAVA_HOME is not set
In-Reply-To: <JIRA.12498925.1376940530000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498925.1376940530000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498925.1376940530000.14815.1380922933156@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1902:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> jconsole.sh fails when JAVA_HOME is not set
> -------------------------------------------
>
>                 Key: WFLY-1902
>                 URL: https://issues.jboss.org/browse/WFLY-1902
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Scripts
>    Affects Versions: 8.0.0.Alpha4
>         Environment: RHEL#/Fedora/Debian RPM
>            Reporter: Aleksandar Kostadinov
>            Assignee: Aleksandar Kostadinov
>              Labels: jconsole
>             Fix For: 8.0.0.CR1
>
>
> In most standard linux distros JAVA_HOME is never set no matter if any JVM is installed or not. This breaks jconsole.sh
> {code}
> # /usr/share/jbossas/bin/jconsole.sh 
> JAVA_HOME is not set. Unable to locate the jars needed to run jconsole.
> {code}
> jconsole.sh needs to try finding a suitable java installation before failing with an error.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:13 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1901) Could not grant
 javax.xml.ws.WebServicePermission to a deployment
In-Reply-To: <JIRA.12498910.1376929649000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498910.1376929649000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498910.1376929649000.14819.1380922933347@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1901:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Could not grant javax.xml.ws.WebServicePermission to a deployment
> -----------------------------------------------------------------
>
>                 Key: WFLY-1901
>                 URL: https://issues.jboss.org/browse/WFLY-1901
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security Manager
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Alessio Soldano
>            Assignee: Stefan Guilhen
>             Fix For: 8.0.0.CR1
>
>
> It's currently not possible by default to grant the javax.xml.ws.WebServicePermission "publish" permission to a user deployment by adding the proper entry in standalone.xml:
> {noformat}
>         <subsystem xmlns="urn:jboss:domain:security-manager:1.0">
>             <deployment-permissions>
>                 <minimum-set>
>                     ...
>                     <permission class="javax.xml.ws.WebServicePermission" name="publishEndpoint"/>
>                 </minimum-set>
>             </deployment-permissions>
>         </subsystem>
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:13 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1871) CLI module command doesn't
 allow cross platform resource paths
In-Reply-To: <JIRA.12498510.1376412050000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498510.1376412050000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498510.1376412050000.14828.1380922933735@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1871:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> CLI module command doesn't allow cross platform resource paths
> --------------------------------------------------------------
>
>                 Key: WFLY-1871
>                 URL: https://issues.jboss.org/browse/WFLY-1871
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Stan Silvert
>            Assignee: Stan Silvert
>             Fix For: 8.0.0.CR1
>
>
> The CLI module command has an argument called "resources".  This argument allows you to specify one or more resources separated by the platform-specific path separator.  The problem with this is that you can not create a platform-independent script that uses this resources argument.
> I have not found a universal path separator character that would work.  However, since the creator of the script knows the characters used in his path, we can allow him to specify his own separator.
> As an enhancement, I propose to add an argument called "resourceDelimiter".  If present, the ASModuleHandler class will use the user-defined delimiter instead of the platform-specific path separator character.
> Example usage:
> {noformat}
> module add --name=org.foo --resources=firstResource.jar:secondResource.jar --resourceDelimiter=: --module-xml=foo-module.xml
> {noformat}
> The above command would work on Unix, Windows, or any other platform.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:13 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1867) Provide access control
	documentation
In-Reply-To: <JIRA.12498454.1376383935000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498454.1376383935000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498454.1376383935000.14832.1380922933897@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1867:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Provide access control documentation
> ------------------------------------
>
>                 Key: WFLY-1867
>                 URL: https://issues.jboss.org/browse/WFLY-1867
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Documentation, Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> The access control features need to be properly documented

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:14 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1858) Add RBAC sensitivity
 classification constraints to undertow subsystem
In-Reply-To: <JIRA.12498290.1375999390000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498290.1375999390000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498290.1375999390000.14836.1380922934094@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1858:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Add RBAC sensitivity classification constraints to undertow subsystem
> ---------------------------------------------------------------------
>
>                 Key: WFLY-1858
>                 URL: https://issues.jboss.org/browse/WFLY-1858
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Web (Undertow)
>            Reporter: Brian Stansberry
>            Assignee: Tomaz Cerar
>              Labels: RBAC-WF-only
>             Fix For: 8.0.0.CR1
>
>
> The current RBAC work updated the web subsystem but not undertow.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:14 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1849) Provide complete model
 descriptions for undertow subsystem
In-Reply-To: <JIRA.12498234.1375963980000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498234.1375963980000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498234.1375963980000.14840.1380922934321@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1849:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Provide complete model descriptions for undertow subsystem
> ----------------------------------------------------------
>
>                 Key: WFLY-1849
>                 URL: https://issues.jboss.org/browse/WFLY-1849
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Domain Management, Web (Undertow)
>            Reporter: Heiko Braun
>            Assignee: Tomaz Cerar
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:14 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1837) manual module testoutput is a
 bit disturbing NPE and dependencies missing
In-Reply-To: <JIRA.12498051.1375789235000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498051.1375789235000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498051.1375789235000.14844.1380922934520@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1837:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> manual module testoutput is a bit disturbing NPE and dependencies missing
> -------------------------------------------------------------------------
>
>                 Key: WFLY-1837
>                 URL: https://issues.jboss.org/browse/WFLY-1837
>             Project: WildFly
>          Issue Type: Task
>          Components: Test Suite
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Bartosz Baranowski
>            Assignee: JBoss SET
>             Fix For: 8.0.0.CR1
>
>
> Manual testmodule shows a lot of NPEs and dependency issues:
> {noformat}
> [org.jboss.as.ejb3] (EJB default - 2) JBAS014249: Error invoking method public abstract void org.jboss.as.test.manualmode.ejb.shutdown.RemoteLatch.testDone() on bean named LatchBean for appname  modulename dep1 distinctname : java.lang.NullPointerException
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:322)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:70)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:203)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> 13:06:07,613 ERROR [org.jboss.as.ejb3] (EJB default - 2) JBAS014250: Could not write method invocation failure for method public abstract void org.jboss.as.test.manualmode.ejb.shutdown.RemoteLatch.testDone() on bean named LatchBean for appname  modulename dep1 distinctname  due to: java.io.IOException: Stream is closed
> 	at org.xnio.streams.BufferPipeOutputStream.closed(BufferPipeOutputStream.java:58) [xnio-api-3.1.0.CR3.jar:3.1.0.CR3]
> 	at org.xnio.streams.BufferPipeOutputStream.checkClosed(BufferPipeOutputStream.java:64) [xnio-api-3.1.0.CR3.jar:3.1.0.CR3]
> 	at org.xnio.streams.BufferPipeOutputStream.write(BufferPipeOutputStream.java:90) [xnio-api-3.1.0.CR3.jar:3.1.0.CR3]
> 	at org.jboss.remoting3.remote.OutboundMessage.write(OutboundMessage.java:252)
> 	at java.io.DataOutputStream.write(DataOutputStream.java:107) [rt.jar:1.7.0_25]
> 	at org.jboss.as.ejb3.remote.protocol.AbstractMessageHandler$1.write(AbstractMessageHandler.java:217)
> 	at org.jboss.marshalling.OutputStreamByteOutput.write(OutputStreamByteOutput.java:56)
> 	at org.jboss.marshalling.SimpleDataOutput.shallowFlush(SimpleDataOutput.java:328)
> 	at org.jboss.marshalling.river.RiverMarshaller.writeString(RiverMarshaller.java:1451)
> 	at org.jboss.marshalling.river.RiverMarshaller.writeNewSerializableClass(RiverMarshaller.java:1362)
> 	at org.jboss.marshalling.river.RiverMarshaller.writeSerializableClass(RiverMarshaller.java:1345)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:883)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
> 	at org.jboss.marshalling.river.RiverObjectOutputStream.defaultWriteObject(RiverObjectOutputStream.java:159)
> 	at java.lang.Throwable.writeObject(Throwable.java:984) [rt.jar:1.7.0_25]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_25]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_25]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_25]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_25]
> 	at org.jboss.marshalling.reflect.SerializableClass.callWriteObject(SerializableClass.java:180)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1007)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:998)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:998)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:998)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> 	at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62)
> 	at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119)
> 	at org.jboss.as.ejb3.remote.protocol.AbstractMessageHandler.writeException(AbstractMessageHandler.java:112)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$400(MethodInvocationMessageHandler.java:70)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:213)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> Caused by: an exception which occurred:
> 	in field suppressedExceptions
> 	in object java.lang.NullPointerException at 18e5c476
> {noformat}
> {noformat}
> 13:01:23,032 ERROR [org.jboss.as.controller.management-operation] (pool-2-thread-1) JBAS014612: Operation ("add") failed - address: ([
>     ("host" => "master"),
>     ("core-service" => "management"),
>     ("management-interface" => "http-interface")
> ]): java.lang.NullPointerException
> 	at org.jboss.as.host.controller.operations.HttpManagementAddHandler.installHttpManagementServices(HttpManagementAddHandler.java:137) [wildfly-host-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
> 	at org.jboss.as.host.controller.operations.HttpManagementAddHandler.performRuntime(HttpManagementAddHandler.java:97) [wildfly-host-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:75) [wildfly-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
> {noformat}
> {noformat}
> 13:01:23,493 ERROR [org.jboss.as.controller.management-operation] (pool-2-thread-1) JBAS014613: Operation ("add") failed - address: ([
>     ("core-service" => "management"),
>     ("management-interface" => "native-interface")
> ]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => [
>     "jboss.remoting.authentication_provider.management is missing [jboss.server.path.\"jboss.server.temp.dir\"]",
>     "jboss.remoting.endpoint.management.management.operation.handler is missing [jboss.as.server-controller]",
>     "jboss.remoting.endpoint.management.channel.management is missing [jboss.remoting.endpoint.management.shutdown.executor]",
>     "jboss.remoting.server.management is missing [jboss.binding.management-native, jboss.socket-binding-manager]"
> ]}
> 13:01:23,494 INFO  [org.jboss.as.controller] (pool-2-thread-1) JBAS014774: Service status report
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.as.server-controller (missing) dependents: [service jboss.remoting.endpoint.management.management.operation.handler] 
>       service jboss.binding.management-native (missing) dependents: [service jboss.remoting.server.management] 
>       service jboss.remoting.endpoint.management.shutdown.executor (missing) dependents: [service jboss.remoting.endpoint.management.channel.management] 
>       service jboss.server.path."jboss.server.temp.dir" (missing) dependents: [service jboss.remoting.authentication_provider.management] 
>       service jboss.socket-binding-manager (missing) dependents: [service jboss.remoting.server.management] 
> 13:01:23,495 INFO  [org.jboss.as.server] (pool-2-thread-1) JBAS015888: Creating http management service using socket-binding (management-http)
> 13:01:23,496 ERROR [org.jboss.as.controller.management-operation] (pool-2-thread-1) JBAS014612: Operation ("add") failed - address: ([
>     ("core-service" => "management"),
>     ("management-interface" => "http-interface")
> ]): org.jboss.msc.service.ServiceNotFoundException: Service service jboss.server.environment not found
> 	at org.jboss.msc.service.ServiceContainerImpl.getRequiredService(ServiceContainerImpl.java:668) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at org.jboss.as.controller.OperationContextImpl$OperationContextServiceRegistry.getRequiredService(OperationContextImpl.java:1068) [wildfly-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:14 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1836) manual module
 SSLEJBRemoteClientTestCase keeps freezing
In-Reply-To: <JIRA.12498050.1375789021000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498050.1375789021000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498050.1375789021000.14848.1380922934747@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1836:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> manual module SSLEJBRemoteClientTestCase keeps freezing
> -------------------------------------------------------
>
>                 Key: WFLY-1836
>                 URL: https://issues.jboss.org/browse/WFLY-1836
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Bartosz Baranowski
>            Assignee: JBoss SET
>             Fix For: 8.0.0.CR1
>
>
> CI job keeps freezing on this test. In local run, it does not fail however:
> execution in batch: 102s+
> standalone        : ~45s

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:14 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:14 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1832) Wildfly High Availability
 Guide: Migration and Changes From Previous Versions write up
In-Reply-To: <JIRA.12497993.1375720397000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497993.1375720397000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497993.1375720397000.14851.1380922934900@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1832:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Wildfly High Availability Guide: Migration and Changes From Previous Versions write up 
> ---------------------------------------------------------------------------------------
>
>                 Key: WFLY-1832
>                 URL: https://issues.jboss.org/browse/WFLY-1832
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Clustering, Documentation
>            Reporter: Radoslav Husar
>             Fix For: 8.0.0.CR1
>
>
> https://docs.jboss.org/author/display/WFLY8/Changes+From+Previous+Versions

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:15 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:15 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1831) Wildfly High Availability
 Guide: Clustering Monitor subsystem write up
In-Reply-To: <JIRA.12497992.1375720334000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497992.1375720334000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497992.1375720334000.14855.1380922935086@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1831:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Wildfly High Availability Guide: Clustering Monitor subsystem write up
> ----------------------------------------------------------------------
>
>                 Key: WFLY-1831
>                 URL: https://issues.jboss.org/browse/WFLY-1831
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Clustering, Documentation
>            Reporter: Radoslav Husar
>            Assignee: Richard Achmatowicz
>             Fix For: 8.0.0.CR1
>
>
> https://docs.jboss.org/author/display/WFLY8/Clustering+Monitor+Subsystem

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:15 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:15 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1830) Wildfly High Availability
 Guide: Hibernate clustering write up
In-Reply-To: <JIRA.12497991.1375720255000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497991.1375720255000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497991.1375720255000.14859.1380922935271@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1830:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Wildfly High Availability Guide: Hibernate clustering write up
> --------------------------------------------------------------
>
>                 Key: WFLY-1830
>                 URL: https://issues.jboss.org/browse/WFLY-1830
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Clustering, Documentation
>            Reporter: Radoslav Husar
>            Assignee: Scott Marlow
>             Fix For: 8.0.0.CR1
>
>
> https://docs.jboss.org/author/display/WFLY8/Hibernate

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:15 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:15 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1827) Wildfly High Availability
 Guide: Clustered Single Sign-on (SSO) write up
In-Reply-To: <JIRA.12497988.1375720092000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497988.1375720092000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497988.1375720092000.14869.1380922935817@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1827:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Wildfly High Availability Guide: Clustered Single Sign-on (SSO) write up
> ------------------------------------------------------------------------
>
>                 Key: WFLY-1827
>                 URL: https://issues.jboss.org/browse/WFLY-1827
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Clustering, Documentation
>            Reporter: Radoslav Husar
>             Fix For: 8.0.0.CR1
>
>
> https://docs.jboss.org/author/display/WFLY8/Clustered+SSO

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:15 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:15 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1828) Wildfly High Availability
 Guide: Load-balancing (LB) and mod_cluster write up
In-Reply-To: <JIRA.12497989.1375720158000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497989.1375720158000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497989.1375720158000.14866.1380922935636@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1828:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Wildfly High Availability Guide: Load-balancing (LB) and mod_cluster write up
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-1828
>                 URL: https://issues.jboss.org/browse/WFLY-1828
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Clustering, Documentation
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.CR1
>
>
> https://docs.jboss.org/author/display/WFLY8/Load+Balancing

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:16 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:16 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1825) Wildfly High Availability
 Guide: Infinispan write up
In-Reply-To: <JIRA.12497986.1375719976000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497986.1375719976000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497986.1375719976000.14875.1380922936140@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1825:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Wildfly High Availability Guide: Infinispan write up
> ----------------------------------------------------
>
>                 Key: WFLY-1825
>                 URL: https://issues.jboss.org/browse/WFLY-1825
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Clustering, Documentation
>            Reporter: Radoslav Husar
>             Fix For: 8.0.0.CR1
>
>
> https://docs.jboss.org/author/display/WFLY8/Infinispan+Subsystem

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:15 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:15 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1826) Wildfly High Availability
 Guide: Clustered Web Sessions write up
In-Reply-To: <JIRA.12497987.1375720036000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497987.1375720036000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497987.1375720036000.14872.1380922935955@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1826:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Wildfly High Availability Guide: Clustered Web Sessions write up
> ----------------------------------------------------------------
>
>                 Key: WFLY-1826
>                 URL: https://issues.jboss.org/browse/WFLY-1826
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Clustering, Documentation
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.CR1
>
>
> https://docs.jboss.org/author/display/WFLY8/Clustered+Web+Sessions

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:16 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:16 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1824) Wildfly High Availability
 Guide: JGroups write up
In-Reply-To: <JIRA.12497985.1375719930000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497985.1375719930000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497985.1375719930000.14879.1380922936397@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1824:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Wildfly High Availability Guide: JGroups write up
> -------------------------------------------------
>
>                 Key: WFLY-1824
>                 URL: https://issues.jboss.org/browse/WFLY-1824
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Clustering, Documentation
>            Reporter: Radoslav Husar
>            Assignee: Richard Achmatowicz
>             Fix For: 8.0.0.CR1
>
>
> https://docs.jboss.org/author/display/WFLY8/JGroups+Subsystem

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:16 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:16 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1745) WeldServices may get into
 inconsistent state
In-Reply-To: <JIRA.12497125.1374581825000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497125.1374581825000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497125.1374581825000.14889.1380922936919@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1745:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> WeldServices may get into inconsistent state
> --------------------------------------------
>
>                 Key: WFLY-1745
>                 URL: https://issues.jboss.org/browse/WFLY-1745
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Jozef Hartinger
>            Assignee: Jozef Hartinger
>             Fix For: 8.0.0.CR1
>
>
> WeldBootstrapService performs an initial bootstrap of the Weld container and also performs Weld shutdown when the service is stopping.
> WeldStartService finishes initialization of Weld container and performs nothing on stop() (WeldBootstrapService is expected to shut down Weld).
> WeldStartService has a dependency on WeldBootstrapService.
> This works fine 99% of the time. However, if a dependency of WeldStartService is restarted (e.g. due to management operation), WeldStartService as its parent is also restarted but WeldBootstrapService is not. 
> As a result, WeldStartService expects to find Weld container in an early initialization phase and wants to finish initialization. However, since WeldBootstrapService was not restarted, the Weld container is still in the initialized state and deployment fails when WSS tries to finish initialization again.
> To reproduce modify EjbRemoveUnitTestCase for test-session-remove.jar to contain empty beans.xml file.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:16 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:16 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1801) Allow remoting endpoint
 options to be configurable
In-Reply-To: <JIRA.12497756.1375358657000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497756.1375358657000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497756.1375358657000.14885.1380922936748@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1801:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Allow remoting endpoint options to be configurable
> --------------------------------------------------
>
>                 Key: WFLY-1801
>                 URL: https://issues.jboss.org/browse/WFLY-1801
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Remoting
>            Reporter: jaikiran pai
>            Assignee: Tomaz Cerar
>             Fix For: 8.0.0.CR1
>
>
> Currently, there's no way the remoting endpoint creation options can be configured. 
> I see a TODO https://github.com/wildfly/wildfly/blob/master/remoting/src/main/java/org/jboss/as/remoting/RemotingSubsystemAdd.java#L78 which seems to have remained unimplemented. 
> For now, the only endpoint point options that are passed are hardcoded from here https://github.com/wildfly/wildfly/blob/master/remoting/src/main/java/org/jboss/as/remoting/EndpointConfigFactory.java#L46.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:17 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:17 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1725) Update The Wildfly High
	Availability Guide
In-Reply-To: <JIRA.12496926.1374260551000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496926.1374260551000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496926.1374260551000.14896.1380922937280@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1725:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Update The Wildfly High Availability Guide 
> -------------------------------------------
>
>                 Key: WFLY-1725
>                 URL: https://issues.jboss.org/browse/WFLY-1725
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>             Fix For: 8.0.0.CR1
>
>
> The main source of clustering-related documentation for a Wildfly user is the High Availability Guide in the Wildfly 8 documentation on docs.jboss.org.
> Update this document into a quality document which will aid the user's understanding of new features and configuration in Wildfly 8 clustering.
> https://docs.jboss.org/author/display/WFLY8/High+Availability+Guide

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:17 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:17 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1702) Investigate module wiring
 consistency at build time
In-Reply-To: <JIRA.12496527.1373967646000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496527.1373967646000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496527.1373967646000.14899.1380922937515@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1702:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Investigate module wiring consistency at build time
> ---------------------------------------------------
>
>                 Key: WFLY-1702
>                 URL: https://issues.jboss.org/browse/WFLY-1702
>             Project: WildFly
>          Issue Type: Task
>          Components: Build System
>            Reporter: Thomas Diesler
>            Assignee: Thomas Diesler
>             Fix For: 8.0.0.CR1
>
>
> Due to the use of human wiring decisions it is possible that the initial modules wiring setup is incomplete/inconsistent. Various inconsistencies can occur 
> * There are code paths in a module that require a class load for which there is no dependency defined
> * Modules define (stale) dependencies that are never used
> * Modules define dependencies that are inconsistent in the class space

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:17 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:17 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1594) Domain Management logout
 'feature' not working for HTTP BASIC authentication.
In-Reply-To: <JIRA.12495179.1372271000000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495179.1372271000000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495179.1372271000000.14904.1380922937782@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1594:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Domain Management logout 'feature' not working for HTTP BASIC authentication.
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-1594
>                 URL: https://issues.jboss.org/browse/WFLY-1594
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> The logout capability assumes Digest authentication, where we have used LDAP for authentication we only use BASIC authentication.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:06 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2220) Unable to reload server after
 adding role and executing :reload
In-Reply-To: <JIRA.12502221.1380896422000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502221.1380896422000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502221.1380896422000.14674.1380922926480@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2220:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Unable to reload server after adding role and executing :reload
> ---------------------------------------------------------------
>
>                 Key: WFLY-2220
>                 URL: https://issues.jboss.org/browse/WFLY-2220
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.CR1
>
>
> Start a clean build of WildFly 8 and execute the following commands in the CLI: -
> {code}
> [standalone at localhost:9990 /connect
> [standalone at localhost:9990 /] ./core-service=management/access=authorization/role-mapping=Operator:add
> {"outcome" => "success"}
> [standalone at localhost:9990 /] :reload
> {
>     "outcome" => "success",
>     "result" => undefined
> }
> [standalone at localhost:9990 /] 
> {code}
> Results in the following error and the server shuts down: -
> {code}
> 15:15:02,275 INFO  [org.jboss.as.server] (Controller Boot Thread) JBAS015888: Creating http management service using socket-binding (management-http)
> 15:15:02,278 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014612: Operation ("add") failed - address: ([
>     ("core-service" => "management"),
>     ("access" => "authorization"),
>     ("role-mapping" => "SuperUser")
> ]): java.lang.UnsupportedOperationException
> 	at java.util.Collections$UnmodifiableMap.put(Collections.java:1342) [rt.jar:1.7.0_17]
> 	at org.jboss.as.controller.access.management.WritableAuthorizerConfiguration.addRoleMappingImmediate(WritableAuthorizerConfiguration.java:163) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.domain.management.access.RoleMappingAdd$1.execute(RoleMappingAdd.java:76) [wildfly-domain-management-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:609) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:487) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:321) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:290) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:356) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:331) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:252) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> 15:15:02,287 INFO  [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.remoting.endpoint.management (missing) dependents: [service jboss.remoting.management.channel.registry] 
> 15:15:02,290 FATAL [org.jboss.as.server] (Controller Boot Thread) JBAS015957: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> 15:15:02,297 INFO  [org.jboss.as] (MSC service thread 1-1) JBAS015950: WildFly 8.0.0.Beta1-SNAPSHOT "WildFly" stopped in 2ms
> {code}
> What is interesting is that the server is manually startable to something has gone wrong regarding resetting the runtime state of RBAC at the time of the reload.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:06 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2219) Update to console 2.0.3.Final
In-Reply-To: <JIRA.12502220.1380896072000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502220.1380896072000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502220.1380896072000.14677.1380922926628@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2219:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Update to console 2.0.3.Final
> -----------------------------
>
>                 Key: WFLY-2219
>                 URL: https://issues.jboss.org/browse/WFLY-2219
>             Project: WildFly
>          Issue Type: Task
>          Components: Web Console
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:06 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2216) include-all role mappings
 don't work in domain
In-Reply-To: <JIRA.12502198.1380887272000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502198.1380887272000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502198.1380887272000.14682.1380922926837@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2216:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> include-all role mappings don't work in domain
> ----------------------------------------------
>
>                 Key: WFLY-2216
>                 URL: https://issues.jboss.org/browse/WFLY-2216
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Ladislav Thon
>            Assignee: Darran Lofthouse
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.CR1
>
>
> If I understand correctly, roles that have {{include-all=true}} in their role mappings should be added to all authenticated users. In my tests, though, this only works in standalone mode.
> In domain mode, if I set a role mapping to {{include-all}}, this setting is not reflected (at least not immediately; maybe it would work after restart, but that's wrong anyway). It doesn't matter which role is set to be {{include-all}} -- in my tests, I use both standard roles and scoped roles and it consistently doesn't work. There's probably some wrong caching going on.
> The failing test case is in my pull request https://github.com/wildfly/wildfly/pull/5166 (it's the _RBAC tests for include-all role mappings in domain_ commit). If it's more convenient, the pull request is the same as my _rbac_ branch (https://github.com/Ladicek/wildfly/commits/rbac).
> Darran, I'm not sure if you are the right assignee -- please reassign if needed. Thanks.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:07 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2215) WorkManagerService does not
 start work manager
In-Reply-To: <JIRA.12502196.1380886644000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502196.1380886644000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502196.1380886644000.14686.1380922927044@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-2215:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> WorkManagerService does not start work manager
> ----------------------------------------------
>
>                 Key: WFLY-2215
>                 URL: https://issues.jboss.org/browse/WFLY-2215
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: JCA
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Bartosz Baranowski
>            Assignee: Stefano Maestri
>             Fix For: 8.0.0.CR1
>
>
> WorkManagerService does not start/restart WorkManager
> https://github.com/wildfly/wildfly/blob/master/connector/src/main/java/org/jboss/as/connector/services/workmanager/WorkManagerService.java#L76
> WorkManager is set in constructor. In stop method, WorkManager.shutdown() is called. start() should invoke WorkManager.cancelShutdown().

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:15 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:15 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1829) Wildfly High Availability
 Guide: EJB Services/Subsystem write up
In-Reply-To: <JIRA.12497990.1375720208000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497990.1375720208000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497990.1375720208000.14862.1380922935461@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1829:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Wildfly High Availability Guide: EJB Services/Subsystem write up
> ----------------------------------------------------------------
>
>                 Key: WFLY-1829
>                 URL: https://issues.jboss.org/browse/WFLY-1829
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Clustering, Documentation
>            Reporter: Radoslav Husar
>             Fix For: 8.0.0.CR1
>
>
> https://docs.jboss.org/author/display/WFLY8/EJB+Subsystem

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:18 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1592) Attempting to use eap6.1
 jboss-cli.sh to connect to remote wildfly (alpha1 or 2) fails;
 credentials not accepted
In-Reply-To: <JIRA.12495153.1372256939000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495153.1372256939000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495153.1372256939000.14914.1380922938247@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1592:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Attempting to use eap6.1 jboss-cli.sh to connect to remote wildfly (alpha1 or 2) fails; credentials not accepted
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1592
>                 URL: https://issues.jboss.org/browse/WFLY-1592
>             Project: WildFly
>          Issue Type: Bug
>          Components: Remoting, Security
>    Affects Versions: 8.0.0.Alpha2
>            Reporter: Rob Stryker
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Using eap6.1 client jars, or the jboss-cli.sh script in a local eap6.1 installation, to connect to a remote wildfly alpha1 or alpha2, seems to work but fails when provided with credentials.  This is most easily replicated as follows:
> 1) On remote machine start wildfly alpha1 or alpha2
> 2) on local machine, cd eap-6.1/bin
> 3) on local machine:
> [rob at rawbdor bin]$ ./jboss-cli.sh 
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
> [disconnected /] connect myhost.net 
> Authenticating against security realm: ManagementRealm
> Username: admin
>  Password: 
> Unable to authenticate against controller at myhost.net:9999: Authentication failed: all available authentication mechanisms failed
> This is an issue for tools as we need a set of jars that communicates correctly with all as7 servers. We currently have a set of jars that communicates with all 7.x / eap 6.x, which is good. If this is merely a bug on the server, then we can hopefully delay having to bundle an additional set of client jars until larger breakages occur. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:18 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1536) Hangs in mixed domain
	testsuite
In-Reply-To: <JIRA.12494340.1371247934000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494340.1371247934000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494340.1371247934000.14926.1380922938744@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1536:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Hangs in mixed domain testsuite
> -------------------------------
>
>                 Key: WFLY-1536
>                 URL: https://issues.jboss.org/browse/WFLY-1536
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>         Attachments: testsuite-hang1-server.txt, testsuite-hang2-client.txt, testsuite-hang2-server.txt
>
>
> http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/wildfly-param-pull/7449/console
> https://dl.dropboxusercontent.com/u/712508/mixed-hang-debug.zip contains details.
> 30805.dump is the client and shows the problem is occurring in the @After cleanup of MixedDomainDeploymentTest as it removes deployments from the domain.
> "main" prio=10 tid=0xf7605c00 nid=0x7856 in Object.wait() [0xf776e000]
>    java.lang.Thread.State: WAITING (on object monitor)
> 	at java.lang.Object.wait(Native Method)
> 	- waiting on <0xe50275f0> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> 	at java.lang.Object.wait(Object.java:503)
> 	at org.jboss.threads.AsyncFutureTask.await(AsyncFutureTask.java:192)
> 	- locked <0xe50275f0> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> 	at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:266)
> 	- locked <0xe50275f0> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> 	at org.jboss.as.controller.client.impl.AbstractDelegatingAsyncFuture.get(AbstractDelegatingAsyncFuture.java:100)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71)
> 	at org.jboss.as.controller.client.helpers.domain.impl.DomainClientImpl.execute(DomainClientImpl.java:81)
> 	at org.jboss.as.test.integration.domain.mixed.MixedDomainDeploymentTest.removeDeployment(MixedDomainDeploymentTest.java:441)
> 	at org.jboss.as.test.integration.domain.mixed.MixedDomainDeploymentTest.cleanDeployments(MixedDomainDeploymentTest.java:343)
> 	at org.jboss.as.test.integration.domain.mixed.MixedDomainDeploymentTest.confirmNoDeployments(MixedDomainDeploymentTest.java:163)
> 31894.dump shows the master HC. management-handler-thread is blocking on the way out (after sending the commit or rollback) waiting for a final result response from the slave.
> "management-handler-thread - 1" prio=10 tid=0xca0efc00 nid=0x7cdd in Object.wait() [0xc7469000]
>    java.lang.Thread.State: WAITING (on object monitor)
> 	at java.lang.Object.wait(Native Method)
> 	- waiting on <0xeb6d6558> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> 	at java.lang.Object.wait(Object.java:503)
> 	at org.jboss.threads.AsyncFutureTask.await(AsyncFutureTask.java:192)
> 	- locked <0xeb6d6558> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> 	at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:266)
> 	- locked <0xeb6d6558> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> 	at org.jboss.as.controller.client.impl.AbstractDelegatingAsyncFuture.get(AbstractDelegatingAsyncFuture.java:100)
> 	at org.jboss.as.domain.controller.operations.coordination.DomainSlaveHandler.finalizeOp(DomainSlaveHandler.java:215)
> 	at org.jboss.as.domain.controller.operations.coordination.DomainSlaveHandler.access$000(DomainSlaveHandler.java:58)
> 	at org.jboss.as.domain.controller.operations.coordination.DomainSlaveHandler$1.handleResult(DomainSlaveHandler.java:179)
> 	at org.jboss.as.controller.AbstractOperationContext$Step.handleRollback(AbstractOperationContext.java:805)
> 	at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:763)
> 	at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:738)
> (Note that the "handleRollback" method name is a red-herring -- the method should be renamed to a "handleResult" as it now is called no matter what the result.)
> 31986.dump is the slave HC. It shows it is blocking in stage DONE after having sent operationPrepared to the master, waiting for commit or rollback.
> "domain-connection-threads - 1" prio=10 tid=0xc91a8400 nid=0x7d1a waiting on condition [0xc87fe000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0xea1fd410> (a java.util.concurrent.CountDownLatch$Sync)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
> 	at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:236)
> 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ProxyOperationControlProxy.operationPrepared(TransactionalProtocolOperationHandler.java:173)
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:337)
> 	at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:211)
> 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.execute(ServerOperationsResolverHandler.java:128)
> Indication is the commit or rollback message is getting lost. There are no threads shown sending or receiving it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:18 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1588) Run CTS batch tests inside
	WildFly
In-Reply-To: <JIRA.12495119.1372216191000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495119.1372216191000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495119.1372216191000.14917.1380922938409@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1588:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Run CTS batch tests inside WildFly
> ----------------------------------
>
>                 Key: WFLY-1588
>                 URL: https://issues.jboss.org/browse/WFLY-1588
>             Project: WildFly
>          Issue Type: Task
>          Components: EE
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Cheng Fang
>            Assignee: Cheng Fang
>             Fix For: 8.0.0.CR1
>
>
> Run CTS batch tests (web- and ejb-vehicle tests) inside WildFly.
> Instructions for running cts7 against WildFly:
> https://community.jboss.org/wiki/TCK7Guide
> A related page, on how to run javax.batch standalone TCK with JBeret:
> https://github.com/jberet/jsr352/wiki/Batch-TCK-with-JBeret

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:18 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1568) Cannot reliably reinstall
 service with same name
In-Reply-To: <JIRA.12494816.1371799050000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494816.1371799050000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494816.1371799050000.14922.1380922938582@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1568:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Cannot reliably reinstall service with same name
> ------------------------------------------------
>
>                 Key: WFLY-1568
>                 URL: https://issues.jboss.org/browse/WFLY-1568
>             Project: WildFly
>          Issue Type: Bug
>          Components: MSC
>            Reporter: Thomas Diesler
>            Assignee: David Lloyd
>             Fix For: 8.0.0.CR1
>
>
> There seems to be an undefined "cleanup period" needed, before a service with the same name can be installed successfully. If you do the below in the same thread it will always fail (I believe). 
> {code}
> controller.setMode(Mode.REMOVE)
> serviceTarget.addService(controller.getName(), service).install()
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:18 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1535) SSLEJBRemoteClientTestCase
 runs into intermittent failures
In-Reply-To: <JIRA.12494315.1371223824000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494315.1371223824000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494315.1371223824000.14929.1380922938920@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1535:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> SSLEJBRemoteClientTestCase runs into intermittent failures
> ----------------------------------------------------------
>
>                 Key: WFLY-1535
>                 URL: https://issues.jboss.org/browse/WFLY-1535
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>            Priority: Critical
>             Fix For: 8.0.0.CR1
>
>
> SSLEJBRemoteClientTestCase runs into intermittent failures on TeamCity. To make matters worse, a failure in one test method can have a side effect on other test methods in that testcase, given the way it's written. The entire run is here http://teamcity.cafe-babe.org/viewLog.html?buildId=5251&tab=buildResultsDiv&buildTypeId=bt27.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:19 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1525) Filesystem JAR permission
	processing
In-Reply-To: <JIRA.12494245.1371164451000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494245.1371164451000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494245.1371164451000.14932.1380922939010@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1525:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Filesystem JAR permission processing
> ------------------------------------
>
>                 Key: WFLY-1525
>                 URL: https://issues.jboss.org/browse/WFLY-1525
>             Project: WildFly
>          Issue Type: Task
>          Components: Security Manager
>            Reporter: David Lloyd
>             Fix For: 8.0.0.CR1
>
>
> Parse {{jboss-permission.xml}} files found in filesystem and (old-style) extension JARs to establish their base permission set.  If no such file is found then default to the minimal permission set.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:19 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1523) Addition of caching for
 backing store access used by realms.
In-Reply-To: <JIRA.12494223.1371139969000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494223.1371139969000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494223.1371139969000.14935.1380922939167@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1523:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Addition of caching for backing store access used by realms.
> ------------------------------------------------------------
>
>                 Key: WFLY-1523
>                 URL: https://issues.jboss.org/browse/WFLY-1523
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.CR1
>
>
> For JAAS this is achieved by caching keyed on the combination of the username and the password, once we switch to the CallbackHandler approach this is no longer applicable as there is often not a single username/credential combination - instead a protocol specific exchange is used to establish the identity of the remote user.
> Any cache would also potentially require: -
>  - Predicable eviction.
>  - Management Operations e.g. clear entire cache, remove single entries etc...
>  - Separation of caches for authenticiation data and additional data loaded for authorization purposes.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:19 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1509) Test transformation of jmx
 audit log resources against AS 7.2.0 (ModelVersion 1.2.0)
In-Reply-To: <JIRA.12494127.1371057415000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494127.1371057415000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494127.1371057415000.14938.1380922939333@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1509:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Test transformation of jmx audit log resources against AS 7.2.0 (ModelVersion 1.2.0)
> ------------------------------------------------------------------------------------
>
>                 Key: WFLY-1509
>                 URL: https://issues.jboss.org/browse/WFLY-1509
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMX
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.CR1
>
>
> Do this once the artifacts are uploaded to maven, or the subsystem test stuff is changed to be able to use the internal maven repository for certain tests

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:19 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1492) Admin Console does not handle
 resource adapter address properly
In-Reply-To: <JIRA.12494007.1370947164000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494007.1370947164000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494007.1370947164000.14941.1380922939460@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1492:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Admin Console does not handle resource adapter address properly
> ---------------------------------------------------------------
>
>                 Key: WFLY-1492
>                 URL: https://issues.jboss.org/browse/WFLY-1492
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Bartosz Baranowski
>            Assignee: Bartosz Baranowski
>             Fix For: 8.0.0.CR1
>
>
> console seems to handle RA entities in a a bad way. Not sure if this is by design and I am the one missing something.
> In case of anonymous declaration( as per JCA specs ? ):
> <resource-adapters>
>     <resource-adapter>
>        <archive>test</archive>
>        <transaction-support>NoTransaction</transaction-support>
>    </resource-adapter>
> </resource-adapters>
> Name of adapter( in model ) is set to to "test" - archive name. However if there are more adapters, model names become:
> /subsystem=resource-adapters/resource-adapter=test
> /subsystem=resource-adapters/resource-adapter=test->1
> /subsystem=resource-adapters/resource-adapter=test->2
> ...
> /subsystem=resource-adapters/resource-adapter=test->n++
> Now, there is another trick. AS supports custom "ID":
> <resource-adapters>
>     <resource-adapter id="XXX">
>        <archive>test</archive>
>        <transaction-support>NoTransaction</transaction-support>
>    </resource-adapter>
> </resource-adapters>
> In this case the model address is "/subsystem=resource-adapters/resource-adapter=XXX".
> In case of second definition, console keeps displaying RA as "test" - since its the archive name. In case of definition with ID or one with '->#' this fails, since console depends on "getArchive()":
> https://github.com/hal/core/blob/master/gui/src/main/java/org/jboss/as/console/client/shared/subsys/jca/ResourceAdapterPresenter.java#L411
> This affects WFLY and all previous release.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:19 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:19 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1478) Enable CORS on the server side
In-Reply-To: <JIRA.12493871.1370725730000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493871.1370725730000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493871.1370725730000.14946.1380922939664@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1478:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Enable CORS on the server side
> ------------------------------
>
>                 Key: WFLY-1478
>                 URL: https://issues.jboss.org/browse/WFLY-1478
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Harald Pehl
>            Assignee: Harald Pehl
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:20 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1428) Extra resource root added to
	WARs
In-Reply-To: <JIRA.12493235.1369928499000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493235.1369928499000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493235.1369928499000.14954.1380922940061@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1428:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Extra resource root added to WARs
> ---------------------------------
>
>                 Key: WFLY-1428
>                 URL: https://issues.jboss.org/browse/WFLY-1428
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (JBoss Web), Web (Undertow)
>            Reporter: David Lloyd
>            Assignee: Remy Maucherat
>             Fix For: 8.0.0.CR1
>
>
> When the class path for WAR deployments is being assembled, it appears that the WAR's root is being added as a resource root.  This seems to be counter to spec; by default this should not be done.  Now that we have the ability to iterate class loader resources, this causes unusual things to be listed.
> Some users may desire this non-standard behavior though.  So, we should have a way (preferably simpler than {{jboss-deployment-structure.xml}}) to enable it; however in this case, the following paths *must* be excluded:
> * {{WEB-INF/lib}}
> * {{WEB-INF/classes}}
> * Any additional configured library or class directories
> * Any other nested, mounted JAR files

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:20 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1388) Cannot load module alias
 defined for root deployment
In-Reply-To: <JIRA.12492591.1369318979000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12492591.1369318979000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12492591.1369318979000.14958.1380922940242@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1388:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Cannot load module alias defined for root deployment
> ----------------------------------------------------
>
>                 Key: WFLY-1388
>                 URL: https://issues.jboss.org/browse/WFLY-1388
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>            Reporter: Thomas Diesler
>            Assignee: Thomas Diesler
>             Fix For: 8.0.0.CR1
>
>
> A module defined like this cannot get loaded by its module-alias
> {code}
> <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
>     <deployment>
>         <resources>
>             <resource-root path="wrapped-resource.jar"  use-physical-code-source="true"/>
>         </resources>
>         <dependencies>
>             <module name="javax.api"/>
>             <module name="javax.jms.api"/>
>             <module name="org.apache.camel.core"/>
>             <module name="org.springframework.beans"/>
>             <module name="org.springframework.context"/>
>             <module name="org.springframework.core"/>
>             <module name="org.springframework.jms"/>
>             <module name="org.springframework.transaction"/>
>             <module name="org.slf4j"/>
>         </dependencies>
>         <module-alias name="org.apache.camel.component.jms"/>
>     </deployment>
> </jboss-deployment-structure>
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:20 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1315) Evaluate making operation
 "composite" EntryType.PUBLIC
In-Reply-To: <JIRA.12491057.1367612465000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12491057.1367612465000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12491057.1367612465000.14962.1380922940429@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1315:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Evaluate making operation "composite" EntryType.PUBLIC
> ------------------------------------------------------
>
>                 Key: WFLY-1315
>                 URL: https://issues.jboss.org/browse/WFLY-1315
>             Project: WildFly
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> When the composite operation handler is registered, it's marked as EntryType.PRIVATE. This operation really isn't private; any reasonable management client will need to invoke it.
> Changing it may have some implications though; we need to evaluate those. The biggest is the operation metadata cannot be complete, because the step parameter elements cannot be fully described.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:20 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1312) Restore EJB3 tests that
 deploy duplicate test deployment
In-Reply-To: <JIRA.12491023.1367572765000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12491023.1367572765000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12491023.1367572765000.14966.1380922940704@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1312:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Restore EJB3 tests that deploy duplicate test deployment
> --------------------------------------------------------
>
>                 Key: WFLY-1312
>                 URL: https://issues.jboss.org/browse/WFLY-1312
>             Project: WildFly
>          Issue Type: Task
>          Components: EJB
>            Reporter: Thomas Diesler
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.CR1
>
>
> There are a number of EJB3 tests that [have been disabled|https://github.com/wildfly/wildfly/commit/a22ea284c7a7761e4626e165cd79359ed3a9f62a] because they deploy a duplicate test deployment

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:21 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:21 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1309) CLI: creating a server on a
 domain slave followed by setting a system property fails when done in batch
 mode
In-Reply-To: <JIRA.12490963.1367501363000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12490963.1367501363000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12490963.1367501363000.14973.1380922941068@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1309:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> CLI: creating a server on a domain slave followed by setting a system property fails when done in batch mode
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1309
>                 URL: https://issues.jboss.org/browse/WFLY-1309
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha1
>         Environment: wildfly build from a git clone on 2013-05-02
>            Reporter: Tom Fonteyne
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>         Attachments: host-domain-controller.xml, host-slave.xml
>
>
> Setup two boxes:
> - on one, run domain mode (full-ha) -> domain controller
> - on the other, configure host.xml to point to the DC, and run the host controller
> Now in CLI:
> # add the group:
> /server-group=slaves:add(profile=full-ha,socket-binding-group=full-ha-sockets)
> # create server and set a prop
> batch
> /host=slave1/server-config=i1:add(group=slaves,auto-start=false)
> /host=slave1/server-config=i1/system-property=env:add(value=dev)
> run-batch 
> results in:
> JBAS010839: Operation failed or was rolled back on all servers.
> Debugging (on EAP 6.0.1) showed the real reason:
> activeStep.response = (org.jboss.dmr.ModelNode) {
>      "outcome" => "failed",
>      "failure-description" => "JBAS010850: No handler for operation
> composite at address [
>      (\"host\" => \"slave1\"),
>      (\"server\" => \"i1\")
> ]",
>      "rolled-back" => true
> } 
> More debugging led to :
> org.jboss.as.controller.AbstractOperationContext
> seems to be where the rollback is set. When debugging, I found that the constructor always sets
>      ModelController.OperationTransactionControl transactionControl
> but at line 332 (eap 6.0.1) / line 372 (wildfly), the end of doCompleteStep() :
>         // Allow any containing TransactionControl to vote
>         final AtomicReference<ResultAction> ref = new AtomicReference<ResultAction>(transactionControl == null ? ResultAction.KEEP : ResultAction.ROLLBACK);
> and ref becomes a rollback.
> I "walked" pretty much of all the code going on in between. The bit where the config is getting persisted is successful.
> But I'm afraid I'm out of my depth as there is *a lot* going on to execute such a composite command :)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:21 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:21 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1014) Enable CORS
In-Reply-To: <JIRA.12488815.1365460947000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12488815.1365460947000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488815.1365460947000.14978.1380922941293@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1014:
-------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Enable CORS
> -----------
>
>                 Key: WFLY-1014
>                 URL: https://issues.jboss.org/browse/WFLY-1014
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Harald Pehl
>            Assignee: Harald Pehl
>             Fix For: 8.0.0.CR1
>
>
> We've been prototyping an alternative distribution channel for the console and have setup a demo that leverages the mozilla app store to deliver the AS7 web console to users:
> https://marketplace.firefox.com/app/kea/?src=mkt-search
> For this to work the AS needs to fully support CORS [1]. The general idea is that you can retrieve the console through a marketplace like the mozilla one (chrome would be another alternative) and connect to any domain controller, wether it runs locally or remotely.
> If want to give it shot, point four firefox browser to the marketplace URL, launch the app and connect to our CORS demo instance that runs on EC2:
> http://as7-preview.dyndns.org:9990
> user: admin
> pass: webstore123!
> [1] http://en.wikipedia.org/wiki/Cross-origin_resource_sharing

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:21 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:21 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-943) XML schema;
 use of elementFormDefault='unqualified'; cannot validate some documents
In-Reply-To: <JIRA.12473954.1346995775000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12473954.1346995775000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12473954.1346995775000.14985.1380922941562@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-943:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> XML schema; use of elementFormDefault='unqualified'; cannot validate some documents
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-943
>                 URL: https://issues.jboss.org/browse/WFLY-943
>             Project: WildFly
>          Issue Type: Bug
>          Components: Documentation
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Elias Ross
>             Fix For: 8.0.0.CR1
>
>         Attachments: jboss-deployment-structure.xml
>
>
> When attempting to write a (seemingly) valid jboss-deployment-structure.xml using the schema in ./docs, my document fails to validate.
> This is because of the settings used in the XSD. Have these XSDs been used to validate actual documents? By setting unqualified to 'qualified' then the documents will probably validate.
> $ git grep elementFormDefault..unqualified
> jboss-deployment-dependencies-1_0.xsd:            elementFormDefault="unqualified"
> jboss-deployment-structure-1_0.xsd:            elementFormDefault="unqualified"
> jboss-deployment-structure-1_1.xsd:            elementFormDefault="unqualified"
> jboss-deployment-structure-1_2.xsd:            elementFormDefault="unqualified"
> jboss-ejb-client_1_0.xsd:            elementFormDefault="unqualified"
> jboss-ejb-client_1_1.xsd:            elementFormDefault="unqualified"
> jboss-ejb-client_1_2.xsd:            elementFormDefault="unqualified"
> jboss-jpa_1_0.xsd:  elementFormDefault="unqualified" 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:21 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:21 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-768) Caused by:
 javax.sound.sampled.UnsupportedAudioFileException: could not get audio
 input stream from input stream
In-Reply-To: <JIRA.12484619.1360525888000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12484619.1360525888000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12484619.1360525888000.14990.1380922941822@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-768:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Caused by: javax.sound.sampled.UnsupportedAudioFileException: could not get audio input stream from input stream
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-768
>                 URL: https://issues.jboss.org/browse/WFLY-768
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>         Environment: windows 7 jdk1.6,eclipse juno,
>            Reporter: raky k
>            Assignee: Jason Greene
>              Labels: UnsupportedAudioFileException
>             Fix For: 8.0.0.CR1
>
>
> The application is working fine in the tomcat when deployed in the Jboss server it does not recognizes wav format and throws error Caused by: javax.sound.sampled.UnsupportedAudioFileException: could not get audio input stream from input stream
> The application is open source and can be found 
> http://sourceforge.net/projects/simplecaptcha/files/simplecaptcha-1.2-j2ee-sample.war/download 
> i have done below changes but still no luck. ( as advised on https://community.jboss.org/thread/197517   )
> "
> Darran is right, it requires to edit the modules/sun/jdk/main/modules.xml and add an entry for com.sun.media.
>  
> Moreover, copy the following files to modules/sun/jdk/main/service-loader-resources/META-INF/services/
> javax.sound.sampled.spi.AudioFileReader
> javax.sound.sampled.spi.AudioFileWriter
> javax.sound.sampled.spi.FormatConversionProvider
> javax.sound.sampled.spi.MixerProvider
> These files can be found inside /jre/lib/resources.jar of JDK, under /META-INF/services/  "

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:22 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-674) NPE in thread "vfs-shutdown"
In-Reply-To: <JIRA.12441752.1310661101000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12441752.1310661101000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12441752.1310661101000.15001.1380922942277@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-674:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> NPE in thread "vfs-shutdown" 
> -----------------------------
>
>                 Key: WFLY-674
>                 URL: https://issues.jboss.org/browse/WFLY-674
>             Project: WildFly
>          Issue Type: Bug
>          Components: VFS
>         Environment: 7.1.0.Alpha1 Jenkins build 1402
>            Reporter: Juergen Zimmermann
>            Assignee: David Lloyd
>             Fix For: 8.0.0.CR1
>
>
> When I shutdown a standalone server I'm getting a NPE. The shutdown command is:
> jboss-admin.bat --connect command=:shutdown
> Console log:
> ...
> 18:24:55,990 INFO  [org.jboss.as.logging] Restored bootstrap log handlers
> 18:24:55,990 INFO  [org.jboss.as.jmx.JMXConnectorService] JMX remote connector stopped
> 18:24:56,075 INFO  [org.jboss.osgi.framework.internal.HostBundleState] Bundle stopped: jboss-as-osgi-configadmin:7.1.0.Alpha1-SNAPSHOT
> 18:24:56,125 INFO  [org.jboss.osgi.framework.internal.HostBundleState] Bundle stopped: org.apache.felix.log:1.0.0
> 18:24:56,230 INFO  [org.apache.catalina.core.StandardContext] Container org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/] has not been started
> 18:24:56,286 INFO  [org.jboss.osgi.framework.internal.HostBundleState] Bundle stopped: org.apache.felix.configadmin:1.2.8
> 18:24:56,323 INFO  [org.jboss.osgi.framework.internal.HostBundleState] Bundle stopped: jboss-osgi-logging:1.0.0
> 18:24:56,330 INFO  [com.arjuna.ats.jbossatx] ARJUNA32018: Destroying TransactionManagerService
> 18:24:56,331 INFO  [com.arjuna.ats.jbossatx] ARJUNA32014: Stopping transaction recovery manager
> 18:24:56,368 ERROR [stderr] Exception in thread "vfs-shutdown" java.lang.NullPointerException
> 18:24:56,368 ERROR [stderr] 	at org.jboss.vfs.TempFileProvider$DeleteTask.run(TempFileProvider.java:151)
> 18:24:56,368 ERROR [stderr] 	at org.jboss.vfs.TempFileProvider.close(TempFileProvider.java:132)
> 18:24:56,368 ERROR [stderr] 	at org.jboss.osgi.vfs30.VirtualFileAdaptor30$2.run(VirtualFileAdaptor30.java:94)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:22 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-669) Use
 OperationBuilder.addFileAsAttachment in the ServerDeploymentManager and
 DomainDeploymentManager impls
In-Reply-To: <JIRA.12465538.1335978221000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12465538.1335978221000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12465538.1335978221000.15004.1380922942452@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-669:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Use OperationBuilder.addFileAsAttachment in the ServerDeploymentManager and DomainDeploymentManager impls
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-669
>                 URL: https://issues.jboss.org/browse/WFLY-669
>             Project: WildFly
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> The ServerDeploymentManager and DomainDeploymentManager interfaces allow users to pass in a File. Currently we immediate convert that File to a FileInputStream and use that IS in the resulting operation. That will force an in-memory copy. Instead, use the OperationBuilder.addFileAsAttachment method introduced in the parent task. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:22 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:22 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-543) Provide an operation to
 request service status report after server has been started
In-Reply-To: <JIRA.12437340.1305215444000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12437340.1305215444000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12437340.1305215444000.15011.1380922942900@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-543:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Provide an operation to request  service status report  after server has been started
> -------------------------------------------------------------------------------------
>
>                 Key: WFLY-543
>                 URL: https://issues.jboss.org/browse/WFLY-543
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Heiko Braun
>              Labels: console_prio
>             Fix For: 8.0.0.CR1
>
>
> For proper healthcare it would beneficial if I could verify the server status after it has been started. I.e. to catch these, which currently only appear in the server log:
> [Server:server-three] 17:48:26,636 INFO  [org.jboss.as.server] (MSC service thread 1-2) Service status report
> [Server:server-three]    New missing/unsatisfied dependencies:
> [Server:server-three]       service jboss.binding.http2 (missing)
> [Server:server-three] 
> [Server:server-three] 17:48:26,636 ERROR [org.jboss.as] (MSC service thread 1-4) JBoss AS 7.0.0.Beta4-SNAPSHOT "(TBD)" started (with errors) in 3893ms - Started 101 of 149 services (1 services failed or missing dependencies, 47 services are passive or on-demand)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:23 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-531) JSR-196 JASPIC 1.1 Support
In-Reply-To: <JIRA.12488516.1364997991000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12488516.1364997991000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488516.1364997991000.15017.1380922943303@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-531:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> JSR-196 JASPIC 1.1 Support
> --------------------------
>
>                 Key: WFLY-531
>                 URL: https://issues.jboss.org/browse/WFLY-531
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Security
>            Reporter: David Lloyd
>            Assignee: Stefan Guilhen
>             Fix For: 8.0.0.CR1
>
>
> Provide support for the 1.1 maintenance release of JASPIC.
> http://jcp.org/aboutJava/communityprocess/maintenance/jsr196/196ChangeLog.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:23 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-498) JGroups thread pool injection
In-Reply-To: <JIRA.12484011.1359735555000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12484011.1359735555000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12484011.1359735555000.15022.1380922943547@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-498:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> JGroups thread pool injection
> -----------------------------
>
>                 Key: WFLY-498
>                 URL: https://issues.jboss.org/browse/WFLY-498
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Clustering
>            Reporter: David Lloyd
>            Assignee: Flemming Harms
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:23 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-497) Infinispan thread pool
	injection
In-Reply-To: <JIRA.12484010.1359735542000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12484010.1359735542000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12484010.1359735542000.15026.1380922943690@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-497:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Infinispan thread pool injection
> --------------------------------
>
>                 Key: WFLY-497
>                 URL: https://issues.jboss.org/browse/WFLY-497
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Clustering
>            Reporter: David Lloyd
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:23 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-496) Web subsystem executor
 configuration integration
In-Reply-To: <JIRA.12484009.1359735451000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12484009.1359735451000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12484009.1359735451000.15029.1380922943864@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-496:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Web subsystem executor configuration integration
> ------------------------------------------------
>
>                 Key: WFLY-496
>                 URL: https://issues.jboss.org/browse/WFLY-496
>             Project: WildFly
>          Issue Type: Sub-task
>            Reporter: David Lloyd
>             Fix For: 8.0.0.CR1
>
>
> The web subsystem's executor injection mechanism needs to be replaced with an integrated executor configuration like JCA did.  This must be done in the next rev of the subsystem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:24 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-485) Review SecurityContext
	associations
In-Reply-To: <JIRA.12465486.1335956357000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12465486.1335956357000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12465486.1335956357000.15038.1380922944281@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-485:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Review SecurityContext associations 
> ------------------------------------
>
>                 Key: WFLY-485
>                 URL: https://issues.jboss.org/browse/WFLY-485
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: David Lloyd
>              Labels: Security_SPI
>             Fix For: 8.0.0.CR1
>
>
> We should re-review the approach we take for security context association within AS7 containers.
> Back at the time of AS 3 it fairly reliable to assume a 1:1 mapping of thread and client with the incoming connection being allocated it's own thread, this is no longer automatically the case and different containers can use different threading models e.g. using Executors to handle asynchronous requests.
> The problem with using a ThreadLocal approach is that every time a container diverges from the 1:1 mapping of thread and client that container needs to work around the issue of an invalid SecurityContext association.
> One possibility is to pass responsibility for managing the context to the container although this then introduces the question of how it is passed from container to container.  This issue needs to consider this further.  
> Also need to review further how the security context can be created at all entry points to the server and how it can be manually switched now that we use SASL on entry for remote calls we do now have the opportunity for equivalent behaviour at the entry point for both web and ejb type calls - in the past we only had this opportunity for web based calls and would only create a security context on entering the interceptors for the EJB calls.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:24 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-479) Ability to rollback AS version
	updates
In-Reply-To: <JIRA.12413605.1277842200000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12413605.1277842200000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12413605.1277842200000.15042.1380922944479@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-479:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Ability to rollback AS version updates
> --------------------------------------
>
>                 Key: WFLY-479
>                 URL: https://issues.jboss.org/browse/WFLY-479
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> This JIRA is based on feedback we received after the Andiamo BOF at JBoss World 2010:
> >> A fixpack installer that handles version rollbacks would be fantastic.
> >> Of course it needs to remain flexible to work with JBoss installs that
> >> have been manually modified.
> Note that this may be out of scope for community AS 7; e.g. it may be a JON function. However, the AS 7 design of things like how we lay down content on the filesystem should take this use case into account.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:24 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-473) Get rid of external .index
	files
In-Reply-To: <JIRA.12487057.1363099573000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12487057.1363099573000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487057.1363099573000.15046.1380922944642@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-473:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Get rid of external .index files
> --------------------------------
>
>                 Key: WFLY-473
>                 URL: https://issues.jboss.org/browse/WFLY-473
>             Project: WildFly
>          Issue Type: Task
>          Components: Build System
>            Reporter: David Lloyd
>             Fix For: 8.0.0.CR1
>
>
> The external {{*.index}} files have become a problem for distribution.  In 8 we should switch to using internal {{META-INF/PATHS.LIST}} files.  These files should be embedded during build.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:25 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-469) Parent Issue for Java EE 7
	Support
In-Reply-To: <JIRA.12485198.1361307312000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485198.1361307312000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485198.1361307312000.15070.1380922945781@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-469:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Parent Issue for Java EE 7 Support
> ----------------------------------
>
>                 Key: WFLY-469
>                 URL: https://issues.jboss.org/browse/WFLY-469
>             Project: WildFly
>          Issue Type: Task
>          Components: EE
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>            Priority: Critical
>             Fix For: 8.0.0.CR1
>
>
> This is the parent issue for tracking tasks related to completing our Java EE 7 support.  Do not close the issue unless Jason has given his blessing.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:26 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-468) Report master SHA1 before pull
 request gets rebased
In-Reply-To: <JIRA.12469873.1341382282000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12469873.1341382282000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12469873.1341382282000.15075.1380922946017@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-468:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Report master SHA1 before pull request gets rebased
> ---------------------------------------------------
>
>                 Key: WFLY-468
>                 URL: https://issues.jboss.org/browse/WFLY-468
>             Project: WildFly
>          Issue Type: Task
>          Components: Test Suite
>            Reporter: Thomas Diesler
>            Assignee: Tomaz Cerar
>             Fix For: 8.0.0.CR1
>
>
> For a successful merge like [this|http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-param-pull/2943/] I see 
> {code}
> + git init
> Initialized empty Git repository in /home/jenkins/jenkins-work/workspace/as7-param-pull/.git/
> + git config user.email jenkins at example.com
> + git config user.name 'Mr. Jenkins'
> + git remote add origin git://github.com/jbossas/jboss-as.git
> + git fetch origin master:refs/remotes/origin/master
> From git://github.com/jbossas/jboss-as
>  * [new branch]      master     -> origin/master
> From git://github.com/jbossas/jboss-as
> ...
>  * [new tag]         7.1.2.Final -> 7.1.2.Final
> + git fetch origin refs/pull/2593/head
> From git://github.com/jbossas/jboss-as
>  * branch            refs/pull/2593/head -> FETCH_HEAD
> + git checkout FETCH_HEAD
> ...
> Checking out files: 100% (9519/9519), done.
> Note: checking out 'FETCH_HEAD'.
> You are in 'detached HEAD' state. You can look around, make experimental
> changes and commit them, and you can discard any commits you make in this
> state without impacting any branches by performing another checkout.
> If you want to create a new branch to retain commits you create, you may
> do so (now or later) by using -b with the checkout command again. Example:
>   git checkout -b new_branch_name
> HEAD is now at 3a64ae5... [AS7-5052] Allow WAR deployments as OSGi bundles
> + git rebase origin/master
> First, rewinding head to replay your work on top of it...
> Applying: [AS7-4918] Registered module using OSGi capability not visible as a bundle
> Applying: [AS7-5049] Allow bundles to get resolved/activated during deployment unit processing
> Applying: [AS7-5104] Remove no-start behaviour for test bundle deployments
> Applying: [AS7-5093] Allow JDBC driver deployments as OSGi bundles
> Applying: [AS7-5052] Allow WAR deployments as OSGi bundles
> {code}
> This tells me that the rebase was ok, but not onto what master revision it happened. Hence I cannot reproduce this run locally.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:26 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-465) Attribute
 check-for-live-server must set on live server to faillback
In-Reply-To: <JIRA.12484192.1360143797000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12484192.1360143797000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12484192.1360143797000.15081.1380922946278@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-465:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Attribute check-for-live-server must set on live server to faillback
> --------------------------------------------------------------------
>
>                 Key: WFLY-465
>                 URL: https://issues.jboss.org/browse/WFLY-465
>             Project: WildFly
>          Issue Type: Task
>          Components: JMS
>            Reporter: Miroslav Novak
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.CR1
>
>         Attachments: standalone-full-ha-backup.xml, standalone-full-ha-live.xml
>
>
> When there is live/backup pair with replicated journal then it should be sufficient to set attribute "check-for-live-server" in messaging subsystem only on backup to force backup server to shutdown when live server comes alive again. Problem is this won't happen.
> Only when attribute "check-for-live-server" is set on live server then failback is successful (backup shutdown itself)
> It's not well documented where "check-for-live-server" should be set in HornetQ project documentation:
> http://docs.jboss.org/hornetq/2.3.0.CR1/docs/user-manual/html_single/index.html#ha.allow-fail-back
> This issue was hit with EAP 6.1.0.DR2 (HQ 2.3.0.CR1).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:26 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-463) Add utility for creating and
 destorying modules in tests
In-Reply-To: <JIRA.12488631.1365114411000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12488631.1365114411000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488631.1365114411000.15085.1380922946450@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-463:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Add utility for creating and destorying modules in tests
> --------------------------------------------------------
>
>                 Key: WFLY-463
>                 URL: https://issues.jboss.org/browse/WFLY-463
>             Project: WildFly
>          Issue Type: Task
>          Components: Test Suite
>            Reporter: Stuart Douglas
>            Assignee: Ondrej Zizka
>             Fix For: 8.0.0.CR1
>
>
> Lots of tests create and destroy a static module to test functionaility involving static modules. If possible all this code should be moved into some kind of static module builder utility. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:26 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-462) Eliminate the threads subsystem
In-Reply-To: <JIRA.12433050.1300303945000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12433050.1300303945000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12433050.1300303945000.15090.1380922946699@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-462:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Eliminate the threads subsystem
> -------------------------------
>
>                 Key: WFLY-462
>                 URL: https://issues.jboss.org/browse/WFLY-462
>             Project: WildFly
>          Issue Type: Task
>            Reporter: David Lloyd
>            Assignee: Tomaz Cerar
>             Fix For: 8.0.0.CR1
>
>
> The threads subsystem should be eliminated, and instead the individual consuming subsystems should utilize common code from the jboss-as-threads module to define and manage thread pools within their own configuration models.
> Subtasks for affected subsystems.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:26 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-459) correct JPA dependency
 injection (stop injecting javassist)
In-Reply-To: <JIRA.12466946.1337626527000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12466946.1337626527000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12466946.1337626527000.15094.1380922946863@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-459:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> correct JPA dependency injection (stop injecting javassist)
> -----------------------------------------------------------
>
>                 Key: WFLY-459
>                 URL: https://issues.jboss.org/browse/WFLY-459
>             Project: WildFly
>          Issue Type: Task
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 8.0.0.CR1
>
>
> Rather than export the javassist dependency, see if we can change javassist to generate proxies for the application classes which aren't on the hibernate module class path.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:27 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-458)
 ServerInventory#reconnectServer should take auto-start into account
In-Reply-To: <JIRA.12477247.1350487476000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12477247.1350487476000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12477247.1350487476000.15098.1380922947047@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-458:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> ServerInventory#reconnectServer should take auto-start into account
> -------------------------------------------------------------------
>
>                 Key: WFLY-458
>                 URL: https://issues.jboss.org/browse/WFLY-458
>             Project: WildFly
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Emanuel Muckenhuber
>             Fix For: 8.0.0.CR1
>
>
> When reconnecting to stopped (but not removed) servers, the ServerInventory should take the auto-start property into account. Otherwise the process will just get removed, however started with the next :reload of the HC.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:27 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-446) Add quickstarts info to
	localhost:8080
In-Reply-To: <JIRA.12452122.1321276825000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12452122.1321276825000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12452122.1321276825000.15112.1380922947659@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-446:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Add quickstarts info to localhost:8080
> --------------------------------------
>
>                 Key: WFLY-446
>                 URL: https://issues.jboss.org/browse/WFLY-446
>             Project: WildFly
>          Issue Type: Task
>            Reporter: Pete Muir
>            Assignee: Pete Muir
>            Priority: Minor
>             Fix For: 8.0.0.CR1
>
>
> Add another static page, quickstarts.html, that lists the quickstarts available and how to get them. Add a link from the main page.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:27 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-457) Replace mod_cluster proxy-list
 attribute with list of outbound socket bindings
In-Reply-To: <JIRA.12489843.1366309174000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489843.1366309174000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489843.1366309174000.15106.1380922947435@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-457:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Replace mod_cluster proxy-list attribute with list of outbound socket bindings
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-457
>                 URL: https://issues.jboss.org/browse/WFLY-457
>             Project: WildFly
>          Issue Type: Task
>          Components: Clustering
>            Reporter: Paul Ferraro
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.CR1
>
>
> Currently, the mod_cluster subsystem defines proxies using a comma separated string of address:port.  This attribute needs to be deprecated in favor of an attribute, call it "proxies" that defines an xs:list of outbound socket binding names.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:27 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-444) Remove
	ServerEnvironment.getModulesDir()
In-Reply-To: <JIRA.12464998.1335367561000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12464998.1335367561000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12464998.1335367561000.15116.1380922947827@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-444:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Remove ServerEnvironment.getModulesDir()
> ----------------------------------------
>
>                 Key: WFLY-444
>                 URL: https://issues.jboss.org/browse/WFLY-444
>             Project: WildFly
>          Issue Type: Task
>          Components: Server
>            Reporter: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> This method was deprecated in 7.1.0 and the OSGi subsystem is removing the only known use of it in 7.1.2. Remove the method in 7.2.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:27 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-450) Add 7.2.0 configuration tests
 to ParseAndMarshalModelsTestCase
In-Reply-To: <JIRA.12484401.1360358274000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12484401.1360358274000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12484401.1360358274000.15109.1380922947561@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-450:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Add 7.2.0 configuration tests to ParseAndMarshalModelsTestCase
> --------------------------------------------------------------
>
>                 Key: WFLY-450
>                 URL: https://issues.jboss.org/browse/WFLY-450
>             Project: WildFly
>          Issue Type: Task
>          Components: Domain Management, Test Suite
>            Reporter: Brian Stansberry
>            Priority: Critical
>             Fix For: 8.0.0.CR1
>
>
> Add 7.2.0 configuration tests to {{org.jboss.as.test.manualmode.parse.ParseAndMarshalModelsTestCase}} test case.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:28 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-441) If possible,
 eliminate the NonTxEmCloser by closing the EM immediately after
 each EM invocation
In-Reply-To: <JIRA.12455914.1325826336000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12455914.1325826336000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12455914.1325826336000.15119.1380922948009@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-441:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> If possible, eliminate the NonTxEmCloser by closing the EM immediately after each EM invocation
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-441
>                 URL: https://issues.jboss.org/browse/WFLY-441
>             Project: WildFly
>          Issue Type: Task
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Priority: Minor
>             Fix For: 8.0.0.CR1
>
>
> For Queries, handoff the EntityManager to a Query object wrapper and have the Query object finalizer close the EntityManager.  
> Make sure that we respect JPA 2.0 section 3.8.6 (detach objects returned from Query object).
> 1.  Methods that return a Query, will hand off the EM to the Query object wrapper.
> 2.  Other methods will close the EM at the end of the EM method invocation.
> When making this change, make sure that performance doesn't degrade.  The cost of this change, will be that each (transaction scoped non-tx) EM invocation will create a new persistence context, but we can eliminate the NonTxEmCloser which has its own overhead.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:28 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-436) Inline JGroups subsystem
 references to threads subsystem.
In-Reply-To: <JIRA.12484691.1360613264000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12484691.1360613264000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12484691.1360613264000.15123.1380922948213@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-436:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Inline JGroups subsystem references to threads subsystem.
> ---------------------------------------------------------
>
>                 Key: WFLY-436
>                 URL: https://issues.jboss.org/browse/WFLY-436
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Clustering
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 8.0.0.CR1
>
>
> Currently, the JGroups subsystem defers to the threads subsystem to define thread pools and thread factories.  Apparently, this is now frowned upon.  Instead, the executors for the default pool, OOB pool, and timer pool should be defined inline.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:28 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-434) Domain Management - Support
 for database connection pool in non AS process.
In-Reply-To: <JIRA.12442411.1311333410000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12442411.1311333410000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12442411.1311333410000.15131.1380922948574@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-434:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Domain Management - Support for database connection pool in non AS process.
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-434
>                 URL: https://issues.jboss.org/browse/WFLY-434
>             Project: WildFly
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> We need to support authentication for users stored in database, the domain management is in a non-AS process so we also need a pool of database connections.
> These connections will be used to read only from the database, other than the isolation offered by the driver we should not require any advanced transaction support.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:28 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-435) Validate servlet run as
 identity propagation
In-Reply-To: <JIRA.12444312.1313093142000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12444312.1313093142000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12444312.1313093142000.15128.1380922948421@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-435:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Validate servlet run as identity propagation
> --------------------------------------------
>
>                 Key: WFLY-435
>                 URL: https://issues.jboss.org/browse/WFLY-435
>             Project: WildFly
>          Issue Type: Task
>          Components: EJB, Security, Web (JBoss Web)
>            Reporter: Marcus Moyses
>            Assignee: Peter Skopek
>            Priority: Minor
>             Fix For: 8.0.0.CR1
>
>
> Need to validate if the run as identity configured in jboss-web.xml for a servlet is propagated to ejb invocations.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:28 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-418) TS: Move resources to source
	packages.
In-Reply-To: <JIRA.12461401.1331565661000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12461401.1331565661000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12461401.1331565661000.15135.1380922948954@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-418:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> TS: Move resources to source packages.
> --------------------------------------
>
>                 Key: WFLY-418
>                 URL: https://issues.jboss.org/browse/WFLY-418
>             Project: WildFly
>          Issue Type: Task
>          Components: Test Suite
>            Reporter: Ondrej Zizka
>            Assignee: Ondrej Zizka
>            Priority: Minor
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:29 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-416) Complete <xs:documentation>
 for all configuration elements/attributes in Infinispan subsystem's XSD
In-Reply-To: <JIRA.12461886.1331909436000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12461886.1331909436000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12461886.1331909436000.15141.1380922949417@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-416:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Complete <xs:documentation> for all configuration elements/attributes in Infinispan subsystem's XSD
> ---------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-416
>                 URL: https://issues.jboss.org/browse/WFLY-416
>             Project: WildFly
>          Issue Type: Task
>          Components: Clustering
>            Reporter: Martin Gencur
>            Assignee: Paul Ferraro
>             Fix For: 8.0.0.CR1
>
>
> Infinispan subsystem's XSD still contains a lot of elements/attributes which do NOT have their description: https://github.com/jbossas/jboss-as/blob/master/build/src/main/resources/docs/schema/jboss-as-infinispan_1_1.xsd
> It would be very useful for users to know what each element is supposed to do.
> This document can help out: https://docspace.corp.redhat.com/docs/DOC-69249

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:31 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-414) Add a non-caching
	authentication cache
In-Reply-To: <JIRA.12455369.1324483914000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12455369.1324483914000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12455369.1324483914000.15146.1380922951106@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-414:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Add a non-caching authentication cache
> --------------------------------------
>
>                 Key: WFLY-414
>                 URL: https://issues.jboss.org/browse/WFLY-414
>             Project: WildFly
>          Issue Type: Task
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: Anil Saldhana
>             Fix For: 8.0.0.CR1
>
>
> Add an option to either disable the authentication cache or a cache implementation that does not cache.
> This is for incoming requests where we do not have a username and password available to use to retrieve an verify items from a cache.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:31 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-410) Implement custom Stack
 resource for JGroups to maintain protocol order
In-Reply-To: <JIRA.12479212.1352900349000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479212.1352900349000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479212.1352900349000.15152.1380922951680@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-410:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Implement custom Stack resource for JGroups to maintain protocol order 
> -----------------------------------------------------------------------
>
>                 Key: WFLY-410
>                 URL: https://issues.jboss.org/browse/WFLY-410
>             Project: WildFly
>          Issue Type: Task
>          Components: Clustering, Domain Management
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>            Priority: Minor
>             Fix For: 8.0.0.CR1
>
>
> A JGroups stack is a transport together with an ordered list of protocols. The transport and the protocols are maintained as child resources. There is no direct way to maintain the order of a set of protocol child resources, so we need to implement a custom resource which does this.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:32 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-405) Patching system
In-Reply-To: <JIRA.12414447.1279060149000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12414447.1279060149000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12414447.1279060149000.15166.1380922952742@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-405:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Patching system
> ---------------
>
>                 Key: WFLY-405
>                 URL: https://issues.jboss.org/browse/WFLY-405
>             Project: WildFly
>          Issue Type: Task
>          Components: Domain Management, Patching
>            Reporter: Brian Stansberry
>            Assignee: Emanuel Muckenhuber
>            Priority: Blocker
>              Labels: rhq
>             Fix For: 8.0.0.CR1
>
>
> "Server" side of the patching system. Server not in the sense of the domain model Server, but rather client-server where the client is whatever tool (JON) determines there are patches available and asks the server to apply them.
> This does not need to implemented until M2 but thinking about it during the design of the InstalledImage is good.
> Links to the current wiki articles:
> https://community.jboss.org/wiki/LayeredDistributionsAndModulePathOrganization
> https://community.jboss.org/wiki/SingleInstallationPatching
> https://community.jboss.org/wiki/ExperimentingWithSingleInstallationPatching

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:33 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-399) mod_cluster subsystem: convert
 operation handlers to use OperationDefinition
In-Reply-To: <JIRA.12479868.1353944133000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479868.1353944133000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479868.1353944133000.15169.1380922953169@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-399:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> mod_cluster subsystem: convert operation handlers to use OperationDefinition
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-399
>                 URL: https://issues.jboss.org/browse/WFLY-399
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Clustering
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.CR1
>
>
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/LoadMetricDefinition.java:[59,59] warning: [deprecation] PropertiesAttributeDefinition(java.lang.String,java.lang.String,boolean) in org.jboss.as.controller.PropertiesAttributeDefinition has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterConfigResourceDefinition.java:[277,29] warning: [deprecation] registerOperationHandler(java.lang.String,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.descriptions.DescriptionProvider,boolean,java.util.EnumSet<org.jboss.as.controller.registry.OperationEntry.Flag>) in org.jboss.as.controller.registry.ManagementResourceRegistration has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterConfigResourceDefinition.java:[280,29] warning: [deprecation] registerOperationHandler(java.lang.String,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.descriptions.DescriptionProvider,boolean,java.util.EnumSet<org.jboss.as.controller.registry.OperationEntry.Flag>) in org.jboss.as.controller.registry.ManagementResourceRegistration has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterConfigResourceDefinition.java:[283,29] warning: [deprecation] registerOperationHandler(java.lang.String,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.descriptions.DescriptionProvider,boolean,java.util.EnumSet<org.jboss.as.controller.registry.OperationEntry.Flag>) in org.jboss.as.controller.registry.ManagementResourceRegistration has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterConfigResourceDefinition.java:[286,29] warning: [deprecation] registerOperationHandler(java.lang.String,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.descriptions.DescriptionProvider,boolean,java.util.EnumSet<org.jboss.as.controller.registry.OperationEntry.Flag>) in org.jboss.as.controller.registry.ManagementResourceRegistration has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterSubsystemAdd.java:[160,19] warning: [deprecation] setProxyList(java.lang.String) in org.jboss.modcluster.config.impl.ModClusterConfig has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterSubsystemAdd.java:[166,15] warning: [deprecation] setExcludedContexts(java.lang.String) in org.jboss.modcluster.config.impl.ModClusterConfig has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterDefinition.java:[100,21] warning: [deprecation] registerOperationHandler(java.lang.String,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.descriptions.DescriptionProvider,boolean,java.util.EnumSet<org.jboss.as.controller.registry.OperationEntry.Flag>) in org.jboss.as.controller.registry.ManagementResourceRegistration has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterDefinition.java:[103,21] warning: [deprecation] registerOperationHandler(java.lang.String,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.descriptions.DescriptionProvider,boolean,java.util.EnumSet<org.jboss.as.controller.registry.OperationEntry.Flag>) in org.jboss.as.controller.registry.ManagementResourceRegistration has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterDefinition.java:[106,21] warning: [deprecation] registerOperationHandler(java.lang.String,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.descriptions.DescriptionProvider,boolean,java.util.EnumSet<org.jboss.as.controller.registry.OperationEntry.Flag>) in org.jboss.as.controller.registry.ManagementResourceRegistration has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterDefinition.java:[110,21] warning: [deprecation] registerOperationHandler(java.lang.String,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.descriptions.DescriptionProvider,boolean) in org.jboss.as.controller.registry.ManagementResourceRegistration has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterDefinition.java:[113,21] warning: [deprecation] registerOperationHandler(java.lang.String,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.descriptions.DescriptionProvider,boolean) in org.jboss.as.controller.registry.ManagementResourceRegistration has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterDefinition.java:[117,21] warning: [deprecation] registerOperationHandler(java.lang.String,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.descriptions.DescriptionProvider,boolean,java.util.EnumSet<org.jboss.as.controller.registry.OperationEntry.Flag>) in org.jboss.as.controller.registry.ManagementResourceRegistration has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterDefinition.java:[120,21] warning: [deprecation] registerOperationHandler(java.lang.String,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.descriptions.DescriptionProvider,boolean,java.util.EnumSet<org.jboss.as.controller.registry.OperationEntry.Flag>) in org.jboss.as.controller.registry.ManagementResourceRegistration has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterDefinition.java:[124,21] warning: [deprecation] registerOperationHandler(java.lang.String,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.descriptions.DescriptionProvider,boolean) in org.jboss.as.controller.registry.ManagementResourceRegistration has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterDefinition.java:[127,21] warning: [deprecation] registerOperationHandler(java.lang.String,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.descriptions.DescriptionProvider,boolean) in org.jboss.as.controller.registry.ManagementResourceRegistration has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterDefinition.java:[130,21] warning: [deprecation] registerOperationHandler(java.lang.String,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.descriptions.DescriptionProvider,boolean) in org.jboss.as.controller.registry.ManagementResourceRegistration has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterDefinition.java:[134,21] warning: [deprecation] registerOperationHandler(java.lang.String,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.descriptions.DescriptionProvider,boolean) in org.jboss.as.controller.registry.ManagementResourceRegistration has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterDefinition.java:[137,21] warning: [deprecation] registerOperationHandler(java.lang.String,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.descriptions.DescriptionProvider,boolean) in org.jboss.as.controller.registry.ManagementResourceRegistration has been deprecated
> [WARNING] /home/rhusar/git/as-master-modcluster/modcluster/src/main/java/org/jboss/as/modcluster/ModClusterDefinition.java:[140,21] warning: [deprecation] registerOperationHandler(java.lang.String,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.descriptions.DescriptionProvider,boolean) in org.jboss.as.controller.registry.ManagementResourceRegistration has been deprecated

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:33 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-378) Provide ability to detect
	server shutdown
In-Reply-To: <JIRA.12479362.1353062219000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479362.1353062219000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479362.1353062219000.15176.1380922953767@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-378:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Provide ability to detect server shutdown
> -----------------------------------------
>
>                 Key: WFLY-378
>                 URL: https://issues.jboss.org/browse/WFLY-378
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Server
>            Reporter: Thomas Diesler
>            Assignee: Jason Greene
>             Fix For: 8.0.0.CR1
>
>
> The general use case is that a subsystem maintains state (on behalf of a deployment) that should be removed on explicit user interaction (i.e. mgmt op) but not on subsystem/server shutdown. This should also work in the domain case. Perhaps the ApplicationServerService (or similar) could be queried about whether it is currently shutting down.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:34 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-377) Provide "destroy-queue" and
 "destroy-topic" operations to CLI
In-Reply-To: <JIRA.12460389.1330512371000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12460389.1330512371000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12460389.1330512371000.15179.1380922954129@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-377:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Provide "destroy-queue" and "destroy-topic" operations to CLI
> -------------------------------------------------------------
>
>                 Key: WFLY-377
>                 URL: https://issues.jboss.org/browse/WFLY-377
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: CLI, JMS
>            Reporter: Miroslav Novak
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.0.CR1
>
>
> Operations "destroy-queue" and "destroy-topic" would destroy queue/topic with all its messages and subscriptions.
> They would be used under for example /subsystem=messaging/hornetq-server=default/jms-queue=testQueue or /subsystem=messaging/hornetq-server=default/jms-topic=testTopic.
> The goal is to provide a simple way how to get rid of those objects to administrators. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:34 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-372) Use ServiceLoader to locate
 mod_cluster custom load metrics
In-Reply-To: <JIRA.12478832.1352374024000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12478832.1352374024000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12478832.1352374024000.15184.1380922954608@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-372:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Use ServiceLoader to locate mod_cluster custom load metrics
> -----------------------------------------------------------
>
>                 Key: WFLY-372
>                 URL: https://issues.jboss.org/browse/WFLY-372
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.CR1
>
>
> Solves the problem of having to identify load metrics by class names.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:34 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-368) Naming subsystem <lookup>
 could use LinkRef/Reference
In-Reply-To: <JIRA.12480761.1355118811000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12480761.1355118811000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12480761.1355118811000.15188.1380922954829@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-368:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Naming subsystem <lookup> could use LinkRef/Reference
> -----------------------------------------------------
>
>                 Key: WFLY-368
>                 URL: https://issues.jboss.org/browse/WFLY-368
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Naming
>            Reporter: James Livingston
>            Assignee: Eduardo Martins
>             Fix For: 8.0.0.CR1
>
>
> NameBindingAdd.installLookup() sets up the machinery so that when Context.lookup() is done it looks up the redirected name and returns it.
> It should be possible to do that by binding a LinkRef, Reference or similar object into JNDI instead.
> Where this could make a difference is when Context.lookupLink() is called instead.
> Currently if you have
>    <simple name="java:/v" value="hello"/>
>    <lookup name="java:/a" lookup="java:/b"/>
> lookupLink("java:/a") will return "hello" rather a LinkRef/Reference/whatever pointing to java:/b.
> We need to decide whether a <lookup> should be considered a "link" for the purposes of lookup() or not. If it should be considered one, then we should change NameBindingAdd.installLookup() to make lookupLink() return the other value.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:35 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-366) Add support for grouping to
 Infinispan subsystem
In-Reply-To: <JIRA.12456230.1326273774000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12456230.1326273774000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12456230.1326273774000.15194.1380922955059@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-366:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Add support for grouping to Infinispan subsystem
> ------------------------------------------------
>
>                 Key: WFLY-366
>                 URL: https://issues.jboss.org/browse/WFLY-366
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>            Reporter: Martin Gencur
>            Assignee: Tristan Tarrant
>             Fix For: 8.0.0.CR1
>
>
> Enable setting of groups in Infinispan subsystem. More information about grouping can be found at https://docs.jboss.org/author/display/ISPN/The+Grouping+API.
> It should be possible to enable it as well as set a grouper class. The following is respective configuration for standalone Infinispan.
> {code:xml}
> <clustering>
>   <hash>
>      <groups enabled="true">
>         <grouper class="com.acme.KXGrouper" />
>      </groups>
>   </hash>
> </clustering>
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:35 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-364) a
 "failure-causes-rollback="false"" attribute for the filesystem scanner
In-Reply-To: <JIRA.12464247.1334623605000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12464247.1334623605000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12464247.1334623605000.15203.1380922955611@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-364:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> a "failure-causes-rollback="false"" attribute for the filesystem scanner
> ------------------------------------------------------------------------
>
>                 Key: WFLY-364
>                 URL: https://issues.jboss.org/browse/WFLY-364
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Max Rydahl Andersen
>             Fix For: 8.0.0.CR1
>
>
> JBIDE-11509, AS7-783 and TORQUE-576 all talk about the problem of all deployments found at startup is deployed in one operation and if one deployment fails all is rolled back resulting in some rather bad usability issues - especially at development time, but even also at production time for those using file deployments.
> Suggestion on irc was that there could be an option on the file scanner (possibly false by default?) to say that failure causes rollback.
> Individual deployments could then still fail, but at least not everything would be rolledback and it would still allow proper interdependent deployments to work. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:35 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-362) provide means to specify
 allowed ciphers for management https or change default to exclude weak
 ciphers
In-Reply-To: <JIRA.12473935.1346965907000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12473935.1346965907000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12473935.1346965907000.15207.1380922955739@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-362:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> provide means to specify allowed ciphers for management https or change default to exclude weak ciphers
> -------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-362
>                 URL: https://issues.jboss.org/browse/WFLY-362
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management, Security
>            Reporter: R Stokoe
>            Assignee: Tomaz Cerar
>             Fix For: 8.0.0.CR1
>
>
> Provide means to specify allowed ciphers for management https.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:36 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-358) Enable checkstyle for
 clustering integration testsuite
In-Reply-To: <JIRA.12485917.1362049129000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485917.1362049129000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485917.1362049129000.15214.1380922956169@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-358:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Enable checkstyle for clustering integration testsuite
> ------------------------------------------------------
>
>                 Key: WFLY-358
>                 URL: https://issues.jboss.org/browse/WFLY-358
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering, Test Suite
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>            Priority: Minor
>             Fix For: 8.0.0.CR1
>
>
> Ideally this will make live easier by less rebasing due to formatting differences and easier PR reviews. Lets see how it goes.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:36 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-353) Support for AS-specific
	mod_cluster metrics
In-Reply-To: <JIRA.12486203.1362418050000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12486203.1362418050000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12486203.1362418050000.15217.1380922956298@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-353:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Support for AS-specific mod_cluster metrics
> -------------------------------------------
>
>                 Key: WFLY-353
>                 URL: https://issues.jboss.org/browse/WFLY-353
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.CR1
>
>
> If we want to create AS-specific load metrics that reference other AS services we need a way for the mod_cluster subsystem to configure these since currently load metrics are statically defined and are not configurable. E.g. connection-pool.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:36 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-348) IO subsystem management API
In-Reply-To: <JIRA.12489434.1366010002000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489434.1366010002000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489434.1366010002000.15226.1380922956685@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-348:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> IO subsystem management API
> ---------------------------
>
>                 Key: WFLY-348
>                 URL: https://issues.jboss.org/browse/WFLY-348
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Tomaz Cerar
>             Fix For: 8.0.0.CR1
>
>
> Expose the IO subsystem management operations

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:36 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-349) FreeBSD
	isThreadCpuTimeSupported
In-Reply-To: <JIRA.12479229.1352909128000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479229.1352909128000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479229.1352909128000.15222.1380922956504@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-349:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> FreeBSD isThreadCpuTimeSupported
> --------------------------------
>
>                 Key: WFLY-349
>                 URL: https://issues.jboss.org/browse/WFLY-349
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>         Environment: FreeBSD 9.0-RELEASE-p3 FreeBSD 9.0-RELEASE-p3 #0: Tue Jun 12 02:52:29 UTC 2012     root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64
> openjdk6/openjdk7
>            Reporter: Alexander Yerenkow
>             Fix For: 8.0.0.CR1
>
>
> Platform Tests should be modified, since it's not respecting when isThreadCpuTimeSupported = false (It continues run some test with isThreadCpuTimeSupported, which produces Exceptions, and all test failed);
> Simple test:
> ThreadMXBean threadMXBean = ManagementFactory.getThreadMXBean();
> System.out.println("threadMXBean.isThreadCpuTimeSupported() = " + threadMXBean.isThreadCpuTimeSupported());
> System.out.println("threadMXBean.isThreadCpuTimeEnabled() = " + threadMXBean.isThreadCpuTimeEnabled());
> Result:
> threadMXBean.isThreadCpuTimeSupported() = false
> Exception in thread "main" java.lang.UnsupportedOperationException: Thread CPU time measurement is not supported
>         at sun.management.ThreadImpl.isThreadCpuTimeEnabled(ThreadImpl.java:98)
>         at Test.main(Test.java:19)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:36 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-346) Clustering TS: Continue work
 on Web tests migration
In-Reply-To: <JIRA.12466250.1336735955000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12466250.1336735955000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12466250.1336735955000.15232.1380922956909@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-346:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Clustering TS: Continue work on Web tests migration
> ---------------------------------------------------
>
>                 Key: WFLY-346
>                 URL: https://issues.jboss.org/browse/WFLY-346
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.CR1
>
>
> https://issues.jboss.org/browse/JBQA-6058?focusedCommentId=12679023&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12679023

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:37 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-343) lower messaging's
 min-large-message-size value in standalone-full.xml
In-Reply-To: <JIRA.12480712.1354892684000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12480712.1354892684000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12480712.1354892684000.15237.1380922957123@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-343:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> lower messaging's min-large-message-size value in standalone-full.xml
> ---------------------------------------------------------------------
>
>                 Key: WFLY-343
>                 URL: https://issues.jboss.org/browse/WFLY-343
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.CR1
>
>
> AS7's messaging subsystem defines 2 attributes:
> journal-file-size => 10MiB
> min-large-message-size => 100KiB
> However, for startup performance issue, the standalone-full.xml sets the journal-file-size at 1OOKiB. This leads to issues since it's the same value than the min-large-message-size.
> If we want to keep a low journal-file-size value in standalone-full.xml, the min-large-message-size must also bet set appropriately (eg 75KiB?)
> For production use, however, we should suggest to the users to remove the journal-file-size and min-large-message-size from standalone-full.xml to use the default values (resp. 10MiB & 100KiB)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:36 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-347) pre/post cli-scripts for AS
 patching feature
In-Reply-To: <JIRA.12475775.1349017637000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12475775.1349017637000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12475775.1349017637000.15229.1380922956794@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-347:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> pre/post cli-scripts for AS patching feature
> --------------------------------------------
>
>                 Key: WFLY-347
>                 URL: https://issues.jboss.org/browse/WFLY-347
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Scripts
>            Reporter: Nicklas Karlsson
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.CR1
>
>
> It would be handy to be able to attach pre/post CLI scripts to be applied for an AS patch.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:37 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-334) HA Singleton deployer for
	applications
In-Reply-To: <JIRA.12467417.1337972417000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12467417.1337972417000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12467417.1337972417000.15252.1380922957819@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-334:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> HA Singleton deployer for applications
> --------------------------------------
>
>                 Key: WFLY-334
>                 URL: https://issues.jboss.org/browse/WFLY-334
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering, Domain Management
>            Reporter: Wolf-Dieter Fink
>            Assignee: Paul Ferraro
>              Labels: deployers, hasingleton
>             Fix For: 8.0.0.CR1
>
>
> A HASingleton deployer should be provided in standalone and domain mode.
> To be able to migrate such singleton applications from former AS versions.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:37 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-342) Reenable
 ClusteredSingleSignOnTestCase test to work with Undertow
In-Reply-To: <JIRA.12471898.1344331018000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12471898.1344331018000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12471898.1344331018000.15248.1380922957615@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-342:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Reenable ClusteredSingleSignOnTestCase test to work with Undertow 
> ------------------------------------------------------------------
>
>                 Key: WFLY-342
>                 URL: https://issues.jboss.org/browse/WFLY-342
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>            Reporter: Kabir Khan
>            Priority: Critical
>             Fix For: 8.0.0.CR1
>
>         Attachments: ClusteredSingleSignOnTestCase1.html, ClusteredSingleSignOnTestCase2.html, ClusteredSingleSignOnTestCase3.html
>
>
> Test have been @Ignored until Undertow implements SSO.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:38 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-322) TS clustering: test with both
 repl and dist caches
In-Reply-To: <JIRA.12461925.1331945943000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12461925.1331945943000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12461925.1331945943000.15273.1380922958432@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-322:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> TS clustering: test with both repl and dist caches
> --------------------------------------------------
>
>                 Key: WFLY-322
>                 URL: https://issues.jboss.org/browse/WFLY-322
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering, Test Suite
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.CR1
>
>
> Just like we did in AS7-3954, but with different cache types.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:38 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-320) Allow jconsole to be launched
 as a modular application
In-Reply-To: <JIRA.12484676.1360603035000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12484676.1360603035000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12484676.1360603035000.15277.1380922958521@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-320:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Allow jconsole to be launched as a modular application
> ------------------------------------------------------
>
>                 Key: WFLY-320
>                 URL: https://issues.jboss.org/browse/WFLY-320
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JMX, Scripts
>            Reporter: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> Make the jconsole scripts launch jconsole as as a modular application. Get rid of the classpath building that resulted in AS7-6498.
> Some (mildly edited) discussion:
> bstansberry: BTW, I filed a JIRA to make the vault tool a proper modular app in AS next. I'm not sure if that's doable for jconsole
> [10:37am] darranl: bstansberry: Yes vault should be modular - I don't believe jconsole is as easily possible unless we add a module for the jconsole classes
> [10:38am] darranl: bstansberry: the problem with jconsole was that we actually needed to call jconsole which I think was a binary so we were just created an extended classpath for that binary to use
> [10:38am] bstansberry: darranl: ok, will do. I didn't file a JIRA for modular jconsole because I figured there would be problems
> [10:39am] darranl: bstansberry: having said that it may be possible now to just switch to use the client jar - that did not exist at the time the jconsole script was first written
> [10:40am] darranl: but at this point may be safer to just update the root of the modules folder and switch to client later
> [10:40am] bstansberry: darranl: this will become more of an issue once we have patching
> [10:40am] bstansberry: since this script won't pick up any patches we may have issued for the listed modules
> [10:40am] bstansberry: and no way are we going to add that to the script
> [10:43am] dmlloyd: I've booted jconsole from within modules before
> [10:43am] dmlloyd: it's possible
> [10:43am] darranl: If it is possbile then maybe we can just make it modular
> [10:44am] dmlloyd: java -jar ~/.m2/repository/org/jboss/modules/jboss-modules/1.1.4.GA/jboss-modules-1.1.4.GA.jar -jar ~/local/jdk/home/lib/jconsole.jar
> [10:44am] dmlloyd: easy as bananas
> [10:45am] dmlloyd: if you use -cp you can also add dependencies via -dep
> [10:45am] dmlloyd: or we could create a jconsole module from openjdk even

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:38 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-315) Avoid running out of threads
 when connecting to the DC from a slave to pull down missing data
In-Reply-To: <JIRA.12488204.1364406845000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12488204.1364406845000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488204.1364406845000.15282.1380922958613@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-315:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Avoid running out of threads when connecting to the DC from a slave to pull down missing data
> ---------------------------------------------------------------------------------------------
>
>                 Key: WFLY-315
>                 URL: https://issues.jboss.org/browse/WFLY-315
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.CR1
>
>
> For WFLY-259 when a slave connects to the DC to pull down missing data, it does this by either getting a lock for the DC, or by joining the permit of the existing DC lock if the request to update a slave's server-config was executed as part of a composite obtaining a lock on the DC.
> The way it works at present there is a thread per slave which is blocked until the transaction completes. The DC threads are a finite resource, so a large number of slaves trying to pull down dats will cause deadlock

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:38 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-324) xinclude support in the
	management model
In-Reply-To: <JIRA.12446086.1314912041000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12446086.1314912041000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12446086.1314912041000.15271.1380922958376@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-324:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> xinclude support in the management model
> ----------------------------------------
>
>                 Key: WFLY-324
>                 URL: https://issues.jboss.org/browse/WFLY-324
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Jason Greene
>             Fix For: 8.0.0.CR1
>
>
> Ability to use xinclude in the domain/xml/host.xml/standalone.xml documents. Not necessarily anywhere, but where the model supports storing the information. Upon changes to the model, persistence of the relevant elements would be to the specified file.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:38 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-316) Javadoc - exclude _private.*
	packages
In-Reply-To: <JIRA.12488463.1364919092000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12488463.1364919092000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488463.1364919092000.15279.1380922958553@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-316:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Javadoc - exclude _private.* packages
> -------------------------------------
>
>                 Key: WFLY-316
>                 URL: https://issues.jboss.org/browse/WFLY-316
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Documentation
>            Reporter: Ondrej Zizka
>            Assignee: Ondrej Zizka
>            Priority: Minor
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:38 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-312) LocalEJBClientFailoverTestCase
 fails intermittently
In-Reply-To: <JIRA.12471899.1344331208000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12471899.1344331208000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12471899.1344331208000.15286.1380922958856@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-312:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> LocalEJBClientFailoverTestCase fails intermittently
> ---------------------------------------------------
>
>                 Key: WFLY-312
>                 URL: https://issues.jboss.org/browse/WFLY-312
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Test Suite
>            Reporter: Kabir Khan
>            Assignee: jaikiran pai
>            Priority: Critical
>             Fix For: 8.0.0.CR1
>
>
> org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.LocalEJBClientFailoverTestCase(UDP).testFailoverWhenLocalTargetApplicationIsUndeployed
> Failing for the past 1 build (Since #4607 )
> Took 2 min 24 sec.
> add description
> Error Message
> java.lang.IllegalArgumentException: JBAS014155: Unknown deployment - app name:  module name: node-name-app distinct name: 
> Stacktrace
> javax.ejb.EJBException: java.lang.IllegalArgumentException: JBAS014155: Unknown deployment - app name:  module name: node-name-app distinct name: 
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:165)
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:229)
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:303)
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:189)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:42)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:43)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
>         at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:327)
>         at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:70)
>         at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:205)
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:662)
>         at org.jboss.threads.JBossThread.run(JBossThread.java:122)
>         at ...asynchronous invocation...(Unknown Source)
>         at org.jboss.ejb.client.remoting.InvocationExceptionResponseHandler$MethodInvocationExceptionResultProducer.getResult(InvocationExceptionResponseHandler.java:99)
>         at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:272)
>         at org.jboss.ejb.client.TransactionInterceptor.handleInvocationResult(TransactionInterceptor.java:46)
>         at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:274)
>         at org.jboss.ejb.client.ReceiverInterceptor.handleInvocationResult(ReceiverInterceptor.java:129)
>         at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:262)
>         at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:437)
>         at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:140)
>         at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:121)
>         at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:104)
>         at $Proxy29.invokeAndFetchNodeNameFromClusteredSFSBRemoteBean(Unknown Source)
>         at org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.LocalEJBClientFailoverTestCase.testFailoverWhenLocalTargetApplicationIsUndeployed(LocalEJBClientFailoverTestCase.java:207)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
>         at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
>         at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
>         at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:270)
>         at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
>         at sun.reflect.GeneratedMethodAccessor12.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>         at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
>         at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
>         at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
>         at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
>         at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
>         at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:53)
>         at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>         at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
>         at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
>         at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
>         at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129)
>         at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>         at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
>         at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89)
>         at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>         at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
>         at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
>         at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>         at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
>         at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
>         at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>         at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
>         at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
>         at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111)
>         at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263)
>         at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226)
>         at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
>         at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
>         at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240)
>         at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
>         at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
>         at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
>         at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
>         at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
>         at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
>         at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
>         at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
>         at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185)
>         at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
>         at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
>         at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
>         at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
>         at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188)
>         at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166)
>         at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
>         at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101)
>         at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
> Caused by: java.lang.IllegalArgumentException: JBAS014155: Unknown deployment - app name:  module name: node-name-app distinct name: 
>         at org.jboss.as.ejb3.remote.LocalEjbReceiver.findBean(LocalEjbReceiver.java:317)
>         at org.jboss.as.ejb3.remote.LocalEjbReceiver.processInvocation(LocalEjbReceiver.java:142)
>         at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:181)
>         at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:42)
>         at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183)
>         at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:125)
>         at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183)
>         at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:136)
>         at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:121)
>         at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:104)
>         at $Proxy30.getNodeName(Unknown Source)
>         at org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.ClientSFSB.invokeAndFetchNodeNameFromClusteredSFSBRemoteBean(ClientSFSB.java:53)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:36)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:58)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:156)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:67)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:227)
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:303)
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:189)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:42)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:43)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
>         at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:327)
>         at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:70)
>         at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:205)
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:662)
>         at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> Standard Output
> 05:46:07,738 INFO  [org.jboss.ejb.client.remoting] (Remoting "config-based-ejb-client-endpoint" task-4) EJBCLIENT000016: Channel Channel ID aa79198c (outbound) of Remoting connection 0ab612f8 to /127.0.0.1:4447 can no longer process messages
> 05:46:07,958 INFO  [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual starting of a server instance
> 05:46:07,971 INFO  [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Starting container with: [/opt/jdk1.6.0_29/bin/java, -Xmx512m, -XX:MaxPermSize=256m, -Djboss.dist=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/../../../build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT, -Djava.net.preferIPv4Stack=true, -Djava.net.preferIPv6Addresses=false, -Dts.timeout.factor=100, -Dnode0=127.0.0.1, -Dnode1=127.0.0.1, -Dmcast=230.0.0.4, -Djbossas.ts.submodule.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust, -Djbossas.ts.integ.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/.., -Djbossas.ts.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/../.., -Djbossas.project.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/../../.., -Djboss.dist=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/../../../build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT, -Djboss.inst=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-0, -Djboss.node.name=node-0, -ea, -Djboss.home.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-0, -Dorg.jboss.boot.log.file=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-0/standalone/log/boot.log, -Dlogging.configuration=file:/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-0/standalone/configuration/logging.properties, -Djboss.bundles.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/../../../build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT/bundles, -jar, /home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-0/jboss-modules.jar, -mp, /home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/../../../build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT/modules, -jaxpmodule, javax.xml.jaxp-provider, org.jboss.as.standalone, -server-config, standalone-ha.xml]
> 05:46:08,724 INFO  [org.jboss.modules] JBoss Modules version 1.1.2.GA
> 05:46:08,967 INFO  [org.jboss.msc] JBoss MSC version 1.0.2.GA
> 05:46:09,049 INFO  [org.jboss.as] JBAS015899: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" starting
> 05:46:10,984 INFO  [org.xnio] XNIO Version 3.0.5.GA
> 05:46:10,985 INFO  [org.jboss.as.server] JBAS015888: Creating http management service using socket-binding (management-http)
> 05:46:11,001 INFO  [org.xnio.nio] XNIO NIO Implementation Version 3.0.5.GA
> 05:46:11,023 INFO  [org.jboss.remoting] JBoss Remoting version 3.2.8.GA
> 05:46:11,036 INFO  [org.jboss.as.logging] JBAS011502: Removing bootstrap log handlers
> &#27;[0m05:46:11,041 INFO  [org.jboss.as.configadmin] (ServerService Thread Pool -- 29) JBAS016200: Activating ConfigAdmin Subsystem
> &#27;[0m&#27;[0m05:46:11,073 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 34) JBAS010280: Activating Infinispan subsystem.
> &#27;[0m&#27;[0m05:46:11,115 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 38) JBAS010260: Activating JGroups subsystem.
> &#27;[0m&#27;[0m05:46:11,224 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 50) JBAS013171: Activating Security Subsystem
> &#27;[0m&#27;[0m05:46:11,225 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 44) JBAS011800: Activating Naming Subsystem
> &#27;[0m&#27;[0m05:46:11,300 INFO  [org.jboss.as.connector.logging] (MSC service thread 1-5) JBAS010408: Starting JCA Subsystem (JBoss IronJacamar 1.0.12.Final)
> &#27;[0m&#27;[0m05:46:11,319 INFO  [org.jboss.as.osgi] (ServerService Thread Pool -- 45) JBAS011906: Activating OSGi Subsystem
> &#27;[0m&#27;[0m05:46:11,336 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 54) JBAS015537: Activating WebServices Extension
> &#27;[0m&#27;[0m05:46:11,391 INFO  [org.jboss.as.security] (MSC service thread 1-3) JBAS013170: Current PicketBox version=4.0.9.Final
> &#27;[0m&#27;[0m05:46:11,516 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 30) JBAS010403: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> &#27;[0m&#27;[0m05:46:11,533 INFO  [org.jboss.as.naming] (MSC service thread 1-5) JBAS011802: Starting Naming Service
> &#27;[0m&#27;[0m05:46:11,571 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-6) JBAS015400: Bound mail session [java:jboss/mail/Default]
> &#27;[0m&#27;[0m05:46:11,885 INFO  [org.jboss.ws.common.management.AbstractServerConfig] (MSC service thread 1-6) JBoss Web Services - Stack CXF Server 4.1.0.Beta1
> &#27;[0m&#27;[0m05:46:11,995 INFO  [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-1) Starting Coyote HTTP/1.1 on http-/127.0.0.1:8080
> &#27;[0m&#27;[0m05:46:11,998 INFO  [org.apache.coyote.ajp.AjpProtocol] (MSC service thread 1-2) Starting Coyote AJP/1.3 on ajp-/127.0.0.1:8009
> &#27;[0m&#27;[0m05:46:12,166 INFO  [org.jboss.modcluster.ModClusterService] (ServerService Thread Pool -- 56) Initializing mod_cluster 1.2.1.Final
> &#27;[0m&#27;[0m05:46:12,229 INFO  [org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl] (ServerService Thread Pool -- 56) Listening to proxy advertisements on 224.0.1.105:23,364
> &#27;[0m&#27;[0m05:46:12,338 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 34) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> &#27;[0m&#27;[0m05:46:12,358 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 34) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> &#27;[0m&#27;[0m05:46:12,520 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-6) JBAS015012: Started FileSystemDeploymentService for directory /home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-0/standalone/deployments
> &#27;[0m&#27;[0m05:46:12,522 INFO  [org.jboss.as.remoting] (MSC service thread 1-5) JBAS017100: Listening on 127.0.0.1:4447
> &#27;[0m&#27;[0m05:46:12,526 INFO  [org.jboss.as.remoting] (MSC service thread 1-2) JBAS017100: Listening on 127.0.0.1:9999
> &#27;[0m&#27;[0m05:46:12,561 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
> &#27;[0m&#27;[0m05:46:12,681 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:9990/management
> &#27;[0m&#27;[0m05:46:12,682 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990
> &#27;[0m&#27;[0m05:46:12,683 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" started in 4449ms - Started 137 of 280 services (142 services are passive or on-demand)
> &#27;[0m05:46:14,559 INFO  [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual starting of a server instance
> 05:46:14,565 INFO  [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Starting container with: [/opt/jdk1.6.0_29/bin/java, -Xmx512m, -XX:MaxPermSize=256m, -Djboss.dist=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/../../../build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT, -Djava.net.preferIPv4Stack=true, -Djava.net.preferIPv6Addresses=false, -Dts.timeout.factor=100, -Dnode0=127.0.0.1, -Dnode1=127.0.0.1, -Dmcast=230.0.0.4, -Djbossas.ts.submodule.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust, -Djbossas.ts.integ.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/.., -Djbossas.ts.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/../.., -Djbossas.project.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/../../.., -Djboss.dist=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/../../../build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT, -Djboss.inst=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-1, -Djboss.node.name=node-1, -Djboss.port.offset=100, -ea, -Djboss.home.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-1, -Dorg.jboss.boot.log.file=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-1/standalone/log/boot.log, -Dlogging.configuration=file:/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-1/standalone/configuration/logging.properties, -Djboss.bundles.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/../../../build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT/bundles, -jar, /home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-1/jboss-modules.jar, -mp, /home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/../../../build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT/modules, -jaxpmodule, javax.xml.jaxp-provider, org.jboss.as.standalone, -server-config, standalone-ha.xml]
> 05:46:15,100 INFO  [org.jboss.modules] JBoss Modules version 1.1.2.GA
> 05:46:15,351 INFO  [org.jboss.msc] JBoss MSC version 1.0.2.GA
> 05:46:15,440 INFO  [org.jboss.as] JBAS015899: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" starting
> 05:46:17,345 INFO  [org.xnio] XNIO Version 3.0.5.GA
> 05:46:17,355 INFO  [org.xnio.nio] XNIO NIO Implementation Version 3.0.5.GA
> 05:46:17,359 INFO  [org.jboss.as.server] JBAS015888: Creating http management service using socket-binding (management-http)
> 05:46:17,378 INFO  [org.jboss.remoting] JBoss Remoting version 3.2.8.GA
> 05:46:17,424 INFO  [org.jboss.as.logging] JBAS011502: Removing bootstrap log handlers
> &#27;[0m05:46:17,429 INFO  [org.jboss.as.configadmin] (ServerService Thread Pool -- 29) JBAS016200: Activating ConfigAdmin Subsystem
> &#27;[0m&#27;[0m05:46:17,472 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 34) JBAS010280: Activating Infinispan subsystem.
> &#27;[0m&#27;[0m05:46:17,514 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 38) JBAS010260: Activating JGroups subsystem.
> &#27;[0m&#27;[0m05:46:17,549 INFO  [org.jboss.as.osgi] (ServerService Thread Pool -- 45) JBAS011906: Activating OSGi Subsystem
> &#27;[0m&#27;[0m05:46:17,562 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 50) JBAS013171: Activating Security Subsystem
> &#27;[0m&#27;[0m05:46:17,622 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 54) JBAS015537: Activating WebServices Extension
> &#27;[0m&#27;[0m05:46:17,628 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 44) JBAS011800: Activating Naming Subsystem
> &#27;[0m&#27;[0m05:46:17,625 INFO  [org.jboss.as.connector.logging] (MSC service thread 1-6) JBAS010408: Starting JCA Subsystem (JBoss IronJacamar 1.0.12.Final)
> &#27;[0m&#27;[0m05:46:17,622 INFO  [org.jboss.as.security] (MSC service thread 1-1) JBAS013170: Current PicketBox version=4.0.9.Final
> &#27;[0m&#27;[0m05:46:17,691 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 30) JBAS010403: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> &#27;[0m&#27;[0m05:46:17,761 INFO  [org.jboss.as.naming] (MSC service thread 1-2) JBAS011802: Starting Naming Service
> &#27;[0m&#27;[0m05:46:17,847 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-4) JBAS015400: Bound mail session [java:jboss/mail/Default]
> &#27;[0m&#27;[0m05:46:18,096 INFO  [org.jboss.ws.common.management.AbstractServerConfig] (MSC service thread 1-3) JBoss Web Services - Stack CXF Server 4.1.0.Beta1
> &#27;[0m&#27;[0m05:46:18,233 INFO  [org.apache.coyote.ajp.AjpProtocol] (MSC service thread 1-5) Starting Coyote AJP/1.3 on ajp-/127.0.0.1:8109
> &#27;[0m&#27;[0m05:46:18,236 INFO  [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-3) Starting Coyote HTTP/1.1 on http-/127.0.0.1:8180
> &#27;[0m&#27;[0m05:46:18,374 INFO  [org.jboss.modcluster.ModClusterService] (ServerService Thread Pool -- 56) Initializing mod_cluster 1.2.1.Final
> &#27;[0m&#27;[0m05:46:18,486 INFO  [org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl] (ServerService Thread Pool -- 56) Listening to proxy advertisements on 224.0.1.105:23,364
> &#27;[0m&#27;[0m05:46:18,571 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 34) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> &#27;[0m&#27;[0m05:46:18,593 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 34) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> &#27;[0m&#27;[0m05:46:18,753 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
> &#27;[0m&#27;[0m05:46:18,778 INFO  [org.jboss.as.remoting] (MSC service thread 1-6) JBAS017100: Listening on 127.0.0.1:10099
> &#27;[0m&#27;[0m05:46:18,778 INFO  [org.jboss.as.remoting] (MSC service thread 1-3) JBAS017100: Listening on 127.0.0.1:4547
> &#27;[0m&#27;[0m05:46:18,783 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-1) JBAS015012: Started FileSystemDeploymentService for directory /home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-1/standalone/deployments
> &#27;[0m&#27;[0m05:46:18,936 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:10090/management
> &#27;[0m&#27;[0m05:46:18,937 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:10090
> &#27;[0m&#27;[0m05:46:18,938 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" started in 4137ms - Started 137 of 280 services (142 services are passive or on-demand)
> &#27;[0m&#27;[0m05:46:21,241 INFO  [org.jboss.as.repository] (management-handler-thread - 2) JBAS014900: Content added at location /home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-1/standalone/data/content/e2/09ce1c0485164619e2ea871a0013f2781ab162/content
> &#27;[0m&#27;[0m05:46:21,299 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015876: Starting deployment of "client-app.jar"
> &#27;[0m&#27;[0m05:46:21,894 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-1) JNDI bindings for session bean named ClientSFSB in deployment unit deployment "client-app.jar" are as follows:
>         java:global/client-app/ClientSFSB!org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.ClientSFSBRemote
>         java:app/client-app/ClientSFSB!org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.ClientSFSBRemote
>         java:module/ClientSFSB!org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.ClientSFSBRemote
>         java:jboss/exported/client-app/ClientSFSB!org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.ClientSFSBRemote
>         java:global/client-app/ClientSFSB
>         java:app/client-app/ClientSFSB
>         java:module/ClientSFSB
> &#27;[0m&#27;[0m05:46:22,409 INFO  [org.jboss.as.server] (management-handler-thread - 2) JBAS018559: Deployed "client-app.jar"
> &#27;[0m&#27;[0m05:46:22,882 INFO  [org.jboss.as.repository] (management-handler-thread - 2) JBAS014900: Content added at location /home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-0/standalone/data/content/dc/274297a56acebcb3414b7407fa05d097f6691b/content
> &#27;[0m&#27;[0m05:46:22,903 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015876: Starting deployment of "node-name-app.jar"
> &#27;[0m&#27;[0m05:46:23,113 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-2) JNDI bindings for session bean named NodeNameSFSB in deployment unit deployment "node-name-app.jar" are as follows:
>         java:global/node-name-app/NodeNameSFSB!org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.NodeNameRetriever
>         java:app/node-name-app/NodeNameSFSB!org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.NodeNameRetriever
>         java:module/NodeNameSFSB!org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.NodeNameRetriever
>         java:jboss/exported/node-name-app/NodeNameSFSB!org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.NodeNameRetriever
>         java:global/node-name-app/NodeNameSFSB
>         java:app/node-name-app/NodeNameSFSB
>         java:module/NodeNameSFSB
> &#27;[0m&#27;[33m05:46:24,128 WARN  [org.jgroups.protocols.UDP] (ServerService Thread Pool -- 1) send buffer of socket java.net.DatagramSocket at 3b5789a5 was set to 640KB, but the OS only allocated 131.07KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> &#27;[0m&#27;[33m05:46:24,132 WARN  [org.jgroups.protocols.UDP] (ServerService Thread Pool -- 1) receive buffer of socket java.net.DatagramSocket at 3b5789a5 was set to 20MB, but the OS only allocated 131.07KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> &#27;[0m&#27;[33m05:46:24,134 WARN  [org.jgroups.protocols.UDP] (ServerService Thread Pool -- 1) send buffer of socket java.net.MulticastSocket at 1a543937 was set to 640KB, but the OS only allocated 131.07KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> &#27;[0m&#27;[33m05:46:24,136 WARN  [org.jgroups.protocols.UDP] (ServerService Thread Pool -- 1) receive buffer of socket java.net.MulticastSocket at 1a543937 was set to 25MB, but the OS only allocated 131.07KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> &#27;[0m&#27;[0m05:46:24,154 INFO  [stdout] (ServerService Thread Pool -- 1) 
> &#27;[0m&#27;[0m05:46:24,155 INFO  [stdout] (ServerService Thread Pool -- 1) -------------------------------------------------------------------
> &#27;[0m&#27;[0m05:46:24,156 INFO  [stdout] (ServerService Thread Pool -- 1) GMS: address=node-0/ejb, cluster=ejb, physical address=127.0.0.1:55200
> &#27;[0m&#27;[0m05:46:24,157 INFO  [stdout] (ServerService Thread Pool -- 1) -------------------------------------------------------------------
> &#27;[0m&#27;[0m05:46:26,383 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 1) ISPN000078: Starting JGroups Channel
> &#27;[0m&#27;[0m05:46:26,408 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 1) ISPN000094: Received new cluster view: [node-0/ejb|0] [node-0/ejb]
> &#27;[0m&#27;[0m05:46:26,411 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 1) ISPN000079: Cache local address is node-0/ejb, physical addresses are [127.0.0.1:55200]
> &#27;[0m&#27;[0m05:46:26,428 INFO  [org.infinispan.factories.GlobalComponentRegistry] (ServerService Thread Pool -- 1) ISPN000128: Infinispan version: Infinispan 'Brahma' 5.1.5.FINAL
> &#27;[0m&#27;[0m05:46:26,648 INFO  [org.infinispan.jmx.CacheJmxRegistration] (ServerService Thread Pool -- 1) ISPN000031: MBeans were successfully registered to the platform mbean server.
> &#27;[0m&#27;[0m05:46:26,832 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 1) JBAS010281: Started remote-connector-client-mappings cache from ejb container
> &#27;[0m&#27;[0m05:46:26,850 INFO  [org.infinispan.jmx.CacheJmxRegistration] (ServerService Thread Pool -- 3) ISPN000031: MBeans were successfully registered to the platform mbean server.
> &#27;[0m&#27;[0m05:46:26,871 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 3) JBAS010281: Started repl cache from ejb container
> &#27;[0m&#27;[0m05:46:26,902 INFO  [org.jboss.as.clustering] (MSC service thread 1-1) JBAS010238: Number of cluster members: 1
> &#27;[0m&#27;[0m05:46:27,058 INFO  [org.infinispan.jmx.CacheJmxRegistration] (MSC service thread 1-4) ISPN000031: MBeans were successfully registered to the platform mbean server.
> &#27;[0m&#27;[0m05:46:27,063 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-4) JBAS010281: Started org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.NodeNameSFSB cache from ejb container
> &#27;[0m&#27;[0m05:46:27,151 INFO  [org.jboss.as.server] (management-handler-thread - 2) JBAS018559: Deployed "node-name-app.jar"
> &#27;[0m&#27;[0m05:46:28,007 INFO  [org.jboss.as.repository] (management-handler-thread - 3) JBAS014900: Content added at location /home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-1/standalone/data/content/e7/e8aacd434237d96e19be07831cf2a158b389fd/content
> &#27;[0m&#27;[0m05:46:28,024 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015876: Starting deployment of "node-name-app.jar"
> &#27;[0m&#27;[0m05:46:28,106 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-5) JNDI bindings for session bean named NodeNameSFSB in deployment unit deployment "node-name-app.jar" are as follows:
>         java:global/node-name-app/NodeNameSFSB!org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.NodeNameRetriever
>         java:app/node-name-app/NodeNameSFSB!org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.NodeNameRetriever
>         java:module/NodeNameSFSB!org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.NodeNameRetriever
>         java:jboss/exported/node-name-app/NodeNameSFSB!org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.NodeNameRetriever
>         java:global/node-name-app/NodeNameSFSB
>         java:app/node-name-app/NodeNameSFSB
>         java:module/NodeNameSFSB
> &#27;[0m&#27;[33m05:46:28,883 WARN  [org.jgroups.protocols.UDP] (ServerService Thread Pool -- 26) send buffer of socket java.net.DatagramSocket at 67310bf was set to 640KB, but the OS only allocated 131.07KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> &#27;[0m&#27;[33m05:46:28,884 WARN  [org.jgroups.protocols.UDP] (ServerService Thread Pool -- 26) receive buffer of socket java.net.DatagramSocket at 67310bf was set to 20MB, but the OS only allocated 131.07KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> &#27;[0m&#27;[33m05:46:28,885 WARN  [org.jgroups.protocols.UDP] (ServerService Thread Pool -- 26) send buffer of socket java.net.MulticastSocket at 14a1373f was set to 640KB, but the OS only allocated 131.07KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> &#27;[0m&#27;[33m05:46:28,885 WARN  [org.jgroups.protocols.UDP] (ServerService Thread Pool -- 26) receive buffer of socket java.net.MulticastSocket at 14a1373f was set to 25MB, but the OS only allocated 131.07KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> &#27;[0m&#27;[0m05:46:28,891 INFO  [stdout] (ServerService Thread Pool -- 26) 
> &#27;[0m&#27;[0m05:46:28,891 INFO  [stdout] (ServerService Thread Pool -- 26) -------------------------------------------------------------------
> &#27;[0m&#27;[0m05:46:28,891 INFO  [stdout] (ServerService Thread Pool -- 26) GMS: address=node-1/ejb, cluster=ejb, physical address=127.0.0.1:55300
> &#27;[0m&#27;[0m05:46:28,892 INFO  [stdout] (ServerService Thread Pool -- 26) -------------------------------------------------------------------
> &#27;[0m&#27;[0m05:46:28,993 INFO  [org.jboss.as.clustering] (ViewHandler,ejb,node-0/ejb) JBAS010225: New cluster view for partition ejb (id: 1, delta: 1, merge: false) : [node-0/ejb, node-1/ejb]
> &#27;[0m&#27;[0m05:46:28,999 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ViewHandler,ejb,node-0/ejb) ISPN000094: Received new cluster view: [node-0/ejb|1] [node-0/ejb, node-1/ejb]
> &#27;[0m&#27;[0m05:46:29,216 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 28) ISPN000078: Starting JGroups Channel
> &#27;[0m&#27;[0m05:46:29,240 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 28) ISPN000094: Received new cluster view: [node-0/ejb|1] [node-0/ejb, node-1/ejb]
> &#27;[0m&#27;[0m05:46:29,243 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 28) ISPN000079: Cache local address is node-1/ejb, physical addresses are [127.0.0.1:55300]
> &#27;[0m&#27;[0m05:46:29,261 INFO  [org.infinispan.factories.GlobalComponentRegistry] (ServerService Thread Pool -- 28) ISPN000128: Infinispan version: Infinispan 'Brahma' 5.1.5.FINAL
> &#27;[0m&#27;[0m05:46:29,479 INFO  [org.infinispan.jmx.CacheJmxRegistration] (ServerService Thread Pool -- 13) ISPN000031: MBeans were successfully registered to the platform mbean server.
> &#27;[0m&#27;[0m05:46:29,517 INFO  [org.infinispan.jmx.CacheJmxRegistration] (ServerService Thread Pool -- 28) ISPN000031: MBeans were successfully registered to the platform mbean server.
> &#27;[0m&#27;[0m05:46:29,879 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 28) JBAS010281: Started repl cache from ejb container
> &#27;[0m&#27;[0m05:46:29,924 INFO  [org.jboss.as.clustering] (MSC service thread 1-5) JBAS010238: Number of cluster members: 2
> &#27;[0m&#27;[0m05:46:30,001 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 13) JBAS010281: Started remote-connector-client-mappings cache from ejb container
> &#27;[0m&#27;[0m05:46:30,395 INFO  [org.jboss.ejb.client.remoting] (Remoting "node-1" task-1) EJBCLIENT000017: Received server version 1 and marshalling strategies [river]
> &#27;[0m&#27;[0m05:46:30,429 INFO  [org.jboss.ejb.client.remoting] (ejb-client-cluster-node-connection-creation-4-thread-1) EJBCLIENT000013: Successful version handshake completed for receiver context EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext at 608d116e, receiver=Remoting connection EJB receiver [connection=Remoting connection <70dbdc4b>,channel=jboss.ejb,nodename=node-0]} on channel Channel ID a99830e9 (outbound) of Remoting connection 6e843edc to /127.0.0.1:4447
> &#27;[0m&#27;[0m05:46:30,571 INFO  [org.infinispan.jmx.CacheJmxRegistration] (MSC service thread 1-4) ISPN000031: MBeans were successfully registered to the platform mbean server.
> &#27;[0m&#27;[0m05:46:30,625 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-4) JBAS010281: Started org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.NodeNameSFSB cache from ejb container
> &#27;[0m&#27;[0m05:46:30,698 INFO  [org.jboss.as.server] (management-handler-thread - 3) JBAS018559: Deployed "node-name-app.jar"
> &#27;[0m05:46:30,874 INFO  [org.jboss.ejb.client.remoting] (Remoting "config-based-ejb-client-endpoint" task-1) EJBCLIENT000017: Received server version 1 and marshalling strategies [river]
> 05:46:30,880 INFO  [org.jboss.ejb.client.remoting] (main) EJBCLIENT000013: Successful version handshake completed for receiver context EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext at 5c4e9b7d, receiver=Remoting connection EJB receiver [connection=Remoting connection <53ddcd5f>,channel=jboss.ejb,nodename=node-1]} on channel Channel ID bd97f0d8 (outbound) of Remoting connection 392bed82 to /127.0.0.1:4547
> 05:46:30,990 INFO  [org.jboss.ejb.client.remoting] (Remoting "config-based-ejb-client-endpoint" task-1) EJBCLIENT000017: Received server version 1 and marshalling strategies [river]
> 05:46:30,992 INFO  [org.jboss.ejb.client.remoting] (ejb-client-cluster-node-connection-creation-3-thread-6) EJBCLIENT000013: Successful version handshake completed for receiver context EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext at 5c4e9b7d, receiver=Remoting connection EJB receiver [connection=Remoting connection <68634baf>,channel=jboss.ejb,nodename=node-0]} on channel Channel ID e21e278d (outbound) of Remoting connection 41171d93 to /127.0.0.1:4447
> &#27;[0m05:46:31,031 INFO  [org.jboss.ejb.client] (EJB default - 1) JBoss EJB Client version 1.0.11.Final
> &#27;[0m&#27;[0m05:46:31,275 INFO  [org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.ClientSFSB] (EJB default - 2) ClientSFSB invoked on node-1
> &#27;[0m&#27;[0m05:46:31,327 INFO  [org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.NodeNameSFSB] (EJB default - 2) NodeNameSFSB invoked on node-1
> &#27;[0m&#27;[0m05:46:31,407 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 13) ISPN000029: Passivating all entries to disk
> &#27;[0m&#27;[0m05:46:31,435 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 13) ISPN000030: Passivated 1 entries in 27 milliseconds
> &#27;[0m&#27;[0m05:46:31,454 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 13) JBAS010282: Stopped org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.NodeNameSFSB cache from ejb container
> &#27;[0m&#27;[0m05:46:31,506 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-5) ISPN000029: Passivating all entries to disk
> &#27;[0m&#27;[0m05:46:31,512 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-5) ISPN000030: Passivated 0 entries in 5 milliseconds
> &#27;[0m&#27;[0m05:46:31,544 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-5) JBAS010282: Stopped repl cache from ejb container
> &#27;[0m&#27;[0m05:46:31,544 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-3) JBAS010282: Stopped remote-connector-client-mappings cache from ejb container
> &#27;[0m&#27;[0m05:46:31,553 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015877: Stopped deployment node-name-app.jar in 168ms
> &#27;[0m&#27;[0m05:46:31,598 INFO  [org.infinispan.cacheviews.CacheViewsManagerImpl] (OOB-15,null) ISPN000170: Our last committed view (CacheView{viewId=2, members=[node-0/ejb, node-1/ejb]}) is not the same as the coordinator's last committed view (CacheView{viewId=3, members=[node-0/ejb]}). This is normal during a merge
> &#27;[0m&#27;[0m05:46:31,631 INFO  [org.infinispan.cacheviews.CacheViewsManagerImpl] (OOB-17,null) ISPN000170: Our last committed view (CacheView{viewId=2, members=[node-0/ejb, node-1/ejb]}) is not the same as the coordinator's last committed view (CacheView{viewId=3, members=[node-0/ejb]}). This is normal during a merge
> &#27;[0m&#27;[33m05:46:31,602 WARN  [org.infinispan.commands.control.CacheViewControlCommand] (OOB-15,null) ISPN000071: Caught exception when handling command CacheViewControlCommand{cache=remote-connector-client-mappings, type=PREPARE_VIEW, sender=node-0/ejb, newViewId=4, newMembers=[node-0/ejb, node-1/ejb], oldViewId=3, oldMembers=[node-0/ejb]}: java.lang.IllegalStateException: remote-connector-client-mappings: Received cache view prepare request after the local node has already shut down
>         at org.infinispan.cacheviews.CacheViewsManagerImpl.handlePrepareView(CacheViewsManagerImpl.java:487)
>         at org.infinispan.commands.control.CacheViewControlCommand.perform(CacheViewControlCommand.java:126)
>         at org.infinispan.remoting.InboundInvocationHandlerImpl.handle(InboundInvocationHandlerImpl.java:95)
>         at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommand(CommandAwareRpcDispatcher.java:226)
>         at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:203)
>         at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:465)
>         at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:372)
>         at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:247)
>         at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:601)
>         at org.jgroups.blocks.mux.MuxUpHandler.up(MuxUpHandler.java:130)
>         at org.jgroups.JChannel.up(JChannel.java:715)
>         at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1020)
>         at org.jgroups.protocols.RSVP.up(RSVP.java:179)
>         at org.jgroups.protocols.FRAG2.up(FRAG2.java:181)
>         at org.jgroups.protocols.FlowControl.up(FlowControl.java:418)
>         at org.jgroups.protocols.FlowControl.up(FlowControl.java:400)
>         at org.jgroups.protocols.pbcast.GMS.up(GMS.java:899)
>         at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244)
>         at org.jgroups.protocols.UNICAST2.handleDataReceived(UNICAST2.java:744)
>         at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:414)
>         at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:572)
>         at org.jgroups.protocols.BARRIER.up(BARRIER.java:102)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143)
>         at org.jgroups.protocols.FD.up(FD.java:273)
>         at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288)
>         at org.jgroups.protocols.MERGE2.up(MERGE2.java:205)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:359)
>         at org.jgroups.protocols.TP$ProtocolAdapter.up(TP.java:2568)
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:1211)
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1775)
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1748)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
>         at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> &#27;[0m&#27;[33m05:46:31,596 WARN  [org.infinispan.commands.control.CacheViewControlCommand] (OOB-20,null) ISPN000071: Caught exception when handling command CacheViewControlCommand{cache=repl, type=PREPARE_VIEW, sender=node-0/ejb, newViewId=3, newMembers=[node-0/ejb, node-1/ejb, node-1/ejb], oldViewId=2, oldMembers=[node-0/ejb, node-1/ejb]}: java.lang.IllegalStateException: repl: Received cache view prepare request after the local node has already shut down
>         at org.infinispan.cacheviews.CacheViewsManagerImpl.handlePrepareView(CacheViewsManagerImpl.java:487)
>         at org.infinispan.commands.control.CacheViewControlCommand.perform(CacheViewControlCommand.java:126)
>         at org.infinispan.remoting.InboundInvocationHandlerImpl.handle(InboundInvocationHandlerImpl.java:95)
>         at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommand(CommandAwareRpcDispatcher.java:226)
>         at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:203)
>         at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:465)
>         at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:372)
>         at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:247)
>         at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:601)
>         at org.jgroups.blocks.mux.MuxUpHandler.up(MuxUpHandler.java:130)
>         at org.jgroups.JChannel.up(JChannel.java:715)
>         at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1020)
>         at org.jgroups.protocols.RSVP.up(RSVP.java:179)
>         at org.jgroups.protocols.FRAG2.up(FRAG2.java:181)
>         at org.jgroups.protocols.FlowControl.up(FlowControl.java:418)
>         at org.jgroups.protocols.FlowControl.up(FlowControl.java:400)
>         at org.jgroups.protocols.pbcast.GMS.up(GMS.java:899)
>         at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244)
>         at org.jgroups.protocols.UNICAST2.handleDataReceived(UNICAST2.java:744)
>         at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:414)
>         at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:572)
>         at org.jgroups.protocols.BARRIER.up(BARRIER.java:102)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143)
>         at org.jgroups.protocols.FD.up(FD.java:273)
>         at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288)
>         at org.jgroups.protocols.MERGE2.up(MERGE2.java:205)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:359)
>         at org.jgroups.protocols.TP$ProtocolAdapter.up(TP.java:2568)
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:1211)
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1775)
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1748)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
>         at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> &#27;[0m&#27;[33m05:46:31,631 WARN  [org.infinispan.commands.control.CacheViewControlCommand] (OOB-16,null) ISPN000071: Caught exception when handling command CacheViewControlCommand{cache=repl, type=PREPARE_VIEW, sender=node-0/ejb, newViewId=3, newMembers=[node-0/ejb, node-1/ejb, node-1/ejb], oldViewId=2, oldMembers=[node-0/ejb, node-1/ejb]}: java.lang.IllegalStateException: Cannot prepare new view CacheView{viewId=3, members=[node-0/ejb, node-1/ejb, node-1/ejb]} on cache repl, we are currently preparing view CacheView{viewId=3, members=[node-0/ejb, node-1/ejb, node-1/ejb]}
>         at org.infinispan.cacheviews.CacheViewInfo.prepareView(CacheViewInfo.java:102)
>         at org.infinispan.cacheviews.CacheViewsManagerImpl.handlePrepareView(CacheViewsManagerImpl.java:481)
>         at org.infinispan.commands.control.CacheViewControlCommand.perform(CacheViewControlCommand.java:126)
>         at org.infinispan.remoting.InboundInvocationHandlerImpl.handle(InboundInvocationHandlerImpl.java:95)
>         at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommand(CommandAwareRpcDispatcher.java:226)
>         at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:203)
>         at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:465)
>         at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:372)
>         at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:247)
>         at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:601)
>         at org.jgroups.blocks.mux.MuxUpHandler.up(MuxUpHandler.java:130)
>         at org.jgroups.JChannel.up(JChannel.java:715)
>         at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1020)
>         at org.jgroups.protocols.RSVP.up(RSVP.java:179)
>         at org.jgroups.protocols.FRAG2.up(FRAG2.java:181)
>         at org.jgroups.protocols.FlowControl.up(FlowControl.java:418)
>         at org.jgroups.protocols.FlowControl.up(FlowControl.java:400)
>         at org.jgroups.protocols.pbcast.GMS.up(GMS.java:899)
>         at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244)
>         at org.jgroups.protocols.UNICAST2.handleDataReceived(UNICAST2.java:744)
>         at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:414)
>         at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:572)
>         at org.jgroups.protocols.BARRIER.up(BARRIER.java:102)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143)
>         at org.jgroups.protocols.FD.up(FD.java:273)
>         at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288)
>         at org.jgroups.protocols.MERGE2.up(MERGE2.java:205)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:359)
>         at org.jgroups.protocols.TP$ProtocolAdapter.up(TP.java:2568)
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:1211)
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1775)
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1748)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
>         at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> &#27;[0m&#27;[33m05:46:31,637 WARN  [org.infinispan.commands.control.CacheViewControlCommand] (OOB-17,null) ISPN000071: Caught exception when handling command CacheViewControlCommand{cache=org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.NodeNameSFSB, type=PREPARE_VIEW, sender=node-0/ejb, newViewId=4, newMembers=[node-0/ejb, node-1/ejb], oldViewId=3, oldMembers=[node-0/ejb]}: java.lang.IllegalStateException: org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.NodeNameSFSB: Received cache view prepare request after the local node has already shut down
>         at org.infinispan.cacheviews.CacheViewsManagerImpl.handlePrepareView(CacheViewsManagerImpl.java:487)
>         at org.infinispan.commands.control.CacheViewControlCommand.perform(CacheViewControlCommand.java:126)
>         at org.infinispan.remoting.InboundInvocationHandlerImpl.handle(InboundInvocationHandlerImpl.java:95)
>         at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommand(CommandAwareRpcDispatcher.java:226)
>         at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:203)
>         at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:465)
>         at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:372)
>         at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:247)
>         at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:601)
>         at org.jgroups.blocks.mux.MuxUpHandler.up(MuxUpHandler.java:130)
>         at org.jgroups.JChannel.up(JChannel.java:715)
>         at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1020)
>         at org.jgroups.protocols.RSVP.up(RSVP.java:179)
>         at org.jgroups.protocols.FRAG2.up(FRAG2.java:181)
>         at org.jgroups.protocols.FlowControl.up(FlowControl.java:418)
>         at org.jgroups.protocols.FlowControl.up(FlowControl.java:400)
>         at org.jgroups.protocols.pbcast.GMS.up(GMS.java:899)
>         at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244)
>         at org.jgroups.protocols.UNICAST2.handleDataReceived(UNICAST2.java:744)
>         at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:414)
>         at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:572)
>         at org.jgroups.protocols.BARRIER.up(BARRIER.java:102)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143)
>         at org.jgroups.protocols.FD.up(FD.java:273)
>         at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288)
>         at org.jgroups.protocols.MERGE2.up(MERGE2.java:205)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:359)
>         at org.jgroups.protocols.TP$ProtocolAdapter.up(TP.java:2568)
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:1211)
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1775)
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1748)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
>         at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> &#27;[0m&#27;[0m05:46:31,865 INFO  [org.jboss.as.clustering] (ViewHandler,ejb,node-0/ejb) JBAS010225: New cluster view for partition ejb (id: 2, delta: -1, merge: false) : [node-0/ejb]
> &#27;[0m&#27;[0m05:46:31,869 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ViewHandler,ejb,node-0/ejb) ISPN000094: Received new cluster view: [node-0/ejb|2] [node-0/ejb]
> &#27;[0m&#27;[31m05:46:31,866 ERROR [org.infinispan.cacheviews.CacheViewsManagerImpl] (CacheViewInstaller-3,node-0/ejb) ISPN000172: Failed to prepare view CacheView{viewId=4, members=[node-0/ejb, node-1/ejb]} for cache  org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.NodeNameSFSB, rolling back to view CacheView{viewId=3, members=[node-0/ejb]}: java.util.concurrent.ExecutionException: org.infinispan.remoting.transport.jgroups.SuspectException: Node node-1/ejb was suspected
>         at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:232) [rt.jar:1.6.0_29]
>         at java.util.concurrent.FutureTask.get(FutureTask.java:91) [rt.jar:1.6.0_29]
>         at org.infinispan.cacheviews.CacheViewsManagerImpl.clusterPrepareView(CacheViewsManagerImpl.java:318) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.cacheviews.CacheViewsManagerImpl.clusterInstallView(CacheViewsManagerImpl.java:249) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.cacheviews.CacheViewsManagerImpl$ViewInstallationTask.call(CacheViewsManagerImpl.java:875) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [rt.jar:1.6.0_29]
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138) [rt.jar:1.6.0_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
>         at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> Caused by: org.infinispan.remoting.transport.jgroups.SuspectException: Node node-1/ejb was suspected
>         at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:170) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:489) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.cacheviews.CacheViewsManagerImpl$2.call(CacheViewsManagerImpl.java:302) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.cacheviews.CacheViewsManagerImpl$2.call(CacheViewsManagerImpl.java:299) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         ... 5 more
> Caused by: SuspectedException
>         at org.jgroups.blocks.MessageDispatcher.sendMessage(MessageDispatcher.java:373) [jgroups-3.1.0.Final.jar:3.1.0.Final]
>         at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:275) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:165) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         ... 8 more
> &#27;[0m&#27;[31m05:46:31,866 ERROR [org.infinispan.cacheviews.CacheViewsManagerImpl] (CacheViewInstaller-1,node-0/ejb) ISPN000172: Failed to prepare view CacheView{viewId=4, members=[node-0/ejb, node-1/ejb]} for cache  remote-connector-client-mappings, rolling back to view CacheView{viewId=3, members=[node-0/ejb]}: java.util.concurrent.ExecutionException: org.infinispan.remoting.transport.jgroups.SuspectException: Node node-1/ejb was suspected
>         at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:232) [rt.jar:1.6.0_29]
>         at java.util.concurrent.FutureTask.get(FutureTask.java:91) [rt.jar:1.6.0_29]
>         at org.infinispan.cacheviews.CacheViewsManagerImpl.clusterPrepareView(CacheViewsManagerImpl.java:318) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.cacheviews.CacheViewsManagerImpl.clusterInstallView(CacheViewsManagerImpl.java:249) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.cacheviews.CacheViewsManagerImpl$ViewInstallationTask.call(CacheViewsManagerImpl.java:875) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [rt.jar:1.6.0_29]
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138) [rt.jar:1.6.0_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
>         at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> Caused by: org.infinispan.remoting.transport.jgroups.SuspectException: Node node-1/ejb was suspected
>         at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:170) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:489) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.cacheviews.CacheViewsManagerImpl$2.call(CacheViewsManagerImpl.java:302) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.cacheviews.CacheViewsManagerImpl$2.call(CacheViewsManagerImpl.java:299) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         ... 5 more
> Caused by: SuspectedException
>         at org.jgroups.blocks.MessageDispatcher.sendMessage(MessageDispatcher.java:373) [jgroups-3.1.0.Final.jar:3.1.0.Final]
>         at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:275) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:165) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         ... 8 more
> &#27;[0m&#27;[0m05:46:31,968 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000082: Stopping the RpcDispatcher
> &#27;[0m&#27;[0m05:46:32,008 INFO  [org.jboss.as.repository] (management-handler-thread - 1) JBAS014901: Content removed from location /home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-1/standalone/data/content/e7/e8aacd434237d96e19be07831cf2a158b389fd/content
> &#27;[0m&#27;[0m05:46:32,010 INFO  [org.jboss.as.server] (management-handler-thread - 1) JBAS018558: Undeployed "node-name-app.jar"
> &#27;[0m&#27;[0m05:46:32,023 INFO  [org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.ClientSFSB] (EJB default - 3) ClientSFSB invoked on node-1
> &#27;[0m&#27;[0m05:46:32,030 INFO  [org.jboss.as.ejb3] (EJB default - 3) JBAS014101: Failed to find SFSB instance with session ID {[-104, 47, 35, -120, 125, 36, 71, 13, -117, 111, -46, -34, -73, -51, 56, 28]} in cache
> &#27;[0m&#27;[31m05:46:32,032 ERROR [org.jboss.as.ejb3.invocation] (EJB default - 3) JBAS014134: EJB Invocation failed on component ClientSFSB for method public abstract java.lang.String org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.ClientSFSBRemote.invokeAndFetchNodeNameFromClusteredSFSBRemoteBean(): javax.ejb.EJBException: java.lang.IllegalArgumentException: JBAS014155: Unknown deployment - app name:  module name: node-name-app distinct name: 
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:165) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:229) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:303) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:189) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:42) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:43) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:327) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:70) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:205) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [rt.jar:1.6.0_29]
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [rt.jar:1.6.0_29]
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138) [rt.jar:1.6.0_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
>         at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
>         at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> Caused by: java.lang.IllegalArgumentException: JBAS014155: Unknown deployment - app name:  module name: node-name-app distinct name: 
>         at org.jboss.as.ejb3.remote.LocalEjbReceiver.findBean(LocalEjbReceiver.java:317) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.as.ejb3.remote.LocalEjbReceiver.processInvocation(LocalEjbReceiver.java:142) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:181) [jboss-ejb-client-1.0.11.Final.jar:1.0.11.Final]
>         at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:42) [jboss-ejb-client-1.0.11.Final.jar:1.0.11.Final]
>         at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183) [jboss-ejb-client-1.0.11.Final.jar:1.0.11.Final]
>         at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:125) [jboss-ejb-client-1.0.11.Final.jar:1.0.11.Final]
>         at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183) [jboss-ejb-client-1.0.11.Final.jar:1.0.11.Final]
>         at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:136) [jboss-ejb-client-1.0.11.Final.jar:1.0.11.Final]
>         at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:121) [jboss-ejb-client-1.0.11.Final.jar:1.0.11.Final]
>         at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:104) [jboss-ejb-client-1.0.11.Final.jar:1.0.11.Final]
>         at $Proxy30.getNodeName(Unknown Source) at org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.ClientSFSB.invokeAndFetchNodeNameFromClusteredSFSBRemoteBean(ClientSFSB.java:53) [client-app.jar:]
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_29]
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_29]
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_29]
>         at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_29]
>         at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:36) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:58)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:156) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:67) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:227) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         ... 29 more
> &#27;[0m05:46:32,102 INFO  [org.jboss.ejb.client.remoting] (Remoting "config-based-ejb-client-endpoint" task-3) EJBCLIENT000011: Discarding result for invocation id 2 since no waiting context found
> &#27;[0m05:46:32,228 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015877: Stopped deployment client-app.jar in 54ms
> &#27;[0m&#27;[0m05:46:32,272 INFO  [org.jboss.as.repository] (management-handler-thread - 2) JBAS014901: Content removed from location /home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-1/standalone/data/content/e2/09ce1c0485164619e2ea871a0013f2781ab162/content
> &#27;[0m&#27;[0m05:46:32,274 INFO  [org.jboss.as.server] (management-handler-thread - 2) JBAS018558: Undeployed "client-app.jar"
> &#27;[0m&#27;[0m05:46:32,328 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 3) ISPN000029: Passivating all entries to disk
> &#27;[0m&#27;[0m05:46:32,350 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 3) ISPN000030: Passivated 1 entries in 22 milliseconds
> &#27;[0m&#27;[0m05:47:31,693 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 3) JBAS010282: Stopped org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.NodeNameSFSB cache from ejb container
> &#27;[0m&#27;[0m05:47:31,740 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-6) ISPN000029: Passivating all entries to disk
> &#27;[0m&#27;[0m05:47:31,746 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-6) ISPN000030: Passivated 0 entries in 5 milliseconds
> &#27;[0m&#27;[0m05:47:31,764 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-6) JBAS010282: Stopped repl cache from ejb container
> &#27;[0m&#27;[0m05:47:31,768 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015877: Stopped deployment node-name-app.jar in 59465ms
> &#27;[0m&#27;[31m05:47:31,882 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (notification-thread-6) ISPN000136: Execution error: org.infinispan.statetransfer.StateTransferInProgressException: Timed out waiting for the state transfer lock, state transfer in progress for view 4
>         at org.infinispan.interceptors.StateTransferLockInterceptor.signalStateTransferInProgress(StateTransferLockInterceptor.java:201)
>         at org.infinispan.interceptors.StateTransferLockInterceptor.visitPrepareCommand(StateTransferLockInterceptor.java:81)
>         at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
>         at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130)
>         at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
>         at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
>         at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:132)
>         at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:91)
>         at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
>         at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
>         at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:86)
>         at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
>         at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
>         at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:345)
>         at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:140)
>         at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:122)
>         at org.infinispan.transaction.synchronization.SynchronizationAdapter.beforeCompletion(SynchronizationAdapter.java:68)
>         at org.infinispan.transaction.tm.DummyTransaction.notifyBeforeCompletion(DummyTransaction.java:230)
>         at org.infinispan.transaction.tm.DummyTransaction.runPrepare(DummyTransaction.java:242)
>         at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:86)
>         at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:102)
>         at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:123)
>         at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:105)
>         at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:86)
>         at org.infinispan.CacheImpl.endBatch(CacheImpl.java:615)
>         at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:80)
>         at org.jboss.as.clustering.registry.RegistryService.invoke(RegistryService.java:260)
>         at org.jboss.as.clustering.registry.RegistryService.viewChanged(RegistryService.java:195)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_29]
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_29]
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_29]
>         at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_29]
>         at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation$1.run(AbstractListenerImpl.java:200)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
>         at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> &#27;[0m&#27;[31m05:47:31,905 ERROR [org.infinispan.transaction.TransactionCoordinator] (notification-thread-6) Error while processing prepare: org.infinispan.statetransfer.StateTransferInProgressException: Timed out waiting for the state transfer lock, state transfer in progress for view 4
>         at org.infinispan.interceptors.StateTransferLockInterceptor.signalStateTransferInProgress(StateTransferLockInterceptor.java:201)
>         at org.infinispan.interceptors.StateTransferLockInterceptor.visitPrepareCommand(StateTransferLockInterceptor.java:81)
>         at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
>         at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130)
>         at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
>         at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
>         at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:132)
>         at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:91)
>         at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
>         at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
>         at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:86)
>         at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
>         at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
>         at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:345)
>         at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:140)
>         at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:122)
>         at org.infinispan.transaction.synchronization.SynchronizationAdapter.beforeCompletion(SynchronizationAdapter.java:68)
>         at org.infinispan.transaction.tm.DummyTransaction.notifyBeforeCompletion(DummyTransaction.java:230)
>         at org.infinispan.transaction.tm.DummyTransaction.runPrepare(DummyTransaction.java:242)
>         at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:86)
>         at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:102)
>         at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:123)
>         at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:105)
>         at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:86)
>         at org.infinispan.CacheImpl.endBatch(CacheImpl.java:615)
>         at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:80)
>         at org.jboss.as.clustering.registry.RegistryService.invoke(RegistryService.java:260)
>         at org.jboss.as.clustering.registry.RegistryService.viewChanged(RegistryService.java:195)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_29]
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_29]
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_29]
>         at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_29]
>         at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation$1.run(AbstractListenerImpl.java:200)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
>         at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> &#27;[0m&#27;[31m05:47:31,924 ERROR [org.infinispan.transaction.tm.DummyTransaction] (notification-thread-6) ISPN000109: beforeCompletion() failed for SynchronizationAdapter{localTransaction=LocalTransaction{remoteLockedNodes=null, isMarkedForRollback=false, transaction=DummyTransaction{xid=DummyXid{id=3}, status=1}, lockedKeys=null, backupKeyLocks=null, viewId=2} org.infinispan.transaction.synchronization.SyncLocalTransaction at 2} org.infinispan.transaction.synchronization.SynchronizationAdapter at 21: org.infinispan.CacheException: Could not prepare. 
>         at org.infinispan.transaction.synchronization.SynchronizationAdapter.beforeCompletion(SynchronizationAdapter.java:70)
>         at org.infinispan.transaction.tm.DummyTransaction.notifyBeforeCompletion(DummyTransaction.java:230)
>         at org.infinispan.transaction.tm.DummyTransaction.runPrepare(DummyTransaction.java:242)
>         at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:86)
>         at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:102)
>         at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:123)
>         at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:105)
>         at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:86)
>         at org.infinispan.CacheImpl.endBatch(CacheImpl.java:615)
>         at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:80)
>         at org.jboss.as.clustering.registry.RegistryService.invoke(RegistryService.java:260)
>         at org.jboss.as.clustering.registry.RegistryService.viewChanged(RegistryService.java:195)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_29]
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_29]
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_29]
>         at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_29]
>         at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation$1.run(AbstractListenerImpl.java:200)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
>         at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> Caused by: javax.transaction.xa.XAException
>         at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:160)
>         at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:122)
>         at org.infinispan.transaction.synchronization.SynchronizationAdapter.beforeCompletion(SynchronizationAdapter.java:68)
>         ... 19 more
> &#27;[0m&#27;[33m05:47:31,936 WARN  [org.infinispan.notifications.cachemanagerlistener.CacheManagerNotifierImpl] (notification-thread-6) ISPN000134: Unable to invoke method public void org.jboss.as.clustering.registry.RegistryService.viewChanged(org.infinispan.notifications.cachemanagerlistener.event.ViewChangedEvent) on Object instance org.jboss.as.clustering.registry.RegistryService at d07ffdf - removing this target object from list of listeners!: org.infinispan.CacheException: Unable to end batch
>         at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:107)
>         at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:86)
>         at org.infinispan.CacheImpl.endBatch(CacheImpl.java:615)
>         at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:80)
>         at org.jboss.as.clustering.registry.RegistryService.invoke(RegistryService.java:260)
>         at org.jboss.as.clustering.registry.RegistryService.viewChanged(RegistryService.java:195)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_29]
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_29]
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_29]
>         at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_29]
>         at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation$1.run(AbstractListenerImpl.java:200)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
>         at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> Caused by: javax.transaction.RollbackException: Exception rolled back, status is: 9
>         at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:89)
>         at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:102)
>         at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:123)
>         at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:105)
>         ... 13 more
> &#27;[0m&#27;[31m05:48:31,737 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (MSC service thread 1-3) ISPN000136: Execution error: org.infinispan.statetransfer.StateTransferInProgressException: Timed out waiting for the state transfer lock, state transfer in progress for view 4
>         at org.infinispan.interceptors.StateTransferLockInterceptor.signalStateTransferInProgress(StateTransferLockInterceptor.java:201) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.interceptors.StateTransferLockInterceptor.visitPrepareCommand(StateTransferLockInterceptor.java:81) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:132) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:91) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:86) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:345) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:140) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:122) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.synchronization.SynchronizationAdapter.beforeCompletion(SynchronizationAdapter.java:68) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.tm.DummyTransaction.notifyBeforeCompletion(DummyTransaction.java:230) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.tm.DummyTransaction.runPrepare(DummyTransaction.java:242) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:86) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:102) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:123) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:105) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:86) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.CacheImpl.endBatch(CacheImpl.java:615) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:80) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.jboss.as.clustering.registry.RegistryService.invoke(RegistryService.java:260) [jboss-as-clustering-registry-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.as.clustering.registry.RegistryService.stop(RegistryService.java:162) [jboss-as-clustering-registry-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:1911) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>         at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:1874) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
>         at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> &#27;[0m&#27;[31m05:48:31,745 ERROR [org.infinispan.transaction.TransactionCoordinator] (MSC service thread 1-3) Error while processing prepare: org.infinispan.statetransfer.StateTransferInProgressException: Timed out waiting for the state transfer lock, state transfer in progress for view 4
>         at org.infinispan.interceptors.StateTransferLockInterceptor.signalStateTransferInProgress(StateTransferLockInterceptor.java:201) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.interceptors.StateTransferLockInterceptor.visitPrepareCommand(StateTransferLockInterceptor.java:81) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:132) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:91) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:86) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:345) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:140) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:122) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.synchronization.SynchronizationAdapter.beforeCompletion(SynchronizationAdapter.java:68) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.tm.DummyTransaction.notifyBeforeCompletion(DummyTransaction.java:230) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.tm.DummyTransaction.runPrepare(DummyTransaction.java:242) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:86) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:102) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:123) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:105) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:86) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.CacheImpl.endBatch(CacheImpl.java:615) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:80) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.jboss.as.clustering.registry.RegistryService.invoke(RegistryService.java:260) [jboss-as-clustering-registry-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.as.clustering.registry.RegistryService.stop(RegistryService.java:162) [jboss-as-clustering-registry-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:1911) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>         at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:1874) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
>         at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> &#27;[0m&#27;[31m05:48:31,754 ERROR [org.infinispan.transaction.tm.DummyTransaction] (MSC service thread 1-3) ISPN000109: beforeCompletion() failed for SynchronizationAdapter{localTransaction=LocalTransaction{remoteLockedNodes=null, isMarkedForRollback=false, transaction=DummyTransaction{xid=DummyXid{id=4}, status=1}, lockedKeys=null, backupKeyLocks=null, viewId=2} org.infinispan.transaction.synchronization.SyncLocalTransaction at 3} org.infinispan.transaction.synchronization.SynchronizationAdapter at 22: org.infinispan.CacheException: Could not prepare. 
>         at org.infinispan.transaction.synchronization.SynchronizationAdapter.beforeCompletion(SynchronizationAdapter.java:70) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.tm.DummyTransaction.notifyBeforeCompletion(DummyTransaction.java:230) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.tm.DummyTransaction.runPrepare(DummyTransaction.java:242) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:86) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:102) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:123) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:105) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:86) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.CacheImpl.endBatch(CacheImpl.java:615) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:80) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.jboss.as.clustering.registry.RegistryService.invoke(RegistryService.java:260) [jboss-as-clustering-registry-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.as.clustering.registry.RegistryService.stop(RegistryService.java:162) [jboss-as-clustering-registry-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:1911) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>         at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:1874) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
>         at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> Caused by: javax.transaction.xa.XAException
>         at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:160) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:122) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.synchronization.SynchronizationAdapter.beforeCompletion(SynchronizationAdapter.java:68) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         ... 16 more
> &#27;[0m&#27;[33m05:48:31,763 WARN  [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC00004: Failure during stop of service jboss.ejb.remoting.connector.client-mappings.registry.ejb: org.infinispan.CacheException: Unable to end batch
>         at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:107)
>         at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:86)
>         at org.infinispan.CacheImpl.endBatch(CacheImpl.java:615)
>         at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:80)
>         at org.jboss.as.clustering.registry.RegistryService.invoke(RegistryService.java:260)
>         at org.jboss.as.clustering.registry.RegistryService.stop(RegistryService.java:162)
>         at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:1911) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>         at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:1874) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
>         at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> Caused by: javax.transaction.RollbackException: Exception rolled back, status is: 9
>         at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:89)
>         at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:102)
>         at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:123)
>         at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:105)
>         ... 10 more
> &#27;[0m&#27;[0m05:48:31,791 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-2) JBAS010282: Stopped remote-connector-client-mappings cache from ejb container
> &#27;[0m&#27;[0m05:48:31,839 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000082: Stopping the RpcDispatcher
> &#27;[0m&#27;[0m05:48:31,899 INFO  [org.jboss.as.repository] (management-handler-thread - 3) JBAS014901: Content removed from location /home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-0/standalone/data/content/dc/274297a56acebcb3414b7407fa05d097f6691b/content
> &#27;[0m&#27;[0m05:48:31,902 INFO  [org.jboss.as.server] (management-handler-thread - 3) JBAS018558: Undeployed "node-name-app.jar"
> &#27;[0m05:48:31,906 INFO  [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual stopping of a server instance
> 05:48:32,069 INFO  [org.jboss.ejb.client.remoting] (Remoting "config-based-ejb-client-endpoint" task-2) EJBCLIENT000016: Channel Channel ID e21e278d (outbound) of Remoting connection 41171d93 to /127.0.0.1:4447 can no longer process messages
> &#27;[0m05:48:32,149 INFO  [org.jboss.ejb.client.remoting] (Remoting "node-1" task-3) EJBCLIENT000016: Channel Channel ID a99830e9 (outbound) of Remoting connection 6e843edc to /127.0.0.1:4447 can no longer process messages
> &#27;[0m05:48:32,256 INFO  [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual stopping of a server instance 
> 05:48:32,345 INFO  [org.jboss.ejb.client.remoting] (Remoting "config-based-ejb-client-endpoint" task-4) EJBCLIENT000016: Channel Channel ID bd97f0d8 (outbound) of Remoting connection 392bed82 to /127.0.0.1:4547 can no longer process messages

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Fri Oct  4 17:42:39 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-307) Add ability to migrate timers
 between data stores
In-Reply-To: <JIRA.12485998.1362106589000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485998.1362106589000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485998.1362106589000.15295.1380922959184@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-307:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Add ability to migrate timers between data stores
> -------------------------------------------------
>
>                 Key: WFLY-307
>                 URL: https://issues.jboss.org/browse/WFLY-307
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EJB
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.CR1
>
>
> It should be possible to move timers between data stores, so that timers can be migrated from the legacy file store.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:39 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-301) Undertow management API
In-Reply-To: <JIRA.12489432.1366009861000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489432.1366009861000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489432.1366009861000.15312.1380922959588@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-301:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Undertow management API
> -----------------------
>
>                 Key: WFLY-301
>                 URL: https://issues.jboss.org/browse/WFLY-301
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management, Web (Undertow)
>            Reporter: Heiko Braun
>            Assignee: Tomaz Cerar
>             Fix For: 8.0.0.CR1
>
>
> Expose undertow subsystem management opertions

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:39 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-288) SecurityDomainJndiInjectable
 should allow "java:/jaas" prefixed security domain on demand
In-Reply-To: <JIRA.12463048.1333389594000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12463048.1333389594000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12463048.1333389594000.15320.1380922959729@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-288:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> SecurityDomainJndiInjectable should allow "java:/jaas" prefixed security domain on demand
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-288
>                 URL: https://issues.jboss.org/browse/WFLY-288
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Security
>            Reporter: Anil Saldhana
>            Assignee: Stefan Guilhen
>             Fix For: 8.0.0.CR1
>
>
> Currently,  security domain strings of the form "java:/jaas/sd" are not resolving properly.  IMO we should allow users to deploy applications on AS4,5,6,7 if they need to.
> So have a flag inside the SecurityDomainJndiInjectable class that is turned off by default.  If you turn it on, then "java:/jaas" is unprefixed if present.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:39 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-308) Provide facility for running
 ejb3 ws endpoints authorization independently
In-Reply-To: <JIRA.12478846.1352382445000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12478846.1352382445000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12478846.1352382445000.15293.1380922959152@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-308:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Provide facility for running ejb3 ws endpoints authorization independently
> --------------------------------------------------------------------------
>
>                 Key: WFLY-308
>                 URL: https://issues.jboss.org/browse/WFLY-308
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EJB
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Alessio Soldano
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.CR1
>
>
> We'd need a mean of checking auth for ejb3 ws endpoints before the actual invocation is performed. This is basically required to enforce security before running JAXWS handler.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:39 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-305) Implement mail inflow
In-Reply-To: <JIRA.12462152.1332335330000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12462152.1332335330000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12462152.1332335330000.15298.1380922959241@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-305:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Implement mail inflow
> ---------------------
>
>                 Key: WFLY-305
>                 URL: https://issues.jboss.org/browse/WFLY-305
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EE
>            Reporter: Tomaz Cerar
>            Assignee: Tomaz Cerar
>             Fix For: 8.0.0.CR1
>
>
> in previous versions of as we had mail-ra resource adapter that added functionality of handling inflow mails.
> there is implementation of this ironjacamar so the code could be reused.
> Resource addapter could/should be added the same way hornetq addapter is added in messaging subsystem.
> code and documentation from ironjacamer
> https://svn.jboss.org/repos/jbossas/projects/jboss-jca/trunk/adapters/src/main/java/org/jboss/jca/adapters/mail/
> http://docs.jboss.org/ironjacamar/userguide/1.1/en-US/html/introduction.html#overview_inbound

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:39 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-296) Batch integration API
In-Reply-To: <JIRA.12489438.1366010343000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489438.1366010343000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489438.1366010343000.15317.1380922959673@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-296:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Batch integration API
> ---------------------
>
>                 Key: WFLY-296
>                 URL: https://issues.jboss.org/browse/WFLY-296
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Cheng Fang
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:39 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-285) Add clustered database based
	timers
In-Reply-To: <JIRA.12485997.1362106420000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485997.1362106420000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485997.1362106420000.15323.1380922959794@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-285:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Add clustered database based timers
> -----------------------------------
>
>                 Key: WFLY-285
>                 URL: https://issues.jboss.org/browse/WFLY-285
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EJB
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.CR1
>
>
> Clustering should be supported for database timers. 
> The general ideal will be that a single database is shared by all nodes in the cluster. When a timer is created it will be inserted into the database. Periodically at a configured interval nodes will refresh their list of active timers from the database. 
> When a timer expires a node will attempt to grab ownership of the timer in the database by updating the row. Due to the use of either optimisitic locking or traditional DB locks only 1 node will be successful, and that node will run the task. 
> We will also support write only nodes, nodes that can create timer tasks, but do not attempt to run them, to allow timer tasks to be run by a subset of the nodes.
> So that you don't have hundreds of existing partition name feature will allow clustered timers to be grouped into smaller partitions, so you can limit the number of nodes that are contending for a timer.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:40 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-283) EJB timers in cluster and
	failover support
In-Reply-To: <JIRA.12460393.1330513902000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12460393.1330513902000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12460393.1330513902000.15351.1380922960528@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-283:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> EJB timers in cluster and failover support
> ------------------------------------------
>
>                 Key: WFLY-283
>                 URL: https://issues.jboss.org/browse/WFLY-283
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering, EJB
>            Reporter: Radoslav Husar
>            Assignee: Paul Ferraro
>             Fix For: 8.0.0.CR1
>
>
> Support for clustered EJB timer service providing failover.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:40 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-277) TS: Integrate JUnitDiff
In-Reply-To: <JIRA.12460907.1331103224000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12460907.1331103224000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12460907.1331103224000.15359.1380922960733@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-277:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> TS: Integrate JUnitDiff
> -----------------------
>
>                 Key: WFLY-277
>                 URL: https://issues.jboss.org/browse/WFLY-277
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Test Suite
>            Reporter: Ondrej Zizka
>            Assignee: Ondrej Zizka
>            Priority: Minor
>             Fix For: 8.0.0.CR1
>
>   Original Estimate: 3 weeks
>  Remaining Estimate: 3 weeks
>
> Running with
> {code}
> -DjunitDiff='<path1>:<path2>:<path3>'
> {code}
> would create a comparison to given testsuite result sets (JUnit .xml and txt files).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:40 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-279) Add deployment-scanner for
 singleton deployments
In-Reply-To: <JIRA.12477883.1351180964000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12477883.1351180964000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12477883.1351180964000.15353.1380922960616@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-279:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Add deployment-scanner for singleton deployments
> ------------------------------------------------
>
>                 Key: WFLY-279
>                 URL: https://issues.jboss.org/browse/WFLY-279
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 8.0.0.CR1
>
>
> To simplify the use of singleton deployments in standalone mode, it would be nice to have a mechanism analogous to the hasingleton-deploy directory in AS6 and earlier.  To do this, we can enhance the existing deployment-scanner to accept an additional policy attribute.  Something like:
> <subsystem xmlns="urn:jboss:domain:deployment-scanner:1.1">
>    <deployment-scanner path="deployments" relative-to="jboss.server.base.dir" scan-interval="5000" policy="standard"/>
>    <deployment-scanner path="singleton-deployments" relative-to="jboss.server.base.dir" scan-interval="5000" policy="singleton"/>
> </subsystem>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:40 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-276) TS: How to use -Djpda with
	clustered tests
In-Reply-To: <JIRA.12453411.1322641838000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12453411.1322641838000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12453411.1322641838000.15362.1380922960803@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-276:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> TS: How to use -Djpda with clustered tests
> ------------------------------------------
>
>                 Key: WFLY-276
>                 URL: https://issues.jboss.org/browse/WFLY-276
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering, Documentation, Test Suite
>            Reporter: Radoslav Husar
>            Assignee: Ondrej Zizka
>            Priority: Minor
>             Fix For: 8.0.0.CR1
>
>
> The doc now says whats pasted below, but I am not sure if both servers are listening on 8787 because (that would fail the startup), if I have to connect to both or where do I configure that, etc.
> {code}
> Running JBoss AS instances with debugger
> Adding -Djpda (May be changed to -Ddebug in the future) will make JBoss AS run with JPDA JVM arguments for debugging.
> It will suspend and wait for the debugger to connect at port 8787.
> JBoss AS is started by Arquillian, when the first test which requires given instance is run. There's (currently) no challenge text in the console, it will look like the first test is stuck. This is being solved in http://jira.codehaus.org/browse/SUREFIRE-781.
> Depending on which test group(s) you run, multiple instances may be started. In that case, you need to attach the debugger multiple times.
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:40 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-273) Document how to configure
 firewall when using different JGroups stacks
In-Reply-To: <JIRA.12459709.1329901880000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12459709.1329901880000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12459709.1329901880000.15366.1380922960933@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-273:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Document how to configure firewall when using different JGroups stacks
> ----------------------------------------------------------------------
>
>                 Key: WFLY-273
>                 URL: https://issues.jboss.org/browse/WFLY-273
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering, Documentation
>            Reporter: Radoslav Husar
>            Assignee: Paul Ferraro
>             Fix For: 8.0.0.CR1
>
>
> Document how to configure firewall for using different clustering stacks
> https://docs.jboss.org/author/display/AS71/High+Availability+Guide
> Needed by OpenShift team (especially TCP stacks).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:41 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-270) Use logger instead of [stdout]
 for JGroups GMS logger
In-Reply-To: <JIRA.12466283.1336752816000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12466283.1336752816000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12466283.1336752816000.15373.1380922961206@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-270:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Use logger instead of [stdout] for JGroups GMS logger
> -----------------------------------------------------
>
>                 Key: WFLY-270
>                 URL: https://issues.jboss.org/browse/WFLY-270
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>            Priority: Trivial
>             Fix For: 8.0.0.CR1
>
>
> ...and possibly remove the unnecessary dash lines on the way.
> {noformat}
> [JBossINF] 12:11:12,677 INFO  [org.jboss.as.osgi] (MSC service thread 1-15) JBAS011907: Register module: Module "deployment.clusterbench-ee6.ear.clusterbench-ee6-ejb.jar:main" from Service Module Loader
> [JBossINF] 12:11:13,142 INFO  [stdout] (ChannelService lifecycle - 1) 
> [JBossINF] 12:11:13,142 INFO  [stdout] (ChannelService lifecycle - 1) -------------------------------------------------------------------
> [JBossINF] 12:11:13,142 INFO  [stdout] (ChannelService lifecycle - 1) GMS: address=perf18/web, cluster=web, physical address=10.16.90.54:55200
> [JBossINF] 12:11:13,143 INFO  [stdout] (ChannelService lifecycle - 1) -------------------------------------------------------------------
> [JBossINF] 12:11:13,209 INFO  [stdout] (ChannelService lifecycle - 1) 
> [JBossINF] 12:11:13,209 INFO  [stdout] (ChannelService lifecycle - 1) -------------------------------------------------------------------
> [JBossINF] 12:11:13,209 INFO  [stdout] (ChannelService lifecycle - 1) GMS: address=perf18/ejb, cluster=ejb, physical address=10.16.90.54:55200
> [JBossINF] 12:11:13,210 INFO  [stdout] (ChannelService lifecycle - 1) -------------------------------------------------------------------
> [JBossINF] 12:11:13,441 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-5) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be pasivated.
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:41 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-269) Updated infinispan management
	API
In-Reply-To: <JIRA.12489440.1366010473000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489440.1366010473000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489440.1366010473000.15377.1380922961294@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-269:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Updated infinispan management API
> ---------------------------------
>
>                 Key: WFLY-269
>                 URL: https://issues.jboss.org/browse/WFLY-269
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Richard Achmatowicz
>             Fix For: 8.0.0.CR1
>
>
> Expose updated management operations

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:41 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-264) Add support for
 use1PcForAutoCommitTransactions
In-Reply-To: <JIRA.12464799.1335208150000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12464799.1335208150000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12464799.1335208150000.15380.1380922961360@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-264:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Add support for use1PcForAutoCommitTransactions
> -----------------------------------------------
>
>                 Key: WFLY-264
>                 URL: https://issues.jboss.org/browse/WFLY-264
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>            Reporter: Paul Ferraro
>            Assignee: Radoslav Husar
>            Priority: Minor
>             Fix For: 8.0.0.CR1
>
>
> Since clustered web sessions/SFSBs won't ever incur inter-node concurrent access, we can tolerate a 1PC commit optimization - which will reduce the number of RPCs involved in replication/distribution.  This should result it a significant performance gains for REPL_SYNC and DIST_SYNC caches.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:41 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-261) Add way to properly parse JNDI
 urls in AS codebase
In-Reply-To: <JIRA.12489917.1366378061000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489917.1366378061000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489917.1366378061000.15392.1380922961705@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-261:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Add way to properly parse JNDI urls in AS codebase
> --------------------------------------------------
>
>                 Key: WFLY-261
>                 URL: https://issues.jboss.org/browse/WFLY-261
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Naming
>            Reporter: Bartosz Baranowski
>            Assignee: Bartosz Baranowski
>             Fix For: 8.0.0.CR1
>
>
> This is a followup of  AS7-2138. Original code, in case no URL context threw NamingException. The  AS7-2138  introduced a fallback to NamingContext in case AS7 does not provide custom hack for url( like EJB ). However the fallback did not fail with NamingException in case it did not locate Context. This essentially made it go knee deep into AS7 service lookups, which hides real cause of failure.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:41 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-262) Update the DC's
 IgnoredTransformationRegistry when changes are made to a slave's
 <ignored-resources>
In-Reply-To: <JIRA.12488205.1364406969000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12488205.1364406969000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488205.1364406969000.15389.1380922961642@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-262:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Update the DC's IgnoredTransformationRegistry when changes are made to a slave's <ignored-resources>
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-262
>                 URL: https://issues.jboss.org/browse/WFLY-262
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:41 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-259) Auto ignore domain resources
 on a slave HC which do not affect its servers
In-Reply-To: <JIRA.12488202.1364406625000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12488202.1364406625000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488202.1364406625000.15402.1380922961922@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-259:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Auto ignore domain resources on a slave HC which do not affect its servers
> --------------------------------------------------------------------------
>
>                 Key: WFLY-259
>                 URL: https://issues.jboss.org/browse/WFLY-259
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.CR1
>
>
> Currently to avoid receiving resources and ops for parts of the domain model which do not work on an older slave we use <ignored-resources> in the slave host.xml to ignore them.
> Instead we should only pull in parts of the domain model that is actually required on the slave for its servers to start. Once started we need to be able to update the slave with domain information as the config changes
> The main things which can change affecting the data required are:
> 1) A domain's server-group, where the profile (and thus extensions) and the socket-binding group can be changed.
> 2) A host's server-config, where the server-group and the socket-binding-group override might be changed.
> For 1) we can piggy-back missing data to the slave.
> For 2) the slave needs to connect back to the DC, attempt to get the DC lock and pull down the required data. If the lock cannot be obtained, the operation should fail fast.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:41 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-263) JASPI Support for Web Services
In-Reply-To: <JIRA.12457542.1327505819000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12457542.1327505819000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12457542.1327505819000.15384.1380922961479@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-263:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> JASPI Support for Web Services
> ------------------------------
>
>                 Key: WFLY-263
>                 URL: https://issues.jboss.org/browse/WFLY-263
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Security, Web Services
>            Reporter: Anil Saldhana
>            Assignee: Jim Ma
>             Fix For: 8.0.0.CR1
>
>
> Take care of the JASPI requirements for SOAP layer.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:42 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-255) Improve reporting during
	deployment hang
In-Reply-To: <JIRA.12484274.1360227116000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12484274.1360227116000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12484274.1360227116000.15413.1380922962181@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-255:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Improve reporting during deployment hang
> ----------------------------------------
>
>                 Key: WFLY-255
>                 URL: https://issues.jboss.org/browse/WFLY-255
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>         Environment: http://java.net/jira/browse/EJB_SPEC-60
> java version "1.7.0_09"
> OpenJDK Runtime Environment (IcedTea7 2.3.3) (7u9-2.3.3-0ubuntu1~12.10.1)
> OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)
> Ubuntu 12.10
>            Reporter: Carlo de Wolf
>             Fix For: 8.0.0.CR1
>
>         Attachments: deployment-hang-20130205.txt, server.log
>
>
> Management Thread waits indefinitely for, what seems to be, a finished operation.
> {noformat}
> "management-handler-thread - 2" prio=10 tid=0x00007fa1380d0000 nid=0x7683 in Object.wait() [0x00007fa136deb000]
>    java.lang.Thread.State: WAITING (on object monitor)
> 	at java.lang.Object.wait(Native Method)
> 	- waiting on <0x00000000e04ae778> (a org.jboss.as.controller.ContainerStateMonitor)
> 	at java.lang.Object.wait(Object.java:503)
> 	at org.jboss.as.controller.ContainerStateMonitor.awaitContainerStateChangeReport(ContainerStateMonitor.java:158)
> 	- locked <0x00000000e04ae778> (a org.jboss.as.controller.ContainerStateMonitor)
> 	at org.jboss.as.controller.ModelControllerImpl.awaitContainerStateChangeReport(ModelControllerImpl.java:464)
> 	at org.jboss.as.controller.OperationContextImpl.awaitModelControllerContainerMonitor(OperationContextImpl.java:148)
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:299)
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229)
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224)
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:142)
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:112)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:139)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:108)
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296)
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> 	at java.lang.Thread.run(Thread.java:722)
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:42 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-244) Undertow Integration Tracker
In-Reply-To: <JIRA.12487782.1363958280000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12487782.1363958280000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487782.1363958280000.15418.1380922962288@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-244:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Undertow Integration Tracker
> ----------------------------
>
>                 Key: WFLY-244
>                 URL: https://issues.jboss.org/browse/WFLY-244
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web (Undertow)
>            Reporter: Tomaz Cerar
>            Assignee: Tomaz Cerar
>            Priority: Critical
>             Fix For: 8.0.0.CR1
>
>
> Tracking issue for all issues related to undertow integration.
> as part of https://github.com/wildfly/wildfly/pull/4810 there tests removed that need to be re-added as part of this tracking issue

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:42 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-241) Specify and expose mod_cluster
 runtime information the should be shown within the console
In-Reply-To: <JIRA.12480703.1354885205000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12480703.1354885205000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12480703.1354885205000.15424.1380922962537@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-241:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Specify and expose mod_cluster runtime information the should be shown within the console
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-241
>                 URL: https://issues.jboss.org/browse/WFLY-241
>             Project: WildFly
>          Issue Type: Clarification
>          Components: Clustering
>            Reporter: Heiko Braun
>            Assignee: Paul Ferraro
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:42 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-229) Expose mgmt client socket
 binding config through ModelControllerClient Factory
In-Reply-To: <JIRA.12481979.1357332857000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12481979.1357332857000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12481979.1357332857000.15443.1380922962945@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-229:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Expose mgmt client socket binding config through ModelControllerClient Factory
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-229
>                 URL: https://issues.jboss.org/browse/WFLY-229
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> Parent task used a secret system property to configure this to support Open Shift's immediate need, but proper configuration is needed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:41 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-258) mod_cluster schema 1.2
In-Reply-To: <JIRA.12458353.1328480847000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12458353.1328480847000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12458353.1328480847000.15406.1380922961984@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-258:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> mod_cluster schema 1.2
> ----------------------
>
>                 Key: WFLY-258
>                 URL: https://issues.jboss.org/browse/WFLY-258
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.CR1
>
>
> Changes to the schema
> * simplified names and sync in line with scheme recommendations
> * remove redundant <mod-cluster-config .. /> for good, everything should be element of the subsystem
> * fix load factor enum: no pool metric supported
> * make load-balancers configurable via socket-outbuound-group mechanism
> * add missing load-balancer properties to <proxies/>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:41 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-260) Error
In-Reply-To: <JIRA.12467490.1338212652000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12467490.1338212652000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12467490.1338212652000.15396.1380922961810@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-260:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Error
> -----
>
>                 Key: WFLY-260
>                 URL: https://issues.jboss.org/browse/WFLY-260
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Class Loading
>            Reporter: Pablo Ochoa
>            Assignee: David Lloyd
>             Fix For: 8.0.0.CR1
>
>
> Buenos D?as,
>     Tengo problema con la version 7.1.1 de Jboss por defecto viene creado un Selector y yo intento crea uno nuevo para el manejo de mi classes me arroja el siguiente error
> Preferred repository selector not installed because one has already exists. No problem, using existing selector...
> Estado investigando de verdad no conseguido algo para poder solventar este problema el la ultima version de Jboss 6 no ocurre este mismo problema agradezco toda la colaboraci?n que me puedan brindar 
>    Te anexo el codigo que utilizo
> import java.util.*;
> import javax.naming.*;
> import org.apache.log4j.Hierarchy;
> import org.apache.log4j.Level;
> import org.apache.log4j.spi.*;
> public class Log4jContextJNDISelector
>    implements RepositorySelector
> {
>    public Log4jContextJNDISelector(){
>        defaultHierarchy = new Hierarchy(new RootLogger(Level.DEBUG));
>    }
>    public LoggerRepository getLoggerRepository()
>    {
>        String loggingContextName = null;
>        try
>        {
>            Context ctx = new InitialContext();
>            loggingContextName = (String)ctx.lookup("java:comp/env/log4j/logging-context");
>        }
>        catch(NamingException ne) { }
>        if(loggingContextName == null)
>            return defaultHierarchy;
>        Hierarchy hierarchy = (Hierarchy)hierMap.get(loggingContextName);
>        if(hierarchy == null)
>        {
>            hierarchy = new Hierarchy(new RootLogger(Level.DEBUG));
>            hierMap.put(loggingContextName, hierarchy);
>        }
>        return hierarchy;
>    }
> Archivo web.xml esta configuraci?n
>        <context-param>
>                <param-name>log4j-selector</param-name>
>                <param-value>ve.com.prueba.gdis.cia.config.logging.Log4jContextJNDISelector</param-value>
>                <description> Selector de repositorios basado en JNDI desde donde se
>                        configurar el repositorio de logs para esta aplicaci?n
>                </description>
>        </context-param>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Fri Oct  4 17:42:43 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-224) Add allowed values for
 attribute "cache-type" in "/subsystem=security/security-domain=*"
In-Reply-To: <JIRA.12486710.1362660680000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12486710.1362660680000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12486710.1362660680000.15453.1380922963164@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-224:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Add allowed values for attribute "cache-type" in "/subsystem=security/security-domain=*"
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-224
>                 URL: https://issues.jboss.org/browse/WFLY-224
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Domain Management, Security
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Harald Pehl
>            Priority: Minor
>             Fix For: 8.0.0.CR1
>
>
> The attribute "cache-type" in "/subsystem=security/security-domain=*" can either be "default" or "infinispan". Please add the allowed value to the resource description. 
> In order to generate the UI based on the management model, it is essential that information like this is present.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:43 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-211) Expose client socket binding
 config through CLI connect configs
In-Reply-To: <JIRA.12481980.1357332935000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12481980.1357332935000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12481980.1357332935000.15475.1380922963693@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-211:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Expose client socket binding config through CLI connect configs
> ---------------------------------------------------------------
>
>                 Key: WFLY-211
>                 URL: https://issues.jboss.org/browse/WFLY-211
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: CLI
>            Reporter: Brian Stansberry
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.0.CR1
>
>
> Once AS7-6277 is done, continue exposing the client bind socket config to CLI users.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:43 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-215) Clustering tests leave a
 hanging instance if they are run in opposite order
In-Reply-To: <JIRA.12487439.1363626505000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12487439.1363626505000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487439.1363626505000.15466.1380922963464@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-215:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Clustering tests leave a hanging instance if they are run in opposite order
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-215
>                 URL: https://issues.jboss.org/browse/WFLY-215
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Clustering, Test Suite
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.CR1
>
>
> Interestingly, if the tests are run in the opposite order i.e. alphabetically, one server instance remains running and doesn't shut down.
> I have used a workaround for now
> {code}
> +                                    <!-- Force the order of tests -->
> +                                    <runOrder>reversealphabetical</runOrder>
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:44 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-174) Missing JSP or EL privileged
	action(s)
In-Reply-To: <JIRA.12486204.1362418431000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12486204.1362418431000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12486204.1362418431000.15489.1380922964014@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-174:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Missing JSP or EL privileged action(s)
> --------------------------------------
>
>                 Key: WFLY-174
>                 URL: https://issues.jboss.org/browse/WFLY-174
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (JBoss Web)
>            Reporter: David Lloyd
>            Assignee: Remy Maucherat
>             Fix For: 8.0.0.CR1
>
>
> When running with a security manager, we're seeing an access control problem with this stack trace:
> {noformat}
> 18:21:08,471 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/web-secure].[jsp]] (http-/127.0.0.1:8080-1) JBWEB000236: Servlet.service() for servlet jsp threw exception: java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "getClassLoader")
>     at java.security.AccessControlContext.checkPermission(AccessControlContext.java:366) [rt.jar:1.7.0_15]
>     at java.security.AccessController.checkPermission(AccessController.java:560) [rt.jar:1.7.0_15]
>     at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) [rt.jar:1.7.0_15]
>     at java.lang.Thread.getContextClassLoader(Thread.java:1451) [rt.jar:1.7.0_15]
>     at javax.el.FactoryFinder.find(FactoryFinder.java:130) [jboss-el-api_2.2_spec-1.0.2.Final.jar:1.0.2.Final]
>     at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:185) [jboss-el-api_2.2_spec-1.0.2.Final.jar:1.0.2.Final]
>     at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:156) [jboss-el-api_2.2_spec-1.0.2.Final.jar:1.0.2.Final]
>     at org.apache.jasper.runtime.JspApplicationContextImpl.<init>(JspApplicationContextImpl.java:48) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
>     at org.apache.jasper.runtime.JspApplicationContextImpl.getInstance(JspApplicationContextImpl.java:77) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
>     at org.apache.jasper.runtime.JspFactoryImpl.getJspApplicationContext(JspFactoryImpl.java:197) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
>     at org.apache.jsp.login_jsp._jspInit(login_jsp.java:22)
>     at org.apache.jasper.runtime.HttpJspBase.init(HttpJspBase.java:51) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
>     at org.apache.jasper.servlet.JspServletWrapper.getServlet(JspServletWrapper.java:151) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
>     at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:320) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
>     at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:309) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
>     at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:242) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
>     at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.2.Final.jar:1.0.2.Final]
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_15]
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_15]
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_15]
>     at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_15]
>     at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:263) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
>     at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:261) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
>     at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_15]
>     at javax.security.auth.Subject.doAsPrivileged(Subject.java:536) [rt.jar:1.7.0_15]
>     at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:295) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
>     at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:155) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
>     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:288) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
>     at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:59) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
>     at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:197) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
>     at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_15]
>     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
>     at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:832) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
>     at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:620) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
>     at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:553) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
>     at org.apache.catalina.core.ApplicationDispatcher.access$000(ApplicationDispatcher.java:69) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
>     at org.apache.catalina.core.ApplicationDispatcher$PrivilegedForward.run(ApplicationDispatcher.java:84) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
>     at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_15]
>     at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:474) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
>     at org.apache.catalina.authenticator.FormAuthenticator.forwardToLoginPage(FormAuthenticator.java:372) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
>     at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:265) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
>     at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:447) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
>     at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
>     at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
>     at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
>     at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
>     at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:336) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
>     at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
>     at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
>     at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:920) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
>     at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_15]
> {noformat}
> It looks like javax.el should probably be getting TCCL from a privileged block, or else org.apache.jasper.runtime.JspApplicationContextImpl.<init> should be executing in a privileged context.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:43 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-214) Consider logging "Number of
 cluster members" on view change like is done at server startup
In-Reply-To: <JIRA.12472811.1345564064000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12472811.1345564064000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12472811.1345564064000.15471.1380922963604@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-214:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Consider logging "Number of cluster members" on view change like is done at server startup
> ------------------------------------------------------------------------------------------
>
>                 Key: WFLY-214
>                 URL: https://issues.jboss.org/browse/WFLY-214
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Clustering
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>            Priority: Optional
>             Fix For: 8.0.0.CR1
>
>
> See https://community.jboss.org/message/754829#754829
> Could we just do the same as for the startup?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:44 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-166) Clearing server environment in
 bootstrap breaks embedded server restart
In-Reply-To: <JIRA.12482977.1358804351000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12482977.1358804351000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12482977.1358804351000.15499.1380922964232@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-166:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Clearing server environment in bootstrap breaks embedded server restart
> -----------------------------------------------------------------------
>
>                 Key: WFLY-166
>                 URL: https://issues.jboss.org/browse/WFLY-166
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>            Reporter: Thomas Diesler
>            Assignee: Bartosz Baranowski
>             Fix For: 8.0.0.CR1
>
>
> Recursively deleting tmp directories as part of Bootstrap.bootstrap() prevents multiple embedded server restarts. I believe it has to do with how directories are crated as part of static VFS initialisation.
> TempFileProvider has this static code
> {code}
>     static {
>         String configTmpDir = System.getProperty(JBOSS_TMP_DIR_PROPERTY);
>         if (configTmpDir == null)
>             configTmpDir = System.getProperty(JVM_TMP_DIR_PROPERTY);
>         try {
>             TMP_ROOT = new File(configTmpDir, "vfs");
>             TMP_ROOT.mkdirs();
>         }
>         catch (Exception e) {
>             throw new RuntimeException("Can't set up temp file provider", e);
>         }
>     }
> {code}
> which creates the vfs directory only once that [this patch|https://github.com/jbossas/jboss-as/commit/ad3e878098] removes. As a consequence on server restart with jboss-vfs on the boot classpath hte vfs directory is missing an no tmp file can be created.
> Generally, the server should only remove state on shutdown that it creates itself on startup/run. Alternatively, jboss-vfs should support a start/stop lifecycle in the TempFileProvider and possibly in other entities that also use static initialisers.
>  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:44 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-160) Reconfigure of JavaMail
	service on-the-fly
In-Reply-To: <JIRA.12475211.1348485863000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12475211.1348485863000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12475211.1348485863000.15504.1380922964353@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-160:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Reconfigure of JavaMail service on-the-fly
> ------------------------------------------
>
>                 Key: WFLY-160
>                 URL: https://issues.jboss.org/browse/WFLY-160
>             Project: WildFly
>          Issue Type: Bug
>          Components: Mail
>            Reporter: Vadim Gusev
>            Assignee: Tomaz Cerar
>             Fix For: 8.0.0.CR1
>
>
> Since JavaMail implemented on Jboss AS7 we can't reconfigure JavaMail service on-the-fly. We always should reload the server to apply new configuration.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:42 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-249) Look into whether READ_ONLY
 but not RUNTIME_ONLY domain server ops should be visible to users
In-Reply-To: <JIRA.12472187.1344607033000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12472187.1344607033000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12472187.1344607033000.15416.1380922962254@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-249:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Look into whether READ_ONLY but not RUNTIME_ONLY domain server ops should be visible to users
> ---------------------------------------------------------------------------------------------
>
>                 Key: WFLY-249
>                 URL: https://issues.jboss.org/browse/WFLY-249
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> Ops registered on a domain server without the RUNTIME_ONLY flag are hidden from users (e.g. in read-operation-names results etc) in order to not delude users into thinking they can do something like :write-attribute directly on a server (instead of modifying host or domain config elements.)
> But shouldn't a READ_ONLY flag be sufficient as well? An op that only reads config should be valid. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:42 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-231)
 HostControllerConnectionService connection timeout is not configurable
In-Reply-To: <JIRA.12457961.1328019404000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12457961.1328019404000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12457961.1328019404000.15429.1380922962674@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-231:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> HostControllerConnectionService connection timeout is not configurable
> ----------------------------------------------------------------------
>
>                 Key: WFLY-231
>                 URL: https://issues.jboss.org/browse/WFLY-231
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Dominik Pospisil
>            Assignee: Bartosz Baranowski
>             Fix For: 8.0.0.CR1
>
>
> I am seeing intermittent failures when starting AS7 in domain mode. It seems that this is due to HostControllerConnectionService has hardcoded 15s timeout when trying to connect to DC. I think that this value should be configurable.
> HostControllerConnectionService.java:
> ...
> ProtocolChannelClient.Configuration configuration = new ProtocolChannelClient.Configuration();
> configuration.setEndpoint(endpointInjector.getValue());
> configuration.setConnectionTimeout(15000);
> configuration.setUri(new URI("remote://" + hcAddressInjector.getValue().getHostName() + ":" + hcAddressInjector.getValue().getPort()));
> client = ProtocolChannelClient.create(configuration);
> ...
> Exception I am getting:
> [Server:server-two] 13:52:54,766 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC00001: Failed to start service jboss.host.controller.channel: org.jboss.msc.service.StartException in service jboss.host.controller.channel: java.net.ConnectException: JBAS012144: Could not connect to remote://localhost.localdomain:9999. The connection timed out
> [Server:server-two] 	at org.jboss.as.server.mgmt.domain.HostControllerConnectionService.start(HostControllerConnectionService.java:103) [jboss-as-server-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
> [Server:server-two] 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1824) [jboss-msc-1.0.1.GA.jar:1.0.1.GA]
> [Server:server-two] 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1759) [jboss-msc-1.0.1.GA.jar:1.0.1.GA]
> [Server:server-two] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [:1.6.0_22]
> [Server:server-two] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [:1.6.0_22]
> [Server:server-two] 	at java.lang.Thread.run(Thread.java:679) [:1.6.0_22]
> [Server:server-two] Caused by: java.net.ConnectException: JBAS012144: Could not connect to remote://localhost.localdomain:9999. The connection timed out
> [Server:server-two] 	at org.jboss.as.protocol.ProtocolChannelClient.connectSync(ProtocolChannelClient.java:166) [jboss-as-protocol-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:43 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-217) Strict location check of
 persistence.xml deployments
In-Reply-To: <JIRA.12467130.1337765236000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12467130.1337765236000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12467130.1337765236000.15458.1380922963315@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-217:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Strict location check of persistence.xml deployments
> ----------------------------------------------------
>
>                 Key: WFLY-217
>                 URL: https://issues.jboss.org/browse/WFLY-217
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: JPA / Hibernate
>            Reporter: Bartosz Baranowski
>            Assignee: Scott Marlow
>            Priority: Minor
>             Fix For: 8.0.0.CR1
>
>
> As of: https://github.com/jbossas/jboss-as/commit/38815193011fba624170a7d938118ee630b6ccb2 it is possible to deploy persistence.xml from invalid location:
> As per JPA spec(https://docs.jboss.org/author/display/AS71/JPA+Reference+Guide), valid locations are:
>  - an EJB-JAR file
>  - the WEB-INF/classes directory of a WAR file
>  - a jar file in the WEB-INF/lib directory of a WAR file
>  - a jar file in the EAR library directory
>  - an application client jar file

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:43 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-207) Add start/stop operations to
 hornetq-server resource
In-Reply-To: <JIRA.12479856.1353936459000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479856.1353936459000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479856.1353936459000.15480.1380922963808@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-207:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Add start/stop operations to hornetq-server resource
> ----------------------------------------------------
>
>                 Key: WFLY-207
>                 URL: https://issues.jboss.org/browse/WFLY-207
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.CR1
>
>
> Currently it is not possible to start/stop a hornetq-server resource without removing or adding it.
> For HornetQ replicated nodes, it'd be useful to be able to start/stop the node (runtime operations) without changing its configuration. That'd be necessary to restart replicated backup servers that have fallen back

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:43 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-228) TS: Migrate from Surefire to
 Failsafe maven plugin.
In-Reply-To: <JIRA.12460908.1331103779000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12460908.1331103779000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12460908.1331103779000.15451.1380922963128@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-228:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> TS: Migrate from Surefire to Failsafe maven plugin.
> ---------------------------------------------------
>
>                 Key: WFLY-228
>                 URL: https://issues.jboss.org/browse/WFLY-228
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Test Suite
>            Reporter: Ondrej Zizka
>            Assignee: Jakub Senko
>             Fix For: 8.0.0.CR1
>
>         Attachments: AS7-failsafe-surefire.html.zip
>
>
> Surefire aims at unit testing.
> Failsafe, unlike Surefire, binds to two build phases - integration-tests and verify.
> That not only moves test execution to the correct phase, but also brings possibility to test several issues present in the testsuite - like skipping successive Surefire executions in a single module if former fails (not affected by -fae).
>  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:43 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-209) Move ClientConfigurationImpl
 factory methods into ModelControllerClientConfiguration
In-Reply-To: <JIRA.12480650.1354821983000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12480650.1354821983000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12480650.1354821983000.15477.1380922963725@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-209:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Move ClientConfigurationImpl factory methods into ModelControllerClientConfiguration
> ------------------------------------------------------------------------------------
>
>                 Key: WFLY-209
>                 URL: https://issues.jboss.org/browse/WFLY-209
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Priority: Minor
>             Fix For: 8.0.0.CR1
>
>
> ClientConfigurationImpl includes a bunch of static factory methods that would fit better in a Factory class in the ModelControllerClientConfiguration interface.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:43 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-205) AttributeDefinition
 validateOperation should convert all expression strings to
 ModelType.EXPRESSION
In-Reply-To: <JIRA.12481843.1357134029000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12481843.1357134029000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12481843.1357134029000.15483.1380922963874@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-205:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> AttributeDefinition validateOperation should convert all expression strings to ModelType.EXPRESSION
> ---------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-205
>                 URL: https://issues.jboss.org/browse/WFLY-205
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> AttributeDefinition.validateOperation currently only converts a string to an expression if the attribute supports expressions. It should convert any time it sees the syntax. This way if a STRING attribute that doesn't support expressions finds one, it will reject it instead of accepting it as a raw string.
> Scheduling for 7.3 out of concern this may break things in 7.2 without time to notice/adapt.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:42 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-230) Add @ValidIdRange annotation
 to message loggers and message bundles
In-Reply-To: <JIRA.12481203.1355503269000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12481203.1355503269000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12481203.1355503269000.15440.1380922962897@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-230:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Add @ValidIdRange annotation to message loggers and message bundles
> -------------------------------------------------------------------
>
>                 Key: WFLY-230
>                 URL: https://issues.jboss.org/browse/WFLY-230
>             Project: WildFly
>          Issue Type: Enhancement
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 8.0.0.CR1
>
>
> A new release of the logging tooling will include a {{@ValidIdRange}} annotation. This will help document which id ranges allowed as well as provide compile time validation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:46 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-149) The console-handler in the
 logging schema still contains a filter element
In-Reply-To: <JIRA.12487191.1363215623000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12487191.1363215623000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487191.1363215623000.15514.1380922966657@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-149:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> The console-handler in the logging schema still contains a filter element
> -------------------------------------------------------------------------
>
>                 Key: WFLY-149
>                 URL: https://issues.jboss.org/browse/WFLY-149
>             Project: WildFly
>          Issue Type: Bug
>          Components: Localization
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:44 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-168) InjectionTarget.postConstruct
 is not called for EJB's
In-Reply-To: <JIRA.12459693.1329865997000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12459693.1329865997000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12459693.1329865997000.15496.1380922964171@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-168:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> InjectionTarget.postConstruct is not called for EJB's
> -----------------------------------------------------
>
>                 Key: WFLY-168
>                 URL: https://issues.jboss.org/browse/WFLY-168
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:46 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-156) Unable to start jboss AS on
 windows if installed on path containig non-ascii characters
In-Reply-To: <JIRA.12481936.1357295043000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12481936.1357295043000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12481936.1357295043000.15510.1380922966475@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-156:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Unable to start  jboss AS on windows if installed on path containig non-ascii characters
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-156
>                 URL: https://issues.jboss.org/browse/WFLY-156
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>         Environment: windows 2008 x64
>            Reporter: Ales Kolenc
>            Assignee: Tomaz Cerar
>            Priority: Critical
>             Fix For: 8.0.0.CR1
>
>
> 1.) Install jboss into a folder containing non-ascii characters. (i.e. "C:\Test?").
> 2.) run standalone.bat
> C:\Test?\jboss-as-7.1.1.Final\bin>set JAVA_HOME=C:\Program Files\Java\jre7
> C:\Test?\jboss-as-7.1.1.Final\bin>standalone.bat
> Calling "C:\Test?\jboss-as-7.1.1.Final\bin\standalone.conf.bat"
> ===============================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: C:\Test?\jboss-as-7.1.1.Final
>   JAVA: C:\Program Files\Java\jre7\bin\java
>   JAVA_OPTS: -XX:+TieredCompilation -Dprogram.name=standalone.bat -Xms64M -Xmx512M -XX:MaxPermSize=256M -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djb
> oss.server.default.config=standalone.xml
> ===============================================================================
> Error: Unable to access jarfile C:\Test?\jboss-as-7.1.1.Final\jboss-modules.jar
> Press any key to continue . . .
> C:\Test?\jboss-as-7.1.1.Final\bin>
> 3.) pleas note that: "Test?" used in path -> '?' does not bellong to system locale code page. E.g.: char '?' is in CP 932, system locale code page used 437/1252,..
> 4.) i would also like to add that jboss does not start if it installed in "normal" folder, but JBOSS_CONFIG_DIR && JBOSS_LOG_DIR are set to folder with non-ascii characters:
> c:\test\jboss-as-7.1.1.Final\bin>set JBOSS_LOG_DIR=c:\Test?
> c:\test\jboss-as-7.1.1.Final\bin>set JBOSS_CONFIG_DIR=c:\Test?\configuration
> c:\test\jboss-as-7.1.1.Final\bin>dir %JBOSS_CONFIG_DIR%
>  Volume in drive C has no label.
>  Volume Serial Number is 2C2F-FA6F
>  Directory of c:\Test?\configuration
> 01/04/2013  02:34 AM    <DIR>          .
> 01/04/2013  02:34 AM    <DIR>          ..
> 01/04/2013  01:42 AM               634 application-roles.properties
> 01/04/2013  01:42 AM               812 application-users.properties
> 01/04/2013  01:42 AM             2,042 logging.properties
> 01/04/2013  01:42 AM               836 mgmt-users.properties
> 01/04/2013  01:42 AM            27,024 standalone-full-ha.xml
> 01/04/2013  01:42 AM            20,794 standalone-full.xml
> 01/04/2013  01:42 AM            20,358 standalone-ha.xml
> 01/04/2013  01:42 AM            15,372 standalone.xml
> 01/04/2013  02:34 AM    <DIR>          standalone_xml_history
>                8 File(s)         87,872 bytes
>                3 Dir(s)  20,185,866,240 bytes free
> c:\test\jboss-as-7.1.1.Final\bin>standalone.bat -Djboss.server.config.dir=%JBOSS_CONFIG_DIR%
> Calling "c:\test\jboss-as-7.1.1.Final\bin\standalone.conf.bat"
> ===============================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: c:\test\jboss-as-7.1.1.Final
>   JAVA: C:\Program Files\Java\jre7\bin\java
>   JAVA_OPTS: -XX:+TieredCompilation -Dprogram.name=standalone.bat -Xms64M -Xmx512M -XX:MaxPermSize=256M -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djb
> oss.server.default.config=standalone.xml
> ===============================================================================
> Unable to read the logging configuration from 'file:c:\Test?\configuration/logging.properties' (java.io.FileNotFoundException: c:\Test?\configuration\logging.properties (The filename, directory name, or volume label syntax is incorrect))
> java.lang.IllegalStateException: JBAS018701: Configuration directory does not exist: c:\Test?\configuration
>         at org.jboss.as.server.ServerEnvironment.<init>(ServerEnvironment.java:371)
>         at org.jboss.as.server.Main.determineEnvironment(Main.java:242)
>         at org.jboss.as.server.Main.main(Main.java:83)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>         at java.lang.reflect.Method.invoke(Unknown Source)
>         at org.jboss.modules.Module.run(Module.java:260)
>         at org.jboss.modules.Main.main(Main.java:291)
> Press any key to continue . . .
> c:\test\jboss-as-7.1.1.Final\bin>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Fri Oct  4 17:42:43 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-216) Include Infinispan CDI as a
	JBoss module
In-Reply-To: <JIRA.12486042.1362141249000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12486042.1362141249000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12486042.1362141249000.15464.1380922963431@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-216:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Include Infinispan CDI as a JBoss module
> ----------------------------------------
>
>                 Key: WFLY-216
>                 URL: https://issues.jboss.org/browse/WFLY-216
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Clustering
>            Reporter: Avelino Martins
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.CR1
>
>
> CDI has become an invaluable technology on any JavaEE project. I find hard to justify having to include infinispan-cdi as a compile dependency on every project that uses ISPN.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:47 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-142) inconsistent usage of
 min/max-occurs in model description
In-Reply-To: <JIRA.12470576.1342507607000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12470576.1342507607000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12470576.1342507607000.15531.1380922967452@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-142:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> inconsistent usage of min/max-occurs in model description
> ---------------------------------------------------------
>
>                 Key: WFLY-142
>                 URL: https://issues.jboss.org/browse/WFLY-142
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Emanuel Muckenhuber
>             Fix For: 8.0.0.CR1
>
>         Attachments: patch.txt
>
>
> The usages of min/max-occurs in the model description are not consistent - e.g. missing in ResourceDescription, mostly wrong when used in the descriptionProvider or outdated examples in the documentation.
> I'll attach a simple patch which should actually fix that issue in line with the documentation [1] (incl. recursive usage) and the usage of the CLI (ls -l). However there might be more to it.
> [1] https://docs.jboss.org/author/display/AS71/Description+of+the+Management+Model

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:46 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-146) "HHH000231: Schema export
 unsuccessful: org.h2.jdbc.JdbcSQLException: Database is already closed" on
 clean shutdown
In-Reply-To: <JIRA.12487494.1363690599000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12487494.1363690599000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487494.1363690599000.15517.1380922966806@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-146:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> "HHH000231: Schema export unsuccessful: org.h2.jdbc.JdbcSQLException: Database is already closed" on clean shutdown
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-146
>                 URL: https://issues.jboss.org/browse/WFLY-146
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Radoslav Husar
>             Fix For: 8.0.0.CR1
>
>         Attachments: server.log
>
>
> Just saw this when I was closely looking through clustering testsuite logs.
> Affected version: master 8a6aac3c8eb6bc94b7eddfa4d090c9ac05c7e37b
> Seems like the connection pool closes earlier than the entiti manager shutdown?
> {code}15:09:34,473 ERROR [org.hibernate.tool.hbm2ddl.SchemaExport] (ServerService Thread Pool -- 54) HHH000231: Schema export unsuccessful: org.h2.jdbc.JdbcSQLException: Database is already closed (to disable automatic closing at VM shutdown, add ";DB_CLOSE_ON_EXIT=FALSE" to the db URL) [90121-168]
> 	at org.h2.message.DbException.getJdbcSQLException(DbException.java:329)
> 	at org.h2.message.DbException.get(DbException.java:169)
> 	at org.h2.message.DbException.get(DbException.java:146)
> 	at org.h2.message.DbException.get(DbException.java:135)
> 	at org.h2.jdbc.JdbcConnection.checkClosed(JdbcConnection.java:1384)
> 	at org.h2.jdbc.JdbcConnection.checkClosed(JdbcConnection.java:1359)
> 	at org.h2.jdbc.JdbcConnection.setAutoCommit(JdbcConnection.java:403)
> 	at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.checkTransaction(BaseWrapperManagedConnection.java:880)
> 	at org.jboss.jca.adapters.jdbc.WrappedConnection.checkTransaction(WrappedConnection.java:1589)
> 	at org.jboss.jca.adapters.jdbc.WrappedConnection.createStatement(WrappedConnection.java:298)
> 	at org.hibernate.tool.hbm2ddl.DatabaseExporter.<init>(DatabaseExporter.java:54)
> 	at org.hibernate.tool.hbm2ddl.SchemaExport.execute(SchemaExport.java:367)
> 	at org.hibernate.tool.hbm2ddl.SchemaExport.drop(SchemaExport.java:318)
> 	at org.hibernate.tool.hbm2ddl.SchemaExport.drop(SchemaExport.java:314)
> 	at org.hibernate.internal.SessionFactoryImpl.close(SessionFactoryImpl.java:1386)
> 	at org.hibernate.ejb.EntityManagerFactoryImpl.close(EntityManagerFactoryImpl.java:194)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$2.run(PersistenceUnitServiceImpl.java:124)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122){code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:49 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-80) Product Version should not
 prepend product name with JBoss
In-Reply-To: <JIRA.12487209.1363252404000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12487209.1363252404000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487209.1363252404000.15579.1380922969647@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-80:
-----------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Product Version should not prepend product name with JBoss
> ----------------------------------------------------------
>
>                 Key: WFLY-80
>                 URL: https://issues.jboss.org/browse/WFLY-80
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>            Reporter: NadirX
>            Assignee: Jason Greene
>            Priority: Minor
>             Fix For: 8.0.0.CR1
>
>
> version/src/main/java/org/jboss/as/version/ProductConfig.java prepends the Product Name with 'JBoss' which is inappropriate for community projects. The result is that at startup I get the following
> "INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss Infinispan Server 5.3.0-SNAPSHOT (AS 7.2.0.Final) started in 3059ms"
> where instead I should see 
> "INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874: Infinispan Server 5.3.0-SNAPSHOT (AS 7.2.0.Final) started in 3059ms"

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:48 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-125) Attribute
 passivate-events-on-replicate of cluster-passivation-store can't be change
 via drm or cli
In-Reply-To: <JIRA.12462154.1332337214000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12462154.1332337214000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12462154.1332337214000.15547.1380922968177@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-125:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Attribute passivate-events-on-replicate of cluster-passivation-store can't be change via drm or cli
> ---------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-125
>                 URL: https://issues.jboss.org/browse/WFLY-125
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>            Reporter: Ond?ej Chaloupka
>            Assignee: Richard Achmatowicz
>              Labels: eap6_need_triage
>             Fix For: 8.0.0.CR1
>
>
> Setting attribute passivate-events-on-replicate via drm or cli does not take affect until operation :reload is used.
> In case that the attribute ( <cluster-passivation-store name="infinispan" cache-container="ejb" passivate-events-on-replicate="false" />) is set directly in standalone*.xml configuration file the supposed functionality is working.
> The test for this could be checked on:
> https://github.com/ochaloup/jboss-as/blob/JBQA-5855-test-migration-passivation-in-cluster/testsuite/integration/clust/src/test/java/org/jboss/as/test/clustering/cluster/ejb3/stateful/passivation/ClusterPassivationTestCase.java

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Fri Oct  4 17:42:47 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-145) User insn't properly informed
 that APR is used
In-Reply-To: <JIRA.12456638.1326707373000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12456638.1326707373000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12456638.1326707373000.15524.1380922967130@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-145:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> User insn't properly informed that APR is used
> ----------------------------------------------
>
>                 Key: WFLY-145
>                 URL: https://issues.jboss.org/browse/WFLY-145
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (JBoss Web)
>            Reporter: Rostislav Svoboda
>            Assignee: Remy Maucherat
>             Fix For: 8.0.0.CR1
>
>
> AS7 log doesn't show sufficient information that APR is used or not. Currently the only clue is that org.apache.coyote.http11.Http11AprProtocol is used instead of org.apache.coyote.http11.Http11Protocol. But it's implementation details and many users can miss that.
> Add log message to inform users if APR is used or not!
> For example APR affect https connector definition which must use openssl based keys and not keystore. And if users do not know APR is used they can be easily confused and blame AS7 as broken.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:48 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-118) JGroups diag failure "failed
 sending diag rsp to /10.16.88.172:47231: java.io.IOException: Message too
 long"
In-Reply-To: <JIRA.12461442.1331572935000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12461442.1331572935000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12461442.1331572935000.15550.1380922968300@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-118:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> JGroups diag failure "failed sending diag rsp to /10.16.88.172:47231: java.io.IOException: Message too long"
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-118
>                 URL: https://issues.jboss.org/browse/WFLY-118
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>         Environment: Linux
>            Reporter: Radoslav Husar
>            Assignee: Paul Ferraro
>            Priority: Minor
>              Labels: eap6_need_triage
>             Fix For: 8.0.0.CR1
>
>
> Implications of the issue are not currently known to me.
> {noformat}
> [JBossINF] 23:18:35,935 SEVERE [org.jgroups.protocols.UDP] (DiagnosticsHandler,null) failed sending diag rsp to /10.16.88.172:47231: java.io.IOException: Message too long
> [JBossINF] 	at java.net.PlainDatagramSocketImpl.send(Native Method) [rt.jar:1.6.0_30]
> [JBossINF] 	at java.net.DatagramSocket.send(DatagramSocket.java:625) [rt.jar:1.6.0_30]
> [JBossINF] 	at org.jgroups.stack.DiagnosticsHandler.sendResponse(DiagnosticsHandler.java:146) [jgroups-3.0.6.Final-redhat-1.jar:3.0.6.Final-redhat-1]
> [JBossINF] 	at org.jgroups.stack.DiagnosticsHandler.handleDiagnosticProbe(DiagnosticsHandler.java:135) [jgroups-3.0.6.Final-redhat-1.jar:3.0.6.Final-redhat-1]
> [JBossINF] 	at org.jgroups.stack.DiagnosticsHandler.run(DiagnosticsHandler.java:95) [jgroups-3.0.6.Final-redhat-1.jar:3.0.6.Final-redhat-1]
> [JBossINF] 	at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]
> {noformat}
> preceed by
> {noformat}
> [JBossINF] 23:18:30,699 ERROR [org.infinispan.transaction.tm.DummyTransaction] (EJB default - 5) ISPN000111: afterCompletion() failed for SynchronizationAdapter{localTransaction=LocalTransaction{remoteLockedNodes=[perf19/ejb, perf21/ejb], isMarkedForRollback=false, transaction=DummyTransaction{xid=DummyXid{id=9740}, status=3}, lockedKeys=null, backupKeyLocks=null, viewId=13} org.infinispan.transaction.synchronization.SyncLocalTransaction at 2607} org.infinispan.transaction.synchronization.SynchronizationAdapter at 2626: org.infinispan.CacheException: org.jgroups.TimeoutException: timeout sending message to perf21/ejb
> [JBossINF] 	at org.infinispan.util.Util.rewrapAsCacheException(Util.java:524)
> [JBossINF] 	at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:168)
> [JBossINF] 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:478)
> [JBossINF] 	at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:148)
> [JBossINF] 	at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:169)
> [JBossINF] 	at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:219)
> [JBossINF] 	at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:206)
> [JBossINF] 	at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:201)
> [JBossINF] 	at org.infinispan.transaction.AbstractEnlistmentAdapter.removeTransactionInfoRemotely(AbstractEnlistmentAdapter.java:81)
> [JBossINF] 	at org.infinispan.transaction.AbstractEnlistmentAdapter.releaseLocksForCompletedTransaction(AbstractEnlistmentAdapter.java:73)
> [JBossINF] 	at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:94)
> [JBossINF] 	at org.infinispan.transaction.tm.DummyTransaction.notifyAfterCompletion(DummyTransaction.java:272)
> [JBossINF] 	at org.infinispan.transaction.tm.DummyTransaction.runCommitTx(DummyTransaction.java:321)
> [JBossINF] 	at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:90)
> [JBossINF] 	at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:100)
> [JBossINF] 	at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:123)
> [JBossINF] 	at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:105)
> [JBossINF] 	at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:86)
> [JBossINF] 	at org.infinispan.CacheImpl.endBatch(CacheImpl.java:580)
> [JBossINF] 	at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:75)
> [JBossINF] 	at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:75)
> [JBossINF] 	at org.jboss.as.clustering.infinispan.invoker.BatchOperation.invoke(BatchOperation.java:26)
> [JBossINF] 	at org.jboss.as.clustering.infinispan.invoker.RetryingCacheInvoker.invoke(RetryingCacheInvoker.java:61)
> [JBossINF] 	at org.jboss.as.clustering.ejb3.cache.backing.infinispan.InfinispanBackingCacheEntryStore.invoke(InfinispanBackingCacheEntryStore.java:225)
> [JBossINF] 	at org.jboss.as.clustering.ejb3.cache.backing.infinispan.InfinispanBackingCacheEntryStore.update(InfinispanBackingCacheEntryStore.java:200)
> [JBossINF] 	at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberContainer.update(SerializationGroupMemberContainer.java:269) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> [JBossINF] 	at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberContainer.update(SerializationGroupMemberContainer.java:50) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> [JBossINF] 	at org.jboss.as.ejb3.cache.impl.backing.PassivatingBackingCacheImpl.release(PassivatingBackingCacheImpl.java:223) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> [JBossINF] 	at org.jboss.as.ejb3.cache.spi.impl.AbstractCache.release(AbstractCache.java:76) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> [JBossINF] 	at org.jboss.as.ejb3.cache.spi.impl.AbstractCache.release(AbstractCache.java:39) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> [JBossINF] 	at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.releaseInstance(StatefulSessionSynchronizationInterceptor.java:197) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> [JBossINF] 	at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.access$200(StatefulSessionSynchronizationInterceptor.java:50) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> [JBossINF] 	at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor$StatefulSessionSynchronization.afterCompletion(StatefulSessionSynchronizationInterceptor.java:271) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> [JBossINF] 	at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(SynchronizationImple.java:96)
> [JBossINF] 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:402)
> [JBossINF] 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:103)
> [JBossINF] 	at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:164)
> [JBossINF] 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165)
> [JBossINF] 	at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:117)
> [JBossINF] 	at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
> [JBossINF] 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:92) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> [JBossINF] 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:232) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> [JBossINF] 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:304) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> [JBossINF] 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:190) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> [JBossINF] 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
> [JBossINF] 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropogatingInterceptor.processInvocation(EJBRemoteTransactionPropogatingInterceptor.java:80) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> [JBossINF] 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
> [JBossINF] 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> [JBossINF] 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
> [JBossINF] 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> [JBossINF] 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
> [JBossINF] 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) [jboss-as-ee-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> [JBossINF] 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
> [JBossINF] 	at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45) [jboss-as-ee-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> [JBossINF] 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
> [JBossINF] 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
> [JBossINF] 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165) [jboss-as-ee-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> [JBossINF] 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:300) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> [JBossINF] 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$200(MethodInvocationMessageHandler.java:64) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> [JBossINF] 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:194) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> [JBossINF] 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [rt.jar:1.6.0_30]
> [JBossINF] 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [rt.jar:1.6.0_30]
> [JBossINF] 	at java.util.concurrent.FutureTask.run(FutureTask.java:138) [rt.jar:1.6.0_30]
> [JBossINF] 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_30]
> [JBossINF] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_30]
> [JBossINF] 	at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]
> [JBossINF] 	at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> [JBossINF] Caused by: org.jgroups.TimeoutException: timeout sending message to perf21/ejb
> [JBossINF] 	at org.jgroups.blocks.MessageDispatcher.sendMessage(MessageDispatcher.java:360)
> [JBossINF] 	at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:263)
> [JBossINF] 	at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:163)
> [JBossINF] 	... 65 more
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:49 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-91) Impossible to use "reload" MDR
 operation in testsuite run
In-Reply-To: <JIRA.12461775.1331816114000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12461775.1331816114000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12461775.1331816114000.15567.1380922969129@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-91:
-----------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Impossible to use "reload" MDR operation in testsuite run
> ---------------------------------------------------------
>
>                 Key: WFLY-91
>                 URL: https://issues.jboss.org/browse/WFLY-91
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMX
>            Reporter: Vladimir Rastseluev
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.0.CR1
>
>         Attachments: AS7-4185-failure.txt
>
>
> Writing test, using Arquillian, that needs server reloading (e.g.for changing server configuration). 
> Test successfully pass, when runs alone. 
> If it runs in testsuite, it can pass or not, but tests,next to it, fail with this exception:
> org.jboss.remoting3.NotOpenException: Writes closed
> 	at org.jboss.remoting3.remote.RemoteConnectionChannel.openOutboundMessage(RemoteConnectionChannel.java:107)
> 	at org.jboss.remoting3.remote.RemoteConnectionChannel.writeMessage(RemoteConnectionChannel.java:296)
> 	at org.jboss.remotingjmx.protocol.v1.Common.write(Common.java:177)
> 	at org.jboss.remotingjmx.protocol.v1.ClientConnection$TheConnection.addNotificationListener(ClientConnection.java:1298)
> 	at org.jboss.arquillian.protocol.jmx.JMXMethodExecutor.invoke(JMXMethodExecutor.java:65)
> 	at org.jboss.arquillian.container.test.impl.execution.RemoteTestExecuter.execute(RemoteTestExecuter.java:120)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114)
> 	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> 	at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:57)
> 	at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
> 	at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129)
> 	at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89)
> 	at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
> 	at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
> 	at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134)
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111)
> 	at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263)
> 	at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> 	at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> 	at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
> 	at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> 	at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> 	at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
> 	at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
> 	at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164)
> 	at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110)
> 	at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175)
> 	at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:49 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-69) Using an extended persistence
 context in a stateless session bean should throw an exception
In-Reply-To: <JIRA.12461041.1331205537000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12461041.1331205537000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12461041.1331205537000.15582.1380922969760@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-69:
-----------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Using an extended persistence context in a stateless session bean should throw an exception
> -------------------------------------------------------------------------------------------
>
>                 Key: WFLY-69
>                 URL: https://issues.jboss.org/browse/WFLY-69
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>            Reporter: Karsten Wutzke
>             Fix For: 8.0.0.CR1
>
>
> Using an extended persistence context in a stateless session bean should not initiate. It should throw an exception to notify the user of incorrect use.
> See JPA 2.0 spec, section 7.6.2:
> "A container-managed extended persistence context can only be initiated within the scope of a stateful session bean."

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:49 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-84) Jasper using wrong
 ProtectionDomain for compiled JSP
In-Reply-To: <JIRA.12486586.1362598770000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12486586.1362598770000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12486586.1362598770000.15575.1380922969469@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-84:
-----------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Jasper using wrong ProtectionDomain for compiled JSP
> ----------------------------------------------------
>
>                 Key: WFLY-84
>                 URL: https://issues.jboss.org/browse/WFLY-84
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (JBoss Web)
>            Reporter: David Lloyd
>            Assignee: Remy Maucherat
>             Fix For: 8.0.0.CR1
>
>
> Compiled JSPs loaded via JasperLoader appear to be using a different ProtectionDomain than the rest of the WAR deployment.  I think it should probably be using a PD which contains the permissions from the deployment's ClassLoader, and probably the CodeSource from the deployment unit from which the JSP file originated.  This will ensure that permissions set via deployment descriptor and/or the management model will take proper effect.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:47 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-131) Seam2Processor will not have
 permissions to its added resource loader
In-Reply-To: <JIRA.12486803.1362759602000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12486803.1362759602000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12486803.1362759602000.15540.1380922967836@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-131:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Seam2Processor will not have permissions to its added resource loader
> ---------------------------------------------------------------------
>
>                 Key: WFLY-131
>                 URL: https://issues.jboss.org/browse/WFLY-131
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>            Reporter: David Lloyd
>            Assignee: Ales Justin
>              Labels: security
>             Fix For: 8.0.0.CR1
>
>
> The {{Seam2Processor}} class adds a {{VFSResourceLoader}} to the deployment in order to copy certain Seam classes into it.  The problem is that the {{VFSResourceLoader}} will fail at runtime with a permission exception because there is no corresponding {{VirtualFilePermission}}.
> For this type of resource loader, it is better just to add the JAR using {{JarFileResourceLoader}}, which does not require permissions at load time and is much faster anyway.
> If you must use {{VFSResourceLoader}}, then instead of creating and adding the resource loader yourself, add a {{ResourceRoot}} to the deployment context.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:49 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-89) Spurious server dirs created
 when directory-grouping="by-type" is set
In-Reply-To: <JIRA.12484874.1360798062000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12484874.1360798062000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12484874.1360798062000.15570.1380922969266@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-89:
-----------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Spurious server dirs created when directory-grouping="by-type" is set
> ---------------------------------------------------------------------
>
>                 Key: WFLY-89
>                 URL: https://issues.jboss.org/browse/WFLY-89
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: James Perkins
>            Priority: Minor
>             Fix For: 8.0.0.CR1
>
>
> Add directory-grouping="by-type" to the <host><servers> element in the stock host.xml and run domain.sh. The following empty directories are created:
> $JBOSS_HOME/domain/servers/server-one
> $JBOSS_HOME/domain/servers/server-two
> The content that would normally be in those dirs if directory-grouping="by-type" wasn't set appears to all be going where it should (e.g. under domain/data, domain/log etc) so the only issue here is the empty directories.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:47 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-143) Improve testing of Infinispan
 subsystem management features
In-Reply-To: <JIRA.12460965.1331141477000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12460965.1331141477000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12460965.1331141477000.15526.1380922967204@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-143:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Improve testing of Infinispan subsystem management features
> -----------------------------------------------------------
>
>                 Key: WFLY-143
>                 URL: https://issues.jboss.org/browse/WFLY-143
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Domain Management
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>             Fix For: 8.0.0.CR1
>
>
> We current use InfinispanSubsystemTest to test the integrity of the Infinispan subsystem implementation. 
> From the documentation:
> {noformat}
> Tests the ability to create a model from an xml configuration, marshal the model back to xml, re-read that marshalled model 
> into a new model that matches the first one, execute a "describe" operation for the model, create yet another model 
> from executing the results of that describe operation, and compare that model to first model.
> {noformat}
> Over and above these tests, we need more specific tests which cover use cases such as:
> - every attribute can be read/written as required and that the subsequent reload-required state is as expected
> - operation sequences such as add/remove/add, add/add give expected results for all resources in the subsystem 
> - validating that the XML configuration specified gets translated into the desired Infinispan configuration
> - and many others

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:50 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-30) @Resource injection of
 Datasource on clustered SFSB fails with serialization error
In-Reply-To: <JIRA.12483468.1359083528000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12483468.1359083528000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12483468.1359083528000.15595.1380922970729@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-30:
-----------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> @Resource injection of Datasource on clustered SFSB fails with serialization error
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-30
>                 URL: https://issues.jboss.org/browse/WFLY-30
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 8.0.0.CR1
>
>
> See JBPAPP6-1762 for details.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:52 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-11) Bundle path for Embedded server
 still not working properly
In-Reply-To: <JIRA.12484275.1360227252000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12484275.1360227252000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12484275.1360227252000.15626.1380922972053@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-11?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-11:
-----------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Bundle path for Embedded server still not working properly
> ----------------------------------------------------------
>
>                 Key: WFLY-11
>                 URL: https://issues.jboss.org/browse/WFLY-11
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Galder Zamarre?o
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.0.CR1
>
>
> Error is:
> {code}  io.escalante.test.artifact.ArtifactInstallTest: bundlesDir not a directory{code}
> The problem is that the check is done in an 'assert' block and that only happens when assertions have been enabled by the user :(
> The problem comes cos bundlesDir is set to "null/bundles", even if I have not set any bundlesDir.
> Seems like bundlesDir is pre-computed too early in EmbeddedContainerConfiguration where it expects a system property, but that might not be set, it might come from arquillian.xml. So better delay until EmbeddedServerFactory.create.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Fri Oct  4 17:42:50 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-55) StatefulFailoverTestCase
 intermittently fails
In-Reply-To: <JIRA.12470733.1342648060000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12470733.1342648060000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12470733.1342648060000.15590.1380922970492@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-55:
-----------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> StatefulFailoverTestCase intermittently fails
> ---------------------------------------------
>
>                 Key: WFLY-55
>                 URL: https://issues.jboss.org/browse/WFLY-55
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Test Suite
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Jason Greene
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.CR1
>
>
> org.jboss.as.test.clustering.cluster.ejb3.stateful.StatefulFailoverTestCase(UDP).testRestart
> Failing for the past 1 build (Since #4183 )
> Took 2 min 18 sec.
> Error Message
> expected:<200> but was:<500>
> Stacktrace
> java.lang.AssertionError: expected:<200> but was:<500>
> 	at org.junit.Assert.fail(Assert.java:93)
> 	at org.junit.Assert.failNotEquals(Assert.java:647)
> 	at org.junit.Assert.assertEquals(Assert.java:128)
> 	at org.junit.Assert.assertEquals(Assert.java:472)
> 	at org.junit.Assert.assertEquals(Assert.java:456)
> 	at org.jboss.as.test.clustering.cluster.ejb3.stateful.StatefulFailoverTestCase.queryCount(StatefulFailoverTestCase.java:256)
> 	at org.jboss.as.test.clustering.cluster.ejb3.stateful.StatefulFailoverTestCase.assertQueryCount(StatefulFailoverTestCase.java:278)
> 	at org.jboss.as.test.clustering.cluster.ejb3.stateful.StatefulFailoverTestCase.testRestart(StatefulFailoverTestCase.java:139)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
> 	at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:270)
> 	at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
> 	at sun.reflect.GeneratedMethodAccessor12.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
> 	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> 	at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:53)
> 	at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
> 	at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129)
> 	at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89)
> 	at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
> 	at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
> 	at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111)
> 	at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263)
> 	at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> 	at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> 	at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
> 	at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> 	at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> 	at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
> 	at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188)
> 	at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166)
> 	at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
> Standard Output
> 13:55:02,557 INFO  [org.jboss.web] (MSC service thread 1-2) JBAS018224: Unregister web context: /stateful
> 13:55:02,619 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 4) ISPN000029: Passivating all entries to disk
> 13:55:02,623 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 4) ISPN000030: Passivated 0 entries in 3 milliseconds
> 13:55:02,619 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 26) ISPN000029: Passivating all entries to disk
> 13:55:02,630 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-5) ISPN000029: Passivating all entries to disk
> 13:55:02,630 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 26) ISPN000030: Passivated 0 entries in 8 milliseconds
> 13:55:02,633 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-5) ISPN000030: Passivated 0 entries in 2 milliseconds
> 13:55:02,644 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-5) JBAS010282: Stopped default-host/stateful cache from web container
> 13:55:02,653 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 4) JBAS010282: Stopped org.jboss.as.test.clustering.cluster.ejb3.stateful.bean.NestedBean cache from ejb container
> 13:55:02,654 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 26) JBAS010282: Stopped org.jboss.as.test.clustering.cluster.ejb3.stateful.bean.StatefulBean cache from ejb container
> 13:55:02,668 INFO  [org.jboss.weld.deployer] (MSC service thread 1-4) JBAS016009: Stopping weld service for deployment stateful.war
> 13:55:02,725 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-4) ISPN000029: Passivating all entries to disk
> 13:55:02,726 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-4) ISPN000030: Passivated 0 entries in 0 milliseconds
> 13:55:02,726 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-3) ISPN000029: Passivating all entries to disk
> 13:55:02,728 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-3) ISPN000030: Passivated 0 entries in 1 milliseconds
> 13:55:02,737 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-3) JBAS010282: Stopped repl cache from ejb container
> 13:55:02,739 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-4) JBAS010282: Stopped repl cache from web container
> 13:55:02,753 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-6) JBAS010282: Stopped remote-connector-client-mappings cache from ejb container
> 13:55:02,775 INFO  [org.infinispan.cacheviews.CacheViewsManagerImpl] (OOB-17,null) ISPN000170: Our last committed view (CacheView{viewId=2, members=[node-0/web, node-1/web]}) is not the same as the coordinator's last committed view (CacheView{viewId=3, members=[node-0/web]}). This is normal during a merge
> 13:55:02,825 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015877: Stopped deployment stateful.war in 298ms
> 13:55:02,786 WARN  [org.infinispan.commands.control.CacheViewControlCommand] (OOB-17,null) ISPN000071: Caught exception when handling command CacheViewControlCommand{cache=default-host/stateful, type=PREPARE_VIEW, sender=node-0/web, newViewId=4, newMembers=[node-0/web, node-1/web], oldViewId=3, oldMembers=[node-0/web]}: java.lang.IllegalStateException: default-host/stateful: Received cache view prepare request after the local node has already shut down
> 	at org.infinispan.cacheviews.CacheViewsManagerImpl.handlePrepareView(CacheViewsManagerImpl.java:487)
> 	at org.infinispan.commands.control.CacheViewControlCommand.perform(CacheViewControlCommand.java:126)
> 	at org.infinispan.remoting.InboundInvocationHandlerImpl.handle(InboundInvocationHandlerImpl.java:95)
> 	at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommand(CommandAwareRpcDispatcher.java:226)
> 	at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:203)
> 	at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:465)
> 	at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:372)
> 	at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:247)
> 	at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:601)
> 	at org.jgroups.blocks.mux.MuxUpHandler.up(MuxUpHandler.java:130)
> 	at org.jgroups.JChannel.up(JChannel.java:715)
> 	at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1020)
> 	at org.jgroups.protocols.RSVP.up(RSVP.java:179)
> 	at org.jgroups.protocols.FRAG2.up(FRAG2.java:181)
> 	at org.jgroups.protocols.FlowControl.up(FlowControl.java:418)
> 	at org.jgroups.protocols.FlowControl.up(FlowControl.java:400)
> 	at org.jgroups.protocols.pbcast.GMS.up(GMS.java:899)
> 	at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244)
> 	at org.jgroups.protocols.UNICAST2.handleDataReceived(UNICAST2.java:744)
> 	at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:414)
> 	at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:572)
> 	at org.jgroups.protocols.BARRIER.up(BARRIER.java:102)
> 	at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143)
> 	at org.jgroups.protocols.FD.up(FD.java:273)
> 	at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288)
> 	at org.jgroups.protocols.MERGE2.up(MERGE2.java:205)
> 	at org.jgroups.protocols.Discovery.up(Discovery.java:359)
> 	at org.jgroups.protocols.TP$ProtocolAdapter.up(TP.java:2568)
> 	at org.jgroups.protocols.TP.passMessageUp(TP.java:1211)
> 	at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1775)
> 	at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1748)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
> 	at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> 13:55:03,062 INFO  [org.jboss.as.clustering] (ViewHandler,web,node-0/web) JBAS010225: New cluster view for partition web (id: 2, delta: -1, merge: false) : [node-0/web]
> 13:55:03,063 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ViewHandler,web,node-0/web) ISPN000094: Received new cluster view: [node-0/web|2] [node-0/web]
> 13:55:03,098 INFO  [org.jboss.as.clustering] (ViewHandler,ejb,node-0/ejb) JBAS010225: New cluster view for partition ejb (id: 2, delta: -1, merge: false) : [node-0/ejb]
> 13:55:03,100 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ViewHandler,ejb,node-0/ejb) ISPN000094: Received new cluster view: [node-0/ejb|2] [node-0/ejb]
> 13:55:03,355 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000082: Stopping the RpcDispatcher
> 13:55:03,501 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000082: Stopping the RpcDispatcher
> 13:55:03,559 INFO  [org.jboss.as.repository] (management-handler-thread - 3) JBAS014901: Content removed from location /home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-1/standalone/data/content/5c/37165cc1c30b1263a1854cab3a82149afcf0f2/content
> 13:55:03,560 INFO  [org.jboss.as.server] (management-handler-thread - 3) JBAS018558: Undeployed "stateful.war"
> 13:55:03,563 INFO  [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual stopping of a server instance
> URLs are: http://127.0.0.1:8080/stateful/count, http://127.0.0.1:8180/stateful/count
> 13:56:02,775 ERROR [org.infinispan.cacheviews.CacheViewsManagerImpl] (CacheViewInstaller-2,node-0/web) ISPN000172: Failed to prepare view CacheView{viewId=4, members=[node-0/web, node-1/web]} for cache  default-host/stateful, rolling back to view CacheView{viewId=3, members=[node-0/web]}: java.util.concurrent.ExecutionException: org.infinispan.CacheException: org.jgroups.TimeoutException: TimeoutException
> 	at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:232) [rt.jar:1.6.0_29]
> 	at java.util.concurrent.FutureTask.get(FutureTask.java:91) [rt.jar:1.6.0_29]
> 	at org.infinispan.cacheviews.CacheViewsManagerImpl.clusterPrepareView(CacheViewsManagerImpl.java:318) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
> 	at org.infinispan.cacheviews.CacheViewsManagerImpl.clusterInstallView(CacheViewsManagerImpl.java:249) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
> 	at org.infinispan.cacheviews.CacheViewsManagerImpl$ViewInstallationTask.call(CacheViewsManagerImpl.java:875) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [rt.jar:1.6.0_29]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138) [rt.jar:1.6.0_29]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
> 	at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> Caused by: org.infinispan.CacheException: org.jgroups.TimeoutException: TimeoutException
> 	at org.infinispan.util.Util.rewrapAsCacheException(Util.java:526) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
> 	at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:172) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
> 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:489) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
> 	at org.infinispan.cacheviews.CacheViewsManagerImpl$2.call(CacheViewsManagerImpl.java:302) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
> 	at org.infinispan.cacheviews.CacheViewsManagerImpl$2.call(CacheViewsManagerImpl.java:299) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
> 	... 5 more
> Caused by: org.jgroups.TimeoutException: TimeoutException
> 	at org.jgroups.util.Promise._getResultWithTimeout(Promise.java:145) [jgroups-3.1.0.Final.jar:3.1.0.Final]
> 	at org.jgroups.util.Promise.getResultWithTimeout(Promise.java:40) [jgroups-3.1.0.Final.jar:3.1.0.Final]
> 	at org.jgroups.util.AckCollector.waitForAllAcks(AckCollector.java:93) [jgroups-3.1.0.Final.jar:3.1.0.Final]
> 	at org.jgroups.protocols.RSVP$Entry.block(RSVP.java:275) [jgroups-3.1.0.Final.jar:3.1.0.Final]
> 	at org.jgroups.protocols.RSVP.down(RSVP.java:114) [jgroups-3.1.0.Final.jar:3.1.0.Final]
> 	at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1025) [jgroups-3.1.0.Final.jar:3.1.0.Final]
> 	at org.jgroups.JChannel.down(JChannel.java:729) [jgroups-3.1.0.Final.jar:3.1.0.Final]
> 	at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.down(MessageDispatcher.java:617) [jgroups-3.1.0.Final.jar:3.1.0.Final]
> 	at org.jgroups.blocks.RequestCorrelator.sendUnicastRequest(RequestCorrelator.java:202) [jgroups-3.1.0.Final.jar:3.1.0.Final]
> 	at org.jgroups.blocks.UnicastRequest.sendRequest(UnicastRequest.java:44) [jgroups-3.1.0.Final.jar:3.1.0.Final]
> 	at org.jgroups.blocks.Request.execute(Request.java:83) [jgroups-3.1.0.Final.jar:3.1.0.Final]
> 	at org.jgroups.blocks.MessageDispatcher.sendMessage(MessageDispatcher.java:366) [jgroups-3.1.0.Final.jar:3.1.0.Final]
> 	at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:275) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
> 	at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:165) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
> 	... 8 more
> 13:56:04,452 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (http-/127.0.0.1:8080-1) ISPN000136: Execution error: org.infinispan.statetransfer.StateTransferInProgressException: Timed out waiting for the state transfer lock, state transfer in progress for view 4
> 	at org.infinispan.interceptors.StateTransferLockInterceptor.signalStateTransferInProgress(StateTransferLockInterceptor.java:201)
> 	at org.infinispan.interceptors.StateTransferLockInterceptor.visitPrepareCommand(StateTransferLockInterceptor.java:81)
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130)
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:132)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:91)
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
> 	at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:86)
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:345)
> 	at org.infinispan.transaction.TransactionCoordinator.commit(TransactionCoordinator.java:174)
> 	at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:81)
> 	at org.infinispan.transaction.tm.DummyTransaction.notifyAfterCompletion(DummyTransaction.java:285)
> 	at org.infinispan.transaction.tm.DummyTransaction.runCommitTx(DummyTransaction.java:334)
> 	at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:91)
> 	at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:102)
> 	at org.jboss.as.clustering.web.impl.TransactionBatchingManager.endBatch(TransactionBatchingManager.java:75)
> 	at org.jboss.as.web.session.DistributableSessionManager.processSessionRepl(DistributableSessionManager.java:1515) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.DistributableSessionManager.storeSession(DistributableSessionManager.java:857) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.InstantSnapshotManager.snapshot(InstantSnapshotManager.java:47) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:133) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:91) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.JvmRouteValve.invoke(JvmRouteValve.java:88) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.LockingValve.invoke(LockingValve.java:56) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:156) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:679) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931) [jbossweb-7.0.16.Final.jar:]
> 	at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> 13:56:04,479 ERROR [org.infinispan.transaction.TransactionCoordinator] (http-/127.0.0.1:8080-1) ISPN000097: Error while processing a prepare in a single-phase transaction: org.infinispan.statetransfer.StateTransferInProgressException: Timed out waiting for the state transfer lock, state transfer in progress for view 4
> 	at org.infinispan.interceptors.StateTransferLockInterceptor.signalStateTransferInProgress(StateTransferLockInterceptor.java:201)
> 	at org.infinispan.interceptors.StateTransferLockInterceptor.visitPrepareCommand(StateTransferLockInterceptor.java:81)
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130)
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:132)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:91)
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
> 	at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:86)
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:345)
> 	at org.infinispan.transaction.TransactionCoordinator.commit(TransactionCoordinator.java:174)
> 	at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:81)
> 	at org.infinispan.transaction.tm.DummyTransaction.notifyAfterCompletion(DummyTransaction.java:285)
> 	at org.infinispan.transaction.tm.DummyTransaction.runCommitTx(DummyTransaction.java:334)
> 	at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:91)
> 	at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:102)
> 	at org.jboss.as.clustering.web.impl.TransactionBatchingManager.endBatch(TransactionBatchingManager.java:75)
> 	at org.jboss.as.web.session.DistributableSessionManager.processSessionRepl(DistributableSessionManager.java:1515) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.DistributableSessionManager.storeSession(DistributableSessionManager.java:857) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.InstantSnapshotManager.snapshot(InstantSnapshotManager.java:47) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:133) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:91) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.JvmRouteValve.invoke(JvmRouteValve.java:88) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.LockingValve.invoke(LockingValve.java:56) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:156) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:679) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931) [jbossweb-7.0.16.Final.jar:]
> 	at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> 13:56:04,503 ERROR [org.infinispan.transaction.tm.DummyTransaction] (http-/127.0.0.1:8080-1) ISPN000111: afterCompletion() failed for SynchronizationAdapter{localTransaction=LocalTransaction{remoteLockedNodes=null, isMarkedForRollback=false, transaction=DummyTransaction{xid=DummyXid{id=19}, status=3}, lockedKeys=null, backupKeyLocks=null, viewId=2} org.infinispan.transaction.synchronization.SyncLocalTransaction at 11} org.infinispan.transaction.synchronization.SynchronizationAdapter at 30: org.infinispan.CacheException: Could not commit.
> 	at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:83)
> 	at org.infinispan.transaction.tm.DummyTransaction.notifyAfterCompletion(DummyTransaction.java:285)
> 	at org.infinispan.transaction.tm.DummyTransaction.runCommitTx(DummyTransaction.java:334)
> 	at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:91)
> 	at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:102)
> 	at org.jboss.as.clustering.web.impl.TransactionBatchingManager.endBatch(TransactionBatchingManager.java:75)
> 	at org.jboss.as.web.session.DistributableSessionManager.processSessionRepl(DistributableSessionManager.java:1515) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.DistributableSessionManager.storeSession(DistributableSessionManager.java:857) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.InstantSnapshotManager.snapshot(InstantSnapshotManager.java:47) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:133) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:91) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.JvmRouteValve.invoke(JvmRouteValve.java:88) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.LockingValve.invoke(LockingValve.java:56) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:156) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:679) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931) [jbossweb-7.0.16.Final.jar:]
> 	at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> Caused by: javax.transaction.xa.XAException
> 	at org.infinispan.transaction.TransactionCoordinator.handleCommitFailure(TransactionCoordinator.java:223)
> 	at org.infinispan.transaction.TransactionCoordinator.commit(TransactionCoordinator.java:176)
> 	at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:81)
> 	... 21 more
> 13:57:04,672 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (http-/127.0.0.1:8080-1) ISPN000136: Execution error: org.infinispan.statetransfer.StateTransferInProgressException: Timed out waiting for the state transfer lock, state transfer in progress for view 4
> 	at org.infinispan.interceptors.StateTransferLockInterceptor.signalStateTransferInProgress(StateTransferLockInterceptor.java:201)
> 	at org.infinispan.interceptors.StateTransferLockInterceptor.visitPrepareCommand(StateTransferLockInterceptor.java:81)
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130)
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:132)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:91)
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
> 	at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:86)
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:345)
> 	at org.infinispan.transaction.TransactionCoordinator.commit(TransactionCoordinator.java:174)
> 	at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:81)
> 	at org.infinispan.transaction.tm.DummyTransaction.notifyAfterCompletion(DummyTransaction.java:285)
> 	at org.infinispan.transaction.tm.DummyTransaction.runCommitTx(DummyTransaction.java:334)
> 	at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:91)
> 	at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:102)
> 	at org.jboss.as.clustering.web.impl.TransactionBatchingManager.endBatch(TransactionBatchingManager.java:75)
> 	at org.jboss.as.web.session.DistributableSessionManager.processSessionRepl(DistributableSessionManager.java:1515) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.DistributableSessionManager.storeSession(DistributableSessionManager.java:857) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.InstantSnapshotManager.snapshot(InstantSnapshotManager.java:47) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:133) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:91) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.JvmRouteValve.invoke(JvmRouteValve.java:88) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.LockingValve.invoke(LockingValve.java:56) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:156) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:679) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931) [jbossweb-7.0.16.Final.jar:]
> 	at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> 13:57:04,697 ERROR [org.infinispan.transaction.TransactionCoordinator] (http-/127.0.0.1:8080-1) ISPN000097: Error while processing a prepare in a single-phase transaction: org.infinispan.statetransfer.StateTransferInProgressException: Timed out waiting for the state transfer lock, state transfer in progress for view 4
> 	at org.infinispan.interceptors.StateTransferLockInterceptor.signalStateTransferInProgress(StateTransferLockInterceptor.java:201)
> 	at org.infinispan.interceptors.StateTransferLockInterceptor.visitPrepareCommand(StateTransferLockInterceptor.java:81)
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130)
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:132)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:91)
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
> 	at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:86)
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:345)
> 	at org.infinispan.transaction.TransactionCoordinator.commit(TransactionCoordinator.java:174)
> 	at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:81)
> 	at org.infinispan.transaction.tm.DummyTransaction.notifyAfterCompletion(DummyTransaction.java:285)
> 	at org.infinispan.transaction.tm.DummyTransaction.runCommitTx(DummyTransaction.java:334)
> 	at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:91)
> 	at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:102)
> 	at org.jboss.as.clustering.web.impl.TransactionBatchingManager.endBatch(TransactionBatchingManager.java:75)
> 	at org.jboss.as.web.session.DistributableSessionManager.processSessionRepl(DistributableSessionManager.java:1515) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.DistributableSessionManager.storeSession(DistributableSessionManager.java:857) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.InstantSnapshotManager.snapshot(InstantSnapshotManager.java:47) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:133) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:91) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.JvmRouteValve.invoke(JvmRouteValve.java:88) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.LockingValve.invoke(LockingValve.java:56) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:156) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:679) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931) [jbossweb-7.0.16.Final.jar:]
> 	at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> 13:57:04,723 ERROR [org.infinispan.transaction.tm.DummyTransaction] (http-/127.0.0.1:8080-1) ISPN000111: afterCompletion() failed for SynchronizationAdapter{localTransaction=LocalTransaction{remoteLockedNodes=null, isMarkedForRollback=false, transaction=DummyTransaction{xid=DummyXid{id=30}, status=3}, lockedKeys=null, backupKeyLocks=null, viewId=2} org.infinispan.transaction.synchronization.SyncLocalTransaction at 1c} org.infinispan.transaction.synchronization.SynchronizationAdapter at 3b: org.infinispan.CacheException: Could not commit.
> 	at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:83)
> 	at org.infinispan.transaction.tm.DummyTransaction.notifyAfterCompletion(DummyTransaction.java:285)
> 	at org.infinispan.transaction.tm.DummyTransaction.runCommitTx(DummyTransaction.java:334)
> 	at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:91)
> 	at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:102)
> 	at org.jboss.as.clustering.web.impl.TransactionBatchingManager.endBatch(TransactionBatchingManager.java:75)
> 	at org.jboss.as.web.session.DistributableSessionManager.processSessionRepl(DistributableSessionManager.java:1515) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.DistributableSessionManager.storeSession(DistributableSessionManager.java:857) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.InstantSnapshotManager.snapshot(InstantSnapshotManager.java:47) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:133) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:91) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.JvmRouteValve.invoke(JvmRouteValve.java:88) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.LockingValve.invoke(LockingValve.java:56) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:156) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:679) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931) [jbossweb-7.0.16.Final.jar:]
> 	at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> Caused by: javax.transaction.xa.XAException
> 	at org.infinispan.transaction.TransactionCoordinator.handleCommitFailure(TransactionCoordinator.java:223)
> 	at org.infinispan.transaction.TransactionCoordinator.commit(TransactionCoordinator.java:176)
> 	at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:81)
> 	... 21 more
> 13:57:04,739 INFO  [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual starting of a server instance
> 13:57:04,745 INFO  [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Starting container with: [/opt/jdk1.6.0_29/bin/java, -Xmx512m, -XX:MaxPermSize=256m, -Djboss.dist=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/../../../build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT, -Djava.net.preferIPv4Stack=true, -Djava.net.preferIPv6Addresses=false, -Dts.timeout.factor=100, -Dnode0=127.0.0.1, -Dnode1=127.0.0.1, -Dmcast=230.0.0.4, -Djbossas.ts.submodule.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust, -Djbossas.ts.integ.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/.., -Djbossas.ts.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/../.., -Djbossas.project.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/../../.., -Djboss.dist=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/../../../build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT, -Djboss.inst=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-1, -Djboss.node.name=node-1, -Djboss.port.offset=100, -ea, -Djboss.home.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-1, -Dorg.jboss.boot.log.file=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-1/standalone/log/boot.log, -Dlogging.configuration=file:/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-1/standalone/configuration/logging.properties, -Djboss.bundles.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/../../../build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT/bundles, -jar, /home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-1/jboss-modules.jar, -mp, /home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/../../../build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT/modules, -jaxpmodule, javax.xml.jaxp-provider, org.jboss.as.standalone, -server-config, standalone-ha.xml]
> 13:57:05,648 INFO  [org.jboss.modules] JBoss Modules version 1.1.2.GA
> 13:57:05,920 INFO  [org.jboss.msc] JBoss MSC version 1.0.2.GA
> 13:57:05,990 INFO  [org.jboss.as] JBAS015899: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" starting
> 13:57:07,922 INFO  [org.xnio] XNIO Version 3.0.5.GA
> 13:57:07,927 INFO  [org.jboss.as.server] JBAS015888: Creating http management service using socket-binding (management-http)
> 13:57:07,933 INFO  [org.xnio.nio] XNIO NIO Implementation Version 3.0.5.GA
> 13:57:07,945 INFO  [org.jboss.remoting] JBoss Remoting version 3.2.8.GA
> 13:57:08,035 INFO  [org.jboss.as.logging] JBAS011502: Removing bootstrap log handlers
> 13:57:08,043 INFO  [org.jboss.as.configadmin] (ServerService Thread Pool -- 29) JBAS016200: Activating ConfigAdmin Subsystem
> 13:57:08,079 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 34) JBAS010280: Activating Infinispan subsystem.
> 13:57:08,127 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 38) JBAS010260: Activating JGroups subsystem.
> 13:57:08,133 INFO  [org.jboss.as.osgi] (ServerService Thread Pool -- 45) JBAS011906: Activating OSGi Subsystem
> 13:57:08,138 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 50) JBAS013171: Activating Security Subsystem
> 13:57:08,176 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 44) JBAS011800: Activating Naming Subsystem
> 13:57:08,246 INFO  [org.jboss.as.security] (MSC service thread 1-4) JBAS013170: Current PicketBox version=4.0.9.Final
> 13:57:08,272 INFO  [org.jboss.as.connector.logging] (MSC service thread 1-3) JBAS010408: Starting JCA Subsystem (JBoss IronJacamar 1.0.11.Final)
> 13:57:08,278 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 54) JBAS015537: Activating WebServices Extension
> 13:57:08,438 INFO  [org.jboss.as.naming] (MSC service thread 1-3) JBAS011802: Starting Naming Service
> 13:57:08,472 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-5) JBAS015400: Bound mail session [java:jboss/mail/Default]
> 13:57:08,537 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 30) JBAS010403: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 13:57:08,791 INFO  [org.jboss.ws.common.management.AbstractServerConfig] (MSC service thread 1-5) JBoss Web Services - Stack CXF Server 4.1.0.Beta1
> 13:57:09,050 INFO  [org.apache.coyote.ajp.AjpProtocol] (MSC service thread 1-2) Starting Coyote AJP/1.3 on ajp-/127.0.0.1:8109
> 13:57:09,062 INFO  [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-1) Starting Coyote HTTP/1.1 on http-/127.0.0.1:8180
> 13:57:09,214 INFO  [org.jboss.modcluster.ModClusterService] (ServerService Thread Pool -- 56) Initializing mod_cluster 1.2.1.Final
> 13:57:09,263 INFO  [org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl] (ServerService Thread Pool -- 56) Listening to proxy advertisements on 224.0.1.105:23,364
> 13:57:09,336 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 34) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> 13:57:09,359 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 34) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> 13:57:09,535 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-4) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
> 13:57:09,553 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-1) JBAS015012: Started FileSystemDeploymentService for directory /home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-1/standalone/deployments
> 13:57:09,559 INFO  [org.jboss.as.remoting] (MSC service thread 1-2) JBAS017100: Listening on 127.0.0.1:4547
> 13:57:09,560 INFO  [org.jboss.as.remoting] (MSC service thread 1-5) JBAS017100: Listening on 127.0.0.1:10099
> 13:57:09,684 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:10090/management
> 13:57:09,685 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:10090
> 13:57:09,685 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" started in 4360ms - Started 138 of 285 services (146 services are passive or on-demand)
> 13:57:11,925 INFO  [org.jboss.as.repository] (management-handler-thread - 2) JBAS014900: Content added at location /home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-1/standalone/data/content/33/a062483bafd997e0d3374cfa764aeb07874c01/content
> 13:57:11,983 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-6) JBAS015876: Starting deployment of "stateful.war"
> 13:57:12,783 INFO  [org.jboss.osgi.framework] (MSC service thread 1-5) JBOSGI011006: OSGi Framework - 2.0.0.CR12
> 13:57:13,163 INFO  [org.jboss.weld.deployer] (MSC service thread 1-1) JBAS016002: Processing weld deployment stateful.war
> 13:57:13,182 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-1) JNDI bindings for session bean named StatefulBean in deployment unit deployment "stateful.war" are as follows:
> 	java:global/stateful/StatefulBean!org.jboss.as.test.clustering.cluster.ejb3.stateful.bean.Stateful
> 	java:app/stateful/StatefulBean!org.jboss.as.test.clustering.cluster.ejb3.stateful.bean.Stateful
> 	java:module/StatefulBean!org.jboss.as.test.clustering.cluster.ejb3.stateful.bean.Stateful
> 	java:global/stateful/StatefulBean
> 	java:app/stateful/StatefulBean
> 	java:module/StatefulBean
> 13:57:13,183 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-1) JNDI bindings for session bean named NestedBean in deployment unit deployment "stateful.war" are as follows:
> 	java:global/stateful/NestedBean!org.jboss.as.test.clustering.cluster.ejb3.stateful.bean.Nested
> 	java:app/stateful/NestedBean!org.jboss.as.test.clustering.cluster.ejb3.stateful.bean.Nested
> 	java:module/NestedBean!org.jboss.as.test.clustering.cluster.ejb3.stateful.bean.Nested
> 	java:global/stateful/NestedBean
> 	java:app/stateful/NestedBean
> 	java:module/NestedBean
> 13:57:13,619 INFO  [org.jboss.weld.deployer] (MSC service thread 1-5) JBAS016005: Starting Services for CDI deployment: stateful.war
> 13:57:13,769 INFO  [org.jboss.weld.Version] (MSC service thread 1-5) WELD-000900 1.1.8 (Final)
> 13:57:13,975 INFO  [org.jboss.weld.deployer] (MSC service thread 1-4) JBAS016008: Starting weld service for deployment stateful.war
> 13:57:14,130 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-5) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> 13:57:14,131 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-2) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> 13:57:14,134 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-1) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> 13:57:14,536 INFO  [org.jboss.weld.ClassLoading] (MSC service thread 1-4) WELD-000119 Not generating any bean definitions from org.jboss.as.test.clustering.ClusterHttpClientUtil because of underlying class loading error
> 13:57:14,538 INFO  [org.jboss.weld.ClassLoading] (MSC service thread 1-4) catching: org.jboss.weld.resources.spi.ResourceLoadingException: Error loading class org.jboss.as.test.clustering.ClusterHttpClientUtil
> 	at org.jboss.weld.resources.ClassTransformer.loadClass(ClassTransformer.java:167) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.bootstrap.BeanDeployer.loadWeldClass(BeanDeployer.java:108) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:79) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.bootstrap.BeanDeployer.addClasses(BeanDeployer.java:123) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.bootstrap.BeanDeployment.createBeans(BeanDeployment.java:184) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:350) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.as.weld.WeldContainer.start(WeldContainer.java:82) [jboss-as-weld-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.weld.services.WeldService.start(WeldService.java:76) [jboss-as-weld-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
> 	at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> Caused by: java.lang.NoClassDefFoundError: org/apache/http/client/methods/HttpUriRequest
> 	at java.lang.Class.getDeclaredFields0(Native Method) [rt.jar:1.6.0_29]
> 	at java.lang.Class.privateGetDeclaredFields(Class.java:2291) [rt.jar:1.6.0_29]
> 	at java.lang.Class.getDeclaredFields(Class.java:1743) [rt.jar:1.6.0_29]
> 	at org.jboss.weld.util.reflection.SecureReflections$4.work(SecureReflections.java:105) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.util.reflection.SecureReflections$4.work(SecureReflections.java:102) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:52) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.util.reflection.SecureReflectionAccess.runAndWrap(SecureReflectionAccess.java:63) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.util.reflection.SecureReflections.getDeclaredFields(SecureReflections.java:102) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.introspector.jlr.WeldClassImpl.<init>(WeldClassImpl.java:154) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.introspector.jlr.WeldClassImpl.of(WeldClassImpl.java:119) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:59) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:50) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at com.google.common.collect.ComputingConcurrentHashMap$ComputingValueReference.compute(ComputingConcurrentHashMap.java:355)
> 	at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.compute(ComputingConcurrentHashMap.java:184)
> 	at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.getOrCompute(ComputingConcurrentHashMap.java:153)
> 	at com.google.common.collect.ComputingConcurrentHashMap.getOrCompute(ComputingConcurrentHashMap.java:69)
> 	at com.google.common.collect.ComputingConcurrentHashMap$ComputingMapAdapter.get(ComputingConcurrentHashMap.java:393)
> 	at org.jboss.weld.resources.ClassTransformer.loadClass(ClassTransformer.java:163) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	... 12 more
> Caused by: java.lang.ClassNotFoundException: org.apache.http.client.methods.HttpUriRequest from [Module "deployment.stateful.war:main" from Service Module Loader]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:423)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)
> 	... 30 more
> 13:57:14,560 INFO  [org.jboss.weld.ClassLoading] (MSC service thread 1-4) WELD-000119 Not generating any bean definitions from org.jboss.as.test.clustering.NodeUtil because of underlying class loading error
> 13:57:14,564 INFO  [org.jboss.weld.ClassLoading] (MSC service thread 1-4) catching: org.jboss.weld.resources.spi.ResourceLoadingException: Error loading class org.jboss.as.test.clustering.NodeUtil
> 	at org.jboss.weld.resources.ClassTransformer.loadClass(ClassTransformer.java:167) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.bootstrap.BeanDeployer.loadWeldClass(BeanDeployer.java:108) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:79) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.bootstrap.BeanDeployer.addClasses(BeanDeployer.java:123) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.bootstrap.BeanDeployment.createBeans(BeanDeployment.java:184) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:350) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.as.weld.WeldContainer.start(WeldContainer.java:82) [jboss-as-weld-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.weld.services.WeldService.start(WeldService.java:76) [jboss-as-weld-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
> 	at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> Caused by: java.lang.NoClassDefFoundError: org/jboss/arquillian/container/test/api/ContainerController
> 	at java.lang.Class.getDeclaredMethods0(Native Method) [rt.jar:1.6.0_29]
> 	at java.lang.Class.privateGetDeclaredMethods(Class.java:2427) [rt.jar:1.6.0_29]
> 	at java.lang.Class.getDeclaredMethods(Class.java:1791) [rt.jar:1.6.0_29]
> 	at org.jboss.weld.util.reflection.SecureReflections$8.work(SecureReflections.java:175) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.util.reflection.SecureReflections$8.work(SecureReflections.java:172) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:52) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.util.reflection.SecureReflectionAccess.runAndWrap(SecureReflectionAccess.java:63) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.util.reflection.SecureReflections.getDeclaredMethods(SecureReflections.java:172) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.introspector.jlr.WeldClassImpl.<init>(WeldClassImpl.java:234) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.introspector.jlr.WeldClassImpl.of(WeldClassImpl.java:119) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:59) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:50) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at com.google.common.collect.ComputingConcurrentHashMap$ComputingValueReference.compute(ComputingConcurrentHashMap.java:355)
> 	at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.compute(ComputingConcurrentHashMap.java:184)
> 	at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.getOrCompute(ComputingConcurrentHashMap.java:153)
> 	at com.google.common.collect.ComputingConcurrentHashMap.getOrCompute(ComputingConcurrentHashMap.java:69)
> 	at com.google.common.collect.ComputingConcurrentHashMap$ComputingMapAdapter.get(ComputingConcurrentHashMap.java:393)
> 	at org.jboss.weld.resources.ClassTransformer.loadClass(ClassTransformer.java:163) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	... 12 more
> Caused by: java.lang.ClassNotFoundException: org.jboss.arquillian.container.test.api.ContainerController from [Module "deployment.stateful.war:main" from Service Module Loader]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:423)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)
> 	... 30 more
> 13:57:14,596 INFO  [org.jboss.weld.ClassLoading] (MSC service thread 1-4) WELD-000119 Not generating any bean definitions from org.jboss.as.test.clustering.DMRUtil because of underlying class loading error
> 13:57:14,597 INFO  [org.jboss.weld.ClassLoading] (MSC service thread 1-4) catching: org.jboss.weld.resources.spi.ResourceLoadingException: Error loading class org.jboss.as.test.clustering.DMRUtil
> 	at org.jboss.weld.resources.ClassTransformer.loadClass(ClassTransformer.java:167) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.bootstrap.BeanDeployer.loadWeldClass(BeanDeployer.java:108) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:79) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.bootstrap.BeanDeployer.addClasses(BeanDeployer.java:123) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.bootstrap.BeanDeployment.createBeans(BeanDeployment.java:184) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:350) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.as.weld.WeldContainer.start(WeldContainer.java:82) [jboss-as-weld-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.weld.services.WeldService.start(WeldService.java:76) [jboss-as-weld-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
> 	at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> Caused by: java.lang.NoClassDefFoundError: org/jboss/dmr/ModelNode
> 	at java.lang.Class.getDeclaredMethods0(Native Method) [rt.jar:1.6.0_29]
> 	at java.lang.Class.privateGetDeclaredMethods(Class.java:2427) [rt.jar:1.6.0_29]
> 	at java.lang.Class.getDeclaredMethods(Class.java:1791) [rt.jar:1.6.0_29]
> 	at org.jboss.weld.util.reflection.SecureReflections$8.work(SecureReflections.java:175) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.util.reflection.SecureReflections$8.work(SecureReflections.java:172) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:52) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.util.reflection.SecureReflectionAccess.runAndWrap(SecureReflectionAccess.java:63) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.util.reflection.SecureReflections.getDeclaredMethods(SecureReflections.java:172) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.introspector.jlr.WeldClassImpl.<init>(WeldClassImpl.java:234) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.introspector.jlr.WeldClassImpl.of(WeldClassImpl.java:119) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:59) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:50) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at com.google.common.collect.ComputingConcurrentHashMap$ComputingValueReference.compute(ComputingConcurrentHashMap.java:355)
> 	at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.compute(ComputingConcurrentHashMap.java:184)
> 	at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.getOrCompute(ComputingConcurrentHashMap.java:153)
> 	at com.google.common.collect.ComputingConcurrentHashMap.getOrCompute(ComputingConcurrentHashMap.java:69)
> 	at com.google.common.collect.ComputingConcurrentHashMap$ComputingMapAdapter.get(ComputingConcurrentHashMap.java:393)
> 	at org.jboss.weld.resources.ClassTransformer.loadClass(ClassTransformer.java:163) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	... 12 more
> Caused by: java.lang.ClassNotFoundException: org.jboss.dmr.ModelNode from [Module "deployment.stateful.war:main" from Service Module Loader]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:423)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)
> 	... 30 more
> 13:57:14,661 WARN  [org.jgroups.protocols.UDP] (ServerService Thread Pool -- 28) send buffer of socket java.net.DatagramSocket at 475b73eb was set to 640KB, but the OS only allocated 131.07KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 13:57:14,663 WARN  [org.jgroups.protocols.UDP] (ServerService Thread Pool -- 28) receive buffer of socket java.net.DatagramSocket at 475b73eb was set to 20MB, but the OS only allocated 131.07KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 13:57:14,663 WARN  [org.jgroups.protocols.UDP] (ServerService Thread Pool -- 28) send buffer of socket java.net.MulticastSocket at 3865db85 was set to 640KB, but the OS only allocated 131.07KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> 13:57:14,664 WARN  [org.jgroups.protocols.UDP] (ServerService Thread Pool -- 28) receive buffer of socket java.net.MulticastSocket at 3865db85 was set to 25MB, but the OS only allocated 131.07KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 13:57:14,669 INFO  [stdout] (ServerService Thread Pool -- 28) 
> 13:57:14,669 INFO  [stdout] (ServerService Thread Pool -- 28) -------------------------------------------------------------------
> 13:57:14,670 INFO  [stdout] (ServerService Thread Pool -- 28) GMS: address=node-1/ejb, cluster=ejb, physical address=127.0.0.1:55300
> 13:57:14,670 INFO  [stdout] (ServerService Thread Pool -- 28) -------------------------------------------------------------------
> 13:57:14,780 INFO  [org.jboss.as.clustering] (ViewHandler,ejb,node-0/ejb) JBAS010225: New cluster view for partition ejb (id: 3, delta: 1, merge: false) : [node-0/ejb, node-1/ejb]
> 13:57:14,781 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ViewHandler,ejb,node-0/ejb) ISPN000094: Received new cluster view: [node-0/ejb|3] [node-0/ejb, node-1/ejb]
> 13:57:14,792 INFO  [stdout] (ServerService Thread Pool -- 27) 
> 13:57:14,793 INFO  [stdout] (ServerService Thread Pool -- 27) -------------------------------------------------------------------
> 13:57:14,793 INFO  [stdout] (ServerService Thread Pool -- 27) GMS: address=node-1/web, cluster=web, physical address=127.0.0.1:55300
> 13:57:14,794 INFO  [stdout] (ServerService Thread Pool -- 27) -------------------------------------------------------------------
> 13:57:14,874 INFO  [org.jboss.as.clustering] (ViewHandler,web,node-0/web) JBAS010225: New cluster view for partition web (id: 3, delta: 1, merge: false) : [node-0/web, node-1/web]
> 13:57:14,875 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ViewHandler,web,node-0/web) ISPN000094: Received new cluster view: [node-0/web|3] [node-0/web, node-1/web]
> 13:57:14,991 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 27) ISPN000078: Starting JGroups Channel
> 13:57:14,992 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 26) ISPN000078: Starting JGroups Channel
> 13:57:15,004 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 27) ISPN000094: Received new cluster view: [node-0/web|3] [node-0/web, node-1/web]
> 13:57:15,004 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 26) ISPN000094: Received new cluster view: [node-0/ejb|3] [node-0/ejb, node-1/ejb]
> 13:57:15,006 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 27) ISPN000079: Cache local address is node-1/web, physical addresses are [127.0.0.1:55300]
> 13:57:15,006 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 26) ISPN000079: Cache local address is node-1/ejb, physical addresses are [127.0.0.1:55300]
> 13:57:15,015 INFO  [org.infinispan.factories.GlobalComponentRegistry] (ServerService Thread Pool -- 27) ISPN000128: Infinispan version: Infinispan 'Brahma' 5.1.5.FINAL
> 13:57:15,016 INFO  [org.infinispan.config.ConfigurationValidatingVisitor] (ServerService Thread Pool -- 27) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> 13:57:15,316 INFO  [org.infinispan.config.ConfigurationValidatingVisitor] (ServerService Thread Pool -- 25) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> 13:57:15,408 INFO  [org.infinispan.jmx.CacheJmxRegistration] (ServerService Thread Pool -- 26) ISPN000031: MBeans were successfully registered to the platform mbean server.
> 13:57:15,426 INFO  [org.infinispan.jmx.CacheJmxRegistration] (ServerService Thread Pool -- 28) ISPN000031: MBeans were successfully registered to the platform mbean server.
> 13:57:15,445 INFO  [org.infinispan.jmx.CacheJmxRegistration] (ServerService Thread Pool -- 25) ISPN000031: MBeans were successfully registered to the platform mbean server.
> 13:57:15,448 INFO  [org.infinispan.jmx.CacheJmxRegistration] (ServerService Thread Pool -- 27) ISPN000031: MBeans were successfully registered to the platform mbean server.
> 13:57:15,653 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 25) JBAS010281: Started default-host/stateful cache from web container
> 13:57:15,655 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 27) JBAS010281: Started repl cache from web container
> 13:57:15,664 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 28) JBAS010281: Started repl cache from ejb container
> 13:57:15,696 INFO  [org.jboss.as.clustering] (MSC service thread 1-2) JBAS010238: Number of cluster members: 2
> 13:57:15,695 INFO  [org.jboss.as.clustering] (MSC service thread 1-5) JBAS010238: Number of cluster members: 2
> 13:57:15,787 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 26) JBAS010281: Started remote-connector-client-mappings cache from ejb container
> 13:57:15,938 INFO  [org.infinispan.jmx.CacheJmxRegistration] (MSC service thread 1-6) ISPN000031: MBeans were successfully registered to the platform mbean server.
> 13:57:15,970 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-6) JBAS010281: Started org.jboss.as.test.clustering.cluster.ejb3.stateful.bean.NestedBean cache from ejb container
> 13:57:15,979 INFO  [org.infinispan.jmx.CacheJmxRegistration] (MSC service thread 1-3) ISPN000031: MBeans were successfully registered to the platform mbean server.
> 13:57:16,025 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-3) JBAS010281: Started org.jboss.as.test.clustering.cluster.ejb3.stateful.bean.StatefulBean cache from ejb container
> 13:57:16,074 INFO  [org.jboss.web] (MSC service thread 1-3) JBAS018210: Register web context: /stateful
> 13:57:16,120 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-3) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> 13:57:16,137 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-3) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> 13:57:16,138 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-3) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> 13:57:16,139 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-3) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> 13:57:16,491 INFO  [org.jboss.as.server] (management-handler-thread - 2) JBAS018559: Deployed "stateful.war"
> 13:57:17,858 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host]] (http-/127.0.0.1:8180-1) Exception sending request initialized lifecycle event to listener instance of class org.jboss.weld.servlet.WeldListener: java.lang.NullPointerException
> 	at org.jboss.as.web.session.ClusteredSession.update(ClusteredSession.java:972) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.DistributableSessionManager.loadSession(DistributableSessionManager.java:1377) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.DistributableSessionManager.findSession(DistributableSessionManager.java:673) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.session.DistributableSessionManager.findSession(DistributableSessionManager.java:84) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.connector.Request.doGetSession(Request.java:2618) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.catalina.connector.Request.getSession(Request.java:2375) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:841) [jbossweb-7.0.16.Final.jar:]
> 	at org.jboss.weld.context.beanstore.http.LazySessionBeanStore.getSession(LazySessionBeanStore.java:72) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.context.beanstore.http.LazySessionBeanStore.<init>(LazySessionBeanStore.java:58) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:31) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:16) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.jboss.weld.servlet.WeldListener.requestInitialized(WeldListener.java:134) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:143) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:679) [jbossweb-7.0.16.Final.jar:]
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931) [jbossweb-7.0.16.Final.jar:]
> 	at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> 13:57:17,939 INFO  [org.jboss.web] (MSC service thread 1-3) JBAS018224: Unregister web context: /stateful
> 13:57:18,021 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 59) ISPN000029: Passivating all entries to disk
> 13:57:18,021 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 58) ISPN000029: Passivating all entries to disk
> 13:57:18,022 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-4) ISPN000029: Passivating all entries to disk
> 13:57:18,027 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-4) ISPN000030: Passivated 0 entries in 5 milliseconds
> 13:57:18,032 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 59) ISPN000030: Passivated 1 entries in 11 milliseconds
> 13:57:18,041 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 58) ISPN000030: Passivated 1 entries in 19 milliseconds
> 13:57:18,047 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 59) JBAS010282: Stopped org.jboss.as.test.clustering.cluster.ejb3.stateful.bean.NestedBean cache from ejb container
> 13:57:18,049 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-4) JBAS010282: Stopped default-host/stateful cache from web container
> 13:57:18,064 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 58) JBAS010282: Stopped org.jboss.as.test.clustering.cluster.ejb3.stateful.bean.StatefulBean cache from ejb container
> 13:57:18,076 INFO  [org.jboss.weld.deployer] (MSC service thread 1-3) JBAS016009: Stopping weld service for deployment stateful.war
> 13:57:18,136 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-3) ISPN000029: Passivating all entries to disk
> 13:57:18,140 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-3) ISPN000030: Passivated 0 entries in 4 milliseconds
> 13:57:18,150 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-5) ISPN000029: Passivating all entries to disk
> 13:57:18,168 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-3) JBAS010282: Stopped repl cache from web container
> 13:57:18,203 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-2) JBAS010282: Stopped remote-connector-client-mappings cache from ejb container
> 13:57:18,221 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-5) ISPN000030: Passivated 1 entries in 70 milliseconds
> 13:57:18,231 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-6) JBAS015877: Stopped deployment stateful.war in 318ms
> 13:57:18,234 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-5) JBAS010282: Stopped repl cache from ejb container
> 13:57:18,706 INFO  [org.jboss.as.clustering] (Incoming-2,null) JBAS010225: New cluster view for partition ejb (id: 4, delta: -1, merge: false) : [node-1/ejb]
> 13:57:18,709 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-2,null) ISPN000094: Received new cluster view: [node-1/ejb|4] [node-1/ejb]
> 13:57:18,828 INFO  [org.jboss.as.clustering] (Incoming-3,null) JBAS010225: New cluster view for partition web (id: 4, delta: -1, merge: false) : [node-1/web]
> 13:57:18,830 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-3,null) ISPN000094: Received new cluster view: [node-1/web|4] [node-1/web]
> 13:57:19,482 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000082: Stopping the RpcDispatcher
> 13:57:19,498 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000082: Stopping the RpcDispatcher
> 13:57:19,533 INFO  [org.jboss.as.repository] (management-handler-thread - 5) JBAS014901: Content removed from location /home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-0/standalone/data/content/d3/a10a6a1365e0e65c637fe0eb4722ef2f866d59/content
> 13:57:19,534 INFO  [org.jboss.as.server] (management-handler-thread - 5) JBAS018558: Undeployed "stateful.war"
> 13:57:19,536 INFO  [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual stopping of a server instance
> 13:57:19,773 INFO  [org.jboss.web] (MSC service thread 1-4) JBAS018224: Unregister web context: /stateful
> 13:57:19,810 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 28) ISPN000029: Passivating all entries to disk
> 13:57:19,813 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-3) ISPN000029: Passivating all entries to disk
> 13:57:19,810 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 25) ISPN000029: Passivating all entries to disk
> 13:57:19,832 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 25) ISPN000030: Passivated 1 entries in 21 milliseconds
> 13:57:19,832 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 28) ISPN000030: Passivated 1 entries in 21 milliseconds
> 13:57:19,839 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 25) JBAS010282: Stopped org.jboss.as.test.clustering.cluster.ejb3.stateful.bean.StatefulBean cache from ejb container
> 13:57:19,839 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 28) JBAS010282: Stopped org.jboss.as.test.clustering.cluster.ejb3.stateful.bean.NestedBean cache from ejb container
> 13:57:19,848 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-3) ISPN000030: Passivated 1 entries in 35 milliseconds
> 13:57:19,855 INFO  [org.jboss.weld.deployer] (MSC service thread 1-2) JBAS016009: Stopping weld service for deployment stateful.war
> 13:57:19,874 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-3) JBAS010282: Stopped default-host/stateful cache from web container
> 13:57:19,900 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-5) ISPN000029: Passivating all entries to disk
> 13:57:19,900 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-5) ISPN000030: Passivated 0 entries in 0 milliseconds
> 13:57:19,906 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-5) JBAS010282: Stopped repl cache from web container
> 13:57:19,922 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-6) ISPN000029: Passivating all entries to disk
> 13:57:19,920 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-4) JBAS010282: Stopped remote-connector-client-mappings cache from ejb container
> 13:57:19,935 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015877: Stopped deployment stateful.war in 174ms
> 13:57:19,936 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-6) ISPN000030: Passivated 1 entries in 14 milliseconds
> 13:57:19,941 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-6) JBAS010282: Stopped repl cache from ejb container
> 13:57:20,232 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000082: Stopping the RpcDispatcher
> 13:57:20,325 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000082: Stopping the RpcDispatcher
> 13:57:20,377 INFO  [org.jboss.as.repository] (management-handler-thread - 3) JBAS014901: Content removed from location /home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-1/standalone/data/content/33/a062483bafd997e0d3374cfa764aeb07874c01/content
> 13:57:20,378 INFO  [org.jboss.as.server] (management-handler-thread - 3) JBAS018558: Undeployed "stateful.war"
> 13:57:20,380 INFO  [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual stopping of a server instance

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Fri Oct  4 17:42:51 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-29) An ear file with modules in
 subfolders can not deploy under AS 7.0
In-Reply-To: <JIRA.12449097.1318316227000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12449097.1318316227000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12449097.1318316227000.15607.1380922971233@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-29:
-----------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> An ear file with modules in subfolders can not deploy under AS 7.0
> ------------------------------------------------------------------
>
>                 Key: WFLY-29
>                 URL: https://issues.jboss.org/browse/WFLY-29
>             Project: WildFly
>          Issue Type: Bug
>          Components: EE
>            Reporter: Adrian Zuo
>            Assignee: David Lloyd
>             Fix For: 8.0.0.CR1
>
>         Attachments: migrate.ear, migrate.ear
>
>
> I have an ear file names migrate.ear which contains one ejb jar (ejb.jar) and one war file (war.war), if I put the ejb jar to a ejb folder and war file to war folder, the ear can not be depoyed.
> If I move the ejb jar and war file out, it can be deployed. 
> Below  structuer can be deployed:
> ejb.jar
> lib/
> lib/util-1.0-SNAPSHOT.jar
> lib/version.jar
> META-INF/
> META-INF/application.xml
> META-INF/MANIFEST.MF
> war.war
>  
> Below structure can not be deployed:
> ejb/
> ejb/ejb.jar
> lib/
> lib/util-1.0-SNAPSHOT.jar
> lib/version.jar
> META-INF/
> META-INF/application.xml
> META-INF/MANIFEST.MF
> war/
> war/war.war
> Below is the error:
> http://community.jboss.org/message/630869#630869

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:52 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8) [PassivateTask] null:
 java.lang.NullPointerException
In-Reply-To: <JIRA.12487456.1363639726000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12487456.1363639726000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487456.1363639726000.15629.1380922972170@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-8:
----------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> [PassivateTask] null: java.lang.NullPointerException
> ----------------------------------------------------
>
>                 Key: WFLY-8
>                 URL: https://issues.jboss.org/browse/WFLY-8
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, EJB
>            Reporter: Radoslav Husar
>            Assignee: Paul Ferraro
>             Fix For: 8.0.0.CR1
>
>         Attachments: server.log
>
>
> Going through the server logs from clustering testsuite suspicious NPE on INFO caught my eye. Seems like an edge case not being covered.
> Affected version: master 8a6aac3c8eb6bc94b7eddfa4d090c9ac05c7e37b
> {code}
> 15:10:57,385 INFO  [org.jboss.as.ejb3.cache.spi.impl.PassivateTask] (pool-17-thread-1) null: java.lang.NullPointerException
>         at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.prePassivate(StatefulSessionComponent.java:157) [jboss-as-ejb3-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
>         at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.prePassivate(StatefulSessionComponent.java:73) [jboss-as-ejb3-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
>         at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberContainer.prePassivate(SerializationGroupMemberContainer.java:165) [jboss-as-ejb3-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
>         at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberContainer.prePassivate(SerializationGroupMemberContainer.java:51) [jboss-as-ejb3-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
>         at org.jboss.as.ejb3.cache.impl.backing.PassivatingBackingCacheImpl.passivate(PassivatingBackingCacheImpl.java:189) [jboss-as-ejb3-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
>         at org.jboss.as.ejb3.cache.impl.backing.PassivatingBackingCacheImpl.passivate(PassivatingBackingCacheImpl.java:60) [jboss-as-ejb3-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
>         at org.jboss.as.ejb3.cache.spi.impl.PassivateTask.run(PassivateTask.java:46) [jboss-as-ejb3-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_17]
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_17]
>         at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_17]
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) [rt.jar:1.7.0_17]
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) [rt.jar:1.7.0_17]
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
>         at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:51 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-19) JMX over remoting pollutes
 query results with ModelController objects
In-Reply-To: <JIRA.12477448.1350636455000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12477448.1350636455000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12477448.1350636455000.15612.1380922971422@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-19?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-19:
-----------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> JMX over remoting pollutes query results with ModelController objects
> ---------------------------------------------------------------------
>
>                 Key: WFLY-19
>                 URL: https://issues.jboss.org/browse/WFLY-19
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, JMX
>            Reporter: NadirX
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.CR1
>
>
> When issuing MBean queries over JMX remoting, the AS is returning a list of org.jboss.as.controller.ModelController objects in addition to those matching the query.
> This is a transcript of a chat we had about it on IRC:
> Oct 15 14:51:46 <ttarrant>      darranl, if I issue a jmx query over jmx-remoting I get many more objects than expected
> Oct 15 14:51:55 <ttarrant>      darranl, i.e. ones that do not match the query
> Oct 15 14:52:09 <ttarrant>      darranl, this is with 7.1.x
> Oct 15 14:52:57 <ttarrant>      darranl, this works if I use the standard JMX over RMI
> Oct 15 14:53:08 -->     fnasser (~fnasser at CPE602ad07ab726-CM602ad07ab723.cpe.net.cable.rogers.com) has joined #jboss-as7
> Oct 15 14:53:09 <--     fnasser has quit (Changing host)
> Oct 15 14:53:09 -->     fnasser (~fnasser at redhat/jboss/fnasser) has joined #jboss-as7
> Oct 15 14:53:09 ---     ChanServ gives voice to fnasser
> Oct 15 14:53:16 <ttarrant>      darranl, do you just pass the query the the mbeanserver ?
> Oct 15 14:53:39 <darranl>       ttarrant: what kind of objects? within AS7 I think there are two things that could affec
> t this 1 - The Remoting JMX protocol, 2 - The domain management representation over JMX
> Oct 15 14:53:54 <darranl>       For #1 yes we just pass it to the MBEanServer and return whatever it returns
> Oct 15 14:54:04 <darranl>       if it was a Remoting JMX bug maybe we are messing up the query
> Oct 15 14:54:16 <ttarrant>      darranl, the query is as follows: *:type=CacheManager,component=Interpreter,name=*
> Oct 15 14:54:16 <darranl>       But not sure if #2 could be the reason more is getting added
> Oct 15 14:54:32 <ttarrant>      darranl, wait a sec
> Oct 15 14:54:57 <darranl>       ttarrant: I would suggest getting a Jira raised and assigned to me, I can verify if it i
> s a remoting jmx issue or pass over if it is a domain management integration issue
> Oct 15 14:55:20 <darranl>       regardless of where it is happenign it sounds like you may have discovered a bug 
> Oct 15 14:56:23 <ttarrant>      darranl, let me get the objects it's returning
> Oct 15 14:56:39 <darranl>       ttarrant: when you enable the RMI approach you bypass both Remoting JMX AND the domain m
> anagement integration 
> Oct 15 14:56:42 <darranl>       ok
> Oct 15 15:26:08 <ttarrant>      darranl, ok, my query actually returns the object I queried for and a bunch of org.jboss.as.controller.ModelController (one for each subsystem)
> Oct 15 15:51:24 <darranl>       ttarrant: ok that does then sound like it is the domain management integration that is 'poluting' the query results 
> Oct 15 15:51:53 <darranl>       ttarrant: going RMI was just bypassing that as well 
> Oct 15 15:52:05 <ttarrant>      darranl, shall I open a Jira ?
> Oct 15 15:52:34 <ttarrant>      darranl, I work around the issue by manually filtering the returned objects based on class name
> Oct 15 15:53:23 <darranl>       ttarrant:  it would probably be one for kkhan to look into, think he is just back today so may be worth the Jira so he can have a look once he has caught back up ;-)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct  4 17:42:51 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-12) Replication of attribute
 changed in @PrePassivate method does not work for nested beans
In-Reply-To: <JIRA.12462276.1332435874000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12462276.1332435874000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12462276.1332435874000.15622.1380922971878@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-12?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-12:
-----------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Replication of attribute changed in @PrePassivate method does not work for nested beans
> ---------------------------------------------------------------------------------------
>
>                 Key: WFLY-12
>                 URL: https://issues.jboss.org/browse/WFLY-12
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, EJB
>            Reporter: Ond?ej Chaloupka
>            Assignee: Paul Ferraro
>             Fix For: 8.0.0.CR1
>
>
> In case that a sfsb nested bean (a stateful bean which is injected into other bean in this case into a clustered bean) changes its attribute (member variable) in @PrePassivate method then the new state is not replicated to other nodes.
> You can check my testcase:
> https://github.com/ochaloup/jboss-as/blob/67f992608bacc2bce95b0d7655083a83e70367e0/testsuite/integration/clust/src/test/java/org/jboss/as/test/clustering/cluster/ejb3/stateful/passivation/ClusterPassivationTestCase.java
> The steps done in tests are following:
> 1) Search for stateful bean (a "parent" bean for the nested one, bean where the nested one is injected to)
> 2) Let the stateful bean be passivated (in this time the nested bean is passivated as well, the @PrePassivate method is called)
> 3) A variable of the nested bean is changed in the @PrePassivate method
> 4) Do a call on second node - changed state isn't on the other node
> You can check it in the linked test. When no method on nested been is called (the call is commented now):
> https://github.com/ochaloup/jboss-as/blob/67f992608bacc2bce95b0d7655083a83e70367e0/testsuite/integration/clust/src/test/java/org/jboss/as/test/clustering/cluster/ejb3/stateful/passivation/ClusterPassivationTestCase.java#L305
> Then the test on the changed attribute fails on the other server:
> https://github.com/ochaloup/jboss-as/blob/67f992608bacc2bce95b0d7655083a83e70367e0/testsuite/integration/clust/src/test/java/org/jboss/as/test/clustering/cluster/ejb3/stateful/passivation/ClusterPassivationTestCase.java#L318

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Fri Oct  4 17:42:51 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Fri, 4 Oct 2013 17:42:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-16) Intermittent failure in
 RemoteOutboundConnectionReconnectTestCase
In-Reply-To: <JIRA.12473474.1346412534000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12473474.1346412534000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12473474.1346412534000.15616.1380922971581@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-16:
-----------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Intermittent failure in RemoteOutboundConnectionReconnectTestCase
> -----------------------------------------------------------------
>
>                 Key: WFLY-16
>                 URL: https://issues.jboss.org/browse/WFLY-16
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>            Reporter: Kabir Khan
>            Assignee: jaikiran pai
>            Priority: Critical
>             Fix For: 8.0.0.CR1
>
>
> Assigning to Jaikiran since I think this is ejb client
> This happened for IPv6 but I don't know if that has any relevance.
> The test has not been disabled
> {code}
> org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteOutboundConnectionReconnectTestCase.testRemoteServerRestarts
> Failing for the past 1 build (Since #3674 )
> Took 8.7 sec.
> add description
> Error Message
> Cannot deploy: server-two-module.jar
> Stacktrace
> org.jboss.arquillian.container.spi.client.container.DeploymentException: Cannot deploy: server-two-module.jar
>      at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:83)
>      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:145)
>      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:39)
>      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>      at java.lang.reflect.Method.invoke(Method.java:597)
>      at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>      at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
>      at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
>      at org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50)
>      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>      at java.lang.reflect.Method.invoke(Method.java:597)
>      at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>      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:39)
>      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>      at java.lang.reflect.Method.invoke(Method.java:597)
>      at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>      at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
>      at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57)
>      at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
>      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>      at java.lang.reflect.Method.invoke(Method.java:597)
>      at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>      at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
>      at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
>      at org.jboss.arquillian.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.deployment.ClientDeployer.deploy(ClientDeployer.java:93)
>      at org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteOutboundConnectionReconnectTestCase.testRemoteServerRestarts(RemoteOutboundConnectionReconnectTestCase.java:199)
>      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>      at java.lang.reflect.Method.invoke(Method.java:597)
>      at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
>      at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
>      at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
>      at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:270)
>      at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
>      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>      at java.lang.reflect.Method.invoke(Method.java:597)
>      at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>      at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
>      at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
>      at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
>      at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
>      at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
>      at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:53)
>      at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
>      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>      at java.lang.reflect.Method.invoke(Method.java:597)
>      at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>      at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
>      at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
>      at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
>      at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129)
>      at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
>      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>      at java.lang.reflect.Method.invoke(Method.java:597)
>      at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>      at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
>      at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89)
>      at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
>      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>      at java.lang.reflect.Method.invoke(Method.java:597)
>      at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>      at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
>      at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
>      at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
>      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>      at java.lang.reflect.Method.invoke(Method.java:597)
>      at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>      at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
>      at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
>      at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
>      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>      at java.lang.reflect.Method.invoke(Method.java:597)
>      at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>      at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
>      at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
>      at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111)
>      at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263)
>      at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226)
>      at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
>      at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
>      at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240)
>      at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
>      at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
>      at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
>      at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
>      at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
>      at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
>      at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
>      at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
>      at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185)
>      at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
>      at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
>      at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
>      at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
>      at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
>      at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234)
>      at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133)
>      at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114)
>      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>      at java.lang.reflect.Method.invoke(Method.java:597)
>      at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188)
>      at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166)
>      at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
>      at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101)
>      at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
> Caused by: java.lang.Exception: {"JBAS014771: Services with missing/unavailable dependencies" => [
>     "jboss.naming.context.java.app.server-two-module.server-two-module.EchoOnServerTwo Missing[JBAS014861: <one or more transitive dependencies>]",
>     "jboss.naming.context.java.global.server-two-module.\"EchoOnServerTwo!org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteEcho\" Missing[JBAS014861: <one or more transitive dependencies>]",
>     "jboss.deployment.unit.\"server-two-module.jar\".component.EchoOnServerTwo.VIEW.\"org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteEcho\".REMOTE Missing[JBAS014861: <one or more transitive dependencies>]",
>     "jboss.deployment.unit.\"server-two-module.jar\".deploymentCompleteService Missing[JBAS014861: <one or more transitive dependencies>]",
>     "jboss.naming.context.java.module.server-two-module.server-two-module.\"EchoOnServerTwo!org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteEcho\" Missing[JBAS014861: <one or more transitive dependencies>]",
>     "jboss.deployment.unit.\"server-two-module.jar\".component.EchoOnServerTwo.START Missing[JBAS014861: <one or more transitive dependencies>]",
>     "jboss.deployment.unit.\"server-two-module.jar\".moduleDeploymentRuntimeInformation Missing[JBAS014861: <one or more transitive dependencies>]",
>     "jboss.naming.context.java.module.server-two-module.server-two-module.EchoOnServerTwo Missing[JBAS014861: <one or more transitive dependencies>]",
>     "jboss.naming.context.java.app.server-two-module.server-two-module.\"EchoOnServerTwo!org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteEcho\" Missing[JBAS014861: <one or more transitive dependencies>]",
>     "jboss.deployment.unit.\"server-two-module.jar\".jndiDependencyService Missing[JBAS014861: <one or more transitive dependencies>]",
>     "jboss.naming.context.java.global.server-two-module.EchoOnServerTwo Missing[JBAS014861: <one or more transitive dependencies>]"
> ]}
>      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:52)
>      at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:77)
>      ... 123 more
> Standard Output
> 02:31:11,030 INFO  [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual starting of a server instance
> 02:31:11,053 INFO  [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Starting container with: [/opt/jdk1.6.0_29/bin/java, -Xmx512m, -XX:MaxPermSize=256m, -Djboss.dist=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/../../../build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT, -Djava.net.preferIPv4Stack=false, -Djava.net.preferIPv6Addresses=true, -Dts.timeout.factor=100, -Dnode0=::1, -Dnode1=fccc::2, -Dmcast=ff01::1, -Djbossas.ts.submodule.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode, -Djbossas.ts.integ.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/.., -Djbossas.ts.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/../.., -Djbossas.project.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/../../.., -Djboss.dist=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/../../../build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT, -Djboss.inst=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/target/jbossas, -Djboss.node.name=default-jbossas, -ea, -Djboss.home.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/target/jbossas, -Dorg.jboss.boot.log.file=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/target/jbossas/standalone/log/boot.log, -Dlogging.configuration=file:/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/target/jbossas/standalone/configuration/logging.properties, -Djboss.bundles.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/../../../build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT/bundles, -jar, /home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/target/jbossas/jboss-modules.jar, -mp, /home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/../../../build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT/modules:/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/target/modules, -jaxpmodule, javax.xml.jaxp-provider, org.jboss.as.standalone, -server-config, standalone-ha.xml]
> 02:31:11,906 INFO  [org.jboss.modules] JBoss Modules version 1.1.3.GA
> 02:31:12,166 INFO  [org.jboss.msc] JBoss MSC version 1.0.2.GA
> 02:31:12,257 INFO  [org.jboss.as] JBAS015899: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" starting
> 02:31:14,791 INFO  [org.jboss.as.server] JBAS015888: Creating http management service using socket-binding (management-http)
> 02:31:14,798 INFO  [org.xnio] XNIO Version 3.0.5.GA
> 02:31:14,827 INFO  [org.xnio.nio] XNIO NIO Implementation Version 3.0.5.GA
> 02:31:14,848 INFO  [org.jboss.as.configadmin] JBAS016200: Activating ConfigAdmin Subsystem
> 02:31:14,849 INFO  [org.jboss.as.logging] JBAS011502: Removing bootstrap log handlers
> &#27;[0m02:31:14,889 INFO  [org.jboss.remoting] (MSC service thread 1-3) JBoss Remoting version 3.2.8.GA
> &#27;[0m&#27;[0m02:31:14,916 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 34) JBAS010280: Activating Infinispan subsystem.
> &#27;[0m&#27;[0m02:31:14,979 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 38) JBAS010260: Activating JGroups subsystem.
> &#27;[0m&#27;[0m02:31:14,991 INFO  [org.jboss.as.osgi] (ServerService Thread Pool -- 45) JBAS011906: Activating OSGi Subsystem
> &#27;[0m&#27;[0m02:31:15,009 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 44) JBAS011800: Activating Naming Subsystem
> &#27;[0m&#27;[0m02:31:15,015 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 50) JBAS013171: Activating Security Subsystem
> &#27;[0m&#27;[0m02:31:15,047 INFO  [org.jboss.as.security] (MSC service thread 1-1) JBAS013170: Current PicketBox version=4.0.13.Final
> &#27;[0m&#27;[0m02:31:15,161 INFO  [org.jboss.as.connector.logging] (MSC service thread 1-6) JBAS010408: Starting JCA Subsystem (JBoss IronJacamar 1.0.12.Final)
> &#27;[0m&#27;[0m02:31:15,164 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 54) JBAS015537: Activating WebServices Extension
> &#27;[0m&#27;[0m02:31:15,332 INFO  [org.jboss.as.naming] (MSC service thread 1-2) JBAS011802: Starting Naming Service
> &#27;[0m&#27;[0m02:31:15,371 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-6) JBAS015400: Bound mail session [java:jboss/mail/Default]
> &#27;[0m&#27;[31m02:31:15,331 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC00001: Failed to start service jboss.remoting.endpoint.subsystem: org.jboss.msc.service.StartException in service jboss.remoting.endpoint.subsystem: Failed to start service
>      at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1767) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>      at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
>      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
>      at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> Caused by: java.lang.NullPointerException
>      at sun.nio.ch.Util.atBugLevel(Util.java:448) [rt.jar:1.6.0_29]
>      at sun.nio.ch.SelectorImpl.<init>(SelectorImpl.java:40) [rt.jar:1.6.0_29]
>      at sun.nio.ch.EPollSelectorImpl.<init>(EPollSelectorImpl.java:47) [rt.jar:1.6.0_29]
>      at sun.nio.ch.EPollSelectorProvider.openSelector(EPollSelectorProvider.java:18) [rt.jar:1.6.0_29]
>      at java.nio.channels.Selector.open(Selector.java:209) [rt.jar:1.6.0_29]
>      at org.xnio.nio.NioXnioWorker.<init>(NioXnioWorker.java:112)
>      at org.xnio.nio.NioXnio.createWorker(NioXnio.java:126)
>      at org.jboss.remoting3.EndpointImpl.construct(EndpointImpl.java:137)
>      at org.jboss.remoting3.Remoting.createEndpoint(Remoting.java:60)
>      at org.jboss.remoting3.Remoting.createEndpoint(Remoting.java:73)
>      at org.jboss.as.remoting.EndpointService.start(EndpointService.java:71)
>      at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>      at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>      ... 3 more
> &#27;[0m&#27;[0m02:31:15,747 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 30) JBAS010403: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> &#27;[0m&#27;[0m02:31:16,070 INFO  [org.jboss.ws.common.management.AbstractServerConfig] (MSC service thread 1-3) JBoss Web Services - Stack CXF Server 4.1.0.Beta2
> &#27;[0m&#27;[0m02:31:16,117 INFO  [org.apache.coyote.ajp.AjpProtocol] (MSC service thread 1-4) Starting Coyote AJP/1.3 on ajp-/0:0:0:0:0:0:0:1%1:8009
> &#27;[0m&#27;[0m02:31:16,117 INFO  [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-5) Starting Coyote HTTP/1.1 on http-/0:0:0:0:0:0:0:1%1:8080
> &#27;[0m&#27;[0m02:31:16,357 INFO  [org.jboss.modcluster.ModClusterService] (ServerService Thread Pool -- 56) Initializing mod_cluster 1.2.1.Final
> &#27;[0m&#27;[0m02:31:16,437 INFO  [org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl] (ServerService Thread Pool -- 56) Listening to proxy advertisements on ff01:0:0:0:0:0:0:3:23,364
> &#27;[0m&#27;[0m02:31:16,718 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 34) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> &#27;[0m&#27;[0m02:31:16,742 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 34) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> &#27;[0m&#27;[0m02:31:16,908 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-3) JBAS015012: Started FileSystemDeploymentService for directory /home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/target/jbossas/standalone/deployments
> &#27;[0m&#27;[0m02:31:16,927 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015876: Starting deployment of "dep1.jar"
> &#27;[0m&#27;[0m02:31:16,960 INFO  [org.jboss.as.remoting] (MSC service thread 1-6) JBAS017100: Listening on [::1]:9999
> &#27;[0m&#27;[0m02:31:16,977 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
> &#27;[0m&#27;[0m02:31:17,615 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-2) JNDI bindings for session bean named ShutdownBean in deployment unit deployment "dep1.jar" are as follows:
>      java:global/dep1/ShutdownBean!org.jboss.as.test.manualmode.ejb.shutdown.RemoteEcho
>      java:app/dep1/ShutdownBean!org.jboss.as.test.manualmode.ejb.shutdown.RemoteEcho
>      java:module/ShutdownBean!org.jboss.as.test.manualmode.ejb.shutdown.RemoteEcho
>      java:jboss/exported/dep1/ShutdownBean!org.jboss.as.test.manualmode.ejb.shutdown.RemoteEcho
>      java:global/dep1/ShutdownBean
>      java:app/dep1/ShutdownBean
>      java:module/ShutdownBean
> &#27;[0m&#27;[0m02:31:17,617 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-2) JNDI bindings for session bean named LatchBean in deployment unit deployment "dep1.jar" are as follows:
>      java:global/dep1/LatchBean!org.jboss.as.test.manualmode.ejb.shutdown.RemoteLatch
>      java:app/dep1/LatchBean!org.jboss.as.test.manualmode.ejb.shutdown.RemoteLatch
>      java:module/LatchBean!org.jboss.as.test.manualmode.ejb.shutdown.RemoteLatch
>      java:jboss/exported/dep1/LatchBean!org.jboss.as.test.manualmode.ejb.shutdown.RemoteLatch
>      java:global/dep1/LatchBean
>      java:app/dep1/LatchBean
>      java:module/LatchBean
> &#27;[0m&#27;[0m02:31:17,619 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-2) JNDI bindings for session bean named RealEcho in deployment unit deployment "dep1.jar" are as follows:
>      java:global/dep1/RealEcho!org.jboss.as.test.manualmode.ejb.shutdown.RemoteEcho
>      java:app/dep1/RealEcho!org.jboss.as.test.manualmode.ejb.shutdown.RemoteEcho
>      java:module/RealEcho!org.jboss.as.test.manualmode.ejb.shutdown.RemoteEcho
>      java:jboss/exported/dep1/RealEcho!org.jboss.as.test.manualmode.ejb.shutdown.RemoteEcho
>      java:global/dep1/RealEcho
>      java:app/dep1/RealEcho
>      java:module/RealEcho
> &#27;[0m&#27;[0m02:31:18,940 INFO  [org.jboss.as.server] (Controller Boot Thread) JBAS018559: Deployed "dep1.jar"
> &#27;[0m&#27;[0m02:31:18,951 INFO  [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014777:   Services which failed to start:      service jboss.remoting.endpoint.subsystem: org.jboss.msc.service.StartException in service jboss.remoting.endpoint.subsystem: Failed to start service
> &#27;[0m&#27;[0m02:31:18,992 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://::1:9990/management
> &#27;[0m&#27;[0m02:31:18,994 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://::1:9990
> &#27;[0m&#27;[31m02:31:18,996 ERROR [org.jboss.as] (Controller Boot Thread) JBAS015875: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" started (with errors) in 7657ms - Started 185 of 364 services (34 services failed or missing dependencies, 144 services are passive or on-demand)
> &#27;[0m&#27;[0m02:31:19,141 INFO  [org.jboss.as.repository] (management-handler-thread - 1) JBAS014900: Content added at location /home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/target/jbossas/standalone/data/content/34/cf5c1cb3656c84a2615763b9f95b3a16536c40/content
> &#27;[0m&#27;[0m02:31:19,164 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015876: Starting deployment of "server-two-module.jar"
> &#27;[0m&#27;[0m02:31:19,227 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-1) JNDI bindings for session bean named EchoOnServerTwo in deployment unit deployment "server-two-module.jar" are as follows:
>      java:global/server-two-module/EchoOnServerTwo!org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteEcho
>      java:app/server-two-module/EchoOnServerTwo!org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteEcho
>      java:module/EchoOnServerTwo!org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteEcho
>      java:jboss/exported/server-two-module/EchoOnServerTwo!org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteEcho
>      java:global/server-two-module/EchoOnServerTwo
>      java:app/server-two-module/EchoOnServerTwo
>      java:module/EchoOnServerTwo
> &#27;[0m&#27;[0m02:31:19,578 INFO  [org.jboss.as.server] (management-handler-thread - 1) JBAS015870: Deploy of deployment "server-two-module.jar" was rolled back with failure message {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.naming.context.java.app.server-two-module.server-two-module.EchoOnServerTwo Missing[JBAS014861: <one or more transitive dependencies>]","jboss.naming.context.java.global.server-two-module.\"EchoOnServerTwo!org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteEcho\" Missing[JBAS014861: <one or more transitive dependencies>]","jboss.deployment.unit.\"server-two-module.jar\".component.EchoOnServerTwo.VIEW.\"org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteEcho\".REMOTE Missing[JBAS014861: <one or more transitive dependencies>]","jboss.deployment.unit.\"server-two-module.jar\".deploymentCompleteService Missing[JBAS014861: <one or more transitive dependencies>]","jboss.naming.context.java.module.server-two-module.server-two-module.\"EchoOnServerTwo!org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteEcho\" Missing[JBAS014861: <one or more transitive dependencies>]","jboss.deployment.unit.\"server-two-module.jar\".component.EchoOnServerTwo.START Missing[JBAS014861: <one or more transitive dependencies>]","jboss.deployment.unit.\"server-two-module.jar\".moduleDeploymentRuntimeInformation Missing[JBAS014861: <one or more transitive dependencies>]","jboss.naming.context.java.module.server-two-module.server-two-module.EchoOnServerTwo Missing[JBAS014861: <one or more transitive dependencies>]","jboss.naming.context.java.app.server-two-module.server-two-module.\"EchoOnServerTwo!org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteEcho\" Missing[JBAS014861: <one or more transitive dependencies>]","jboss.deployment.unit.\"server-two-module.jar\".jndiDependencyService Missing[JBAS014861: <one or more transitive dependencies>]","jboss.naming.context.java.global.server-two-module.EchoOnServerTwo Missing[JBAS014861: <one or more transitive dependencies>]"]}
> &#27;[0m&#27;[0m02:31:19,652 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015877: Stopped deployment server-two-module.jar in 97ms
> &#27;[0m
>  Help us localize this page Page generated: Aug 31, 2012 7:20:23 AMJenkins ver. 1.473
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Fri Oct  4 17:48:03 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 4 Oct 2013 17:48:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-674) NPE in thread "vfs-shutdown"
In-Reply-To: <JIRA.12441752.1310661101000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12441752.1310661101000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12441752.1310661101000.15651.1380923283408@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar resolved WFLY-674.
------------------------------

    Fix Version/s: 8.0.0.Beta1
                       (was: 8.0.0.CR1)
       Resolution: Done

    
> NPE in thread "vfs-shutdown" 
> -----------------------------
>
>                 Key: WFLY-674
>                 URL: https://issues.jboss.org/browse/WFLY-674
>             Project: WildFly
>          Issue Type: Bug
>          Components: VFS
>         Environment: 7.1.0.Alpha1 Jenkins build 1402
>            Reporter: Juergen Zimmermann
>            Assignee: David Lloyd
>             Fix For: 8.0.0.Beta1
>
>
> When I shutdown a standalone server I'm getting a NPE. The shutdown command is:
> jboss-admin.bat --connect command=:shutdown
> Console log:
> ...
> 18:24:55,990 INFO  [org.jboss.as.logging] Restored bootstrap log handlers
> 18:24:55,990 INFO  [org.jboss.as.jmx.JMXConnectorService] JMX remote connector stopped
> 18:24:56,075 INFO  [org.jboss.osgi.framework.internal.HostBundleState] Bundle stopped: jboss-as-osgi-configadmin:7.1.0.Alpha1-SNAPSHOT
> 18:24:56,125 INFO  [org.jboss.osgi.framework.internal.HostBundleState] Bundle stopped: org.apache.felix.log:1.0.0
> 18:24:56,230 INFO  [org.apache.catalina.core.StandardContext] Container org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/] has not been started
> 18:24:56,286 INFO  [org.jboss.osgi.framework.internal.HostBundleState] Bundle stopped: org.apache.felix.configadmin:1.2.8
> 18:24:56,323 INFO  [org.jboss.osgi.framework.internal.HostBundleState] Bundle stopped: jboss-osgi-logging:1.0.0
> 18:24:56,330 INFO  [com.arjuna.ats.jbossatx] ARJUNA32018: Destroying TransactionManagerService
> 18:24:56,331 INFO  [com.arjuna.ats.jbossatx] ARJUNA32014: Stopping transaction recovery manager
> 18:24:56,368 ERROR [stderr] Exception in thread "vfs-shutdown" java.lang.NullPointerException
> 18:24:56,368 ERROR [stderr] 	at org.jboss.vfs.TempFileProvider$DeleteTask.run(TempFileProvider.java:151)
> 18:24:56,368 ERROR [stderr] 	at org.jboss.vfs.TempFileProvider.close(TempFileProvider.java:132)
> 18:24:56,368 ERROR [stderr] 	at org.jboss.osgi.vfs30.VirtualFileAdaptor30$2.run(VirtualFileAdaptor30.java:94)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct  5 02:17:02 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Sat, 5 Oct 2013 02:17:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-287) Rule names with
 non-alphabetic characters may lead to name clashes
In-Reply-To: <JIRA.12502262.1380953728624@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502262.1380953728624@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502262.1380953728624.16197.1380953822583@jira02.app.mwc.hst.phx2.redhat.com>

Davide Sottara created DROOLS-287:
-------------------------------------

             Summary: Rule names with non-alphabetic characters may lead to name clashes
                 Key: DROOLS-287
                 URL: https://issues.jboss.org/browse/DROOLS-287
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  6.0.0.CR4, 5.5.0.Final
            Reporter: Davide Sottara
            Assignee: Mark Proctor
            Priority: Critical
             Fix For: 5.5.1.Final, 6.0.0.CR5


A KB with the two following rules will not compile:

rule "Rule_>"
when then end

rule "Rule_<"
when then end



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct  5 03:04:02 2013
From: jira-events at lists.jboss.org (Michael Furman (JIRA))
Date: Sat, 5 Oct 2013 03:04:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBAS-9549) The UDP port opened for all
 IPs in the JBoss 7 standalone configuration
In-Reply-To: <JIRA.12502263.1380956572613@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502263.1380956572613@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502263.1380956572613.16200.1380956642689@jira02.app.mwc.hst.phx2.redhat.com>

Michael Furman created JBAS-9549:
------------------------------------

             Summary: The UDP port opened for all IPs in the JBoss 7 standalone configuration
                 Key: JBAS-9549
                 URL: https://issues.jboss.org/browse/JBAS-9549
             Project: Application Server 3  4  5 and 6
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Security
            Reporter: Michael Furman
            Assignee: Anil Saldhana


The bug is for Jboss 7.1.1.Final  (I was not able to select it when I open the issue)

I launched  Jboss 7.1.1.Final on Centos6 using JDK7.

When I check what port is opened I see the following UDP port opened for all IPs:
 

netstat -ntulp

Active Internet connections (only servers)

Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name

udp        0                    0 :::43676                      :::*                                                  2460/java

 

The port is changing its value each time I restart JBoss.

Where and why the UDP port is configured?

   

I use `standalone\configuration\standalone.xml` and I can not find any UDP configuration there.

      

I still can see opened UDP port and I want to close it.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct  5 03:13:02 2013
From: jira-events at lists.jboss.org (Michael Furman (JIRA))
Date: Sat, 5 Oct 2013 03:13:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBAS-9549) The UDP port opened for all
 IPs in the JBoss 7 standalone configuration
In-Reply-To: <JIRA.12502263.1380956572000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502263.1380956572000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502263.1380956572000.16203.1380957182586@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBAS-9549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Furman updated JBAS-9549:
---------------------------------

    Description: 
The bug is for Jboss 7.1.1.Final  (I was not able to select it when I opened the issue)

I launched  Jboss 7.1.1.Final on Centos6 using JDK7.

When I check what port is opened I see the following UDP port opened for all IPs:
 

netstat -ntulp

Active Internet connections (only servers)

Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name

udp        0                    0 :::43676                      :::*                                                  2460/java

 

The port is changing its value each time I restart JBoss.

Where and why the UDP port is configured?

   

I use `standalone\configuration\standalone.xml` and I can not find any UDP configuration there.

      

I still can see opened UDP port and I want to close it.


  was:
The bug is for Jboss 7.1.1.Final  (I was not able to select it when I open the issue)

I launched  Jboss 7.1.1.Final on Centos6 using JDK7.

When I check what port is opened I see the following UDP port opened for all IPs:
 

netstat -ntulp

Active Internet connections (only servers)

Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name

udp        0                    0 :::43676                      :::*                                                  2460/java

 

The port is changing its value each time I restart JBoss.

Where and why the UDP port is configured?

   

I use `standalone\configuration\standalone.xml` and I can not find any UDP configuration there.

      

I still can see opened UDP port and I want to close it.



    
> The UDP port opened for all IPs in the JBoss 7 standalone configuration
> -----------------------------------------------------------------------
>
>                 Key: JBAS-9549
>                 URL: https://issues.jboss.org/browse/JBAS-9549
>             Project: Application Server 3  4  5 and 6
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: Michael Furman
>            Assignee: Anil Saldhana
>
> The bug is for Jboss 7.1.1.Final  (I was not able to select it when I opened the issue)
> I launched  Jboss 7.1.1.Final on Centos6 using JDK7.
> When I check what port is opened I see the following UDP port opened for all IPs:
>  
> netstat -ntulp
> Active Internet connections (only servers)
> Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name
> udp        0                    0 :::43676                      :::*                                                  2460/java
>  
> The port is changing its value each time I restart JBoss.
> Where and why the UDP port is configured?
>    
> I use `standalone\configuration\standalone.xml` and I can not find any UDP configuration there.
>       
> I still can see opened UDP port and I want to close it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct  5 03:15:03 2013
From: jira-events at lists.jboss.org (Michael Furman (JIRA))
Date: Sat, 5 Oct 2013 03:15:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBAS-9549) The UDP port opened for all
 IPs in the JBoss 7 standalone configuration
In-Reply-To: <JIRA.12502263.1380956572000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502263.1380956572000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502263.1380956572000.16206.1380957303510@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBAS-9549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Furman updated JBAS-9549:
---------------------------------

    Description: 
The bug is for Jboss 7.1.1.Final  (I was not able to select it when I opened the issue)

I launched  Jboss 7.1.1.Final on Centos6 using JDK7.

When I check what ports are opened I see the following UDP port opened for all IPs:
 

netstat -ntulp

Active Internet connections (only servers)

Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name

udp        0                    0 :::43676                      :::*                                                  2460/java

 

The port is changing its value each time I restart JBoss.

Where and why the UDP port is configured?
   

I use `standalone\configuration\standalone.xml` and I can not find any UDP configuration there.

      

I still can see opened UDP port and I want to close it.


  was:
The bug is for Jboss 7.1.1.Final  (I was not able to select it when I opened the issue)

I launched  Jboss 7.1.1.Final on Centos6 using JDK7.

When I check what port is opened I see the following UDP port opened for all IPs:
 

netstat -ntulp

Active Internet connections (only servers)

Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name

udp        0                    0 :::43676                      :::*                                                  2460/java

 

The port is changing its value each time I restart JBoss.

Where and why the UDP port is configured?

   

I use `standalone\configuration\standalone.xml` and I can not find any UDP configuration there.

      

I still can see opened UDP port and I want to close it.



    
> The UDP port opened for all IPs in the JBoss 7 standalone configuration
> -----------------------------------------------------------------------
>
>                 Key: JBAS-9549
>                 URL: https://issues.jboss.org/browse/JBAS-9549
>             Project: Application Server 3  4  5 and 6
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: Michael Furman
>            Assignee: Anil Saldhana
>
> The bug is for Jboss 7.1.1.Final  (I was not able to select it when I opened the issue)
> I launched  Jboss 7.1.1.Final on Centos6 using JDK7.
> When I check what ports are opened I see the following UDP port opened for all IPs:
>  
> netstat -ntulp
> Active Internet connections (only servers)
> Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name
> udp        0                    0 :::43676                      :::*                                                  2460/java
>  
> The port is changing its value each time I restart JBoss.
> Where and why the UDP port is configured?
>    
> I use `standalone\configuration\standalone.xml` and I can not find any UDP configuration there.
>       
> I still can see opened UDP port and I want to close it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct  5 03:19:02 2013
From: jira-events at lists.jboss.org (Michael Furman (JIRA))
Date: Sat, 5 Oct 2013 03:19:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBAS-9549) The UDP port opened for all
 IPs in the JBoss 7 standalone configuration
In-Reply-To: <JIRA.12502263.1380956572000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502263.1380956572000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502263.1380956572000.16208.1380957542609@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBAS-9549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Furman updated JBAS-9549:
---------------------------------

    Attachment: standalone.xml


The configuration 
                
> The UDP port opened for all IPs in the JBoss 7 standalone configuration
> -----------------------------------------------------------------------
>
>                 Key: JBAS-9549
>                 URL: https://issues.jboss.org/browse/JBAS-9549
>             Project: Application Server 3  4  5 and 6
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: Michael Furman
>            Assignee: Anil Saldhana
>         Attachments: standalone.xml
>
>
> The bug is for Jboss 7.1.1.Final  (I was not able to select it when I opened the issue)
> I launched  Jboss 7.1.1.Final on Centos6 using JDK7.
> When I check what ports are opened I see the following UDP port opened for all IPs:
>  
> netstat -ntulp
> Active Internet connections (only servers)
> Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name
> udp        0                    0 :::43676                      :::*                                                  2460/java
>  
> The port is changing its value each time I restart JBoss.
> Where and why the UDP port is configured?
>    
> I use `standalone\configuration\standalone.xml` and I can not find any UDP configuration there.
>       
> I still can see opened UDP port and I want to close it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct  5 08:17:02 2013
From: jira-events at lists.jboss.org (Alexander Yerenkow (JIRA))
Date: Sat, 5 Oct 2013 08:17:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-349) FreeBSD
	isThreadCpuTimeSupported
In-Reply-To: <JIRA.12479229.1352909128000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479229.1352909128000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479229.1352909128000.16356.1380975422642@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809633#comment-12809633 ] 

Alexander Yerenkow commented on WFLY-349:
-----------------------------------------

Please, take a look at this pull request

https://github.com/wildfly/wildfly/pull/5223

It should close this issue.
                
> FreeBSD isThreadCpuTimeSupported
> --------------------------------
>
>                 Key: WFLY-349
>                 URL: https://issues.jboss.org/browse/WFLY-349
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>         Environment: FreeBSD 9.0-RELEASE-p3 FreeBSD 9.0-RELEASE-p3 #0: Tue Jun 12 02:52:29 UTC 2012     root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64
> openjdk6/openjdk7
>            Reporter: Alexander Yerenkow
>             Fix For: 8.0.0.CR1
>
>
> Platform Tests should be modified, since it's not respecting when isThreadCpuTimeSupported = false (It continues run some test with isThreadCpuTimeSupported, which produces Exceptions, and all test failed);
> Simple test:
> ThreadMXBean threadMXBean = ManagementFactory.getThreadMXBean();
> System.out.println("threadMXBean.isThreadCpuTimeSupported() = " + threadMXBean.isThreadCpuTimeSupported());
> System.out.println("threadMXBean.isThreadCpuTimeEnabled() = " + threadMXBean.isThreadCpuTimeEnabled());
> Result:
> threadMXBean.isThreadCpuTimeSupported() = false
> Exception in thread "main" java.lang.UnsupportedOperationException: Thread CPU time measurement is not supported
>         at sun.management.ThreadImpl.isThreadCpuTimeEnabled(ThreadImpl.java:98)
>         at Test.main(Test.java:19)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct  5 08:57:02 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Sat, 5 Oct 2013 08:57:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2224) CLI doesn't exit batch mode
 when failures occur in run-batch
In-Reply-To: <JIRA.12502269.1380977814136@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502269.1380977814136@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502269.1380977814136.16366.1380977822586@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-2224:
--------------------------------------

             Summary: CLI doesn't exit batch mode when failures occur in run-batch
                 Key: WFLY-2224
                 URL: https://issues.jboss.org/browse/WFLY-2224
             Project: WildFly
          Issue Type: Bug
          Components: CLI
    Affects Versions: 8.0.0.Beta1
            Reporter: Brian Stansberry
            Assignee: Alexey Loubyansky
             Fix For: 8.0.0.CR1


If you execute a batch that fails, the CLI remains in batch mode.

[domain at localhost:9990 /] batch
[domain at localhost:9990 / #] /profile=test:add
#1 /profile=test:add
[domain at localhost:9990 / #] :bogus
#2 /:bogus
[domain at localhost:9990 / #] run-batch
JBAS014884: No operation named 'bogus' exists at address []
[domain at localhost:9990 / #]

This might be intentional (e.g. to let me fix a typo in my ":bogus" op), but if so, perhaps some output explaining that would be good? And for non-interactive mode staying in the batch seems wrong.

The same problem occurs in the EAP branch, which is where I first noticed it when investigating another issue. In that case the :bogus command wasn't bogus but was a proper op that failed for legitimate reasons. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct  5 10:41:02 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Sat, 5 Oct 2013 10:41:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1858) Add RBAC sensitivity
 classification constraints to undertow subsystem
In-Reply-To: <JIRA.12498290.1375999390000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498290.1375999390000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498290.1375999390000.16373.1380984062649@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-1858:
-----------------------------------

    Priority: Blocker  (was: Major)

    
> Add RBAC sensitivity classification constraints to undertow subsystem
> ---------------------------------------------------------------------
>
>                 Key: WFLY-1858
>                 URL: https://issues.jboss.org/browse/WFLY-1858
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Web (Undertow)
>            Reporter: Brian Stansberry
>            Assignee: Tomaz Cerar
>            Priority: Blocker
>              Labels: RBAC-WF-only
>             Fix For: 8.0.0.CR1
>
>
> The current RBAC work updated the web subsystem but not undertow.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct  5 11:36:02 2013
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Sat, 5 Oct 2013 11:36:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2225) Mutated AtomicInteger/Long
 session attributes are not replicated
In-Reply-To: <JIRA.12502271.1380987263370@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502271.1380987263370@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502271.1380987263370.16383.1380987362555@jira02.app.mwc.hst.phx2.redhat.com>

Paul Ferraro created WFLY-2225:
----------------------------------

             Summary: Mutated AtomicInteger/Long session attributes are not replicated
                 Key: WFLY-2225
                 URL: https://issues.jboss.org/browse/WFLY-2225
             Project: WildFly
          Issue Type: Bug
          Components: Clustering
    Affects Versions: 8.0.0.Beta1
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro
             Fix For: 8.0.0.CR1


The logic in CacheMutator treats all Number subclasses as immutable.  However, AtomicInteger and AtomicLong both extend Number, but are mutable.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct  5 17:09:02 2013
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Sat, 5 Oct 2013 17:09:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2224) CLI doesn't exit batch mode
 when failures occur in run-batch
In-Reply-To: <JIRA.12502269.1380977814000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502269.1380977814000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502269.1380977814000.16442.1381007342710@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809643#comment-12809643 ] 

Alexey Loubyansky commented on WFLY-2224:
-----------------------------------------

Yes, it is intentional and is described in the help content for the command.
                
> CLI doesn't exit batch mode when failures occur in run-batch
> ------------------------------------------------------------
>
>                 Key: WFLY-2224
>                 URL: https://issues.jboss.org/browse/WFLY-2224
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Brian Stansberry
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.0.CR1
>
>
> If you execute a batch that fails, the CLI remains in batch mode.
> [domain at localhost:9990 /] batch
> [domain at localhost:9990 / #] /profile=test:add
> #1 /profile=test:add
> [domain at localhost:9990 / #] :bogus
> #2 /:bogus
> [domain at localhost:9990 / #] run-batch
> JBAS014884: No operation named 'bogus' exists at address []
> [domain at localhost:9990 / #]
> This might be intentional (e.g. to let me fix a typo in my ":bogus" op), but if so, perhaps some output explaining that would be good? And for non-interactive mode staying in the batch seems wrong.
> The same problem occurs in the EAP branch, which is where I first noticed it when investigating another issue. In that case the :bogus command wasn't bogus but was a proper op that failed for legitimate reasons. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Oct  6 03:33:02 2013
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sun, 6 Oct 2013 03:33:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-287) Rule names with
 non-alphabetic characters may lead to name clashes
In-Reply-To: <JIRA.12502262.1380953728000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502262.1380953728000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502262.1380953728000.16463.1381044782707@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809645#comment-12809645 ] 

Geoffrey De Smet commented on DROOLS-287:
-----------------------------------------

That's probably because Java classnames can't contain "<" or ">" and the rules becomes java class files.

A solution to this is escaping for example with the "$" character:
"Rule_>" becomes "Rule_$gt$"
"Rule_<" becomes "Rule_$lt$"
"Rule_$" becomes "Rule_$dollar$"
"Rule_?" becomes "Rule_$u1245$" (presuming that 1245 is the unicode for ?.
"Rule a" becomes "Rule$space$a"
"Rule  a" becomes "Rule$space$$space$a"
                
> Rule names with non-alphabetic characters may lead to name clashes
> ------------------------------------------------------------------
>
>                 Key: DROOLS-287
>                 URL: https://issues.jboss.org/browse/DROOLS-287
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final,  6.0.0.CR4
>            Reporter: Davide Sottara
>            Assignee: Mark Proctor
>            Priority: Critical
>             Fix For: 5.5.1.Final, 6.0.0.CR5
>
>
> A KB with the two following rules will not compile:
> rule "Rule_>"
> when then end
> rule "Rule_<"
> when then end

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Sun Oct  6 03:33:02 2013
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sun, 6 Oct 2013 03:33:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-287) Rule names with
 non-alphabetic characters may lead to name clashes
In-Reply-To: <JIRA.12502262.1380953728000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502262.1380953728000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502262.1380953728000.16467.1381044782893@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809645#comment-12809645 ] 

Geoffrey De Smet edited comment on DROOLS-287 at 10/6/13 3:32 AM:
------------------------------------------------------------------

That's probably because Java classnames can't contain "<" or ">" and the rules becomes java class files.

A solution to this is escaping, for example with the "$" character:
"Rule_>" becomes "Rule_$gt$"
"Rule_<" becomes "Rule_$lt$"
"Rule_$" becomes "Rule_$dollar$"
"Rule_?" becomes "Rule_$u1245$" (presuming that 1245 is the unicode for ?.
"Rule a" becomes "Rule$space$a"
"Rule  a" becomes "Rule$space$$space$a"
                
      was (Author: ge0ffrey):
    That's probably because Java classnames can't contain "<" or ">" and the rules becomes java class files.

A solution to this is escaping for example with the "$" character:
"Rule_>" becomes "Rule_$gt$"
"Rule_<" becomes "Rule_$lt$"
"Rule_$" becomes "Rule_$dollar$"
"Rule_?" becomes "Rule_$u1245$" (presuming that 1245 is the unicode for ?.
"Rule a" becomes "Rule$space$a"
"Rule  a" becomes "Rule$space$$space$a"
                  
> Rule names with non-alphabetic characters may lead to name clashes
> ------------------------------------------------------------------
>
>                 Key: DROOLS-287
>                 URL: https://issues.jboss.org/browse/DROOLS-287
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final,  6.0.0.CR4
>            Reporter: Davide Sottara
>            Assignee: Mark Proctor
>            Priority: Critical
>             Fix For: 5.5.1.Final, 6.0.0.CR5
>
>
> A KB with the two following rules will not compile:
> rule "Rule_>"
> when then end
> rule "Rule_<"
> when then end

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Sun Oct  6 03:33:03 2013
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sun, 6 Oct 2013 03:33:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-287) Rule names with
 non-alphabetic characters may lead to name clashes
In-Reply-To: <JIRA.12502262.1380953728000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502262.1380953728000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502262.1380953728000.16470.1381044783041@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809645#comment-12809645 ] 

Geoffrey De Smet edited comment on DROOLS-287 at 10/6/13 3:32 AM:
------------------------------------------------------------------

That's probably because Java classnames can't contain "<" or ">" and the rules becomes java class files.

A solution to this is escaping, for example with the "$" character:
"Rule_>" becomes "Rule_$gt$"
"Rule_<" becomes "Rule_$lt$"
"Rule_$" becomes "Rule_$dollar$"
"Rule_?" becomes "Rule_$u1245$" (presuming that 1245 is the unicode for ?)
"Rule a" becomes "Rule$space$a"
"Rule  a" becomes "Rule$space$$space$a"
                
      was (Author: ge0ffrey):
    That's probably because Java classnames can't contain "<" or ">" and the rules becomes java class files.

A solution to this is escaping, for example with the "$" character:
"Rule_>" becomes "Rule_$gt$"
"Rule_<" becomes "Rule_$lt$"
"Rule_$" becomes "Rule_$dollar$"
"Rule_?" becomes "Rule_$u1245$" (presuming that 1245 is the unicode for ?.
"Rule a" becomes "Rule$space$a"
"Rule  a" becomes "Rule$space$$space$a"
                  
> Rule names with non-alphabetic characters may lead to name clashes
> ------------------------------------------------------------------
>
>                 Key: DROOLS-287
>                 URL: https://issues.jboss.org/browse/DROOLS-287
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final,  6.0.0.CR4
>            Reporter: Davide Sottara
>            Assignee: Mark Proctor
>            Priority: Critical
>             Fix For: 5.5.1.Final, 6.0.0.CR5
>
>
> A KB with the two following rules will not compile:
> rule "Rule_>"
> when then end
> rule "Rule_<"
> when then end

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Sun Oct  6 03:35:02 2013
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sun, 6 Oct 2013 03:35:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-287) Rule names with
 non-alphabetic characters may lead to name clashes
In-Reply-To: <JIRA.12502262.1380953728000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502262.1380953728000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502262.1380953728000.16475.1381044902834@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Geoffrey De Smet updated DROOLS-287:
------------------------------------

    Description: 
A KB with the two following rules will not compile:

{code}
rule "Rule_>"
when then end

rule "Rule_<"
when then end
{code}


Here's a more realistic example:

{code}
rule "dollar > euro"
when then end

rule "dollar < euro"
when then end
{code}


  was:
A KB with the two following rules will not compile:

rule "Rule_>"
when then end

rule "Rule_<"
when then end




    
> Rule names with non-alphabetic characters may lead to name clashes
> ------------------------------------------------------------------
>
>                 Key: DROOLS-287
>                 URL: https://issues.jboss.org/browse/DROOLS-287
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final,  6.0.0.CR4
>            Reporter: Davide Sottara
>            Assignee: Mark Proctor
>            Priority: Critical
>             Fix For: 5.5.1.Final, 6.0.0.CR5
>
>
> A KB with the two following rules will not compile:
> {code}
> rule "Rule_>"
> when then end
> rule "Rule_<"
> when then end
> {code}
> Here's a more realistic example:
> {code}
> rule "dollar > euro"
> when then end
> rule "dollar < euro"
> when then end
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Oct  6 03:37:02 2013
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sun, 6 Oct 2013 03:37:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-287) Rule names with
 non-alphabetic characters may lead to name clashes
In-Reply-To: <JIRA.12502262.1380953728000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502262.1380953728000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502262.1380953728000.16478.1381045022569@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809645#comment-12809645 ] 

Geoffrey De Smet edited comment on DROOLS-287 at 10/6/13 3:35 AM:
------------------------------------------------------------------

That's probably because Java classnames can't contain "<" or ">" and the rules becomes java class files.

A solution to this is *escaping*, for example with the "$" character:
"Rule_>" becomes "Rule_$gt$"
"Rule_<" becomes "Rule_$lt$"
"Rule_$" becomes "Rule_$dollar$"
"Rule_?" becomes "Rule_$u1245$" (presuming that 1245 is the unicode for ?)
"Rule a" becomes "Rule$space$a"
"Rule  a" becomes "Rule$space$$space$a"
                
      was (Author: ge0ffrey):
    That's probably because Java classnames can't contain "<" or ">" and the rules becomes java class files.

A solution to this is escaping, for example with the "$" character:
"Rule_>" becomes "Rule_$gt$"
"Rule_<" becomes "Rule_$lt$"
"Rule_$" becomes "Rule_$dollar$"
"Rule_?" becomes "Rule_$u1245$" (presuming that 1245 is the unicode for ?)
"Rule a" becomes "Rule$space$a"
"Rule  a" becomes "Rule$space$$space$a"
                  
> Rule names with non-alphabetic characters may lead to name clashes
> ------------------------------------------------------------------
>
>                 Key: DROOLS-287
>                 URL: https://issues.jboss.org/browse/DROOLS-287
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final,  6.0.0.CR4
>            Reporter: Davide Sottara
>            Assignee: Mark Proctor
>            Priority: Critical
>             Fix For: 5.5.1.Final, 6.0.0.CR5
>
>
> A KB with the two following rules will not compile:
> {code}
> rule "Rule_>"
> when then end
> rule "Rule_<"
> when then end
> {code}
> Here's a more realistic example:
> {code}
> rule "dollar > euro"
> when then end
> rule "dollar < euro"
> when then end
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Sun Oct  6 12:32:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Sun, 6 Oct 2013 12:32:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (AS7-6423) JBoss RPM doesn't adhere to LFS
In-Reply-To: <JIRA.12483879.1359571728000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12483879.1359571728000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12483879.1359571728000.16509.1381077122958@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-6423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809648#comment-12809648 ] 

RH Bugzilla Integration commented on AS7-6423:
----------------------------------------------

Fernando Nasser <fnasser at redhat.com> made a comment on [bug 1011067|https://bugzilla.redhat.com/show_bug.cgi?id=1011067]


                
> JBoss RPM doesn't adhere to LFS
> -------------------------------
>
>                 Key: AS7-6423
>                 URL: https://issues.jboss.org/browse/AS7-6423
>             Project: Application Server 7
>          Issue Type: Enhancement
>          Components: Build System
>    Affects Versions: 7.1.2.Final (EAP)
>         Environment: Red Hat Enterprise Linux Server release 6.3 (Santiago)
>            Reporter: rafael liu
>            Assignee: Fernando Nasser
>            Priority: Minor
>              Labels: rpm
>
> In /usr/share/jbossas/domain links to tmp and data folders were mixed up:
> {noformat} 
> [domain]]# ls -l
> total 4
> lrwxrwxrwx. 1 jboss jboss   19 Jan  2 14:45 configuration -> /etc/jbossas/domain
> lrwxrwxrwx. 1 jboss jboss   23 Jan  2 14:45 data -> /var/tmp/jbossas/domain
> lrwxrwxrwx. 1 jboss jboss   23 Jan  2 14:45 log -> /var/log/jbossas/domain
> drwxrwxr-x. 5 jboss jboss 4096 Jan  2 16:02 servers
> lrwxrwxrwx. 1 jboss jboss   25 Jan  2 14:45 tmp -> /var/cache/jbossas/domain
> {noformat} 
> In /usr/share/jbossas/standalone tmp folder is not linked:
> {noformat} 
> [standalone]# ls -l
> total 12
> lrwxrwxrwx. 1 jboss jboss   23 Jan  2 14:45 configuration -> /etc/jbossas/standalone
> drwxr-xr-x. 2 jboss jboss 4096 Jan  2 14:45 deployments
> drwxr-xr-x. 3 jboss jboss 4096 Jan  2 14:45 lib
> lrwxrwxrwx. 1 jboss jboss   27 Jan  2 14:45 log -> /var/log/jbossas/standalone
> drwxr-xr-x. 3 jboss jboss 4096 Jan  2 14:45 tmp
> {noformat} 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Oct  6 12:32:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Sun, 6 Oct 2013 12:32:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (AS7-6423) JBoss RPM doesn't adhere to LFS
In-Reply-To: <JIRA.12483879.1359571728000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12483879.1359571728000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12483879.1359571728000.16512.1381077123150@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-6423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809649#comment-12809649 ] 

RH Bugzilla Integration commented on AS7-6423:
----------------------------------------------

Fernando Nasser <fnasser at redhat.com> changed the Status of [bug 1011067|https://bugzilla.redhat.com/show_bug.cgi?id=1011067] from NEW to CLOSED
                
> JBoss RPM doesn't adhere to LFS
> -------------------------------
>
>                 Key: AS7-6423
>                 URL: https://issues.jboss.org/browse/AS7-6423
>             Project: Application Server 7
>          Issue Type: Enhancement
>          Components: Build System
>    Affects Versions: 7.1.2.Final (EAP)
>         Environment: Red Hat Enterprise Linux Server release 6.3 (Santiago)
>            Reporter: rafael liu
>            Assignee: Fernando Nasser
>            Priority: Minor
>              Labels: rpm
>
> In /usr/share/jbossas/domain links to tmp and data folders were mixed up:
> {noformat} 
> [domain]]# ls -l
> total 4
> lrwxrwxrwx. 1 jboss jboss   19 Jan  2 14:45 configuration -> /etc/jbossas/domain
> lrwxrwxrwx. 1 jboss jboss   23 Jan  2 14:45 data -> /var/tmp/jbossas/domain
> lrwxrwxrwx. 1 jboss jboss   23 Jan  2 14:45 log -> /var/log/jbossas/domain
> drwxrwxr-x. 5 jboss jboss 4096 Jan  2 16:02 servers
> lrwxrwxrwx. 1 jboss jboss   25 Jan  2 14:45 tmp -> /var/cache/jbossas/domain
> {noformat} 
> In /usr/share/jbossas/standalone tmp folder is not linked:
> {noformat} 
> [standalone]# ls -l
> total 12
> lrwxrwxrwx. 1 jboss jboss   23 Jan  2 14:45 configuration -> /etc/jbossas/standalone
> drwxr-xr-x. 2 jboss jboss 4096 Jan  2 14:45 deployments
> drwxr-xr-x. 3 jboss jboss 4096 Jan  2 14:45 lib
> lrwxrwxrwx. 1 jboss jboss   27 Jan  2 14:45 log -> /var/log/jbossas/standalone
> drwxr-xr-x. 3 jboss jboss 4096 Jan  2 14:45 tmp
> {noformat} 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Oct  6 14:18:02 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Sun, 6 Oct 2013 14:18:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-287) Rule names with
 non-alphabetic characters may lead to name clashes
In-Reply-To: <JIRA.12502262.1380953728000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502262.1380953728000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502262.1380953728000.16535.1381083482579@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809651#comment-12809651 ] 

Davide Sottara commented on DROOLS-287:
---------------------------------------

I agree. The solution currently implemented replaces illegal characters with underscores, and then uses an incrementing counter to resolve ambiguities. 
But this would make it impossible to determine the name of the class from the name of the rule alone, which may be a problem in some case. 
I'll see if this can be fixed easily

                
> Rule names with non-alphabetic characters may lead to name clashes
> ------------------------------------------------------------------
>
>                 Key: DROOLS-287
>                 URL: https://issues.jboss.org/browse/DROOLS-287
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final,  6.0.0.CR4
>            Reporter: Davide Sottara
>            Assignee: Mark Proctor
>            Priority: Critical
>             Fix For: 5.5.1.Final, 6.0.0.CR5
>
>
> A KB with the two following rules will not compile:
> {code}
> rule "Rule_>"
> when then end
> rule "Rule_<"
> when then end
> {code}
> Here's a more realistic example:
> {code}
> rule "dollar > euro"
> when then end
> rule "dollar < euro"
> when then end
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Oct  6 17:30:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Sun, 6 Oct 2013 17:30:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1697) Fix JPA
 SerializableValidatorFactory memory leak
In-Reply-To: <JIRA.12496481.1373901643000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496481.1373901643000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496481.1373901643000.16544.1381095002734@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809654#comment-12809654 ] 

RH Bugzilla Integration commented on WFLY-1697:
-----------------------------------------------

Tomaz Cerar <tcerar at redhat.com> changed the Status of [bug 1003600|https://bugzilla.redhat.com/show_bug.cgi?id=1003600] from ASSIGNED to ON_QA
                
> Fix JPA SerializableValidatorFactory memory leak
> ------------------------------------------------
>
>                 Key: WFLY-1697
>                 URL: https://issues.jboss.org/browse/WFLY-1697
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>
> See http://lists.jboss.org/pipermail/wildfly-dev/2013-July/000466.html for details on recreating the SerializableValidatorFactory leak and Hibernate service loader references to Integreation class/properties.  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Oct  6 23:48:02 2013
From: jira-events at lists.jboss.org (Jorge Solorzano (JIRA))
Date: Sun, 6 Oct 2013 23:48:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2226) Web Console adds two slash in
	the address
In-Reply-To: <JIRA.12502291.1381117579680@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502291.1381117579680@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502291.1381117579680.17206.1381117682628@jira02.app.mwc.hst.phx2.redhat.com>

Jorge Solorzano created WFLY-2226:
-------------------------------------

             Summary: Web Console adds two slash in the address
                 Key: WFLY-2226
                 URL: https://issues.jboss.org/browse/WFLY-2226
             Project: WildFly
          Issue Type: Bug
          Components: Web Console
    Affects Versions: 8.0.0.Beta1
            Reporter: Jorge Solorzano
            Assignee: Heiko Braun
            Priority: Trivial


The web console adds two slashes to the address after the port

http://localhost:9990//console/App.html



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Oct  6 23:48:02 2013
From: jira-events at lists.jboss.org (Jorge Solorzano (JIRA))
Date: Sun, 6 Oct 2013 23:48:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2226) Web Console adds two slashes
 in the address
In-Reply-To: <JIRA.12502291.1381117579000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502291.1381117579000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502291.1381117579000.17212.1381117682865@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jorge Solorzano updated WFLY-2226:
----------------------------------

    Summary: Web Console adds two slashes in the address  (was: Web Console adds two slash in the address)

    
> Web Console adds two slashes in the address
> -------------------------------------------
>
>                 Key: WFLY-2226
>                 URL: https://issues.jboss.org/browse/WFLY-2226
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web Console
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Jorge Solorzano
>            Assignee: Heiko Braun
>            Priority: Trivial
>
> The web console adds two slashes to the address after the port
> http://localhost:9990//console/App.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 02:47:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Oct 2013 02:47:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2172) Resurrect the mixed domain
 testing and fix any problems
In-Reply-To: <JIRA.12501720.1380277458000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501720.1380277458000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501720.1380277458000.17893.1381128422630@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12810301#comment-12810301 ] 

RH Bugzilla Integration commented on WFLY-2172:
-----------------------------------------------

Rostislav Svoboda <rsvoboda at redhat.com> made a comment on [bug 1015243|https://bugzilla.redhat.com/show_bug.cgi?id=1015243]

This is big effort, already in late tests execution phase (waiting for ER5), targeting for test development phase for EAP 6.3.
                
> Resurrect the mixed domain testing and fix any problems
> -------------------------------------------------------
>
>                 Key: WFLY-2172
>                 URL: https://issues.jboss.org/browse/WFLY-2172
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Brian Stansberry
>            Priority: Blocker
>             Fix For: 8.0.0.CR1
>
>
> THis has not been run for quite some time, and needs to be included in the general testing.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 02:57:02 2013
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Mon, 7 Oct 2013 02:57:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-287) Rule names with
 non-alphabetic characters may lead to name clashes
In-Reply-To: <JIRA.12502262.1380953728000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502262.1380953728000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502262.1380953728000.17906.1381129022627@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12809645#comment-12809645 ] 

Geoffrey De Smet edited comment on DROOLS-287 at 10/7/13 2:55 AM:
------------------------------------------------------------------

That's probably because Java classnames can't contain "<" or ">" and the rules becomes java class files.

Solution A): a solution to this is *escaping*, for example with the "$" character:
"Rule_>" becomes "Rule_$gt$"
"Rule_<" becomes "Rule_$lt$"
"Rule_$" becomes "Rule_$dollar$"
"Rule_?" becomes "Rule_$u1245$" (presuming that 1245 is the unicode for ?)
"Rule a" becomes "Rule$space$a"
"Rule  a" becomes "Rule$space$$space$a"
                
      was (Author: ge0ffrey):
    That's probably because Java classnames can't contain "<" or ">" and the rules becomes java class files.

A solution to this is *escaping*, for example with the "$" character:
"Rule_>" becomes "Rule_$gt$"
"Rule_<" becomes "Rule_$lt$"
"Rule_$" becomes "Rule_$dollar$"
"Rule_?" becomes "Rule_$u1245$" (presuming that 1245 is the unicode for ?)
"Rule a" becomes "Rule$space$a"
"Rule  a" becomes "Rule$space$$space$a"
                  
> Rule names with non-alphabetic characters may lead to name clashes
> ------------------------------------------------------------------
>
>                 Key: DROOLS-287
>                 URL: https://issues.jboss.org/browse/DROOLS-287
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final,  6.0.0.CR4
>            Reporter: Davide Sottara
>            Assignee: Mark Proctor
>            Priority: Critical
>             Fix For: 5.5.1.Final, 6.0.0.CR5
>
>
> A KB with the two following rules will not compile:
> {code}
> rule "Rule_>"
> when then end
> rule "Rule_<"
> when then end
> {code}
> Here's a more realistic example:
> {code}
> rule "dollar > euro"
> when then end
> rule "dollar < euro"
> when then end
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Mon Oct  7 03:01:02 2013
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Mon, 7 Oct 2013 03:01:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-287) Rule names with
 non-alphabetic characters may lead to name clashes
In-Reply-To: <JIRA.12502262.1380953728000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502262.1380953728000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502262.1380953728000.17909.1381129262993@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12810303#comment-12810303 ] 

Geoffrey De Smet commented on DROOLS-287:
-----------------------------------------

Solution B) Prune the invalid characters like it does now (for example "dollareuro", but keep a Map to it's original ruleName too (for example "dollar > euro".
If a conflicting pruned rulename "dollareuro" is found:
- Check the original ruleName "dollar > euro" is indeed unique (fail-fast if it's not)
- Append "1" to the pruned ruleName, "dollareuro1", check if it's unique.
- If not unique (still conflicting): Append "2" instead: "dollareuro2"
- etc "dollareuro3", ..., "dollareuro9",  "dollareuro10", "dollareuro11", ...


Personally, I believe solution A) is better then solution B).
                
> Rule names with non-alphabetic characters may lead to name clashes
> ------------------------------------------------------------------
>
>                 Key: DROOLS-287
>                 URL: https://issues.jboss.org/browse/DROOLS-287
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final,  6.0.0.CR4
>            Reporter: Davide Sottara
>            Assignee: Mark Proctor
>            Priority: Critical
>             Fix For: 5.5.1.Final, 6.0.0.CR5
>
>
> A KB with the two following rules will not compile:
> {code}
> rule "Rule_>"
> when then end
> rule "Rule_<"
> when then end
> {code}
> Here's a more realistic example:
> {code}
> rule "dollar > euro"
> when then end
> rule "dollar < euro"
> when then end
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 03:30:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Oct 2013 03:30:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1083) PreparedStatement cache
 constraints not maintained
In-Reply-To: <JIRA.12500678.1379075076000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500678.1379075076000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500678.1379075076000.17930.1381131003136@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBJCA-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12810306#comment-12810306 ] 

RH Bugzilla Integration commented on JBJCA-1083:
------------------------------------------------

Vladimir Rastseluev <vrastsel at redhat.com> made a comment on [bug 1008763|https://bugzilla.redhat.com/show_bug.cgi?id=1008763]

Verified on EAP 6.2.0 ER4
                
> PreparedStatement cache constraints not maintained
> --------------------------------------------------
>
>                 Key: JBJCA-1083
>                 URL: https://issues.jboss.org/browse/JBJCA-1083
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: JDBC
>    Affects Versions: 1.0.20.Final, 1.1.0.Final
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>            Priority: Critical
>             Fix For: 1.0.21.Final, 1.1.1.Final
>
>
> The PreparedStatement cache doesn't maintain its constraint on the number of cached entries

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 03:30:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Oct 2013 03:30:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1083) PreparedStatement cache
 constraints not maintained
In-Reply-To: <JIRA.12500678.1379075076000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500678.1379075076000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500678.1379075076000.17932.1381131003276@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBJCA-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12810307#comment-12810307 ] 

RH Bugzilla Integration commented on JBJCA-1083:
------------------------------------------------

Vladimir Rastseluev <vrastsel at redhat.com> changed the Status of [bug 1008763|https://bugzilla.redhat.com/show_bug.cgi?id=1008763] from ON_QA to VERIFIED
                
> PreparedStatement cache constraints not maintained
> --------------------------------------------------
>
>                 Key: JBJCA-1083
>                 URL: https://issues.jboss.org/browse/JBJCA-1083
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: JDBC
>    Affects Versions: 1.0.20.Final, 1.1.0.Final
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>            Priority: Critical
>             Fix For: 1.0.21.Final, 1.1.1.Final
>
>
> The PreparedStatement cache doesn't maintain its constraint on the number of cached entries

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 03:34:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Oct 2013 03:34:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1070) Memory leak if hashCode of
 Transaction isn't stable
In-Reply-To: <JIRA.12498669.1376567503000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498669.1376567503000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498669.1376567503000.17940.1381131242604@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBJCA-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12810309#comment-12810309 ] 

RH Bugzilla Integration commented on JBJCA-1070:
------------------------------------------------

Vladimir Rastseluev <vrastsel at redhat.com> changed the Status of [bug 1007608|https://bugzilla.redhat.com/show_bug.cgi?id=1007608] from ON_QA to VERIFIED
                
> Memory leak if hashCode of Transaction isn't stable
> ---------------------------------------------------
>
>                 Key: JBJCA-1070
>                 URL: https://issues.jboss.org/browse/JBJCA-1070
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0.19.Final, 1.1.0.Final
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>            Priority: Critical
>             Fix For: 1.0.20.Final, 1.1.1.Final
>
>
> Happens in TransactionSynchronizer

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 03:34:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Oct 2013 03:34:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1070) Memory leak if hashCode of
 Transaction isn't stable
In-Reply-To: <JIRA.12498669.1376567503000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498669.1376567503000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498669.1376567503000.17943.1381131242791@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBJCA-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12810310#comment-12810310 ] 

RH Bugzilla Integration commented on JBJCA-1070:
------------------------------------------------

Vladimir Rastseluev <vrastsel at redhat.com> made a comment on [bug 1007608|https://bugzilla.redhat.com/show_bug.cgi?id=1007608]

Verified on EAP 6.2.0 ER4
                
> Memory leak if hashCode of Transaction isn't stable
> ---------------------------------------------------
>
>                 Key: JBJCA-1070
>                 URL: https://issues.jboss.org/browse/JBJCA-1070
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0.19.Final, 1.1.0.Final
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>            Priority: Critical
>             Fix For: 1.0.20.Final, 1.1.1.Final
>
>
> Happens in TransactionSynchronizer

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 03:48:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Mon, 7 Oct 2013 03:48:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2226) Web Console adds two slashes
 in the address
In-Reply-To: <JIRA.12502291.1381117579000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502291.1381117579000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502291.1381117579000.18043.1381132083595@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun reassigned WFLY-2226:
---------------------------------

    Assignee: Harald Pehl  (was: Heiko Braun)


the redirect from [1] seems to be wrong. can you look into it Harald?

[1] http://localhost:9990
                
> Web Console adds two slashes in the address
> -------------------------------------------
>
>                 Key: WFLY-2226
>                 URL: https://issues.jboss.org/browse/WFLY-2226
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web Console
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Jorge Solorzano
>            Assignee: Harald Pehl
>            Priority: Trivial
>
> The web console adds two slashes to the address after the port
> http://localhost:9990//console/App.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 04:03:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Oct 2013 04:03:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-924) Reduce the log level of
 optional components failing to start log message (JBAS011006 message id)
In-Reply-To: <JIRA.12470562.1342479956000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12470562.1342479956000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12470562.1342479956000.18084.1381132983722@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12810332#comment-12810332 ] 

RH Bugzilla Integration commented on WFLY-924:
----------------------------------------------

Jan Martiska <jmartisk at redhat.com> changed the Status of [bug 900711|https://bugzilla.redhat.com/show_bug.cgi?id=900711] from ON_QA to VERIFIED
                
> Reduce the log level of optional components failing to start log message (JBAS011006 message id)
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-924
>                 URL: https://issues.jboss.org/browse/WFLY-924
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: EE
>    Affects Versions: 8.0.0.Alpha2
>         Environment: JBoss EAP 6.0 GA, web services subsystem removed, war deployed containing Metro or CXF web services implementation
>            Reporter: Brad Maxwell
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Alpha3
>
>
> It tries to create this class if CXF is packaged in the war: org.apache.cxf.transport.http.Servlet3ContinuationProvider$Servlet3Continuation 
> And this stack is logged as a warning:
> 11:08:40,879 INFO  [org.jboss.as.osgi] (MSC service thread 1-1) JBAS011907: Register module: Module "deployment.test.war:main" from Service Module Loader
> 11:08:40,905 WARN  [org.jboss.as.ee] (MSC service thread 1-6) JBAS011006: Not installing optional component org.apache.cxf.transport.http.Servlet3ContinuationProvider$Servlet3Continuation due to exception: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS011054: Could not find default constructor for class org.apache.cxf.transport.http.Servlet3ContinuationProvider$Servlet3Continuation
>   at org.jboss.as.ee.component.ComponentDescription$DefaultComponentConfigurator.configure(ComponentDescription.java:606) [jboss-as-ee-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
>   at org.jboss.as.ee.component.deployers.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:83) [jboss-as-ee-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
>   at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:116)
>   at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
>   at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
>   at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_30]
>   at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_30]
>   at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]
> If Metro is packaged in the war, it tries to load com.sun.xml.ws.transport.http.servlet.WSAsyncListener and logs a warning with this stack: 
> 16:48:57,302 WARN  [org.jboss.as.ee] (MSC service thread 1-1) JBAS011006: Not installing optional component com.sun.xml.ws.transport.http.servlet.WSAsyncListener$1 due to exception: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS011054: Could not find default constructor for class com.sun.xml.ws.transport.http.servlet.WSAsyncListener$1
>   at org.jboss.as.ee.component.ComponentDescription$DefaultComponentConfigurator.configure(ComponentDescription.java:606) [jboss-as-ee-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
>   at org.jboss.as.ee.component.deployers.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:83) [jboss-as-ee-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
>   at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:116)
>   at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
>   at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
>   at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_30]
>   at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_30]
>   at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 04:03:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Oct 2013 04:03:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-924) Reduce the log level of
 optional components failing to start log message (JBAS011006 message id)
In-Reply-To: <JIRA.12470562.1342479956000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12470562.1342479956000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12470562.1342479956000.18092.1381132984932@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12810333#comment-12810333 ] 

RH Bugzilla Integration commented on WFLY-924:
----------------------------------------------

Jan Martiska <jmartisk at redhat.com> made a comment on [bug 900711|https://bugzilla.redhat.com/show_bug.cgi?id=900711]

Verified in EAP 6.2.0.ER4.
                
> Reduce the log level of optional components failing to start log message (JBAS011006 message id)
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-924
>                 URL: https://issues.jboss.org/browse/WFLY-924
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: EE
>    Affects Versions: 8.0.0.Alpha2
>         Environment: JBoss EAP 6.0 GA, web services subsystem removed, war deployed containing Metro or CXF web services implementation
>            Reporter: Brad Maxwell
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Alpha3
>
>
> It tries to create this class if CXF is packaged in the war: org.apache.cxf.transport.http.Servlet3ContinuationProvider$Servlet3Continuation 
> And this stack is logged as a warning:
> 11:08:40,879 INFO  [org.jboss.as.osgi] (MSC service thread 1-1) JBAS011907: Register module: Module "deployment.test.war:main" from Service Module Loader
> 11:08:40,905 WARN  [org.jboss.as.ee] (MSC service thread 1-6) JBAS011006: Not installing optional component org.apache.cxf.transport.http.Servlet3ContinuationProvider$Servlet3Continuation due to exception: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS011054: Could not find default constructor for class org.apache.cxf.transport.http.Servlet3ContinuationProvider$Servlet3Continuation
>   at org.jboss.as.ee.component.ComponentDescription$DefaultComponentConfigurator.configure(ComponentDescription.java:606) [jboss-as-ee-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
>   at org.jboss.as.ee.component.deployers.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:83) [jboss-as-ee-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
>   at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:116)
>   at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
>   at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
>   at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_30]
>   at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_30]
>   at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]
> If Metro is packaged in the war, it tries to load com.sun.xml.ws.transport.http.servlet.WSAsyncListener and logs a warning with this stack: 
> 16:48:57,302 WARN  [org.jboss.as.ee] (MSC service thread 1-1) JBAS011006: Not installing optional component com.sun.xml.ws.transport.http.servlet.WSAsyncListener$1 due to exception: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS011054: Could not find default constructor for class com.sun.xml.ws.transport.http.servlet.WSAsyncListener$1
>   at org.jboss.as.ee.component.ComponentDescription$DefaultComponentConfigurator.configure(ComponentDescription.java:606) [jboss-as-ee-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
>   at org.jboss.as.ee.component.deployers.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:83) [jboss-as-ee-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
>   at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:116)
>   at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
>   at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
>   at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_30]
>   at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_30]
>   at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 04:03:05 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Oct 2013 04:03:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2069) can not switch from connector
 to discovery-group-name for JMS (pooled-) connection factories
In-Reply-To: <JIRA.12500687.1379080160000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500687.1379080160000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500687.1379080160000.18097.1381132985553@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12810335#comment-12810335 ] 

RH Bugzilla Integration commented on WFLY-2069:
-----------------------------------------------

Miroslav Novak <mnovak at redhat.com> made a comment on [bug 1001612|https://bugzilla.redhat.com/show_bug.cgi?id=1001612]

BZ was verified in EAP 6.2.0.ER4 by following batch:

batch
/subsystem=messaging/hornetq-server=default/connection-factory=RemoteConnectionFactory:undefine-attribute(name=connector)
/subsystem=messaging/hornetq-server=default/connection-factory=RemoteConnectionFactory:write-attribute(name=discovery-group-name,value=dg-group1)
run-batch

In this way connector for connection factory can be undefined and set discovery-group. Or discovery-group undefined and changed set connector.

This must be done in a batch or commands will fail as it is reported in description.
                
> can not switch from connector to discovery-group-name for JMS (pooled-) connection factories 
> ---------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2069
>                 URL: https://issues.jboss.org/browse/WFLY-2069
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.Beta1
>
>
> connectors and discovery-group-name are alternative attributes of JMS (pooled) connection factories.
> If a resource defines one of this attribute, it must be able to "switch" to the other by running a batch command to:
> 1. undefine the attribute
> 2. write the value of the other attribute
> This currently does not work:
> {noformat}
> [standalone at localhost:9999 /] batch
> [standalone at localhost:9999 / #] /subsystem=messaging/hornetq-server=default/connection-factory=RemoteConnectionFactory:undefine-attribute(name=connector)
> #1 /subsystem=messaging/hornetq-server=default/connection-factory=RemoteConnectionFactory:undefine-attribute(name=connector)
> [standalone at localhost:9999 / #] /subsystem=messaging/hornetq-server=default/connection-factory=RemoteConnectionFactory:write-attribute(name=discovery-group-name,value=dg-group1)
> #2 /subsystem=messaging/hornetq-server=default/connection-factory=RemoteConnectionFactory:write-attribute(name=discovery-group-name,value=dg-group1)
> [standalone at localhost:9999 / #] run-batch
> {"JBAS014653: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "JBAS011630: Alternative attribute of (connector) is already defined."}}
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 04:03:05 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Oct 2013 04:03:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (AS7-5107) define connectors as
 alternatives to discovery-group
In-Reply-To: <JIRA.12469832.1341326802000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12469832.1341326802000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12469832.1341326802000.18095.1381132985365@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-5107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12810334#comment-12810334 ] 

RH Bugzilla Integration commented on AS7-5107:
----------------------------------------------

Miroslav Novak <mnovak at redhat.com> changed the Status of [bug 1001612|https://bugzilla.redhat.com/show_bug.cgi?id=1001612] from ON_QA to VERIFIED
                
> define connectors as alternatives to discovery-group
> ----------------------------------------------------
>
>                 Key: AS7-5107
>                 URL: https://issues.jboss.org/browse/AS7-5107
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 7.1.2.Final (EAP)
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: EAP 6.1.0.Alpha (7.2.0.Final)
>
>
> cluster-connections, bridges and JMS connection factories must define either connectors or discovery-group but not both.
> The choice is handled in the messaging susbsystem parser but it's not enforced by the attributes' definitions. Admin operations are not shielded against a misconfiguration by changing directly these attributes

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 04:03:06 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Oct 2013 04:03:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (AS7-5107) define connectors as
 alternatives to discovery-group
In-Reply-To: <JIRA.12469832.1341326802000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12469832.1341326802000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12469832.1341326802000.18101.1381132986185@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-5107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12810336#comment-12810336 ] 

RH Bugzilla Integration commented on AS7-5107:
----------------------------------------------

Miroslav Novak <mnovak at redhat.com> made a comment on [bug 1001612|https://bugzilla.redhat.com/show_bug.cgi?id=1001612]

BZ was verified in EAP 6.2.0.ER4 by following batch:

batch
/subsystem=messaging/hornetq-server=default/connection-factory=RemoteConnectionFactory:undefine-attribute(name=connector)
/subsystem=messaging/hornetq-server=default/connection-factory=RemoteConnectionFactory:write-attribute(name=discovery-group-name,value=dg-group1)
run-batch

In this way connector for connection factory can be undefined and set discovery-group. Or discovery-group undefined and changed set connector.

This must be done in a batch or commands will fail as it is reported in description.
                
> define connectors as alternatives to discovery-group
> ----------------------------------------------------
>
>                 Key: AS7-5107
>                 URL: https://issues.jboss.org/browse/AS7-5107
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 7.1.2.Final (EAP)
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: EAP 6.1.0.Alpha (7.2.0.Final)
>
>
> cluster-connections, bridges and JMS connection factories must define either connectors or discovery-group but not both.
> The choice is handled in the messaging susbsystem parser but it's not enforced by the attributes' definitions. Admin operations are not shielded against a misconfiguration by changing directly these attributes

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 04:03:06 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Oct 2013 04:03:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2069) can not switch from connector
 to discovery-group-name for JMS (pooled-) connection factories
In-Reply-To: <JIRA.12500687.1379080160000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500687.1379080160000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500687.1379080160000.18103.1381132986575@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12810337#comment-12810337 ] 

RH Bugzilla Integration commented on WFLY-2069:
-----------------------------------------------

Miroslav Novak <mnovak at redhat.com> changed the Status of [bug 1001612|https://bugzilla.redhat.com/show_bug.cgi?id=1001612] from ON_QA to VERIFIED
                
> can not switch from connector to discovery-group-name for JMS (pooled-) connection factories 
> ---------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2069
>                 URL: https://issues.jboss.org/browse/WFLY-2069
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.Beta1
>
>
> connectors and discovery-group-name are alternative attributes of JMS (pooled) connection factories.
> If a resource defines one of this attribute, it must be able to "switch" to the other by running a batch command to:
> 1. undefine the attribute
> 2. write the value of the other attribute
> This currently does not work:
> {noformat}
> [standalone at localhost:9999 /] batch
> [standalone at localhost:9999 / #] /subsystem=messaging/hornetq-server=default/connection-factory=RemoteConnectionFactory:undefine-attribute(name=connector)
> #1 /subsystem=messaging/hornetq-server=default/connection-factory=RemoteConnectionFactory:undefine-attribute(name=connector)
> [standalone at localhost:9999 / #] /subsystem=messaging/hornetq-server=default/connection-factory=RemoteConnectionFactory:write-attribute(name=discovery-group-name,value=dg-group1)
> #2 /subsystem=messaging/hornetq-server=default/connection-factory=RemoteConnectionFactory:write-attribute(name=discovery-group-name,value=dg-group1)
> [standalone at localhost:9999 / #] run-batch
> {"JBAS014653: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "JBAS011630: Alternative attribute of (connector) is already defined."}}
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 04:09:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Oct 2013 04:09:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2071) Messaging queue attributes
 must be read-only
In-Reply-To: <JIRA.12500697.1379086256000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500697.1379086256000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500697.1379086256000.18111.1381133342862@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12810341#comment-12810341 ] 

RH Bugzilla Integration commented on WFLY-2071:
-----------------------------------------------

Miroslav Novak <mnovak at redhat.com> changed the Status of [bug 1004789|https://bugzilla.redhat.com/show_bug.cgi?id=1004789] from ON_QA to VERIFIED
                
> Messaging queue attributes must be read-only
> --------------------------------------------
>
>                 Key: WFLY-2071
>                 URL: https://issues.jboss.org/browse/WFLY-2071
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JMS
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.Beta1
>
>
> Currently, the messaging subsystem's queue and jms-queue resources defines attributes that are writable (eg filter and durable attribute).
> This is not correct, once a queue is created with these attributes, they can not be changed for the lifetime of a queue (a durable queue can not become non-durable).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 04:09:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Oct 2013 04:09:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2071) Messaging queue attributes
 must be read-only
In-Reply-To: <JIRA.12500697.1379086256000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500697.1379086256000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500697.1379086256000.18113.1381133342968@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12810342#comment-12810342 ] 

RH Bugzilla Integration commented on WFLY-2071:
-----------------------------------------------

Miroslav Novak <mnovak at redhat.com> made a comment on [bug 1004789|https://bugzilla.redhat.com/show_bug.cgi?id=1004789]

Verified in EAP 6.2.0.ER4. Attribute selector on queue is read-only now. Thanks Jeff for the change.
                
> Messaging queue attributes must be read-only
> --------------------------------------------
>
>                 Key: WFLY-2071
>                 URL: https://issues.jboss.org/browse/WFLY-2071
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JMS
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.Beta1
>
>
> Currently, the messaging subsystem's queue and jms-queue resources defines attributes that are writable (eg filter and durable attribute).
> This is not correct, once a queue is created with these attributes, they can not be changed for the lifetime of a queue (a durable queue can not become non-durable).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 04:24:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Oct 2013 04:24:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2135) Change distributed config on
 address settings to Page instead of Block
In-Reply-To: <JIRA.12501318.1379952235000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501318.1379952235000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501318.1379952235000.18167.1381134243117@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12810348#comment-12810348 ] 

RH Bugzilla Integration commented on WFLY-2135:
-----------------------------------------------

Miroslav Novak <mnovak at redhat.com> made a comment on [bug 1011074|https://bugzilla.redhat.com/show_bug.cgi?id=1011074]

There is PAGE policy in all standalone and domain files/profiles.

Verified in EAP 6.2.0.ER4.
                
> Change distributed config on address settings to Page instead of Block
> ----------------------------------------------------------------------
>
>                 Key: WFLY-2135
>                 URL: https://issues.jboss.org/browse/WFLY-2135
>             Project: WildFly
>          Issue Type: Feature Request
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 8.0.0.Beta1
>
>
> We have had so many cases of questions about why the producing is blocked when not consuming.
> Users are expecting Page by default, so we should change the default.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 04:24:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Oct 2013 04:24:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2135) Change distributed config on
 address settings to Page instead of Block
In-Reply-To: <JIRA.12501318.1379952235000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501318.1379952235000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501318.1379952235000.18170.1381134243289@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12810349#comment-12810349 ] 

RH Bugzilla Integration commented on WFLY-2135:
-----------------------------------------------

Miroslav Novak <mnovak at redhat.com> changed the Status of [bug 1011074|https://bugzilla.redhat.com/show_bug.cgi?id=1011074] from ON_QA to VERIFIED
                
> Change distributed config on address settings to Page instead of Block
> ----------------------------------------------------------------------
>
>                 Key: WFLY-2135
>                 URL: https://issues.jboss.org/browse/WFLY-2135
>             Project: WildFly
>          Issue Type: Feature Request
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 8.0.0.Beta1
>
>
> We have had so many cases of questions about why the producing is blocked when not consuming.
> Users are expecting Page by default, so we should change the default.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 04:41:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Oct 2013 04:41:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (AS7-5132) Connection timeout to local
 port 9999 with clustered AS 7.1.1.Final
In-Reply-To: <JIRA.12469992.1341600408000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12469992.1341600408000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12469992.1341600408000.18271.1381135263407@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-5132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12810362#comment-12810362 ] 

RH Bugzilla Integration commented on AS7-5132:
----------------------------------------------

Pavel Jelinek <pjelinek at redhat.com> made a comment on [bug 900988|https://bugzilla.redhat.com/show_bug.cgi?id=900988]

org.jboss.as.test.integration.ws.tools.jbws3207.JBWS3207TestCase passes now but 
org.jboss.as.test.manualmode.ejb.shutdown.RemoteCallWhileShuttingDownTestCase fails due to the timeout for EAP 6.2.0 ER3 consistently on Windows on mw Jenkins, e.g.:

https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP6/view/EAP6-AS-Testsuite/job/eap-61-as-testsuite-Win-matrix-OracleJDK6/56/jdk=java16_default,label_exp=w2k8%26%26x86/testReport/org.jboss.as.test.manualmode.ejb.shutdown/RemoteCallWhileShuttingDownTestCase/testServerShutdownRemoteCall/

https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP6/view/EAP6-AS-Testsuite/job/eap-61-as-testsuite-Win-matrix-OracleJDK6/57/jdk=java16_default,label_exp=w2k8%26%26x86/testReport/org.jboss.as.test.manualmode.ejb.shutdown/RemoteCallWhileShuttingDownTestCase/testServerShutdownRemoteCall/

https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP6/view/EAP6-AS-Testsuite/job/eap-61-as-testsuite-Win-matrix-OracleJDK6/55/jdk=java16_default,label_exp=w2k8%26%26x86_64/testReport/org.jboss.as.test.manualmode.ejb.shutdown/RemoteCallWhileShuttingDownTestCase/testServerShutdownRemoteCall/

https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP6/view/EAP6-AS-Testsuite/job/eap-61-as-testsuite-Win-matrix-OracleJDK6/56/jdk=java16_default,label_exp=w2k8%26%26x86_64/testReport/org.jboss.as.test.manualmode.ejb.shutdown/RemoteCallWhileShuttingDownTestCase/testServerShutdownRemoteCall/

https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP6/view/EAP6-AS-Testsuite/job/eap-61-as-testsuite-Win-matrix-OracleJDK6/57/jdk=java16_default,label_exp=w2k8%26%26x86_64/testReport/org.jboss.as.test.manualmode.ejb.shutdown/RemoteCallWhileShuttingDownTestCase/testServerShutdownRemoteCall/

https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP6/view/EAP6-AS-Testsuite/job/eap-61-as-testsuite-Win-matrix-OracleJDK6/58/jdk=java16_default,label_exp=w2k8%26%26x86_64/testReport/org.jboss.as.test.manualmode.ejb.shutdown/RemoteCallWhileShuttingDownTestCase/testServerShutdownRemoteCall/

https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP6/view/EAP6-AS-Testsuite/job/eap-61-as-testsuite-Win-matrix-OracleJDK6/58/jdk=java16_default,label_exp=w2k8r2/testReport/org.jboss.as.test.manualmode.ejb.shutdown/RemoteCallWhileShuttingDownTestCase/testServerShutdownRemoteCall/
                
> Connection timeout to local port 9999 with clustered AS 7.1.1.Final
> -------------------------------------------------------------------
>
>                 Key: AS7-5132
>                 URL: https://issues.jboss.org/browse/AS7-5132
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 7.1.1.Final
>         Environment: Fedora 17 on Amazon EC2
>            Reporter: Jack Lund
>            Assignee: Emanuel Muckenhuber
>              Labels: as7, cluster, domain
>             Fix For: 7.1.3.Final (EAP), EAP 6.1.0.Alpha (7.2.0.Final)
>
>
> A clustered configuration of two AS 7 instances has an issue with the connection to port 9999 timing out when starting up. The instances are configured as per https://docs.jboss.org/author/display/AS71/AS7+Cluster+Howto. On startup, we get the following error randomly for one or more of the server instances:
> {quote}
> [Server:server-two] 16:36:03,492 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC00001: Failed to start service jboss.host.controller.client: org.jboss.msc.service.StartException in service jboss.host.controller.client: java.net.ConnectException: JBAS012144: Could not connect to remote://10.108.25.156:9999. The connection timed out
> [Server:server-two]           at org.jboss.as.server.mgmt.domain.HostControllerServerClient.start(HostControllerServerClient.java:161) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> [Server:server-two]           at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> [Server:server-two]           at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> [Server:server-two]           at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_05]
> [Server:server-two]           at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_05]
> [Server:server-two]           at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_05]
> [Server:server-two] Caused by: java.net.ConnectException: JBAS012144: Could not connect to remote://nephele-beta-jboss1:9999. The connection timed out
> [Server:server-two]           at org.jboss.as.protocol.ProtocolChannelClient.connectSync(ProtocolChannelClient.java:155) [jboss-as-protocol-7.1.1.Final.jar:7.1.1.Final]
> [Server:server-two]           at org.jboss.as.server.mgmt.domain.HostControllerServerConnection.openChannel(HostControllerServerConnection.java:158) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> [Server:server-two]           at org.jboss.as.server.mgmt.domain.HostControllerServerConnection.connect(HostControllerServerConnection.java:86) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> [Server:server-two]           at org.jboss.as.server.mgmt.domain.HostControllerServerClient.start(HostControllerServerClient.java:135) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> [Server:server-two]           ... 5 more
> {quote}
> We usually have to restart the master server instance 10-15 times before all server instances start up without this error, which suggests a race condition between the listening and connecting sockets. Note that this is running on the equivalent of a single-core, fairly slow machine currently, which may be exacerbating the effects.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 04:41:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Oct 2013 04:41:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (AS7-5132) Connection timeout to local
 port 9999 with clustered AS 7.1.1.Final
In-Reply-To: <JIRA.12469992.1341600408000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12469992.1341600408000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12469992.1341600408000.18277.1381135263823@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-5132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12810365#comment-12810365 ] 

RH Bugzilla Integration commented on AS7-5132:
----------------------------------------------

Pavel Jelinek <pjelinek at redhat.com> changed the Status of [bug 900988|https://bugzilla.redhat.com/show_bug.cgi?id=900988] from ON_QA to ASSIGNED
                
> Connection timeout to local port 9999 with clustered AS 7.1.1.Final
> -------------------------------------------------------------------
>
>                 Key: AS7-5132
>                 URL: https://issues.jboss.org/browse/AS7-5132
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 7.1.1.Final
>         Environment: Fedora 17 on Amazon EC2
>            Reporter: Jack Lund
>            Assignee: Emanuel Muckenhuber
>              Labels: as7, cluster, domain
>             Fix For: 7.1.3.Final (EAP), EAP 6.1.0.Alpha (7.2.0.Final)
>
>
> A clustered configuration of two AS 7 instances has an issue with the connection to port 9999 timing out when starting up. The instances are configured as per https://docs.jboss.org/author/display/AS71/AS7+Cluster+Howto. On startup, we get the following error randomly for one or more of the server instances:
> {quote}
> [Server:server-two] 16:36:03,492 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC00001: Failed to start service jboss.host.controller.client: org.jboss.msc.service.StartException in service jboss.host.controller.client: java.net.ConnectException: JBAS012144: Could not connect to remote://10.108.25.156:9999. The connection timed out
> [Server:server-two]           at org.jboss.as.server.mgmt.domain.HostControllerServerClient.start(HostControllerServerClient.java:161) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> [Server:server-two]           at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> [Server:server-two]           at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> [Server:server-two]           at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_05]
> [Server:server-two]           at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_05]
> [Server:server-two]           at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_05]
> [Server:server-two] Caused by: java.net.ConnectException: JBAS012144: Could not connect to remote://nephele-beta-jboss1:9999. The connection timed out
> [Server:server-two]           at org.jboss.as.protocol.ProtocolChannelClient.connectSync(ProtocolChannelClient.java:155) [jboss-as-protocol-7.1.1.Final.jar:7.1.1.Final]
> [Server:server-two]           at org.jboss.as.server.mgmt.domain.HostControllerServerConnection.openChannel(HostControllerServerConnection.java:158) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> [Server:server-two]           at org.jboss.as.server.mgmt.domain.HostControllerServerConnection.connect(HostControllerServerConnection.java:86) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> [Server:server-two]           at org.jboss.as.server.mgmt.domain.HostControllerServerClient.start(HostControllerServerClient.java:135) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> [Server:server-two]           ... 5 more
> {quote}
> We usually have to restart the master server instance 10-15 times before all server instances start up without this error, which suggests a race condition between the listening and connecting sockets. Note that this is running on the equivalent of a single-core, fairly slow machine currently, which may be exacerbating the effects.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 04:41:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Oct 2013 04:41:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (AS7-5350)
 CliArgumentsTestCase.testWrongControler always fails on windows
In-Reply-To: <JIRA.12472341.1344851689000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12472341.1344851689000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12472341.1344851689000.18281.1381135264039@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-5350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12810366#comment-12810366 ] 

RH Bugzilla Integration commented on AS7-5350:
----------------------------------------------

Pavel Jelinek <pjelinek at redhat.com> changed the Status of [bug 900988|https://bugzilla.redhat.com/show_bug.cgi?id=900988] from ON_QA to ASSIGNED
                
> CliArgumentsTestCase.testWrongControler always fails on windows
> ---------------------------------------------------------------
>
>                 Key: AS7-5350
>                 URL: https://issues.jboss.org/browse/AS7-5350
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 7.1.2.Final (EAP), EAP 6.1.0.Alpha (7.2.0.Final)
>         Environment: Windows
>            Reporter: Tomaz Cerar
>            Assignee: Alexey Loubyansky
>             Fix For: EAP 6.1.0.Alpha (7.2.0.Final)
>
>
> org.jboss.as.test.integration.management.cli.CliArgumentsTestCase.testWrongControler consistently fails on windows.
> jenkins build where it can be seen
> http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-master-windows-build/243/testReport/org.jboss.as.test.integration.management.cli/CliArgumentsTestCase/testWrongControler/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 04:41:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Oct 2013 04:41:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (AS7-5350)
 CliArgumentsTestCase.testWrongControler always fails on windows
In-Reply-To: <JIRA.12472341.1344851689000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12472341.1344851689000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12472341.1344851689000.18285.1381135264261@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-5350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12810367#comment-12810367 ] 

RH Bugzilla Integration commented on AS7-5350:
----------------------------------------------

Pavel Jelinek <pjelinek at redhat.com> made a comment on [bug 900988|https://bugzilla.redhat.com/show_bug.cgi?id=900988]

org.jboss.as.test.integration.ws.tools.jbws3207.JBWS3207TestCase passes now but 
org.jboss.as.test.manualmode.ejb.shutdown.RemoteCallWhileShuttingDownTestCase fails due to the timeout for EAP 6.2.0 ER3 consistently on Windows on mw Jenkins, e.g.:

https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP6/view/EAP6-AS-Testsuite/job/eap-61-as-testsuite-Win-matrix-OracleJDK6/56/jdk=java16_default,label_exp=w2k8%26%26x86/testReport/org.jboss.as.test.manualmode.ejb.shutdown/RemoteCallWhileShuttingDownTestCase/testServerShutdownRemoteCall/

https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP6/view/EAP6-AS-Testsuite/job/eap-61-as-testsuite-Win-matrix-OracleJDK6/57/jdk=java16_default,label_exp=w2k8%26%26x86/testReport/org.jboss.as.test.manualmode.ejb.shutdown/RemoteCallWhileShuttingDownTestCase/testServerShutdownRemoteCall/

https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP6/view/EAP6-AS-Testsuite/job/eap-61-as-testsuite-Win-matrix-OracleJDK6/55/jdk=java16_default,label_exp=w2k8%26%26x86_64/testReport/org.jboss.as.test.manualmode.ejb.shutdown/RemoteCallWhileShuttingDownTestCase/testServerShutdownRemoteCall/

https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP6/view/EAP6-AS-Testsuite/job/eap-61-as-testsuite-Win-matrix-OracleJDK6/56/jdk=java16_default,label_exp=w2k8%26%26x86_64/testReport/org.jboss.as.test.manualmode.ejb.shutdown/RemoteCallWhileShuttingDownTestCase/testServerShutdownRemoteCall/

https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP6/view/EAP6-AS-Testsuite/job/eap-61-as-testsuite-Win-matrix-OracleJDK6/57/jdk=java16_default,label_exp=w2k8%26%26x86_64/testReport/org.jboss.as.test.manualmode.ejb.shutdown/RemoteCallWhileShuttingDownTestCase/testServerShutdownRemoteCall/

https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP6/view/EAP6-AS-Testsuite/job/eap-61-as-testsuite-Win-matrix-OracleJDK6/58/jdk=java16_default,label_exp=w2k8%26%26x86_64/testReport/org.jboss.as.test.manualmode.ejb.shutdown/RemoteCallWhileShuttingDownTestCase/testServerShutdownRemoteCall/

https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP6/view/EAP6-AS-Testsuite/job/eap-61-as-testsuite-Win-matrix-OracleJDK6/58/jdk=java16_default,label_exp=w2k8r2/testReport/org.jboss.as.test.manualmode.ejb.shutdown/RemoteCallWhileShuttingDownTestCase/testServerShutdownRemoteCall/
                
> CliArgumentsTestCase.testWrongControler always fails on windows
> ---------------------------------------------------------------
>
>                 Key: AS7-5350
>                 URL: https://issues.jboss.org/browse/AS7-5350
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 7.1.2.Final (EAP), EAP 6.1.0.Alpha (7.2.0.Final)
>         Environment: Windows
>            Reporter: Tomaz Cerar
>            Assignee: Alexey Loubyansky
>             Fix For: EAP 6.1.0.Alpha (7.2.0.Final)
>
>
> org.jboss.as.test.integration.management.cli.CliArgumentsTestCase.testWrongControler consistently fails on windows.
> jenkins build where it can be seen
> http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-master-windows-build/243/testReport/org.jboss.as.test.integration.management.cli/CliArgumentsTestCase/testWrongControler/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 04:43:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Oct 2013 04:43:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1409) custom mail server should
 allow definition of independent properties
In-Reply-To: <JIRA.12493068.1369815646000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493068.1369815646000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493068.1369815646000.18291.1381135382848@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12810369#comment-12810369 ] 

RH Bugzilla Integration commented on WFLY-1409:
-----------------------------------------------

Jakub Cechacek <jcechace at redhat.com> changed the Status of [bug 968200|https://bugzilla.redhat.com/show_bug.cgi?id=968200] from ON_QA to VERIFIED
                
> custom mail server should allow definition of independent properties
> --------------------------------------------------------------------
>
>                 Key: WFLY-1409
>                 URL: https://issues.jboss.org/browse/WFLY-1409
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Mail
>            Reporter: Jakub Cechacek
>            Assignee: Tomaz Cerar
>            Priority: Minor
>             Fix For: 8.0.0.Beta1
>
>
> Current implementation doesn't allow definition of independent properties - instead they will always have form of "mail.$ServerName.someprop". Thus it's not possible to setup properties such as "mail.transport.protocol"[1] inside custom server. 
> Also customer will unlikely design custom transport protocol from scratch. More often it will be just a wrapper around existing protocol such as smtp with some additional functionality (this is also case of [2]). However as a workaround one can define custom server together with server for underlying protocol within one mail session. 
> [1] which will cause session.getTransport(); to return null as default protocol is not set. 
> [2] https://c.na7.visual.force.com/apex/Case_View?id=500A000000A4N8b

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 04:43:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Oct 2013 04:43:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1409) custom mail server should
 allow definition of independent properties
In-Reply-To: <JIRA.12493068.1369815646000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493068.1369815646000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493068.1369815646000.18295.1381135383133@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12810370#comment-12810370 ] 

RH Bugzilla Integration commented on WFLY-1409:
-----------------------------------------------

Jakub Cechacek <jcechace at redhat.com> made a comment on [bug 968200|https://bugzilla.redhat.com/show_bug.cgi?id=968200]

Verified 6.2.0.ER4
                
> custom mail server should allow definition of independent properties
> --------------------------------------------------------------------
>
>                 Key: WFLY-1409
>                 URL: https://issues.jboss.org/browse/WFLY-1409
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Mail
>            Reporter: Jakub Cechacek
>            Assignee: Tomaz Cerar
>            Priority: Minor
>             Fix For: 8.0.0.Beta1
>
>
> Current implementation doesn't allow definition of independent properties - instead they will always have form of "mail.$ServerName.someprop". Thus it's not possible to setup properties such as "mail.transport.protocol"[1] inside custom server. 
> Also customer will unlikely design custom transport protocol from scratch. More often it will be just a wrapper around existing protocol such as smtp with some additional functionality (this is also case of [2]). However as a workaround one can define custom server together with server for underlying protocol within one mail session. 
> [1] which will cause session.getTransport(); to return null as default protocol is not set. 
> [2] https://c.na7.visual.force.com/apex/Case_View?id=500A000000A4N8b

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 04:43:03 2013
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Mon, 7 Oct 2013 04:43:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1837) manual module testoutput is a
 bit disturbing NPE and dependencies missing
In-Reply-To: <JIRA.12498051.1375789235000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498051.1375789235000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498051.1375789235000.18298.1381135383339@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carlo de Wolf updated WFLY-1837:
--------------------------------

    Fix Version/s:     (was: 8.0.0.CR1)

    
> manual module testoutput is a bit disturbing NPE and dependencies missing
> -------------------------------------------------------------------------
>
>                 Key: WFLY-1837
>                 URL: https://issues.jboss.org/browse/WFLY-1837
>             Project: WildFly
>          Issue Type: Task
>          Components: Test Suite
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Bartosz Baranowski
>            Assignee: JBoss SET
>
> Manual testmodule shows a lot of NPEs and dependency issues:
> {noformat}
> [org.jboss.as.ejb3] (EJB default - 2) JBAS014249: Error invoking method public abstract void org.jboss.as.test.manualmode.ejb.shutdown.RemoteLatch.testDone() on bean named LatchBean for appname  modulename dep1 distinctname : java.lang.NullPointerException
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:322)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:70)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:203)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> 13:06:07,613 ERROR [org.jboss.as.ejb3] (EJB default - 2) JBAS014250: Could not write method invocation failure for method public abstract void org.jboss.as.test.manualmode.ejb.shutdown.RemoteLatch.testDone() on bean named LatchBean for appname  modulename dep1 distinctname  due to: java.io.IOException: Stream is closed
> 	at org.xnio.streams.BufferPipeOutputStream.closed(BufferPipeOutputStream.java:58) [xnio-api-3.1.0.CR3.jar:3.1.0.CR3]
> 	at org.xnio.streams.BufferPipeOutputStream.checkClosed(BufferPipeOutputStream.java:64) [xnio-api-3.1.0.CR3.jar:3.1.0.CR3]
> 	at org.xnio.streams.BufferPipeOutputStream.write(BufferPipeOutputStream.java:90) [xnio-api-3.1.0.CR3.jar:3.1.0.CR3]
> 	at org.jboss.remoting3.remote.OutboundMessage.write(OutboundMessage.java:252)
> 	at java.io.DataOutputStream.write(DataOutputStream.java:107) [rt.jar:1.7.0_25]
> 	at org.jboss.as.ejb3.remote.protocol.AbstractMessageHandler$1.write(AbstractMessageHandler.java:217)
> 	at org.jboss.marshalling.OutputStreamByteOutput.write(OutputStreamByteOutput.java:56)
> 	at org.jboss.marshalling.SimpleDataOutput.shallowFlush(SimpleDataOutput.java:328)
> 	at org.jboss.marshalling.river.RiverMarshaller.writeString(RiverMarshaller.java:1451)
> 	at org.jboss.marshalling.river.RiverMarshaller.writeNewSerializableClass(RiverMarshaller.java:1362)
> 	at org.jboss.marshalling.river.RiverMarshaller.writeSerializableClass(RiverMarshaller.java:1345)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:883)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
> 	at org.jboss.marshalling.river.RiverObjectOutputStream.defaultWriteObject(RiverObjectOutputStream.java:159)
> 	at java.lang.Throwable.writeObject(Throwable.java:984) [rt.jar:1.7.0_25]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_25]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_25]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_25]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_25]
> 	at org.jboss.marshalling.reflect.SerializableClass.callWriteObject(SerializableClass.java:180)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1007)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:998)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:998)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:998)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> 	at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62)
> 	at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119)
> 	at org.jboss.as.ejb3.remote.protocol.AbstractMessageHandler.writeException(AbstractMessageHandler.java:112)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$400(MethodInvocationMessageHandler.java:70)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:213)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> Caused by: an exception which occurred:
> 	in field suppressedExceptions
> 	in object java.lang.NullPointerException at 18e5c476
> {noformat}
> {noformat}
> 13:01:23,032 ERROR [org.jboss.as.controller.management-operation] (pool-2-thread-1) JBAS014612: Operation ("add") failed - address: ([
>     ("host" => "master"),
>     ("core-service" => "management"),
>     ("management-interface" => "http-interface")
> ]): java.lang.NullPointerException
> 	at org.jboss.as.host.controller.operations.HttpManagementAddHandler.installHttpManagementServices(HttpManagementAddHandler.java:137) [wildfly-host-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
> 	at org.jboss.as.host.controller.operations.HttpManagementAddHandler.performRuntime(HttpManagementAddHandler.java:97) [wildfly-host-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:75) [wildfly-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
> {noformat}
> {noformat}
> 13:01:23,493 ERROR [org.jboss.as.controller.management-operation] (pool-2-thread-1) JBAS014613: Operation ("add") failed - address: ([
>     ("core-service" => "management"),
>     ("management-interface" => "native-interface")
> ]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => [
>     "jboss.remoting.authentication_provider.management is missing [jboss.server.path.\"jboss.server.temp.dir\"]",
>     "jboss.remoting.endpoint.management.management.operation.handler is missing [jboss.as.server-controller]",
>     "jboss.remoting.endpoint.management.channel.management is missing [jboss.remoting.endpoint.management.shutdown.executor]",
>     "jboss.remoting.server.management is missing [jboss.binding.management-native, jboss.socket-binding-manager]"
> ]}
> 13:01:23,494 INFO  [org.jboss.as.controller] (pool-2-thread-1) JBAS014774: Service status report
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.as.server-controller (missing) dependents: [service jboss.remoting.endpoint.management.management.operation.handler] 
>       service jboss.binding.management-native (missing) dependents: [service jboss.remoting.server.management] 
>       service jboss.remoting.endpoint.management.shutdown.executor (missing) dependents: [service jboss.remoting.endpoint.management.channel.management] 
>       service jboss.server.path."jboss.server.temp.dir" (missing) dependents: [service jboss.remoting.authentication_provider.management] 
>       service jboss.socket-binding-manager (missing) dependents: [service jboss.remoting.server.management] 
> 13:01:23,495 INFO  [org.jboss.as.server] (pool-2-thread-1) JBAS015888: Creating http management service using socket-binding (management-http)
> 13:01:23,496 ERROR [org.jboss.as.controller.management-operation] (pool-2-thread-1) JBAS014612: Operation ("add") failed - address: ([
>     ("core-service" => "management"),
>     ("management-interface" => "http-interface")
> ]): org.jboss.msc.service.ServiceNotFoundException: Service service jboss.server.environment not found
> 	at org.jboss.msc.service.ServiceContainerImpl.getRequiredService(ServiceContainerImpl.java:668) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at org.jboss.as.controller.OperationContextImpl$OperationContextServiceRegistry.getRequiredService(OperationContextImpl.java:1068) [wildfly-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 04:45:04 2013
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Mon, 7 Oct 2013 04:45:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1836) manual module
 SSLEJBRemoteClientTestCase keeps freezing
In-Reply-To: <JIRA.12498050.1375789021000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498050.1375789021000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498050.1375789021000.18302.1381135504520@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carlo de Wolf updated WFLY-1836:
--------------------------------

    Fix Version/s:     (was: 8.0.0.CR1)

    
> manual module SSLEJBRemoteClientTestCase keeps freezing
> -------------------------------------------------------
>
>                 Key: WFLY-1836
>                 URL: https://issues.jboss.org/browse/WFLY-1836
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Bartosz Baranowski
>            Assignee: JBoss SET
>
> CI job keeps freezing on this test. In local run, it does not fail however:
> execution in batch: 102s+
> standalone        : ~45s

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 04:59:03 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Mon, 7 Oct 2013 04:59:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2220) Unable to reload server after
 adding role and executing :reload
In-Reply-To: <JIRA.12502221.1380896422000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502221.1380896422000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502221.1380896422000.18354.1381136343383@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ladislav Thon updated WFLY-2220:
--------------------------------

        Parent: WFLY-490
    Issue Type: Sub-task  (was: Bug)

    
> Unable to reload server after adding role and executing :reload
> ---------------------------------------------------------------
>
>                 Key: WFLY-2220
>                 URL: https://issues.jboss.org/browse/WFLY-2220
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.CR1
>
>
> Start a clean build of WildFly 8 and execute the following commands in the CLI: -
> {code}
> [standalone at localhost:9990 /connect
> [standalone at localhost:9990 /] ./core-service=management/access=authorization/role-mapping=Operator:add
> {"outcome" => "success"}
> [standalone at localhost:9990 /] :reload
> {
>     "outcome" => "success",
>     "result" => undefined
> }
> [standalone at localhost:9990 /] 
> {code}
> Results in the following error and the server shuts down: -
> {code}
> 15:15:02,275 INFO  [org.jboss.as.server] (Controller Boot Thread) JBAS015888: Creating http management service using socket-binding (management-http)
> 15:15:02,278 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014612: Operation ("add") failed - address: ([
>     ("core-service" => "management"),
>     ("access" => "authorization"),
>     ("role-mapping" => "SuperUser")
> ]): java.lang.UnsupportedOperationException
> 	at java.util.Collections$UnmodifiableMap.put(Collections.java:1342) [rt.jar:1.7.0_17]
> 	at org.jboss.as.controller.access.management.WritableAuthorizerConfiguration.addRoleMappingImmediate(WritableAuthorizerConfiguration.java:163) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.domain.management.access.RoleMappingAdd$1.execute(RoleMappingAdd.java:76) [wildfly-domain-management-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:609) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:487) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:321) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:290) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:356) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:331) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:252) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> 15:15:02,287 INFO  [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.remoting.endpoint.management (missing) dependents: [service jboss.remoting.management.channel.registry] 
> 15:15:02,290 FATAL [org.jboss.as.server] (Controller Boot Thread) JBAS015957: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> 15:15:02,297 INFO  [org.jboss.as] (MSC service thread 1-1) JBAS015950: WildFly 8.0.0.Beta1-SNAPSHOT "WildFly" stopped in 2ms
> {code}
> What is interesting is that the server is manually startable to something has gone wrong regarding resetting the runtime state of RBAC at the time of the reload.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 05:22:02 2013
From: jira-events at lists.jboss.org (Bartosz Baranowski (JIRA))
Date: Mon, 7 Oct 2013 05:22:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2217) Enable reload tests
In-Reply-To: <JIRA.12502203.1380888864000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502203.1380888864000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502203.1380888864000.18420.1381137722872@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bartosz Baranowski updated WFLY-2217:
-------------------------------------

    Priority: Blocker  (was: Major)

    
> Enable reload tests
> -------------------
>
>                 Key: WFLY-2217
>                 URL: https://issues.jboss.org/browse/WFLY-2217
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Test Suite
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Bartosz Baranowski
>            Assignee: Bartosz Baranowski
>            Priority: Blocker
>
> Tests need not stay ignored any longer!
> Some tests which :reload are still ignored, even though :reload has been fixed ( well, it seems there is more to it due to other code changes )

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 05:31:02 2013
From: jira-events at lists.jboss.org (Bartosz Baranowski (JIRA))
Date: Mon, 7 Oct 2013 05:31:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2217) Enable reload tests
In-Reply-To: <JIRA.12502203.1380888864000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502203.1380888864000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502203.1380888864000.18441.1381138262979@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bartosz Baranowski updated WFLY-2217:
-------------------------------------

    Comment: was deleted

(was: A comment with security level 'JBoss Employee' was removed.)

    
> Enable reload tests
> -------------------
>
>                 Key: WFLY-2217
>                 URL: https://issues.jboss.org/browse/WFLY-2217
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Test Suite
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Bartosz Baranowski
>            Assignee: Bartosz Baranowski
>            Priority: Blocker
>
> Tests need not stay ignored any longer!
> Some tests which :reload are still ignored, even though :reload has been fixed ( well, it seems there is more to it due to other code changes )

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 05:31:03 2013
From: jira-events at lists.jboss.org (Bartosz Baranowski (JIRA))
Date: Mon, 7 Oct 2013 05:31:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2217) Enable reload tests
In-Reply-To: <JIRA.12502203.1380888864000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502203.1380888864000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502203.1380888864000.18443.1381138263087@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bartosz Baranowski updated WFLY-2217:
-------------------------------------

    Priority: Major  (was: Blocker)

    
> Enable reload tests
> -------------------
>
>                 Key: WFLY-2217
>                 URL: https://issues.jboss.org/browse/WFLY-2217
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Test Suite
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Bartosz Baranowski
>            Assignee: Bartosz Baranowski
>
> Tests need not stay ignored any longer!
> Some tests which :reload are still ignored, even though :reload has been fixed ( well, it seems there is more to it due to other code changes )

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 05:37:02 2013
From: jira-events at lists.jboss.org (Bartosz Baranowski (JIRA))
Date: Mon, 7 Oct 2013 05:37:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2227) Upgrade IronJacamar to
	1.1.1.[CR1|Final]
In-Reply-To: <JIRA.12502301.1381138519647@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502301.1381138519647@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502301.1381138519647.18451.1381138622651@jira02.app.mwc.hst.phx2.redhat.com>

Bartosz Baranowski created WFLY-2227:
----------------------------------------

             Summary: Upgrade IronJacamar to 1.1.1.[CR1|Final]
                 Key: WFLY-2227
                 URL: https://issues.jboss.org/browse/WFLY-2227
             Project: WildFly
          Issue Type: Component  Upgrade
          Components: JCA
    Affects Versions: 8.0.0.Beta1
            Reporter: Bartosz Baranowski
            Assignee: Jason Greene
            Priority: Critical
             Fix For: 8.0.0.CR1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 06:16:03 2013
From: jira-events at lists.jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Mon, 7 Oct 2013 06:16:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-199) The entire kie build should
 work on maven 3.1.0 too
In-Reply-To: <JIRA.12497109.1374566859000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497109.1374566859000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497109.1374566859000.18509.1381140963420@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12810398#comment-12810398 ] 

Michael Biarnes Kiefer commented on DROOLS-199:
-----------------------------------------------

I run mvn clean install -Dfull with maven version 3.1.0; droolsjbpm-tools didn't copmpile:

https://gist.github.com/mbiarnes/6865529



                
> The entire kie build should work on maven 3.1.0 too
> ---------------------------------------------------
>
>                 Key: DROOLS-199
>                 URL: https://issues.jboss.org/browse/DROOLS-199
>             Project: Drools
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Geoffrey De Smet
>            Assignee: Michael Biarnes Kiefer
>
> To reproduce:
> - Install maven 3.1.0
> - Run mvn-all.sh clean install -Dfull
> Note: Any changes to the pom must still allow them to run with 3.0.5 too.
> 1) At least droolsjbpm-tools (drools-eclipse) is guaranteed to fail because it uses an older tycho version and only tycho 0.18.1 is compatible with maven 3.1.0 according to the tycho mailing list.
> So the maven tycho plugin will need to be upgraded to 0.18.1 (which works with maven 3.0.5 too - so they say).
> 2) There might be other surprises...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 06:44:02 2013
From: jira-events at lists.jboss.org (Jozef Hartinger (JIRA))
Date: Mon, 7 Oct 2013 06:44:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2228) EJB and web module cannot
 have the same name in an ear
In-Reply-To: <JIRA.12502307.1381142531826@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502307.1381142531826@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502307.1381142531826.18592.1381142642749@jira02.app.mwc.hst.phx2.redhat.com>

Jozef Hartinger created WFLY-2228:
-------------------------------------

             Summary: EJB and web module cannot have the same name in an ear
                 Key: WFLY-2228
                 URL: https://issues.jboss.org/browse/WFLY-2228
             Project: WildFly
          Issue Type: Bug
    Affects Versions: 8.0.0.Beta1
            Reporter: Jozef Hartinger
            Assignee: Eduardo Martins
             Fix For: 8.0.0.CR1
         Attachments: weld-translator.ear

Having an ear project like this:

{code}
weld.translator.ear
+--weld-translator.war
+--weld-translator.jar
{code}

I am no longer able to deploy it to WildFly. This is a regression caused by the following commit: https://github.com/wildfly/wildfly/commit/d4aecbe5d2b241befa5da43b19c2d0712621ac0a

The deployment exception:
{noformat}
10:45:56,835 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874: WildFly 8.0.0.Beta1 "WildFly" started in 3433ms - Started 180 of 217 services (62 services are lazy, passive or on-demand)
10:46:22,816 INFO  [org.jboss.as.repository] (management-handler-thread - 1) JBAS014900: Content added at location /home/jharting/jboss/Weld/wildfly-8.0.0.Beta1/standalone/data/content/41/4cdfd11cd5283d5356778f396c618ca2477c6b/content
10:46:22,842 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015876: Starting deployment of "weld-translator.ear" (runtime-name: "weld-translator.ear")
10:46:22,912 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015876: Starting deployment of "null" (runtime-name: "weld-jsf-translator-war-2.1.0-SNAPSHOT.war")
10:46:22,912 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015876: Starting deployment of "null" (runtime-name: "weld-jsf-translator-ejb-2.1.0-SNAPSHOT.jar")
10:46:23,147 INFO  [org.jboss.weld.deployer] (MSC service thread 1-8) JBAS016002: Processing weld deployment weld-translator.ear
10:46:23,192 INFO  [org.hibernate.validator.internal.util.Version] (MSC service thread 1-8) HV000001: Hibernate Validator 5.0.1.Final
10:46:23,340 INFO  [org.jboss.weld.deployer] (MSC service thread 1-1) JBAS016002: Processing weld deployment weld-jsf-translator-war-2.1.0-SNAPSHOT.war
10:46:23,353 INFO  [org.jboss.weld.deployer] (MSC service thread 1-6) JBAS016002: Processing weld deployment weld-jsf-translator-ejb-2.1.0-SNAPSHOT.jar
10:46:23,366 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-6) JNDI bindings for session bean named TranslatorControllerBean in deployment unit subdeployment "weld-jsf-translator-ejb-2.1.0-SNAPSHOT.jar" of deployment "weld-translator.ear" are as follows:

        java:global/weld-translator/weld-jsf-translator-ejb-2.1.0-SNAPSHOT/TranslatorControllerBean!org.jboss.weld.examples.translator.TranslatorController
        java:app/weld-jsf-translator-ejb-2.1.0-SNAPSHOT/TranslatorControllerBean!org.jboss.weld.examples.translator.TranslatorController
        java:module/TranslatorControllerBean!org.jboss.weld.examples.translator.TranslatorController
        java:global/weld-translator/weld-jsf-translator-ejb-2.1.0-SNAPSHOT/TranslatorControllerBean
        java:app/weld-jsf-translator-ejb-2.1.0-SNAPSHOT/TranslatorControllerBean
        java:module/TranslatorControllerBean

10:46:23,369 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-6) JNDI bindings for session bean named SentenceTranslator in deployment unit subdeployment "weld-jsf-translator-ejb-2.1.0-SNAPSHOT.jar" of deployment "weld-translator.ear" are as follows:

        java:global/weld-translator/weld-jsf-translator-ejb-2.1.0-SNAPSHOT/SentenceTranslator!org.jboss.weld.examples.translator.Translator
        java:app/weld-jsf-translator-ejb-2.1.0-SNAPSHOT/SentenceTranslator!org.jboss.weld.examples.translator.Translator
        java:module/SentenceTranslator!org.jboss.weld.examples.translator.Translator
        java:global/weld-translator/weld-jsf-translator-ejb-2.1.0-SNAPSHOT/SentenceTranslator
        java:app/weld-jsf-translator-ejb-2.1.0-SNAPSHOT/SentenceTranslator
        java:module/SentenceTranslator

10:46:23,392 INFO  [org.jboss.weld.deployer] (MSC service thread 1-1) JBAS016005: Starting Services for CDI deployment: weld-translator.ear
10:46:23,430 INFO  [org.jboss.weld.Version] (MSC service thread 1-1) WELD-000900: 2.1.0 (2013-10-07 08:46)
10:46:23,448 INFO  [org.jboss.weld.deployer] (MSC service thread 1-1) JBAS016008: Starting weld service for deployment weld-translator.ear
10:46:24,654 INFO  [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-8) Initializing Mojarra 2.2.3-jbossorg-1 20130910-1739 for context '/weld-translator'
10:46:25,490 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) JBAS018210: Register web context: /weld-translator
10:46:25,569 INFO  [org.jboss.as.server] (management-handler-thread - 1) JBAS018559: Deployed "weld-translator.ear" (runtime-name : "weld-translator.ear")
10:46:43,715 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) JBAS018224: Unregister web context: /weld-translator
10:46:43,731 INFO  [org.jboss.weld.deployer] (MSC service thread 1-7) JBAS016009: Stopping weld service for deployment weld-translator.ear
10:46:43,775 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015877: Stopped deployment null (runtime-name: weld-jsf-translator-ejb-2.1.0-SNAPSHOT.jar) in 65ms
10:46:43,777 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-6) JBAS015877: Stopped deployment null (runtime-name: weld-jsf-translator-war-2.1.0-SNAPSHOT.war) in 68ms
10:46:43,779 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-6) JBAS015877: Stopped deployment weld-translator.ear (runtime-name: weld-translator.ear) in 70ms
10:46:43,820 INFO  [org.jboss.as.repository] (management-handler-thread - 2) JBAS014901: Content removed from location /home/jharting/jboss/Weld/wildfly-8.0.0.Beta1/standalone/data/content/41/4cdfd11cd5283d5356778f396c618ca2477c6b/content
10:46:43,821 INFO  [org.jboss.as.server] (management-handler-thread - 2) JBAS018558: Undeployed "weld-translator.ear" (runtime-name: "weld-translator.ear")
10:47:10,201 INFO  [org.jboss.as.repository] (management-handler-thread - 3) JBAS014900: Content added at location /home/jharting/jboss/Weld/wildfly-8.0.0.Beta1/standalone/data/content/d9/22ca6b33304b2cccc227cdf8f6aadeedad88f9/content
10:47:10,203 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015876: Starting deployment of "weld-translator.ear" (runtime-name: "weld-translator.ear")
10:47:10,223 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015876: Starting deployment of "null" (runtime-name: "weld-translator.jar")
10:47:10,223 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015876: Starting deployment of "null" (runtime-name: "weld-translator.war")
10:47:10,297 INFO  [org.jboss.weld.deployer] (MSC service thread 1-5) JBAS016002: Processing weld deployment weld-translator.ear
10:47:10,310 INFO  [org.jboss.weld.deployer] (MSC service thread 1-6) JBAS016002: Processing weld deployment weld-translator.war
10:47:10,311 INFO  [org.jboss.weld.deployer] (MSC service thread 1-2) JBAS016002: Processing weld deployment weld-translator.jar
10:47:10,314 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-2) JNDI bindings for session bean named TranslatorControllerBean in deployment unit subdeployment "weld-translator.jar" of deployment "weld-translator.ear" are as follows:

        java:global/weld-translator/weld-translator.jar/TranslatorControllerBean!org.jboss.weld.examples.translator.TranslatorController
        java:app/weld-translator.jar/TranslatorControllerBean!org.jboss.weld.examples.translator.TranslatorController
        java:module/TranslatorControllerBean!org.jboss.weld.examples.translator.TranslatorController
        java:global/weld-translator/weld-translator.jar/TranslatorControllerBean
        java:app/weld-translator.jar/TranslatorControllerBean
        java:module/TranslatorControllerBean

10:47:10,314 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-2) JNDI bindings for session bean named SentenceTranslator in deployment unit subdeployment "weld-translator.jar" of deployment "weld-translator.ear" are as follows:

        java:global/weld-translator/weld-translator.jar/SentenceTranslator!org.jboss.weld.examples.translator.Translator
        java:app/weld-translator.jar/SentenceTranslator!org.jboss.weld.examples.translator.Translator
        java:module/SentenceTranslator!org.jboss.weld.examples.translator.Translator
        java:global/weld-translator/weld-translator.jar/SentenceTranslator
        java:app/weld-translator.jar/SentenceTranslator
        java:module/SentenceTranslator

10:47:10,318 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.subunit."weld-translator.ear"."weld-translator.jar".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."weld-translator.ear"."weld-translator.jar".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of subdeployment "weld-translator.jar" of deployment "weld-translator.ear"
        at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Beta1.jar:8.0.0.Beta1]
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
        at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.concurrent.ee.context.config.weld-translator.weld-translator is already registered
        at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
        at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
        at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:767) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
        at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
        at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2384) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
        at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
        at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2384) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
        at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
        at org.jboss.as.ee.concurrent.deployers.EEConcurrentContextProcessor.setupConcurrentContext(EEConcurrentContextProcessor.java:110)
        at org.jboss.as.ee.concurrent.deployers.EEConcurrentContextProcessor.processModuleDescription(EEConcurrentContextProcessor.java:71)
        at org.jboss.as.ee.concurrent.deployers.EEConcurrentContextProcessor.deploy(EEConcurrentContextProcessor.java:54)
        at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta1.jar:8.0.0.Beta1]
        ... 5 more

10:47:10,329 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "weld-translator.ear")]) - failure description: {
    "JBAS014671: Failed services" => {"jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.jar\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.jar\".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of subdeployment \"weld-translator.jar\" of deployment \"weld-translator.ear\"
    Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.concurrent.ee.context.config.weld-translator.weld-translator is already registered"},
    "JBAS014771: Services with missing/unavailable dependencies" => [
        "jboss.deployment.unit.\"weld-translator.ear\".weld.weldClassIntrospector is missing [jboss.deployment.unit.\"weld-translator.ear\".beanmanager]",
        "jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.war\".batch is missing [jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.war\".beanmanager]",
        "jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.war\".weld.weldClassIntrospector is missing [jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.war\".beanmanager]"
    ]
}
10:47:10,338 ERROR [org.jboss.as.server] (management-handler-thread - 3) JBAS015870: Deploy of deployment "weld-translator.ear" was rolled back with the following failure message: 
{
    "JBAS014671: Failed services" => {"jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.jar\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.jar\".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of subdeployment \"weld-translator.jar\" of deployment \"weld-translator.ear\"
    Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.concurrent.ee.context.config.weld-translator.weld-translator is already registered"},
    "JBAS014771: Services with missing/unavailable dependencies" => [
        "jboss.deployment.unit.\"weld-translator.ear\".weld.weldClassIntrospector is missing [jboss.deployment.unit.\"weld-translator.ear\".beanmanager]",
        "jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.war\".batch is missing [jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.war\".beanmanager]",
        "jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.war\".weld.weldClassIntrospector is missing [jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.war\".beanmanager]"
    ]
}
10:47:10,351 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015877: Stopped deployment null (runtime-name: weld-translator.jar) in 18ms
10:47:10,354 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015877: Stopped deployment null (runtime-name: weld-translator.war) in 21ms
10:47:10,356 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015877: Stopped deployment weld-translator.ear (runtime-name: weld-translator.ear) in 23ms
10:47:10,358 INFO  [org.jboss.as.controller] (management-handler-thread - 3) JBAS014774: Service status report
JBAS014775:    New missing/unsatisfied dependencies:
      service jboss.deployment.subunit."weld-translator.ear"."weld-translator.war".beanmanager (missing) dependents: [service jboss.deployment.subunit."weld-translator.ear"."weld-translator.war".weld.weldClassIntrospector, service jboss.deployment.subunit."weld-translator.ear"."weld-translator.war".batch] 
      service jboss.deployment.unit."weld-translator.ear".beanmanager (missing) dependents: [service jboss.deployment.unit."weld-translator.ear".weld.weldClassIntrospector] 
      service jboss.naming.context.java.module.weld-translator."weld-translator.war" (missing) dependents: [service jboss.deployment.subunit."weld-translator.ear"."weld-translator.war".INSTALL] 
JBAS014777:   Services which failed to start:      service jboss.deployment.subunit."weld-translator.ear"."weld-translator.jar".POST_MODULE
{noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 06:44:02 2013
From: jira-events at lists.jboss.org (Jozef Hartinger (JIRA))
Date: Mon, 7 Oct 2013 06:44:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2228) EJB and web module cannot
 have the same name in an ear
In-Reply-To: <JIRA.12502307.1381142531000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502307.1381142531000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502307.1381142531000.18596.1381142642991@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Hartinger updated WFLY-2228:
----------------------------------

    Attachment: weld-translator.ear


Attached reproducer
                
> EJB and web module cannot have the same name in an ear
> ------------------------------------------------------
>
>                 Key: WFLY-2228
>                 URL: https://issues.jboss.org/browse/WFLY-2228
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Jozef Hartinger
>            Assignee: Eduardo Martins
>             Fix For: 8.0.0.CR1
>
>         Attachments: weld-translator.ear
>
>
> Having an ear project like this:
> {code}
> weld.translator.ear
> +--weld-translator.war
> +--weld-translator.jar
> {code}
> I am no longer able to deploy it to WildFly. This is a regression caused by the following commit: https://github.com/wildfly/wildfly/commit/d4aecbe5d2b241befa5da43b19c2d0712621ac0a
> The deployment exception:
> {noformat}
> 10:45:56,835 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874: WildFly 8.0.0.Beta1 "WildFly" started in 3433ms - Started 180 of 217 services (62 services are lazy, passive or on-demand)
> 10:46:22,816 INFO  [org.jboss.as.repository] (management-handler-thread - 1) JBAS014900: Content added at location /home/jharting/jboss/Weld/wildfly-8.0.0.Beta1/standalone/data/content/41/4cdfd11cd5283d5356778f396c618ca2477c6b/content
> 10:46:22,842 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015876: Starting deployment of "weld-translator.ear" (runtime-name: "weld-translator.ear")
> 10:46:22,912 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015876: Starting deployment of "null" (runtime-name: "weld-jsf-translator-war-2.1.0-SNAPSHOT.war")
> 10:46:22,912 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015876: Starting deployment of "null" (runtime-name: "weld-jsf-translator-ejb-2.1.0-SNAPSHOT.jar")
> 10:46:23,147 INFO  [org.jboss.weld.deployer] (MSC service thread 1-8) JBAS016002: Processing weld deployment weld-translator.ear
> 10:46:23,192 INFO  [org.hibernate.validator.internal.util.Version] (MSC service thread 1-8) HV000001: Hibernate Validator 5.0.1.Final
> 10:46:23,340 INFO  [org.jboss.weld.deployer] (MSC service thread 1-1) JBAS016002: Processing weld deployment weld-jsf-translator-war-2.1.0-SNAPSHOT.war
> 10:46:23,353 INFO  [org.jboss.weld.deployer] (MSC service thread 1-6) JBAS016002: Processing weld deployment weld-jsf-translator-ejb-2.1.0-SNAPSHOT.jar
> 10:46:23,366 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-6) JNDI bindings for session bean named TranslatorControllerBean in deployment unit subdeployment "weld-jsf-translator-ejb-2.1.0-SNAPSHOT.jar" of deployment "weld-translator.ear" are as follows:
>         java:global/weld-translator/weld-jsf-translator-ejb-2.1.0-SNAPSHOT/TranslatorControllerBean!org.jboss.weld.examples.translator.TranslatorController
>         java:app/weld-jsf-translator-ejb-2.1.0-SNAPSHOT/TranslatorControllerBean!org.jboss.weld.examples.translator.TranslatorController
>         java:module/TranslatorControllerBean!org.jboss.weld.examples.translator.TranslatorController
>         java:global/weld-translator/weld-jsf-translator-ejb-2.1.0-SNAPSHOT/TranslatorControllerBean
>         java:app/weld-jsf-translator-ejb-2.1.0-SNAPSHOT/TranslatorControllerBean
>         java:module/TranslatorControllerBean
> 10:46:23,369 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-6) JNDI bindings for session bean named SentenceTranslator in deployment unit subdeployment "weld-jsf-translator-ejb-2.1.0-SNAPSHOT.jar" of deployment "weld-translator.ear" are as follows:
>         java:global/weld-translator/weld-jsf-translator-ejb-2.1.0-SNAPSHOT/SentenceTranslator!org.jboss.weld.examples.translator.Translator
>         java:app/weld-jsf-translator-ejb-2.1.0-SNAPSHOT/SentenceTranslator!org.jboss.weld.examples.translator.Translator
>         java:module/SentenceTranslator!org.jboss.weld.examples.translator.Translator
>         java:global/weld-translator/weld-jsf-translator-ejb-2.1.0-SNAPSHOT/SentenceTranslator
>         java:app/weld-jsf-translator-ejb-2.1.0-SNAPSHOT/SentenceTranslator
>         java:module/SentenceTranslator
> 10:46:23,392 INFO  [org.jboss.weld.deployer] (MSC service thread 1-1) JBAS016005: Starting Services for CDI deployment: weld-translator.ear
> 10:46:23,430 INFO  [org.jboss.weld.Version] (MSC service thread 1-1) WELD-000900: 2.1.0 (2013-10-07 08:46)
> 10:46:23,448 INFO  [org.jboss.weld.deployer] (MSC service thread 1-1) JBAS016008: Starting weld service for deployment weld-translator.ear
> 10:46:24,654 INFO  [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-8) Initializing Mojarra 2.2.3-jbossorg-1 20130910-1739 for context '/weld-translator'
> 10:46:25,490 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) JBAS018210: Register web context: /weld-translator
> 10:46:25,569 INFO  [org.jboss.as.server] (management-handler-thread - 1) JBAS018559: Deployed "weld-translator.ear" (runtime-name : "weld-translator.ear")
> 10:46:43,715 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) JBAS018224: Unregister web context: /weld-translator
> 10:46:43,731 INFO  [org.jboss.weld.deployer] (MSC service thread 1-7) JBAS016009: Stopping weld service for deployment weld-translator.ear
> 10:46:43,775 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015877: Stopped deployment null (runtime-name: weld-jsf-translator-ejb-2.1.0-SNAPSHOT.jar) in 65ms
> 10:46:43,777 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-6) JBAS015877: Stopped deployment null (runtime-name: weld-jsf-translator-war-2.1.0-SNAPSHOT.war) in 68ms
> 10:46:43,779 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-6) JBAS015877: Stopped deployment weld-translator.ear (runtime-name: weld-translator.ear) in 70ms
> 10:46:43,820 INFO  [org.jboss.as.repository] (management-handler-thread - 2) JBAS014901: Content removed from location /home/jharting/jboss/Weld/wildfly-8.0.0.Beta1/standalone/data/content/41/4cdfd11cd5283d5356778f396c618ca2477c6b/content
> 10:46:43,821 INFO  [org.jboss.as.server] (management-handler-thread - 2) JBAS018558: Undeployed "weld-translator.ear" (runtime-name: "weld-translator.ear")
> 10:47:10,201 INFO  [org.jboss.as.repository] (management-handler-thread - 3) JBAS014900: Content added at location /home/jharting/jboss/Weld/wildfly-8.0.0.Beta1/standalone/data/content/d9/22ca6b33304b2cccc227cdf8f6aadeedad88f9/content
> 10:47:10,203 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015876: Starting deployment of "weld-translator.ear" (runtime-name: "weld-translator.ear")
> 10:47:10,223 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015876: Starting deployment of "null" (runtime-name: "weld-translator.jar")
> 10:47:10,223 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015876: Starting deployment of "null" (runtime-name: "weld-translator.war")
> 10:47:10,297 INFO  [org.jboss.weld.deployer] (MSC service thread 1-5) JBAS016002: Processing weld deployment weld-translator.ear
> 10:47:10,310 INFO  [org.jboss.weld.deployer] (MSC service thread 1-6) JBAS016002: Processing weld deployment weld-translator.war
> 10:47:10,311 INFO  [org.jboss.weld.deployer] (MSC service thread 1-2) JBAS016002: Processing weld deployment weld-translator.jar
> 10:47:10,314 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-2) JNDI bindings for session bean named TranslatorControllerBean in deployment unit subdeployment "weld-translator.jar" of deployment "weld-translator.ear" are as follows:
>         java:global/weld-translator/weld-translator.jar/TranslatorControllerBean!org.jboss.weld.examples.translator.TranslatorController
>         java:app/weld-translator.jar/TranslatorControllerBean!org.jboss.weld.examples.translator.TranslatorController
>         java:module/TranslatorControllerBean!org.jboss.weld.examples.translator.TranslatorController
>         java:global/weld-translator/weld-translator.jar/TranslatorControllerBean
>         java:app/weld-translator.jar/TranslatorControllerBean
>         java:module/TranslatorControllerBean
> 10:47:10,314 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-2) JNDI bindings for session bean named SentenceTranslator in deployment unit subdeployment "weld-translator.jar" of deployment "weld-translator.ear" are as follows:
>         java:global/weld-translator/weld-translator.jar/SentenceTranslator!org.jboss.weld.examples.translator.Translator
>         java:app/weld-translator.jar/SentenceTranslator!org.jboss.weld.examples.translator.Translator
>         java:module/SentenceTranslator!org.jboss.weld.examples.translator.Translator
>         java:global/weld-translator/weld-translator.jar/SentenceTranslator
>         java:app/weld-translator.jar/SentenceTranslator
>         java:module/SentenceTranslator
> 10:47:10,318 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.subunit."weld-translator.ear"."weld-translator.jar".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."weld-translator.ear"."weld-translator.jar".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of subdeployment "weld-translator.jar" of deployment "weld-translator.ear"
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Beta1.jar:8.0.0.Beta1]
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
>         at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.concurrent.ee.context.config.weld-translator.weld-translator is already registered
>         at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>         at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>         at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:767) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>         at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>         at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2384) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>         at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>         at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2384) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>         at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>         at org.jboss.as.ee.concurrent.deployers.EEConcurrentContextProcessor.setupConcurrentContext(EEConcurrentContextProcessor.java:110)
>         at org.jboss.as.ee.concurrent.deployers.EEConcurrentContextProcessor.processModuleDescription(EEConcurrentContextProcessor.java:71)
>         at org.jboss.as.ee.concurrent.deployers.EEConcurrentContextProcessor.deploy(EEConcurrentContextProcessor.java:54)
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta1.jar:8.0.0.Beta1]
>         ... 5 more
> 10:47:10,329 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "weld-translator.ear")]) - failure description: {
>     "JBAS014671: Failed services" => {"jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.jar\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.jar\".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of subdeployment \"weld-translator.jar\" of deployment \"weld-translator.ear\"
>     Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.concurrent.ee.context.config.weld-translator.weld-translator is already registered"},
>     "JBAS014771: Services with missing/unavailable dependencies" => [
>         "jboss.deployment.unit.\"weld-translator.ear\".weld.weldClassIntrospector is missing [jboss.deployment.unit.\"weld-translator.ear\".beanmanager]",
>         "jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.war\".batch is missing [jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.war\".beanmanager]",
>         "jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.war\".weld.weldClassIntrospector is missing [jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.war\".beanmanager]"
>     ]
> }
> 10:47:10,338 ERROR [org.jboss.as.server] (management-handler-thread - 3) JBAS015870: Deploy of deployment "weld-translator.ear" was rolled back with the following failure message: 
> {
>     "JBAS014671: Failed services" => {"jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.jar\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.jar\".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of subdeployment \"weld-translator.jar\" of deployment \"weld-translator.ear\"
>     Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.concurrent.ee.context.config.weld-translator.weld-translator is already registered"},
>     "JBAS014771: Services with missing/unavailable dependencies" => [
>         "jboss.deployment.unit.\"weld-translator.ear\".weld.weldClassIntrospector is missing [jboss.deployment.unit.\"weld-translator.ear\".beanmanager]",
>         "jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.war\".batch is missing [jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.war\".beanmanager]",
>         "jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.war\".weld.weldClassIntrospector is missing [jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.war\".beanmanager]"
>     ]
> }
> 10:47:10,351 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015877: Stopped deployment null (runtime-name: weld-translator.jar) in 18ms
> 10:47:10,354 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015877: Stopped deployment null (runtime-name: weld-translator.war) in 21ms
> 10:47:10,356 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015877: Stopped deployment weld-translator.ear (runtime-name: weld-translator.ear) in 23ms
> 10:47:10,358 INFO  [org.jboss.as.controller] (management-handler-thread - 3) JBAS014774: Service status report
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.deployment.subunit."weld-translator.ear"."weld-translator.war".beanmanager (missing) dependents: [service jboss.deployment.subunit."weld-translator.ear"."weld-translator.war".weld.weldClassIntrospector, service jboss.deployment.subunit."weld-translator.ear"."weld-translator.war".batch] 
>       service jboss.deployment.unit."weld-translator.ear".beanmanager (missing) dependents: [service jboss.deployment.unit."weld-translator.ear".weld.weldClassIntrospector] 
>       service jboss.naming.context.java.module.weld-translator."weld-translator.war" (missing) dependents: [service jboss.deployment.subunit."weld-translator.ear"."weld-translator.war".INSTALL] 
> JBAS014777:   Services which failed to start:      service jboss.deployment.subunit."weld-translator.ear"."weld-translator.jar".POST_MODULE
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 06:55:02 2013
From: jira-events at lists.jboss.org (Eduardo Martins (JIRA))
Date: Mon, 7 Oct 2013 06:55:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2228) EJB and web module cannot
 have the same name in an ear
In-Reply-To: <JIRA.12502307.1381142531000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502307.1381142531000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502307.1381142531000.18608.1381143302546@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Eduardo Martins resolved WFLY-2228.
-----------------------------------

    Resolution: Duplicate Issue


Same as WFLY-2223 which already has a PR submitted
                
> EJB and web module cannot have the same name in an ear
> ------------------------------------------------------
>
>                 Key: WFLY-2228
>                 URL: https://issues.jboss.org/browse/WFLY-2228
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Jozef Hartinger
>            Assignee: Eduardo Martins
>             Fix For: 8.0.0.CR1
>
>         Attachments: weld-translator.ear
>
>
> Having an ear project like this:
> {code}
> weld.translator.ear
> +--weld-translator.war
> +--weld-translator.jar
> {code}
> I am no longer able to deploy it to WildFly. This is a regression caused by the following commit: https://github.com/wildfly/wildfly/commit/d4aecbe5d2b241befa5da43b19c2d0712621ac0a
> The deployment exception:
> {noformat}
> 10:45:56,835 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874: WildFly 8.0.0.Beta1 "WildFly" started in 3433ms - Started 180 of 217 services (62 services are lazy, passive or on-demand)
> 10:46:22,816 INFO  [org.jboss.as.repository] (management-handler-thread - 1) JBAS014900: Content added at location /home/jharting/jboss/Weld/wildfly-8.0.0.Beta1/standalone/data/content/41/4cdfd11cd5283d5356778f396c618ca2477c6b/content
> 10:46:22,842 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015876: Starting deployment of "weld-translator.ear" (runtime-name: "weld-translator.ear")
> 10:46:22,912 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015876: Starting deployment of "null" (runtime-name: "weld-jsf-translator-war-2.1.0-SNAPSHOT.war")
> 10:46:22,912 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015876: Starting deployment of "null" (runtime-name: "weld-jsf-translator-ejb-2.1.0-SNAPSHOT.jar")
> 10:46:23,147 INFO  [org.jboss.weld.deployer] (MSC service thread 1-8) JBAS016002: Processing weld deployment weld-translator.ear
> 10:46:23,192 INFO  [org.hibernate.validator.internal.util.Version] (MSC service thread 1-8) HV000001: Hibernate Validator 5.0.1.Final
> 10:46:23,340 INFO  [org.jboss.weld.deployer] (MSC service thread 1-1) JBAS016002: Processing weld deployment weld-jsf-translator-war-2.1.0-SNAPSHOT.war
> 10:46:23,353 INFO  [org.jboss.weld.deployer] (MSC service thread 1-6) JBAS016002: Processing weld deployment weld-jsf-translator-ejb-2.1.0-SNAPSHOT.jar
> 10:46:23,366 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-6) JNDI bindings for session bean named TranslatorControllerBean in deployment unit subdeployment "weld-jsf-translator-ejb-2.1.0-SNAPSHOT.jar" of deployment "weld-translator.ear" are as follows:
>         java:global/weld-translator/weld-jsf-translator-ejb-2.1.0-SNAPSHOT/TranslatorControllerBean!org.jboss.weld.examples.translator.TranslatorController
>         java:app/weld-jsf-translator-ejb-2.1.0-SNAPSHOT/TranslatorControllerBean!org.jboss.weld.examples.translator.TranslatorController
>         java:module/TranslatorControllerBean!org.jboss.weld.examples.translator.TranslatorController
>         java:global/weld-translator/weld-jsf-translator-ejb-2.1.0-SNAPSHOT/TranslatorControllerBean
>         java:app/weld-jsf-translator-ejb-2.1.0-SNAPSHOT/TranslatorControllerBean
>         java:module/TranslatorControllerBean
> 10:46:23,369 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-6) JNDI bindings for session bean named SentenceTranslator in deployment unit subdeployment "weld-jsf-translator-ejb-2.1.0-SNAPSHOT.jar" of deployment "weld-translator.ear" are as follows:
>         java:global/weld-translator/weld-jsf-translator-ejb-2.1.0-SNAPSHOT/SentenceTranslator!org.jboss.weld.examples.translator.Translator
>         java:app/weld-jsf-translator-ejb-2.1.0-SNAPSHOT/SentenceTranslator!org.jboss.weld.examples.translator.Translator
>         java:module/SentenceTranslator!org.jboss.weld.examples.translator.Translator
>         java:global/weld-translator/weld-jsf-translator-ejb-2.1.0-SNAPSHOT/SentenceTranslator
>         java:app/weld-jsf-translator-ejb-2.1.0-SNAPSHOT/SentenceTranslator
>         java:module/SentenceTranslator
> 10:46:23,392 INFO  [org.jboss.weld.deployer] (MSC service thread 1-1) JBAS016005: Starting Services for CDI deployment: weld-translator.ear
> 10:46:23,430 INFO  [org.jboss.weld.Version] (MSC service thread 1-1) WELD-000900: 2.1.0 (2013-10-07 08:46)
> 10:46:23,448 INFO  [org.jboss.weld.deployer] (MSC service thread 1-1) JBAS016008: Starting weld service for deployment weld-translator.ear
> 10:46:24,654 INFO  [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-8) Initializing Mojarra 2.2.3-jbossorg-1 20130910-1739 for context '/weld-translator'
> 10:46:25,490 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) JBAS018210: Register web context: /weld-translator
> 10:46:25,569 INFO  [org.jboss.as.server] (management-handler-thread - 1) JBAS018559: Deployed "weld-translator.ear" (runtime-name : "weld-translator.ear")
> 10:46:43,715 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) JBAS018224: Unregister web context: /weld-translator
> 10:46:43,731 INFO  [org.jboss.weld.deployer] (MSC service thread 1-7) JBAS016009: Stopping weld service for deployment weld-translator.ear
> 10:46:43,775 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015877: Stopped deployment null (runtime-name: weld-jsf-translator-ejb-2.1.0-SNAPSHOT.jar) in 65ms
> 10:46:43,777 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-6) JBAS015877: Stopped deployment null (runtime-name: weld-jsf-translator-war-2.1.0-SNAPSHOT.war) in 68ms
> 10:46:43,779 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-6) JBAS015877: Stopped deployment weld-translator.ear (runtime-name: weld-translator.ear) in 70ms
> 10:46:43,820 INFO  [org.jboss.as.repository] (management-handler-thread - 2) JBAS014901: Content removed from location /home/jharting/jboss/Weld/wildfly-8.0.0.Beta1/standalone/data/content/41/4cdfd11cd5283d5356778f396c618ca2477c6b/content
> 10:46:43,821 INFO  [org.jboss.as.server] (management-handler-thread - 2) JBAS018558: Undeployed "weld-translator.ear" (runtime-name: "weld-translator.ear")
> 10:47:10,201 INFO  [org.jboss.as.repository] (management-handler-thread - 3) JBAS014900: Content added at location /home/jharting/jboss/Weld/wildfly-8.0.0.Beta1/standalone/data/content/d9/22ca6b33304b2cccc227cdf8f6aadeedad88f9/content
> 10:47:10,203 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015876: Starting deployment of "weld-translator.ear" (runtime-name: "weld-translator.ear")
> 10:47:10,223 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015876: Starting deployment of "null" (runtime-name: "weld-translator.jar")
> 10:47:10,223 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015876: Starting deployment of "null" (runtime-name: "weld-translator.war")
> 10:47:10,297 INFO  [org.jboss.weld.deployer] (MSC service thread 1-5) JBAS016002: Processing weld deployment weld-translator.ear
> 10:47:10,310 INFO  [org.jboss.weld.deployer] (MSC service thread 1-6) JBAS016002: Processing weld deployment weld-translator.war
> 10:47:10,311 INFO  [org.jboss.weld.deployer] (MSC service thread 1-2) JBAS016002: Processing weld deployment weld-translator.jar
> 10:47:10,314 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-2) JNDI bindings for session bean named TranslatorControllerBean in deployment unit subdeployment "weld-translator.jar" of deployment "weld-translator.ear" are as follows:
>         java:global/weld-translator/weld-translator.jar/TranslatorControllerBean!org.jboss.weld.examples.translator.TranslatorController
>         java:app/weld-translator.jar/TranslatorControllerBean!org.jboss.weld.examples.translator.TranslatorController
>         java:module/TranslatorControllerBean!org.jboss.weld.examples.translator.TranslatorController
>         java:global/weld-translator/weld-translator.jar/TranslatorControllerBean
>         java:app/weld-translator.jar/TranslatorControllerBean
>         java:module/TranslatorControllerBean
> 10:47:10,314 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-2) JNDI bindings for session bean named SentenceTranslator in deployment unit subdeployment "weld-translator.jar" of deployment "weld-translator.ear" are as follows:
>         java:global/weld-translator/weld-translator.jar/SentenceTranslator!org.jboss.weld.examples.translator.Translator
>         java:app/weld-translator.jar/SentenceTranslator!org.jboss.weld.examples.translator.Translator
>         java:module/SentenceTranslator!org.jboss.weld.examples.translator.Translator
>         java:global/weld-translator/weld-translator.jar/SentenceTranslator
>         java:app/weld-translator.jar/SentenceTranslator
>         java:module/SentenceTranslator
> 10:47:10,318 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.subunit."weld-translator.ear"."weld-translator.jar".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."weld-translator.ear"."weld-translator.jar".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of subdeployment "weld-translator.jar" of deployment "weld-translator.ear"
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Beta1.jar:8.0.0.Beta1]
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
>         at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.concurrent.ee.context.config.weld-translator.weld-translator is already registered
>         at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>         at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>         at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:767) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>         at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>         at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2384) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>         at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>         at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2384) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>         at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>         at org.jboss.as.ee.concurrent.deployers.EEConcurrentContextProcessor.setupConcurrentContext(EEConcurrentContextProcessor.java:110)
>         at org.jboss.as.ee.concurrent.deployers.EEConcurrentContextProcessor.processModuleDescription(EEConcurrentContextProcessor.java:71)
>         at org.jboss.as.ee.concurrent.deployers.EEConcurrentContextProcessor.deploy(EEConcurrentContextProcessor.java:54)
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta1.jar:8.0.0.Beta1]
>         ... 5 more
> 10:47:10,329 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "weld-translator.ear")]) - failure description: {
>     "JBAS014671: Failed services" => {"jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.jar\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.jar\".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of subdeployment \"weld-translator.jar\" of deployment \"weld-translator.ear\"
>     Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.concurrent.ee.context.config.weld-translator.weld-translator is already registered"},
>     "JBAS014771: Services with missing/unavailable dependencies" => [
>         "jboss.deployment.unit.\"weld-translator.ear\".weld.weldClassIntrospector is missing [jboss.deployment.unit.\"weld-translator.ear\".beanmanager]",
>         "jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.war\".batch is missing [jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.war\".beanmanager]",
>         "jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.war\".weld.weldClassIntrospector is missing [jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.war\".beanmanager]"
>     ]
> }
> 10:47:10,338 ERROR [org.jboss.as.server] (management-handler-thread - 3) JBAS015870: Deploy of deployment "weld-translator.ear" was rolled back with the following failure message: 
> {
>     "JBAS014671: Failed services" => {"jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.jar\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.jar\".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of subdeployment \"weld-translator.jar\" of deployment \"weld-translator.ear\"
>     Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.concurrent.ee.context.config.weld-translator.weld-translator is already registered"},
>     "JBAS014771: Services with missing/unavailable dependencies" => [
>         "jboss.deployment.unit.\"weld-translator.ear\".weld.weldClassIntrospector is missing [jboss.deployment.unit.\"weld-translator.ear\".beanmanager]",
>         "jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.war\".batch is missing [jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.war\".beanmanager]",
>         "jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.war\".weld.weldClassIntrospector is missing [jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.war\".beanmanager]"
>     ]
> }
> 10:47:10,351 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015877: Stopped deployment null (runtime-name: weld-translator.jar) in 18ms
> 10:47:10,354 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015877: Stopped deployment null (runtime-name: weld-translator.war) in 21ms
> 10:47:10,356 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015877: Stopped deployment weld-translator.ear (runtime-name: weld-translator.ear) in 23ms
> 10:47:10,358 INFO  [org.jboss.as.controller] (management-handler-thread - 3) JBAS014774: Service status report
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.deployment.subunit."weld-translator.ear"."weld-translator.war".beanmanager (missing) dependents: [service jboss.deployment.subunit."weld-translator.ear"."weld-translator.war".weld.weldClassIntrospector, service jboss.deployment.subunit."weld-translator.ear"."weld-translator.war".batch] 
>       service jboss.deployment.unit."weld-translator.ear".beanmanager (missing) dependents: [service jboss.deployment.unit."weld-translator.ear".weld.weldClassIntrospector] 
>       service jboss.naming.context.java.module.weld-translator."weld-translator.war" (missing) dependents: [service jboss.deployment.subunit."weld-translator.ear"."weld-translator.war".INSTALL] 
> JBAS014777:   Services which failed to start:      service jboss.deployment.subunit."weld-translator.ear"."weld-translator.jar".POST_MODULE
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 06:57:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Oct 2013 06:57:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-67) Improve LogManager formatter
 capability: System resources, thread ID and minified category
In-Reply-To: <JIRA.12490045.1366637143000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12490045.1366637143000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12490045.1366637143000.18617.1381143423035@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/LOGMGR-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12810409#comment-12810409 ] 

RH Bugzilla Integration commented on LOGMGR-67:
-----------------------------------------------

Ondrej Lukas <olukas at redhat.com> changed the Status of [bug 994744|https://bugzilla.redhat.com/show_bug.cgi?id=994744] from ON_QA to ASSIGNED
                
> Improve LogManager formatter capability: System resources, thread ID and minified category
> ------------------------------------------------------------------------------------------
>
>                 Key: LOGMGR-67
>                 URL: https://issues.jboss.org/browse/LOGMGR-67
>             Project: JBoss Log Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: core
>    Affects Versions: 1.3.2.Final
>         Environment: JBoss EAP 6.0.1
>            Reporter: Jeremy KUHN
>            Assignee: James Perkins
>              Labels: jboss
>             Fix For: 1.5.0.Final, 2.0.0.Beta1
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> Hello,
> We are currently developing a major JEE application running on multiple JBoss EAP 6.0.1 instances in a service oriented architecture.
> The current implementation of JBoss-logmanager (1.3.2.Final) shipped with JBoss EAP doesn't provide the functionality we require in term of logging formatting.
> We are missing:
> - Thread ID (Thread names are too long and of different length that disturb the reading of logs)
> - we haven't find a way to get the hostname displayed in the logs, a simple solution would be to be able to include System properties and therefore the jboss.host.name property in the pattern. System properties would also be interesting to identified the log coming from a specific application (we'll have one application deployed per JBoss instance). Ideally, we'd like to have the ability to provide a context name to know which application has logged the event but this seems to have been delivered with logging profiles.
> - logback has this interesting feature that lets you minify the log category: instead of org.jboss.logmanager.config.ConfigAction you'll get o.j.l.c.ConfigAction which is more readable in the logs.
> Regards

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 06:57:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Oct 2013 06:57:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-67) Improve LogManager formatter
 capability: System resources, thread ID and minified category
In-Reply-To: <JIRA.12490045.1366637143000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12490045.1366637143000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12490045.1366637143000.18634.1381143423794@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/LOGMGR-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12810412#comment-12810412 ] 

RH Bugzilla Integration commented on LOGMGR-67:
-----------------------------------------------

Ondrej Lukas <olukas at redhat.com> made a comment on [bug 994744|https://bugzilla.redhat.com/show_bug.cgi?id=994744]

Unfortunatelly verification failed. Thread ID and Minified log categories are ok, but setting system property works bad. If I add %${test.property} to formatter and start server with -Dtest.property=property that use "p" from word property as %p and then log of that part looks like INFOroperty.
                
> Improve LogManager formatter capability: System resources, thread ID and minified category
> ------------------------------------------------------------------------------------------
>
>                 Key: LOGMGR-67
>                 URL: https://issues.jboss.org/browse/LOGMGR-67
>             Project: JBoss Log Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: core
>    Affects Versions: 1.3.2.Final
>         Environment: JBoss EAP 6.0.1
>            Reporter: Jeremy KUHN
>            Assignee: James Perkins
>              Labels: jboss
>             Fix For: 1.5.0.Final, 2.0.0.Beta1
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> Hello,
> We are currently developing a major JEE application running on multiple JBoss EAP 6.0.1 instances in a service oriented architecture.
> The current implementation of JBoss-logmanager (1.3.2.Final) shipped with JBoss EAP doesn't provide the functionality we require in term of logging formatting.
> We are missing:
> - Thread ID (Thread names are too long and of different length that disturb the reading of logs)
> - we haven't find a way to get the hostname displayed in the logs, a simple solution would be to be able to include System properties and therefore the jboss.host.name property in the pattern. System properties would also be interesting to identified the log coming from a specific application (we'll have one application deployed per JBoss instance). Ideally, we'd like to have the ability to provide a context name to know which application has logged the event but this seems to have been delivered with logging profiles.
> - logback has this interesting feature that lets you minify the log category: instead of org.jboss.logmanager.config.ConfigAction you'll get o.j.l.c.ConfigAction which is more readable in the logs.
> Regards

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 06:59:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Oct 2013 06:59:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1697) Fix JPA
 SerializableValidatorFactory memory leak
In-Reply-To: <JIRA.12496481.1373901643000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496481.1373901643000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496481.1373901643000.18658.1381143542581@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12810416#comment-12810416 ] 

RH Bugzilla Integration commented on WFLY-1697:
-----------------------------------------------

Marek Schmidt <maschmid at redhat.com> changed the Status of [bug 1003600|https://bugzilla.redhat.com/show_bug.cgi?id=1003600] from ON_QA to ASSIGNED
                
> Fix JPA SerializableValidatorFactory memory leak
> ------------------------------------------------
>
>                 Key: WFLY-1697
>                 URL: https://issues.jboss.org/browse/WFLY-1697
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>
> See http://lists.jboss.org/pipermail/wildfly-dev/2013-July/000466.html for details on recreating the SerializableValidatorFactory leak and Hibernate service loader references to Integreation class/properties.  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 07:03:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Oct 2013 07:03:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1996) Application client will not
 start if run against a standalone client jar
In-Reply-To: <JIRA.12499903.1378291333000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499903.1378291333000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499903.1378291333000.18681.1381143782691@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12810423#comment-12810423 ] 

RH Bugzilla Integration commented on WFLY-1996:
-----------------------------------------------

Aleksandar Kostadinov <akostadi at redhat.com> made a comment on [bug 1003104|https://bugzilla.redhat.com/show_bug.cgi?id=1003104]

Tested with ER3.1 and automated test is in place for RPM distribution.
                
> Application client will not start if run against a standalone client jar
> ------------------------------------------------------------------------
>
>                 Key: WFLY-1996
>                 URL: https://issues.jboss.org/browse/WFLY-1996
>             Project: WildFly
>          Issue Type: Bug
>          Components: Application Client
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 07:03:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Oct 2013 07:03:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1996) Application client will not
 start if run against a standalone client jar
In-Reply-To: <JIRA.12499903.1378291333000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499903.1378291333000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499903.1378291333000.18684.1381143782869@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12810424#comment-12810424 ] 

RH Bugzilla Integration commented on WFLY-1996:
-----------------------------------------------

Aleksandar Kostadinov <akostadi at redhat.com> changed the Status of [bug 1003104|https://bugzilla.redhat.com/show_bug.cgi?id=1003104] from ON_QA to VERIFIED
                
> Application client will not start if run against a standalone client jar
> ------------------------------------------------------------------------
>
>                 Key: WFLY-1996
>                 URL: https://issues.jboss.org/browse/WFLY-1996
>             Project: WildFly
>          Issue Type: Bug
>          Components: Application Client
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 07:05:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 7 Oct 2013 07:05:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-553) Allow for alternative access
 control providers to be plugged into management.
In-Reply-To: <JIRA.12451179.1320311142000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12451179.1320311142000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12451179.1320311142000.18705.1381143903565@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-553:
----------------------------------

    Summary: Allow for alternative access control providers to be plugged into management.  (was: Implementation of a more complex ACL scheme for domain management)


Just changing the title of this issue as the next step is to formalise support for plugging in different providers, at this stage there is not an identified need for us to actually provide alternative providers ourselves.
                
> Allow for alternative access control providers to be plugged into management.
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-553
>                 URL: https://issues.jboss.org/browse/WFLY-553
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: Authorization, Realm_Management
>             Fix For: 9.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 07:13:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Oct 2013 07:13:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2093) No any log generated after
 changing periodic-rotating-file-handler to size-rotating-file-handler
In-Reply-To: <JIRA.12500810.1379401775000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500810.1379401775000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500810.1379401775000.18722.1381144382630@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12810430#comment-12810430 ] 

RH Bugzilla Integration commented on WFLY-2093:
-----------------------------------------------

Ondrej Lukas <olukas at redhat.com> made a comment on [bug 1008806|https://bugzilla.redhat.com/show_bug.cgi?id=1008806]

I tried to reproduce it according your steps, but it always works fine for me. It logs WARN message but it writes another logs which looks right as usual. Is there any other needed configuration please? I can't verify it for that reason.
                
> No any log generated after changing periodic-rotating-file-handler to size-rotating-file-handler
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2093
>                 URL: https://issues.jboss.org/browse/WFLY-2093
>             Project: WildFly
>          Issue Type: Bug
>          Components: Logging
>            Reporter: Xiaohui Wu
>            Assignee: James Perkins
>
> There is no any log in the server.log after changing periodic-rotating-file-handler to size-rotating-file-handler.
> The reproduce steps:
> 1. remove the part periodic-rotating-file-handler in standalone.xml
>             <periodic-rotating-file-handler name="FILE">
>                 <formatter>
>                     <pattern-formatter pattern="%d{HH:mm:ss.SSS} %-5p [%c] (%t) %s%E%n"/>
>                 </formatter>
>                 <file relative-to="jboss.server.log.dir" path="server.log"/>
>                 <suffix value=".yyyy-MM-dd"/>
>                 <append value="true"/>
>             </periodic-rotating-file-handler>
> 2. add one size-rotating-file-handler
>             <size-rotating-file-handler name="FILE" autoflush="true">
>                 <formatter>
>                     <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p (%c) [%t] %s%E%n"/>
>                 </formatter>
>                 <file relative-to="jboss.server.log.dir" path="server.log"/>
>                 <rotate-size value="500k"/>
>                 <max-backup-index value="15"/>
>                 <append value="true"/>
>             </size-rotating-file-handler>
> 3. start the jboss server, then you will see there is a warning in the server.log and no any further logs in the server.log.
> 13:23:28,205 WARN  [org.jboss.as.logging] (Controller Boot Thread) JBAS011511: Replacing handler 'FILE' during add operation. Either the handler type or the module name differs from the initial configuration.
> The possible fix: 
> https://issues.jboss.org/browse/WFLY-178 the code change is in https://github.com/wildfly/wildfly/pull/4137 
> and the bugzilla is in EAP6.1.0: 
> https://bugzilla.redhat.com/show_bug.cgi?id=918103
> But this issue still exists in 6.1.1
> Best Regards,
> Vicky

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 07:15:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 7 Oct 2013 07:15:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2229) Add support for PKCS12
 Keystores in security realms.
In-Reply-To: <JIRA.12502310.1381144389849@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502310.1381144389849@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502310.1381144389849.18729.1381144503311@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-2229:
--------------------------------------

             Summary: Add support for PKCS12 Keystores in security realms.
                 Key: WFLY-2229
                 URL: https://issues.jboss.org/browse/WFLY-2229
             Project: WildFly
          Issue Type: Feature Request
          Components: Domain Management, Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 8.0.0.CR1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 07:17:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Oct 2013 07:17:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1914) Application client container
	doesn't start
In-Reply-To: <JIRA.12499060.1377081913000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499060.1377081913000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499060.1377081913000.18738.1381144622707@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12810431#comment-12810431 ] 

RH Bugzilla Integration commented on WFLY-1914:
-----------------------------------------------

Aleksandar Kostadinov <akostadi at redhat.com> made a comment on [bug 999465|https://bugzilla.redhat.com/show_bug.cgi?id=999465]

We still see the issue with 6.2.0 ER3.1.. just saying
                
> Application client container doesn't start
> ------------------------------------------
>
>                 Key: WFLY-1914
>                 URL: https://issues.jboss.org/browse/WFLY-1914
>             Project: WildFly
>          Issue Type: Bug
>          Components: Application Client
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Beta1
>
>
> Application client container fails to start with the following exception:
> {code}
> 16:23:40,742 INFO  [org.jboss.as.jacorb] (MSC service thread 1-7) JBAS016328: CORBA Naming Service started
> 16:23:40,744 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("add") failed - address: ([
>     ("subsystem" => "naming"),
>     ("service" => "remote-naming")
> ]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.naming.remote is missing [jboss.remoting.endpoint.subsystem]"]}
> 16:23:40,779 INFO  [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.remoting.endpoint.subsystem (missing) dependents: [service jboss.naming.remote] 
> 16:23:40,782 ERROR [org.jboss.as] (Controller Boot Thread) JBAS015875: WildFly 8.0.0.Beta1-SNAPSHOT "WildFly" started (with errors) in 1471ms - Started 99 of 103 services (1 services failed or missing dependencies, 9 services are lazy, passive or on-demand)
> {code}
> when started using the following command:
> {code}
> JBOSS_HOME/bin/appclient.sh /foo/bar/some.jar
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 07:22:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 7 Oct 2013 07:22:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2127) Resurrect regular expression
 based group name identification for LDAP
In-Reply-To: <JIRA.12501174.1379925943000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501174.1379925943000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501174.1379925943000.18743.1381144922609@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2127:
-----------------------------------

    Fix Version/s: 9.0.0.CR1
                       (was: 8.0.0.CR1)

    
> Resurrect regular expression based group name identification for LDAP
> ---------------------------------------------------------------------
>
>                 Key: WFLY-2127
>                 URL: https://issues.jboss.org/browse/WFLY-2127
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 9.0.0.CR1
>
>
> The changes contributed under WFLY-455 contained a feature to extract the group name from the distinguished name based on a regular expression search - this should be resurrected as a third mode for group name identification.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 07:37:02 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Mon, 7 Oct 2013 07:37:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2230) Web subsystem transformers
	for 7.2.0
In-Reply-To: <JIRA.12502316.1381145821682@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502316.1381145821682@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502316.1381145821682.18795.1381145822841@jira02.app.mwc.hst.phx2.redhat.com>

Kabir Khan created WFLY-2230:
--------------------------------

             Summary: Web subsystem transformers for 7.2.0
                 Key: WFLY-2230
                 URL: https://issues.jboss.org/browse/WFLY-2230
             Project: WildFly
          Issue Type: Sub-task
          Components: Web (JBoss Web)
            Reporter: Kabir Khan
            Assignee: Tomaz Cerar




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 07:39:03 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Mon, 7 Oct 2013 07:39:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2231) Datasources subsystem
 transformers for 7.2.0
In-Reply-To: <JIRA.12502317.1381145882890@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502317.1381145882890@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502317.1381145882890.18813.1381145943658@jira02.app.mwc.hst.phx2.redhat.com>

Kabir Khan created WFLY-2231:
--------------------------------

             Summary: Datasources subsystem transformers for 7.2.0
                 Key: WFLY-2231
                 URL: https://issues.jboss.org/browse/WFLY-2231
             Project: WildFly
          Issue Type: Sub-task
          Components: JCA
            Reporter: Kabir Khan
            Assignee: Jesper Pedersen
             Fix For: 8.0.0.CR1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 07:39:04 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Mon, 7 Oct 2013 07:39:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2230) Web subsystem transformers
	for 7.2.0
In-Reply-To: <JIRA.12502316.1381145821000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502316.1381145821000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502316.1381145821000.18828.1381145944330@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-2230:
-----------------------------

    Fix Version/s: 8.0.0.CR1

    
> Web subsystem transformers for 7.2.0
> ------------------------------------
>
>                 Key: WFLY-2230
>                 URL: https://issues.jboss.org/browse/WFLY-2230
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Web (JBoss Web)
>            Reporter: Kabir Khan
>            Assignee: Tomaz Cerar
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 07:39:04 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Mon, 7 Oct 2013 07:39:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2232) EE subsystem transformers for
	7.2.0
In-Reply-To: <JIRA.12502318.1381145938213@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502318.1381145938213@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502318.1381145938213.18831.1381145944456@jira02.app.mwc.hst.phx2.redhat.com>

Kabir Khan created WFLY-2232:
--------------------------------

             Summary: EE subsystem transformers for 7.2.0
                 Key: WFLY-2232
                 URL: https://issues.jboss.org/browse/WFLY-2232
             Project: WildFly
          Issue Type: Sub-task
          Components: EE
            Reporter: Kabir Khan
            Assignee: David Lloyd
             Fix For: 8.0.0.CR1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 07:41:03 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Mon, 7 Oct 2013 07:41:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2233) EJB3 subsystem transformers
	for 7.2.0
In-Reply-To: <JIRA.12502319.1381145984149@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502319.1381145984149@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502319.1381145984149.18848.1381146063231@jira02.app.mwc.hst.phx2.redhat.com>

Kabir Khan created WFLY-2233:
--------------------------------

             Summary: EJB3 subsystem transformers for 7.2.0
                 Key: WFLY-2233
                 URL: https://issues.jboss.org/browse/WFLY-2233
             Project: WildFly
          Issue Type: Sub-task
          Components: EJB
            Reporter: Kabir Khan
            Assignee: Kabir Khan
             Fix For: 8.0.0.CR1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 07:41:03 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Mon, 7 Oct 2013 07:41:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2234) Infinispan subsystem
 transformers for 7.2.0
In-Reply-To: <JIRA.12502320.1381146027254@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502320.1381146027254@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502320.1381146027254.18851.1381146063352@jira02.app.mwc.hst.phx2.redhat.com>

Kabir Khan created WFLY-2234:
--------------------------------

             Summary: Infinispan subsystem transformers for 7.2.0
                 Key: WFLY-2234
                 URL: https://issues.jboss.org/browse/WFLY-2234
             Project: WildFly
          Issue Type: Sub-task
          Components: Clustering
            Reporter: Kabir Khan
            Assignee: Paul Ferraro
             Fix For: 8.0.0.CR1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 07:43:02 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Mon, 7 Oct 2013 07:43:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2235) JCA subsystem transformers
	for 7.2.0
In-Reply-To: <JIRA.12502321.1381146069273@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502321.1381146069273@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502321.1381146069273.18856.1381146182835@jira02.app.mwc.hst.phx2.redhat.com>

Kabir Khan created WFLY-2235:
--------------------------------

             Summary: JCA subsystem transformers for 7.2.0
                 Key: WFLY-2235
                 URL: https://issues.jboss.org/browse/WFLY-2235
             Project: WildFly
          Issue Type: Sub-task
          Components: JCA
            Reporter: Kabir Khan
            Assignee: Jesper Pedersen
             Fix For: 8.0.0.CR1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 07:43:02 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Mon, 7 Oct 2013 07:43:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2236) JGroups subsystem
	transformers for 7.2.0
In-Reply-To: <JIRA.12502322.1381146122311@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502322.1381146122311@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502322.1381146122311.18858.1381146182949@jira02.app.mwc.hst.phx2.redhat.com>

Kabir Khan created WFLY-2236:
--------------------------------

             Summary: JGroups subsystem transformers for 7.2.0
                 Key: WFLY-2236
                 URL: https://issues.jboss.org/browse/WFLY-2236
             Project: WildFly
          Issue Type: Sub-task
          Components: Clustering
            Reporter: Kabir Khan
            Assignee: Paul Ferraro
             Fix For: 8.0.0.CR1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 07:43:04 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Mon, 7 Oct 2013 07:43:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2237) JMX subsystem transformers
	for 7.2.0
In-Reply-To: <JIRA.12502323.1381146154051@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502323.1381146154051@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502323.1381146154051.18890.1381146184432@jira02.app.mwc.hst.phx2.redhat.com>

Kabir Khan created WFLY-2237:
--------------------------------

             Summary: JMX subsystem transformers for 7.2.0
                 Key: WFLY-2237
                 URL: https://issues.jboss.org/browse/WFLY-2237
             Project: WildFly
          Issue Type: Sub-task
          Components: JMX
            Reporter: Kabir Khan
            Assignee: Kabir Khan
             Fix For: 8.0.0.CR1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 07:45:04 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Mon, 7 Oct 2013 07:45:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2238) Logging subsystem
	transformers for 7.2.0
In-Reply-To: <JIRA.12502324.1381146266467@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502324.1381146266467@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502324.1381146266467.18911.1381146304219@jira02.app.mwc.hst.phx2.redhat.com>

Kabir Khan created WFLY-2238:
--------------------------------

             Summary: Logging subsystem transformers for 7.2.0
                 Key: WFLY-2238
                 URL: https://issues.jboss.org/browse/WFLY-2238
             Project: WildFly
          Issue Type: Sub-task
          Components: Logging
            Reporter: Kabir Khan
            Assignee: James Perkins
             Fix For: 8.0.0.CR1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 07:47:02 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Mon, 7 Oct 2013 07:47:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2239) Messaging subsystem
	transformers for 7.2.0
In-Reply-To: <JIRA.12502325.1381146310089@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502325.1381146310089@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502325.1381146310089.18937.1381146422650@jira02.app.mwc.hst.phx2.redhat.com>

Kabir Khan created WFLY-2239:
--------------------------------

             Summary: Messaging subsystem transformers for 7.2.0
                 Key: WFLY-2239
                 URL: https://issues.jboss.org/browse/WFLY-2239
             Project: WildFly
          Issue Type: Sub-task
          Components: JMX
            Reporter: Kabir Khan
            Assignee: Kabir Khan
             Fix For: 8.0.0.CR1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 07:47:02 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Mon, 7 Oct 2013 07:47:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2240) Modcluster transformers for
	7.2.0
In-Reply-To: <JIRA.12502326.1381146344416@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502326.1381146344416@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502326.1381146344416.18940.1381146422769@jira02.app.mwc.hst.phx2.redhat.com>

Kabir Khan created WFLY-2240:
--------------------------------

             Summary: Modcluster transformers for 7.2.0
                 Key: WFLY-2240
                 URL: https://issues.jboss.org/browse/WFLY-2240
             Project: WildFly
          Issue Type: Sub-task
            Reporter: Kabir Khan
             Fix For: 8.0.0.CR1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 07:47:02 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Mon, 7 Oct 2013 07:47:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2241) Naming subsystem transformers
	for 7.2.0
In-Reply-To: <JIRA.12502327.1381146366983@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502327.1381146366983@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502327.1381146366983.18942.1381146422857@jira02.app.mwc.hst.phx2.redhat.com>

Kabir Khan created WFLY-2241:
--------------------------------

             Summary: Naming subsystem transformers for 7.2.0
                 Key: WFLY-2241
                 URL: https://issues.jboss.org/browse/WFLY-2241
             Project: WildFly
          Issue Type: Sub-task
            Reporter: Kabir Khan




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 07:49:02 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Mon, 7 Oct 2013 07:49:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2242) Remoting subsystem
	transformers for 7.2.0
In-Reply-To: <JIRA.12502328.1381146428045@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502328.1381146428045@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502328.1381146428045.18962.1381146542775@jira02.app.mwc.hst.phx2.redhat.com>

Kabir Khan created WFLY-2242:
--------------------------------

             Summary: Remoting subsystem transformers for 7.2.0
                 Key: WFLY-2242
                 URL: https://issues.jboss.org/browse/WFLY-2242
             Project: WildFly
          Issue Type: Sub-task
          Components: Remoting
            Reporter: Kabir Khan
            Assignee: Kabir Khan
             Fix For: 8.0.0.CR1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 07:49:03 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Mon, 7 Oct 2013 07:49:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2243) Resource Adapters subsystem
 transformers for 7.2.0
In-Reply-To: <JIRA.12502329.1381146471884@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502329.1381146471884@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502329.1381146471884.18967.1381146543040@jira02.app.mwc.hst.phx2.redhat.com>

Kabir Khan created WFLY-2243:
--------------------------------

             Summary: Resource Adapters subsystem transformers for 7.2.0
                 Key: WFLY-2243
                 URL: https://issues.jboss.org/browse/WFLY-2243
             Project: WildFly
          Issue Type: Sub-task
          Components: JCA
            Reporter: Kabir Khan
            Assignee: Jesper Pedersen
             Fix For: 8.0.0.CR1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 07:49:03 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Mon, 7 Oct 2013 07:49:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2244) Security subsystem
	transformers for 7.2.0
In-Reply-To: <JIRA.12502330.1381146506572@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502330.1381146506572@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502330.1381146506572.18973.1381146543311@jira02.app.mwc.hst.phx2.redhat.com>

Kabir Khan created WFLY-2244:
--------------------------------

             Summary: Security subsystem transformers for 7.2.0
                 Key: WFLY-2244
                 URL: https://issues.jboss.org/browse/WFLY-2244
             Project: WildFly
          Issue Type: Sub-task
            Reporter: Kabir Khan
             Fix For: 8.0.0.CR1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 07:49:04 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Mon, 7 Oct 2013 07:49:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2245) Transactions subsystem
 transformers for 7.2.0
In-Reply-To: <JIRA.12502331.1381146540630@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502331.1381146540630@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502331.1381146540630.18999.1381146544553@jira02.app.mwc.hst.phx2.redhat.com>

Kabir Khan created WFLY-2245:
--------------------------------

             Summary: Transactions subsystem transformers for 7.2.0
                 Key: WFLY-2245
                 URL: https://issues.jboss.org/browse/WFLY-2245
             Project: WildFly
          Issue Type: Sub-task
          Components: Transactions
            Reporter: Kabir Khan
            Assignee: jaikiran pai
             Fix For: 8.0.0.CR1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 07:51:02 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Mon, 7 Oct 2013 07:51:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2244) Security subsystem
	transformers for 7.2.0
In-Reply-To: <JIRA.12502330.1381146506000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502330.1381146506000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502330.1381146506000.19019.1381146662772@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-2244:
-----------------------------

    Component/s: Security
                     (was: Domain Management)

    
> Security subsystem transformers for 7.2.0
> -----------------------------------------
>
>                 Key: WFLY-2244
>                 URL: https://issues.jboss.org/browse/WFLY-2244
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Security
>            Reporter: Kabir Khan
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 07:51:02 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Mon, 7 Oct 2013 07:51:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2244) Security subsystem
	transformers for 7.2.0
In-Reply-To: <JIRA.12502330.1381146506000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502330.1381146506000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502330.1381146506000.19023.1381146662962@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan reassigned WFLY-2244:
--------------------------------

    Assignee: Darran Lofthouse

    
> Security subsystem transformers for 7.2.0
> -----------------------------------------
>
>                 Key: WFLY-2244
>                 URL: https://issues.jboss.org/browse/WFLY-2244
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Security
>            Reporter: Kabir Khan
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 07:51:03 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Mon, 7 Oct 2013 07:51:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2240) Modcluster transformers for
	7.2.0
In-Reply-To: <JIRA.12502326.1381146344000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502326.1381146344000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502326.1381146344000.19027.1381146663135@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan reassigned WFLY-2240:
--------------------------------

    Assignee: Jean-Frederic Clere

    
> Modcluster transformers for 7.2.0
> ---------------------------------
>
>                 Key: WFLY-2240
>                 URL: https://issues.jboss.org/browse/WFLY-2240
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Jean-Frederic Clere
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 07:51:03 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Mon, 7 Oct 2013 07:51:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2241) Naming subsystem transformers
	for 7.2.0
In-Reply-To: <JIRA.12502327.1381146366000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502327.1381146366000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502327.1381146366000.19031.1381146663286@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan reassigned WFLY-2241:
--------------------------------

    Assignee: Brian Stansberry

    
> Naming subsystem transformers for 7.2.0
> ---------------------------------------
>
>                 Key: WFLY-2241
>                 URL: https://issues.jboss.org/browse/WFLY-2241
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Brian Stansberry
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 07:51:03 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Mon, 7 Oct 2013 07:51:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2240) Modcluster transformers for
	7.2.0
In-Reply-To: <JIRA.12502326.1381146344000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502326.1381146344000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502326.1381146344000.19036.1381146663480@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-2240:
-----------------------------

    Component/s: Clustering
                     (was: Domain Management)

    
> Modcluster transformers for 7.2.0
> ---------------------------------
>
>                 Key: WFLY-2240
>                 URL: https://issues.jboss.org/browse/WFLY-2240
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Clustering
>            Reporter: Kabir Khan
>            Assignee: Jean-Frederic Clere
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 07:51:03 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Mon, 7 Oct 2013 07:51:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2241) Naming subsystem transformers
	for 7.2.0
In-Reply-To: <JIRA.12502327.1381146366000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502327.1381146366000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502327.1381146366000.19039.1381146663595@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-2241:
-----------------------------

    Component/s: Naming
                     (was: Domain Management)

    
> Naming subsystem transformers for 7.2.0
> ---------------------------------------
>
>                 Key: WFLY-2241
>                 URL: https://issues.jboss.org/browse/WFLY-2241
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Naming
>            Reporter: Kabir Khan
>            Assignee: Brian Stansberry
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 07:53:02 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Mon, 7 Oct 2013 07:53:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2246) Weld
In-Reply-To: <JIRA.12502332.1381146729164@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502332.1381146729164@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502332.1381146729164.19045.1381146782777@jira02.app.mwc.hst.phx2.redhat.com>

Kabir Khan created WFLY-2246:
--------------------------------

             Summary: Weld
                 Key: WFLY-2246
                 URL: https://issues.jboss.org/browse/WFLY-2246
             Project: WildFly
          Issue Type: Sub-task
          Components: CDI / Weld
            Reporter: Kabir Khan
            Assignee: Stuart Douglas
             Fix For: 8.0.0.CR1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 07:53:02 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Mon, 7 Oct 2013 07:53:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2246) Weld subsystem transformers
	for 7.2.0
In-Reply-To: <JIRA.12502332.1381146729000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502332.1381146729000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502332.1381146729000.19048.1381146782883@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-2246:
-----------------------------

    Summary: Weld subsystem transformers for 7.2.0  (was: Weld)

    
> Weld subsystem transformers for 7.2.0
> -------------------------------------
>
>                 Key: WFLY-2246
>                 URL: https://issues.jboss.org/browse/WFLY-2246
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: CDI / Weld
>            Reporter: Kabir Khan
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 08:04:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Oct 2013 08:04:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1547) deploy directories not
	cleaned up
In-Reply-To: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479851.1353935247000.19090.1381147443138@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12810467#comment-12810467 ] 

RH Bugzilla Integration commented on WFLY-1547:
-----------------------------------------------

Nikoleta Ziakova <nziakova at redhat.com> made a comment on [bug 1004383|https://bugzilla.redhat.com/show_bug.cgi?id=1004383]

In EAP 6.2.0 ER3 jboss-vfs was upgraded to 3.2.2.Final instead of 3.2.0.Final. Is this version correct, please?

Upgrade was made correctly and if the version is OK then I can set this issue verified.

Both EAP zip and Maven repo zip contain jboss-vfs-3.2.2.Final-redhat-1.jar

pom.xml in EAP src zip:
  <version.org.jboss.jboss-vfs>3.2.2.Final-redhat-1</version.org.jboss.jboss-vfs>
  <dependency>
      <groupId>org.jboss</groupId>
      <artifactId>jboss-vfs</artifactId>
      <version>${version.org.jboss.jboss-vfs}</version>
  </dependency>

eap6-supported-artifacts-6.2.0.Beta1.pom in Maven repo zip:
  <dependency>
    <groupId>org.jboss</groupId>
    <artifactId>jboss-vfs</artifactId>
    <version>3.2.2.Final-redhat-1</version>
  </dependency>
                
> deploy directories not cleaned up
> ---------------------------------
>
>                 Key: WFLY-1547
>                 URL: https://issues.jboss.org/browse/WFLY-1547
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Shaun Appleton
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Beta1
>
>         Attachments: deployment_with_hack_no_hook.txt
>
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 08:04:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Oct 2013 08:04:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1547) deploy directories not
	cleaned up
In-Reply-To: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479851.1353935247000.19103.1381147443678@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12810468#comment-12810468 ] 

RH Bugzilla Integration commented on WFLY-1547:
-----------------------------------------------

Tomaz Cerar <tcerar at redhat.com> made a comment on [bug 1004383|https://bugzilla.redhat.com/show_bug.cgi?id=1004383]

Yes, 3.2.2.Final is correct, 3.2.0 and 3.2.1 had issues in some scenarios.
                
> deploy directories not cleaned up
> ---------------------------------
>
>                 Key: WFLY-1547
>                 URL: https://issues.jboss.org/browse/WFLY-1547
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Shaun Appleton
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Beta1
>
>         Attachments: deployment_with_hack_no_hook.txt
>
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 08:06:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Oct 2013 08:06:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1341) Missing charset-related paths
	from sun.jdk
In-Reply-To: <JIRA.12491807.1368584295000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12491807.1368584295000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12491807.1368584295000.19109.1381147562702@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12810470#comment-12810470 ] 

RH Bugzilla Integration commented on WFLY-1341:
-----------------------------------------------

Ladislav Thon <lthon at redhat.com> changed the Status of [bug 959478|https://bugzilla.redhat.com/show_bug.cgi?id=959478] from ON_QA to ASSIGNED
                
> Missing charset-related paths from sun.jdk
> ------------------------------------------
>
>                 Key: WFLY-1341
>                 URL: https://issues.jboss.org/browse/WFLY-1341
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Brad Maxwell
>            Assignee: David Lloyd
>             Fix For: 8.0.0.Alpha1
>
>
> The sun.jdk module needs the sun.nio.ext and sun.nio.cs packages to load charsets from application code properly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 08:08:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Oct 2013 08:08:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1341) Missing charset-related paths
	from sun.jdk
In-Reply-To: <JIRA.12491807.1368584295000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12491807.1368584295000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12491807.1368584295000.19112.1381147682540@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12810471#comment-12810471 ] 

RH Bugzilla Integration commented on WFLY-1341:
-----------------------------------------------

Ladislav Thon <lthon at redhat.com> made a comment on [bug 959478|https://bugzilla.redhat.com/show_bug.cgi?id=959478]

I don't think this has been fixed correctly. Specifically, I belive that there is no such package as "sun.nio.ext" -- instead, it should have been "sun.nio.cs.ext". Moving back to assigned.

On the other hand, I admit I'm not expert in this area, so I'd like to be proven wrong :-)
                
> Missing charset-related paths from sun.jdk
> ------------------------------------------
>
>                 Key: WFLY-1341
>                 URL: https://issues.jboss.org/browse/WFLY-1341
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Brad Maxwell
>            Assignee: David Lloyd
>             Fix For: 8.0.0.Alpha1
>
>
> The sun.jdk module needs the sun.nio.ext and sun.nio.cs packages to load charsets from application code properly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 08:10:03 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 7 Oct 2013 08:10:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2231) Datasources subsystem
 transformers for 7.2.0
In-Reply-To: <JIRA.12502317.1381145882000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502317.1381145882000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502317.1381145882000.19120.1381147803003@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen reassigned WFLY-2231:
-------------------------------------

    Assignee: Stefano Maestri  (was: Jesper Pedersen)

    
> Datasources subsystem transformers for 7.2.0
> --------------------------------------------
>
>                 Key: WFLY-2231
>                 URL: https://issues.jboss.org/browse/WFLY-2231
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: JCA
>            Reporter: Kabir Khan
>            Assignee: Stefano Maestri
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 08:10:03 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 7 Oct 2013 08:10:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2235) JCA subsystem transformers
	for 7.2.0
In-Reply-To: <JIRA.12502321.1381146069000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502321.1381146069000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502321.1381146069000.19125.1381147803239@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen reassigned WFLY-2235:
-------------------------------------

    Assignee: Stefano Maestri  (was: Jesper Pedersen)

    
> JCA subsystem transformers for 7.2.0
> ------------------------------------
>
>                 Key: WFLY-2235
>                 URL: https://issues.jboss.org/browse/WFLY-2235
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: JCA
>            Reporter: Kabir Khan
>            Assignee: Stefano Maestri
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 08:10:03 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 7 Oct 2013 08:10:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2243) Resource Adapters subsystem
 transformers for 7.2.0
In-Reply-To: <JIRA.12502329.1381146471000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502329.1381146471000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502329.1381146471000.19129.1381147803397@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen reassigned WFLY-2243:
-------------------------------------

    Assignee: Stefano Maestri  (was: Jesper Pedersen)

    
> Resource Adapters subsystem transformers for 7.2.0
> --------------------------------------------------
>
>                 Key: WFLY-2243
>                 URL: https://issues.jboss.org/browse/WFLY-2243
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: JCA
>            Reporter: Kabir Khan
>            Assignee: Stefano Maestri
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 08:18:02 2013
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 7 Oct 2013 08:18:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2239) Messaging subsystem
	transformers for 7.2.0
In-Reply-To: <JIRA.12502325.1381146310000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502325.1381146310000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502325.1381146310000.19159.1381148282614@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil reassigned WFLY-2239:
---------------------------------

    Assignee: Jeff Mesnil  (was: Kabir Khan)

    
> Messaging subsystem transformers for 7.2.0
> ------------------------------------------
>
>                 Key: WFLY-2239
>                 URL: https://issues.jboss.org/browse/WFLY-2239
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: JMX
>            Reporter: Kabir Khan
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 08:18:02 2013
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 7 Oct 2013 08:18:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2239) Messaging subsystem
	transformers for 7.2.0
In-Reply-To: <JIRA.12502325.1381146310000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502325.1381146310000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502325.1381146310000.19161.1381148282762@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil updated WFLY-2239:
------------------------------

    Component/s: JMS
                     (was: JMX)

    
> Messaging subsystem transformers for 7.2.0
> ------------------------------------------
>
>                 Key: WFLY-2239
>                 URL: https://issues.jboss.org/browse/WFLY-2239
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: JMS
>            Reporter: Kabir Khan
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 08:32:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 7 Oct 2013 08:32:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SASL-42) Add option to relax protocol
 check within mechanisms.
In-Reply-To: <JIRA.12502339.1381149061869@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502339.1381149061869@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502339.1381149061869.19202.1381149122598@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created SASL-42:
------------------------------------

             Summary: Add option to relax protocol check within mechanisms.
                 Key: SASL-42
                 URL: https://issues.jboss.org/browse/SASL-42
             Project: JBoss SASL Provider
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 1.0.4.CR1


The Digest MD5 mechanism contains a check that the URI received from the remote client matches the expected value, unfortunately older clients use a hard coded protocol or 'remote' - newer clients and servers use 'remoting'.

This issue is to add a configuration option so that server side this checking can be relaxed, most appropriate would be to supply a list of accepted alternative protocols.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 08:38:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 7 Oct 2013 08:38:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1592) Attempting to use eap6.1
 jboss-cli.sh to connect to remote wildfly (alpha1 or 2) fails;
 credentials not accepted
In-Reply-To: <JIRA.12495153.1372256939000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495153.1372256939000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495153.1372256939000.19230.1381149483040@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12810483#comment-12810483 ] 

Darran Lofthouse commented on WFLY-1592:
----------------------------------------

This issue is due to changes introduced in REM3-29 where the default protocol was switched from 'remote' to 'remoting'.

Reverting that change would not be appropriate as it is needed to be able to enable GSSAPI support.

The change for REM3-29 does allow the protocol name to be specified in configuration however doing that would require the same config on the server and in all clients - it would also only be a short term fix until we enable support for GSSAP.

SASL-42 will instead allow the server side to specify a list of accepted alternative protocols, when GSSAPI is in use it will be essential for clients using it to use the correct protocol but older clients may still want to connect with username / password auth.
                
> Attempting to use eap6.1 jboss-cli.sh to connect to remote wildfly (alpha1 or 2) fails; credentials not accepted
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1592
>                 URL: https://issues.jboss.org/browse/WFLY-1592
>             Project: WildFly
>          Issue Type: Bug
>          Components: Remoting, Security
>    Affects Versions: 8.0.0.Alpha2
>            Reporter: Rob Stryker
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Using eap6.1 client jars, or the jboss-cli.sh script in a local eap6.1 installation, to connect to a remote wildfly alpha1 or alpha2, seems to work but fails when provided with credentials.  This is most easily replicated as follows:
> 1) On remote machine start wildfly alpha1 or alpha2
> 2) on local machine, cd eap-6.1/bin
> 3) on local machine:
> [rob at rawbdor bin]$ ./jboss-cli.sh 
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
> [disconnected /] connect myhost.net 
> Authenticating against security realm: ManagementRealm
> Username: admin
>  Password: 
> Unable to authenticate against controller at myhost.net:9999: Authentication failed: all available authentication mechanisms failed
> This is an issue for tools as we need a set of jars that communicates correctly with all as7 servers. We currently have a set of jars that communicates with all 7.x / eap 6.x, which is good. If this is merely a bug on the server, then we can hopefully delay having to bundle an additional set of client jars until larger breakages occur. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 08:43:02 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 7 Oct 2013 08:43:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2247) Add javax.transaction.api to
	JDBC module
In-Reply-To: <JIRA.12502341.1381149662504@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502341.1381149662504@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502341.1381149662504.19242.1381149782504@jira02.app.mwc.hst.phx2.redhat.com>

Jesper Pedersen created WFLY-2247:
-------------------------------------

             Summary: Add javax.transaction.api to JDBC module
                 Key: WFLY-2247
                 URL: https://issues.jboss.org/browse/WFLY-2247
             Project: WildFly
          Issue Type: Bug
          Components: JCA
    Affects Versions: 8.0.0.Beta1
            Reporter: Jesper Pedersen
            Assignee: Stefano Maestri
             Fix For: 8.0.0.CR1


Add the javax.transaction.api module to the JDBC module such that people can use XA related classes during verification

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 08:55:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 7 Oct 2013 08:55:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2248) Upgrade to JBoss SASL
	1.0.4.CR1
In-Reply-To: <JIRA.12502345.1381150424686@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502345.1381150424686@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502345.1381150424686.19267.1381150503275@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-2248:
--------------------------------------

             Summary: Upgrade to JBoss SASL 1.0.4.CR1
                 Key: WFLY-2248
                 URL: https://issues.jboss.org/browse/WFLY-2248
             Project: WildFly
          Issue Type: Component  Upgrade
          Components: Domain Management, Remoting, Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 8.0.0.CR1


To allow relaxing the protocol check within the Digest MD5 mechanism.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 09:03:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Oct 2013 09:03:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1547) deploy directories not
	cleaned up
In-Reply-To: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479851.1353935247000.19304.1381150983163@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12810491#comment-12810491 ] 

RH Bugzilla Integration commented on WFLY-1547:
-----------------------------------------------

Nikoleta Ziakova <nziakova at redhat.com> changed the Status of [bug 1004383|https://bugzilla.redhat.com/show_bug.cgi?id=1004383] from ON_QA to VERIFIED
                
> deploy directories not cleaned up
> ---------------------------------
>
>                 Key: WFLY-1547
>                 URL: https://issues.jboss.org/browse/WFLY-1547
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Shaun Appleton
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Beta1
>
>         Attachments: deployment_with_hack_no_hook.txt
>
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 09:03:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Oct 2013 09:03:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1547) deploy directories not
	cleaned up
In-Reply-To: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479851.1353935247000.19317.1381150983710@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12810492#comment-12810492 ] 

RH Bugzilla Integration commented on WFLY-1547:
-----------------------------------------------

Nikoleta Ziakova <nziakova at redhat.com> made a comment on [bug 1004383|https://bugzilla.redhat.com/show_bug.cgi?id=1004383]

Thank you.
Verified for EAP 6.2.0 ER3.
                
> deploy directories not cleaned up
> ---------------------------------
>
>                 Key: WFLY-1547
>                 URL: https://issues.jboss.org/browse/WFLY-1547
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Shaun Appleton
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Beta1
>
>         Attachments: deployment_with_hack_no_hook.txt
>
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 09:03:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Oct 2013 09:03:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-101) JMSService.start is doing
	blocking I/O
In-Reply-To: <JIRA.12489128.1365693199000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489128.1365693199000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489128.1365693199000.19320.1381150983838@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12810493#comment-12810493 ] 

RH Bugzilla Integration commented on WFLY-101:
----------------------------------------------

Miroslav Novak <mnovak at redhat.com> made a comment on [bug 1003913|https://bugzilla.redhat.com/show_bug.cgi?id=1003913]

Hi Jeff, 

could you help with verification of this bz, please? I can see that PR contains actually more than one thing. "HornetQ fail-back results in XA recovery warnings" I can verify easily.

Problem is "[WFLY-101] JMSService.start to perform blocking I/O asynchronously" I guess only way to verify is to read the code, right?
                
> JMSService.start is doing blocking I/O
> --------------------------------------
>
>                 Key: WFLY-101
>                 URL: https://issues.jboss.org/browse/WFLY-101
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.Alpha1
>
>
> flag the start context as asynchronous

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 09:21:02 2013
From: jira-events at lists.jboss.org (Juergen Zimmermann (JIRA))
Date: Mon, 7 Oct 2013 09:21:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2249) NPE during redeployment of a
	war
In-Reply-To: <JIRA.12502347.1381151954567@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502347.1381151954567@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502347.1381151954567.19396.1381152062700@jira02.app.mwc.hst.phx2.redhat.com>

Juergen Zimmermann created WFLY-2249:
----------------------------------------

             Summary: NPE during redeployment of a war
                 Key: WFLY-2249
                 URL: https://issues.jboss.org/browse/WFLY-2249
             Project: WildFly
          Issue Type: Bug
          Components: JPA / Hibernate
    Affects Versions: 8.0.0.Beta1
            Reporter: Juergen Zimmermann
            Assignee: Scott Marlow


When I redeploy an already running war, then I get the following NPE. The (re-) deployment is done via the Maven plugin org.jboss.as.plugins:jboss-as-maven-plugin:7.4.Final. It looks like the redployment was successful anyway. Hmm...

{code}
ERROR [org.jboss.msc.service.fail] MSC000001: Failed to start service jboss.deployment.unit."shop.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."shop.war".PARSE: JBAS018733: Failed to process phase PARSE of deployment "shop.war"
	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
Caused by: java.lang.NullPointerException
	at org.jboss.as.jpa.processor.PersistenceUnitParseProcessor.handleWarDeployment(PersistenceUnitParseProcessor.java:126)
	at org.jboss.as.jpa.processor.PersistenceUnitParseProcessor.deploy(PersistenceUnitParseProcessor.java:83)
	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta1.jar:8.0.0.Beta1]
	... 5 more
{code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 09:26:02 2013
From: jira-events at lists.jboss.org (Radoslav Husar (JIRA))
Date: Mon, 7 Oct 2013 09:26:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2240) Modcluster transformers for
	7.2.0
In-Reply-To: <JIRA.12502326.1381146344000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502326.1381146344000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502326.1381146344000.19404.1381152362859@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar reassigned WFLY-2240:
------------------------------------

    Assignee: Radoslav Husar  (was: Jean-Frederic Clere)


I ll take it as im working on the related transformers.
                
> Modcluster transformers for 7.2.0
> ---------------------------------
>
>                 Key: WFLY-2240
>                 URL: https://issues.jboss.org/browse/WFLY-2240
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Clustering
>            Reporter: Kabir Khan
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 09:28:02 2013
From: jira-events at lists.jboss.org (Pete Muir (JIRA))
Date: Mon, 7 Oct 2013 09:28:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-446) Add quickstarts info to
	localhost:8080
In-Reply-To: <JIRA.12452122.1321276825000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12452122.1321276825000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12452122.1321276825000.19406.1381152482513@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pete Muir resolved WFLY-446.
----------------------------

    Fix Version/s:     (was: 8.0.0.CR1)
       Resolution: Out of Date


Now out of date, quickstarts target EAP.
                
> Add quickstarts info to localhost:8080
> --------------------------------------
>
>                 Key: WFLY-446
>                 URL: https://issues.jboss.org/browse/WFLY-446
>             Project: WildFly
>          Issue Type: Task
>            Reporter: Pete Muir
>            Assignee: Pete Muir
>            Priority: Minor
>
> Add another static page, quickstarts.html, that lists the quickstarts available and how to get them. Add a link from the main page.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 09:36:02 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 7 Oct 2013 09:36:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-364) a
 "failure-causes-rollback="false"" attribute for the filesystem scanner
In-Reply-To: <JIRA.12464247.1334623605000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12464247.1334623605000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12464247.1334623605000.19433.1381152962907@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFLY-364:
-------------------------------------

    Assignee: Brian Stansberry

    
> a "failure-causes-rollback="false"" attribute for the filesystem scanner
> ------------------------------------------------------------------------
>
>                 Key: WFLY-364
>                 URL: https://issues.jboss.org/browse/WFLY-364
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Max Rydahl Andersen
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> JBIDE-11509, AS7-783 and TORQUE-576 all talk about the problem of all deployments found at startup is deployed in one operation and if one deployment fails all is rolled back resulting in some rather bad usability issues - especially at development time, but even also at production time for those using file deployments.
> Suggestion on irc was that there could be an option on the file scanner (possibly false by default?) to say that failure causes rollback.
> Individual deployments could then still fail, but at least not everything would be rolledback and it would still allow proper interdependent deployments to work. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 09:50:02 2013
From: jira-events at lists.jboss.org (Farah Juma (JIRA))
Date: Mon, 7 Oct 2013 09:50:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2176) JSF should be able to access
 the CDI-enabled ValidatorFactory
In-Reply-To: <JIRA.12501764.1380319880000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501764.1380319880000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501764.1380319880000.19511.1381153802483@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Farah Juma updated WFLY-2176:
-----------------------------

    Fix Version/s: 8.0.0.CR1

    
> JSF should be able to access the CDI-enabled ValidatorFactory
> -------------------------------------------------------------
>
>                 Key: WFLY-2176
>                 URL: https://issues.jboss.org/browse/WFLY-2176
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JSF
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Farah Juma
>            Assignee: Farah Juma
>             Fix For: 8.0.0.CR1
>
>
> Currently, for every deployment that uses JSF, the JSF subsystem adds the org.hibernate.validator module to the deployment.  A ValidatorFactory is then obtained via the standard Bean Validation bootstrap strategy. However, a ValidatorFactory obtained this way isn't CDI-enabled. JSF needs to use the EE LazyValidatorFactory instead.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 10:17:03 2013
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Mon, 7 Oct 2013 10:17:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2250) Upgrade JGroups to 3.4.0.Final
In-Reply-To: <JIRA.12502351.1381155380373@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502351.1381155380373@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502351.1381155380373.19598.1381155423106@jira02.app.mwc.hst.phx2.redhat.com>

Paul Ferraro created WFLY-2250:
----------------------------------

             Summary: Upgrade JGroups to 3.4.0.Final
                 Key: WFLY-2250
                 URL: https://issues.jboss.org/browse/WFLY-2250
             Project: WildFly
          Issue Type: Component  Upgrade
          Components: Clustering
    Affects Versions: 8.0.0.Beta1
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro
             Fix For: 8.0.0.CR1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 10:25:02 2013
From: jira-events at lists.jboss.org (Frank Cornelis (JIRA))
Date: Mon, 7 Oct 2013 10:25:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2251) ;
	jsessionid=... in URL not supported
In-Reply-To: <JIRA.12502353.1381155859686@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502353.1381155859686@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502353.1381155859686.19633.1381155902584@jira02.app.mwc.hst.phx2.redhat.com>

Frank Cornelis created WFLY-2251:
------------------------------------

             Summary: ;jsessionid=... in URL not supported
                 Key: WFLY-2251
                 URL: https://issues.jboss.org/browse/WFLY-2251
             Project: WildFly
          Issue Type: Bug
          Components: Web (Undertow)
    Affects Versions: 8.0.0.Beta1
            Reporter: Frank Cornelis
            Assignee: Stuart Douglas
            Priority: Blocker


When configuring a servlet within your Java EE application, you can reach it via:
https://localhost/your_app_context/your_servlet_mapping
but not via:
https://localhost/your_app_context/your_servlet_mapping;jsessionid=whatever

You get a "Not Found" error message instead. This used to work under JBoss EAP 6.1.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 10:47:02 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Mon, 7 Oct 2013 10:47:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2239) Messaging subsystem
	transformers for 7.2.0
In-Reply-To: <JIRA.12502325.1381146310000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502325.1381146310000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502325.1381146310000.19666.1381157222616@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12810548#comment-12810548 ] 

Kabir Khan commented on WFLY-2239:
----------------------------------

Jeff, I noticed that the messaging subsystem transformers tests currently lack the following call:
{code}
checkSubsystemModelTransformation(mainServices, modelVersion);
{code}
That is needed to make sure that the model built up by the transformed operations is the same as the model created by the resource transformation. Please see the usage in the other transformers tests.
                
> Messaging subsystem transformers for 7.2.0
> ------------------------------------------
>
>                 Key: WFLY-2239
>                 URL: https://issues.jboss.org/browse/WFLY-2239
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: JMS
>            Reporter: Kabir Khan
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 10:51:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Oct 2013 10:51:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1489) Incorrect heap description in
 VM metrics view
In-Reply-To: <JIRA.12493929.1370859389000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493929.1370859389000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493929.1370859389000.19672.1381157462682@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12810549#comment-12810549 ] 

RH Bugzilla Integration commented on WFLY-1489:
-----------------------------------------------

Heiko Braun <hbraun at redhat.com> changed the Status of [bug 880648|https://bugzilla.redhat.com/show_bug.cgi?id=880648] from NEW to MODIFIED
                
> Incorrect heap description in VM metrics view
> ---------------------------------------------
>
>                 Key: WFLY-1489
>                 URL: https://issues.jboss.org/browse/WFLY-1489
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web Console
>            Reporter: Heiko Braun
>            Assignee: Chao Wang
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 10:57:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 7 Oct 2013 10:57:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SASL-42) Add option to relax protocol
 check within mechanisms.
In-Reply-To: <JIRA.12502339.1381149061000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502339.1381149061000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502339.1381149061000.19691.1381157822568@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SASL-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved SASL-42.
----------------------------------

    Resolution: Done

    
> Add option to relax protocol check within mechanisms.
> -----------------------------------------------------
>
>                 Key: SASL-42
>                 URL: https://issues.jboss.org/browse/SASL-42
>             Project: JBoss SASL Provider
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.0.4.CR1
>
>
> The Digest MD5 mechanism contains a check that the URI received from the remote client matches the expected value, unfortunately older clients use a hard coded protocol or 'remote' - newer clients and servers use 'remoting'.
> This issue is to add a configuration option so that server side this checking can be relaxed, most appropriate would be to supply a list of accepted alternative protocols.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 10:59:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 7 Oct 2013 10:59:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SASL-43) Release JBoss SASL 1.0.4.CR1
In-Reply-To: <JIRA.12502358.1381157855128@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502358.1381157855128@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502358.1381157855128.19694.1381157942561@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created SASL-43:
------------------------------------

             Summary: Release JBoss SASL 1.0.4.CR1
                 Key: SASL-43
                 URL: https://issues.jboss.org/browse/SASL-43
             Project: JBoss SASL Provider
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 11:07:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Oct 2013 11:07:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1697) Fix JPA
 SerializableValidatorFactory memory leak
In-Reply-To: <JIRA.12496481.1373901643000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496481.1373901643000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496481.1373901643000.19734.1381158422761@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12810561#comment-12810561 ] 

RH Bugzilla Integration commented on WFLY-1697:
-----------------------------------------------

Tomaz Cerar <tcerar at redhat.com> made a comment on [bug 1003600|https://bugzilla.redhat.com/show_bug.cgi?id=1003600]

I can reproduce this, it is related to buggy h2 we use for ExampleDB datasource.
I will send PR to address this same way we did in upstream
                
> Fix JPA SerializableValidatorFactory memory leak
> ------------------------------------------------
>
>                 Key: WFLY-1697
>                 URL: https://issues.jboss.org/browse/WFLY-1697
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>
> See http://lists.jboss.org/pipermail/wildfly-dev/2013-July/000466.html for details on recreating the SerializableValidatorFactory leak and Hibernate service loader references to Integreation class/properties.  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 11:45:02 2013
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 7 Oct 2013 11:45:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2218) Subsystem transformers
	against 7.2.0
In-Reply-To: <JIRA.12502213.1380892269000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502213.1380892269000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502213.1380892269000.19877.1381160702800@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil updated WFLY-2218:
------------------------------

    Description: 
We have not tested the majority of subsystem transformers against AS 7.2.0. I have attempted to document why we need subsystem transformation here, and also how to use the framework: 

https://docs.jboss.org/author/display/WFLY8/Domain+Mode+Subsystem+Transformers

This document is WIP, and I will be updating it a bit more over the next few days.

https://gist.github.com/kabir/6825607 contains the difference of a running WildFly instance against AS 7.2.0 in domain mode (for subsystems you don't really need to bother about this one)

https://gist.github.com/kabir/6825559 contains the difference of a running WildFly instance against AS 7.2.0 in standalone mode, here you can see what has changed in the subsystems.

When creating a new subsystem transformers test against 7.2.0, you will need the resource definition for the ModelVersion your subsystem uses in 7.2.0. If this is not found, you need to add a test to your subsystem, which you can delete once you have the .dmr file containing the resource defintion. Here is what I did to generate the file for JMX
{code}
    @Test
    public void deleteMeWhenDone() throws Exception {
        ModelTestControllerVersion controllerVersion = ModelTestControllerVersion.V7_2_0_FINAL;
        ModelVersion modelVersion = ModelVersion.create(1, 1, 0); //Whatever version of your subsystem 7.2.0.Final has
        KernelServicesBuilder builder = createKernelServicesBuilder(null);

        builder.createLegacyKernelServicesBuilder(null, controllerVersion, modelVersion)
            .addMavenResourceURL("org.jboss.as:jboss-as-jmx:" + controllerVersion.getMavenGavVersion());
        KernelServices services = builder.build();

        generateLegacySubsystemResourceRegistrationDmr(services, modelVersion);
    }
{code}
Now run the test and delete it. The legacy .dmr file should be in {{target/test-classes/org/jboss/as/subsystem/test/<your-subsystem-name>-<your-version>.dmr}}. Copy this .dmr file to {{subsystem-test/framework/src/main/resources/org/jboss/as/subsystem/test}}.

You will likely also need to update org.jboss.as.subsystem.test.KnownVersions to include your latest subsystem version, once you start doing real testing.

Bear in mind that if you need to add some transformation to 7.2.0 due to some new feature in WildFly 8, you will probably also need to add the same transformation to 7.1.x as well!


  was:


We have not tested the majority of subsystem transformers against AS 7.2.0. I have attempted to document why we need subsystem transformation here, and also how to use the framework: https://docs.jboss.org/author/display/WFLY8/Domain+Mode+Subsystem+https://docs.jboss.org/author/display/WFLY8/Domain+Mode+Subsystem+Transformers. This document is WIP, and I will be updating it a bit more over the next few days.

https://gist.github.com/kabir/6825607 contains the difference of a running WildFly instance against AS 7.2.0 in domain mode (for subsystems you don't really need to bother about this one)

https://gist.github.com/kabir/6825559 contains the difference of a running WildFly instance against AS 7.2.0 in standalone mode, here you can see what has changed in the subsystems.

When creating a new subsystem transformers test against 7.2.0, you will need the resource definition for the ModelVersion your subsystem uses in 7.2.0. If this is not found, you need to add a test to your subsystem, which you can delete once you have the .dmr file containing the resource defintion. Here is what I did to generate the file for JMX
{code}
    @Test
    public void deleteMeWhenDone() throws Exception {
        ModelTestControllerVersion controllerVersion = ModelTestControllerVersion.V7_2_0_FINAL;
        ModelVersion modelVersion = ModelVersion.create(1, 1, 0); //Whatever version of your subsystem 7.2.0.Final has
        KernelServicesBuilder builder = createKernelServicesBuilder(null);

        builder.createLegacyKernelServicesBuilder(null, controllerVersion, modelVersion)
            .addMavenResourceURL("org.jboss.as:jboss-as-jmx:" + controllerVersion.getMavenGavVersion());
        KernelServices services = builder.build();

        generateLegacySubsystemResourceRegistrationDmr(services, modelVersion);
    }
{code}
Now run the test and delete it. The legacy .dmr file should be in {{target/test-classes/org/jboss/as/subsystem/test/<your-subsystem-name>-<your-version>.dmr}}. Copy this .dmr file to {{subsystem-test/framework/src/main/resources/org/jboss/as/subsystem/test}}.

You will likely also need to update org.jboss.as.subsystem.test.KnownVersions to include your latest subsystem version, once you start doing real testing.

Bear in mind that if you need to add some transformation to 7.2.0 due to some new feature in WildFly 8, you will probably also need to add the same transformation to 7.1.x as well!



    
> Subsystem transformers against 7.2.0
> ------------------------------------
>
>                 Key: WFLY-2218
>                 URL: https://issues.jboss.org/browse/WFLY-2218
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>    Affects Versions: 8.0.0.CR1
>            Reporter: Kabir Khan
>            Assignee: Brian Stansberry
>
> We have not tested the majority of subsystem transformers against AS 7.2.0. I have attempted to document why we need subsystem transformation here, and also how to use the framework: 
> https://docs.jboss.org/author/display/WFLY8/Domain+Mode+Subsystem+Transformers
> This document is WIP, and I will be updating it a bit more over the next few days.
> https://gist.github.com/kabir/6825607 contains the difference of a running WildFly instance against AS 7.2.0 in domain mode (for subsystems you don't really need to bother about this one)
> https://gist.github.com/kabir/6825559 contains the difference of a running WildFly instance against AS 7.2.0 in standalone mode, here you can see what has changed in the subsystems.
> When creating a new subsystem transformers test against 7.2.0, you will need the resource definition for the ModelVersion your subsystem uses in 7.2.0. If this is not found, you need to add a test to your subsystem, which you can delete once you have the .dmr file containing the resource defintion. Here is what I did to generate the file for JMX
> {code}
>     @Test
>     public void deleteMeWhenDone() throws Exception {
>         ModelTestControllerVersion controllerVersion = ModelTestControllerVersion.V7_2_0_FINAL;
>         ModelVersion modelVersion = ModelVersion.create(1, 1, 0); //Whatever version of your subsystem 7.2.0.Final has
>         KernelServicesBuilder builder = createKernelServicesBuilder(null);
>         builder.createLegacyKernelServicesBuilder(null, controllerVersion, modelVersion)
>             .addMavenResourceURL("org.jboss.as:jboss-as-jmx:" + controllerVersion.getMavenGavVersion());
>         KernelServices services = builder.build();
>         generateLegacySubsystemResourceRegistrationDmr(services, modelVersion);
>     }
> {code}
> Now run the test and delete it. The legacy .dmr file should be in {{target/test-classes/org/jboss/as/subsystem/test/<your-subsystem-name>-<your-version>.dmr}}. Copy this .dmr file to {{subsystem-test/framework/src/main/resources/org/jboss/as/subsystem/test}}.
> You will likely also need to update org.jboss.as.subsystem.test.KnownVersions to include your latest subsystem version, once you start doing real testing.
> Bear in mind that if you need to add some transformation to 7.2.0 due to some new feature in WildFly 8, you will probably also need to add the same transformation to 7.1.x as well!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 11:49:03 2013
From: jira-events at lists.jboss.org (Matt Fluet (JIRA))
Date: Mon, 7 Oct 2013 11:49:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2222) SecurityExceptions when
 starting server with signed jars in an exploded app deployment
In-Reply-To: <JIRA.12502248.1380908971000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502248.1380908971000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502248.1380908971000.19902.1381160943161@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12810593#comment-12810593 ] 

Matt Fluet commented on WFLY-2222:
----------------------------------

David, our testing with your latest commit looks good.  Automated restarts ran all weekend...our control site hit the SecurityException twice, but the site patched with the fix worked fine.
                
> SecurityExceptions when starting server with signed jars in an exploded app deployment
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-2222
>                 URL: https://issues.jboss.org/browse/WFLY-2222
>             Project: WildFly
>          Issue Type: Bug
>          Components: Class Loading
>            Reporter: Matt Fluet
>            Assignee: David Lloyd
>            Priority: Critical
>         Attachments: 0001-Fix-ClassLoader-SecurityException-with-jar-certifica.patch
>
>
> This issue is directly related to https://issues.jboss.org/browse/AS7-2724, where signed jars are sometimes throwing a security exception when the server starts up and then classes cannot be loaded out of certain packages (appears to be some sort of a concurrency issue).  
> The fix for that issue was applied to JarFileResourceLoader here:  https://github.com/jboss-modules/jboss-modules/commit/8cf33f5c02c0c4bf6f96d04efa8845762bbc90ae
> However, our application is exploded, so the VFSResourceLoader needs a similar fix.  I will attach a git patch file with the change we're proposing.
> To test the theory, we applied the patch to one server and left another as is as a control...we then left a process running that continually restarted the server for 3 days.  The control server hit the SecurityException problem 5 times, and the patched server didn't show it at all.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 11:55:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Oct 2013 11:55:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1697) Fix JPA
 SerializableValidatorFactory memory leak
In-Reply-To: <JIRA.12496481.1373901643000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496481.1373901643000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496481.1373901643000.19930.1381161302769@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12810600#comment-12810600 ] 

RH Bugzilla Integration commented on WFLY-1697:
-----------------------------------------------

Tomaz Cerar <tcerar at redhat.com> made a comment on [bug 1003600|https://bugzilla.redhat.com/show_bug.cgi?id=1003600]

https://github.com/jbossas/jboss-eap/pull/515
This PR changes default ExampleDS configuration to disable H2 DatabaseCloser thread creation which can hold reference to hibernate CL.

This same problem exists also in this quickstart
https://github.com/wildfly/quickstart/blob/master/kitchensink-html5-mobile/src/test/resources/arquillian-ds.xml also needs this change 
;DB_CLOSE_ON_EXIT=FALSE should be added to url.

with that change memory leak does not appear anymore.

This problem is related only to h2 in memory database and does not affect any other jdbc drivers I was testing.

If I run quickstart with modified datasource this memory leak does not appear anymore
                
> Fix JPA SerializableValidatorFactory memory leak
> ------------------------------------------------
>
>                 Key: WFLY-1697
>                 URL: https://issues.jboss.org/browse/WFLY-1697
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>
> See http://lists.jboss.org/pipermail/wildfly-dev/2013-July/000466.html for details on recreating the SerializableValidatorFactory leak and Hibernate service loader references to Integreation class/properties.  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 11:55:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Oct 2013 11:55:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1697) Fix JPA
 SerializableValidatorFactory memory leak
In-Reply-To: <JIRA.12496481.1373901643000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496481.1373901643000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496481.1373901643000.19932.1381161302832@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12810601#comment-12810601 ] 

RH Bugzilla Integration commented on WFLY-1697:
-----------------------------------------------

Tomaz Cerar <tcerar at redhat.com> changed the Status of [bug 1003600|https://bugzilla.redhat.com/show_bug.cgi?id=1003600] from ASSIGNED to ON_QA
                
> Fix JPA SerializableValidatorFactory memory leak
> ------------------------------------------------
>
>                 Key: WFLY-1697
>                 URL: https://issues.jboss.org/browse/WFLY-1697
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>
> See http://lists.jboss.org/pipermail/wildfly-dev/2013-July/000466.html for details on recreating the SerializableValidatorFactory leak and Hibernate service loader references to Integreation class/properties.  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 12:38:03 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Mon, 7 Oct 2013 12:38:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2242) Remoting subsystem
	transformers for 7.2.0
In-Reply-To: <JIRA.12502328.1381146428000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502328.1381146428000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502328.1381146428000.20149.1381163883220@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12810693#comment-12810693 ] 

Kabir Khan commented on WFLY-2242:
----------------------------------

This actually already had the transformers in place, but needed additional testing
                
> Remoting subsystem transformers for 7.2.0
> -----------------------------------------
>
>                 Key: WFLY-2242
>                 URL: https://issues.jboss.org/browse/WFLY-2242
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Remoting
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 13:00:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Oct 2013 13:00:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-67) Improve LogManager formatter
 capability: System resources, thread ID and minified category
In-Reply-To: <JIRA.12490045.1366637143000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12490045.1366637143000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12490045.1366637143000.20263.1381165204038@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/LOGMGR-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12810733#comment-12810733 ] 

RH Bugzilla Integration commented on LOGMGR-67:
-----------------------------------------------

James Perkins <jperkins at redhat.com> made a comment on [bug 994744|https://bugzilla.redhat.com/show_bug.cgi?id=994744]

Looks like the expression is attempting to be resolved by server instead of allowing the logmanager to resovle the expression.
                
> Improve LogManager formatter capability: System resources, thread ID and minified category
> ------------------------------------------------------------------------------------------
>
>                 Key: LOGMGR-67
>                 URL: https://issues.jboss.org/browse/LOGMGR-67
>             Project: JBoss Log Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: core
>    Affects Versions: 1.3.2.Final
>         Environment: JBoss EAP 6.0.1
>            Reporter: Jeremy KUHN
>            Assignee: James Perkins
>              Labels: jboss
>             Fix For: 1.5.0.Final, 2.0.0.Beta1
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> Hello,
> We are currently developing a major JEE application running on multiple JBoss EAP 6.0.1 instances in a service oriented architecture.
> The current implementation of JBoss-logmanager (1.3.2.Final) shipped with JBoss EAP doesn't provide the functionality we require in term of logging formatting.
> We are missing:
> - Thread ID (Thread names are too long and of different length that disturb the reading of logs)
> - we haven't find a way to get the hostname displayed in the logs, a simple solution would be to be able to include System properties and therefore the jboss.host.name property in the pattern. System properties would also be interesting to identified the log coming from a specific application (we'll have one application deployed per JBoss instance). Ideally, we'd like to have the ability to provide a context name to know which application has logged the event but this seems to have been delivered with logging profiles.
> - logback has this interesting feature that lets you minify the log category: instead of org.jboss.logmanager.config.ConfigAction you'll get o.j.l.c.ConfigAction which is more readable in the logs.
> Regards

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 14:22:03 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Mon, 7 Oct 2013 14:22:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2218) Subsystem transformers
	against 7.2.0
In-Reply-To: <JIRA.12502213.1380892269000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502213.1380892269000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502213.1380892269000.20631.1381170123324@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-2218:
-----------------------------

    Description: 
We have not tested the majority of subsystem transformers against AS 7.2.0. I have attempted to document why we need subsystem transformation here, and also how to use the framework: 

https://docs.jboss.org/author/display/WFLY8/Domain+Mode+Subsystem+Transformers

This document is WIP, and I will be updating it a bit more over the next few days.

https://gist.github.com/kabir/6825607 contains the difference of a running WildFly instance against AS 7.2.0 in domain mode (for subsystems you don't really need to bother about this one)

https://gist.github.com/kabir/6825559 contains the difference of a running WildFly instance against AS 7.2.0 in standalone mode, here you can see what has changed in the subsystems.

When creating a new subsystem transformers test against 7.2.0, you will need the resource definition for the ModelVersion your subsystem uses in 7.2.0. If this is not found, you need to add a test to your subsystem, which you can delete once you have the .dmr file containing the resource defintion. Here is what I did to generate the file for JMX
{code}
    @Test
    public void deleteMeWhenDone() throws Exception {
        ModelTestControllerVersion controllerVersion = ModelTestControllerVersion.V7_2_0_FINAL;
        ModelVersion modelVersion = ModelVersion.create(1, 1, 0); //Whatever version of your subsystem 7.2.0.Final has
        KernelServicesBuilder builder = createKernelServicesBuilder(null);

        builder.createLegacyKernelServicesBuilder(null, controllerVersion, modelVersion)
            .addMavenResourceURL("org.jboss.as:jboss-as-jmx:" + controllerVersion.getMavenGavVersion());
        KernelServices services = builder.build();

        generateLegacySubsystemResourceRegistrationDmr(services, modelVersion);
    }
{code}
Now run the test and delete it. The legacy .dmr file should be in {{target/test-classes/org/jboss/as/subsystem/test/<your-subsystem-name>-<your-version>.dmr}}. Copy this .dmr file to {{subsystem-test/framework/src/main/resources/org/jboss/as/subsystem/test}}.

You will likely also need to update org.jboss.as.subsystem.test.KnownVersions to include your latest subsystem version, once you start doing real testing.

Bear in mind that if you need to add some transformation to 7.2.0 due to some new feature in WildFly 8, you will probably also need to add the same transformation to 7.1.x as well!

Although some subsystems already have added transformers, we still need to add tests.

  was:
We have not tested the majority of subsystem transformers against AS 7.2.0. I have attempted to document why we need subsystem transformation here, and also how to use the framework: 

https://docs.jboss.org/author/display/WFLY8/Domain+Mode+Subsystem+Transformers

This document is WIP, and I will be updating it a bit more over the next few days.

https://gist.github.com/kabir/6825607 contains the difference of a running WildFly instance against AS 7.2.0 in domain mode (for subsystems you don't really need to bother about this one)

https://gist.github.com/kabir/6825559 contains the difference of a running WildFly instance against AS 7.2.0 in standalone mode, here you can see what has changed in the subsystems.

When creating a new subsystem transformers test against 7.2.0, you will need the resource definition for the ModelVersion your subsystem uses in 7.2.0. If this is not found, you need to add a test to your subsystem, which you can delete once you have the .dmr file containing the resource defintion. Here is what I did to generate the file for JMX
{code}
    @Test
    public void deleteMeWhenDone() throws Exception {
        ModelTestControllerVersion controllerVersion = ModelTestControllerVersion.V7_2_0_FINAL;
        ModelVersion modelVersion = ModelVersion.create(1, 1, 0); //Whatever version of your subsystem 7.2.0.Final has
        KernelServicesBuilder builder = createKernelServicesBuilder(null);

        builder.createLegacyKernelServicesBuilder(null, controllerVersion, modelVersion)
            .addMavenResourceURL("org.jboss.as:jboss-as-jmx:" + controllerVersion.getMavenGavVersion());
        KernelServices services = builder.build();

        generateLegacySubsystemResourceRegistrationDmr(services, modelVersion);
    }
{code}
Now run the test and delete it. The legacy .dmr file should be in {{target/test-classes/org/jboss/as/subsystem/test/<your-subsystem-name>-<your-version>.dmr}}. Copy this .dmr file to {{subsystem-test/framework/src/main/resources/org/jboss/as/subsystem/test}}.

You will likely also need to update org.jboss.as.subsystem.test.KnownVersions to include your latest subsystem version, once you start doing real testing.

Bear in mind that if you need to add some transformation to 7.2.0 due to some new feature in WildFly 8, you will probably also need to add the same transformation to 7.1.x as well!



    
> Subsystem transformers against 7.2.0
> ------------------------------------
>
>                 Key: WFLY-2218
>                 URL: https://issues.jboss.org/browse/WFLY-2218
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>    Affects Versions: 8.0.0.CR1
>            Reporter: Kabir Khan
>            Assignee: Brian Stansberry
>
> We have not tested the majority of subsystem transformers against AS 7.2.0. I have attempted to document why we need subsystem transformation here, and also how to use the framework: 
> https://docs.jboss.org/author/display/WFLY8/Domain+Mode+Subsystem+Transformers
> This document is WIP, and I will be updating it a bit more over the next few days.
> https://gist.github.com/kabir/6825607 contains the difference of a running WildFly instance against AS 7.2.0 in domain mode (for subsystems you don't really need to bother about this one)
> https://gist.github.com/kabir/6825559 contains the difference of a running WildFly instance against AS 7.2.0 in standalone mode, here you can see what has changed in the subsystems.
> When creating a new subsystem transformers test against 7.2.0, you will need the resource definition for the ModelVersion your subsystem uses in 7.2.0. If this is not found, you need to add a test to your subsystem, which you can delete once you have the .dmr file containing the resource defintion. Here is what I did to generate the file for JMX
> {code}
>     @Test
>     public void deleteMeWhenDone() throws Exception {
>         ModelTestControllerVersion controllerVersion = ModelTestControllerVersion.V7_2_0_FINAL;
>         ModelVersion modelVersion = ModelVersion.create(1, 1, 0); //Whatever version of your subsystem 7.2.0.Final has
>         KernelServicesBuilder builder = createKernelServicesBuilder(null);
>         builder.createLegacyKernelServicesBuilder(null, controllerVersion, modelVersion)
>             .addMavenResourceURL("org.jboss.as:jboss-as-jmx:" + controllerVersion.getMavenGavVersion());
>         KernelServices services = builder.build();
>         generateLegacySubsystemResourceRegistrationDmr(services, modelVersion);
>     }
> {code}
> Now run the test and delete it. The legacy .dmr file should be in {{target/test-classes/org/jboss/as/subsystem/test/<your-subsystem-name>-<your-version>.dmr}}. Copy this .dmr file to {{subsystem-test/framework/src/main/resources/org/jboss/as/subsystem/test}}.
> You will likely also need to update org.jboss.as.subsystem.test.KnownVersions to include your latest subsystem version, once you start doing real testing.
> Bear in mind that if you need to add some transformation to 7.2.0 due to some new feature in WildFly 8, you will probably also need to add the same transformation to 7.1.x as well!
> Although some subsystems already have added transformers, we still need to add tests.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 14:40:02 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Mon, 7 Oct 2013 14:40:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-288) Expose PMML compilation
	errors
In-Reply-To: <JIRA.12502378.1381171123637@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502378.1381171123637@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502378.1381171123637.20694.1381171202983@jira02.app.mwc.hst.phx2.redhat.com>

Davide Sottara created DROOLS-288:
-------------------------------------

             Summary: Expose PMML compilation errors
                 Key: DROOLS-288
                 URL: https://issues.jboss.org/browse/DROOLS-288
             Project: Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Davide Sottara
            Assignee: Mark Proctor
            Priority: Minor




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 14:44:02 2013
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Mon, 7 Oct 2013 14:44:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2252) Upgrade Infinispan to
	6.0.0.CR1
In-Reply-To: <JIRA.12502379.1381171415594@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502379.1381171415594@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502379.1381171415594.20710.1381171442647@jira02.app.mwc.hst.phx2.redhat.com>

Paul Ferraro created WFLY-2252:
----------------------------------

             Summary: Upgrade Infinispan to 6.0.0.CR1
                 Key: WFLY-2252
                 URL: https://issues.jboss.org/browse/WFLY-2252
             Project: WildFly
          Issue Type: Component  Upgrade
          Components: Clustering
    Affects Versions: 8.0.0.Beta1
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro
             Fix For: 8.0.0.CR1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 14:48:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Oct 2013 14:48:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1914) Application client container
	doesn't start
In-Reply-To: <JIRA.12499060.1377081913000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499060.1377081913000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499060.1377081913000.20718.1381171682657@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12810930#comment-12810930 ] 

RH Bugzilla Integration commented on WFLY-1914:
-----------------------------------------------

Aleksandar Kostadinov <akostadi at redhat.com> made a comment on [bug 999465|https://bugzilla.redhat.com/show_bug.cgi?id=999465]

Brian, I speculated that it is ER3.1, I'm using RPM distro that's possibly not exactly matching 3.1. I'll try again when ER5 is out.
                
> Application client container doesn't start
> ------------------------------------------
>
>                 Key: WFLY-1914
>                 URL: https://issues.jboss.org/browse/WFLY-1914
>             Project: WildFly
>          Issue Type: Bug
>          Components: Application Client
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Beta1
>
>
> Application client container fails to start with the following exception:
> {code}
> 16:23:40,742 INFO  [org.jboss.as.jacorb] (MSC service thread 1-7) JBAS016328: CORBA Naming Service started
> 16:23:40,744 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("add") failed - address: ([
>     ("subsystem" => "naming"),
>     ("service" => "remote-naming")
> ]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.naming.remote is missing [jboss.remoting.endpoint.subsystem]"]}
> 16:23:40,779 INFO  [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.remoting.endpoint.subsystem (missing) dependents: [service jboss.naming.remote] 
> 16:23:40,782 ERROR [org.jboss.as] (Controller Boot Thread) JBAS015875: WildFly 8.0.0.Beta1-SNAPSHOT "WildFly" started (with errors) in 1471ms - Started 99 of 103 services (1 services failed or missing dependencies, 9 services are lazy, passive or on-demand)
> {code}
> when started using the following command:
> {code}
> JBOSS_HOME/bin/appclient.sh /foo/bar/some.jar
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 14:56:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Oct 2013 14:56:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1914) Application client container
	doesn't start
In-Reply-To: <JIRA.12499060.1377081913000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499060.1377081913000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499060.1377081913000.20761.1381172162607@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12810941#comment-12810941 ] 

RH Bugzilla Integration commented on WFLY-1914:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> made a comment on [bug 999465|https://bugzilla.redhat.com/show_bug.cgi?id=999465]

Ah, I see. ER3.1 was just some sort of respin of ER3 that didn't include any new fixes.
                
> Application client container doesn't start
> ------------------------------------------
>
>                 Key: WFLY-1914
>                 URL: https://issues.jboss.org/browse/WFLY-1914
>             Project: WildFly
>          Issue Type: Bug
>          Components: Application Client
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Beta1
>
>
> Application client container fails to start with the following exception:
> {code}
> 16:23:40,742 INFO  [org.jboss.as.jacorb] (MSC service thread 1-7) JBAS016328: CORBA Naming Service started
> 16:23:40,744 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("add") failed - address: ([
>     ("subsystem" => "naming"),
>     ("service" => "remote-naming")
> ]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.naming.remote is missing [jboss.remoting.endpoint.subsystem]"]}
> 16:23:40,779 INFO  [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.remoting.endpoint.subsystem (missing) dependents: [service jboss.naming.remote] 
> 16:23:40,782 ERROR [org.jboss.as] (Controller Boot Thread) JBAS015875: WildFly 8.0.0.Beta1-SNAPSHOT "WildFly" started (with errors) in 1471ms - Started 99 of 103 services (1 services failed or missing dependencies, 9 services are lazy, passive or on-demand)
> {code}
> when started using the following command:
> {code}
> JBOSS_HOME/bin/appclient.sh /foo/bar/some.jar
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 15:00:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Oct 2013 15:00:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2173) Get subsystem test framework
 working with AS 7.2.0 legacy controller
In-Reply-To: <JIRA.12501755.1380296954000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501755.1380296954000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501755.1380296954000.20792.1381172403824@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12810954#comment-12810954 ] 

RH Bugzilla Integration commented on WFLY-2173:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1015245|https://bugzilla.redhat.com/show_bug.cgi?id=1015245] from ASSIGNED to POST
                
> Get subsystem test framework working with AS 7.2.0 legacy controller
> --------------------------------------------------------------------
>
>                 Key: WFLY-2173
>                 URL: https://issues.jboss.org/browse/WFLY-2173
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 15:00:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Oct 2013 15:00:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2185) Get core model test framework
 working with 7.2.0.Final legacy controller
In-Reply-To: <JIRA.12501848.1380553676000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501848.1380553676000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501848.1380553676000.20796.1381172403983@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12810956#comment-12810956 ] 

RH Bugzilla Integration commented on WFLY-2185:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1015245|https://bugzilla.redhat.com/show_bug.cgi?id=1015245] from ASSIGNED to POST
                
> Get core model test framework working with 7.2.0.Final legacy controller
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2185
>                 URL: https://issues.jboss.org/browse/WFLY-2185
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 16:11:02 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 7 Oct 2013 16:11:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2134) Changing management
 http-interface with CLI doesn't work.
In-Reply-To: <JIRA.12501315.1379949144000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501315.1379949144000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501315.1379949144000.21023.1381176662829@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-2134:
-----------------------------------

    Fix Version/s: 8.0.0.CR1
         Assignee: Darran Lofthouse  (was: Alexey Loubyansky)
      Component/s: Domain Management
                       (was: CLI)

    
> Changing management http-interface with CLI doesn't work.
> ---------------------------------------------------------
>
>                 Key: WFLY-2134
>                 URL: https://issues.jboss.org/browse/WFLY-2134
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Filip Bogyai
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> When you try to change http-interface with CLI you get: Communication error: java.util.concurrent.ExecutionException: Operation failed: Operation failed: Channel closed
> On server side: JBAS014626: Operation was interrupted before stability could be reached
> For example try to add secure-socket-binding attribute:
> /core-service=management/management-interface=http-interface:write-attribute(name=secure-socket-binding, value=management-https)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 16:11:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 7 Oct 2013 16:11:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2134) Changing management
 http-interface with CLI doesn't work.
In-Reply-To: <JIRA.12501315.1379949144000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501315.1379949144000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501315.1379949144000.21027.1381176663014@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12811046#comment-12811046 ] 

Brian Stansberry commented on WFLY-2134:
----------------------------------------

This is the same problem as WFLY-2194.
                
> Changing management http-interface with CLI doesn't work.
> ---------------------------------------------------------
>
>                 Key: WFLY-2134
>                 URL: https://issues.jboss.org/browse/WFLY-2134
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Filip Bogyai
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> When you try to change http-interface with CLI you get: Communication error: java.util.concurrent.ExecutionException: Operation failed: Operation failed: Channel closed
> On server side: JBAS014626: Operation was interrupted before stability could be reached
> For example try to add secure-socket-binding attribute:
> /core-service=management/management-interface=http-interface:write-attribute(name=secure-socket-binding, value=management-https)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 16:11:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 7 Oct 2013 16:11:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2134) Changing management
 http-interface with CLI doesn't work.
In-Reply-To: <JIRA.12501315.1379949144000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501315.1379949144000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501315.1379949144000.21031.1381176663305@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry resolved WFLY-2134.
------------------------------------

    Resolution: Done

    
> Changing management http-interface with CLI doesn't work.
> ---------------------------------------------------------
>
>                 Key: WFLY-2134
>                 URL: https://issues.jboss.org/browse/WFLY-2134
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Filip Bogyai
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> When you try to change http-interface with CLI you get: Communication error: java.util.concurrent.ExecutionException: Operation failed: Operation failed: Channel closed
> On server side: JBAS014626: Operation was interrupted before stability could be reached
> For example try to add secure-socket-binding attribute:
> /core-service=management/management-interface=http-interface:write-attribute(name=secure-socket-binding, value=management-https)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 16:29:02 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Mon, 7 Oct 2013 16:29:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2253) component upgrade to jipijapa
	1.0.0.Beta2
In-Reply-To: <JIRA.12502386.1381177639212@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502386.1381177639212@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502386.1381177639212.21116.1381177742718@jira02.app.mwc.hst.phx2.redhat.com>

Scott Marlow created WFLY-2253:
----------------------------------

             Summary: component upgrade to jipijapa 1.0.0.Beta2
                 Key: WFLY-2253
                 URL: https://issues.jboss.org/browse/WFLY-2253
             Project: WildFly
          Issue Type: Feature Request
          Components: JPA / Hibernate
            Reporter: Scott Marlow
            Assignee: Scott Marlow
             Fix For: 8.0.0.CR1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 17:03:02 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 7 Oct 2013 17:03:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2254) Allow restart of management
 interface services via allow-resource-restart header
In-Reply-To: <JIRA.12502399.1381179712289@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502399.1381179712289@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502399.1381179712289.21335.1381179782586@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-2254:
--------------------------------------

             Summary: Allow restart of management interface services via allow-resource-restart header
                 Key: WFLY-2254
                 URL: https://issues.jboss.org/browse/WFLY-2254
             Project: WildFly
          Issue Type: Enhancement
          Components: Domain Management
            Reporter: Brian Stansberry
            Priority: Minor


The management interface resources seem like good candidates for allow-resource-restart handling. A restart of the services should not propagate through a broad range of dependent services, while an admin could quite reasonably want to update these without taking a server outage.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 17:33:02 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 7 Oct 2013 17:33:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2138) Cannot add security realm
 child resources in a domain
In-Reply-To: <JIRA.12501333.1379967150000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501333.1379967150000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501333.1379967150000.21438.1381181582737@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry resolved WFLY-2138.
------------------------------------

    Fix Version/s: 8.0.0.Beta1
                       (was: 8.0.0.CR1)
       Resolution: Done


Fixed in https://github.com/wildfly/wildfly/commit/5a663d4513ff3fd1d187cf47cbbaf1dc4ba1a47e
                
> Cannot add security realm child resources in a domain
> -----------------------------------------------------
>
>                 Key: WFLY-2138
>                 URL: https://issues.jboss.org/browse/WFLY-2138
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>
> /] /host=master/core-service=management/security-realm=JBossTest:add
> {
>     "outcome" => "success",
>     "result" => undefined,
>     "server-groups" => undefined
> }
> [domain at localhost:9990 /] /host=master/core-service=management/security-realm=JBossTest/authentication=properties:add(path=application-users.properties, relative-to=jboss.server.config.dir)
> {
>     "outcome" => "failed",
>     "result" => undefined,
>     "failure-description" => "JBAS010839: Operation failed or was rolled back on all servers.",
>     "rolled-back" => true,
>     "server-groups" => {"main-server-group" => {"host" => {"master" => {
>         "server-one" => {"response" => {
>             "outcome" => "failed",
>             "failure-description" => "JBAS014883: No resource definition is registered for address [
>     (\"host\" => \"master\"),
>     (\"core-service\" => \"management\"),
>     (\"security-realm\" => \"JBossTest\"),
>     (\"authentication\" => \"properties\")
> ]",
>             "rolled-back" => true
>         }},
>         "server-two" => {"response" => {
>             "outcome" => "failed",
>             "failure-description" => "JBAS014883: No resource definition is registered for address [
>     (\"host\" => \"master\"),
>     (\"core-service\" => \"management\"),
>     (\"security-realm\" => \"JBossTest\"),
>     (\"authentication\" => \"properties\")
> ]",
>             "rolled-back" => true
>         }}
>     }}}}
> }
> Note the addresses in the server level failure messages. It appears the /host=master level is not being stripped from the request to the server.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 17:35:02 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 7 Oct 2013 17:35:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2003) Failed handling operation
	rollback -- null
In-Reply-To: <JIRA.12500017.1378366299000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500017.1378366299000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500017.1378366299000.21444.1381181702757@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry resolved WFLY-2003.
------------------------------------

    Fix Version/s: 8.0.0.Beta1
                       (was: 8.0.0.CR1)
       Resolution: Done


I haven't seen these and the QE testing of EAP isn't finding them either, so I'm going to assume a change in Beta1 took care of this. Please reopen if you find it's still happening.
                
> Failed handling operation rollback -- null
> ------------------------------------------
>
>                 Key: WFLY-2003
>                 URL: https://issues.jboss.org/browse/WFLY-2003
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Beta1
>
>
> Not sure what's causing these, but when operating the web console in domain mode I see planty of these on the console: 
> {noformat}
> [Host Controller] 09:29:23,565 ERROR [org.jboss.as.controller.client] (XNIO-1 task-1) JBAS014781: Step handler org.jboss.as.domain.controller.operations.coordination.DomainFinalResultHandler at 59f61bf9 for operation composite at address [] failed handling operation rollback -- null
> {noformat}
> The strange thing is that the management operations return successfully.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 17:37:02 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 7 Oct 2013 17:37:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1867) Provide access control
	documentation
In-Reply-To: <JIRA.12498454.1376383935000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498454.1376383935000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498454.1376383935000.21447.1381181822588@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-1867:
-----------------------------------

        Parent: WFLY-490
    Issue Type: Sub-task  (was: Enhancement)

    
> Provide access control documentation
> ------------------------------------
>
>                 Key: WFLY-1867
>                 URL: https://issues.jboss.org/browse/WFLY-1867
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Documentation, Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> The access control features need to be properly documented

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 17:39:02 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 7 Oct 2013 17:39:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1741) RBAC: Response headers don't
 match payload structure
In-Reply-To: <JIRA.12497111.1374568060000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497111.1374568060000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497111.1374568060000.21461.1381181942809@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12811192#comment-12811192 ] 

Brian Stansberry commented on WFLY-1741:
----------------------------------------

I don't understand. It's looks fine to me. What do you think it should look like?
                
> RBAC: Response headers don't match payload structure
> ----------------------------------------------------
>
>                 Key: WFLY-1741
>                 URL: https://issues.jboss.org/browse/WFLY-1741
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>
> the 'relative-address' header doesn't match the response structure:
> (hint: the 'data-source' element is missing)
> {noformat}
> [standalone at localhost:9990 /] /subsystem=datasources:read-children-resources(child-type=data-source){roles=monitor}
> {
>     "outcome" => "success",
>     "result" => {
>         "ExampleDS" => {
>             "allocation-retry" => undefined,
>             "allocation-retry-wait-millis" => undefined,
>             [...]        }
>     },
>     "response-headers" => {"access-control" => [               {
>             "absolute-address" => [
>                 ("subsystem" => "datasources"),
>                 ("data-source" => "ExampleDS")
>             ],
>             "relative-address" => [("data-source" => "ExampleDS")],
>             "filtered-attributes" => [
>                 "user-name",
>                 "security-domain",
>                 "password"
>             ]
>         }
>     ]}
> }
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 17:41:02 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 7 Oct 2013 17:41:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1736) CommandLineArgumentUsage
 class substring value discarded
In-Reply-To: <JIRA.12497088.1374523551000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497088.1374523551000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497088.1374523551000.21469.1381182062923@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-1736:
-----------------------------------

    Fix Version/s: 8.0.0.CR1

    
> CommandLineArgumentUsage class substring value discarded
> --------------------------------------------------------
>
>                 Key: WFLY-1736
>                 URL: https://issues.jboss.org/browse/WFLY-1736
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Cheng Fang
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> CommandLineArgumentUsage class has a substring call but return value discarded:
> {code}
> if( input.get(0).length() > width ){
>                     String tooLong = input.remove(0);
>                     tooLong.substring(0, width-5);
>                     input.add("Command removed. Too long.");
>                 }
> {code}
> FindBugs also finds a static field should be final:
> {code}
> protected static List<String> instructions = new ArrayList<String>();
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 17:41:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 7 Oct 2013 17:41:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1729) Provide an access control
 user guide chapter
In-Reply-To: <JIRA.12496983.1374482003000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496983.1374482003000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496983.1374482003000.21479.1381182063577@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry resolved WFLY-1729.
------------------------------------

    Resolution: Duplicate Issue

    
> Provide an access control user guide chapter
> --------------------------------------------
>
>                 Key: WFLY-1729
>                 URL: https://issues.jboss.org/browse/WFLY-1729
>             Project: WildFly
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 17:43:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 7 Oct 2013 17:43:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1623) Access Control:
	read-children-resources
In-Reply-To: <JIRA.12495505.1372757345000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495505.1372757345000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495505.1372757345000.21491.1381182183316@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry resolved WFLY-1623.
------------------------------------

    Fix Version/s: 8.0.0.Beta1
       Resolution: Done


Please start a thread on the dev list if more information is needed.
                
> Access Control: read-children-resources
> ---------------------------------------
>
>                 Key: WFLY-1623
>                 URL: https://issues.jboss.org/browse/WFLY-1623
>             Project: WildFly
>          Issue Type: Clarification
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Beta1
>
>
> What priviledges apply to a read-children-resources operation? The ones of the parent resource or the ones for each child resource?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 19:38:02 2013
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Mon, 7 Oct 2013 19:38:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-84) LoggingMXBean is not being
 set during log manager initialization
In-Reply-To: <JIRA.12502403.1381188970094@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502403.1381188970094@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502403.1381188970094.21856.1381189082618@jira02.app.mwc.hst.phx2.redhat.com>

James Perkins created LOGMGR-84:
-----------------------------------

             Summary: LoggingMXBean is not being set during log manager initialization
                 Key: LOGMGR-84
                 URL: https://issues.jboss.org/browse/LOGMGR-84
             Project: JBoss Log Manager
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: James Perkins
            Assignee: James Perkins


Debugging seems to show the static {{LoggingMXBean}} being set in the {{org.jboss.logmanager.LogManager}} constructor, but some time later the static instance is reinitialized to {{null}} in the {{java.util.logging.LogManager}}.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 19:44:02 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Mon, 7 Oct 2013 19:44:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-289) PackageBuilder throws NPE
 when a declared class extends another, undeclared one
In-Reply-To: <JIRA.12502404.1381189422302@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502404.1381189422302@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502404.1381189422302.21870.1381189442514@jira02.app.mwc.hst.phx2.redhat.com>

Davide Sottara created DROOLS-289:
-------------------------------------

             Summary: PackageBuilder throws NPE when a declared class extends another, undeclared one
                 Key: DROOLS-289
                 URL: https://issues.jboss.org/browse/DROOLS-289
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Davide Sottara
            Assignee: Mark Proctor


Parent class(es) used with declare must be declared themselves.
However, instead of returning a compilation error, the package builder
throws a runtime NPE

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 20:15:03 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Mon, 7 Oct 2013 20:15:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2249) NPE during redeployment of a
	war
In-Reply-To: <JIRA.12502347.1381151954000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502347.1381151954000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502347.1381151954000.21885.1381191303142@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12811356#comment-12811356 ] 

Scott Marlow commented on WFLY-2249:
------------------------------------

Perhaps we should have a null pointer check in that code.  Are you setup to debug WildFly 8 and catch the NPE at PersistenceUnitParseProcessor.java:126?  Would be good to know the npe cause and more details.

                
> NPE during redeployment of a war
> --------------------------------
>
>                 Key: WFLY-2249
>                 URL: https://issues.jboss.org/browse/WFLY-2249
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Juergen Zimmermann
>            Assignee: Scott Marlow
>
> When I redeploy an already running war, then I get the following NPE. The (re-) deployment is done via the Maven plugin org.jboss.as.plugins:jboss-as-maven-plugin:7.4.Final. It looks like the redployment was successful anyway. Hmm...
> {code}
> ERROR [org.jboss.msc.service.fail] MSC000001: Failed to start service jboss.deployment.unit."shop.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."shop.war".PARSE: JBAS018733: Failed to process phase PARSE of deployment "shop.war"
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> Caused by: java.lang.NullPointerException
> 	at org.jboss.as.jpa.processor.PersistenceUnitParseProcessor.handleWarDeployment(PersistenceUnitParseProcessor.java:126)
> 	at org.jboss.as.jpa.processor.PersistenceUnitParseProcessor.deploy(PersistenceUnitParseProcessor.java:83)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	... 5 more
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 20:24:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Oct 2013 20:24:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1569) Not possible to reload server
 when JTS transactions are activated
In-Reply-To: <JIRA.12494844.1371818256000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494844.1371818256000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494844.1371818256000.21900.1381191842736@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12811360#comment-12811360 ] 

RH Bugzilla Integration commented on WFLY-1569:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1011379|https://bugzilla.redhat.com/show_bug.cgi?id=1011379] from POST to MODIFIED
                
> Not possible to reload server when JTS transactions are activated
> -----------------------------------------------------------------
>
>                 Key: WFLY-1569
>                 URL: https://issues.jboss.org/browse/WFLY-1569
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Ond?ej Chaloupka
>            Assignee: Stefano Maestri
>
> When transactions are set for JTS being used
>  - <jts/> tag under transactions subsystem
>  - transactions="on" under jacorb subsystem
> then it is not possible to reload the server.
> The reload causes the following exception being shown.
> {code}
> 14:30:56,388 WARN  [com.arjuna.ats.jts] (MSC service thread 1-5) ARJUNA022083: JacOrbRCServiceInit - Failed to start RC service: org.omg.CORBA.OBJECT_NOT_EXIST: POA destroyed
>  at org.jacorb.poa.POA.checkDestructionApparent(POA.java:1409)                           
>  at org.jacorb.poa.POA.set_servant(POA.java:1979)                          
>  at com.arjuna.ats.internal.jts.orbspecific.jacorb.recoverycoordinators.JacOrbRCServiceInit.startRCservice(JacOrbRCServiceInit.java:197) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]        
>  at com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement.startRCservice(RecoveryEnablement.java:137) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]        
>  at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:66) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]         
>  at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:104) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]              
>  at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:224) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]               
>  at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65) [narayana-jts-integration-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]            
>  at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:139) [wildfly-transactions-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]              
>  at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1942) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]                
>  at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1875) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]                  
>  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]                       
>  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]                       
>  at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]                       
> 14:30:56,396 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.txn.ArjunaRecoveryManager: org.jboss.msc.service.StartException in service jboss.txn.ArjunaRecoveryManager: JBAS010101: Recovery manager create failed                                 
>  at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:142)                      
>  at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1942) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]                
>  at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1875) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]                  
>  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]                       
>  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]                       
>  at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]                       
> Caused by: java.lang.RuntimeException: ARJUNA012364: RecoveryActivator init failed for com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement            
>  at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:67)                 
>  at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:104)                      
>  at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:224)                       
>  at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65)                  
>  at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:139)                      
>  ... 5 more 
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Mon Oct  7 20:32:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Oct 2013 20:32:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2057)
 org.jboss.as.server.deployment.RegisteredDeploymentUnitProcessor has
 unstable compareTo()
In-Reply-To: <JIRA.12500645.1379015464000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500645.1379015464000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500645.1379015464000.21919.1381192323027@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12811364#comment-12811364 ] 

RH Bugzilla Integration commented on WFLY-2057:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1013470|https://bugzilla.redhat.com/show_bug.cgi?id=1013470] from POST to MODIFIED
                
> org.jboss.as.server.deployment.RegisteredDeploymentUnitProcessor has unstable compareTo()
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-2057
>                 URL: https://issues.jboss.org/browse/WFLY-2057
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>            Reporter: David Lloyd
>            Assignee: Stuart Douglas
>            Priority: Blocker
>             Fix For: 8.0.0.Beta1
>
>
> As the description says, org.jboss.as.server.deployment.RegisteredDeploymentUnitProcessor's compareTo is wrong.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 20:32:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Oct 2013 20:32:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2131) read-operation-names to
 return a filtered list of allowed operations
In-Reply-To: <JIRA.12501207.1379945777000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501207.1379945777000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501207.1379945777000.21923.1381192323179@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12811365#comment-12811365 ] 

RH Bugzilla Integration commented on WFLY-2131:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1013056|https://bugzilla.redhat.com/show_bug.cgi?id=1013056] from NEW to MODIFIED
                
> read-operation-names to return a filtered list of allowed operations
> --------------------------------------------------------------------
>
>                 Key: WFLY-2131
>                 URL: https://issues.jboss.org/browse/WFLY-2131
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Alexey Loubyansky
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Beta1
>
>
> As discussed on IRC with Kabir, Heiko and me, we agreed that read-operation-names should return only the operations the caller is permitted to execute.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 20:32:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Oct 2013 20:32:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1756) Add access-control parameter
 to read-operation-description operation
In-Reply-To: <JIRA.12497280.1374684426000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497280.1374684426000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497280.1374684426000.21929.1381192323391@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12811366#comment-12811366 ] 

RH Bugzilla Integration commented on WFLY-1756:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1013056|https://bugzilla.redhat.com/show_bug.cgi?id=1013056] from NEW to MODIFIED
                
> Add access-control parameter to read-operation-description operation
> --------------------------------------------------------------------
>
>                 Key: WFLY-1756
>                 URL: https://issues.jboss.org/browse/WFLY-1756
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Beta1
>
>
> Similar to read-resource-description

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 20:34:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Oct 2013 20:34:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1913) CLI 'module add' command fail
 if a drive letter is specified in its resource path
In-Reply-To: <JIRA.12499050.1377075768000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499050.1377075768000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499050.1377075768000.21935.1381192442661@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12811369#comment-12811369 ] 

RH Bugzilla Integration commented on WFLY-1913:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1014921|https://bugzilla.redhat.com/show_bug.cgi?id=1014921] from POST to MODIFIED
                
> CLI 'module add' command fail if a drive letter is specified in its resource path
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-1913
>                 URL: https://issues.jboss.org/browse/WFLY-1913
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>             Fix For: 8.0.0.CR1
>
>         Attachments: install-mojarra-2.0.0.cli
>
>
> If a drive letter is specified in the resource path the module add command fails on MS Windows. It cannot locate such a resource because of doubled drive letter in the translated path.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 20:54:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Oct 2013 20:54:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-272) KieSession.fireUntilHalt()
 consumes 100% CPU
In-Reply-To: <JIRA.12501361.1380017684000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501361.1380017684000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501361.1380017684000.21963.1381193642772@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12811372#comment-12811372 ] 

RH Bugzilla Integration commented on DROOLS-272:
------------------------------------------------

Edson Tirelli <etirelli at redhat.com> changed the Status of [bug 1012140|https://bugzilla.redhat.com/show_bug.cgi?id=1012140] from ASSIGNED to MODIFIED
                
> KieSession.fireUntilHalt() consumes 100% CPU
> --------------------------------------------
>
>                 Key: DROOLS-272
>                 URL: https://issues.jboss.org/browse/DROOLS-272
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR3
>         Environment: Mac OS-X 1.8.5 + Hotspot JDK 1.7.0_40, RHEL 6.4 + OpenJDK 1.7.0_25, Fedora 18 + Java 6.
>            Reporter: Duncan Doyle
>            Assignee: Mark Proctor
>            Priority: Blocker
>
> When I run a KieSession.fireUntilHalt(), my application starts consuming 100% CPU, without anything actually happening inside the app (no events/facts are being inserted, no rules are activated/fired, etc.). We've tested this on multiple machines, different OSs, different JDKs, etc., and they all show the same behaviour.
> I've created a small test that shows the problem. The test loads a simple DRL via KieClasspathContainer, retrieves a new KieSession and runs a KieSession.fireUntilHalt() in a separate thread. After launching the thread, I let the main thread sleep for 30 seconds (3 * 10) and during this time period, CPU load increases to 100%. I then halt the session and sleep for another 10 seconds, which causes the CPU load to back to normal. The test project can be found here: https://github.com/DuncanDoyle/DroolsFireUntilHalt/
> Just run 'mvn clean test' on the project.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 20:54:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Oct 2013 20:54:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-272) KieSession.fireUntilHalt()
 consumes 100% CPU
In-Reply-To: <JIRA.12501361.1380017684000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501361.1380017684000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501361.1380017684000.21966.1381193642901@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12811373#comment-12811373 ] 

RH Bugzilla Integration commented on DROOLS-272:
------------------------------------------------

Edson Tirelli <etirelli at redhat.com> made a comment on [bug 1012140|https://bugzilla.redhat.com/show_bug.cgi?id=1012140]

Fixed.

6.0.x: http://github.com/droolsjbpm/drools/commit/a0ec3c66d
master: http://github.com/droolsjbpm/drools/commit/fc269f7cf
                
> KieSession.fireUntilHalt() consumes 100% CPU
> --------------------------------------------
>
>                 Key: DROOLS-272
>                 URL: https://issues.jboss.org/browse/DROOLS-272
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR3
>         Environment: Mac OS-X 1.8.5 + Hotspot JDK 1.7.0_40, RHEL 6.4 + OpenJDK 1.7.0_25, Fedora 18 + Java 6.
>            Reporter: Duncan Doyle
>            Assignee: Mark Proctor
>            Priority: Blocker
>
> When I run a KieSession.fireUntilHalt(), my application starts consuming 100% CPU, without anything actually happening inside the app (no events/facts are being inserted, no rules are activated/fired, etc.). We've tested this on multiple machines, different OSs, different JDKs, etc., and they all show the same behaviour.
> I've created a small test that shows the problem. The test loads a simple DRL via KieClasspathContainer, retrieves a new KieSession and runs a KieSession.fireUntilHalt() in a separate thread. After launching the thread, I let the main thread sleep for 30 seconds (3 * 10) and during this time period, CPU load increases to 100%. I then halt the session and sleep for another 10 seconds, which causes the CPU load to back to normal. The test project can be found here: https://github.com/DuncanDoyle/DroolsFireUntilHalt/
> Just run 'mvn clean test' on the project.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 20:56:02 2013
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Mon, 7 Oct 2013 20:56:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-272) KieSession.fireUntilHalt()
 consumes 100% CPU
In-Reply-To: <JIRA.12501361.1380017684000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501361.1380017684000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501361.1380017684000.21975.1381193762738@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli resolved DROOLS-272.
----------------------------------

         Assignee: Edson Tirelli  (was: Mark Proctor)
    Fix Version/s: 6.0.0.CR5
       Resolution: Done

    
> KieSession.fireUntilHalt() consumes 100% CPU
> --------------------------------------------
>
>                 Key: DROOLS-272
>                 URL: https://issues.jboss.org/browse/DROOLS-272
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR3
>         Environment: Mac OS-X 1.8.5 + Hotspot JDK 1.7.0_40, RHEL 6.4 + OpenJDK 1.7.0_25, Fedora 18 + Java 6.
>            Reporter: Duncan Doyle
>            Assignee: Edson Tirelli
>            Priority: Blocker
>             Fix For: 6.0.0.CR5
>
>
> When I run a KieSession.fireUntilHalt(), my application starts consuming 100% CPU, without anything actually happening inside the app (no events/facts are being inserted, no rules are activated/fired, etc.). We've tested this on multiple machines, different OSs, different JDKs, etc., and they all show the same behaviour.
> I've created a small test that shows the problem. The test loads a simple DRL via KieClasspathContainer, retrieves a new KieSession and runs a KieSession.fireUntilHalt() in a separate thread. After launching the thread, I let the main thread sleep for 30 seconds (3 * 10) and during this time period, CPU load increases to 100%. I then halt the session and sleep for another 10 seconds, which causes the CPU load to back to normal. The test project can be found here: https://github.com/DuncanDoyle/DroolsFireUntilHalt/
> Just run 'mvn clean test' on the project.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 20:56:02 2013
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Mon, 7 Oct 2013 20:56:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-272) KieSession.fireUntilHalt()
 consumes 100% CPU
In-Reply-To: <JIRA.12501361.1380017684000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501361.1380017684000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501361.1380017684000.21977.1381193762806@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli closed DROOLS-272.
--------------------------------


    
> KieSession.fireUntilHalt() consumes 100% CPU
> --------------------------------------------
>
>                 Key: DROOLS-272
>                 URL: https://issues.jboss.org/browse/DROOLS-272
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR3
>         Environment: Mac OS-X 1.8.5 + Hotspot JDK 1.7.0_40, RHEL 6.4 + OpenJDK 1.7.0_25, Fedora 18 + Java 6.
>            Reporter: Duncan Doyle
>            Assignee: Edson Tirelli
>            Priority: Blocker
>             Fix For: 6.0.0.CR5
>
>
> When I run a KieSession.fireUntilHalt(), my application starts consuming 100% CPU, without anything actually happening inside the app (no events/facts are being inserted, no rules are activated/fired, etc.). We've tested this on multiple machines, different OSs, different JDKs, etc., and they all show the same behaviour.
> I've created a small test that shows the problem. The test loads a simple DRL via KieClasspathContainer, retrieves a new KieSession and runs a KieSession.fireUntilHalt() in a separate thread. After launching the thread, I let the main thread sleep for 30 seconds (3 * 10) and during this time period, CPU load increases to 100%. I then halt the session and sleep for another 10 seconds, which causes the CPU load to back to normal. The test project can be found here: https://github.com/DuncanDoyle/DroolsFireUntilHalt/
> Just run 'mvn clean test' on the project.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 22:41:03 2013
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Mon, 7 Oct 2013 22:41:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1948)
 java.lang.IllegalStateException: Destination queue.ISXO_AuditLogQueue_01
 not active after MessagingClusterHealthMBean restart JMS service
In-Reply-To: <JIRA.12502101.1380799169000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502101.1380799169000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502101.1380799169000.22006.1381200063042@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBMESSAGING-1948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12811382#comment-12811382 ] 

Yong Hao Gao commented on JBMESSAGING-1948:
-------------------------------------------

Hi Flemming,

When JMS service is shutdown by the MessagingClusterHealthMBean, all queues and connection factories will be stopped, and they will be restarted when JBM service is restarted. This means all old Connection Factories JNDI references held in clients will be invalid after service restart. You need to do JNDI lookup again for them.

Are you having this issue when you are using 'in-vm' connections? (which means your clients and the JBM service are in one VM, like a MDB deployed in the node)

Thanks
Howard

                
> java.lang.IllegalStateException: Destination queue.ISXO_AuditLogQueue_01 not active after MessagingClusterHealthMBean restart JMS service
> -----------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1948
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1948
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.8.SP9
>            Reporter: Flemming Harms
>            Assignee: Yong Hao Gao
>         Attachments: ConnectionFactory-diff.patch, postoffice-patch.diff
>
>
> I get this error ?java.lang.IllegalStateException: Destination queue.ISXO_AuditLogQueue_01 not active? after MessagingClusterHealthMBean restarts the JMS service with JBoss Messaging 1.4.8.SP9. 
> I have 2 node JBoss5 cluster with JBoss Messaging and I have enabled the new failover model and setup the MessagingClusterHealthMBean to monitor split brain.
> I disconnect the cable from one of the servers MessagingClusterHealthMBean discover it?s alone and shut down the JMS service as expected. After a while I connect the server again and the server discover the other server and MessagingClusterHealthMBean starts the JMS service also as expected.
> But when I connect a client it fails with ?java.lang.IllegalStateException: Destination queue.ISXO_AuditLogQueue_01 not active? and what I can see in the debugger ServerConnectionEndpoint have reference to the old post office where the queue is still exits in the inactiveConditions Set.
> Log from the server when it discover it?s alone and it restart the service again
> 2013-09-07 21:29:06,381 ERROR [org.jboss.messaging.core.impl.postoffice.MessagingPostOffice] (Thread-32) I'm orphaned and now I can't tell others that I'm alive. Shutdown node: 102
> 2013-09-07 21:29:09,728 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-32) Stopping JBM node on DB failure...
> 2013-09-07 21:29:09,731 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-32) Queue[/queue/ExpiryQueue] stopped
> 2013-09-07 21:29:09,732 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-32) Queue[/queue/DLQ] stopped
> 2013-09-07 21:29:09,733 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-32) Queue[/ISXO/AuditLogQueue, name=ISXO_AuditLogQueue_01] stopped
> 2013-09-07 21:29:09,733 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-32) Queue[/ISXO/CiscoUCSEventQueue, name=ISXO_CiscoUCSEventQueue_01] stopped
> 2013-09-07 21:29:09,738 INFO  [org.jboss.jms.server.destination.TopicService] (Thread-32) Topic[/ISXO/RemoteEventTopic, name=ISXO_RemoteEventQueue_01] stopped
> 2013-09-07 21:29:09,739 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-32) Queue[/ISXO/ScheduledJobQueue, name=ISXO_ScheduledJobQueue_01] stopped
> 2013-09-07 21:29:11,210 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-32) org.jboss.jms.server.connectionfactory.ConnectionFactory at 366480d7 undeployed
> 2013-09-07 21:29:11,216 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-32) org.jboss.jms.server.connectionfactory.ConnectionFactory at 467463b3 undeployed
> 2013-09-07 21:29:11,216 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-32) org.jboss.jms.server.connectionfactory.ConnectionFactory at 21fdb35f undeployed
> 2013-09-07 21:29:11,216 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-32) org.jboss.jms.server.connectionfactory.ConnectionFactory at 443578f2 undeployed
> 2013-09-07 21:29:11,235 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-32) org.jboss.jms.server.connectionfactory.ConnectionFactory at ecdede5 undeployed
> 2013-09-07 21:29:11,298 ERROR [org.jgroups.blocks.ConnectionTable] (OOB-43,192.168.56.102:7900) failed sending data to 192.168.56.101:7900: java.net.SocketException: Socket closed
> 2013-09-07 21:29:14,413 WARN  [org.jgroups.protocols.pbcast.NAKACK] (OOB-19,192.168.56.102:55200) 192.168.56.102:55200] discarded message from non-member 192.168.56.101:55200, my view is [192.168.56.102
> 2013-09-07 21:29:14,863 WARN  [org.jgroups.protocols.pbcast.NAKACK] (OOB-19,192.168.56.102:55200) 192.168.56.102:55200] discarded message from non-member 192.168.56.101:55200, my view is [192.168.56.102
> 2013-09-07 21:29:21,080 INFO  [org.jboss.jms.server.ServerPeer] (Thread-32) JMS ServerPeer[102] stopped
> 2013-09-07 21:29:21,090 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-32) JBM node is stopped.
> 2013-09-07 21:29:21,090 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] (Incoming-2,192.168.56.102:55200) Dead members: 1 ([192.168.56.101:55200])
> 2013-09-07 21:29:21,090 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] (Incoming-2,192.168.56.102:55200) All Members : 1 ([192.168.56.102:55200])
> 2013-09-07 21:30:24,666 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Restarting JBM node...
> 2013-09-07 21:30:33,369 INFO  [org.jboss.jms.server.ServerPeer] (Thread-75) JBoss Messaging 1.4.8.SP9 server [102] started
> 2013-09-07 21:30:33,459 INFO  [STDOUT] (Thread-75) 
> ---------------------------------------------------------
> GMS: address is 192.168.56.102:55200 (cluster=DefaultPartition-JMS-CTRL)
> ---------------------------------------------------------
> 2013-09-07 21:30:33,524 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] (Thread-75) org.jboss.messaging.core.impl.postoffice.GroupMember$ControlMembershipListener at 6a500238 got new view [192
> 2013-09-07 21:30:33,525 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] (Thread-75) I am (192.168.56.102:55200)
> 2013-09-07 21:30:33,525 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] (Thread-75) New Members : 2 ([192.168.56.101:55200, 192.168.56.102:55200])
> 2013-09-07 21:30:33,525 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] (Thread-75) All Members : 2 ([192.168.56.101:55200, 192.168.56.102:55200])
> 2013-09-07 21:30:33,570 INFO  [STDOUT] (pool-151-thread-1) 
> ---------------------------------------------------------
> GMS: address is 192.168.56.102:7900 (cluster=DefaultPartition-JMS-DATA)
> ---------------------------------------------------------
> 2013-09-07 21:30:33,779 INFO  [org.jboss.messaging.core.impl.postoffice.MessagingPostOffice] (Thread-75) Waiting for JGroups...
> 2013-09-07 21:30:33,784 INFO  [org.jboss.messaging.core.impl.postoffice.MessagingPostOffice] (Thread-75) JGroups starts to work again, initializing state
> 2013-09-07 21:30:33,785 INFO  [org.jboss.messaging.core.impl.postoffice.MessagingPostOffice] (Thread-75) Now node is ready for work.
> 2013-09-07 21:30:34,896 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) Connector sslbisocket://192.168.56.102:4459 has leasing enabled, lease period 25000 milliseconds
> 2013-09-07 21:30:34,896 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered connection factory jboss.messaging.connectionfactory:service=SSLConnectionFactory
> 2013-09-07 21:30:34,896 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) org.jboss.jms.server.connectionfactory.ConnectionFactory at 366480d7 started
> 2013-09-07 21:30:36,797 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) Connector bisocket://192.168.56.102:4457 has leasing enabled, lease period 25000 milliseconds
> 2013-09-07 21:30:36,797 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered connection factory jboss.messaging.connectionfactory:service=ConnectionFactory
> 2013-09-07 21:30:36,797 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) org.jboss.jms.server.connectionfactory.ConnectionFactory at 467463b3 started
> 2013-09-07 21:30:37,207 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) Connector servlet://192.168.56.102:8080 has leasing enabled, lease period 25000 milliseconds
> 2013-09-07 21:30:37,207 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered connection factory jboss.messaging.connectionfactory:service=ServletConnectionFactory
> 2013-09-07 21:30:37,207 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) org.jboss.jms.server.connectionfactory.ConnectionFactory at 21fdb35f started
> 2013-09-07 21:30:37,440 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) Connector bisocket://192.168.56.102:4457 has leasing enabled, lease period 25000 milliseconds
> 2013-09-07 21:30:37,441 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered connection factory jboss.messaging.connectionfactory:service=ClusteredConnectionFactory
> 2013-09-07 21:30:37,441 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) org.jboss.jms.server.connectionfactory.ConnectionFactory at 443578f2 started
> 2013-09-07 21:30:41,483 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) Connector bisocket://192.168.56.102:4457 has leasing enabled, lease period 25000 milliseconds
> 2013-09-07 21:30:41,483 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered connection factory jboss.messaging.connectionfactory:service=ClusterPullConnectionFactory
> 2013-09-07 21:30:41,483 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) org.jboss.jms.server.connectionfactory.ConnectionFactory at ecdede5 started
> 2013-09-07 21:30:41,483 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered destination jboss.messaging.destination:service=Queue,name=ExpiryQueue
> 2013-09-07 21:30:41,715 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-75) Queue[/queue/ExpiryQueue] started, fullSize=200000, pageSize=2000, downCacheSize=2000
> 2013-09-07 21:30:41,715 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered destination jboss.messaging.destination:service=Queue,name=DLQ
> 2013-09-07 21:30:42,259 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-75) Queue[/queue/DLQ] started, fullSize=200000, pageSize=2000, downCacheSize=2000
> 2013-09-07 21:30:42,259 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered destination jboss.messaging.destination:service=Queue,name=ISXO_AuditLogQueue_01
> 2013-09-07 21:30:42,495 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-75) Queue[/ISXO/AuditLogQueue, name=ISXO_AuditLogQueue_01] started, fullSize=200000, pageSize=2000, downCacheSize=20
> 2013-09-07 21:30:42,495 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered destination jboss.messaging.destination:service=Queue,name=ISXO_CiscoUCSEventQueue_01
> 2013-09-07 21:30:42,923 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-75) Queue[/ISXO/CiscoUCSEventQueue, name=ISXO_CiscoUCSEventQueue_01] started, fullSize=200000, pageSize=2000, downCa
> 2013-09-07 21:30:42,923 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered destination jboss.messaging.destination:service=Topic,name=ISXO_RemoteEventQueue_01
> 2013-09-07 21:30:43,122 INFO  [org.jboss.jms.server.destination.TopicService] (Thread-75) Topic[/ISXO/RemoteEventTopic, name=ISXO_RemoteEventQueue_01] started, fullSize=200000, pageSize=2000, downCacheS
> 2013-09-07 21:30:43,122 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered destination jboss.messaging.destination:service=Queue,name=ISXO_ScheduledJobQueue_01
> 2013-09-07 21:30:43,559 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-75) Queue[/ISXO/ScheduledJobQueue, name=ISXO_ScheduledJobQueue_01] started, fullSize=200000, pageSize=2000, downCach
> 2013-09-07 21:30:43,559 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) JBM node restarted.
> Stack trace the ?java.lang.IllegalStateException: Destination queue.ISXO_AuditLogQueue_01 not active?
> Daemon Thread [ISXOSchedulerPrioritized_Worker-1] (Suspended (breakpoint at line 3046 in MessagingPostOffice))	
> 	owns: AtomicAction  (id=519)	
> 	MessagingPostOffice.routeInternal(MessageReference, Condition, Transaction, boolean, Set) line: 3046	
> 	MessagingPostOffice.route(MessageReference, Condition, Transaction) line: 983	
> 	ServerConnectionEndpoint.sendMessage(JBossMessage, Transaction, boolean) line: 796	
> 	ServerConnectionEndpoint.processTransaction(ClientTransaction, Transaction, boolean) line: 852	
> 	ServerConnectionEndpoint.sendTransaction(TransactionRequest, boolean) line: 516	
> 	ConnectionAdvised.org$jboss$jms$server$endpoint$advised$ConnectionAdvised$sendTransaction$aop(TransactionRequest, boolean) line: 106	
> 	ConnectionAdvised$sendTransaction_N3268650789275322226.invokeTarget() line: not available	
> 	ConnectionAdvised$sendTransaction_N3268650789275322226(MethodInvocation).invokeNext() line: 111	
> 	SecurityAspect.handleSendTransaction(Invocation) line: 200	
> 	NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]	
> 	NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39	
> 	DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25	
> 	Method.invoke(Object, Object...) line: 597	
> 	PerInstanceAdvice.invoke(Invocation) line: 122	
> 	ConnectionAdvised$sendTransaction_N3268650789275322226(MethodInvocation).invokeNext() line: 102	
> 	ServerLogInterceptor.invoke(Invocation) line: 105	
> 	ConnectionAdvised$sendTransaction_N3268650789275322226(MethodInvocation).invokeNext() line: 102	
> 	ConnectionAdvised.sendTransaction(TransactionRequest, boolean) line: not available	
> 	ConnectionSendTransactionRequest.serverInvoke() line: 86	
> 	JMSServerInvocationHandler.invoke(InvocationRequest) line: 165	
> 	BisocketServerInvoker(ServerInvoker).invoke(InvocationRequest) line: 930	
> 	LocalClientInvoker.invoke(InvocationRequest) line: 106	
> 	Client.invoke(Object, Map, InvokerLocator) line: 2034	
> 	Client.invoke(Object, Map) line: 877	
> 	Client.invoke(Object) line: 865	
> 	ClientConnectionDelegate(DelegateSupport).doInvoke(Client, RequestSupport, boolean) line: 189	
> 	ClientConnectionDelegate(DelegateSupport).doInvoke(Client, RequestSupport) line: 160	
> 	ClientConnectionDelegate.org$jboss$jms$client$delegate$ClientConnectionDelegate$sendTransaction$aop(TransactionRequest, boolean) line: 241	
> 	ClientConnectionDelegate$sendTransaction_N3268650789275322226.invokeTarget() line: not available	
> 	ClientConnectionDelegate$sendTransaction_N3268650789275322226(MethodInvocation).invokeNext() line: 111	
> 	FailoverValveInterceptor.invoke(Invocation) line: 92	
> 	PerInstanceInterceptor.invoke(Invocation) line: 86	
> 	ClientConnectionDelegate$sendTransaction_N3268650789275322226(MethodInvocation).invokeNext() line: 102	
> 	ClosedInterceptor.invoke(Invocation) line: 172	
> 	PerInstanceInterceptor.invoke(Invocation) line: 86	
> 	ClientConnectionDelegate$sendTransaction_N3268650789275322226(MethodInvocation).invokeNext() line: 102	
> 	ClientConnectionDelegate.sendTransaction(TransactionRequest, boolean) line: not available	
> 	ResourceManager.sendTransactionXA(TransactionRequest, ConnectionDelegate) line: 712	
> 	ResourceManager.commit(Xid, boolean, ConnectionDelegate) line: 392	
> 	MessagingXAResource.commit(Xid, boolean) line: 275	
> 	JmsXAResource.commit(Xid, boolean) line: 98	
> 	XAResourceRecord.topLevelOnePhaseCommit() line: 811	
> 	AtomicAction(BasicAction).onePhaseCommit(boolean) line: 2656	
> 	AtomicAction(BasicAction).End(boolean) line: 1784	
> 	AtomicAction(TwoPhaseCoordinator).end(boolean) line: 94	
> 	AtomicAction(AtomicAction).commit(boolean) line: 160	
> 	TransactionImple.commitAndDisassociate() line: 1431	
> 	TransactionManagerImple(BaseTransaction).commit() line: 137	
> 	TransactionManagerDelegate(BaseTransactionManagerDelegate).commit() line: 75	
> 	Ejb3TxPolicy(TxPolicy).endTransaction(TransactionManager, Transaction) line: 170	
> 	Ejb3TxPolicy(TxPolicy).invokeInOurTx(Invocation, TransactionManager) line: 87	
> 	TxInterceptor$Required.invoke(Invocation) line: 190	
> 	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
> 	TxPropagationInterceptor.invoke(Invocation) line: 76	
> 	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
> 	NullInterceptor.invoke(Invocation) line: 42	
> 	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
> 	Ejb3AuthenticationInterceptorv2.invoke(Invocation) line: 182	
> 	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
> 	ENCPropagationInterceptor.invoke(Invocation) line: 41	
> 	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
> 	BlockContainerShutdownInterceptor.invoke(Invocation) line: 67	
> 	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
> 	CurrentInvocationContextInterceptor.invoke(Invocation) line: 47	
> 	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
> 	CurrentInvocationInterceptor.invoke(Invocation) line: 67	
> 	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
> 	EJB3TCCLInterceptor.invoke(Invocation) line: 86	
> 	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
> 	StatelessContainer(SessionSpecContainer).invoke(Serializable, SerializableMethod, Object[]) line: 193	
> 	StatelessContainer(SessionSpecContainer).invoke(Object, SerializableMethod, Object[]) line: 250	
> 	SessionLocalProxyInvocationHandler(SessionProxyInvocationHandlerBase).invoke(Object, Method, Object[]) line: 188	
> 	$Proxy702.publishMessages(EventSet) line: not available	
> 	NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]	
> 	NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39	
> 	DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25	
> 	Method.invoke(Object, Object...) line: 597	
> 	ClusteredEJB3InvokerJob(EJB3InvokerJob).invokeEjb(Object, JobExecutionContext) line: 196	
> 	ClusteredEJB3InvokerJob(EJB3InvokerJob).doExecute(JobExecutionContext) line: 141	
> 	ClusteredEJB3InvokerJob(EJB3InvokerJob).execute(JobExecutionContext) line: 78	
> 	JobRunShell.run() line: 203	
> 	SimpleThreadPool$WorkerThread.run() line: 520
> Update
> ========
> After debugging the code to understand what is going on I'm pretty sure we have situation where it use an old ServerConnectionEndpoint with a old postoffice instance. In our case we have a bean(stateless) that inject the TopicConnectionFactory and and Topic as resource this could possible reuse an old connection?
> I can see that sometimes it get an instance of ServerConnectionEndpoint which contains a reference to the current server peer and to the old post office. The server peer instance actual holde the reference to the new post office, but because the postoffice variable is only set on constructor level this is never changed. 
> Furthermore I can see the start method in ConnectionFactory was creating a listener that listens for failed connections, but this was not removed when the service stopped. After I removed the listener when the ConnectionFactory is stopped,  and restarted i'm able to receive updates again and it does not fail with a  "java.lang.IllegalStateException: Destination queue.MyQueue not active"

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Mon Oct  7 22:55:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Oct 2013 22:55:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1075)
 ironjacamar-deployers-common.jar contains source files (*.java)
In-Reply-To: <JIRA.12499731.1378101155000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499731.1378101155000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499731.1378101155000.22030.1381200902697@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBJCA-1075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12811386#comment-12811386 ] 

RH Bugzilla Integration commented on JBJCA-1075:
------------------------------------------------

Lin Gao <lgao at redhat.com> changed the Status of [bug 996098|https://bugzilla.redhat.com/show_bug.cgi?id=996098] from NEW to ON_QA
                
> ironjacamar-deployers-common.jar contains source files (*.java)
> ---------------------------------------------------------------
>
>                 Key: JBJCA-1075
>                 URL: https://issues.jboss.org/browse/JBJCA-1075
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Build
>    Affects Versions: 1.0.20.Final, 1.1.0.Final
>            Reporter: Lin Gao
>            Assignee: Lin Gao
>
> There are .java files included in ironjacamar-deployers-common.jar:
> {code}[lgao at dhcp-192-139 target]$ unzip -l ironjacamar-deployers-common.jar |grep ".java"
>      8739  08-30-2013 16:30   org/jboss/jca/deployers/DeployersBundle_$bundle.java
>      7944  08-30-2013 16:30   org/jboss/jca/deployers/DeployersLogger_$logger.java
> {code}
> The generated java file should not be packaged in the binary jar.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 22:55:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 7 Oct 2013 22:55:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1075)
 ironjacamar-deployers-common.jar contains source files (*.java)
In-Reply-To: <JIRA.12499731.1378101155000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499731.1378101155000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499731.1378101155000.22032.1381200902834@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBJCA-1075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12811387#comment-12811387 ] 

RH Bugzilla Integration commented on JBJCA-1075:
------------------------------------------------

Lin Gao <lgao at redhat.com> made a comment on [bug 996098|https://bugzilla.redhat.com/show_bug.cgi?id=996098]

Yes, it was fixed in ironjacamar-1.0.21.Final, which was included in EAP 6.2.0 ER3. hand over to QA
                
> ironjacamar-deployers-common.jar contains source files (*.java)
> ---------------------------------------------------------------
>
>                 Key: JBJCA-1075
>                 URL: https://issues.jboss.org/browse/JBJCA-1075
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Build
>    Affects Versions: 1.0.20.Final, 1.1.0.Final
>            Reporter: Lin Gao
>            Assignee: Lin Gao
>
> There are .java files included in ironjacamar-deployers-common.jar:
> {code}[lgao at dhcp-192-139 target]$ unzip -l ironjacamar-deployers-common.jar |grep ".java"
>      8739  08-30-2013 16:30   org/jboss/jca/deployers/DeployersBundle_$bundle.java
>      7944  08-30-2013 16:30   org/jboss/jca/deployers/DeployersLogger_$logger.java
> {code}
> The generated java file should not be packaged in the binary jar.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 23:22:02 2013
From: jira-events at lists.jboss.org (Paul Qing (JIRA))
Date: Mon, 7 Oct 2013 23:22:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-290) Can't parse condition as
 FieldConstraintDescr in 5.5.0
In-Reply-To: <JIRA.12502406.1381202452739@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502406.1381202452739@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502406.1381202452739.22047.1381202522583@jira02.app.mwc.hst.phx2.redhat.com>

Paul Qing created DROOLS-290:
--------------------------------

             Summary: Can't parse condition as FieldConstraintDescr in 5.5.0
                 Key: DROOLS-290
                 URL: https://issues.jboss.org/browse/DROOLS-290
             Project: Drools
          Issue Type: Release
      Security Level: Public (Everyone can see)
         Environment: jdk1.6.0.25
            Reporter: Paul Qing
            Assignee: Mark Proctor


hi everyone,

I met a issue when I upgrade drools from 5.0.1 to 5.5.0. when I parse  a rule in the 5.5.0. It will parse condition as ExprConstraintDescr. However,It can parse this condition as  FieldConstraintDescr in the 5.0.1. I don't know that this is a bug or not. the rule is as following:

rule "guy_13"

    when

        $g:Guy(age==13)

    then

        return true;

end

the root cause is the parser has parsed "$g:Guy(age==13)" as ExprConstraintDescr in the 5.5.0 and it can work in the 5.0.1.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct  7 23:26:02 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Mon, 7 Oct 2013 23:26:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-290) Can't parse condition as
 FieldConstraintDescr in 5.5.0
In-Reply-To: <JIRA.12502406.1381202452000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502406.1381202452000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502406.1381202452000.22051.1381202762597@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12811393#comment-12811393 ] 

Davide Sottara commented on DROOLS-290:
---------------------------------------

Constraints are handled differently in 5.5 as opposed to 5.0. In later versions, you can have "free-form" constraints as opposed to simpler <Field OP Value>.
This is not a bug. Are you manipulating the Descr tree yourself? Those classes have never been part of the public API, as far as I know
                
> Can't parse condition as FieldConstraintDescr in 5.5.0
> ------------------------------------------------------
>
>                 Key: DROOLS-290
>                 URL: https://issues.jboss.org/browse/DROOLS-290
>             Project: Drools
>          Issue Type: Release
>      Security Level: Public(Everyone can see) 
>         Environment: jdk1.6.0.25
>            Reporter: Paul Qing
>            Assignee: Mark Proctor
>
> hi everyone,
> I met a issue when I upgrade drools from 5.0.1 to 5.5.0. when I parse  a rule in the 5.5.0. It will parse condition as ExprConstraintDescr. However,It can parse this condition as  FieldConstraintDescr in the 5.0.1. I don't know that this is a bug or not. the rule is as following:
> rule "guy_13"
>     when
>         $g:Guy(age==13)
>     then
>         return true;
> end
> the root cause is the parser has parsed "$g:Guy(age==13)" as ExprConstraintDescr in the 5.5.0 and it can work in the 5.0.1.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 00:41:02 2013
From: jira-events at lists.jboss.org (Josef Cacek (JIRA))
Date: Tue, 8 Oct 2013 00:41:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2255) ManagedAuditLoggerImpl
 doesn't replace handlers correctly
In-Reply-To: <JIRA.12502407.1381207161548@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502407.1381207161548@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502407.1381207161548.22202.1381207262545@jira02.app.mwc.hst.phx2.redhat.com>

Josef Cacek created WFLY-2255:
---------------------------------

             Summary: ManagedAuditLoggerImpl doesn't replace handlers correctly
                 Key: WFLY-2255
                 URL: https://issues.jboss.org/browse/WFLY-2255
             Project: WildFly
          Issue Type: Bug
          Components: Logging
    Affects Versions: 8.0.0.Beta1
            Reporter: Josef Cacek
            Assignee: Josef Cacek




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 02:28:02 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Tue, 8 Oct 2013 02:28:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-291) ClassCastException during
 constraint jitting when an interface is used for implementation and
 traiting
In-Reply-To: <JIRA.12502409.1381213669852@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502409.1381213669852@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502409.1381213669852.22287.1381213682577@jira02.app.mwc.hst.phx2.redhat.com>

Davide Sottara created DROOLS-291:
-------------------------------------

             Summary: ClassCastException during constraint jitting when an interface is used for implementation and traiting
                 Key: DROOLS-291
                 URL: https://issues.jboss.org/browse/DROOLS-291
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  6.0.0.CR4, 5.5.0.Final
            Reporter: Davide Sottara
            Assignee: Mark Proctor
            Priority: Critical


The following combination is needed:
- an interface IX with at least one getter/setter pair
- a trait IY extending IX
- a class K implementing IX
- a jittable constraint on IX

The constraint is first triggered by an "instance" of IY, 
but jitted by an instance of K.
The condition analyzer assumes that IY is the natural
domain of the constratint, rather than IX. The jitted
constraint will then try to cast K to IY, resulting in
a disruptive CCE




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 02:33:02 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Tue, 8 Oct 2013 02:33:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-290) Can't parse condition as
 FieldConstraintDescr in 5.5.0
In-Reply-To: <JIRA.12502406.1381202452000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502406.1381202452000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502406.1381202452000.22294.1381213982552@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12811393#comment-12811393 ] 

Davide Sottara edited comment on DROOLS-290 at 10/8/13 2:31 AM:
----------------------------------------------------------------

Constraints are handled differently in 5.5 than 5.0. In later versions, you can have "free-form" constraints as opposed to simpler <Field OP Value>.
This is not a bug. Are you manipulating the Descr tree yourself? Those classes have never been part of the public API, as far as I know
                
      was (Author: dsotty):
    Constraints are handled differently in 5.5 as opposed to 5.0. In later versions, you can have "free-form" constraints as opposed to simpler <Field OP Value>.
This is not a bug. Are you manipulating the Descr tree yourself? Those classes have never been part of the public API, as far as I know
                  
> Can't parse condition as FieldConstraintDescr in 5.5.0
> ------------------------------------------------------
>
>                 Key: DROOLS-290
>                 URL: https://issues.jboss.org/browse/DROOLS-290
>             Project: Drools
>          Issue Type: Release
>      Security Level: Public(Everyone can see) 
>         Environment: jdk1.6.0.25
>            Reporter: Paul Qing
>            Assignee: Mark Proctor
>
> hi everyone,
> I met a issue when I upgrade drools from 5.0.1 to 5.5.0. when I parse  a rule in the 5.5.0. It will parse condition as ExprConstraintDescr. However,It can parse this condition as  FieldConstraintDescr in the 5.0.1. I don't know that this is a bug or not. the rule is as following:
> rule "guy_13"
>     when
>         $g:Guy(age==13)
>     then
>         return true;
> end
> the root cause is the parser has parsed "$g:Guy(age==13)" as ExprConstraintDescr in the 5.5.0 and it can work in the 5.0.1.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 02:57:02 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 8 Oct 2013 02:57:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1741) RBAC: Response headers don't
 match payload structure
In-Reply-To: <JIRA.12497111.1374568060000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497111.1374568060000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497111.1374568060000.22302.1381215422627@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun closed WFLY-1741.
-----------------------------

    Resolution: Rejected

    
> RBAC: Response headers don't match payload structure
> ----------------------------------------------------
>
>                 Key: WFLY-1741
>                 URL: https://issues.jboss.org/browse/WFLY-1741
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>
> the 'relative-address' header doesn't match the response structure:
> (hint: the 'data-source' element is missing)
> {noformat}
> [standalone at localhost:9990 /] /subsystem=datasources:read-children-resources(child-type=data-source){roles=monitor}
> {
>     "outcome" => "success",
>     "result" => {
>         "ExampleDS" => {
>             "allocation-retry" => undefined,
>             "allocation-retry-wait-millis" => undefined,
>             [...]        }
>     },
>     "response-headers" => {"access-control" => [               {
>             "absolute-address" => [
>                 ("subsystem" => "datasources"),
>                 ("data-source" => "ExampleDS")
>             ],
>             "relative-address" => [("data-source" => "ExampleDS")],
>             "filtered-attributes" => [
>                 "user-name",
>                 "security-domain",
>                 "password"
>             ]
>         }
>     ]}
> }
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 02:57:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 8 Oct 2013 02:57:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1650) Legacy subsystem testing
 needs some classloading exclusion mecanism
In-Reply-To: <JIRA.12495799.1373019038000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495799.1373019038000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495799.1373019038000.22304.1381215422699@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12811426#comment-12811426 ] 

RH Bugzilla Integration commented on WFLY-1650:
-----------------------------------------------

Pavel Jelinek <pjelinek at redhat.com> changed the Status of [bug 980923|https://bugzilla.redhat.com/show_bug.cgi?id=980923] from ON_QA to ASSIGNED
                
> Legacy subsystem testing needs some classloading exclusion mecanism
> -------------------------------------------------------------------
>
>                 Key: WFLY-1650
>                 URL: https://issues.jboss.org/browse/WFLY-1650
>             Project: WildFly
>          Issue Type: Bug
>          Components: Logging, Test Suite
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>             Fix For: 8.0.0.Beta1
>
>
> When translation messages are used (which is the case of EAP) we have conflicts between generated $logger classes when testing submodules.
> Some $logger classes exis thus they are loaded by the parent classloader before the childfirstclassloader tries to load them, thus we have a potential ClassCastException brewing. 
> For exemple this breaks the EAP build on a French OS.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 02:57:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 8 Oct 2013 02:57:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1650) Legacy subsystem testing
 needs some classloading exclusion mecanism
In-Reply-To: <JIRA.12495799.1373019038000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495799.1373019038000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495799.1373019038000.22310.1381215422976@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12811427#comment-12811427 ] 

RH Bugzilla Integration commented on WFLY-1650:
-----------------------------------------------

Pavel Jelinek <pjelinek at redhat.com> made a comment on [bug 980923|https://bugzilla.redhat.com/show_bug.cgi?id=980923]

Tests mentioned above pass, but for EAP 6.2.0 ER4 with fr_FR locale there are still some failing tests:

org.jboss.as.jpa.subsystem.JPA11SubsystemTestCase.testTransformers7_1_2 	
org.jboss.as.jpa.subsystem.JPA11SubsystemTestCase.testTransformersRejectExpressions7_1_2
org.jboss.as.modcluster.ModClusterSubsystemTestCase.testTransformers712 	
org.jboss.as.modcluster.ModClusterSubsystemTestCase.testExpressionsAreRejected712 
org.jboss.as.osgi.parser.OSGiSubsystemTestCase.testTransformerAS712 
org.jboss.as.osgi.parser.OSGiSubsystemTestCase.testRejectExpressionsAS712 

See: 

https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-60-as-testsuite-RHEL-matrix-OracleJDK6-french-pjelinek/1/testReport/

https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-60-as-testsuite-RHEL-matrix-openJDK7-french-pjelinek/1/testReport/
                
> Legacy subsystem testing needs some classloading exclusion mecanism
> -------------------------------------------------------------------
>
>                 Key: WFLY-1650
>                 URL: https://issues.jboss.org/browse/WFLY-1650
>             Project: WildFly
>          Issue Type: Bug
>          Components: Logging, Test Suite
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>             Fix For: 8.0.0.Beta1
>
>
> When translation messages are used (which is the case of EAP) we have conflicts between generated $logger classes when testing submodules.
> Some $logger classes exis thus they are loaded by the parent classloader before the childfirstclassloader tries to load them, thus we have a potential ClassCastException brewing. 
> For exemple this breaks the EAP build on a French OS.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 03:08:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 8 Oct 2013 03:08:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-101) JMSService.start is doing
	blocking I/O
In-Reply-To: <JIRA.12489128.1365693199000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489128.1365693199000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489128.1365693199000.22325.1381216083014@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12811431#comment-12811431 ] 

RH Bugzilla Integration commented on WFLY-101:
----------------------------------------------

Jeff Mesnil <jmesnil at redhat.com> made a comment on [bug 1003913|https://bugzilla.redhat.com/show_bug.cgi?id=1003913]

(In reply to Miroslav Novak from comment #5)
> Problem is "[WFLY-101] JMSService.start to perform blocking I/O
> asynchronously" I guess only way to verify is to read the code, right?

That's correct, there is no observable way to verify this.
Reading the code, it appears that the JMSService.start/stop methods performs HornetQ-related operations asynchronously in a separate executor: https://github.com/jmesnil/jboss-eap/commit/161295de1ae35a10c53dcc8f4fce933b4baadeb2#diff-60f2c56b6f01bb06387cbe9054ddc549R89
                
> JMSService.start is doing blocking I/O
> --------------------------------------
>
>                 Key: WFLY-101
>                 URL: https://issues.jboss.org/browse/WFLY-101
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.Alpha1
>
>
> flag the start context as asynchronous

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 04:39:03 2013
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Tue, 8 Oct 2013 04:39:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1963) Rollback leaves files
	undeleted on Windows
In-Reply-To: <JIRA.12499497.1377684219000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499497.1377684219000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499497.1377684219000.22774.1381221543236@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emanuel Muckenhuber resolved WFLY-1963.
---------------------------------------

    Resolution: Done

    
> Rollback leaves files undeleted on Windows
> ------------------------------------------
>
>                 Key: WFLY-1963
>                 URL: https://issues.jboss.org/browse/WFLY-1963
>             Project: WildFly
>          Issue Type: Bug
>          Components: Patching
>            Reporter: Jan Martiska
>            Assignee: Emanuel Muckenhuber
>            Priority: Blocker
>
> When rolling back a patch on Windows, if some of its files are still used (eg. active modules), file locking prevents the rollback process to delete them. We need a solution probably cleaning up these files when the server is being restarted.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 04:39:03 2013
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Tue, 8 Oct 2013 04:39:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1963) Rollback leaves files
	undeleted on Windows
In-Reply-To: <JIRA.12499497.1377684219000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499497.1377684219000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499497.1377684219000.22776.1381221543341@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emanuel Muckenhuber updated WFLY-1963:
--------------------------------------

    Fix Version/s: 8.0.0.CR1

    
> Rollback leaves files undeleted on Windows
> ------------------------------------------
>
>                 Key: WFLY-1963
>                 URL: https://issues.jboss.org/browse/WFLY-1963
>             Project: WildFly
>          Issue Type: Bug
>          Components: Patching
>            Reporter: Jan Martiska
>            Assignee: Emanuel Muckenhuber
>            Priority: Blocker
>             Fix For: 8.0.0.CR1
>
>
> When rolling back a patch on Windows, if some of its files are still used (eg. active modules), file locking prevents the rollback process to delete them. We need a solution probably cleaning up these files when the server is being restarted.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 04:41:02 2013
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Tue, 8 Oct 2013 04:41:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2104) Patch-gen tool should provide
 users with better error messages
In-Reply-To: <JIRA.12500897.1379504473000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500897.1379504473000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500897.1379504473000.22781.1381221662723@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emanuel Muckenhuber resolved WFLY-2104.
---------------------------------------

    Fix Version/s: 8.0.0.CR1
       Resolution: Done

    
> Patch-gen tool should provide users with better error messages
> --------------------------------------------------------------
>
>                 Key: WFLY-2104
>                 URL: https://issues.jboss.org/browse/WFLY-2104
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Patching
>            Reporter: Vaclav Tunka
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.CR1
>
>
> Patch-gen tool should provide better error messages to user. Eg. telling what exactly is wrong, instead of listing the full usage.
> [vtunka at voidray tool]$ ./tool.sh --create-template --cumlative 6.2.0
> USAGE:
> patch-gen.sh --create-template --one-of     [patch-id]
> patch-gen.sh --create-template --cumulative [patch-id]
> this will create a patch-config-[patch-id].xml
> if this is not desired just append --std.out
> There is a typo in --cumlative instead of --cumulative, but the tool doesn't say that, and user is left to explore possible sources of error.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 05:25:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 8 Oct 2013 05:25:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2172) Resurrect the mixed domain
 testing and fix any problems
In-Reply-To: <JIRA.12501720.1380277458000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501720.1380277458000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501720.1380277458000.23076.1381224302770@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12811669#comment-12811669 ] 

RH Bugzilla Integration commented on WFLY-2172:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> made a comment on [bug 1015243|https://bugzilla.redhat.com/show_bug.cgi?id=1015243]

The work has already been done. It lives here: https://github.com/jbossas/jboss-eap/pull/510.
                
> Resurrect the mixed domain testing and fix any problems
> -------------------------------------------------------
>
>                 Key: WFLY-2172
>                 URL: https://issues.jboss.org/browse/WFLY-2172
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Brian Stansberry
>            Priority: Blocker
>             Fix For: 8.0.0.CR1
>
>
> THis has not been run for quite some time, and needs to be included in the general testing.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 05:37:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 8 Oct 2013 05:37:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2256) Add a TRACE level category
 for the operations used to start a server.
In-Reply-To: <JIRA.12502422.1381225020848@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502422.1381225020848@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502422.1381225020848.23180.1381225022604@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-2256:
--------------------------------------

             Summary: Add a TRACE level category for the operations used to start a server.
                 Key: WFLY-2256
                 URL: https://issues.jboss.org/browse/WFLY-2256
             Project: WildFly
          Issue Type: Enhancement
          Components: Domain Management, Logging
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 8.0.0.CR1


Sometimes after being able to start a server from the XML configuration it is useful to be able to identify the actual operations that are executed to start the server.

>From a development perspective this is useful for double checking the operations are as we expect.

>From an end user perspective this can be useful to identify the set of equivalent operations needed if the same was to be achieved in a CLI script.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 05:59:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 8 Oct 2013 05:59:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2172) Resurrect the mixed domain
 testing and fix any problems
In-Reply-To: <JIRA.12501720.1380277458000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501720.1380277458000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501720.1380277458000.23325.1381226342911@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12811756#comment-12811756 ] 

RH Bugzilla Integration commented on WFLY-2172:
-----------------------------------------------

Rostislav Svoboda <rsvoboda at redhat.com> made a comment on [bug 1015243|https://bugzilla.redhat.com/show_bug.cgi?id=1015243]

Brian, Kabir, thank you for comments. Changing qa_ack to +. There is no description and BZ title implied that it would be QA task.
                
> Resurrect the mixed domain testing and fix any problems
> -------------------------------------------------------
>
>                 Key: WFLY-2172
>                 URL: https://issues.jboss.org/browse/WFLY-2172
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Brian Stansberry
>            Priority: Blocker
>             Fix For: 8.0.0.CR1
>
>
> THis has not been run for quite some time, and needs to be included in the general testing.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 06:07:02 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Tue, 8 Oct 2013 06:07:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2255) ManagedAuditLoggerImpl
 doesn't replace handlers correctly
In-Reply-To: <JIRA.12502407.1381207161000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502407.1381207161000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502407.1381207161000.23343.1381226822721@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-2255:
-----------------------------

    Component/s: Domain Management
                     (was: Logging)

    
> ManagedAuditLoggerImpl doesn't replace handlers correctly
> ---------------------------------------------------------
>
>                 Key: WFLY-2255
>                 URL: https://issues.jboss.org/browse/WFLY-2255
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Josef Cacek
>            Assignee: Josef Cacek
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 06:13:03 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 8 Oct 2013 06:13:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-291) ClassCastException during
 constraint jitting when an interface is used for implementation and
 traiting
In-Reply-To: <JIRA.12502409.1381213669000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502409.1381213669000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502409.1381213669000.23366.1381227183179@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-291:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> ClassCastException during constraint jitting when an interface is used for implementation and traiting
> ------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-291
>                 URL: https://issues.jboss.org/browse/DROOLS-291
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final,  6.0.0.CR4
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Critical
>
> The following combination is needed:
> - an interface IX with at least one getter/setter pair
> - a trait IY extending IX
> - a class K implementing IX
> - a jittable constraint on IX
> The constraint is first triggered by an "instance" of IY, 
> but jitted by an instance of K.
> The condition analyzer assumes that IY is the natural
> domain of the constratint, rather than IX. The jitted
> constraint will then try to cast K to IY, resulting in
> a disruptive CCE

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 06:15:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 8 Oct 2013 06:15:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1358) Support Windows paths with
 spaces in batch files
In-Reply-To: <JIRA.12492011.1368754869000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12492011.1368754869000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12492011.1368754869000.23371.1381227303197@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12811772#comment-12811772 ] 

RH Bugzilla Integration commented on WFLY-1358:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> changed the Status of [bug 916960|https://bugzilla.redhat.com/show_bug.cgi?id=916960] from NEW to VERIFIED
                
> Support Windows paths with spaces in batch files
> ------------------------------------------------
>
>                 Key: WFLY-1358
>                 URL: https://issues.jboss.org/browse/WFLY-1358
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Scripts
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Minor
>             Fix For: 8.0.0.Alpha1
>
>
> If a Windows path has a space or {{()}} in it the scripts fail to execute.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 06:15:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 8 Oct 2013 06:15:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1358) Support Windows paths with
 spaces in batch files
In-Reply-To: <JIRA.12492011.1368754869000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12492011.1368754869000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12492011.1368754869000.23373.1381227303276@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12811773#comment-12811773 ] 

RH Bugzilla Integration commented on WFLY-1358:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> made a comment on [bug 916960|https://bugzilla.redhat.com/show_bug.cgi?id=916960]

I retested this with latest EAP build and the issue is fixed.

Verified on EAP 6.2.0.ER5.
                
> Support Windows paths with spaces in batch files
> ------------------------------------------------
>
>                 Key: WFLY-1358
>                 URL: https://issues.jboss.org/browse/WFLY-1358
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Scripts
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Minor
>             Fix For: 8.0.0.Alpha1
>
>
> If a Windows path has a space or {{()}} in it the scripts fail to execute.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 06:23:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 8 Oct 2013 06:23:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-85) slf4j-jboss-logmanager
 does not support parametization of a logging statement in the presence of a
 Throwable
In-Reply-To: <JIRA.12472064.1344503194000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12472064.1344503194000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12472064.1344503194000.23405.1381227783163@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBLOGGING-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12811785#comment-12811785 ] 

RH Bugzilla Integration commented on JBLOGGING-85:
--------------------------------------------------

Ondrej Lukas <olukas at redhat.com> changed the Status of [bug 876489|https://bugzilla.redhat.com/show_bug.cgi?id=876489] from ON_QA to VERIFIED
                
> slf4j-jboss-logmanager does not support parametization of a logging statement in the presence of a Throwable
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: JBLOGGING-85
>                 URL: https://issues.jboss.org/browse/JBLOGGING-85
>             Project: JBoss Logging
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: slf4j-jboss-logmanager
>            Reporter: Hercules Zeus
>            Assignee: James Perkins
>
> http://www.slf4j.org/faq.html#paramException describes that from slf4j 1.6 onwards doing the following will print a stacktrace:
> logger.error("Failed to format {}", s, e);
> However, due to the implementation of org.slf4j.impl.MessageFormatter in slf4j-jboss-logmanager, when logger.error(String, Object, Object) is called, even if the third parameter is a Throwable, it is not recognised as such.
> Investigating further, it seems that org.slf4j.impl.MessageFormatter is probably just an old copy of org.slf4j.helpers.MessageFormatter in slfj-api 1.6.1, where most formatting methods used to return a String now returns a FormattingTuple.
> This issue can be fixed by making all calls in Slf4Logger to org.slf4j.impl.MessageFormatter to call org.slf4j.helpers.MessageFormatter instead and appropriately call ExtLogRecord.setThrown(formattingTuple.getThrowable()).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 06:23:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 8 Oct 2013 06:23:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-85) slf4j-jboss-logmanager
 does not support parametization of a logging statement in the presence of a
 Throwable
In-Reply-To: <JIRA.12472064.1344503194000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12472064.1344503194000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12472064.1344503194000.23413.1381227783515@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBLOGGING-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12811786#comment-12811786 ] 

RH Bugzilla Integration commented on JBLOGGING-85:
--------------------------------------------------

Ondrej Lukas <olukas at redhat.com> made a comment on [bug 876489|https://bugzilla.redhat.com/show_bug.cgi?id=876489]

Verified on EAP 6.2.0.ER4
                
> slf4j-jboss-logmanager does not support parametization of a logging statement in the presence of a Throwable
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: JBLOGGING-85
>                 URL: https://issues.jboss.org/browse/JBLOGGING-85
>             Project: JBoss Logging
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: slf4j-jboss-logmanager
>            Reporter: Hercules Zeus
>            Assignee: James Perkins
>
> http://www.slf4j.org/faq.html#paramException describes that from slf4j 1.6 onwards doing the following will print a stacktrace:
> logger.error("Failed to format {}", s, e);
> However, due to the implementation of org.slf4j.impl.MessageFormatter in slf4j-jboss-logmanager, when logger.error(String, Object, Object) is called, even if the third parameter is a Throwable, it is not recognised as such.
> Investigating further, it seems that org.slf4j.impl.MessageFormatter is probably just an old copy of org.slf4j.helpers.MessageFormatter in slfj-api 1.6.1, where most formatting methods used to return a String now returns a FormattingTuple.
> This issue can be fixed by making all calls in Slf4Logger to org.slf4j.impl.MessageFormatter to call org.slf4j.helpers.MessageFormatter instead and appropriately call ExtLogRecord.setThrown(formattingTuple.getThrowable()).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 06:34:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 8 Oct 2013 06:34:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SASL-43) Release JBoss SASL 1.0.4.CR1
In-Reply-To: <JIRA.12502358.1381157855000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502358.1381157855000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502358.1381157855000.23465.1381228442557@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SASL-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved SASL-43.
----------------------------------

    Fix Version/s: 1.0.4.CR1
       Resolution: Done

    
> Release JBoss SASL 1.0.4.CR1
> ----------------------------
>
>                 Key: SASL-43
>                 URL: https://issues.jboss.org/browse/SASL-43
>             Project: JBoss SASL Provider
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.0.4.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 06:36:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 8 Oct 2013 06:36:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-291) ClassCastException during
 constraint jitting when an interface is used for implementation and
 traiting
In-Reply-To: <JIRA.12502409.1381213669000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502409.1381213669000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502409.1381213669000.23470.1381228562817@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-291.
--------------------------------

    Fix Version/s: 5.5.1.Final
                   6.0.0.CR5
       Resolution: Done

    
> ClassCastException during constraint jitting when an interface is used for implementation and traiting
> ------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-291
>                 URL: https://issues.jboss.org/browse/DROOLS-291
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final,  6.0.0.CR4
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Critical
>             Fix For: 5.5.1.Final, 6.0.0.CR5
>
>
> The following combination is needed:
> - an interface IX with at least one getter/setter pair
> - a trait IY extending IX
> - a class K implementing IX
> - a jittable constraint on IX
> The constraint is first triggered by an "instance" of IY, 
> but jitted by an instance of K.
> The condition analyzer assumes that IY is the natural
> domain of the constratint, rather than IX. The jitted
> constraint will then try to cast K to IY, resulting in
> a disruptive CCE

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 06:36:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 8 Oct 2013 06:36:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SASL-40) Update the local authentication
 mechanism to allow permissions to be specified for the challenge file.
In-Reply-To: <JIRA.12486810.1362763394000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12486810.1362763394000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12486810.1362763394000.23472.1381228562972@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SASL-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated SASL-40:
---------------------------------

    Fix Version/s: 1.0.4.CR2
                       (was: 1.0.4.CR1)

    
> Update the local authentication mechanism to allow permissions to be specified for the challenge file.
> ------------------------------------------------------------------------------------------------------
>
>                 Key: SASL-40
>                 URL: https://issues.jboss.org/browse/SASL-40
>             Project: JBoss SASL Provider
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.0.4.CR2
>
>
> (This would include switching to a dependency on Java 7 server side at least)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 06:36:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 8 Oct 2013 06:36:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SASL-39) Support for stronger hashes as
 alternatives to MD5
In-Reply-To: <JIRA.12479914.1354008365000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479914.1354008365000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479914.1354008365000.23476.1381228563146@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SASL-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated SASL-39:
---------------------------------

    Fix Version/s: 1.0.4.CR2
                       (was: 1.0.4.CR1)

    
> Support for stronger hashes as alternatives to MD5
> --------------------------------------------------
>
>                 Key: SASL-39
>                 URL: https://issues.jboss.org/browse/SASL-39
>             Project: JBoss SASL Provider
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Darran Lofthouse
>             Fix For: 1.0.4.CR2
>
>
> Presently Digest authentication is based on MD5 - however we should either update the mechanism or add new mechanisms to support the use of stronger hashes.
> As this library is used both client and server side installations that require the stronger hashes can just ensure the client and server have the latest version of this library - installations that still require interaction with MD5 will need to ensure that it is still available as a mechanism.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 06:36:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 8 Oct 2013 06:36:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SASL-11) From RFC-2831 a realm name can
 contain whitespace,
 this means using space as the delimiter for possible realms is incorrect
In-Reply-To: <JIRA.12447706.1316779828000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12447706.1316779828000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12447706.1316779828000.23480.1381228563280@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SASL-11?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated SASL-11:
---------------------------------

    Fix Version/s: 1.0.4.CR2
                       (was: 1.0.4.CR1)

    
> From RFC-2831 a realm name can contain whitespace, this means using space as the delimiter for possible realms is incorrect
> ---------------------------------------------------------------------------------------------------------------------------
>
>                 Key: SASL-11
>                 URL: https://issues.jboss.org/browse/SASL-11
>             Project: JBoss SASL Provider
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.0.4.CR2
>
>
> By using space as the separator a single realm name that contains a space is split into two realms.
> Either support quoted realm names if they contain a space or choose a different delimiter - (A different delimiter other than a control character may be difficult as the rest can appear in a realm name)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 06:36:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 8 Oct 2013 06:36:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SASL-10) Pluggable nonce handling
	strategy
In-Reply-To: <JIRA.12446879.1315944468000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12446879.1315944468000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12446879.1315944468000.23484.1381228563479@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SASL-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated SASL-10:
---------------------------------

    Fix Version/s: 1.0.4.CR2
                       (was: 1.0.4.CR1)

    
> Pluggable nonce handling strategy
> ---------------------------------
>
>                 Key: SASL-10
>                 URL: https://issues.jboss.org/browse/SASL-10
>             Project: JBoss SASL Provider
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.0.4.CR2
>
>
> Implement a pluggable nonce handling strategy.
> At the very least we need to be able to switch to using a SecureRandom instead of Random.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 06:36:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 8 Oct 2013 06:36:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SASL-11) From RFC-2831 a realm name can
 contain whitespace,
 this means using space as the delimiter for possible realms is incorrect
In-Reply-To: <JIRA.12447706.1316779828000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12447706.1316779828000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12447706.1316779828000.23488.1381228563609@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SASL-11?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated SASL-11:
---------------------------------

    Sprint: Sprint 1

    
> From RFC-2831 a realm name can contain whitespace, this means using space as the delimiter for possible realms is incorrect
> ---------------------------------------------------------------------------------------------------------------------------
>
>                 Key: SASL-11
>                 URL: https://issues.jboss.org/browse/SASL-11
>             Project: JBoss SASL Provider
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.0.4.CR2
>
>
> By using space as the separator a single realm name that contains a space is split into two realms.
> Either support quoted realm names if they contain a space or choose a different delimiter - (A different delimiter other than a control character may be difficult as the rest can appear in a realm name)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 06:36:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 8 Oct 2013 06:36:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SASL-39) Support for stronger hashes as
 alternatives to MD5
In-Reply-To: <JIRA.12479914.1354008365000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479914.1354008365000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479914.1354008365000.23491.1381228563742@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SASL-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated SASL-39:
---------------------------------

    Sprint: Sprint 1

    
> Support for stronger hashes as alternatives to MD5
> --------------------------------------------------
>
>                 Key: SASL-39
>                 URL: https://issues.jboss.org/browse/SASL-39
>             Project: JBoss SASL Provider
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Darran Lofthouse
>             Fix For: 1.0.4.CR2
>
>
> Presently Digest authentication is based on MD5 - however we should either update the mechanism or add new mechanisms to support the use of stronger hashes.
> As this library is used both client and server side installations that require the stronger hashes can just ensure the client and server have the latest version of this library - installations that still require interaction with MD5 will need to ensure that it is still available as a mechanism.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 06:38:03 2013
From: jira-events at lists.jboss.org (Gytis Trikleris (JIRA))
Date: Tue, 8 Oct 2013 06:38:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2201) Server-side XTS handlers not
 added if @WebService#portName is missing
In-Reply-To: <JIRA.12501360.1380015769000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501360.1380015769000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501360.1380015769000.23524.1381228683977@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12811816#comment-12811816 ] 

Gytis Trikleris commented on WFLY-2201:
---------------------------------------

I do not want to raise the PR until JBTM-1963 is sorted, because it may cause the applications to fail unexpectedly...
                
> Server-side XTS handlers not added if @WebService#portName is missing
> ---------------------------------------------------------------------
>
>                 Key: WFLY-2201
>                 URL: https://issues.jboss.org/browse/WFLY-2201
>             Project: WildFly
>          Issue Type: Bug
>          Components: XTS
>            Reporter: Paul Robinson
>            Assignee: Gytis Trikleris
>            Priority: Minor
>             Fix For: 8.0.0.CR1
>
>
> To reproduce, remove portName or targetNameSpace attributes from org.jboss.narayana.compensations.functional.distributed.DistributedTest in the TXFramework suite. You will see that the test fails with:
> {code}
> "MustUnderstand headers: [{http://docs.oasis-open.org/ws-tx/wscoor/2006/06}CoordinationContext] are not understood"
> {code}
> The problem is that the Endpoint is not recognised, by the XTS subsytem, as having a valid @WebService annotation if these attributes are missing. In reality they are optional and an application should be allowed to leave them off. However, these attribute values are used by the XTS subsytem, so we would need to find a way of using the defaults if they are missing from the annotation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 07:04:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 8 Oct 2013 07:04:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-266) KIE resolving dependend
	artifacts issue
In-Reply-To: <JIRA.12500919.1379513154000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500919.1379513154000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500919.1379513154000.23584.1381230242606@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12811842#comment-12811842 ] 

RH Bugzilla Integration commented on DROOLS-266:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> made a comment on [bug 1014157|https://bugzilla.redhat.com/show_bug.cgi?id=1014157]


                
> KIE resolving dependend artifacts issue
> ---------------------------------------
>
>                 Key: DROOLS-266
>                 URL: https://issues.jboss.org/browse/DROOLS-266
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR3
>            Reporter: Kurt Stam
>            Assignee: Mario Fusco
>             Fix For: 6.0.0.CR5
>
>         Attachments: kie-load-from-maven-issue.tgz, kie-load-from-maven-issue.tgz
>
>
> This happens when for a dependency the scope is
> - set to 'provided' and
> - a parameter (in the case ${jbpm.version}) is used in the version field.
> So the relevant entry in the pom is:
> <dependency>
>       <groupId>org.drools</groupId>
>       <artifactId>drools-core</artifactId>
>       <version>${drools.version}</version>
>       <scope>provided</scope>
>     </dependency>
> which leads to
> 11:15:02,584  WARN Dependency artifact not found for: org.jbpm:jbpm-bpmn2:${jbpm.version}
> and then the NPE. I'm guessing the parameter is not being resolved.
> 1. it probably should resolve parameters
> 2. if a dependency is scoped as 'provided' I think it is supposed to locate it on the classpath and NOT from maven. However I'm not sure this is the way that works in testing anyway.
> 3. if the dependency  cannot be found it should probably stop and not even proceed rather then warn?
> 4. it should be interesting to see why it gets the NPE.
> If you change the dependency from 'provided' to 'test' things work fine.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 07:34:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 8 Oct 2013 07:34:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-218) Update add-user utility to
 allow overrides of property file name.
In-Reply-To: <JIRA.12489742.1366220996000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489742.1366220996000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489742.1366220996000.23741.1381232042967@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12811884#comment-12811884 ] 

RH Bugzilla Integration commented on WFLY-218:
----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> made a comment on [bug 978984|https://bugzilla.redhat.com/show_bug.cgi?id=978984]

As this bug seems stuck in a loop I am providing a dev NACK until this bot can actually make up it's mind if this bug should have an ACK for the release or not.
                
> Update add-user utility to allow overrides of property file name.
> -----------------------------------------------------------------
>
>                 Key: WFLY-218
>                 URL: https://issues.jboss.org/browse/WFLY-218
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Domain Management, Scripts
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.Alpha3
>
>
> This enhancement is going to add two additional command line options to the add-user utility: -
> -up --user-properties
> This will specify the file name of the properties file containing the users and passwords.
> -gp --group-properties
> This will specify the file name of the properties file containing the users groups.
> If specified as absolute paths no searches will be used to locate additional file otherwise both the standalone and domain configuration folders will be searched for matching files.
> group-properties can only be specified if there is a user-properties, the omission of group-properties will disable the prompt to ask for a users groups.
> Specifying a user-properties disables the prompt asking if this is management or application as the primary reason for asking that was to decide which files to look for.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 08:59:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 8 Oct 2013 08:59:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2207) CLI Unable to connect using
 https-remoting address.
In-Reply-To: <JIRA.12502036.1380735356000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502036.1380735356000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502036.1380735356000.24165.1381237143056@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812020#comment-12812020 ] 

Darran Lofthouse commented on WFLY-2207:
----------------------------------------

Additionally if the SSL connection can not be established there is no indication as to why, just the error message after the 5 second timeout.
                
> CLI Unable to connect using https-remoting address.
> ---------------------------------------------------
>
>                 Key: WFLY-2207
>                 URL: https://issues.jboss.org/browse/WFLY-2207
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.CR1
>
>
> The CLI is failing to connect over https with the following: -
> {code}
> [disconnected /] connect https-remoting://localhost:9993
> The controller is not available at localhost:9993: java.net.ConnectException: JBAS012144: Could not connect to https-remoting://localhost:9993. The connection timed out: JBAS012144: Could not connect to https-remoting://localhost:9993. The connection timed out
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 09:05:03 2013
From: jira-events at lists.jboss.org (prasad Kasthuri (JIRA))
Date: Tue, 8 Oct 2013 09:05:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2257) Building JBoss EAP from
 sources causing hang and errors, no progress.
In-Reply-To: <JIRA.12502449.1381237429922@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502449.1381237429922@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502449.1381237429922.24204.1381237503050@jira02.app.mwc.hst.phx2.redhat.com>

prasad Kasthuri created WFLY-2257:
-------------------------------------

             Summary: Building JBoss EAP from sources causing hang and errors, no progress.
                 Key: WFLY-2257
                 URL: https://issues.jboss.org/browse/WFLY-2257
             Project: WildFly
          Issue Type: Feature Request
          Components: Build System
    Affects Versions: 8.0.0.Beta1
            Reporter: prasad Kasthuri
            Assignee: Paul Gier




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 09:07:03 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 8 Oct 2013 09:07:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2257) Building JBoss EAP from
 sources causing hang and errors, no progress.
In-Reply-To: <JIRA.12502449.1381237429000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502449.1381237429000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502449.1381237429000.24223.1381237623525@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812036#comment-12812036 ] 

Tomaz Cerar commented on WFLY-2257:
-----------------------------------

You marked version as WildFly 8.0.0.Beta1 
you can follow this guide how to build wildfly https://community.jboss.org/wiki/HackingOnWildFly
and its sources are available here https://github.com/wildfly/wildfly
can you post more details what is going wrong with building wildfly?
                
> Building JBoss EAP from sources causing hang and errors, no progress.
> ---------------------------------------------------------------------
>
>                 Key: WFLY-2257
>                 URL: https://issues.jboss.org/browse/WFLY-2257
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Build System
>    Affects Versions: 8.0.0.Beta1
>            Reporter: prasad Kasthuri
>            Assignee: Paul Gier
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 09:07:03 2013
From: jira-events at lists.jboss.org (prasad Kasthuri (JIRA))
Date: Tue, 8 Oct 2013 09:07:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2257) Building JBoss EAP from
 sources causing hang and errors, no progress.
In-Reply-To: <JIRA.12502449.1381237429000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502449.1381237429000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502449.1381237429000.24229.1381237623785@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812038#comment-12812038 ] 

prasad Kasthuri commented on WFLY-2257:
---------------------------------------

The testsuite is throwing lot of errors. Below is the snippet of error from the JBoss EAP console. The sources have been downloaded from https://github.com/wildfly/wildfly. 

Sep 27, 2013 10:26:59 AM org.jboss.msc.service.ServiceContainerImpl <init>
ERROR: MSC000010: Failed to register MBean with MBeanServer
javax.management.InstanceAlreadyExistsException: jboss.msc:type=container,name=test
        at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
        at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
        at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)
        at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
        at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
        at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:513)
        at org.jboss.msc.service.ServiceContainerImpl.<init>(ServiceContainerImpl.java:371)
        at org.jboss.msc.service.ServiceContainer$Factory.create(ServiceContainer.java:173)
        at org.jboss.as.controller.test.AbstractControllerTestBase.setupController(AbstractControllerTestBase.java:131)
        at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:601)
        at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
        at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
        at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
        at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
        at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)

                
> Building JBoss EAP from sources causing hang and errors, no progress.
> ---------------------------------------------------------------------
>
>                 Key: WFLY-2257
>                 URL: https://issues.jboss.org/browse/WFLY-2257
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Build System
>    Affects Versions: 8.0.0.Beta1
>            Reporter: prasad Kasthuri
>            Assignee: Paul Gier
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 09:09:02 2013
From: jira-events at lists.jboss.org (prasad Kasthuri (JIRA))
Date: Tue, 8 Oct 2013 09:09:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2257) Building JBoss EAP from
 sources causing hang and errors, no progress.
In-Reply-To: <JIRA.12502449.1381237429000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502449.1381237429000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502449.1381237429000.24233.1381237742658@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812038#comment-12812038 ] 

prasad Kasthuri edited comment on WFLY-2257 at 10/8/13 9:07 AM:
----------------------------------------------------------------

The testsuite is throwing lot of errors. Below is the snippet of error from the JBoss EAP console. The sources have been downloaded from https://github.com/wildfly/wildfly. 

Sep 27, 2013 10:26:59 AM org.jboss.msc.service.ServiceContainerImpl <init>
ERROR: MSC000010: Failed to register MBean with MBeanServer
javax.management.InstanceAlreadyExistsException: jboss.msc:type=container,name=test
        at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
        at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
        at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)
        at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
        at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
        at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:513)
        at org.jboss.msc.service.ServiceContainerImpl.<init>(ServiceContainerImpl.java:371)
        at org.jboss.msc.service.ServiceContainer$Factory.create(ServiceContainer.java:173)
        at org.jboss.as.controller.test.AbstractControllerTestBase.setupController(AbstractControllerTestBase.java:131)
        at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:601)
        at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
        at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
        at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
        at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
        at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
 at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
        at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
        at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
        at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
        at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
        at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
        at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
        at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
        at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
        at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133)
        at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:601)
        at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188)
        at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166)
        at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
        at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101)
        at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)

                
      was (Author: prasad.kasthuri):
    The testsuite is throwing lot of errors. Below is the snippet of error from the JBoss EAP console. The sources have been downloaded from https://github.com/wildfly/wildfly. 

Sep 27, 2013 10:26:59 AM org.jboss.msc.service.ServiceContainerImpl <init>
ERROR: MSC000010: Failed to register MBean with MBeanServer
javax.management.InstanceAlreadyExistsException: jboss.msc:type=container,name=test
        at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
        at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
        at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)
        at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
        at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
        at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:513)
        at org.jboss.msc.service.ServiceContainerImpl.<init>(ServiceContainerImpl.java:371)
        at org.jboss.msc.service.ServiceContainer$Factory.create(ServiceContainer.java:173)
        at org.jboss.as.controller.test.AbstractControllerTestBase.setupController(AbstractControllerTestBase.java:131)
        at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:601)
        at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
        at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
        at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
        at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
        at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)

                  
> Building JBoss EAP from sources causing hang and errors, no progress.
> ---------------------------------------------------------------------
>
>                 Key: WFLY-2257
>                 URL: https://issues.jboss.org/browse/WFLY-2257
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Build System
>    Affects Versions: 8.0.0.Beta1
>            Reporter: prasad Kasthuri
>            Assignee: Paul Gier
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 09:11:03 2013
From: jira-events at lists.jboss.org (Flemming Harms (JIRA))
Date: Tue, 8 Oct 2013 09:11:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1948)
 java.lang.IllegalStateException: Destination queue.ISXO_AuditLogQueue_01
 not active after MessagingClusterHealthMBean restart JMS service
In-Reply-To: <JIRA.12502101.1380799169000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502101.1380799169000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502101.1380799169000.24262.1381237863774@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBMESSAGING-1948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812041#comment-12812041 ] 

Flemming Harms commented on JBMESSAGING-1948:
---------------------------------------------

Hi Howard

Thanks for the answer.

Yes it run 'in-vm' and I also tried the lookup JNDI workaround and that also seems to be working. But the thing is that as a JEE application developer you will properly use the @Resource annotation to injects JMS related resources into a stateless bean, and you will not expect it to connect to old Connection Factories because it's stateless.

The patch I submitted seems to solve this issue, that is what our test shows. But I'm unsure if this will potential break other parts in the JBoss Messaging?

In my opinion this should be transparent to the JEE developer and should be handle either by the JBoss AS or JBoss Messaging :)

thanks
Flemming

                
> java.lang.IllegalStateException: Destination queue.ISXO_AuditLogQueue_01 not active after MessagingClusterHealthMBean restart JMS service
> -----------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1948
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1948
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.8.SP9
>            Reporter: Flemming Harms
>            Assignee: Yong Hao Gao
>         Attachments: ConnectionFactory-diff.patch, postoffice-patch.diff
>
>
> I get this error ?java.lang.IllegalStateException: Destination queue.ISXO_AuditLogQueue_01 not active? after MessagingClusterHealthMBean restarts the JMS service with JBoss Messaging 1.4.8.SP9. 
> I have 2 node JBoss5 cluster with JBoss Messaging and I have enabled the new failover model and setup the MessagingClusterHealthMBean to monitor split brain.
> I disconnect the cable from one of the servers MessagingClusterHealthMBean discover it?s alone and shut down the JMS service as expected. After a while I connect the server again and the server discover the other server and MessagingClusterHealthMBean starts the JMS service also as expected.
> But when I connect a client it fails with ?java.lang.IllegalStateException: Destination queue.ISXO_AuditLogQueue_01 not active? and what I can see in the debugger ServerConnectionEndpoint have reference to the old post office where the queue is still exits in the inactiveConditions Set.
> Log from the server when it discover it?s alone and it restart the service again
> 2013-09-07 21:29:06,381 ERROR [org.jboss.messaging.core.impl.postoffice.MessagingPostOffice] (Thread-32) I'm orphaned and now I can't tell others that I'm alive. Shutdown node: 102
> 2013-09-07 21:29:09,728 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-32) Stopping JBM node on DB failure...
> 2013-09-07 21:29:09,731 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-32) Queue[/queue/ExpiryQueue] stopped
> 2013-09-07 21:29:09,732 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-32) Queue[/queue/DLQ] stopped
> 2013-09-07 21:29:09,733 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-32) Queue[/ISXO/AuditLogQueue, name=ISXO_AuditLogQueue_01] stopped
> 2013-09-07 21:29:09,733 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-32) Queue[/ISXO/CiscoUCSEventQueue, name=ISXO_CiscoUCSEventQueue_01] stopped
> 2013-09-07 21:29:09,738 INFO  [org.jboss.jms.server.destination.TopicService] (Thread-32) Topic[/ISXO/RemoteEventTopic, name=ISXO_RemoteEventQueue_01] stopped
> 2013-09-07 21:29:09,739 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-32) Queue[/ISXO/ScheduledJobQueue, name=ISXO_ScheduledJobQueue_01] stopped
> 2013-09-07 21:29:11,210 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-32) org.jboss.jms.server.connectionfactory.ConnectionFactory at 366480d7 undeployed
> 2013-09-07 21:29:11,216 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-32) org.jboss.jms.server.connectionfactory.ConnectionFactory at 467463b3 undeployed
> 2013-09-07 21:29:11,216 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-32) org.jboss.jms.server.connectionfactory.ConnectionFactory at 21fdb35f undeployed
> 2013-09-07 21:29:11,216 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-32) org.jboss.jms.server.connectionfactory.ConnectionFactory at 443578f2 undeployed
> 2013-09-07 21:29:11,235 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-32) org.jboss.jms.server.connectionfactory.ConnectionFactory at ecdede5 undeployed
> 2013-09-07 21:29:11,298 ERROR [org.jgroups.blocks.ConnectionTable] (OOB-43,192.168.56.102:7900) failed sending data to 192.168.56.101:7900: java.net.SocketException: Socket closed
> 2013-09-07 21:29:14,413 WARN  [org.jgroups.protocols.pbcast.NAKACK] (OOB-19,192.168.56.102:55200) 192.168.56.102:55200] discarded message from non-member 192.168.56.101:55200, my view is [192.168.56.102
> 2013-09-07 21:29:14,863 WARN  [org.jgroups.protocols.pbcast.NAKACK] (OOB-19,192.168.56.102:55200) 192.168.56.102:55200] discarded message from non-member 192.168.56.101:55200, my view is [192.168.56.102
> 2013-09-07 21:29:21,080 INFO  [org.jboss.jms.server.ServerPeer] (Thread-32) JMS ServerPeer[102] stopped
> 2013-09-07 21:29:21,090 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-32) JBM node is stopped.
> 2013-09-07 21:29:21,090 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] (Incoming-2,192.168.56.102:55200) Dead members: 1 ([192.168.56.101:55200])
> 2013-09-07 21:29:21,090 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] (Incoming-2,192.168.56.102:55200) All Members : 1 ([192.168.56.102:55200])
> 2013-09-07 21:30:24,666 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Restarting JBM node...
> 2013-09-07 21:30:33,369 INFO  [org.jboss.jms.server.ServerPeer] (Thread-75) JBoss Messaging 1.4.8.SP9 server [102] started
> 2013-09-07 21:30:33,459 INFO  [STDOUT] (Thread-75) 
> ---------------------------------------------------------
> GMS: address is 192.168.56.102:55200 (cluster=DefaultPartition-JMS-CTRL)
> ---------------------------------------------------------
> 2013-09-07 21:30:33,524 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] (Thread-75) org.jboss.messaging.core.impl.postoffice.GroupMember$ControlMembershipListener at 6a500238 got new view [192
> 2013-09-07 21:30:33,525 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] (Thread-75) I am (192.168.56.102:55200)
> 2013-09-07 21:30:33,525 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] (Thread-75) New Members : 2 ([192.168.56.101:55200, 192.168.56.102:55200])
> 2013-09-07 21:30:33,525 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] (Thread-75) All Members : 2 ([192.168.56.101:55200, 192.168.56.102:55200])
> 2013-09-07 21:30:33,570 INFO  [STDOUT] (pool-151-thread-1) 
> ---------------------------------------------------------
> GMS: address is 192.168.56.102:7900 (cluster=DefaultPartition-JMS-DATA)
> ---------------------------------------------------------
> 2013-09-07 21:30:33,779 INFO  [org.jboss.messaging.core.impl.postoffice.MessagingPostOffice] (Thread-75) Waiting for JGroups...
> 2013-09-07 21:30:33,784 INFO  [org.jboss.messaging.core.impl.postoffice.MessagingPostOffice] (Thread-75) JGroups starts to work again, initializing state
> 2013-09-07 21:30:33,785 INFO  [org.jboss.messaging.core.impl.postoffice.MessagingPostOffice] (Thread-75) Now node is ready for work.
> 2013-09-07 21:30:34,896 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) Connector sslbisocket://192.168.56.102:4459 has leasing enabled, lease period 25000 milliseconds
> 2013-09-07 21:30:34,896 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered connection factory jboss.messaging.connectionfactory:service=SSLConnectionFactory
> 2013-09-07 21:30:34,896 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) org.jboss.jms.server.connectionfactory.ConnectionFactory at 366480d7 started
> 2013-09-07 21:30:36,797 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) Connector bisocket://192.168.56.102:4457 has leasing enabled, lease period 25000 milliseconds
> 2013-09-07 21:30:36,797 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered connection factory jboss.messaging.connectionfactory:service=ConnectionFactory
> 2013-09-07 21:30:36,797 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) org.jboss.jms.server.connectionfactory.ConnectionFactory at 467463b3 started
> 2013-09-07 21:30:37,207 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) Connector servlet://192.168.56.102:8080 has leasing enabled, lease period 25000 milliseconds
> 2013-09-07 21:30:37,207 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered connection factory jboss.messaging.connectionfactory:service=ServletConnectionFactory
> 2013-09-07 21:30:37,207 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) org.jboss.jms.server.connectionfactory.ConnectionFactory at 21fdb35f started
> 2013-09-07 21:30:37,440 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) Connector bisocket://192.168.56.102:4457 has leasing enabled, lease period 25000 milliseconds
> 2013-09-07 21:30:37,441 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered connection factory jboss.messaging.connectionfactory:service=ClusteredConnectionFactory
> 2013-09-07 21:30:37,441 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) org.jboss.jms.server.connectionfactory.ConnectionFactory at 443578f2 started
> 2013-09-07 21:30:41,483 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) Connector bisocket://192.168.56.102:4457 has leasing enabled, lease period 25000 milliseconds
> 2013-09-07 21:30:41,483 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered connection factory jboss.messaging.connectionfactory:service=ClusterPullConnectionFactory
> 2013-09-07 21:30:41,483 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) org.jboss.jms.server.connectionfactory.ConnectionFactory at ecdede5 started
> 2013-09-07 21:30:41,483 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered destination jboss.messaging.destination:service=Queue,name=ExpiryQueue
> 2013-09-07 21:30:41,715 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-75) Queue[/queue/ExpiryQueue] started, fullSize=200000, pageSize=2000, downCacheSize=2000
> 2013-09-07 21:30:41,715 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered destination jboss.messaging.destination:service=Queue,name=DLQ
> 2013-09-07 21:30:42,259 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-75) Queue[/queue/DLQ] started, fullSize=200000, pageSize=2000, downCacheSize=2000
> 2013-09-07 21:30:42,259 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered destination jboss.messaging.destination:service=Queue,name=ISXO_AuditLogQueue_01
> 2013-09-07 21:30:42,495 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-75) Queue[/ISXO/AuditLogQueue, name=ISXO_AuditLogQueue_01] started, fullSize=200000, pageSize=2000, downCacheSize=20
> 2013-09-07 21:30:42,495 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered destination jboss.messaging.destination:service=Queue,name=ISXO_CiscoUCSEventQueue_01
> 2013-09-07 21:30:42,923 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-75) Queue[/ISXO/CiscoUCSEventQueue, name=ISXO_CiscoUCSEventQueue_01] started, fullSize=200000, pageSize=2000, downCa
> 2013-09-07 21:30:42,923 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered destination jboss.messaging.destination:service=Topic,name=ISXO_RemoteEventQueue_01
> 2013-09-07 21:30:43,122 INFO  [org.jboss.jms.server.destination.TopicService] (Thread-75) Topic[/ISXO/RemoteEventTopic, name=ISXO_RemoteEventQueue_01] started, fullSize=200000, pageSize=2000, downCacheS
> 2013-09-07 21:30:43,122 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered destination jboss.messaging.destination:service=Queue,name=ISXO_ScheduledJobQueue_01
> 2013-09-07 21:30:43,559 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-75) Queue[/ISXO/ScheduledJobQueue, name=ISXO_ScheduledJobQueue_01] started, fullSize=200000, pageSize=2000, downCach
> 2013-09-07 21:30:43,559 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) JBM node restarted.
> Stack trace the ?java.lang.IllegalStateException: Destination queue.ISXO_AuditLogQueue_01 not active?
> Daemon Thread [ISXOSchedulerPrioritized_Worker-1] (Suspended (breakpoint at line 3046 in MessagingPostOffice))	
> 	owns: AtomicAction  (id=519)	
> 	MessagingPostOffice.routeInternal(MessageReference, Condition, Transaction, boolean, Set) line: 3046	
> 	MessagingPostOffice.route(MessageReference, Condition, Transaction) line: 983	
> 	ServerConnectionEndpoint.sendMessage(JBossMessage, Transaction, boolean) line: 796	
> 	ServerConnectionEndpoint.processTransaction(ClientTransaction, Transaction, boolean) line: 852	
> 	ServerConnectionEndpoint.sendTransaction(TransactionRequest, boolean) line: 516	
> 	ConnectionAdvised.org$jboss$jms$server$endpoint$advised$ConnectionAdvised$sendTransaction$aop(TransactionRequest, boolean) line: 106	
> 	ConnectionAdvised$sendTransaction_N3268650789275322226.invokeTarget() line: not available	
> 	ConnectionAdvised$sendTransaction_N3268650789275322226(MethodInvocation).invokeNext() line: 111	
> 	SecurityAspect.handleSendTransaction(Invocation) line: 200	
> 	NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]	
> 	NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39	
> 	DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25	
> 	Method.invoke(Object, Object...) line: 597	
> 	PerInstanceAdvice.invoke(Invocation) line: 122	
> 	ConnectionAdvised$sendTransaction_N3268650789275322226(MethodInvocation).invokeNext() line: 102	
> 	ServerLogInterceptor.invoke(Invocation) line: 105	
> 	ConnectionAdvised$sendTransaction_N3268650789275322226(MethodInvocation).invokeNext() line: 102	
> 	ConnectionAdvised.sendTransaction(TransactionRequest, boolean) line: not available	
> 	ConnectionSendTransactionRequest.serverInvoke() line: 86	
> 	JMSServerInvocationHandler.invoke(InvocationRequest) line: 165	
> 	BisocketServerInvoker(ServerInvoker).invoke(InvocationRequest) line: 930	
> 	LocalClientInvoker.invoke(InvocationRequest) line: 106	
> 	Client.invoke(Object, Map, InvokerLocator) line: 2034	
> 	Client.invoke(Object, Map) line: 877	
> 	Client.invoke(Object) line: 865	
> 	ClientConnectionDelegate(DelegateSupport).doInvoke(Client, RequestSupport, boolean) line: 189	
> 	ClientConnectionDelegate(DelegateSupport).doInvoke(Client, RequestSupport) line: 160	
> 	ClientConnectionDelegate.org$jboss$jms$client$delegate$ClientConnectionDelegate$sendTransaction$aop(TransactionRequest, boolean) line: 241	
> 	ClientConnectionDelegate$sendTransaction_N3268650789275322226.invokeTarget() line: not available	
> 	ClientConnectionDelegate$sendTransaction_N3268650789275322226(MethodInvocation).invokeNext() line: 111	
> 	FailoverValveInterceptor.invoke(Invocation) line: 92	
> 	PerInstanceInterceptor.invoke(Invocation) line: 86	
> 	ClientConnectionDelegate$sendTransaction_N3268650789275322226(MethodInvocation).invokeNext() line: 102	
> 	ClosedInterceptor.invoke(Invocation) line: 172	
> 	PerInstanceInterceptor.invoke(Invocation) line: 86	
> 	ClientConnectionDelegate$sendTransaction_N3268650789275322226(MethodInvocation).invokeNext() line: 102	
> 	ClientConnectionDelegate.sendTransaction(TransactionRequest, boolean) line: not available	
> 	ResourceManager.sendTransactionXA(TransactionRequest, ConnectionDelegate) line: 712	
> 	ResourceManager.commit(Xid, boolean, ConnectionDelegate) line: 392	
> 	MessagingXAResource.commit(Xid, boolean) line: 275	
> 	JmsXAResource.commit(Xid, boolean) line: 98	
> 	XAResourceRecord.topLevelOnePhaseCommit() line: 811	
> 	AtomicAction(BasicAction).onePhaseCommit(boolean) line: 2656	
> 	AtomicAction(BasicAction).End(boolean) line: 1784	
> 	AtomicAction(TwoPhaseCoordinator).end(boolean) line: 94	
> 	AtomicAction(AtomicAction).commit(boolean) line: 160	
> 	TransactionImple.commitAndDisassociate() line: 1431	
> 	TransactionManagerImple(BaseTransaction).commit() line: 137	
> 	TransactionManagerDelegate(BaseTransactionManagerDelegate).commit() line: 75	
> 	Ejb3TxPolicy(TxPolicy).endTransaction(TransactionManager, Transaction) line: 170	
> 	Ejb3TxPolicy(TxPolicy).invokeInOurTx(Invocation, TransactionManager) line: 87	
> 	TxInterceptor$Required.invoke(Invocation) line: 190	
> 	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
> 	TxPropagationInterceptor.invoke(Invocation) line: 76	
> 	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
> 	NullInterceptor.invoke(Invocation) line: 42	
> 	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
> 	Ejb3AuthenticationInterceptorv2.invoke(Invocation) line: 182	
> 	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
> 	ENCPropagationInterceptor.invoke(Invocation) line: 41	
> 	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
> 	BlockContainerShutdownInterceptor.invoke(Invocation) line: 67	
> 	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
> 	CurrentInvocationContextInterceptor.invoke(Invocation) line: 47	
> 	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
> 	CurrentInvocationInterceptor.invoke(Invocation) line: 67	
> 	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
> 	EJB3TCCLInterceptor.invoke(Invocation) line: 86	
> 	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
> 	StatelessContainer(SessionSpecContainer).invoke(Serializable, SerializableMethod, Object[]) line: 193	
> 	StatelessContainer(SessionSpecContainer).invoke(Object, SerializableMethod, Object[]) line: 250	
> 	SessionLocalProxyInvocationHandler(SessionProxyInvocationHandlerBase).invoke(Object, Method, Object[]) line: 188	
> 	$Proxy702.publishMessages(EventSet) line: not available	
> 	NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]	
> 	NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39	
> 	DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25	
> 	Method.invoke(Object, Object...) line: 597	
> 	ClusteredEJB3InvokerJob(EJB3InvokerJob).invokeEjb(Object, JobExecutionContext) line: 196	
> 	ClusteredEJB3InvokerJob(EJB3InvokerJob).doExecute(JobExecutionContext) line: 141	
> 	ClusteredEJB3InvokerJob(EJB3InvokerJob).execute(JobExecutionContext) line: 78	
> 	JobRunShell.run() line: 203	
> 	SimpleThreadPool$WorkerThread.run() line: 520
> Update
> ========
> After debugging the code to understand what is going on I'm pretty sure we have situation where it use an old ServerConnectionEndpoint with a old postoffice instance. In our case we have a bean(stateless) that inject the TopicConnectionFactory and and Topic as resource this could possible reuse an old connection?
> I can see that sometimes it get an instance of ServerConnectionEndpoint which contains a reference to the current server peer and to the old post office. The server peer instance actual holde the reference to the new post office, but because the postoffice variable is only set on constructor level this is never changed. 
> Furthermore I can see the start method in ConnectionFactory was creating a listener that listens for failed connections, but this was not removed when the service stopped. After I removed the listener when the ConnectionFactory is stopped,  and restarted i'm able to receive updates again and it does not fail with a  "java.lang.IllegalStateException: Destination queue.MyQueue not active"

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Tue Oct  8 09:17:02 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Tue, 8 Oct 2013 09:17:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2258) Add sensitivities to the
 subsystem 'describe' operations
In-Reply-To: <JIRA.12502454.1381238107914@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502454.1381238107914@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502454.1381238107914.24367.1381238222743@jira02.app.mwc.hst.phx2.redhat.com>

Kabir Khan created WFLY-2258:
--------------------------------

             Summary: Add sensitivities to the subsystem 'describe' operations
                 Key: WFLY-2258
                 URL: https://issues.jboss.org/browse/WFLY-2258
             Project: WildFly
          Issue Type: Sub-task
          Components: Domain Management
            Reporter: Kabir Khan
            Assignee: Brian Stansberry
             Fix For: 8.0.0.CR1


THis can probably reuse the classification we used for read-config-as-xml

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 09:21:03 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 8 Oct 2013 09:21:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2257) Building JBoss EAP from
 sources causing hang and errors, no progress.
In-Reply-To: <JIRA.12502449.1381237429000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502449.1381237429000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502449.1381237429000.24428.1381238463324@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812061#comment-12812061 ] 

Tomaz Cerar commented on WFLY-2257:
-----------------------------------

What JBoss EAP console? when building you have only your console bash/cmd/powershell depending on your OS.
make sure you have proper JDK when building it, current requirement for JDK is oracle JDK7 as updated as possible (currently u40).

you can build it also without running tests by adding -DskipTests on the end of build command
                
> Building JBoss EAP from sources causing hang and errors, no progress.
> ---------------------------------------------------------------------
>
>                 Key: WFLY-2257
>                 URL: https://issues.jboss.org/browse/WFLY-2257
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Build System
>    Affects Versions: 8.0.0.Beta1
>            Reporter: prasad Kasthuri
>            Assignee: Paul Gier
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 09:23:02 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 8 Oct 2013 09:23:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2257) Building WildFly from sources
 causing hang and errors, no progress.
In-Reply-To: <JIRA.12502449.1381237429000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502449.1381237429000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502449.1381237429000.24437.1381238582960@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-2257:
------------------------------

    Summary: Building WildFly from sources causing hang and errors, no progress.  (was: Building JBoss EAP from sources causing hang and errors, no progress.)

    
> Building WildFly from sources causing hang and errors, no progress.
> -------------------------------------------------------------------
>
>                 Key: WFLY-2257
>                 URL: https://issues.jboss.org/browse/WFLY-2257
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Build System
>    Affects Versions: 8.0.0.Beta1
>            Reporter: prasad Kasthuri
>            Assignee: Paul Gier
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 09:25:03 2013
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Tue, 8 Oct 2013 09:25:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1948)
 java.lang.IllegalStateException: Destination queue.ISXO_AuditLogQueue_01
 not active after MessagingClusterHealthMBean restart JMS service
In-Reply-To: <JIRA.12502101.1380799169000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502101.1380799169000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502101.1380799169000.24478.1381238703911@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBMESSAGING-1948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812068#comment-12812068 ] 

Yong Hao Gao commented on JBMESSAGING-1948:
-------------------------------------------

Hi,

The patch seems fine but I need to run the test suite to make sure it doesn't break any tests before I bring the patch in. 

Thanks
Howard

                
> java.lang.IllegalStateException: Destination queue.ISXO_AuditLogQueue_01 not active after MessagingClusterHealthMBean restart JMS service
> -----------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1948
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1948
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.8.SP9
>            Reporter: Flemming Harms
>            Assignee: Yong Hao Gao
>         Attachments: ConnectionFactory-diff.patch, postoffice-patch.diff
>
>
> I get this error ?java.lang.IllegalStateException: Destination queue.ISXO_AuditLogQueue_01 not active? after MessagingClusterHealthMBean restarts the JMS service with JBoss Messaging 1.4.8.SP9. 
> I have 2 node JBoss5 cluster with JBoss Messaging and I have enabled the new failover model and setup the MessagingClusterHealthMBean to monitor split brain.
> I disconnect the cable from one of the servers MessagingClusterHealthMBean discover it?s alone and shut down the JMS service as expected. After a while I connect the server again and the server discover the other server and MessagingClusterHealthMBean starts the JMS service also as expected.
> But when I connect a client it fails with ?java.lang.IllegalStateException: Destination queue.ISXO_AuditLogQueue_01 not active? and what I can see in the debugger ServerConnectionEndpoint have reference to the old post office where the queue is still exits in the inactiveConditions Set.
> Log from the server when it discover it?s alone and it restart the service again
> 2013-09-07 21:29:06,381 ERROR [org.jboss.messaging.core.impl.postoffice.MessagingPostOffice] (Thread-32) I'm orphaned and now I can't tell others that I'm alive. Shutdown node: 102
> 2013-09-07 21:29:09,728 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-32) Stopping JBM node on DB failure...
> 2013-09-07 21:29:09,731 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-32) Queue[/queue/ExpiryQueue] stopped
> 2013-09-07 21:29:09,732 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-32) Queue[/queue/DLQ] stopped
> 2013-09-07 21:29:09,733 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-32) Queue[/ISXO/AuditLogQueue, name=ISXO_AuditLogQueue_01] stopped
> 2013-09-07 21:29:09,733 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-32) Queue[/ISXO/CiscoUCSEventQueue, name=ISXO_CiscoUCSEventQueue_01] stopped
> 2013-09-07 21:29:09,738 INFO  [org.jboss.jms.server.destination.TopicService] (Thread-32) Topic[/ISXO/RemoteEventTopic, name=ISXO_RemoteEventQueue_01] stopped
> 2013-09-07 21:29:09,739 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-32) Queue[/ISXO/ScheduledJobQueue, name=ISXO_ScheduledJobQueue_01] stopped
> 2013-09-07 21:29:11,210 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-32) org.jboss.jms.server.connectionfactory.ConnectionFactory at 366480d7 undeployed
> 2013-09-07 21:29:11,216 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-32) org.jboss.jms.server.connectionfactory.ConnectionFactory at 467463b3 undeployed
> 2013-09-07 21:29:11,216 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-32) org.jboss.jms.server.connectionfactory.ConnectionFactory at 21fdb35f undeployed
> 2013-09-07 21:29:11,216 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-32) org.jboss.jms.server.connectionfactory.ConnectionFactory at 443578f2 undeployed
> 2013-09-07 21:29:11,235 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-32) org.jboss.jms.server.connectionfactory.ConnectionFactory at ecdede5 undeployed
> 2013-09-07 21:29:11,298 ERROR [org.jgroups.blocks.ConnectionTable] (OOB-43,192.168.56.102:7900) failed sending data to 192.168.56.101:7900: java.net.SocketException: Socket closed
> 2013-09-07 21:29:14,413 WARN  [org.jgroups.protocols.pbcast.NAKACK] (OOB-19,192.168.56.102:55200) 192.168.56.102:55200] discarded message from non-member 192.168.56.101:55200, my view is [192.168.56.102
> 2013-09-07 21:29:14,863 WARN  [org.jgroups.protocols.pbcast.NAKACK] (OOB-19,192.168.56.102:55200) 192.168.56.102:55200] discarded message from non-member 192.168.56.101:55200, my view is [192.168.56.102
> 2013-09-07 21:29:21,080 INFO  [org.jboss.jms.server.ServerPeer] (Thread-32) JMS ServerPeer[102] stopped
> 2013-09-07 21:29:21,090 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-32) JBM node is stopped.
> 2013-09-07 21:29:21,090 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] (Incoming-2,192.168.56.102:55200) Dead members: 1 ([192.168.56.101:55200])
> 2013-09-07 21:29:21,090 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] (Incoming-2,192.168.56.102:55200) All Members : 1 ([192.168.56.102:55200])
> 2013-09-07 21:30:24,666 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Restarting JBM node...
> 2013-09-07 21:30:33,369 INFO  [org.jboss.jms.server.ServerPeer] (Thread-75) JBoss Messaging 1.4.8.SP9 server [102] started
> 2013-09-07 21:30:33,459 INFO  [STDOUT] (Thread-75) 
> ---------------------------------------------------------
> GMS: address is 192.168.56.102:55200 (cluster=DefaultPartition-JMS-CTRL)
> ---------------------------------------------------------
> 2013-09-07 21:30:33,524 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] (Thread-75) org.jboss.messaging.core.impl.postoffice.GroupMember$ControlMembershipListener at 6a500238 got new view [192
> 2013-09-07 21:30:33,525 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] (Thread-75) I am (192.168.56.102:55200)
> 2013-09-07 21:30:33,525 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] (Thread-75) New Members : 2 ([192.168.56.101:55200, 192.168.56.102:55200])
> 2013-09-07 21:30:33,525 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] (Thread-75) All Members : 2 ([192.168.56.101:55200, 192.168.56.102:55200])
> 2013-09-07 21:30:33,570 INFO  [STDOUT] (pool-151-thread-1) 
> ---------------------------------------------------------
> GMS: address is 192.168.56.102:7900 (cluster=DefaultPartition-JMS-DATA)
> ---------------------------------------------------------
> 2013-09-07 21:30:33,779 INFO  [org.jboss.messaging.core.impl.postoffice.MessagingPostOffice] (Thread-75) Waiting for JGroups...
> 2013-09-07 21:30:33,784 INFO  [org.jboss.messaging.core.impl.postoffice.MessagingPostOffice] (Thread-75) JGroups starts to work again, initializing state
> 2013-09-07 21:30:33,785 INFO  [org.jboss.messaging.core.impl.postoffice.MessagingPostOffice] (Thread-75) Now node is ready for work.
> 2013-09-07 21:30:34,896 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) Connector sslbisocket://192.168.56.102:4459 has leasing enabled, lease period 25000 milliseconds
> 2013-09-07 21:30:34,896 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered connection factory jboss.messaging.connectionfactory:service=SSLConnectionFactory
> 2013-09-07 21:30:34,896 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) org.jboss.jms.server.connectionfactory.ConnectionFactory at 366480d7 started
> 2013-09-07 21:30:36,797 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) Connector bisocket://192.168.56.102:4457 has leasing enabled, lease period 25000 milliseconds
> 2013-09-07 21:30:36,797 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered connection factory jboss.messaging.connectionfactory:service=ConnectionFactory
> 2013-09-07 21:30:36,797 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) org.jboss.jms.server.connectionfactory.ConnectionFactory at 467463b3 started
> 2013-09-07 21:30:37,207 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) Connector servlet://192.168.56.102:8080 has leasing enabled, lease period 25000 milliseconds
> 2013-09-07 21:30:37,207 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered connection factory jboss.messaging.connectionfactory:service=ServletConnectionFactory
> 2013-09-07 21:30:37,207 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) org.jboss.jms.server.connectionfactory.ConnectionFactory at 21fdb35f started
> 2013-09-07 21:30:37,440 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) Connector bisocket://192.168.56.102:4457 has leasing enabled, lease period 25000 milliseconds
> 2013-09-07 21:30:37,441 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered connection factory jboss.messaging.connectionfactory:service=ClusteredConnectionFactory
> 2013-09-07 21:30:37,441 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) org.jboss.jms.server.connectionfactory.ConnectionFactory at 443578f2 started
> 2013-09-07 21:30:41,483 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) Connector bisocket://192.168.56.102:4457 has leasing enabled, lease period 25000 milliseconds
> 2013-09-07 21:30:41,483 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered connection factory jboss.messaging.connectionfactory:service=ClusterPullConnectionFactory
> 2013-09-07 21:30:41,483 INFO  [org.jboss.jms.server.connectionfactory.ConnectionFactory] (Thread-75) org.jboss.jms.server.connectionfactory.ConnectionFactory at ecdede5 started
> 2013-09-07 21:30:41,483 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered destination jboss.messaging.destination:service=Queue,name=ExpiryQueue
> 2013-09-07 21:30:41,715 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-75) Queue[/queue/ExpiryQueue] started, fullSize=200000, pageSize=2000, downCacheSize=2000
> 2013-09-07 21:30:41,715 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered destination jboss.messaging.destination:service=Queue,name=DLQ
> 2013-09-07 21:30:42,259 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-75) Queue[/queue/DLQ] started, fullSize=200000, pageSize=2000, downCacheSize=2000
> 2013-09-07 21:30:42,259 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered destination jboss.messaging.destination:service=Queue,name=ISXO_AuditLogQueue_01
> 2013-09-07 21:30:42,495 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-75) Queue[/ISXO/AuditLogQueue, name=ISXO_AuditLogQueue_01] started, fullSize=200000, pageSize=2000, downCacheSize=20
> 2013-09-07 21:30:42,495 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered destination jboss.messaging.destination:service=Queue,name=ISXO_CiscoUCSEventQueue_01
> 2013-09-07 21:30:42,923 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-75) Queue[/ISXO/CiscoUCSEventQueue, name=ISXO_CiscoUCSEventQueue_01] started, fullSize=200000, pageSize=2000, downCa
> 2013-09-07 21:30:42,923 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered destination jboss.messaging.destination:service=Topic,name=ISXO_RemoteEventQueue_01
> 2013-09-07 21:30:43,122 INFO  [org.jboss.jms.server.destination.TopicService] (Thread-75) Topic[/ISXO/RemoteEventTopic, name=ISXO_RemoteEventQueue_01] started, fullSize=200000, pageSize=2000, downCacheS
> 2013-09-07 21:30:43,122 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) Registered destination jboss.messaging.destination:service=Queue,name=ISXO_ScheduledJobQueue_01
> 2013-09-07 21:30:43,559 INFO  [org.jboss.jms.server.destination.QueueService] (Thread-75) Queue[/ISXO/ScheduledJobQueue, name=ISXO_ScheduledJobQueue_01] started, fullSize=200000, pageSize=2000, downCach
> 2013-09-07 21:30:43,559 INFO  [org.jboss.jms.server.MessagingClusterHealthMBean] (Thread-75) JBM node restarted.
> Stack trace the ?java.lang.IllegalStateException: Destination queue.ISXO_AuditLogQueue_01 not active?
> Daemon Thread [ISXOSchedulerPrioritized_Worker-1] (Suspended (breakpoint at line 3046 in MessagingPostOffice))	
> 	owns: AtomicAction  (id=519)	
> 	MessagingPostOffice.routeInternal(MessageReference, Condition, Transaction, boolean, Set) line: 3046	
> 	MessagingPostOffice.route(MessageReference, Condition, Transaction) line: 983	
> 	ServerConnectionEndpoint.sendMessage(JBossMessage, Transaction, boolean) line: 796	
> 	ServerConnectionEndpoint.processTransaction(ClientTransaction, Transaction, boolean) line: 852	
> 	ServerConnectionEndpoint.sendTransaction(TransactionRequest, boolean) line: 516	
> 	ConnectionAdvised.org$jboss$jms$server$endpoint$advised$ConnectionAdvised$sendTransaction$aop(TransactionRequest, boolean) line: 106	
> 	ConnectionAdvised$sendTransaction_N3268650789275322226.invokeTarget() line: not available	
> 	ConnectionAdvised$sendTransaction_N3268650789275322226(MethodInvocation).invokeNext() line: 111	
> 	SecurityAspect.handleSendTransaction(Invocation) line: 200	
> 	NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]	
> 	NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39	
> 	DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25	
> 	Method.invoke(Object, Object...) line: 597	
> 	PerInstanceAdvice.invoke(Invocation) line: 122	
> 	ConnectionAdvised$sendTransaction_N3268650789275322226(MethodInvocation).invokeNext() line: 102	
> 	ServerLogInterceptor.invoke(Invocation) line: 105	
> 	ConnectionAdvised$sendTransaction_N3268650789275322226(MethodInvocation).invokeNext() line: 102	
> 	ConnectionAdvised.sendTransaction(TransactionRequest, boolean) line: not available	
> 	ConnectionSendTransactionRequest.serverInvoke() line: 86	
> 	JMSServerInvocationHandler.invoke(InvocationRequest) line: 165	
> 	BisocketServerInvoker(ServerInvoker).invoke(InvocationRequest) line: 930	
> 	LocalClientInvoker.invoke(InvocationRequest) line: 106	
> 	Client.invoke(Object, Map, InvokerLocator) line: 2034	
> 	Client.invoke(Object, Map) line: 877	
> 	Client.invoke(Object) line: 865	
> 	ClientConnectionDelegate(DelegateSupport).doInvoke(Client, RequestSupport, boolean) line: 189	
> 	ClientConnectionDelegate(DelegateSupport).doInvoke(Client, RequestSupport) line: 160	
> 	ClientConnectionDelegate.org$jboss$jms$client$delegate$ClientConnectionDelegate$sendTransaction$aop(TransactionRequest, boolean) line: 241	
> 	ClientConnectionDelegate$sendTransaction_N3268650789275322226.invokeTarget() line: not available	
> 	ClientConnectionDelegate$sendTransaction_N3268650789275322226(MethodInvocation).invokeNext() line: 111	
> 	FailoverValveInterceptor.invoke(Invocation) line: 92	
> 	PerInstanceInterceptor.invoke(Invocation) line: 86	
> 	ClientConnectionDelegate$sendTransaction_N3268650789275322226(MethodInvocation).invokeNext() line: 102	
> 	ClosedInterceptor.invoke(Invocation) line: 172	
> 	PerInstanceInterceptor.invoke(Invocation) line: 86	
> 	ClientConnectionDelegate$sendTransaction_N3268650789275322226(MethodInvocation).invokeNext() line: 102	
> 	ClientConnectionDelegate.sendTransaction(TransactionRequest, boolean) line: not available	
> 	ResourceManager.sendTransactionXA(TransactionRequest, ConnectionDelegate) line: 712	
> 	ResourceManager.commit(Xid, boolean, ConnectionDelegate) line: 392	
> 	MessagingXAResource.commit(Xid, boolean) line: 275	
> 	JmsXAResource.commit(Xid, boolean) line: 98	
> 	XAResourceRecord.topLevelOnePhaseCommit() line: 811	
> 	AtomicAction(BasicAction).onePhaseCommit(boolean) line: 2656	
> 	AtomicAction(BasicAction).End(boolean) line: 1784	
> 	AtomicAction(TwoPhaseCoordinator).end(boolean) line: 94	
> 	AtomicAction(AtomicAction).commit(boolean) line: 160	
> 	TransactionImple.commitAndDisassociate() line: 1431	
> 	TransactionManagerImple(BaseTransaction).commit() line: 137	
> 	TransactionManagerDelegate(BaseTransactionManagerDelegate).commit() line: 75	
> 	Ejb3TxPolicy(TxPolicy).endTransaction(TransactionManager, Transaction) line: 170	
> 	Ejb3TxPolicy(TxPolicy).invokeInOurTx(Invocation, TransactionManager) line: 87	
> 	TxInterceptor$Required.invoke(Invocation) line: 190	
> 	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
> 	TxPropagationInterceptor.invoke(Invocation) line: 76	
> 	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
> 	NullInterceptor.invoke(Invocation) line: 42	
> 	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
> 	Ejb3AuthenticationInterceptorv2.invoke(Invocation) line: 182	
> 	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
> 	ENCPropagationInterceptor.invoke(Invocation) line: 41	
> 	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
> 	BlockContainerShutdownInterceptor.invoke(Invocation) line: 67	
> 	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
> 	CurrentInvocationContextInterceptor.invoke(Invocation) line: 47	
> 	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
> 	CurrentInvocationInterceptor.invoke(Invocation) line: 67	
> 	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
> 	EJB3TCCLInterceptor.invoke(Invocation) line: 86	
> 	StatefulContainerInvocation(MethodInvocation).invokeNext() line: 102	
> 	StatelessContainer(SessionSpecContainer).invoke(Serializable, SerializableMethod, Object[]) line: 193	
> 	StatelessContainer(SessionSpecContainer).invoke(Object, SerializableMethod, Object[]) line: 250	
> 	SessionLocalProxyInvocationHandler(SessionProxyInvocationHandlerBase).invoke(Object, Method, Object[]) line: 188	
> 	$Proxy702.publishMessages(EventSet) line: not available	
> 	NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]	
> 	NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39	
> 	DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25	
> 	Method.invoke(Object, Object...) line: 597	
> 	ClusteredEJB3InvokerJob(EJB3InvokerJob).invokeEjb(Object, JobExecutionContext) line: 196	
> 	ClusteredEJB3InvokerJob(EJB3InvokerJob).doExecute(JobExecutionContext) line: 141	
> 	ClusteredEJB3InvokerJob(EJB3InvokerJob).execute(JobExecutionContext) line: 78	
> 	JobRunShell.run() line: 203	
> 	SimpleThreadPool$WorkerThread.run() line: 520
> Update
> ========
> After debugging the code to understand what is going on I'm pretty sure we have situation where it use an old ServerConnectionEndpoint with a old postoffice instance. In our case we have a bean(stateless) that inject the TopicConnectionFactory and and Topic as resource this could possible reuse an old connection?
> I can see that sometimes it get an instance of ServerConnectionEndpoint which contains a reference to the current server peer and to the old post office. The server peer instance actual holde the reference to the new post office, but because the postoffice variable is only set on constructor level this is never changed. 
> Furthermore I can see the start method in ConnectionFactory was creating a listener that listens for failed connections, but this was not removed when the service stopped. After I removed the listener when the ConnectionFactory is stopped,  and restarted i'm able to receive updates again and it does not fail with a  "java.lang.IllegalStateException: Destination queue.MyQueue not active"

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Tue Oct  8 09:45:04 2013
From: jira-events at lists.jboss.org (prasad Kasthuri (JIRA))
Date: Tue, 8 Oct 2013 09:45:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2257) Building WildFly from sources
 causing hang and errors, no progress.
In-Reply-To: <JIRA.12502449.1381237429000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502449.1381237429000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502449.1381237429000.24570.1381239904445@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812090#comment-12812090 ] 

prasad Kasthuri commented on WFLY-2257:
---------------------------------------

Let me try with Latest update of Oracle JDK 7 and come back to you. Thanks a ton for the reply.
                
> Building WildFly from sources causing hang and errors, no progress.
> -------------------------------------------------------------------
>
>                 Key: WFLY-2257
>                 URL: https://issues.jboss.org/browse/WFLY-2257
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Build System
>    Affects Versions: 8.0.0.Beta1
>            Reporter: prasad Kasthuri
>            Assignee: Paul Gier
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 09:53:03 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Tue, 8 Oct 2013 09:53:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2258) Add sensitivities to the
 subsystem 'describe' operations
In-Reply-To: <JIRA.12502454.1381238107000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502454.1381238107000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502454.1381238107000.24609.1381240383109@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812099#comment-12812099 ] 

Kabir Khan commented on WFLY-2258:
----------------------------------

Adding it to GenericSubsystemDescribeHandler.DEFINITION is a start, but we also need to make sure that it gets the relevant permissions if someone registers a custom handler. Perhaps a check for the name in the ConcreteResourceRegistration.registerOperationHandler() methods?
                
> Add sensitivities to the subsystem 'describe' operations
> --------------------------------------------------------
>
>                 Key: WFLY-2258
>                 URL: https://issues.jboss.org/browse/WFLY-2258
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> THis can probably reuse the classification we used for read-config-as-xml

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 10:05:03 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 8 Oct 2013 10:05:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1547) deploy directories not
	cleaned up
In-Reply-To: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479851.1353935247000.24690.1381241103626@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-1547:
------------------------------

    Comment: was deleted

(was: A comment with security level 'JBoss Employee' was removed.)

    
> deploy directories not cleaned up
> ---------------------------------
>
>                 Key: WFLY-1547
>                 URL: https://issues.jboss.org/browse/WFLY-1547
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Shaun Appleton
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Beta1
>
>         Attachments: deployment_with_hack_no_hook.txt
>
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 10:05:04 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 8 Oct 2013 10:05:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1547) deploy directories not
	cleaned up
In-Reply-To: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479851.1353935247000.24704.1381241104332@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-1547:
------------------------------

    Comment: was deleted

(was: A comment with security level 'JBoss Employee' was removed.)

    
> deploy directories not cleaned up
> ---------------------------------
>
>                 Key: WFLY-1547
>                 URL: https://issues.jboss.org/browse/WFLY-1547
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Shaun Appleton
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Beta1
>
>         Attachments: deployment_with_hack_no_hook.txt
>
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 10:05:05 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 8 Oct 2013 10:05:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1547) deploy directories not
	cleaned up
In-Reply-To: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479851.1353935247000.24718.1381241105132@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-1547:
------------------------------

    Comment: was deleted

(was: A comment with security level 'JBoss Employee' was removed.)

    
> deploy directories not cleaned up
> ---------------------------------
>
>                 Key: WFLY-1547
>                 URL: https://issues.jboss.org/browse/WFLY-1547
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Shaun Appleton
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Beta1
>
>         Attachments: deployment_with_hack_no_hook.txt
>
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 10:05:05 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 8 Oct 2013 10:05:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1547) deploy directories not
	cleaned up
In-Reply-To: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479851.1353935247000.24732.1381241105753@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-1547:
------------------------------

    Comment: was deleted

(was: A comment with security level 'JBoss Employee' was removed.)

    
> deploy directories not cleaned up
> ---------------------------------
>
>                 Key: WFLY-1547
>                 URL: https://issues.jboss.org/browse/WFLY-1547
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Shaun Appleton
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Beta1
>
>         Attachments: deployment_with_hack_no_hook.txt
>
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 10:07:03 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 8 Oct 2013 10:07:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1547) deploy directories not
	cleaned up
In-Reply-To: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479851.1353935247000.24776.1381241223701@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-1547:
------------------------------

    Comment: was deleted

(was: A comment with security level 'JBoss Employee' was removed.)

    
> deploy directories not cleaned up
> ---------------------------------
>
>                 Key: WFLY-1547
>                 URL: https://issues.jboss.org/browse/WFLY-1547
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Shaun Appleton
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Beta1
>
>         Attachments: deployment_with_hack_no_hook.txt
>
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 10:07:04 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 8 Oct 2013 10:07:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1547) deploy directories not
	cleaned up
In-Reply-To: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479851.1353935247000.24797.1381241224934@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-1547:
------------------------------

    Comment: was deleted

(was: A comment with security level 'JBoss Employee' was removed.)

    
> deploy directories not cleaned up
> ---------------------------------
>
>                 Key: WFLY-1547
>                 URL: https://issues.jboss.org/browse/WFLY-1547
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Shaun Appleton
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Beta1
>
>         Attachments: deployment_with_hack_no_hook.txt
>
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 10:07:05 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 8 Oct 2013 10:07:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1547) deploy directories not
	cleaned up
In-Reply-To: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479851.1353935247000.24811.1381241225537@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-1547:
------------------------------

    Comment: was deleted

(was: Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1004383|https://bugzilla.redhat.com/show_bug.cgi?id=1004383] from NEW to MODIFIED)

    
> deploy directories not cleaned up
> ---------------------------------
>
>                 Key: WFLY-1547
>                 URL: https://issues.jboss.org/browse/WFLY-1547
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Shaun Appleton
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Beta1
>
>         Attachments: deployment_with_hack_no_hook.txt
>
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 10:07:06 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 8 Oct 2013 10:07:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1547) deploy directories not
	cleaned up
In-Reply-To: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479851.1353935247000.24827.1381241226101@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-1547:
------------------------------

    Comment: was deleted

(was: Paul Gier <pgier at redhat.com> changed the Status of [bug 1004383|https://bugzilla.redhat.com/show_bug.cgi?id=1004383] from MODIFIED to ON_QA)

    
> deploy directories not cleaned up
> ---------------------------------
>
>                 Key: WFLY-1547
>                 URL: https://issues.jboss.org/browse/WFLY-1547
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Shaun Appleton
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Beta1
>
>         Attachments: deployment_with_hack_no_hook.txt
>
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 10:23:02 2013
From: jira-events at lists.jboss.org (Radoslav Husar (JIRA))
Date: Tue, 8 Oct 2013 10:23:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2171) Use deployment unit
 processors to register mod_cluster metrics
In-Reply-To: <JIRA.12501718.1380276630000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501718.1380276630000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501718.1380276630000.24988.1381242182856@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-2171:
---------------------------------

    Priority: Blocker  (was: Critical)


Making this blocker, this really needs to get in ASAP.
                
> Use deployment unit processors to register mod_cluster metrics
> --------------------------------------------------------------
>
>                 Key: WFLY-2171
>                 URL: https://issues.jboss.org/browse/WFLY-2171
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>            Priority: Blocker
>             Fix For: 8.0.0.CR1
>
>
> Remove static dependency and make it runtime using DUPs.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 10:25:02 2013
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Tue, 8 Oct 2013 10:25:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1740) ManagedSocketBinding class
 Impossible cast from java.net.InetAddress to java.net.InetSocketAddress
In-Reply-To: <JIRA.12497092.1374526330000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497092.1374526330000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497092.1374526330000.25002.1381242302982@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emanuel Muckenhuber resolved WFLY-1740.
---------------------------------------

    Fix Version/s: 8.0.0.CR1
       Resolution: Done

    
> ManagedSocketBinding class Impossible cast from java.net.InetAddress to java.net.InetSocketAddress
> --------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1740
>                 URL: https://issues.jboss.org/browse/WFLY-1740
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Cheng Fang
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.CR1
>
>
> Reported by FindBugs:
> Impossible cast from java.net.InetAddress to java.net.InetSocketAddress
> Class:
> ManagedSocketBinding (org.jboss.as.network) line 55
> Method:
> getBindAddress (org.jboss.as.network.ManagedSocketBinding.getBindAddress())
> Priority:
> ? ? ?High Confidence Correctness
> ?
> Problem classification:
> Correctness (Bad casts of object references)
> BC_IMPOSSIBLE_CAST (Impossible cast)
> Notes:
> Actual type java.net.InetAddress
> Expected java.net.InetSocketAddress
> Return value of Class.cast(Object)
> FindBadCast2 (BC|NP)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Tue Oct  8 10:35:05 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 8 Oct 2013 10:35:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2160) Allow Expression for
 datasource subsystem enabled property
In-Reply-To: <JIRA.12501556.1380149025000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501556.1380149025000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501556.1380149025000.25083.1381242905255@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-2160:
------------------------------

    Fix Version/s: 8.0.0.CR1

    
> Allow Expression for datasource subsystem enabled property
> ----------------------------------------------------------
>
>                 Key: WFLY-2160
>                 URL: https://issues.jboss.org/browse/WFLY-2160
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, JCA
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Steven Rose
>            Assignee: Tomaz Cerar
>            Priority: Minor
>              Labels: wildfly
>             Fix For: 8.0.0.CR1
>
>
> Currently the datasource sub system does not allow expressions. I would like to be able to do this: <datasource jta="true" jndi-name="java:/ds1DS" pool-name="ds1DS" enabled="${ds1.enabled}" use-java-context="true" use-ccm="true"> and set the ds1.enabled property via a properties file.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 10:37:02 2013
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Tue, 8 Oct 2013 10:37:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2209) short versions of command
 arguments (e.g. -h) are not recognized
In-Reply-To: <JIRA.12502091.1380796517000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502091.1380796517000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502091.1380796517000.25102.1381243022826@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky resolved WFLY-2209.
-------------------------------------

    Fix Version/s: 8.0.0.CR1
       Resolution: Done


Fixed.
                
> short versions of command arguments (e.g. -h) are not recognized
> ----------------------------------------------------------------
>
>                 Key: WFLY-2209
>                 URL: https://issues.jboss.org/browse/WFLY-2209
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.0.CR1
>
>
> The validation of command arguments doesn't take into account their short versions leading rejecting the command in case the short versions are used (e.g. -h for --help).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 10:39:02 2013
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Tue, 8 Oct 2013 10:39:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2209) short versions of command
 arguments (e.g. -h) are not recognized
In-Reply-To: <JIRA.12502091.1380796517000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502091.1380796517000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502091.1380796517000.25114.1381243142758@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky updated WFLY-2209:
------------------------------------

    Git Pull Request: https://github.com/wildfly/wildfly/pull/5210

    
> short versions of command arguments (e.g. -h) are not recognized
> ----------------------------------------------------------------
>
>                 Key: WFLY-2209
>                 URL: https://issues.jboss.org/browse/WFLY-2209
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.0.CR1
>
>
> The validation of command arguments doesn't take into account their short versions leading rejecting the command in case the short versions are used (e.g. -h for --help).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 10:39:03 2013
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Tue, 8 Oct 2013 10:39:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2067) Ability to get result data
 from CLI batches
In-Reply-To: <JIRA.12500684.1379078996000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500684.1379078996000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500684.1379078996000.25126.1381243143471@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky updated WFLY-2067:
------------------------------------

    Forum Reference: https://github.com/wildfly/wildfly/pull/5210

    
> Ability to get result data from CLI batches
> -------------------------------------------
>
>                 Key: WFLY-2067
>                 URL: https://issues.jboss.org/browse/WFLY-2067
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: CLI
>            Reporter: Brian Stansberry
>            Assignee: Alexey Loubyansky
>
> The CLI batch feature doesn't provide any details on the result other than success or failure. This is appropriate for some use cases, but isn't for others, e.g. https://gist.github.com/heiko-braun/6550656
> It would be nice to give users the ability to request the full result output, e.g. something like 
> run-batch --verbose

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 10:49:02 2013
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Tue, 8 Oct 2013 10:49:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2067) Ability to get result data
 from CLI batches
In-Reply-To: <JIRA.12500684.1379078996000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500684.1379078996000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500684.1379078996000.25204.1381243742875@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky resolved WFLY-2067.
-------------------------------------

    Fix Version/s: 8.0.0.CR1
       Resolution: Done


Fixed. --verbose has been added and for most of the commands the response headers are printed if they are present in the operation result.
                
> Ability to get result data from CLI batches
> -------------------------------------------
>
>                 Key: WFLY-2067
>                 URL: https://issues.jboss.org/browse/WFLY-2067
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: CLI
>            Reporter: Brian Stansberry
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.0.CR1
>
>
> The CLI batch feature doesn't provide any details on the result other than success or failure. This is appropriate for some use cases, but isn't for others, e.g. https://gist.github.com/heiko-braun/6550656
> It would be nice to give users the ability to request the full result output, e.g. something like 
> run-batch --verbose

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 10:51:02 2013
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Tue, 8 Oct 2013 10:51:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2023) review output of jboss-cli
	for batches
In-Reply-To: <JIRA.12500245.1378496753000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500245.1378496753000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500245.1378496753000.25213.1381243862787@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky resolved WFLY-2023.
-------------------------------------

    Fix Version/s: 8.0.0.CR1
       Resolution: Done


The line printing after Enter has been removed.
                
> review output of jboss-cli for batches
> --------------------------------------
>
>                 Key: WFLY-2023
>                 URL: https://issues.jboss.org/browse/WFLY-2023
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Frank Langelage
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.0.CR1
>
>
> jboss-cli displays lines of input file, although they are not executed.
> If not executed hey should not be printed.
> It might be useful to introduce a command line option "--verbose" an to print everything to stdout, if / command / end-if. Maybe even the output of the commands executed (read-resource, add).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 10:51:02 2013
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Tue, 8 Oct 2013 10:51:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2023) review output of jboss-cli
	for batches
In-Reply-To: <JIRA.12500245.1378496753000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500245.1378496753000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500245.1378496753000.25216.1381243862978@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky updated WFLY-2023:
------------------------------------

    Git Pull Request: https://github.com/wildfly/wildfly/pull/5210

    
> review output of jboss-cli for batches
> --------------------------------------
>
>                 Key: WFLY-2023
>                 URL: https://issues.jboss.org/browse/WFLY-2023
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Frank Langelage
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.0.CR1
>
>
> jboss-cli displays lines of input file, although they are not executed.
> If not executed hey should not be printed.
> It might be useful to introduce a command line option "--verbose" an to print everything to stdout, if / command / end-if. Maybe even the output of the commands executed (read-resource, add).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 10:51:03 2013
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Tue, 8 Oct 2013 10:51:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2204) runtime exceptions thrown
 during parsing crash cli sessions
In-Reply-To: <JIRA.12502024.1380726912000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502024.1380726912000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502024.1380726912000.25218.1381243863103@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky updated WFLY-2204:
------------------------------------

    Git Pull Request: https://github.com/wildfly/wildfly/pull/5210

    
> runtime exceptions thrown during parsing crash cli sessions
> -----------------------------------------------------------
>
>                 Key: WFLY-2204
>                 URL: https://issues.jboss.org/browse/WFLY-2204
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>
> Runtime exceptions thrown during command line parsing crash CLI sessions.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 10:53:02 2013
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Tue, 8 Oct 2013 10:53:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2204) runtime exceptions thrown
 during parsing crash cli sessions
In-Reply-To: <JIRA.12502024.1380726912000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502024.1380726912000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502024.1380726912000.25225.1381243982739@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky resolved WFLY-2204.
-------------------------------------

    Fix Version/s: 8.0.0.CR1
       Resolution: Done


Fixed.
                
> runtime exceptions thrown during parsing crash cli sessions
> -----------------------------------------------------------
>
>                 Key: WFLY-2204
>                 URL: https://issues.jboss.org/browse/WFLY-2204
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.0.CR1
>
>
> Runtime exceptions thrown during command line parsing crash CLI sessions.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 10:55:02 2013
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Tue, 8 Oct 2013 10:55:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2051) CLI write attribute dialog
 for string value should enclose value in generated command to double quotes
In-Reply-To: <JIRA.12500587.1378980513000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500587.1378980513000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500587.1378980513000.25235.1381244102994@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky updated WFLY-2051:
------------------------------------

    Git Pull Request: https://github.com/wildfly/wildfly/pull/5210

    
> CLI write attribute dialog for string value should enclose value in generated command to double quotes
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2051
>                 URL: https://issues.jboss.org/browse/WFLY-2051
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Chao Wang
>            Assignee: Alexey Loubyansky
>
> {noformat}
> Wildfly issue for https://bugzilla.redhat.com/show_bug.cgi?id=988283
> String value entered in write attribute dialog is written to command without double quotes, which is wrong in many cases
> Eg. when user enteres in dialog value ${jboss.bind.address:127.0.0.1}
> following command is generated:
> /subsystem=webservices/:write-attribute(name=wsdl-host,value=${jboss.bind.address:127.0.0.1})
> Correctly should be generated command 
> /subsystem=webservices/:write-attribute(name=wsdl-host,value="${jboss.bind.address:127.0.0.1}")
> 1. start AS
>   ./bin/standalone.sh
> 2. start CLI GUI 
>   ./bin/jboss-cli.sh --gui &
> 3. click on node subsystem=webservices of /
> 4. right click on wsdl-host and select write-attribute
> 5. enter value ${jboss.bind.address:127.0.0.1} and click OK
> 6. submit generated command
> 7. reload node
>   click on node subsystem=webservices of / (close node)
>   click on node subsystem=webservices of / (open node)
> Result is wsdl-host=$ instead of wsdl-host=${jboss.bind.address:127.0.0.1}
> Workaround: in dialog box enclose the value in double quotes
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 10:55:03 2013
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Tue, 8 Oct 2013 10:55:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2051) CLI write attribute dialog
 for string value should enclose value in generated command to double quotes
In-Reply-To: <JIRA.12500587.1378980513000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500587.1378980513000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500587.1378980513000.25243.1381244103475@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky resolved WFLY-2051.
-------------------------------------

    Fix Version/s: 8.0.0.CR1
       Resolution: Done


Fixed.
                
> CLI write attribute dialog for string value should enclose value in generated command to double quotes
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2051
>                 URL: https://issues.jboss.org/browse/WFLY-2051
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Chao Wang
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.0.CR1
>
>
> {noformat}
> Wildfly issue for https://bugzilla.redhat.com/show_bug.cgi?id=988283
> String value entered in write attribute dialog is written to command without double quotes, which is wrong in many cases
> Eg. when user enteres in dialog value ${jboss.bind.address:127.0.0.1}
> following command is generated:
> /subsystem=webservices/:write-attribute(name=wsdl-host,value=${jboss.bind.address:127.0.0.1})
> Correctly should be generated command 
> /subsystem=webservices/:write-attribute(name=wsdl-host,value="${jboss.bind.address:127.0.0.1}")
> 1. start AS
>   ./bin/standalone.sh
> 2. start CLI GUI 
>   ./bin/jboss-cli.sh --gui &
> 3. click on node subsystem=webservices of /
> 4. right click on wsdl-host and select write-attribute
> 5. enter value ${jboss.bind.address:127.0.0.1} and click OK
> 6. submit generated command
> 7. reload node
>   click on node subsystem=webservices of / (close node)
>   click on node subsystem=webservices of / (open node)
> Result is wsdl-host=$ instead of wsdl-host=${jboss.bind.address:127.0.0.1}
> Workaround: in dialog box enclose the value in double quotes
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 11:09:03 2013
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Tue, 8 Oct 2013 11:09:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-292) Current AgendaGroup does not
 give way when setFocus is called
In-Reply-To: <JIRA.12502473.1381244876814@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502473.1381244876814@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502473.1381244876814.25328.1381244943333@jira02.app.mwc.hst.phx2.redhat.com>

Mark Proctor created DROOLS-292:
-----------------------------------

             Summary: Current AgendaGroup does not give way when setFocus is called
                 Key: DROOLS-292
                 URL: https://issues.jboss.org/browse/DROOLS-292
             Project: Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions:  6.0.0.CR4
            Reporter: Mark Proctor
            Assignee: Mark Proctor
             Fix For: 6.0.0.CR5




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 11:11:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 8 Oct 2013 11:11:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-292) Current AgendaGroup does not
 give way when setFocus is called
In-Reply-To: <JIRA.12502473.1381244876000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502473.1381244876000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502473.1381244876000.25337.1381245062793@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated DROOLS-292:
-------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1016727

    
> Current AgendaGroup does not give way when setFocus is called
> -------------------------------------------------------------
>
>                 Key: DROOLS-292
>                 URL: https://issues.jboss.org/browse/DROOLS-292
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>            Reporter: Mark Proctor
>            Assignee: Mark Proctor
>             Fix For: 6.0.0.CR5
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 11:42:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 8 Oct 2013 11:42:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (AS7-5768) Support resource adapter
 deployments via modules
In-Reply-To: <JIRA.12477219.1350477165000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12477219.1350477165000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12477219.1350477165000.25467.1381246922886@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-5768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812324#comment-12812324 ] 

RH Bugzilla Integration commented on AS7-5768:
----------------------------------------------

Van Halbert <vhalbert at redhat.com> changed the Status of [bug 868964|https://bugzilla.redhat.com/show_bug.cgi?id=868964] from MODIFIED to ON_QA
                
> Support resource adapter deployments via modules
> ------------------------------------------------
>
>                 Key: AS7-5768
>                 URL: https://issues.jboss.org/browse/AS7-5768
>             Project: Application Server 7
>          Issue Type: Task
>          Components: JCA
>            Reporter: Jesper Pedersen
>            Assignee: Stefano Maestri
>             Fix For: EAP 6.1.0.Alpha (7.2.0.Final)
>
>         Attachments: AS7-5768-example.tgz
>
>
> Add a new minor revision of the :resource-adapters: subsystem where the user has a choice of using
> {code}
> <archive>foo.rar</archive>
> {code}
> or
> {code}
> <module id="com.eis" slot="main"/>
> {code}
> where the latter contains the resource adapter in its unpacked form.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 12:01:03 2013
From: jira-events at lists.jboss.org (Christian Kaltepoth (JIRA))
Date: Tue, 8 Oct 2013 12:01:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2259) JSESSIONID in URL should be
	lowercase
In-Reply-To: <JIRA.12502478.1381247959861@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502478.1381247959861@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502478.1381247959861.25541.1381248063732@jira02.app.mwc.hst.phx2.redhat.com>

Christian Kaltepoth created WFLY-2259:
-----------------------------------------

             Summary: JSESSIONID in URL should be lowercase
                 Key: WFLY-2259
                 URL: https://issues.jboss.org/browse/WFLY-2259
             Project: WildFly
          Issue Type: Bug
          Components: Web (Undertow)
    Affects Versions: 8.0.0.Beta1
            Reporter: Christian Kaltepoth
            Assignee: Stuart Douglas


I know this looks like a very minor thing, but this was causing trouble for me in some integration tests, so I think I should bring it up here.

Wildfly appends *{{JSESSIONID}}* instead of *{{jsessionid}}* to the URL when encoding the session id (uppercase instead of lowercase). IMHO the spec requires it to be lowercase.

>From Servlet 3.1 spec:

{quote}
*7.1.3 URL Rewriting*

The session ID must be encoded as a path parameter in the URL string. The name of the parameter must be jsessionid. Here is an example of a URL containing encoded path information:
{code}http://www.myserver.com/catalog/index.html;jsessionid=1234{code}
{quote}


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 12:03:03 2013
From: jira-events at lists.jboss.org (Christian Kaltepoth (JIRA))
Date: Tue, 8 Oct 2013 12:03:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2259) JSESSIONID in URL should be
	lowercase
In-Reply-To: <JIRA.12502478.1381247959000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502478.1381247959000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502478.1381247959000.25573.1381248183065@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812342#comment-12812342 ] 

Christian Kaltepoth commented on WFLY-2259:
-------------------------------------------

I think this will also fix WFLY-2251, because an URL like this works:

https://localhost/your_app_context/your_servlet_mapping;JSESSIONID=whatever

But this one doesn't:

https://localhost/your_app_context/your_servlet_mapping;jsessionid=whatever

                
> JSESSIONID in URL should be lowercase
> -------------------------------------
>
>                 Key: WFLY-2259
>                 URL: https://issues.jboss.org/browse/WFLY-2259
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Christian Kaltepoth
>            Assignee: Stuart Douglas
>
> I know this looks like a very minor thing, but this was causing trouble for me in some integration tests, so I think I should bring it up here.
> Wildfly appends *{{JSESSIONID}}* instead of *{{jsessionid}}* to the URL when encoding the session id (uppercase instead of lowercase). IMHO the spec requires it to be lowercase.
> From Servlet 3.1 spec:
> {quote}
> *7.1.3 URL Rewriting*
> The session ID must be encoded as a path parameter in the URL string. The name of the parameter must be jsessionid. Here is an example of a URL containing encoded path information:
> {code}http://www.myserver.com/catalog/index.html;jsessionid=1234{code}
> {quote}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 12:03:03 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Tue, 8 Oct 2013 12:03:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2260) Vault tests pollute tmp dir
In-Reply-To: <JIRA.12502480.1381248164080@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502480.1381248164080@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502480.1381248164080.25576.1381248183253@jira02.app.mwc.hst.phx2.redhat.com>

Kabir Khan created WFLY-2260:
--------------------------------

             Summary: Vault tests pollute tmp dir
                 Key: WFLY-2260
                 URL: https://issues.jboss.org/browse/WFLY-2260
             Project: WildFly
          Issue Type: Feature Request
          Components: Security
            Reporter: Kabir Khan
            Assignee: Darran Lofthouse
             Fix For: 8.0.0.CR1


SlaveHostControllerAuthenticationTestCase often fails on inspection this seems to be that the wrong version of the vault file is being used from the tmp directory.

One way to see this is to clear out the tmp directory, and to run 
$mvn clean install -pl testsuite/domain/  -DallTests -Dtest=org.jboss.as.test.integration.domain.SlaveHostControllerAuthenticationTestCase

a few times, most likely from the second time it will fail. This happens during setup of the test, so you can reproduce more easily by adding a simple class
{code}
public class __Throwaway {
   public static void main(String[] args) throws Exception{
       SlaveHostControllerAuthenticationTestCase test = new SlaveHostControllerAuthenticationTestCase();
       test.setupVault();
       test.slaveWithVaultPasswordTest();
   }
}
{code}
and adjusting the visiblity of the SlaveHostControllerAuthenticationTestCase
methods. There are also other tests using the vault which also seem to pollute the tmp dir.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 12:08:02 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Tue, 8 Oct 2013 12:08:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2260) Vault tests pollute tmp dir
In-Reply-To: <JIRA.12502480.1381248164000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502480.1381248164000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502480.1381248164000.25589.1381248482734@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan reassigned WFLY-2260:
--------------------------------

    Assignee: Anil Saldhana  (was: Darran Lofthouse)

    
> Vault tests pollute tmp dir
> ---------------------------
>
>                 Key: WFLY-2260
>                 URL: https://issues.jboss.org/browse/WFLY-2260
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Security
>            Reporter: Kabir Khan
>            Assignee: Anil Saldhana
>             Fix For: 8.0.0.CR1
>
>
> SlaveHostControllerAuthenticationTestCase often fails on inspection this seems to be that the wrong version of the vault file is being used from the tmp directory.
> One way to see this is to clear out the tmp directory, and to run 
> $mvn clean install -pl testsuite/domain/  -DallTests -Dtest=org.jboss.as.test.integration.domain.SlaveHostControllerAuthenticationTestCase
> a few times, most likely from the second time it will fail. This happens during setup of the test, so you can reproduce more easily by adding a simple class
> {code}
> public class __Throwaway {
>    public static void main(String[] args) throws Exception{
>        SlaveHostControllerAuthenticationTestCase test = new SlaveHostControllerAuthenticationTestCase();
>        test.setupVault();
>        test.slaveWithVaultPasswordTest();
>    }
> }
> {code}
> and adjusting the visiblity of the SlaveHostControllerAuthenticationTestCase
> methods. There are also other tests using the vault which also seem to pollute the tmp dir.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 12:08:02 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Tue, 8 Oct 2013 12:08:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2260) Vault tests pollute tmp dir
In-Reply-To: <JIRA.12502480.1381248164000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502480.1381248164000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502480.1381248164000.25593.1381248482971@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-2260:
-----------------------------

    Description: 
SlaveHostControllerAuthenticationTestCase often fails. On inspection this seems to be that the wrong version of the vault file is being used from the tmp directory.

One way to see this is to clear out the tmp directory, and to run 
$mvn clean install -pl testsuite/domain/  -DallTests -Dtest=org.jboss.as.test.integration.domain.SlaveHostControllerAuthenticationTestCase

a few times, most likely from the second time it will fail. This happens during setup of the test, so you can reproduce more easily by adding a simple class
{code}
public class __Throwaway {
   public static void main(String[] args) throws Exception{
       SlaveHostControllerAuthenticationTestCase test = new SlaveHostControllerAuthenticationTestCase();
       test.setupVault();
       test.slaveWithVaultPasswordTest();
   }
}
{code}
and adjusting the visiblity of the SlaveHostControllerAuthenticationTestCase
methods. There are also other tests using the vault which also seem to pollute the tmp dir.

  was:
SlaveHostControllerAuthenticationTestCase often fails on inspection this seems to be that the wrong version of the vault file is being used from the tmp directory.

One way to see this is to clear out the tmp directory, and to run 
$mvn clean install -pl testsuite/domain/  -DallTests -Dtest=org.jboss.as.test.integration.domain.SlaveHostControllerAuthenticationTestCase

a few times, most likely from the second time it will fail. This happens during setup of the test, so you can reproduce more easily by adding a simple class
{code}
public class __Throwaway {
   public static void main(String[] args) throws Exception{
       SlaveHostControllerAuthenticationTestCase test = new SlaveHostControllerAuthenticationTestCase();
       test.setupVault();
       test.slaveWithVaultPasswordTest();
   }
}
{code}
and adjusting the visiblity of the SlaveHostControllerAuthenticationTestCase
methods. There are also other tests using the vault which also seem to pollute the tmp dir.


    
> Vault tests pollute tmp dir
> ---------------------------
>
>                 Key: WFLY-2260
>                 URL: https://issues.jboss.org/browse/WFLY-2260
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Security
>            Reporter: Kabir Khan
>            Assignee: Anil Saldhana
>             Fix For: 8.0.0.CR1
>
>
> SlaveHostControllerAuthenticationTestCase often fails. On inspection this seems to be that the wrong version of the vault file is being used from the tmp directory.
> One way to see this is to clear out the tmp directory, and to run 
> $mvn clean install -pl testsuite/domain/  -DallTests -Dtest=org.jboss.as.test.integration.domain.SlaveHostControllerAuthenticationTestCase
> a few times, most likely from the second time it will fail. This happens during setup of the test, so you can reproduce more easily by adding a simple class
> {code}
> public class __Throwaway {
>    public static void main(String[] args) throws Exception{
>        SlaveHostControllerAuthenticationTestCase test = new SlaveHostControllerAuthenticationTestCase();
>        test.setupVault();
>        test.slaveWithVaultPasswordTest();
>    }
> }
> {code}
> and adjusting the visiblity of the SlaveHostControllerAuthenticationTestCase
> methods. There are also other tests using the vault which also seem to pollute the tmp dir.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 12:12:02 2013
From: jira-events at lists.jboss.org (Juergen Zimmermann (JIRA))
Date: Tue, 8 Oct 2013 12:12:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2249) NPE during redeployment of a
	war
In-Reply-To: <JIRA.12502347.1381151954000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502347.1381151954000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502347.1381151954000.25604.1381248722566@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812347#comment-12812347 ] 

Juergen Zimmermann commented on WFLY-2249:
------------------------------------------

I just switched to the current snapshot of Beta2 : the issue isn't there. Shall I close this issue?
                
> NPE during redeployment of a war
> --------------------------------
>
>                 Key: WFLY-2249
>                 URL: https://issues.jboss.org/browse/WFLY-2249
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Juergen Zimmermann
>            Assignee: Scott Marlow
>
> When I redeploy an already running war, then I get the following NPE. The (re-) deployment is done via the Maven plugin org.jboss.as.plugins:jboss-as-maven-plugin:7.4.Final. It looks like the redployment was successful anyway. Hmm...
> {code}
> ERROR [org.jboss.msc.service.fail] MSC000001: Failed to start service jboss.deployment.unit."shop.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."shop.war".PARSE: JBAS018733: Failed to process phase PARSE of deployment "shop.war"
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> Caused by: java.lang.NullPointerException
> 	at org.jboss.as.jpa.processor.PersistenceUnitParseProcessor.handleWarDeployment(PersistenceUnitParseProcessor.java:126)
> 	at org.jboss.as.jpa.processor.PersistenceUnitParseProcessor.deploy(PersistenceUnitParseProcessor.java:83)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	... 5 more
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 12:21:02 2013
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Tue, 8 Oct 2013 12:21:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2260) Vault tests pollute tmp dir
In-Reply-To: <JIRA.12502480.1381248164000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502480.1381248164000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502480.1381248164000.25621.1381249262612@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana reassigned WFLY-2260:
-----------------------------------

    Assignee: Peter Skopek  (was: Anil Saldhana)

    
> Vault tests pollute tmp dir
> ---------------------------
>
>                 Key: WFLY-2260
>                 URL: https://issues.jboss.org/browse/WFLY-2260
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Security
>            Reporter: Kabir Khan
>            Assignee: Peter Skopek
>             Fix For: 8.0.0.CR1
>
>
> SlaveHostControllerAuthenticationTestCase often fails. On inspection this seems to be that the wrong version of the vault file is being used from the tmp directory.
> One way to see this is to clear out the tmp directory, and to run 
> $mvn clean install -pl testsuite/domain/  -DallTests -Dtest=org.jboss.as.test.integration.domain.SlaveHostControllerAuthenticationTestCase
> a few times, most likely from the second time it will fail. This happens during setup of the test, so you can reproduce more easily by adding a simple class
> {code}
> public class __Throwaway {
>    public static void main(String[] args) throws Exception{
>        SlaveHostControllerAuthenticationTestCase test = new SlaveHostControllerAuthenticationTestCase();
>        test.setupVault();
>        test.slaveWithVaultPasswordTest();
>    }
> }
> {code}
> and adjusting the visiblity of the SlaveHostControllerAuthenticationTestCase
> methods. There are also other tests using the vault which also seem to pollute the tmp dir.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 12:38:02 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Tue, 8 Oct 2013 12:38:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2249) NPE during redeployment of a
	war
In-Reply-To: <JIRA.12502347.1381151954000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502347.1381151954000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502347.1381151954000.25671.1381250282888@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812359#comment-12812359 ] 

Scott Marlow commented on WFLY-2249:
------------------------------------

Was the NullPointerException occurring consistently with Beta1?  Or did it just happen one time?
                
> NPE during redeployment of a war
> --------------------------------
>
>                 Key: WFLY-2249
>                 URL: https://issues.jboss.org/browse/WFLY-2249
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Juergen Zimmermann
>            Assignee: Scott Marlow
>
> When I redeploy an already running war, then I get the following NPE. The (re-) deployment is done via the Maven plugin org.jboss.as.plugins:jboss-as-maven-plugin:7.4.Final. It looks like the redployment was successful anyway. Hmm...
> {code}
> ERROR [org.jboss.msc.service.fail] MSC000001: Failed to start service jboss.deployment.unit."shop.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."shop.war".PARSE: JBAS018733: Failed to process phase PARSE of deployment "shop.war"
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> Caused by: java.lang.NullPointerException
> 	at org.jboss.as.jpa.processor.PersistenceUnitParseProcessor.handleWarDeployment(PersistenceUnitParseProcessor.java:126)
> 	at org.jboss.as.jpa.processor.PersistenceUnitParseProcessor.deploy(PersistenceUnitParseProcessor.java:83)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	... 5 more
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 12:55:02 2013
From: jira-events at lists.jboss.org (Cheng Fang (JIRA))
Date: Tue, 8 Oct 2013 12:55:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2261) standalone.sh --debug without
 port number not working
In-Reply-To: <JIRA.12502486.1381251288609@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502486.1381251288609@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502486.1381251288609.25706.1381251302560@jira02.app.mwc.hst.phx2.redhat.com>

Cheng Fang created WFLY-2261:
--------------------------------

             Summary: standalone.sh --debug without port number not working 
                 Key: WFLY-2261
                 URL: https://issues.jboss.org/browse/WFLY-2261
             Project: WildFly
          Issue Type: Bug
          Components: CLI
    Affects Versions: 8.0.0.Beta1
            Reporter: Cheng Fang
            Assignee: Alexey Loubyansky


./standalone.sh --debug port-num works, but it failed when omitting port number.

sh -x standalone.sh --debug  (expecting the default port 8787 to be used)

{noformat}
+ eval '"/Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/bin/java"' '-D"[Standalone]"' -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n '"-Dorg.jboss.boot.log.file=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/log/server.log"' '"-Dlogging.configuration=file:/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/configuration/logging.properties"' -jar '"/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/jboss-modules.jar"' -mp '"/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/modules"' org.jboss.as.standalone '-Djboss.home.dir="/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT"' '-Djboss.server.base.dir="/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone"' ' ""'
++ /Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/bin/java '-D[Standalone]' -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n -Dorg.jboss.boot.log.file=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/log/server.log -Dlogging.configuration=file:/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/configuration/logging.properties -jar /Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/jboss-modules.jar -mp /Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/modules org.jboss.as.standalone -Djboss.home.dir=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT -Djboss.server.base.dir=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone ''
Listening for transport dt_socket at address: 8787
12:19:36,715 INFO  [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final
12:19:36,886 ERROR [stderr] (main) JBAS015801: Invalid option ''
12:19:36,893 INFO  [stdout] (main)
12:19:36,893 INFO  [stdout] (main) Usage: standalone.sh [args...]
{noformat}

sh -x standalone.sh --debug 8787 (the working command)
{noformat}
+ eval '"/Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/bin/java"' '-D"[Standalone]"' -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n '"-Dorg.jboss.boot.log.file=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/log/server.log"' '"-Dlogging.configuration=file:/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/configuration/logging.properties"' -jar '"/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/jboss-modules.jar"' -mp '"/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/modules"' org.jboss.as.standalone '-Djboss.home.dir="/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT"' '-Djboss.server.base.dir="/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone"' ''
++ /Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/bin/java '-D[Standalone]' -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n -Dorg.jboss.boot.log.file=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/log/server.log -Dlogging.configuration=file:/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/configuration/logging.properties -jar /Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/jboss-modules.jar -mp /Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/modules org.jboss.as.standalone -Djboss.home.dir=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT -Djboss.server.base.dir=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone
Listening for transport dt_socket at address: 8787
12:20:39,251 INFO  [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final
12:20:39,626 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.0.Beta2
{noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Tue Oct  8 13:30:02 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 8 Oct 2013 13:30:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2262) HTTP connectors not visible
 for Deployer (EAP 6.x)
In-Reply-To: <JIRA.12502491.1381253294443@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502491.1381253294443@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502491.1381253294443.25897.1381253402687@jira02.app.mwc.hst.phx2.redhat.com>

Heiko Braun created WFLY-2262:
---------------------------------

             Summary: HTTP connectors not visible for Deployer (EAP 6.x)
                 Key: WFLY-2262
                 URL: https://issues.jboss.org/browse/WFLY-2262
             Project: WildFly
          Issue Type: Feature Request
          Components: Domain Management
            Reporter: Heiko Braun
            Assignee: Brian Stansberry


web not undertow. Bug or feature:

{noformat}
[standalone at localhost:9999 /] /subsystem=web:read-children-resources(child-type=connector){roles=deployer}
{
    "outcome" => "success",
    "result" => {},
    "response-headers" => {"access-control" => [{
        "absolute-address" => [("subsystem" => "web")],
        "relative-address" => [],
        "filtered-children-types" => ["connector"]
    }]}
}
{noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 13:30:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 8 Oct 2013 13:30:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2262) HTTP connectors not visible
 for Deployer (EAP 6.x)
In-Reply-To: <JIRA.12502491.1381253294000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502491.1381253294000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502491.1381253294000.25908.1381253403270@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun updated WFLY-2262:
------------------------------

    Fix Version/s: 8.0.0.CR1

    
> HTTP connectors not visible for Deployer (EAP 6.x)
> --------------------------------------------------
>
>                 Key: WFLY-2262
>                 URL: https://issues.jboss.org/browse/WFLY-2262
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> web not undertow. Bug or feature:
> {noformat}
> [standalone at localhost:9999 /] /subsystem=web:read-children-resources(child-type=connector){roles=deployer}
> {
>     "outcome" => "success",
>     "result" => {},
>     "response-headers" => {"access-control" => [{
>         "absolute-address" => [("subsystem" => "web")],
>         "relative-address" => [],
>         "filtered-children-types" => ["connector"]
>     }]}
> }
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 13:30:02 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 8 Oct 2013 13:30:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2262) HTTP connectors not visible
 for Deployer (EAP 6.x)
In-Reply-To: <JIRA.12502491.1381253294000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502491.1381253294000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502491.1381253294000.25904.1381253402995@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun updated WFLY-2262:
------------------------------

    Issue Type: Bug  (was: Feature Request)

    
> HTTP connectors not visible for Deployer (EAP 6.x)
> --------------------------------------------------
>
>                 Key: WFLY-2262
>                 URL: https://issues.jboss.org/browse/WFLY-2262
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>
> web not undertow. Bug or feature:
> {noformat}
> [standalone at localhost:9999 /] /subsystem=web:read-children-resources(child-type=connector){roles=deployer}
> {
>     "outcome" => "success",
>     "result" => {},
>     "response-headers" => {"access-control" => [{
>         "absolute-address" => [("subsystem" => "web")],
>         "relative-address" => [],
>         "filtered-children-types" => ["connector"]
>     }]}
> }
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 14:09:02 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 8 Oct 2013 14:09:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2263) Access control meta data:
 Instance references
In-Reply-To: <JIRA.12502494.1381255726271@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502494.1381255726271@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502494.1381255726271.26040.1381255742566@jira02.app.mwc.hst.phx2.redhat.com>

Heiko Braun created WFLY-2263:
---------------------------------

             Summary: Access control meta data: Instance references
                 Key: WFLY-2263
                 URL: https://issues.jboss.org/browse/WFLY-2263
             Project: WildFly
          Issue Type: Enhancement
          Components: Domain Management
            Reporter: Heiko Braun
            Assignee: Brian Stansberry
             Fix For: 8.0.0.CR1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 14:17:02 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 8 Oct 2013 14:17:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2263) Access control meta data:
 Instance references
In-Reply-To: <JIRA.12502494.1381255726000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502494.1381255726000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502494.1381255726000.26059.1381256222663@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812429#comment-12812429 ] 

Heiko Braun commented on WFLY-2263:
-----------------------------------

when requesting access control meta data, we return a the 'default' policy per resource type and 'exceptions' (instance specific) 

Here's an 'exception': 

{noformat}
[("subsystem" => "datasources"),("data-source" => "ExampleDS")]={
    "read" => true,
    "write" => false,
   
    [...]
}
{noformat}

As you can see it uses the string representation of the instance address as the property key. This makes it really hard to match that key against requested resources. I would prefer the instance name to become the key, and instead provide an inline address represenation, of proper ModelType.LIST (like all other address attributes):

{noformat}
["ExampleDS"={
    instanceAddress = [("subsystem" => "datasources"),("data-source" => "ExampleDS")],
     "read" => true,
    "write" => false,
   
    [...]
}
{noformat}
                
> Access control meta data: Instance references
> ---------------------------------------------
>
>                 Key: WFLY-2263
>                 URL: https://issues.jboss.org/browse/WFLY-2263
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 14:17:02 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 8 Oct 2013 14:17:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2263) Access control meta data:
 Instance references
In-Reply-To: <JIRA.12502494.1381255726000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502494.1381255726000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502494.1381255726000.26063.1381256222873@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812430#comment-12812430 ] 

Heiko Braun commented on WFLY-2263:
-----------------------------------

[~kabirkhan] Can you comment on this? 
                
> Access control meta data: Instance references
> ---------------------------------------------
>
>                 Key: WFLY-2263
>                 URL: https://issues.jboss.org/browse/WFLY-2263
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 14:19:02 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 8 Oct 2013 14:19:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2263) Access control meta data:
 Instance references
In-Reply-To: <JIRA.12502494.1381255726000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502494.1381255726000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502494.1381255726000.26067.1381256342629@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812429#comment-12812429 ] 

Heiko Braun edited comment on WFLY-2263 at 10/8/13 2:17 PM:
------------------------------------------------------------

when requesting access control meta data, we return a the 'default' policy per resource type and 'exceptions' (instance specific) 

Here's an 'exception': 

{noformat}
[("subsystem" => "datasources"),("data-source" => "ExampleDS")]={
    "read" => true,
    "write" => false,
   
    [...]
}
{noformat}

As you can see it uses the string representation of the instance address as the property key. This makes it really hard to match that key against requested resources (property keys are just String in the DMR API). 

I would prefer the instance name to become the key, and instead provide an inline address represenation, of proper ModelType.LIST (like all other address attributes):

{noformat}
["ExampleDS"={
    instanceAddress = [("subsystem" => "datasources"),("data-source" => "ExampleDS")],
     "read" => true,
    "write" => false,
   
    [...]
}
{noformat}
                
      was (Author: heiko.braun):
    when requesting access control meta data, we return a the 'default' policy per resource type and 'exceptions' (instance specific) 

Here's an 'exception': 

{noformat}
[("subsystem" => "datasources"),("data-source" => "ExampleDS")]={
    "read" => true,
    "write" => false,
   
    [...]
}
{noformat}

As you can see it uses the string representation of the instance address as the property key. This makes it really hard to match that key against requested resources. I would prefer the instance name to become the key, and instead provide an inline address represenation, of proper ModelType.LIST (like all other address attributes):

{noformat}
["ExampleDS"={
    instanceAddress = [("subsystem" => "datasources"),("data-source" => "ExampleDS")],
     "read" => true,
    "write" => false,
   
    [...]
}
{noformat}
                  
> Access control meta data: Instance references
> ---------------------------------------------
>
>                 Key: WFLY-2263
>                 URL: https://issues.jboss.org/browse/WFLY-2263
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 14:23:02 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Tue, 8 Oct 2013 14:23:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2263) Access control meta data:
 Instance references
In-Reply-To: <JIRA.12502494.1381255726000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502494.1381255726000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502494.1381255726000.26081.1381256582904@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812434#comment-12812434 ] 

Kabir Khan commented on WFLY-2263:
----------------------------------

That will not really work if the registration's parent is also a wildcard, e.g. /subsystem=undertow/server=*/host=*:read-resource-description. You need the full path
                
> Access control meta data: Instance references
> ---------------------------------------------
>
>                 Key: WFLY-2263
>                 URL: https://issues.jboss.org/browse/WFLY-2263
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 14:23:03 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Tue, 8 Oct 2013 14:23:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2263) Access control meta data:
 Instance references
In-Reply-To: <JIRA.12502494.1381255726000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502494.1381255726000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502494.1381255726000.26087.1381256583226@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812434#comment-12812434 ] 

Kabir Khan edited comment on WFLY-2263 at 10/8/13 2:22 PM:
-----------------------------------------------------------

That will not really work if the registration's parent is also a wildcard, e.g. 
{{/subsystem=undertow/server=*/host=*:read-resource-description}}. You need the full path
                
      was (Author: kabirkhan):
    That will not really work if the registration's parent is also a wildcard, e.g. /subsystem=undertow/server=*/host=*:read-resource-description. You need the full path
                  
> Access control meta data: Instance references
> ---------------------------------------------
>
>                 Key: WFLY-2263
>                 URL: https://issues.jboss.org/browse/WFLY-2263
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 14:23:03 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Tue, 8 Oct 2013 14:23:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2263) Access control meta data:
 Instance references
In-Reply-To: <JIRA.12502494.1381255726000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502494.1381255726000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502494.1381255726000.26093.1381256583495@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812434#comment-12812434 ] 

Kabir Khan edited comment on WFLY-2263 at 10/8/13 2:22 PM:
-----------------------------------------------------------

That will not really work if the registration's parent is also a wildcard, e.g. 
{code}/subsystem=undertow/server=*/host=*:read-resource-description{code}. You need the full path
                
      was (Author: kabirkhan):
    That will not really work if the registration's parent is also a wildcard, e.g. 
{{/subsystem=undertow/server=*/host=*:read-resource-description}}. You need the full path
                  
> Access control meta data: Instance references
> ---------------------------------------------
>
>                 Key: WFLY-2263
>                 URL: https://issues.jboss.org/browse/WFLY-2263
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 14:25:02 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Tue, 8 Oct 2013 14:25:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2263) Access control meta data:
 Instance references
In-Reply-To: <JIRA.12502494.1381255726000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502494.1381255726000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502494.1381255726000.26100.1381256702714@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812436#comment-12812436 ] 

Kabir Khan commented on WFLY-2263:
----------------------------------

I missed the inline address representation, but the problem is still there could be two instances with the same key but different parent
                
> Access control meta data: Instance references
> ---------------------------------------------
>
>                 Key: WFLY-2263
>                 URL: https://issues.jboss.org/browse/WFLY-2263
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 14:31:02 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Tue, 8 Oct 2013 14:31:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2260) Vault tests pollute tmp dir
In-Reply-To: <JIRA.12502480.1381248164000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502480.1381248164000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502480.1381248164000.26114.1381257062549@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812439#comment-12812439 ] 

Kabir Khan commented on WFLY-2260:
----------------------------------

This commit just pushed to master disables the vault part of the test https://github.com/wildfly/wildfly/commit/79771a59567d4ce1d72d231be076e585208ecfdd. It will need reenabling as part of any work done on this issue.
                
> Vault tests pollute tmp dir
> ---------------------------
>
>                 Key: WFLY-2260
>                 URL: https://issues.jboss.org/browse/WFLY-2260
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Security
>            Reporter: Kabir Khan
>            Assignee: Peter Skopek
>             Fix For: 8.0.0.CR1
>
>
> SlaveHostControllerAuthenticationTestCase often fails. On inspection this seems to be that the wrong version of the vault file is being used from the tmp directory.
> One way to see this is to clear out the tmp directory, and to run 
> $mvn clean install -pl testsuite/domain/  -DallTests -Dtest=org.jboss.as.test.integration.domain.SlaveHostControllerAuthenticationTestCase
> a few times, most likely from the second time it will fail. This happens during setup of the test, so you can reproduce more easily by adding a simple class
> {code}
> public class __Throwaway {
>    public static void main(String[] args) throws Exception{
>        SlaveHostControllerAuthenticationTestCase test = new SlaveHostControllerAuthenticationTestCase();
>        test.setupVault();
>        test.slaveWithVaultPasswordTest();
>    }
> }
> {code}
> and adjusting the visiblity of the SlaveHostControllerAuthenticationTestCase
> methods. There are also other tests using the vault which also seem to pollute the tmp dir.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 14:42:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 8 Oct 2013 14:42:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2220) Unable to reload server after
 adding role and executing :reload
In-Reply-To: <JIRA.12502221.1380896422000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502221.1380896422000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502221.1380896422000.26124.1381257722499@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812442#comment-12812442 ] 

RH Bugzilla Integration commented on WFLY-2220:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1015585|https://bugzilla.redhat.com/show_bug.cgi?id=1015585] from POST to MODIFIED
                
> Unable to reload server after adding role and executing :reload
> ---------------------------------------------------------------
>
>                 Key: WFLY-2220
>                 URL: https://issues.jboss.org/browse/WFLY-2220
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.CR1
>
>
> Start a clean build of WildFly 8 and execute the following commands in the CLI: -
> {code}
> [standalone at localhost:9990 /connect
> [standalone at localhost:9990 /] ./core-service=management/access=authorization/role-mapping=Operator:add
> {"outcome" => "success"}
> [standalone at localhost:9990 /] :reload
> {
>     "outcome" => "success",
>     "result" => undefined
> }
> [standalone at localhost:9990 /] 
> {code}
> Results in the following error and the server shuts down: -
> {code}
> 15:15:02,275 INFO  [org.jboss.as.server] (Controller Boot Thread) JBAS015888: Creating http management service using socket-binding (management-http)
> 15:15:02,278 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014612: Operation ("add") failed - address: ([
>     ("core-service" => "management"),
>     ("access" => "authorization"),
>     ("role-mapping" => "SuperUser")
> ]): java.lang.UnsupportedOperationException
> 	at java.util.Collections$UnmodifiableMap.put(Collections.java:1342) [rt.jar:1.7.0_17]
> 	at org.jboss.as.controller.access.management.WritableAuthorizerConfiguration.addRoleMappingImmediate(WritableAuthorizerConfiguration.java:163) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.domain.management.access.RoleMappingAdd$1.execute(RoleMappingAdd.java:76) [wildfly-domain-management-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:609) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:487) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:321) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:290) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:356) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:331) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:252) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> 15:15:02,287 INFO  [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.remoting.endpoint.management (missing) dependents: [service jboss.remoting.management.channel.registry] 
> 15:15:02,290 FATAL [org.jboss.as.server] (Controller Boot Thread) JBAS015957: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> 15:15:02,297 INFO  [org.jboss.as] (MSC service thread 1-1) JBAS015950: WildFly 8.0.0.Beta1-SNAPSHOT "WildFly" stopped in 2ms
> {code}
> What is interesting is that the server is manually startable to something has gone wrong regarding resetting the runtime state of RBAC at the time of the reload.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 14:44:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 8 Oct 2013 14:44:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2216) include-all role mappings
 don't work in domain
In-Reply-To: <JIRA.12502198.1380887272000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502198.1380887272000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502198.1380887272000.26129.1381257842618@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812443#comment-12812443 ] 

RH Bugzilla Integration commented on WFLY-2216:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1015493|https://bugzilla.redhat.com/show_bug.cgi?id=1015493] from POST to MODIFIED
                
> include-all role mappings don't work in domain
> ----------------------------------------------
>
>                 Key: WFLY-2216
>                 URL: https://issues.jboss.org/browse/WFLY-2216
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Ladislav Thon
>            Assignee: Darran Lofthouse
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.CR1
>
>
> If I understand correctly, roles that have {{include-all=true}} in their role mappings should be added to all authenticated users. In my tests, though, this only works in standalone mode.
> In domain mode, if I set a role mapping to {{include-all}}, this setting is not reflected (at least not immediately; maybe it would work after restart, but that's wrong anyway). It doesn't matter which role is set to be {{include-all}} -- in my tests, I use both standard roles and scoped roles and it consistently doesn't work. There's probably some wrong caching going on.
> The failing test case is in my pull request https://github.com/wildfly/wildfly/pull/5166 (it's the _RBAC tests for include-all role mappings in domain_ commit). If it's more convenient, the pull request is the same as my _rbac_ branch (https://github.com/Ladicek/wildfly/commits/rbac).
> Darran, I'm not sure if you are the right assignee -- please reassign if needed. Thanks.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 15:56:02 2013
From: jira-events at lists.jboss.org (Stefan Guilhen (JIRA))
Date: Tue, 8 Oct 2013 15:56:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1919) PicketBox 4.0.18.Final
In-Reply-To: <JIRA.12499106.1377100373000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499106.1377100373000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499106.1377100373000.26169.1381262162563@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Guilhen closed WFLY-1919.
--------------------------------

    Resolution: Done


This has been incorporated by WFLY-2038
                
> PicketBox 4.0.18.Final
> ----------------------
>
>                 Key: WFLY-1919
>                 URL: https://issues.jboss.org/browse/WFLY-1919
>             Project: WildFly
>          Issue Type: Component  Upgrade
>          Components: Build System
>            Reporter: Jesper Pedersen
>            Assignee: Stefan Guilhen
>            Priority: Critical
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 15:58:02 2013
From: jira-events at lists.jboss.org (Pedro Igor (JIRA))
Date: Tue, 8 Oct 2013 15:58:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-752) Release PicketBox
	4.0.20.Beta1
In-Reply-To: <JIRA.12502498.1381262268311@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502498.1381262268311@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502498.1381262268311.26171.1381262282517@jira02.app.mwc.hst.phx2.redhat.com>

Pedro Igor created SECURITY-752:
-----------------------------------

             Summary: Release PicketBox 4.0.20.Beta1
                 Key: SECURITY-752
                 URL: https://issues.jboss.org/browse/SECURITY-752
             Project: PicketBox 
          Issue Type: Release
      Security Level: Public (Everyone can see)
          Components: JBossSX, Security SPI
            Reporter: Stefan Guilhen
            Assignee: Stefan Guilhen




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 16:40:02 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 8 Oct 2013 16:40:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2263) Access control meta data:
 Instance references
In-Reply-To: <JIRA.12502494.1381255726000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502494.1381255726000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502494.1381255726000.26193.1381264802818@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812456#comment-12812456 ] 

Brian Stansberry commented on WFLY-2263:
----------------------------------------

Can there be two instances of the same key but different parent?

If the request is for multiple items (e.g. /x=*/y=<whatever>) shouldn't the response be a list with a separate element for each instance of x? So then the contents of each element should be distinct.
                
> Access control meta data: Instance references
> ---------------------------------------------
>
>                 Key: WFLY-2263
>                 URL: https://issues.jboss.org/browse/WFLY-2263
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 18:02:02 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Tue, 8 Oct 2013 18:02:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2263) Access control meta data:
 Instance references
In-Reply-To: <JIRA.12502494.1381255726000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502494.1381255726000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502494.1381255726000.26268.1381269722628@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812469#comment-12812469 ] 

Kabir Khan commented on WFLY-2263:
----------------------------------

Ah right, not a map like I thought when I looked quickly. So a list of property, where each property entry has the full address, and the access control. That should be possible. Something like this?
{code}
    public static void main(String[] args) {
        ModelNode node = new ModelNode();

        node.add("HostA", createEntry("Server-1", "HostA"));
        node.add("HostA", createEntry("Server-2", "HostA"));
        node.add("HostB", createEntry("Server-2", "HostB"));
        System.out.println(node);
    }

    private static ModelNode createEntry(String server, String host) {
        ModelNode node = new ModelNode();
        node.get("addresss").add("subsystem", "datasources");
        node.get("addresss").add("server", server);
        node.get("addresss").add("host", host);
        node.get("read").set(true);
        node.get("write").set(true);
        return node;
    }
{code}
Giving:
{code}
[
    ("HostA" => {
    "addresss" => [
        ("subsystem" => "undertow"),
        ("server" => "Server-1"),
        ("host" => "HostA")
    ],
    "read" => true,
    "write" => true
}),
    ("HostA" => {
    "addresss" => [
        ("subsystem" => "undertow"),
        ("server" => "Server-2"),
        ("host" => "HostA")
    ],
    "read" => true,
    "write" => true
}),
    ("HostB" => {
    "addresss" => [
        ("subsystem" => "undertow"),
        ("server" => "Server-2"),
        ("host" => "HostB")
    ],
    "read" => true,
    "write" => true
})
]
{code}

                
> Access control meta data: Instance references
> ---------------------------------------------
>
>                 Key: WFLY-2263
>                 URL: https://issues.jboss.org/browse/WFLY-2263
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 18:16:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 8 Oct 2013 18:16:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2185) Get core model test framework
 working with 7.2.0.Final legacy controller
In-Reply-To: <JIRA.12501848.1380553676000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501848.1380553676000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501848.1380553676000.26271.1381270562999@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812470#comment-12812470 ] 

RH Bugzilla Integration commented on WFLY-2185:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1015245|https://bugzilla.redhat.com/show_bug.cgi?id=1015245] from POST to MODIFIED
                
> Get core model test framework working with 7.2.0.Final legacy controller
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2185
>                 URL: https://issues.jboss.org/browse/WFLY-2185
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 18:16:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 8 Oct 2013 18:16:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2173) Get subsystem test framework
 working with AS 7.2.0 legacy controller
In-Reply-To: <JIRA.12501755.1380296954000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501755.1380296954000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501755.1380296954000.26273.1381270563080@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812471#comment-12812471 ] 

RH Bugzilla Integration commented on WFLY-2173:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1015245|https://bugzilla.redhat.com/show_bug.cgi?id=1015245] from POST to MODIFIED
                
> Get subsystem test framework working with AS 7.2.0 legacy controller
> --------------------------------------------------------------------
>
>                 Key: WFLY-2173
>                 URL: https://issues.jboss.org/browse/WFLY-2173
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 18:18:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 8 Oct 2013 18:18:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1697) Fix JPA
 SerializableValidatorFactory memory leak
In-Reply-To: <JIRA.12496481.1373901643000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496481.1373901643000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496481.1373901643000.26278.1381270682574@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812472#comment-12812472 ] 

RH Bugzilla Integration commented on WFLY-1697:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1003600|https://bugzilla.redhat.com/show_bug.cgi?id=1003600] from ON_QA to MODIFIED
                
> Fix JPA SerializableValidatorFactory memory leak
> ------------------------------------------------
>
>                 Key: WFLY-1697
>                 URL: https://issues.jboss.org/browse/WFLY-1697
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>
> See http://lists.jboss.org/pipermail/wildfly-dev/2013-July/000466.html for details on recreating the SerializableValidatorFactory leak and Hibernate service loader references to Integreation class/properties.  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 18:48:02 2013
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Tue, 8 Oct 2013 18:48:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-292) Current AgendaGroup does not
 give way when setFocus is called
In-Reply-To: <JIRA.12502473.1381244876000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502473.1381244876000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502473.1381244876000.26288.1381272482572@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mark Proctor resolved DROOLS-292.
---------------------------------

    Resolution: Done

    
> Current AgendaGroup does not give way when setFocus is called
> -------------------------------------------------------------
>
>                 Key: DROOLS-292
>                 URL: https://issues.jboss.org/browse/DROOLS-292
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>            Reporter: Mark Proctor
>            Assignee: Mark Proctor
>             Fix For: 6.0.0.CR5
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 19:24:02 2013
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Tue, 8 Oct 2013 19:24:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2264) Property expressions resolved
 before the PatternFormatter can resolve them
In-Reply-To: <JIRA.12502502.1381274548172@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502502.1381274548172@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502502.1381274548172.26290.1381274642538@jira02.app.mwc.hst.phx2.redhat.com>

James Perkins created WFLY-2264:
-----------------------------------

             Summary: Property expressions resolved before the PatternFormatter can resolve them
                 Key: WFLY-2264
                 URL: https://issues.jboss.org/browse/WFLY-2264
             Project: WildFly
          Issue Type: Bug
          Components: Logging
            Reporter: James Perkins
            Assignee: James Perkins
            Priority: Minor
             Fix For: 8.0.0.CR1


System property expressions defined in {{pattern-formatter}} or {{formatter}} attributes are processed by the {{AttributeDefinition}} rather than left and processed by the {{PatternFormatter}}. This results in invalid pattern values being used and stops the server from logging.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 19:24:02 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Tue, 8 Oct 2013 19:24:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2264) Property expressions resolved
 before the PatternFormatter can resolve them
In-Reply-To: <JIRA.12502502.1381274548000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502502.1381274548000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502502.1381274548000.26294.1381274642698@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812476#comment-12812476 ] 

David Lloyd commented on WFLY-2264:
-----------------------------------

This is correct behavior.  It is not correct to leave expression parsing until a later stage and in fact will become disallowed in the future.
                
> Property expressions resolved before the PatternFormatter can resolve them
> --------------------------------------------------------------------------
>
>                 Key: WFLY-2264
>                 URL: https://issues.jboss.org/browse/WFLY-2264
>             Project: WildFly
>          Issue Type: Bug
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Minor
>             Fix For: 8.0.0.CR1
>
>
> System property expressions defined in {{pattern-formatter}} or {{formatter}} attributes are processed by the {{AttributeDefinition}} rather than left and processed by the {{PatternFormatter}}. This results in invalid pattern values being used and stops the server from logging.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 19:30:02 2013
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Tue, 8 Oct 2013 19:30:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2264) Property expressions resolved
 before the PatternFormatter can resolve them
In-Reply-To: <JIRA.12502502.1381274548000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502502.1381274548000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502502.1381274548000.26296.1381275002507@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812477#comment-12812477 ] 

James Perkins commented on WFLY-2264:
-------------------------------------

So a logging format pattern like the following should not be allowed?

{code}
%d{yyyy-MM-dd HH:mm:ss,SSS} %${server.name:localhost} %-5p [%c] (%t) %s%E%n
{code}

Maybe for the pattern I should have chose something better then {{%$}}. It just seemed the logical thing to do to keep it standard with our other property expressions.
                
> Property expressions resolved before the PatternFormatter can resolve them
> --------------------------------------------------------------------------
>
>                 Key: WFLY-2264
>                 URL: https://issues.jboss.org/browse/WFLY-2264
>             Project: WildFly
>          Issue Type: Bug
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Minor
>             Fix For: 8.0.0.CR1
>
>
> System property expressions defined in {{pattern-formatter}} or {{formatter}} attributes are processed by the {{AttributeDefinition}} rather than left and processed by the {{PatternFormatter}}. This results in invalid pattern values being used and stops the server from logging.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 21:02:02 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 8 Oct 2013 21:02:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-434) Domain Management - Support
 for database connection pool in non AS process.
In-Reply-To: <JIRA.12442411.1311333410000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12442411.1311333410000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12442411.1311333410000.26340.1381280522559@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-434:
----------------------------------

    Fix Version/s: 9.0.0.CR1
                       (was: 8.0.0.CR1)

    
> Domain Management - Support for database connection pool in non AS process.
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-434
>                 URL: https://issues.jboss.org/browse/WFLY-434
>             Project: WildFly
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Brian Stansberry
>             Fix For: 9.0.0.CR1
>
>
> We need to support authentication for users stored in database, the domain management is in a non-AS process so we also need a pool of database connections.
> These connections will be used to read only from the database, other than the isolation offered by the driver we should not require any advanced transaction support.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 22:31:02 2013
From: jira-events at lists.jboss.org (Lin Gao (JIRA))
Date: Tue, 8 Oct 2013 22:31:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1086) ant -Das=true clean jars
	failed
In-Reply-To: <JIRA.12501690.1380248503000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501690.1380248503000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501690.1380248503000.26356.1381285862560@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lin Gao updated JBJCA-1086:
---------------------------

    Affects Version/s: 1.1.0.Final

    
> ant -Das=true clean jars failed 
> --------------------------------
>
>                 Key: JBJCA-1086
>                 URL: https://issues.jboss.org/browse/JBJCA-1086
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Build
>    Affects Versions: 1.1.0.Final
>            Reporter: Lin Gao
>            Assignee: Lin Gao
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 22:31:02 2013
From: jira-events at lists.jboss.org (Lin Gao (JIRA))
Date: Tue, 8 Oct 2013 22:31:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1086) ant -Das=true clean jars
	failed
In-Reply-To: <JIRA.12501690.1380248503000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501690.1380248503000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501690.1380248503000.26357.1381285862608@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lin Gao resolved JBJCA-1086.
----------------------------

    Resolution: Done

    
> ant -Das=true clean jars failed 
> --------------------------------
>
>                 Key: JBJCA-1086
>                 URL: https://issues.jboss.org/browse/JBJCA-1086
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Build
>    Affects Versions: 1.1.0.Final
>            Reporter: Lin Gao
>            Assignee: Lin Gao
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 23:06:02 2013
From: jira-events at lists.jboss.org (zhihong liu (JIRA))
Date: Tue, 8 Oct 2013 23:06:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2265)
 WebUtils#getRealPath("/config-data") cannot be resolved to absolute file
 path
In-Reply-To: <JIRA.12502507.1381287850917@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502507.1381287850917@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502507.1381287850917.26362.1381287962577@jira02.app.mwc.hst.phx2.redhat.com>

zhihong liu created WFLY-2265:
---------------------------------

             Summary: WebUtils#getRealPath("/config-data") cannot be resolved to absolute file path
                 Key: WFLY-2265
                 URL: https://issues.jboss.org/browse/WFLY-2265
             Project: WildFly
          Issue Type: Bug
          Components: Web (JBoss Web)
    Affects Versions: 8.0.0.Beta1
         Environment: Windows 7
            Reporter: zhihong liu
            Assignee: Remy Maucherat
             Fix For: 8.0.0.Beta1


In windows , when use the WebUtils.getRealPath("config-data/TESTDEV") , it returns error message : ServletContext resource [/config-data/TESTDEV] cannot be resolved to absolute file path.

 but WebUtils.getRealPath("/") can return the true path . that is to say , this method can't parse the backslash followed by a string . but it works good in linux/unix .

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct  8 23:10:03 2013
From: jira-events at lists.jboss.org (zhihong liu (JIRA))
Date: Tue, 8 Oct 2013 23:10:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2265)
 WebUtils#getRealPath("config-data/TESTDEV") cannot be resolved to absolute
 file path
In-Reply-To: <JIRA.12502507.1381287850000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502507.1381287850000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502507.1381287850000.26373.1381288203037@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

zhihong liu updated WFLY-2265:
------------------------------

    Summary: WebUtils#getRealPath("config-data/TESTDEV") cannot be resolved to absolute file path  (was: WebUtils#getRealPath("/config-data") cannot be resolved to absolute file path)

    
> WebUtils#getRealPath("config-data/TESTDEV") cannot be resolved to absolute file path
> ------------------------------------------------------------------------------------
>
>                 Key: WFLY-2265
>                 URL: https://issues.jboss.org/browse/WFLY-2265
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (JBoss Web)
>    Affects Versions: 8.0.0.Beta1
>         Environment: Windows 7
>            Reporter: zhihong liu
>            Assignee: Remy Maucherat
>              Labels: jboss
>             Fix For: 8.0.0.Beta1
>
>   Original Estimate: 3 weeks
>  Remaining Estimate: 3 weeks
>
> In windows , when use the WebUtils.getRealPath("config-data/TESTDEV") , it returns error message : ServletContext resource [/config-data/TESTDEV] cannot be resolved to absolute file path.
>  but WebUtils.getRealPath("/") can return the true path . that is to say , this method can't parse the backslash followed by a string . but it works good in linux/unix .

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 00:49:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 9 Oct 2013 00:49:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2093) No any log generated after
 changing periodic-rotating-file-handler to size-rotating-file-handler
In-Reply-To: <JIRA.12500810.1379401775000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500810.1379401775000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500810.1379401775000.26396.1381294142930@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812486#comment-12812486 ] 

RH Bugzilla Integration commented on WFLY-2093:
-----------------------------------------------

xiaohui Wu <xiwu at redhat.com> made a comment on [bug 1008806|https://bugzilla.redhat.com/show_bug.cgi?id=1008806]

To Ondrej Lukas:
There are no other more steps, but you need a fresh EAP6.1.1 or EAP6.1.0.

(In reply to Ondrej Lukas from comment #8)
> I tried to reproduce it according your steps, but it always works fine for
> me. It logs WARN message but it writes another logs which looks right as
> usual. Is there any other needed configuration please? I can't verify it for
> that reason.
                
> No any log generated after changing periodic-rotating-file-handler to size-rotating-file-handler
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2093
>                 URL: https://issues.jboss.org/browse/WFLY-2093
>             Project: WildFly
>          Issue Type: Bug
>          Components: Logging
>            Reporter: Xiaohui Wu
>            Assignee: James Perkins
>
> There is no any log in the server.log after changing periodic-rotating-file-handler to size-rotating-file-handler.
> The reproduce steps:
> 1. remove the part periodic-rotating-file-handler in standalone.xml
>             <periodic-rotating-file-handler name="FILE">
>                 <formatter>
>                     <pattern-formatter pattern="%d{HH:mm:ss.SSS} %-5p [%c] (%t) %s%E%n"/>
>                 </formatter>
>                 <file relative-to="jboss.server.log.dir" path="server.log"/>
>                 <suffix value=".yyyy-MM-dd"/>
>                 <append value="true"/>
>             </periodic-rotating-file-handler>
> 2. add one size-rotating-file-handler
>             <size-rotating-file-handler name="FILE" autoflush="true">
>                 <formatter>
>                     <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p (%c) [%t] %s%E%n"/>
>                 </formatter>
>                 <file relative-to="jboss.server.log.dir" path="server.log"/>
>                 <rotate-size value="500k"/>
>                 <max-backup-index value="15"/>
>                 <append value="true"/>
>             </size-rotating-file-handler>
> 3. start the jboss server, then you will see there is a warning in the server.log and no any further logs in the server.log.
> 13:23:28,205 WARN  [org.jboss.as.logging] (Controller Boot Thread) JBAS011511: Replacing handler 'FILE' during add operation. Either the handler type or the module name differs from the initial configuration.
> The possible fix: 
> https://issues.jboss.org/browse/WFLY-178 the code change is in https://github.com/wildfly/wildfly/pull/4137 
> and the bugzilla is in EAP6.1.0: 
> https://bugzilla.redhat.com/show_bug.cgi?id=918103
> But this issue still exists in 6.1.1
> Best Regards,
> Vicky

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 01:08:02 2013
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Wed, 9 Oct 2013 01:08:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2261) standalone.sh --debug without
 port number not working
In-Reply-To: <JIRA.12502486.1381251288000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502486.1381251288000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502486.1381251288000.26409.1381295282596@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky updated WFLY-2261:
------------------------------------

    Component/s: Scripts
                     (was: CLI)

    
> standalone.sh --debug without port number not working 
> ------------------------------------------------------
>
>                 Key: WFLY-2261
>                 URL: https://issues.jboss.org/browse/WFLY-2261
>             Project: WildFly
>          Issue Type: Bug
>          Components: Scripts
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Cheng Fang
>            Assignee: Alexey Loubyansky
>
> ./standalone.sh --debug port-num works, but it failed when omitting port number.
> sh -x standalone.sh --debug  (expecting the default port 8787 to be used)
> {noformat}
> + eval '"/Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/bin/java"' '-D"[Standalone]"' -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n '"-Dorg.jboss.boot.log.file=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/log/server.log"' '"-Dlogging.configuration=file:/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/configuration/logging.properties"' -jar '"/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/jboss-modules.jar"' -mp '"/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/modules"' org.jboss.as.standalone '-Djboss.home.dir="/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT"' '-Djboss.server.base.dir="/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone"' ' ""'
> ++ /Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/bin/java '-D[Standalone]' -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n -Dorg.jboss.boot.log.file=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/log/server.log -Dlogging.configuration=file:/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/configuration/logging.properties -jar /Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/jboss-modules.jar -mp /Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/modules org.jboss.as.standalone -Djboss.home.dir=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT -Djboss.server.base.dir=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone ''
> Listening for transport dt_socket at address: 8787
> 12:19:36,715 INFO  [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final
> 12:19:36,886 ERROR [stderr] (main) JBAS015801: Invalid option ''
> 12:19:36,893 INFO  [stdout] (main)
> 12:19:36,893 INFO  [stdout] (main) Usage: standalone.sh [args...]
> {noformat}
> sh -x standalone.sh --debug 8787 (the working command)
> {noformat}
> + eval '"/Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/bin/java"' '-D"[Standalone]"' -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n '"-Dorg.jboss.boot.log.file=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/log/server.log"' '"-Dlogging.configuration=file:/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/configuration/logging.properties"' -jar '"/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/jboss-modules.jar"' -mp '"/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/modules"' org.jboss.as.standalone '-Djboss.home.dir="/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT"' '-Djboss.server.base.dir="/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone"' ''
> ++ /Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/bin/java '-D[Standalone]' -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n -Dorg.jboss.boot.log.file=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/log/server.log -Dlogging.configuration=file:/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/configuration/logging.properties -jar /Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/jboss-modules.jar -mp /Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/modules org.jboss.as.standalone -Djboss.home.dir=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT -Djboss.server.base.dir=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone
> Listening for transport dt_socket at address: 8787
> 12:20:39,251 INFO  [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final
> 12:20:39,626 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.0.Beta2
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Wed Oct  9 01:08:02 2013
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Wed, 9 Oct 2013 01:08:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2261) standalone.sh --debug without
 port number not working
In-Reply-To: <JIRA.12502486.1381251288000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502486.1381251288000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502486.1381251288000.26412.1381295282739@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky updated WFLY-2261:
------------------------------------

    Assignee: Brian Stansberry  (was: Alexey Loubyansky)

    
> standalone.sh --debug without port number not working 
> ------------------------------------------------------
>
>                 Key: WFLY-2261
>                 URL: https://issues.jboss.org/browse/WFLY-2261
>             Project: WildFly
>          Issue Type: Bug
>          Components: Scripts
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Cheng Fang
>            Assignee: Brian Stansberry
>
> ./standalone.sh --debug port-num works, but it failed when omitting port number.
> sh -x standalone.sh --debug  (expecting the default port 8787 to be used)
> {noformat}
> + eval '"/Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/bin/java"' '-D"[Standalone]"' -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n '"-Dorg.jboss.boot.log.file=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/log/server.log"' '"-Dlogging.configuration=file:/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/configuration/logging.properties"' -jar '"/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/jboss-modules.jar"' -mp '"/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/modules"' org.jboss.as.standalone '-Djboss.home.dir="/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT"' '-Djboss.server.base.dir="/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone"' ' ""'
> ++ /Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/bin/java '-D[Standalone]' -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n -Dorg.jboss.boot.log.file=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/log/server.log -Dlogging.configuration=file:/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/configuration/logging.properties -jar /Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/jboss-modules.jar -mp /Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/modules org.jboss.as.standalone -Djboss.home.dir=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT -Djboss.server.base.dir=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone ''
> Listening for transport dt_socket at address: 8787
> 12:19:36,715 INFO  [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final
> 12:19:36,886 ERROR [stderr] (main) JBAS015801: Invalid option ''
> 12:19:36,893 INFO  [stdout] (main)
> 12:19:36,893 INFO  [stdout] (main) Usage: standalone.sh [args...]
> {noformat}
> sh -x standalone.sh --debug 8787 (the working command)
> {noformat}
> + eval '"/Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/bin/java"' '-D"[Standalone]"' -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n '"-Dorg.jboss.boot.log.file=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/log/server.log"' '"-Dlogging.configuration=file:/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/configuration/logging.properties"' -jar '"/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/jboss-modules.jar"' -mp '"/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/modules"' org.jboss.as.standalone '-Djboss.home.dir="/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT"' '-Djboss.server.base.dir="/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone"' ''
> ++ /Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/bin/java '-D[Standalone]' -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n -Dorg.jboss.boot.log.file=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/log/server.log -Dlogging.configuration=file:/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/configuration/logging.properties -jar /Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/jboss-modules.jar -mp /Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/modules org.jboss.as.standalone -Djboss.home.dir=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT -Djboss.server.base.dir=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone
> Listening for transport dt_socket at address: 8787
> 12:20:39,251 INFO  [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final
> 12:20:39,626 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.0.Beta2
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Wed Oct  9 01:31:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 9 Oct 2013 01:31:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2093) No any log generated after
 changing periodic-rotating-file-handler to size-rotating-file-handler
In-Reply-To: <JIRA.12500810.1379401775000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500810.1379401775000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500810.1379401775000.26419.1381296662752@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812488#comment-12812488 ] 

RH Bugzilla Integration commented on WFLY-2093:
-----------------------------------------------

Ondrej Lukas <olukas at redhat.com> made a comment on [bug 1008806|https://bugzilla.redhat.com/show_bug.cgi?id=1008806]

Thanks for reply, but I still can't reproduce it. However PR was merged to JBoss EAP and in EAP 6.2.0.ER4 it has expected behavior. Could you take a look on that please and are you ok with I verified it?
                
> No any log generated after changing periodic-rotating-file-handler to size-rotating-file-handler
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2093
>                 URL: https://issues.jboss.org/browse/WFLY-2093
>             Project: WildFly
>          Issue Type: Bug
>          Components: Logging
>            Reporter: Xiaohui Wu
>            Assignee: James Perkins
>
> There is no any log in the server.log after changing periodic-rotating-file-handler to size-rotating-file-handler.
> The reproduce steps:
> 1. remove the part periodic-rotating-file-handler in standalone.xml
>             <periodic-rotating-file-handler name="FILE">
>                 <formatter>
>                     <pattern-formatter pattern="%d{HH:mm:ss.SSS} %-5p [%c] (%t) %s%E%n"/>
>                 </formatter>
>                 <file relative-to="jboss.server.log.dir" path="server.log"/>
>                 <suffix value=".yyyy-MM-dd"/>
>                 <append value="true"/>
>             </periodic-rotating-file-handler>
> 2. add one size-rotating-file-handler
>             <size-rotating-file-handler name="FILE" autoflush="true">
>                 <formatter>
>                     <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p (%c) [%t] %s%E%n"/>
>                 </formatter>
>                 <file relative-to="jboss.server.log.dir" path="server.log"/>
>                 <rotate-size value="500k"/>
>                 <max-backup-index value="15"/>
>                 <append value="true"/>
>             </size-rotating-file-handler>
> 3. start the jboss server, then you will see there is a warning in the server.log and no any further logs in the server.log.
> 13:23:28,205 WARN  [org.jboss.as.logging] (Controller Boot Thread) JBAS011511: Replacing handler 'FILE' during add operation. Either the handler type or the module name differs from the initial configuration.
> The possible fix: 
> https://issues.jboss.org/browse/WFLY-178 the code change is in https://github.com/wildfly/wildfly/pull/4137 
> and the bugzilla is in EAP6.1.0: 
> https://bugzilla.redhat.com/show_bug.cgi?id=918103
> But this issue still exists in 6.1.1
> Best Regards,
> Vicky

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 02:23:02 2013
From: jira-events at lists.jboss.org (Lin Gao (JIRA))
Date: Wed, 9 Oct 2013 02:23:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1085) Generate aggregated javadoc
In-Reply-To: <JIRA.12501583.1380176984000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501583.1380176984000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501583.1380176984000.26454.1381299782547@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lin Gao updated JBJCA-1085:
---------------------------

    Git Pull Request: https://github.com/ironjacamar/ironjacamar/pull/78, https://github.com/ironjacamar/ironjacamar/pull/79  (was: https://github.com/ironjacamar/ironjacamar/pull/78)

    
> Generate aggregated javadoc
> ---------------------------
>
>                 Key: JBJCA-1085
>                 URL: https://issues.jboss.org/browse/JBJCA-1085
>             Project: IronJacamar
>          Issue Type: Task
>            Reporter: Lin Gao
>            Assignee: Lin Gao
>
> Discussion at: https://groups.google.com/forum/#!topic/ironjacamar-developers/vjBJqmT07o8
> There would be 3 bundles
> All API / SPI packages
> Everything with as=false
> Everything with as=true

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 02:47:02 2013
From: jira-events at lists.jboss.org (Jay Kumar SenSharma (JIRA))
Date: Wed, 9 Oct 2013 02:47:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2266) Deployment Overlay feature is
 not able to replace the application libraries.
In-Reply-To: <JIRA.12502513.1381301201545@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502513.1381301201545@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502513.1381301201545.26514.1381301222827@jira02.app.mwc.hst.phx2.redhat.com>

Jay Kumar SenSharma created WFLY-2266:
-----------------------------------------

             Summary: Deployment Overlay feature is not able to replace the application libraries.
                 Key: WFLY-2266
                 URL: https://issues.jboss.org/browse/WFLY-2266
             Project: WildFly
          Issue Type: Bug
          Components: Domain Management
    Affects Versions: 8.0.0.Beta1
         Environment: All Operating Systems
            Reporter: Jay Kumar SenSharma
            Assignee: Brian Stansberry


-----------------------
   According to the documentation: [1] the deployment overlay feature is applicable for "swapping out deployment descriptors, modifying static web resources to change the branding of an application, or even replacing jar libraries with different versions."   

   Here it talks about "replacing jar libraries" which is not working as expected and causes  the following error.

[1] https://docs.jboss.org/author/display/AS72/Deployment+Overlays

Follow the below sequence of deployment and overlay:
Steps to Reproduce:
------------------
Step-1).
========= Undeploy if any existing application is deployed  and then freshly deploy the application.

[standalone at localhost:9999 /] undeploy DeploymentOverlayDemo.war 
[standalone at localhost:9999 /] deploy /home/jaysensharma/TestApp/build/DeploymentOverlayDemo.war


Step-2).
========= Make some changes in java code "Hello.java". Create a new JAR  Hello.jar which we want to replace at (/WEB-INF/lib/Hello.jar) using deployment-overlay feature.  In the attached ant basd Demo just do "ant compile"  to create a new Jar "${project.dir}/tmp/Hello.jar"


Step-3).
========= Use the following command in order to replace the "/WEB-INF/lib/Hello.jar" with the newly created Hello.jar using deployment overlay feature as following:

[standalone at localhost:9999 /] deployment-overlay add --name=myOverLay_1 --content=/WEB-INF/lib/Hello.jar=/home/jaysensharma/TestApp/tmp/Hello.jar --deployments=DeploymentOverlayDemo.war --redeploy-affected

  
   Above causes the following Exception:
++++++++++++++++++++++++++++++++++++++++
12:09:59,736 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS018224: Unregister web context: /DeploymentOverlayDemo
12:09:59,760 WARN  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017530: Could not delete servlet temp file /NotBackedUp/SVN_16_Jan/WildFly/build_Apps/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/tmp/DeploymentOverlayDemo.war/org/apache/jsp
12:09:59,761 WARN  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017530: Could not delete servlet temp file /NotBackedUp/SVN_16_Jan/WildFly/build_Apps/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/tmp/DeploymentOverlayDemo.war/org/apache
12:09:59,761 WARN  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017530: Could not delete servlet temp file /NotBackedUp/SVN_16_Jan/WildFly/build_Apps/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/tmp/DeploymentOverlayDemo.war/org
12:09:59,762 WARN  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017530: Could not delete servlet temp file /NotBackedUp/SVN_16_Jan/WildFly/build_Apps/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/tmp/DeploymentOverlayDemo.war
12:09:59,787 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015877: Stopped deployment DeploymentOverlayDemo.war (runtime-name: DeploymentOverlayDemo.war) in 56ms
12:09:59,789 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015876: Starting deployment of "DeploymentOverlayDemo.war" (runtime-name: "DeploymentOverlayDemo.war")
12:09:59,799 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."DeploymentOverlayDemo.war".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit."DeploymentOverlayDemo.war".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment "DeploymentOverlayDemo.war"
	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018776: Failed to get content for deployment overlay myOverLay_1 at /WEB-INF/lib/Hello.jar
	at org.jboss.as.server.deployment.ContentOverrideDeploymentUnitProcessor.deploy(ContentOverrideDeploymentUnitProcessor.java:70) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	... 5 more
Caused by: java.io.IOException: VFS000017: Filesystem already mounted at mount point ""/content/DeploymentOverlayDemo.war/WEB-INF/lib/Hello.jar""
	at org.jboss.vfs.VFS.mount(VFS.java:127) [jboss-vfs-3.2.2.Final.jar:3.2.2.Final]
	at org.jboss.vfs.VFS.doMount(VFS.java:336) [jboss-vfs-3.2.2.Final.jar:3.2.2.Final]
	at org.jboss.vfs.VFS.mountReal(VFS.java:423) [jboss-vfs-3.2.2.Final.jar:3.2.2.Final]
	at org.jboss.as.server.deployment.ContentOverrideDeploymentUnitProcessor.deploy(ContentOverrideDeploymentUnitProcessor.java:67) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	... 6 more

12:09:59,805 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) JBAS014613: Operation ("redeploy") failed - address: ([("deployment" => "DeploymentOverlayDemo.war")]) - failure description: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"DeploymentOverlayDemo.war\".STRUCTURE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"DeploymentOverlayDemo.war\".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment \"DeploymentOverlayDemo.war\"
    Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018776: Failed to get content for deployment overlay myOverLay_1 at /WEB-INF/lib/Hello.jar
    Caused by: java.io.IOException: VFS000017: Filesystem already mounted at mount point \"\"/content/DeploymentOverlayDemo.war/WEB-INF/lib/Hello.jar\"\""}}
12:09:59,809 ERROR [org.jboss.as.server] (management-handler-thread - 3) JBAS015860: Redeploy of deployment "DeploymentOverlayDemo.war" was rolled back with the following failure message: 
{"JBAS014671: Failed services" => {"jboss.deployment.unit.\"DeploymentOverlayDemo.war\".STRUCTURE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"DeploymentOverlayDemo.war\".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment \"DeploymentOverlayDemo.war\"
    Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018776: Failed to get content for deployment overlay myOverLay_1 at /WEB-INF/lib/Hello.jar
    Caused by: java.io.IOException: VFS000017: Filesystem already mounted at mount point \"\"/content/DeploymentOverlayDemo.war/WEB-INF/lib/Hello.jar\"\""}}
12:09:59,814 INFO  [org.jboss.as.controller] (management-handler-thread - 3) JBAS014774: Service status report
JBAS014777:   Services which failed to start:      service jboss.deployment.unit."DeploymentOverlayDemo.war".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit."DeploymentOverlayDemo.war".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment "DeploymentOverlayDemo.war"
++++++++++++++++++++++++++++++++++++++++

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 02:53:02 2013
From: jira-events at lists.jboss.org (Jay Kumar SenSharma (JIRA))
Date: Wed, 9 Oct 2013 02:53:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2266) Deployment Overlay feature is
 not able to replace the application libraries.
In-Reply-To: <JIRA.12502513.1381301201000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502513.1381301201000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502513.1381301201000.26531.1381301582842@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jay Kumar SenSharma updated WFLY-2266:
--------------------------------------

    Description: 
-----------------------
   According to the documentation: [1] the deployment overlay feature is applicable for "swapping out deployment descriptors, modifying static web resources to change the branding of an application, or even replacing jar libraries with different versions."   

   Here it talks about "replacing jar libraries" which is not working as expected and causes  the following error.

[1] https://docs.jboss.org/author/display/AS72/Deployment+Overlays

Follow the below sequence of deployment and overlay:
Steps to Reproduce:
------------------
Step-1).
========= Undeploy if any existing application is deployed  and then freshly deploy the application.
{quote}
[standalone at localhost:9999 /] undeploy DeploymentOverlayDemo.war 
[standalone at localhost:9999 /] deploy /home/jaysensharma/TestApp/build/DeploymentOverlayDemo.war
{quote}

Step-2).
========= Make some changes in java code "Hello.java". Create a new JAR  Hello.jar which we want to replace at (/WEB-INF/lib/Hello.jar) using deployment-overlay feature.  In the attached ant basd Demo just do "ant compile"  to create a new Jar "${project.dir}/tmp/Hello.jar"


Step-3).
========= Use the following command in order to replace the "/WEB-INF/lib/Hello.jar" with the newly created Hello.jar using deployment overlay feature as following:
{quote}
[standalone at localhost:9999 /] deployment-overlay add --name=myOverLay_1 --content=/WEB-INF/lib/Hello.jar=/home/jaysensharma/TestApp/tmp/Hello.jar --deployments=DeploymentOverlayDemo.war --redeploy-affected
{quote}
  
   Above causes the following Exception:
{quote}
12:09:59,736 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS018224: Unregister web context: /DeploymentOverlayDemo
12:09:59,760 WARN  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017530: Could not delete servlet temp file /NotBackedUp/SVN_16_Jan/WildFly/build_Apps/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/tmp/DeploymentOverlayDemo.war/org/apache/jsp
12:09:59,761 WARN  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017530: Could not delete servlet temp file /NotBackedUp/SVN_16_Jan/WildFly/build_Apps/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/tmp/DeploymentOverlayDemo.war/org/apache
12:09:59,761 WARN  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017530: Could not delete servlet temp file /NotBackedUp/SVN_16_Jan/WildFly/build_Apps/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/tmp/DeploymentOverlayDemo.war/org
12:09:59,762 WARN  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017530: Could not delete servlet temp file /NotBackedUp/SVN_16_Jan/WildFly/build_Apps/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/tmp/DeploymentOverlayDemo.war
12:09:59,787 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015877: Stopped deployment DeploymentOverlayDemo.war (runtime-name: DeploymentOverlayDemo.war) in 56ms
12:09:59,789 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015876: Starting deployment of "DeploymentOverlayDemo.war" (runtime-name: "DeploymentOverlayDemo.war")
12:09:59,799 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."DeploymentOverlayDemo.war".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit."DeploymentOverlayDemo.war".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment "DeploymentOverlayDemo.war"
	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018776: Failed to get content for deployment overlay myOverLay_1 at /WEB-INF/lib/Hello.jar
	at org.jboss.as.server.deployment.ContentOverrideDeploymentUnitProcessor.deploy(ContentOverrideDeploymentUnitProcessor.java:70) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	... 5 more
Caused by: java.io.IOException: VFS000017: Filesystem already mounted at mount point ""/content/DeploymentOverlayDemo.war/WEB-INF/lib/Hello.jar""
	at org.jboss.vfs.VFS.mount(VFS.java:127) [jboss-vfs-3.2.2.Final.jar:3.2.2.Final]
	at org.jboss.vfs.VFS.doMount(VFS.java:336) [jboss-vfs-3.2.2.Final.jar:3.2.2.Final]
	at org.jboss.vfs.VFS.mountReal(VFS.java:423) [jboss-vfs-3.2.2.Final.jar:3.2.2.Final]
	at org.jboss.as.server.deployment.ContentOverrideDeploymentUnitProcessor.deploy(ContentOverrideDeploymentUnitProcessor.java:67) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	... 6 more

12:09:59,805 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) JBAS014613: Operation ("redeploy") failed - address: ([("deployment" => "DeploymentOverlayDemo.war")]) - failure description: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"DeploymentOverlayDemo.war\".STRUCTURE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"DeploymentOverlayDemo.war\".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment \"DeploymentOverlayDemo.war\"
    Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018776: Failed to get content for deployment overlay myOverLay_1 at /WEB-INF/lib/Hello.jar
    Caused by: java.io.IOException: VFS000017: Filesystem already mounted at mount point \"\"/content/DeploymentOverlayDemo.war/WEB-INF/lib/Hello.jar\"\""}}
12:09:59,809 ERROR [org.jboss.as.server] (management-handler-thread - 3) JBAS015860: Redeploy of deployment "DeploymentOverlayDemo.war" was rolled back with the following failure message: 
{"JBAS014671: Failed services" => {"jboss.deployment.unit.\"DeploymentOverlayDemo.war\".STRUCTURE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"DeploymentOverlayDemo.war\".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment \"DeploymentOverlayDemo.war\"
    Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018776: Failed to get content for deployment overlay myOverLay_1 at /WEB-INF/lib/Hello.jar
    Caused by: java.io.IOException: VFS000017: Filesystem already mounted at mount point \"\"/content/DeploymentOverlayDemo.war/WEB-INF/lib/Hello.jar\"\""}}
12:09:59,814 INFO  [org.jboss.as.controller] (management-handler-thread - 3) JBAS014774: Service status report
JBAS014777:   Services which failed to start:      service jboss.deployment.unit."DeploymentOverlayDemo.war".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit."DeploymentOverlayDemo.war".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment "DeploymentOverlayDemo.war"
{quote}

  was:
-----------------------
   According to the documentation: [1] the deployment overlay feature is applicable for "swapping out deployment descriptors, modifying static web resources to change the branding of an application, or even replacing jar libraries with different versions."   

   Here it talks about "replacing jar libraries" which is not working as expected and causes  the following error.

[1] https://docs.jboss.org/author/display/AS72/Deployment+Overlays

Follow the below sequence of deployment and overlay:
Steps to Reproduce:
------------------
Step-1).
========= Undeploy if any existing application is deployed  and then freshly deploy the application.

[standalone at localhost:9999 /] undeploy DeploymentOverlayDemo.war 
[standalone at localhost:9999 /] deploy /home/jaysensharma/TestApp/build/DeploymentOverlayDemo.war


Step-2).
========= Make some changes in java code "Hello.java". Create a new JAR  Hello.jar which we want to replace at (/WEB-INF/lib/Hello.jar) using deployment-overlay feature.  In the attached ant basd Demo just do "ant compile"  to create a new Jar "${project.dir}/tmp/Hello.jar"


Step-3).
========= Use the following command in order to replace the "/WEB-INF/lib/Hello.jar" with the newly created Hello.jar using deployment overlay feature as following:

[standalone at localhost:9999 /] deployment-overlay add --name=myOverLay_1 --content=/WEB-INF/lib/Hello.jar=/home/jaysensharma/TestApp/tmp/Hello.jar --deployments=DeploymentOverlayDemo.war --redeploy-affected

  
   Above causes the following Exception:
++++++++++++++++++++++++++++++++++++++++
12:09:59,736 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS018224: Unregister web context: /DeploymentOverlayDemo
12:09:59,760 WARN  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017530: Could not delete servlet temp file /NotBackedUp/SVN_16_Jan/WildFly/build_Apps/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/tmp/DeploymentOverlayDemo.war/org/apache/jsp
12:09:59,761 WARN  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017530: Could not delete servlet temp file /NotBackedUp/SVN_16_Jan/WildFly/build_Apps/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/tmp/DeploymentOverlayDemo.war/org/apache
12:09:59,761 WARN  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017530: Could not delete servlet temp file /NotBackedUp/SVN_16_Jan/WildFly/build_Apps/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/tmp/DeploymentOverlayDemo.war/org
12:09:59,762 WARN  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017530: Could not delete servlet temp file /NotBackedUp/SVN_16_Jan/WildFly/build_Apps/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/tmp/DeploymentOverlayDemo.war
12:09:59,787 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015877: Stopped deployment DeploymentOverlayDemo.war (runtime-name: DeploymentOverlayDemo.war) in 56ms
12:09:59,789 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015876: Starting deployment of "DeploymentOverlayDemo.war" (runtime-name: "DeploymentOverlayDemo.war")
12:09:59,799 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."DeploymentOverlayDemo.war".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit."DeploymentOverlayDemo.war".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment "DeploymentOverlayDemo.war"
	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018776: Failed to get content for deployment overlay myOverLay_1 at /WEB-INF/lib/Hello.jar
	at org.jboss.as.server.deployment.ContentOverrideDeploymentUnitProcessor.deploy(ContentOverrideDeploymentUnitProcessor.java:70) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	... 5 more
Caused by: java.io.IOException: VFS000017: Filesystem already mounted at mount point ""/content/DeploymentOverlayDemo.war/WEB-INF/lib/Hello.jar""
	at org.jboss.vfs.VFS.mount(VFS.java:127) [jboss-vfs-3.2.2.Final.jar:3.2.2.Final]
	at org.jboss.vfs.VFS.doMount(VFS.java:336) [jboss-vfs-3.2.2.Final.jar:3.2.2.Final]
	at org.jboss.vfs.VFS.mountReal(VFS.java:423) [jboss-vfs-3.2.2.Final.jar:3.2.2.Final]
	at org.jboss.as.server.deployment.ContentOverrideDeploymentUnitProcessor.deploy(ContentOverrideDeploymentUnitProcessor.java:67) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	... 6 more

12:09:59,805 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) JBAS014613: Operation ("redeploy") failed - address: ([("deployment" => "DeploymentOverlayDemo.war")]) - failure description: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"DeploymentOverlayDemo.war\".STRUCTURE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"DeploymentOverlayDemo.war\".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment \"DeploymentOverlayDemo.war\"
    Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018776: Failed to get content for deployment overlay myOverLay_1 at /WEB-INF/lib/Hello.jar
    Caused by: java.io.IOException: VFS000017: Filesystem already mounted at mount point \"\"/content/DeploymentOverlayDemo.war/WEB-INF/lib/Hello.jar\"\""}}
12:09:59,809 ERROR [org.jboss.as.server] (management-handler-thread - 3) JBAS015860: Redeploy of deployment "DeploymentOverlayDemo.war" was rolled back with the following failure message: 
{"JBAS014671: Failed services" => {"jboss.deployment.unit.\"DeploymentOverlayDemo.war\".STRUCTURE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"DeploymentOverlayDemo.war\".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment \"DeploymentOverlayDemo.war\"
    Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018776: Failed to get content for deployment overlay myOverLay_1 at /WEB-INF/lib/Hello.jar
    Caused by: java.io.IOException: VFS000017: Filesystem already mounted at mount point \"\"/content/DeploymentOverlayDemo.war/WEB-INF/lib/Hello.jar\"\""}}
12:09:59,814 INFO  [org.jboss.as.controller] (management-handler-thread - 3) JBAS014774: Service status report
JBAS014777:   Services which failed to start:      service jboss.deployment.unit."DeploymentOverlayDemo.war".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit."DeploymentOverlayDemo.war".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment "DeploymentOverlayDemo.war"
++++++++++++++++++++++++++++++++++++++++


    
> Deployment Overlay feature is not able to replace the application libraries.
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-2266
>                 URL: https://issues.jboss.org/browse/WFLY-2266
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 8.0.0.Beta1
>         Environment: All Operating Systems
>            Reporter: Jay Kumar SenSharma
>            Assignee: Brian Stansberry
>              Labels: deployment
>
> -----------------------
>    According to the documentation: [1] the deployment overlay feature is applicable for "swapping out deployment descriptors, modifying static web resources to change the branding of an application, or even replacing jar libraries with different versions."   
>    Here it talks about "replacing jar libraries" which is not working as expected and causes  the following error.
> [1] https://docs.jboss.org/author/display/AS72/Deployment+Overlays
> Follow the below sequence of deployment and overlay:
> Steps to Reproduce:
> ------------------
> Step-1).
> ========= Undeploy if any existing application is deployed  and then freshly deploy the application.
> {quote}
> [standalone at localhost:9999 /] undeploy DeploymentOverlayDemo.war 
> [standalone at localhost:9999 /] deploy /home/jaysensharma/TestApp/build/DeploymentOverlayDemo.war
> {quote}
> Step-2).
> ========= Make some changes in java code "Hello.java". Create a new JAR  Hello.jar which we want to replace at (/WEB-INF/lib/Hello.jar) using deployment-overlay feature.  In the attached ant basd Demo just do "ant compile"  to create a new Jar "${project.dir}/tmp/Hello.jar"
> Step-3).
> ========= Use the following command in order to replace the "/WEB-INF/lib/Hello.jar" with the newly created Hello.jar using deployment overlay feature as following:
> {quote}
> [standalone at localhost:9999 /] deployment-overlay add --name=myOverLay_1 --content=/WEB-INF/lib/Hello.jar=/home/jaysensharma/TestApp/tmp/Hello.jar --deployments=DeploymentOverlayDemo.war --redeploy-affected
> {quote}
>   
>    Above causes the following Exception:
> {quote}
> 12:09:59,736 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS018224: Unregister web context: /DeploymentOverlayDemo
> 12:09:59,760 WARN  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017530: Could not delete servlet temp file /NotBackedUp/SVN_16_Jan/WildFly/build_Apps/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/tmp/DeploymentOverlayDemo.war/org/apache/jsp
> 12:09:59,761 WARN  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017530: Could not delete servlet temp file /NotBackedUp/SVN_16_Jan/WildFly/build_Apps/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/tmp/DeploymentOverlayDemo.war/org/apache
> 12:09:59,761 WARN  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017530: Could not delete servlet temp file /NotBackedUp/SVN_16_Jan/WildFly/build_Apps/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/tmp/DeploymentOverlayDemo.war/org
> 12:09:59,762 WARN  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017530: Could not delete servlet temp file /NotBackedUp/SVN_16_Jan/WildFly/build_Apps/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/tmp/DeploymentOverlayDemo.war
> 12:09:59,787 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015877: Stopped deployment DeploymentOverlayDemo.war (runtime-name: DeploymentOverlayDemo.war) in 56ms
> 12:09:59,789 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015876: Starting deployment of "DeploymentOverlayDemo.war" (runtime-name: "DeploymentOverlayDemo.war")
> 12:09:59,799 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."DeploymentOverlayDemo.war".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit."DeploymentOverlayDemo.war".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment "DeploymentOverlayDemo.war"
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018776: Failed to get content for deployment overlay myOverLay_1 at /WEB-INF/lib/Hello.jar
> 	at org.jboss.as.server.deployment.ContentOverrideDeploymentUnitProcessor.deploy(ContentOverrideDeploymentUnitProcessor.java:70) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	... 5 more
> Caused by: java.io.IOException: VFS000017: Filesystem already mounted at mount point ""/content/DeploymentOverlayDemo.war/WEB-INF/lib/Hello.jar""
> 	at org.jboss.vfs.VFS.mount(VFS.java:127) [jboss-vfs-3.2.2.Final.jar:3.2.2.Final]
> 	at org.jboss.vfs.VFS.doMount(VFS.java:336) [jboss-vfs-3.2.2.Final.jar:3.2.2.Final]
> 	at org.jboss.vfs.VFS.mountReal(VFS.java:423) [jboss-vfs-3.2.2.Final.jar:3.2.2.Final]
> 	at org.jboss.as.server.deployment.ContentOverrideDeploymentUnitProcessor.deploy(ContentOverrideDeploymentUnitProcessor.java:67) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	... 6 more
> 12:09:59,805 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) JBAS014613: Operation ("redeploy") failed - address: ([("deployment" => "DeploymentOverlayDemo.war")]) - failure description: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"DeploymentOverlayDemo.war\".STRUCTURE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"DeploymentOverlayDemo.war\".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment \"DeploymentOverlayDemo.war\"
>     Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018776: Failed to get content for deployment overlay myOverLay_1 at /WEB-INF/lib/Hello.jar
>     Caused by: java.io.IOException: VFS000017: Filesystem already mounted at mount point \"\"/content/DeploymentOverlayDemo.war/WEB-INF/lib/Hello.jar\"\""}}
> 12:09:59,809 ERROR [org.jboss.as.server] (management-handler-thread - 3) JBAS015860: Redeploy of deployment "DeploymentOverlayDemo.war" was rolled back with the following failure message: 
> {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"DeploymentOverlayDemo.war\".STRUCTURE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"DeploymentOverlayDemo.war\".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment \"DeploymentOverlayDemo.war\"
>     Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018776: Failed to get content for deployment overlay myOverLay_1 at /WEB-INF/lib/Hello.jar
>     Caused by: java.io.IOException: VFS000017: Filesystem already mounted at mount point \"\"/content/DeploymentOverlayDemo.war/WEB-INF/lib/Hello.jar\"\""}}
> 12:09:59,814 INFO  [org.jboss.as.controller] (management-handler-thread - 3) JBAS014774: Service status report
> JBAS014777:   Services which failed to start:      service jboss.deployment.unit."DeploymentOverlayDemo.war".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit."DeploymentOverlayDemo.war".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment "DeploymentOverlayDemo.war"
> {quote}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 02:55:03 2013
From: jira-events at lists.jboss.org (Jay Kumar SenSharma (JIRA))
Date: Wed, 9 Oct 2013 02:55:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2266) Deployment Overlay feature is
 not able to replace the application libraries.
In-Reply-To: <JIRA.12502513.1381301201000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502513.1381301201000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502513.1381301201000.26548.1381301703298@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jay Kumar SenSharma updated WFLY-2266:
--------------------------------------

    Description: 
-----------------------
   According to the documentation: [1] the deployment overlay feature is applicable for "swapping out deployment descriptors, modifying static web resources to change the branding of an application, or even replacing jar libraries with different versions."   

   Here it talks about "replacing jar libraries" which is not working as expected and causes  the following error.

[1] https://docs.jboss.org/author/display/AS72/Deployment+Overlays

Follow the below sequence of deployment and overlay:
Steps to Reproduce:
------------------
*Step-1).* Undeploy if any existing application is deployed  and then freshly deploy the application.
{quote}
[standalone at localhost:9999 /] undeploy DeploymentOverlayDemo.war 
[standalone at localhost:9999 /] deploy /home/jaysensharma/TestApp/build/DeploymentOverlayDemo.war
{quote}

*Step-2).* Make some changes in java code _"Hello.java"_ . Create a new JAR  Hello.jar which we want to replace at _(/WEB-INF/lib/Hello.jar)_ using deployment-overlay feature.  In the attached ant based Demo just do _"ant compile"_  to create a new Jar _"${project.dir}/tmp/Hello.jar"_


*Step-3).* Use the following command in order to replace the "/WEB-INF/lib/Hello.jar" with the newly created Hello.jar using deployment overlay feature as following:
{quote}
[standalone at localhost:9999 /] deployment-overlay add --name=myOverLay_1 --content=/WEB-INF/lib/Hello.jar=/home/jaysensharma/TestApp/tmp/Hello.jar --deployments=DeploymentOverlayDemo.war --redeploy-affected
{quote}
  
   Above causes the following Exception:
{quote}
12:09:59,736 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS018224: Unregister web context: /DeploymentOverlayDemo
12:09:59,760 WARN  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017530: Could not delete servlet temp file /NotBackedUp/SVN_16_Jan/WildFly/build_Apps/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/tmp/DeploymentOverlayDemo.war/org/apache/jsp
12:09:59,761 WARN  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017530: Could not delete servlet temp file /NotBackedUp/SVN_16_Jan/WildFly/build_Apps/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/tmp/DeploymentOverlayDemo.war/org/apache
12:09:59,761 WARN  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017530: Could not delete servlet temp file /NotBackedUp/SVN_16_Jan/WildFly/build_Apps/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/tmp/DeploymentOverlayDemo.war/org
12:09:59,762 WARN  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017530: Could not delete servlet temp file /NotBackedUp/SVN_16_Jan/WildFly/build_Apps/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/tmp/DeploymentOverlayDemo.war
12:09:59,787 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015877: Stopped deployment DeploymentOverlayDemo.war (runtime-name: DeploymentOverlayDemo.war) in 56ms
12:09:59,789 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015876: Starting deployment of "DeploymentOverlayDemo.war" (runtime-name: "DeploymentOverlayDemo.war")
12:09:59,799 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."DeploymentOverlayDemo.war".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit."DeploymentOverlayDemo.war".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment "DeploymentOverlayDemo.war"
	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018776: Failed to get content for deployment overlay myOverLay_1 at /WEB-INF/lib/Hello.jar
	at org.jboss.as.server.deployment.ContentOverrideDeploymentUnitProcessor.deploy(ContentOverrideDeploymentUnitProcessor.java:70) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	... 5 more
Caused by: java.io.IOException: VFS000017: Filesystem already mounted at mount point ""/content/DeploymentOverlayDemo.war/WEB-INF/lib/Hello.jar""
	at org.jboss.vfs.VFS.mount(VFS.java:127) [jboss-vfs-3.2.2.Final.jar:3.2.2.Final]
	at org.jboss.vfs.VFS.doMount(VFS.java:336) [jboss-vfs-3.2.2.Final.jar:3.2.2.Final]
	at org.jboss.vfs.VFS.mountReal(VFS.java:423) [jboss-vfs-3.2.2.Final.jar:3.2.2.Final]
	at org.jboss.as.server.deployment.ContentOverrideDeploymentUnitProcessor.deploy(ContentOverrideDeploymentUnitProcessor.java:67) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	... 6 more

12:09:59,805 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) JBAS014613: Operation ("redeploy") failed - address: ([("deployment" => "DeploymentOverlayDemo.war")]) - failure description: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"DeploymentOverlayDemo.war\".STRUCTURE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"DeploymentOverlayDemo.war\".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment \"DeploymentOverlayDemo.war\"
    Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018776: Failed to get content for deployment overlay myOverLay_1 at /WEB-INF/lib/Hello.jar
    Caused by: java.io.IOException: VFS000017: Filesystem already mounted at mount point \"\"/content/DeploymentOverlayDemo.war/WEB-INF/lib/Hello.jar\"\""}}
12:09:59,809 ERROR [org.jboss.as.server] (management-handler-thread - 3) JBAS015860: Redeploy of deployment "DeploymentOverlayDemo.war" was rolled back with the following failure message: 
{"JBAS014671: Failed services" => {"jboss.deployment.unit.\"DeploymentOverlayDemo.war\".STRUCTURE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"DeploymentOverlayDemo.war\".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment \"DeploymentOverlayDemo.war\"
    Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018776: Failed to get content for deployment overlay myOverLay_1 at /WEB-INF/lib/Hello.jar
    Caused by: java.io.IOException: VFS000017: Filesystem already mounted at mount point \"\"/content/DeploymentOverlayDemo.war/WEB-INF/lib/Hello.jar\"\""}}
12:09:59,814 INFO  [org.jboss.as.controller] (management-handler-thread - 3) JBAS014774: Service status report
JBAS014777:   Services which failed to start:      service jboss.deployment.unit."DeploymentOverlayDemo.war".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit."DeploymentOverlayDemo.war".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment "DeploymentOverlayDemo.war"
{quote}

  was:
-----------------------
   According to the documentation: [1] the deployment overlay feature is applicable for "swapping out deployment descriptors, modifying static web resources to change the branding of an application, or even replacing jar libraries with different versions."   

   Here it talks about "replacing jar libraries" which is not working as expected and causes  the following error.

[1] https://docs.jboss.org/author/display/AS72/Deployment+Overlays

Follow the below sequence of deployment and overlay:
Steps to Reproduce:
------------------
Step-1).
========= Undeploy if any existing application is deployed  and then freshly deploy the application.
{quote}
[standalone at localhost:9999 /] undeploy DeploymentOverlayDemo.war 
[standalone at localhost:9999 /] deploy /home/jaysensharma/TestApp/build/DeploymentOverlayDemo.war
{quote}

Step-2).
========= Make some changes in java code "Hello.java". Create a new JAR  Hello.jar which we want to replace at (/WEB-INF/lib/Hello.jar) using deployment-overlay feature.  In the attached ant basd Demo just do "ant compile"  to create a new Jar "${project.dir}/tmp/Hello.jar"


Step-3).
========= Use the following command in order to replace the "/WEB-INF/lib/Hello.jar" with the newly created Hello.jar using deployment overlay feature as following:
{quote}
[standalone at localhost:9999 /] deployment-overlay add --name=myOverLay_1 --content=/WEB-INF/lib/Hello.jar=/home/jaysensharma/TestApp/tmp/Hello.jar --deployments=DeploymentOverlayDemo.war --redeploy-affected
{quote}
  
   Above causes the following Exception:
{quote}
12:09:59,736 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS018224: Unregister web context: /DeploymentOverlayDemo
12:09:59,760 WARN  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017530: Could not delete servlet temp file /NotBackedUp/SVN_16_Jan/WildFly/build_Apps/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/tmp/DeploymentOverlayDemo.war/org/apache/jsp
12:09:59,761 WARN  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017530: Could not delete servlet temp file /NotBackedUp/SVN_16_Jan/WildFly/build_Apps/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/tmp/DeploymentOverlayDemo.war/org/apache
12:09:59,761 WARN  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017530: Could not delete servlet temp file /NotBackedUp/SVN_16_Jan/WildFly/build_Apps/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/tmp/DeploymentOverlayDemo.war/org
12:09:59,762 WARN  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017530: Could not delete servlet temp file /NotBackedUp/SVN_16_Jan/WildFly/build_Apps/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/tmp/DeploymentOverlayDemo.war
12:09:59,787 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015877: Stopped deployment DeploymentOverlayDemo.war (runtime-name: DeploymentOverlayDemo.war) in 56ms
12:09:59,789 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015876: Starting deployment of "DeploymentOverlayDemo.war" (runtime-name: "DeploymentOverlayDemo.war")
12:09:59,799 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."DeploymentOverlayDemo.war".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit."DeploymentOverlayDemo.war".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment "DeploymentOverlayDemo.war"
	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018776: Failed to get content for deployment overlay myOverLay_1 at /WEB-INF/lib/Hello.jar
	at org.jboss.as.server.deployment.ContentOverrideDeploymentUnitProcessor.deploy(ContentOverrideDeploymentUnitProcessor.java:70) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	... 5 more
Caused by: java.io.IOException: VFS000017: Filesystem already mounted at mount point ""/content/DeploymentOverlayDemo.war/WEB-INF/lib/Hello.jar""
	at org.jboss.vfs.VFS.mount(VFS.java:127) [jboss-vfs-3.2.2.Final.jar:3.2.2.Final]
	at org.jboss.vfs.VFS.doMount(VFS.java:336) [jboss-vfs-3.2.2.Final.jar:3.2.2.Final]
	at org.jboss.vfs.VFS.mountReal(VFS.java:423) [jboss-vfs-3.2.2.Final.jar:3.2.2.Final]
	at org.jboss.as.server.deployment.ContentOverrideDeploymentUnitProcessor.deploy(ContentOverrideDeploymentUnitProcessor.java:67) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	... 6 more

12:09:59,805 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) JBAS014613: Operation ("redeploy") failed - address: ([("deployment" => "DeploymentOverlayDemo.war")]) - failure description: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"DeploymentOverlayDemo.war\".STRUCTURE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"DeploymentOverlayDemo.war\".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment \"DeploymentOverlayDemo.war\"
    Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018776: Failed to get content for deployment overlay myOverLay_1 at /WEB-INF/lib/Hello.jar
    Caused by: java.io.IOException: VFS000017: Filesystem already mounted at mount point \"\"/content/DeploymentOverlayDemo.war/WEB-INF/lib/Hello.jar\"\""}}
12:09:59,809 ERROR [org.jboss.as.server] (management-handler-thread - 3) JBAS015860: Redeploy of deployment "DeploymentOverlayDemo.war" was rolled back with the following failure message: 
{"JBAS014671: Failed services" => {"jboss.deployment.unit.\"DeploymentOverlayDemo.war\".STRUCTURE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"DeploymentOverlayDemo.war\".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment \"DeploymentOverlayDemo.war\"
    Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018776: Failed to get content for deployment overlay myOverLay_1 at /WEB-INF/lib/Hello.jar
    Caused by: java.io.IOException: VFS000017: Filesystem already mounted at mount point \"\"/content/DeploymentOverlayDemo.war/WEB-INF/lib/Hello.jar\"\""}}
12:09:59,814 INFO  [org.jboss.as.controller] (management-handler-thread - 3) JBAS014774: Service status report
JBAS014777:   Services which failed to start:      service jboss.deployment.unit."DeploymentOverlayDemo.war".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit."DeploymentOverlayDemo.war".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment "DeploymentOverlayDemo.war"
{quote}


    
> Deployment Overlay feature is not able to replace the application libraries.
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-2266
>                 URL: https://issues.jboss.org/browse/WFLY-2266
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 8.0.0.Beta1
>         Environment: All Operating Systems
>            Reporter: Jay Kumar SenSharma
>            Assignee: Brian Stansberry
>              Labels: deployment
>
> -----------------------
>    According to the documentation: [1] the deployment overlay feature is applicable for "swapping out deployment descriptors, modifying static web resources to change the branding of an application, or even replacing jar libraries with different versions."   
>    Here it talks about "replacing jar libraries" which is not working as expected and causes  the following error.
> [1] https://docs.jboss.org/author/display/AS72/Deployment+Overlays
> Follow the below sequence of deployment and overlay:
> Steps to Reproduce:
> ------------------
> *Step-1).* Undeploy if any existing application is deployed  and then freshly deploy the application.
> {quote}
> [standalone at localhost:9999 /] undeploy DeploymentOverlayDemo.war 
> [standalone at localhost:9999 /] deploy /home/jaysensharma/TestApp/build/DeploymentOverlayDemo.war
> {quote}
> *Step-2).* Make some changes in java code _"Hello.java"_ . Create a new JAR  Hello.jar which we want to replace at _(/WEB-INF/lib/Hello.jar)_ using deployment-overlay feature.  In the attached ant based Demo just do _"ant compile"_  to create a new Jar _"${project.dir}/tmp/Hello.jar"_
> *Step-3).* Use the following command in order to replace the "/WEB-INF/lib/Hello.jar" with the newly created Hello.jar using deployment overlay feature as following:
> {quote}
> [standalone at localhost:9999 /] deployment-overlay add --name=myOverLay_1 --content=/WEB-INF/lib/Hello.jar=/home/jaysensharma/TestApp/tmp/Hello.jar --deployments=DeploymentOverlayDemo.war --redeploy-affected
> {quote}
>   
>    Above causes the following Exception:
> {quote}
> 12:09:59,736 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS018224: Unregister web context: /DeploymentOverlayDemo
> 12:09:59,760 WARN  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017530: Could not delete servlet temp file /NotBackedUp/SVN_16_Jan/WildFly/build_Apps/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/tmp/DeploymentOverlayDemo.war/org/apache/jsp
> 12:09:59,761 WARN  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017530: Could not delete servlet temp file /NotBackedUp/SVN_16_Jan/WildFly/build_Apps/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/tmp/DeploymentOverlayDemo.war/org/apache
> 12:09:59,761 WARN  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017530: Could not delete servlet temp file /NotBackedUp/SVN_16_Jan/WildFly/build_Apps/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/tmp/DeploymentOverlayDemo.war/org
> 12:09:59,762 WARN  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017530: Could not delete servlet temp file /NotBackedUp/SVN_16_Jan/WildFly/build_Apps/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/tmp/DeploymentOverlayDemo.war
> 12:09:59,787 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015877: Stopped deployment DeploymentOverlayDemo.war (runtime-name: DeploymentOverlayDemo.war) in 56ms
> 12:09:59,789 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015876: Starting deployment of "DeploymentOverlayDemo.war" (runtime-name: "DeploymentOverlayDemo.war")
> 12:09:59,799 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."DeploymentOverlayDemo.war".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit."DeploymentOverlayDemo.war".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment "DeploymentOverlayDemo.war"
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018776: Failed to get content for deployment overlay myOverLay_1 at /WEB-INF/lib/Hello.jar
> 	at org.jboss.as.server.deployment.ContentOverrideDeploymentUnitProcessor.deploy(ContentOverrideDeploymentUnitProcessor.java:70) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	... 5 more
> Caused by: java.io.IOException: VFS000017: Filesystem already mounted at mount point ""/content/DeploymentOverlayDemo.war/WEB-INF/lib/Hello.jar""
> 	at org.jboss.vfs.VFS.mount(VFS.java:127) [jboss-vfs-3.2.2.Final.jar:3.2.2.Final]
> 	at org.jboss.vfs.VFS.doMount(VFS.java:336) [jboss-vfs-3.2.2.Final.jar:3.2.2.Final]
> 	at org.jboss.vfs.VFS.mountReal(VFS.java:423) [jboss-vfs-3.2.2.Final.jar:3.2.2.Final]
> 	at org.jboss.as.server.deployment.ContentOverrideDeploymentUnitProcessor.deploy(ContentOverrideDeploymentUnitProcessor.java:67) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	... 6 more
> 12:09:59,805 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) JBAS014613: Operation ("redeploy") failed - address: ([("deployment" => "DeploymentOverlayDemo.war")]) - failure description: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"DeploymentOverlayDemo.war\".STRUCTURE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"DeploymentOverlayDemo.war\".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment \"DeploymentOverlayDemo.war\"
>     Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018776: Failed to get content for deployment overlay myOverLay_1 at /WEB-INF/lib/Hello.jar
>     Caused by: java.io.IOException: VFS000017: Filesystem already mounted at mount point \"\"/content/DeploymentOverlayDemo.war/WEB-INF/lib/Hello.jar\"\""}}
> 12:09:59,809 ERROR [org.jboss.as.server] (management-handler-thread - 3) JBAS015860: Redeploy of deployment "DeploymentOverlayDemo.war" was rolled back with the following failure message: 
> {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"DeploymentOverlayDemo.war\".STRUCTURE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"DeploymentOverlayDemo.war\".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment \"DeploymentOverlayDemo.war\"
>     Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018776: Failed to get content for deployment overlay myOverLay_1 at /WEB-INF/lib/Hello.jar
>     Caused by: java.io.IOException: VFS000017: Filesystem already mounted at mount point \"\"/content/DeploymentOverlayDemo.war/WEB-INF/lib/Hello.jar\"\""}}
> 12:09:59,814 INFO  [org.jboss.as.controller] (management-handler-thread - 3) JBAS014774: Service status report
> JBAS014777:   Services which failed to start:      service jboss.deployment.unit."DeploymentOverlayDemo.war".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit."DeploymentOverlayDemo.war".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment "DeploymentOverlayDemo.war"
> {quote}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 04:34:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Wed, 9 Oct 2013 04:34:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2266) Deployment Overlay feature is
 not able to replace the application libraries.
In-Reply-To: <JIRA.12502513.1381301201000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502513.1381301201000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502513.1381301201000.26864.1381307642663@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFLY-2266:
------------------------------------

    Assignee: Stuart Douglas  (was: Brian Stansberry)

    
> Deployment Overlay feature is not able to replace the application libraries.
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-2266
>                 URL: https://issues.jboss.org/browse/WFLY-2266
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 8.0.0.Beta1
>         Environment: All Operating Systems
>            Reporter: Jay Kumar SenSharma
>            Assignee: Stuart Douglas
>              Labels: deployment
>
> -----------------------
>    According to the documentation: [1] the deployment overlay feature is applicable for "swapping out deployment descriptors, modifying static web resources to change the branding of an application, or even replacing jar libraries with different versions."   
>    Here it talks about "replacing jar libraries" which is not working as expected and causes  the following error.
> [1] https://docs.jboss.org/author/display/AS72/Deployment+Overlays
> Follow the below sequence of deployment and overlay:
> Steps to Reproduce:
> ------------------
> *Step-1).* Undeploy if any existing application is deployed  and then freshly deploy the application.
> {quote}
> [standalone at localhost:9999 /] undeploy DeploymentOverlayDemo.war 
> [standalone at localhost:9999 /] deploy /home/jaysensharma/TestApp/build/DeploymentOverlayDemo.war
> {quote}
> *Step-2).* Make some changes in java code _"Hello.java"_ . Create a new JAR  Hello.jar which we want to replace at _(/WEB-INF/lib/Hello.jar)_ using deployment-overlay feature.  In the attached ant based Demo just do _"ant compile"_  to create a new Jar _"${project.dir}/tmp/Hello.jar"_
> *Step-3).* Use the following command in order to replace the "/WEB-INF/lib/Hello.jar" with the newly created Hello.jar using deployment overlay feature as following:
> {quote}
> [standalone at localhost:9999 /] deployment-overlay add --name=myOverLay_1 --content=/WEB-INF/lib/Hello.jar=/home/jaysensharma/TestApp/tmp/Hello.jar --deployments=DeploymentOverlayDemo.war --redeploy-affected
> {quote}
>   
>    Above causes the following Exception:
> {quote}
> 12:09:59,736 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS018224: Unregister web context: /DeploymentOverlayDemo
> 12:09:59,760 WARN  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017530: Could not delete servlet temp file /NotBackedUp/SVN_16_Jan/WildFly/build_Apps/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/tmp/DeploymentOverlayDemo.war/org/apache/jsp
> 12:09:59,761 WARN  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017530: Could not delete servlet temp file /NotBackedUp/SVN_16_Jan/WildFly/build_Apps/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/tmp/DeploymentOverlayDemo.war/org/apache
> 12:09:59,761 WARN  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017530: Could not delete servlet temp file /NotBackedUp/SVN_16_Jan/WildFly/build_Apps/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/tmp/DeploymentOverlayDemo.war/org
> 12:09:59,762 WARN  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017530: Could not delete servlet temp file /NotBackedUp/SVN_16_Jan/WildFly/build_Apps/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/tmp/DeploymentOverlayDemo.war
> 12:09:59,787 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015877: Stopped deployment DeploymentOverlayDemo.war (runtime-name: DeploymentOverlayDemo.war) in 56ms
> 12:09:59,789 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015876: Starting deployment of "DeploymentOverlayDemo.war" (runtime-name: "DeploymentOverlayDemo.war")
> 12:09:59,799 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."DeploymentOverlayDemo.war".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit."DeploymentOverlayDemo.war".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment "DeploymentOverlayDemo.war"
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018776: Failed to get content for deployment overlay myOverLay_1 at /WEB-INF/lib/Hello.jar
> 	at org.jboss.as.server.deployment.ContentOverrideDeploymentUnitProcessor.deploy(ContentOverrideDeploymentUnitProcessor.java:70) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	... 5 more
> Caused by: java.io.IOException: VFS000017: Filesystem already mounted at mount point ""/content/DeploymentOverlayDemo.war/WEB-INF/lib/Hello.jar""
> 	at org.jboss.vfs.VFS.mount(VFS.java:127) [jboss-vfs-3.2.2.Final.jar:3.2.2.Final]
> 	at org.jboss.vfs.VFS.doMount(VFS.java:336) [jboss-vfs-3.2.2.Final.jar:3.2.2.Final]
> 	at org.jboss.vfs.VFS.mountReal(VFS.java:423) [jboss-vfs-3.2.2.Final.jar:3.2.2.Final]
> 	at org.jboss.as.server.deployment.ContentOverrideDeploymentUnitProcessor.deploy(ContentOverrideDeploymentUnitProcessor.java:67) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	... 6 more
> 12:09:59,805 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) JBAS014613: Operation ("redeploy") failed - address: ([("deployment" => "DeploymentOverlayDemo.war")]) - failure description: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"DeploymentOverlayDemo.war\".STRUCTURE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"DeploymentOverlayDemo.war\".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment \"DeploymentOverlayDemo.war\"
>     Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018776: Failed to get content for deployment overlay myOverLay_1 at /WEB-INF/lib/Hello.jar
>     Caused by: java.io.IOException: VFS000017: Filesystem already mounted at mount point \"\"/content/DeploymentOverlayDemo.war/WEB-INF/lib/Hello.jar\"\""}}
> 12:09:59,809 ERROR [org.jboss.as.server] (management-handler-thread - 3) JBAS015860: Redeploy of deployment "DeploymentOverlayDemo.war" was rolled back with the following failure message: 
> {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"DeploymentOverlayDemo.war\".STRUCTURE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"DeploymentOverlayDemo.war\".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment \"DeploymentOverlayDemo.war\"
>     Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018776: Failed to get content for deployment overlay myOverLay_1 at /WEB-INF/lib/Hello.jar
>     Caused by: java.io.IOException: VFS000017: Filesystem already mounted at mount point \"\"/content/DeploymentOverlayDemo.war/WEB-INF/lib/Hello.jar\"\""}}
> 12:09:59,814 INFO  [org.jboss.as.controller] (management-handler-thread - 3) JBAS014774: Service status report
> JBAS014777:   Services which failed to start:      service jboss.deployment.unit."DeploymentOverlayDemo.war".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit."DeploymentOverlayDemo.war".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment "DeploymentOverlayDemo.war"
> {quote}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 05:09:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 9 Oct 2013 05:09:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-101) JMSService.start is doing
	blocking I/O
In-Reply-To: <JIRA.12489128.1365693199000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489128.1365693199000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489128.1365693199000.27067.1381309743050@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812573#comment-12812573 ] 

RH Bugzilla Integration commented on WFLY-101:
----------------------------------------------

Miroslav Novak <mnovak at redhat.com> made a comment on [bug 1003913|https://bugzilla.redhat.com/show_bug.cgi?id=1003913]

Hi Jeff,

I tried to use debugger to hold start of HornetQ - line break point was HornetQServerImpl.start line 404. But I didn't see other services to start when debugger stopped initialization of HornetQ. My understanding is that those services should start when they do not have dependency on messaging. Is it right?

Thanks,

Mirek
                
> JMSService.start is doing blocking I/O
> --------------------------------------
>
>                 Key: WFLY-101
>                 URL: https://issues.jboss.org/browse/WFLY-101
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.Alpha1
>
>
> flag the start context as asynchronous

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 05:17:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 9 Oct 2013 05:17:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-101) JMSService.start is doing
	blocking I/O
In-Reply-To: <JIRA.12489128.1365693199000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489128.1365693199000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489128.1365693199000.27071.1381310222582@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812574#comment-12812574 ] 

RH Bugzilla Integration commented on WFLY-101:
----------------------------------------------

Jeff Mesnil <jmesnil at redhat.com> made a comment on [bug 1003913|https://bugzilla.redhat.com/show_bug.cgi?id=1003913]

Breakpoint should be on org.hornetq.jms.server.impl.JMSServerManagerImpl#start

That the HornetQ class that is called by WildFly JMSService.

I'm nto sure what should happen exactly but since the JMS server start is asynchrounous now, other WildFly services will be able to start without being blocked.
This changes nothing for services *depending* on JMSService. They will not be started until the JMSService is started (asynchronously or not).
                
> JMSService.start is doing blocking I/O
> --------------------------------------
>
>                 Key: WFLY-101
>                 URL: https://issues.jboss.org/browse/WFLY-101
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.Alpha1
>
>
> flag the start context as asynchronous

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 05:49:02 2013
From: jira-events at lists.jboss.org (Jari Juslin (JIRA))
Date: Wed, 9 Oct 2013 05:49:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2267) Persisting a new entity bean
 with certain patterns fails to ARJUNA016082 on flush stage.
In-Reply-To: <JIRA.12502535.1381312028357@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502535.1381312028357@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502535.1381312028357.27146.1381312142674@jira02.app.mwc.hst.phx2.redhat.com>

Jari Juslin created WFLY-2267:
---------------------------------

             Summary: Persisting a new entity bean with certain patterns fails to ARJUNA016082 on flush stage.
                 Key: WFLY-2267
                 URL: https://issues.jboss.org/browse/WFLY-2267
             Project: WildFly
          Issue Type: Bug
          Components: Transactions
    Affects Versions: 8.0.0.Beta1, 8.0.0.Alpha4
         Environment: Ubuntu Linux 13.04, JDK 1.7.0u40 64-bit.
            Reporter: Jari Juslin
            Assignee: jaikiran pai
         Attachments: infinispan_bug_repro2.zip

Persisting a new entity inside a CMT and then exiting the transactional method throws ARJUNA016082 in certain cases.

I have extracted two cases where the bug manifests.
1) Creating a new entity bean and then changing one field after the persist call.
2) Creating a new entity bean that has another entity linked to it, and the newly created entity is on the blind side of the relationship.

Here is the RESTeasy service and the entity bean needed to replicate this (also packaged to the attached test case):

package bugrepro2;

import javax.ejb.LocalBean;
import javax.ejb.Stateless;
import javax.persistence.EntityManager;
import javax.persistence.PersistenceContext;
import javax.ws.rs.POST;
import javax.ws.rs.Path;

/**
 * @author Jari Juslin, zds at ecolane.com
 */
@Stateless
@LocalBean
@Path("/bug_repro2")
public class BugRepro2Rest {
    @PersistenceContext(unitName = "persistence_context2")
    protected EntityManager entityManager;
    
    @POST
    public String manifestArjunaBug() {
        BugReproEntity entry = new BugReproEntity();

        entityManager.persist(entry);
        
        entry.setHasChanges(true);
        
        return "Success\n";
    }
}

package bugrepro2;

import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.Table;

import org.hibernate.annotations.Cache;
import org.hibernate.annotations.CacheConcurrencyStrategy;

@Entity()
@Table(name = "bugrepro_entity")
@Cache(usage=CacheConcurrencyStrategy.TRANSACTIONAL)
public class BugReproEntity {
    private Integer id;

    private boolean hasChanges;

    public BugReproEntity() {
    }

    @Id
    @GeneratedValue(strategy=GenerationType.IDENTITY)
    @Column(name="id")
    public Integer getId() {
        return id;
    }

    public void setId(Integer id) {
        this.id = id;
    }

    @Column(name="has_changes")
    public boolean getHasChanges() {
        return hasChanges;
    }

    public void setHasChanges(boolean hasChanges) {
        this.hasChanges = hasChanges;
    }
}

The resulting exception:
2013-10-09 12:44:07,362 WARN  [org.infinispan.transaction.TransactionTable] (default task-31:) ISPN000101: Failed synchronization registration: java.lang.IllegalStateException: ARJUNA016082: Synchronizations are not allowed! Transaction status isActionStatus.RUNNING
	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronizationImple(TransactionImple.java:379)
	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronization(TransactionImple.java:356)
	at org.infinispan.transaction.TransactionTable.enlist(TransactionTable.java:196)
	at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:269)
	at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:231)
	at org.infinispan.interceptors.TxInterceptor.visitPutKeyValueCommand(TxInterceptor.java:177)
	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
	at org.infinispan.interceptors.CacheMgmtInterceptor.updateStoreStatistics(CacheMgmtInterceptor.java:148)
	at org.infinispan.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:134)
	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:106)
	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:70)
	at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32)
	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:321)
	at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1298)
	at org.infinispan.CacheImpl.putInternal(CacheImpl.java:871)
	at org.infinispan.CacheImpl.put(CacheImpl.java:863)
	at org.infinispan.DecoratedCache.put(DecoratedCache.java:401)
	at org.infinispan.AbstractDelegatingCache.put(AbstractDelegatingCache.java:276)
	at org.hibernate.cache.infinispan.access.TransactionalAccessDelegate.update(TransactionalAccessDelegate.java:187) [hibernate-infinispan-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.cache.infinispan.entity.TransactionalAccess.update(TransactionalAccess.java:89) [hibernate-infinispan-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.action.internal.EntityUpdateAction.execute(EntityUpdateAction.java:208) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:377) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:369) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:287) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:340) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:52) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1235) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:405) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:113) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:53) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76)
	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:273)
	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:93)
	at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1170)
	at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
	at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:93) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:437)
	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72)
	at bugrepro2.BugRepro2Rest$$$view31.manifestArjunaBug(Unknown Source) [classes:]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_40]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_40]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_40]
	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_40]
	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137) [resteasy-jaxrs-3.0.4.Final.jar:]
	at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:280) [resteasy-jaxrs-3.0.4.Final.jar:]
	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:234) [resteasy-jaxrs-3.0.4.Final.jar:]
	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:221) [resteasy-jaxrs-3.0.4.Final.jar:]
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356) [resteasy-jaxrs-3.0.4.Final.jar:]
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179) [resteasy-jaxrs-3.0.4.Final.jar:]
	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) [resteasy-jaxrs-3.0.4.Final.jar:]
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.4.Final.jar:]
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.4.Final.jar:]
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:59) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:218) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:619) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]

I have reported this also to Infinispan, because I am not sure which party is to blame.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 05:49:02 2013
From: jira-events at lists.jboss.org (Jari Juslin (JIRA))
Date: Wed, 9 Oct 2013 05:49:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2267) Persisting a new entity bean
 with certain patterns fails to ARJUNA016082 on flush stage.
In-Reply-To: <JIRA.12502535.1381312028000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502535.1381312028000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502535.1381312028000.27149.1381312142860@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jari Juslin updated WFLY-2267:
------------------------------

    Attachment: infinispan_bug_repro2.zip


The test case to reproduce the bug.
                
> Persisting a new entity bean with certain patterns fails to ARJUNA016082 on flush stage.
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-2267
>                 URL: https://issues.jboss.org/browse/WFLY-2267
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>    Affects Versions: 8.0.0.Alpha4, 8.0.0.Beta1
>         Environment: Ubuntu Linux 13.04, JDK 1.7.0u40 64-bit.
>            Reporter: Jari Juslin
>            Assignee: jaikiran pai
>         Attachments: infinispan_bug_repro2.zip
>
>
> Persisting a new entity inside a CMT and then exiting the transactional method throws ARJUNA016082 in certain cases.
> I have extracted two cases where the bug manifests.
> 1) Creating a new entity bean and then changing one field after the persist call.
> 2) Creating a new entity bean that has another entity linked to it, and the newly created entity is on the blind side of the relationship.
> Here is the RESTeasy service and the entity bean needed to replicate this (also packaged to the attached test case):
> package bugrepro2;
> import javax.ejb.LocalBean;
> import javax.ejb.Stateless;
> import javax.persistence.EntityManager;
> import javax.persistence.PersistenceContext;
> import javax.ws.rs.POST;
> import javax.ws.rs.Path;
> /**
>  * @author Jari Juslin, zds at ecolane.com
>  */
> @Stateless
> @LocalBean
> @Path("/bug_repro2")
> public class BugRepro2Rest {
>     @PersistenceContext(unitName = "persistence_context2")
>     protected EntityManager entityManager;
>     
>     @POST
>     public String manifestArjunaBug() {
>         BugReproEntity entry = new BugReproEntity();
>         entityManager.persist(entry);
>         
>         entry.setHasChanges(true);
>         
>         return "Success\n";
>     }
> }
> package bugrepro2;
> import javax.persistence.Column;
> import javax.persistence.Entity;
> import javax.persistence.GeneratedValue;
> import javax.persistence.GenerationType;
> import javax.persistence.Id;
> import javax.persistence.Table;
> import org.hibernate.annotations.Cache;
> import org.hibernate.annotations.CacheConcurrencyStrategy;
> @Entity()
> @Table(name = "bugrepro_entity")
> @Cache(usage=CacheConcurrencyStrategy.TRANSACTIONAL)
> public class BugReproEntity {
>     private Integer id;
>     private boolean hasChanges;
>     public BugReproEntity() {
>     }
>     @Id
>     @GeneratedValue(strategy=GenerationType.IDENTITY)
>     @Column(name="id")
>     public Integer getId() {
>         return id;
>     }
>     public void setId(Integer id) {
>         this.id = id;
>     }
>     @Column(name="has_changes")
>     public boolean getHasChanges() {
>         return hasChanges;
>     }
>     public void setHasChanges(boolean hasChanges) {
>         this.hasChanges = hasChanges;
>     }
> }
> The resulting exception:
> 2013-10-09 12:44:07,362 WARN  [org.infinispan.transaction.TransactionTable] (default task-31:) ISPN000101: Failed synchronization registration: java.lang.IllegalStateException: ARJUNA016082: Synchronizations are not allowed! Transaction status isActionStatus.RUNNING
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronizationImple(TransactionImple.java:379)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronization(TransactionImple.java:356)
> 	at org.infinispan.transaction.TransactionTable.enlist(TransactionTable.java:196)
> 	at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:269)
> 	at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:231)
> 	at org.infinispan.interceptors.TxInterceptor.visitPutKeyValueCommand(TxInterceptor.java:177)
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.updateStoreStatistics(CacheMgmtInterceptor.java:148)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:134)
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:106)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:70)
> 	at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32)
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:321)
> 	at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1298)
> 	at org.infinispan.CacheImpl.putInternal(CacheImpl.java:871)
> 	at org.infinispan.CacheImpl.put(CacheImpl.java:863)
> 	at org.infinispan.DecoratedCache.put(DecoratedCache.java:401)
> 	at org.infinispan.AbstractDelegatingCache.put(AbstractDelegatingCache.java:276)
> 	at org.hibernate.cache.infinispan.access.TransactionalAccessDelegate.update(TransactionalAccessDelegate.java:187) [hibernate-infinispan-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.cache.infinispan.entity.TransactionalAccess.update(TransactionalAccess.java:89) [hibernate-infinispan-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.action.internal.EntityUpdateAction.execute(EntityUpdateAction.java:208) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:377) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:369) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:287) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:340) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:52) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1235) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:405) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:113) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:53) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76)
> 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:273)
> 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:93)
> 	at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1170)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
> 	at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:93) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:437)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72)
> 	at bugrepro2.BugRepro2Rest$$$view31.manifestArjunaBug(Unknown Source) [classes:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_40]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_40]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_40]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_40]
> 	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:280) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:234) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:221) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:59) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:218) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:619) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> I have reported this also to Infinispan, because I am not sure which party is to blame.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 05:51:02 2013
From: jira-events at lists.jboss.org (Jari Juslin (JIRA))
Date: Wed, 9 Oct 2013 05:51:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2267) Persisting a new entity bean
 with certain patterns fails to ARJUNA016082 on flush stage.
In-Reply-To: <JIRA.12502535.1381312028000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502535.1381312028000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502535.1381312028000.27155.1381312262681@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jari Juslin updated WFLY-2267:
------------------------------

    Description: 
Persisting a new entity inside a CMT and then exiting the transactional method throws ARJUNA016082 in certain cases.

I have extracted two cases where the bug manifests.
1) Creating a new entity bean and then changing one field after the persist call.
2) Creating a new entity bean that has another entity linked to it, and the newly created entity is on the blind side of the relationship.

Here is the RESTeasy service and the entity bean needed to replicate this (also packaged to the attached test case):

package bugrepro2;

import javax.ejb.LocalBean;
import javax.ejb.Stateless;
import javax.persistence.EntityManager;
import javax.persistence.PersistenceContext;
import javax.ws.rs.POST;
import javax.ws.rs.Path;

/**
 * @author Jari Juslin, zds at ecolane.com
 */
@Stateless
@LocalBean
@Path("/bug_repro2")
public class BugRepro2Rest {
    @PersistenceContext(unitName = "persistence_context2")
    protected EntityManager entityManager;
    
    @POST
    public String manifestArjunaBug() {
        BugReproEntity entry = new BugReproEntity();

        entityManager.persist(entry);
        
        entry.setHasChanges(true);
        
        return "Success\n";
    }
}

package bugrepro2;

import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.Table;

import org.hibernate.annotations.Cache;
import org.hibernate.annotations.CacheConcurrencyStrategy;

@Entity()
@Table(name = "bugrepro_entity")
@Cache(usage=CacheConcurrencyStrategy.TRANSACTIONAL)
public class BugReproEntity {
    private Integer id;

    private boolean hasChanges;

    public BugReproEntity() {
    }

    @Id
    @GeneratedValue(strategy=GenerationType.IDENTITY)
    @Column(name="id")
    public Integer getId() {
        return id;
    }

    public void setId(Integer id) {
        this.id = id;
    }

    @Column(name="has_changes")
    public boolean getHasChanges() {
        return hasChanges;
    }

    public void setHasChanges(boolean hasChanges) {
        this.hasChanges = hasChanges;
    }
}

The resulting exception:
2013-10-09 12:44:07,362 WARN  [org.infinispan.transaction.TransactionTable] (default task-31:) ISPN000101: Failed synchronization registration: java.lang.IllegalStateException: ARJUNA016082: Synchronizations are not allowed! Transaction status isActionStatus.RUNNING
	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronizationImple(TransactionImple.java:379)
	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronization(TransactionImple.java:356)
	at org.infinispan.transaction.TransactionTable.enlist(TransactionTable.java:196)
	at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:269)
	at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:231)
	at org.infinispan.interceptors.TxInterceptor.visitPutKeyValueCommand(TxInterceptor.java:177)
	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
	at org.infinispan.interceptors.CacheMgmtInterceptor.updateStoreStatistics(CacheMgmtInterceptor.java:148)
	at org.infinispan.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:134)
	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:106)
	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:70)
	at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32)
	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:321)
	at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1298)
	at org.infinispan.CacheImpl.putInternal(CacheImpl.java:871)
	at org.infinispan.CacheImpl.put(CacheImpl.java:863)
	at org.infinispan.DecoratedCache.put(DecoratedCache.java:401)
	at org.infinispan.AbstractDelegatingCache.put(AbstractDelegatingCache.java:276)
	at org.hibernate.cache.infinispan.access.TransactionalAccessDelegate.update(TransactionalAccessDelegate.java:187) [hibernate-infinispan-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.cache.infinispan.entity.TransactionalAccess.update(TransactionalAccess.java:89) [hibernate-infinispan-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.action.internal.EntityUpdateAction.execute(EntityUpdateAction.java:208) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:377) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:369) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:287) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:340) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:52) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1235) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:405) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:113) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:53) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76)
	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:273)
	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:93)
	at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1170)
	at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
	at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:93) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:437)
	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72)
	at bugrepro2.BugRepro2Rest$$$view31.manifestArjunaBug(Unknown Source) [classes:]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_40]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_40]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_40]
	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_40]
	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137) [resteasy-jaxrs-3.0.4.Final.jar:]
	at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:280) [resteasy-jaxrs-3.0.4.Final.jar:]
	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:234) [resteasy-jaxrs-3.0.4.Final.jar:]
	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:221) [resteasy-jaxrs-3.0.4.Final.jar:]
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356) [resteasy-jaxrs-3.0.4.Final.jar:]
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179) [resteasy-jaxrs-3.0.4.Final.jar:]
	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) [resteasy-jaxrs-3.0.4.Final.jar:]
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.4.Final.jar:]
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.4.Final.jar:]
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:59) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:218) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:619) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]

The datasource definition from standalone.xml:
                <datasource jndi-name="java:/BugRepro2DS" pool-name="BugRepro2DS" enabled="true">
                    <connection-url>jdbc:mysql://localhost:3306/bugrepro2</connection-url>
                    <driver>mysql</driver>
                    <security>
                        <user-name>*******</user-name>
                        <password>*******</password>
                    </security>
                </datasource>

                <drivers>
                    <driver name="mysql" module="com.mysql">
                        <xa-datasource-class>com.mysql.jdbc.jdbc2.optional.MysqlXADataSource</xa-datasource-class>
                    </driver>
                </drivers>

I have reported this also to Infinispan, because I am not sure which party is to blame.

  was:
Persisting a new entity inside a CMT and then exiting the transactional method throws ARJUNA016082 in certain cases.

I have extracted two cases where the bug manifests.
1) Creating a new entity bean and then changing one field after the persist call.
2) Creating a new entity bean that has another entity linked to it, and the newly created entity is on the blind side of the relationship.

Here is the RESTeasy service and the entity bean needed to replicate this (also packaged to the attached test case):

package bugrepro2;

import javax.ejb.LocalBean;
import javax.ejb.Stateless;
import javax.persistence.EntityManager;
import javax.persistence.PersistenceContext;
import javax.ws.rs.POST;
import javax.ws.rs.Path;

/**
 * @author Jari Juslin, zds at ecolane.com
 */
@Stateless
@LocalBean
@Path("/bug_repro2")
public class BugRepro2Rest {
    @PersistenceContext(unitName = "persistence_context2")
    protected EntityManager entityManager;
    
    @POST
    public String manifestArjunaBug() {
        BugReproEntity entry = new BugReproEntity();

        entityManager.persist(entry);
        
        entry.setHasChanges(true);
        
        return "Success\n";
    }
}

package bugrepro2;

import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.Table;

import org.hibernate.annotations.Cache;
import org.hibernate.annotations.CacheConcurrencyStrategy;

@Entity()
@Table(name = "bugrepro_entity")
@Cache(usage=CacheConcurrencyStrategy.TRANSACTIONAL)
public class BugReproEntity {
    private Integer id;

    private boolean hasChanges;

    public BugReproEntity() {
    }

    @Id
    @GeneratedValue(strategy=GenerationType.IDENTITY)
    @Column(name="id")
    public Integer getId() {
        return id;
    }

    public void setId(Integer id) {
        this.id = id;
    }

    @Column(name="has_changes")
    public boolean getHasChanges() {
        return hasChanges;
    }

    public void setHasChanges(boolean hasChanges) {
        this.hasChanges = hasChanges;
    }
}

The resulting exception:
2013-10-09 12:44:07,362 WARN  [org.infinispan.transaction.TransactionTable] (default task-31:) ISPN000101: Failed synchronization registration: java.lang.IllegalStateException: ARJUNA016082: Synchronizations are not allowed! Transaction status isActionStatus.RUNNING
	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronizationImple(TransactionImple.java:379)
	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronization(TransactionImple.java:356)
	at org.infinispan.transaction.TransactionTable.enlist(TransactionTable.java:196)
	at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:269)
	at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:231)
	at org.infinispan.interceptors.TxInterceptor.visitPutKeyValueCommand(TxInterceptor.java:177)
	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
	at org.infinispan.interceptors.CacheMgmtInterceptor.updateStoreStatistics(CacheMgmtInterceptor.java:148)
	at org.infinispan.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:134)
	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:106)
	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:70)
	at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32)
	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:321)
	at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1298)
	at org.infinispan.CacheImpl.putInternal(CacheImpl.java:871)
	at org.infinispan.CacheImpl.put(CacheImpl.java:863)
	at org.infinispan.DecoratedCache.put(DecoratedCache.java:401)
	at org.infinispan.AbstractDelegatingCache.put(AbstractDelegatingCache.java:276)
	at org.hibernate.cache.infinispan.access.TransactionalAccessDelegate.update(TransactionalAccessDelegate.java:187) [hibernate-infinispan-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.cache.infinispan.entity.TransactionalAccess.update(TransactionalAccess.java:89) [hibernate-infinispan-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.action.internal.EntityUpdateAction.execute(EntityUpdateAction.java:208) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:377) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:369) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:287) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:340) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:52) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1235) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:405) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:113) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:53) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76)
	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:273)
	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:93)
	at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1170)
	at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
	at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:93) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:437)
	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72)
	at bugrepro2.BugRepro2Rest$$$view31.manifestArjunaBug(Unknown Source) [classes:]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_40]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_40]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_40]
	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_40]
	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137) [resteasy-jaxrs-3.0.4.Final.jar:]
	at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:280) [resteasy-jaxrs-3.0.4.Final.jar:]
	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:234) [resteasy-jaxrs-3.0.4.Final.jar:]
	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:221) [resteasy-jaxrs-3.0.4.Final.jar:]
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356) [resteasy-jaxrs-3.0.4.Final.jar:]
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179) [resteasy-jaxrs-3.0.4.Final.jar:]
	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) [resteasy-jaxrs-3.0.4.Final.jar:]
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.4.Final.jar:]
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.4.Final.jar:]
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:59) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:218) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:619) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]

I have reported this also to Infinispan, because I am not sure which party is to blame.


    
> Persisting a new entity bean with certain patterns fails to ARJUNA016082 on flush stage.
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-2267
>                 URL: https://issues.jboss.org/browse/WFLY-2267
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>    Affects Versions: 8.0.0.Alpha4, 8.0.0.Beta1
>         Environment: Ubuntu Linux 13.04, JDK 1.7.0u40 64-bit.
>            Reporter: Jari Juslin
>            Assignee: jaikiran pai
>         Attachments: infinispan_bug_repro2.zip
>
>
> Persisting a new entity inside a CMT and then exiting the transactional method throws ARJUNA016082 in certain cases.
> I have extracted two cases where the bug manifests.
> 1) Creating a new entity bean and then changing one field after the persist call.
> 2) Creating a new entity bean that has another entity linked to it, and the newly created entity is on the blind side of the relationship.
> Here is the RESTeasy service and the entity bean needed to replicate this (also packaged to the attached test case):
> package bugrepro2;
> import javax.ejb.LocalBean;
> import javax.ejb.Stateless;
> import javax.persistence.EntityManager;
> import javax.persistence.PersistenceContext;
> import javax.ws.rs.POST;
> import javax.ws.rs.Path;
> /**
>  * @author Jari Juslin, zds at ecolane.com
>  */
> @Stateless
> @LocalBean
> @Path("/bug_repro2")
> public class BugRepro2Rest {
>     @PersistenceContext(unitName = "persistence_context2")
>     protected EntityManager entityManager;
>     
>     @POST
>     public String manifestArjunaBug() {
>         BugReproEntity entry = new BugReproEntity();
>         entityManager.persist(entry);
>         
>         entry.setHasChanges(true);
>         
>         return "Success\n";
>     }
> }
> package bugrepro2;
> import javax.persistence.Column;
> import javax.persistence.Entity;
> import javax.persistence.GeneratedValue;
> import javax.persistence.GenerationType;
> import javax.persistence.Id;
> import javax.persistence.Table;
> import org.hibernate.annotations.Cache;
> import org.hibernate.annotations.CacheConcurrencyStrategy;
> @Entity()
> @Table(name = "bugrepro_entity")
> @Cache(usage=CacheConcurrencyStrategy.TRANSACTIONAL)
> public class BugReproEntity {
>     private Integer id;
>     private boolean hasChanges;
>     public BugReproEntity() {
>     }
>     @Id
>     @GeneratedValue(strategy=GenerationType.IDENTITY)
>     @Column(name="id")
>     public Integer getId() {
>         return id;
>     }
>     public void setId(Integer id) {
>         this.id = id;
>     }
>     @Column(name="has_changes")
>     public boolean getHasChanges() {
>         return hasChanges;
>     }
>     public void setHasChanges(boolean hasChanges) {
>         this.hasChanges = hasChanges;
>     }
> }
> The resulting exception:
> 2013-10-09 12:44:07,362 WARN  [org.infinispan.transaction.TransactionTable] (default task-31:) ISPN000101: Failed synchronization registration: java.lang.IllegalStateException: ARJUNA016082: Synchronizations are not allowed! Transaction status isActionStatus.RUNNING
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronizationImple(TransactionImple.java:379)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronization(TransactionImple.java:356)
> 	at org.infinispan.transaction.TransactionTable.enlist(TransactionTable.java:196)
> 	at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:269)
> 	at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:231)
> 	at org.infinispan.interceptors.TxInterceptor.visitPutKeyValueCommand(TxInterceptor.java:177)
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.updateStoreStatistics(CacheMgmtInterceptor.java:148)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:134)
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:106)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:70)
> 	at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32)
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:321)
> 	at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1298)
> 	at org.infinispan.CacheImpl.putInternal(CacheImpl.java:871)
> 	at org.infinispan.CacheImpl.put(CacheImpl.java:863)
> 	at org.infinispan.DecoratedCache.put(DecoratedCache.java:401)
> 	at org.infinispan.AbstractDelegatingCache.put(AbstractDelegatingCache.java:276)
> 	at org.hibernate.cache.infinispan.access.TransactionalAccessDelegate.update(TransactionalAccessDelegate.java:187) [hibernate-infinispan-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.cache.infinispan.entity.TransactionalAccess.update(TransactionalAccess.java:89) [hibernate-infinispan-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.action.internal.EntityUpdateAction.execute(EntityUpdateAction.java:208) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:377) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:369) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:287) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:340) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:52) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1235) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:405) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:113) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:53) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76)
> 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:273)
> 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:93)
> 	at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1170)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
> 	at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:93) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:437)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72)
> 	at bugrepro2.BugRepro2Rest$$$view31.manifestArjunaBug(Unknown Source) [classes:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_40]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_40]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_40]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_40]
> 	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:280) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:234) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:221) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:59) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:218) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:619) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> The datasource definition from standalone.xml:
>                 <datasource jndi-name="java:/BugRepro2DS" pool-name="BugRepro2DS" enabled="true">
>                     <connection-url>jdbc:mysql://localhost:3306/bugrepro2</connection-url>
>                     <driver>mysql</driver>
>                     <security>
>                         <user-name>*******</user-name>
>                         <password>*******</password>
>                     </security>
>                 </datasource>
>                 <drivers>
>                     <driver name="mysql" module="com.mysql">
>                         <xa-datasource-class>com.mysql.jdbc.jdbc2.optional.MysqlXADataSource</xa-datasource-class>
>                     </driver>
>                 </drivers>
> I have reported this also to Infinispan, because I am not sure which party is to blame.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 05:59:03 2013
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 9 Oct 2013 05:59:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2268) Add Generic JMS RA
In-Reply-To: <JIRA.12502537.1381312737880@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502537.1381312737880@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502537.1381312737880.27199.1381312743306@jira02.app.mwc.hst.phx2.redhat.com>

Jeff Mesnil created WFLY-2268:
---------------------------------

             Summary: Add Generic JMS RA
                 Key: WFLY-2268
                 URL: https://issues.jboss.org/browse/WFLY-2268
             Project: WildFly
          Issue Type: Feature Request
          Components: JCA, JMS
            Reporter: Jeff Mesnil
            Assignee: Jeff Mesnil
             Fix For: 8.0.0.CR1


WildFly could integrate the Generic JMS RA[1] to be able to use JMS brokers that does not provide a resource adapter.

[1] https://github.com/jms-ra/generic-jms-ra

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 06:01:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 9 Oct 2013 06:01:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2268) Add Generic JMS RA
In-Reply-To: <JIRA.12502537.1381312737000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502537.1381312737000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502537.1381312737000.27202.1381312864029@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2268:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1016762

    
> Add Generic JMS RA
> ------------------
>
>                 Key: WFLY-2268
>                 URL: https://issues.jboss.org/browse/WFLY-2268
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JCA, JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.CR1
>
>
> WildFly could integrate the Generic JMS RA[1] to be able to use JMS brokers that does not provide a resource adapter.
> [1] https://github.com/jms-ra/generic-jms-ra

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 06:01:04 2013
From: jira-events at lists.jboss.org (prasad Kasthuri (JIRA))
Date: Wed, 9 Oct 2013 06:01:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2269) Integration tests in Wildfly
 are running into errors
In-Reply-To: <JIRA.12502538.1381312812004@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502538.1381312812004@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502538.1381312812004.27204.1381312864365@jira02.app.mwc.hst.phx2.redhat.com>

prasad Kasthuri created WFLY-2269:
-------------------------------------

             Summary: Integration tests in Wildfly are running into errors
                 Key: WFLY-2269
                 URL: https://issues.jboss.org/browse/WFLY-2269
             Project: WildFly
          Issue Type: Feature Request
            Reporter: prasad Kasthuri


I am trying to run integration tests from wildfly Sources which is running into some issues. Running the test individually also causing the same issue. 

./integration-tests.sh  -Dts.clust -Dtest=org.jboss.as.test.clustering.cluster.dispatcher.CommandDispatcherTestCase
-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Running org.jboss.as.test.clustering.cluster.dispatcher.CommandDispatcherTestCase
Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 7.72 sec <<< FAILURE!

Results :

Tests in error:
  org.jboss.as.test.clustering.cluster.dispatcher.CommandDispatcherTestCase: DeploymentScenario contains a target (container-0) not matching any defined Container in th
e registry.(..)
  org.jboss.as.test.clustering.cluster.dispatcher.CommandDispatcherTestCase

Tests run: 2, Failures: 0, Errors: 2, Skipped: 0


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 06:03:02 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 9 Oct 2013 06:03:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2269) Integration tests in Wildfly
 are running into errors
In-Reply-To: <JIRA.12502538.1381312812000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502538.1381312812000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502538.1381312812000.27206.1381312982503@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812598#comment-12812598 ] 

Tomaz Cerar commented on WFLY-2269:
-----------------------------------

This disscussion belongs into forums first. also you are missing most of important information we would need to be able to help you
at minimum information about JDK & OS
                
> Integration tests in Wildfly are running into errors
> ----------------------------------------------------
>
>                 Key: WFLY-2269
>                 URL: https://issues.jboss.org/browse/WFLY-2269
>             Project: WildFly
>          Issue Type: Feature Request
>            Reporter: prasad Kasthuri
>
> I am trying to run integration tests from wildfly Sources which is running into some issues. Running the test individually also causing the same issue. 
> ./integration-tests.sh  -Dts.clust -Dtest=org.jboss.as.test.clustering.cluster.dispatcher.CommandDispatcherTestCase
> -------------------------------------------------------
>  T E S T S
> -------------------------------------------------------
> Running org.jboss.as.test.clustering.cluster.dispatcher.CommandDispatcherTestCase
> Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 7.72 sec <<< FAILURE!
> Results :
> Tests in error:
>   org.jboss.as.test.clustering.cluster.dispatcher.CommandDispatcherTestCase: DeploymentScenario contains a target (container-0) not matching any defined Container in th
> e registry.(..)
>   org.jboss.as.test.clustering.cluster.dispatcher.CommandDispatcherTestCase
> Tests run: 2, Failures: 0, Errors: 2, Skipped: 0

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 06:05:03 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 9 Oct 2013 06:05:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2257) Building WildFly from sources
 causing hang and errors, no progress.
In-Reply-To: <JIRA.12502449.1381237429000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502449.1381237429000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502449.1381237429000.27214.1381313103431@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar closed WFLY-2257.
-----------------------------

      Assignee: Tomaz Cerar  (was: Paul Gier)
    Resolution: Rejected


This discussion belongs to forums.
                
> Building WildFly from sources causing hang and errors, no progress.
> -------------------------------------------------------------------
>
>                 Key: WFLY-2257
>                 URL: https://issues.jboss.org/browse/WFLY-2257
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Build System
>    Affects Versions: 8.0.0.Beta1
>            Reporter: prasad Kasthuri
>            Assignee: Tomaz Cerar
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 06:09:02 2013
From: jira-events at lists.jboss.org (Jari Juslin (JIRA))
Date: Wed, 9 Oct 2013 06:09:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2267) Persisting a new entity bean
 with certain patterns fails to ARJUNA016082 on flush stage.
In-Reply-To: <JIRA.12502535.1381312028000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502535.1381312028000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502535.1381312028000.27244.1381313342572@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jari Juslin updated WFLY-2267:
------------------------------

    Attachment: infinispan_bug_repro.zip


The second test case; now there are now changes made after persist, but two beans alone is enough to reproduce the bug.
                
> Persisting a new entity bean with certain patterns fails to ARJUNA016082 on flush stage.
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-2267
>                 URL: https://issues.jboss.org/browse/WFLY-2267
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>    Affects Versions: 8.0.0.Alpha4, 8.0.0.Beta1
>         Environment: Ubuntu Linux 13.04, JDK 1.7.0u40 64-bit.
>            Reporter: Jari Juslin
>            Assignee: jaikiran pai
>         Attachments: infinispan_bug_repro.zip, infinispan_bug_repro2.zip
>
>
> Persisting a new entity inside a CMT and then exiting the transactional method throws ARJUNA016082 in certain cases.
> I have extracted two cases where the bug manifests.
> 1) Creating a new entity bean and then changing one field after the persist call.
> 2) Creating a new entity bean that has another entity linked to it, and the newly created entity is on the blind side of the relationship.
> Here is the RESTeasy service and the entity bean needed to replicate this (also packaged to the attached test case):
> package bugrepro2;
> import javax.ejb.LocalBean;
> import javax.ejb.Stateless;
> import javax.persistence.EntityManager;
> import javax.persistence.PersistenceContext;
> import javax.ws.rs.POST;
> import javax.ws.rs.Path;
> /**
>  * @author Jari Juslin, zds at ecolane.com
>  */
> @Stateless
> @LocalBean
> @Path("/bug_repro2")
> public class BugRepro2Rest {
>     @PersistenceContext(unitName = "persistence_context2")
>     protected EntityManager entityManager;
>     
>     @POST
>     public String manifestArjunaBug() {
>         BugReproEntity entry = new BugReproEntity();
>         entityManager.persist(entry);
>         
>         entry.setHasChanges(true);
>         
>         return "Success\n";
>     }
> }
> package bugrepro2;
> import javax.persistence.Column;
> import javax.persistence.Entity;
> import javax.persistence.GeneratedValue;
> import javax.persistence.GenerationType;
> import javax.persistence.Id;
> import javax.persistence.Table;
> import org.hibernate.annotations.Cache;
> import org.hibernate.annotations.CacheConcurrencyStrategy;
> @Entity()
> @Table(name = "bugrepro_entity")
> @Cache(usage=CacheConcurrencyStrategy.TRANSACTIONAL)
> public class BugReproEntity {
>     private Integer id;
>     private boolean hasChanges;
>     public BugReproEntity() {
>     }
>     @Id
>     @GeneratedValue(strategy=GenerationType.IDENTITY)
>     @Column(name="id")
>     public Integer getId() {
>         return id;
>     }
>     public void setId(Integer id) {
>         this.id = id;
>     }
>     @Column(name="has_changes")
>     public boolean getHasChanges() {
>         return hasChanges;
>     }
>     public void setHasChanges(boolean hasChanges) {
>         this.hasChanges = hasChanges;
>     }
> }
> The resulting exception:
> 2013-10-09 12:44:07,362 WARN  [org.infinispan.transaction.TransactionTable] (default task-31:) ISPN000101: Failed synchronization registration: java.lang.IllegalStateException: ARJUNA016082: Synchronizations are not allowed! Transaction status isActionStatus.RUNNING
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronizationImple(TransactionImple.java:379)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronization(TransactionImple.java:356)
> 	at org.infinispan.transaction.TransactionTable.enlist(TransactionTable.java:196)
> 	at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:269)
> 	at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:231)
> 	at org.infinispan.interceptors.TxInterceptor.visitPutKeyValueCommand(TxInterceptor.java:177)
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.updateStoreStatistics(CacheMgmtInterceptor.java:148)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:134)
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:106)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:70)
> 	at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32)
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:321)
> 	at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1298)
> 	at org.infinispan.CacheImpl.putInternal(CacheImpl.java:871)
> 	at org.infinispan.CacheImpl.put(CacheImpl.java:863)
> 	at org.infinispan.DecoratedCache.put(DecoratedCache.java:401)
> 	at org.infinispan.AbstractDelegatingCache.put(AbstractDelegatingCache.java:276)
> 	at org.hibernate.cache.infinispan.access.TransactionalAccessDelegate.update(TransactionalAccessDelegate.java:187) [hibernate-infinispan-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.cache.infinispan.entity.TransactionalAccess.update(TransactionalAccess.java:89) [hibernate-infinispan-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.action.internal.EntityUpdateAction.execute(EntityUpdateAction.java:208) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:377) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:369) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:287) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:340) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:52) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1235) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:405) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:113) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:53) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76)
> 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:273)
> 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:93)
> 	at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1170)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
> 	at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:93) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:437)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72)
> 	at bugrepro2.BugRepro2Rest$$$view31.manifestArjunaBug(Unknown Source) [classes:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_40]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_40]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_40]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_40]
> 	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:280) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:234) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:221) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:59) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:218) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:619) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> The datasource definition from standalone.xml:
>                 <datasource jndi-name="java:/BugRepro2DS" pool-name="BugRepro2DS" enabled="true">
>                     <connection-url>jdbc:mysql://localhost:3306/bugrepro2</connection-url>
>                     <driver>mysql</driver>
>                     <security>
>                         <user-name>*******</user-name>
>                         <password>*******</password>
>                     </security>
>                 </datasource>
>                 <drivers>
>                     <driver name="mysql" module="com.mysql">
>                         <xa-datasource-class>com.mysql.jdbc.jdbc2.optional.MysqlXADataSource</xa-datasource-class>
>                     </driver>
>                 </drivers>
> I have reported this also to Infinispan, because I am not sure which party is to blame.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 06:11:02 2013
From: jira-events at lists.jboss.org (Jari Juslin (JIRA))
Date: Wed, 9 Oct 2013 06:11:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2267) Persisting a new entity bean
 with certain patterns fails to ARJUNA016082 on flush stage.
In-Reply-To: <JIRA.12502535.1381312028000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502535.1381312028000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502535.1381312028000.27249.1381313462662@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jari Juslin updated WFLY-2267:
------------------------------

    Workaround Description: 
On the first test case you can work around the problem by making sure you do not change any values on the newly persisted bean after the persist call.

On the second test case this does not help, as the bug manifests even if all data is set before persist.

    
> Persisting a new entity bean with certain patterns fails to ARJUNA016082 on flush stage.
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-2267
>                 URL: https://issues.jboss.org/browse/WFLY-2267
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>    Affects Versions: 8.0.0.Alpha4, 8.0.0.Beta1
>         Environment: Ubuntu Linux 13.04, JDK 1.7.0u40 64-bit.
>            Reporter: Jari Juslin
>            Assignee: jaikiran pai
>         Attachments: infinispan_bug_repro.zip, infinispan_bug_repro2.zip
>
>
> Persisting a new entity inside a CMT and then exiting the transactional method throws ARJUNA016082 in certain cases.
> I have extracted two cases where the bug manifests.
> 1) Creating a new entity bean and then changing one field after the persist call.
> 2) Creating a new entity bean that has another entity linked to it, and the newly created entity is on the blind side of the relationship.
> Here is the RESTeasy service and the entity bean needed to replicate this (also packaged to the attached test case):
> package bugrepro2;
> import javax.ejb.LocalBean;
> import javax.ejb.Stateless;
> import javax.persistence.EntityManager;
> import javax.persistence.PersistenceContext;
> import javax.ws.rs.POST;
> import javax.ws.rs.Path;
> /**
>  * @author Jari Juslin, zds at ecolane.com
>  */
> @Stateless
> @LocalBean
> @Path("/bug_repro2")
> public class BugRepro2Rest {
>     @PersistenceContext(unitName = "persistence_context2")
>     protected EntityManager entityManager;
>     
>     @POST
>     public String manifestArjunaBug() {
>         BugReproEntity entry = new BugReproEntity();
>         entityManager.persist(entry);
>         
>         entry.setHasChanges(true);
>         
>         return "Success\n";
>     }
> }
> package bugrepro2;
> import javax.persistence.Column;
> import javax.persistence.Entity;
> import javax.persistence.GeneratedValue;
> import javax.persistence.GenerationType;
> import javax.persistence.Id;
> import javax.persistence.Table;
> import org.hibernate.annotations.Cache;
> import org.hibernate.annotations.CacheConcurrencyStrategy;
> @Entity()
> @Table(name = "bugrepro_entity")
> @Cache(usage=CacheConcurrencyStrategy.TRANSACTIONAL)
> public class BugReproEntity {
>     private Integer id;
>     private boolean hasChanges;
>     public BugReproEntity() {
>     }
>     @Id
>     @GeneratedValue(strategy=GenerationType.IDENTITY)
>     @Column(name="id")
>     public Integer getId() {
>         return id;
>     }
>     public void setId(Integer id) {
>         this.id = id;
>     }
>     @Column(name="has_changes")
>     public boolean getHasChanges() {
>         return hasChanges;
>     }
>     public void setHasChanges(boolean hasChanges) {
>         this.hasChanges = hasChanges;
>     }
> }
> The resulting exception:
> 2013-10-09 12:44:07,362 WARN  [org.infinispan.transaction.TransactionTable] (default task-31:) ISPN000101: Failed synchronization registration: java.lang.IllegalStateException: ARJUNA016082: Synchronizations are not allowed! Transaction status isActionStatus.RUNNING
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronizationImple(TransactionImple.java:379)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronization(TransactionImple.java:356)
> 	at org.infinispan.transaction.TransactionTable.enlist(TransactionTable.java:196)
> 	at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:269)
> 	at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:231)
> 	at org.infinispan.interceptors.TxInterceptor.visitPutKeyValueCommand(TxInterceptor.java:177)
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.updateStoreStatistics(CacheMgmtInterceptor.java:148)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:134)
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:106)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:70)
> 	at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32)
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:321)
> 	at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1298)
> 	at org.infinispan.CacheImpl.putInternal(CacheImpl.java:871)
> 	at org.infinispan.CacheImpl.put(CacheImpl.java:863)
> 	at org.infinispan.DecoratedCache.put(DecoratedCache.java:401)
> 	at org.infinispan.AbstractDelegatingCache.put(AbstractDelegatingCache.java:276)
> 	at org.hibernate.cache.infinispan.access.TransactionalAccessDelegate.update(TransactionalAccessDelegate.java:187) [hibernate-infinispan-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.cache.infinispan.entity.TransactionalAccess.update(TransactionalAccess.java:89) [hibernate-infinispan-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.action.internal.EntityUpdateAction.execute(EntityUpdateAction.java:208) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:377) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:369) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:287) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:340) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:52) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1235) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:405) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:113) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:53) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76)
> 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:273)
> 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:93)
> 	at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1170)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
> 	at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:93) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:437)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72)
> 	at bugrepro2.BugRepro2Rest$$$view31.manifestArjunaBug(Unknown Source) [classes:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_40]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_40]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_40]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_40]
> 	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:280) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:234) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:221) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:59) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:218) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:619) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> The datasource definition from standalone.xml:
>                 <datasource jndi-name="java:/BugRepro2DS" pool-name="BugRepro2DS" enabled="true">
>                     <connection-url>jdbc:mysql://localhost:3306/bugrepro2</connection-url>
>                     <driver>mysql</driver>
>                     <security>
>                         <user-name>*******</user-name>
>                         <password>*******</password>
>                     </security>
>                 </datasource>
>                 <drivers>
>                     <driver name="mysql" module="com.mysql">
>                         <xa-datasource-class>com.mysql.jdbc.jdbc2.optional.MysqlXADataSource</xa-datasource-class>
>                     </driver>
>                 </drivers>
> I have reported this also to Infinispan, because I am not sure which party is to blame.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 06:13:02 2013
From: jira-events at lists.jboss.org (prasad Kasthuri (JIRA))
Date: Wed, 9 Oct 2013 06:13:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2269) Integration tests in Wildfly
 are running into errors
In-Reply-To: <JIRA.12502538.1381312812000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502538.1381312812000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502538.1381312812000.27257.1381313582485@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812606#comment-12812606 ] 

prasad Kasthuri commented on WFLY-2269:
---------------------------------------

I am using Oracle JDK 1.7 with update 25. (1.7.0_25) and the OS is RHEL 6.
                
> Integration tests in Wildfly are running into errors
> ----------------------------------------------------
>
>                 Key: WFLY-2269
>                 URL: https://issues.jboss.org/browse/WFLY-2269
>             Project: WildFly
>          Issue Type: Feature Request
>            Reporter: prasad Kasthuri
>
> I am trying to run integration tests from wildfly Sources which is running into some issues. Running the test individually also causing the same issue. 
> ./integration-tests.sh  -Dts.clust -Dtest=org.jboss.as.test.clustering.cluster.dispatcher.CommandDispatcherTestCase
> -------------------------------------------------------
>  T E S T S
> -------------------------------------------------------
> Running org.jboss.as.test.clustering.cluster.dispatcher.CommandDispatcherTestCase
> Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 7.72 sec <<< FAILURE!
> Results :
> Tests in error:
>   org.jboss.as.test.clustering.cluster.dispatcher.CommandDispatcherTestCase: DeploymentScenario contains a target (container-0) not matching any defined Container in th
> e registry.(..)
>   org.jboss.as.test.clustering.cluster.dispatcher.CommandDispatcherTestCase
> Tests run: 2, Failures: 0, Errors: 2, Skipped: 0

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 06:34:02 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 9 Oct 2013 06:34:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2269) Integration tests in Wildfly
 are running into errors
In-Reply-To: <JIRA.12502538.1381312812000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502538.1381312812000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502538.1381312812000.27304.1381314842755@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar closed WFLY-2269.
-----------------------------

    Resolution: Rejected


This discussions belong to forums https://community.jboss.org/en/wildfly 
lets continue there.
                
> Integration tests in Wildfly are running into errors
> ----------------------------------------------------
>
>                 Key: WFLY-2269
>                 URL: https://issues.jboss.org/browse/WFLY-2269
>             Project: WildFly
>          Issue Type: Feature Request
>            Reporter: prasad Kasthuri
>
> I am trying to run integration tests from wildfly Sources which is running into some issues. Running the test individually also causing the same issue. 
> ./integration-tests.sh  -Dts.clust -Dtest=org.jboss.as.test.clustering.cluster.dispatcher.CommandDispatcherTestCase
> -------------------------------------------------------
>  T E S T S
> -------------------------------------------------------
> Running org.jboss.as.test.clustering.cluster.dispatcher.CommandDispatcherTestCase
> Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 7.72 sec <<< FAILURE!
> Results :
> Tests in error:
>   org.jboss.as.test.clustering.cluster.dispatcher.CommandDispatcherTestCase: DeploymentScenario contains a target (container-0) not matching any defined Container in th
> e registry.(..)
>   org.jboss.as.test.clustering.cluster.dispatcher.CommandDispatcherTestCase
> Tests run: 2, Failures: 0, Errors: 2, Skipped: 0

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 06:36:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 9 Oct 2013 06:36:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2270) Attempt to remove scoped role
 current user is a member of results in failure.
In-Reply-To: <JIRA.12502541.1381314949349@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502541.1381314949349@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502541.1381314949349.27317.1381314963388@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-2270:
--------------------------------------

             Summary: Attempt to remove scoped role current user is a member of results in failure.
                 Key: WFLY-2270
                 URL: https://issues.jboss.org/browse/WFLY-2270
             Project: WildFly
          Issue Type: Bug
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 8.0.0.CR1


Take the following scoped role definition and assignment: -

{code}
            <host-scoped-roles>
                <role name="master-Monitior" base-role="MONITOR">
                    <host name="master"/>
                </role>
            </host-scoped-roles>
{code}

{code}
 <role name="master-Monitior" include-all="true"/>
{code}

Removal results in the following: -

{code}
[domain at localhost:9990 /] ./core-service=management/access=authorization/host-scoped-role=master-Monitior:remove
{
    "outcome" => "failed",
    "failure-description" => {"domain-failure-description" => "JBAS014749: Operation handler failed: JBAS013470: Unknown role 'MASTER-MONITIOR'"},
    "rolled-back" => true
}
{code}

Server side this is reported as: -

{code}
[Host Controller] 11:24:57,780 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014612: Operation ("remove") failed - address: ([
[Host Controller]     ("core-service" => "management"),
[Host Controller]     ("access" => "authorization"),
[Host Controller]     ("host-scoped-role" => "master-Monitior")
[Host Controller] ]): java.lang.IllegalArgumentException: JBAS013470: Unknown role 'MASTER-MONITIOR'
[Host Controller] 	at org.jboss.as.controller.access.rbac.DefaultPermissionFactory.getUserPermissions(DefaultPermissionFactory.java:134) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
[Host Controller] 	at org.jboss.as.controller.access.rbac.DefaultPermissionFactory.getUserPermissions(DefaultPermissionFactory.java:107) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
[Host Controller] 	at org.jboss.as.controller.access.permission.ManagementPermissionAuthorizer.authorize(ManagementPermissionAuthorizer.java:99) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
[Host Controller] 	at org.jboss.as.controller.access.management.DelegatingConfigurableAuthorizer.authorize(DelegatingConfigurableAuthorizer.java:98) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
[Host Controller] 	at org.jboss.as.controller.OperationContextImpl.getBasicAuthorizationResponse(OperationContextImpl.java:1157) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
[Host Controller] 	at org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1059) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
[Host Controller] 	at org.jboss.as.controller.OperationContextImpl.readResourceFromRoot(OperationContextImpl.java:542) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
[Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationResolver.getServerOperations(ServerOperationResolver.java:232)
[Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.getServerOperations(ServerOperationsResolverHandler.java:149)
[Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.access$000(ServerOperationsResolverHandler.java:58)
[Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler$2.getServerOperations(ServerOperationsResolverHandler.java:113)
[Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.HostControllerExecutionSupport$Factory$DomainOpExecutionSupport.getServerOps(HostControllerExecutionSupport.java:265)
[Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.execute(ServerOperationsResolverHandler.java:124)
[Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:609) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
[Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:487) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
[Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
[Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
[Host Controller] 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:258) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
[Host Controller] 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:143) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
[Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:205) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
[Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:110) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
[Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:157) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
[Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:153) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
[Host Controller] 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_17]
[Host Controller] 	at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_17]
[Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
[Host Controller] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [wildfly-protocol-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
[Host Controller] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [wildfly-protocol-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
[Host Controller] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
[Host Controller] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
[Host Controller] 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
[Host Controller] 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
{code}

At this point I believe that role removal is actually successful, however a subsequent operation is failing as the role previously associated with the user no longer exists.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 06:54:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 9 Oct 2013 06:54:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2270) Attempt to remove scoped role
 current user is a member of results in failure.
In-Reply-To: <JIRA.12502541.1381314949000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502541.1381314949000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502541.1381314949000.27346.1381316043082@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812617#comment-12812617 ] 

Darran Lofthouse commented on WFLY-2270:
----------------------------------------

Further debugging this is not as complex as originally described, adding a new role-mapping that the current user is assigned to but where the role mapping does not map to a standard role or to a scoped role.

Need to double check with Brian, this may be an omission in role mapping creation - either we should ban the existence of the role in the first place or we need to ignore it when checking permissions.
                
> Attempt to remove scoped role current user is a member of results in failure.
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-2270
>                 URL: https://issues.jboss.org/browse/WFLY-2270
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Take the following scoped role definition and assignment: -
> {code}
>             <host-scoped-roles>
>                 <role name="master-Monitior" base-role="MONITOR">
>                     <host name="master"/>
>                 </role>
>             </host-scoped-roles>
> {code}
> {code}
>  <role name="master-Monitior" include-all="true"/>
> {code}
> Removal results in the following: -
> {code}
> [domain at localhost:9990 /] ./core-service=management/access=authorization/host-scoped-role=master-Monitior:remove
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "JBAS014749: Operation handler failed: JBAS013470: Unknown role 'MASTER-MONITIOR'"},
>     "rolled-back" => true
> }
> {code}
> Server side this is reported as: -
> {code}
> [Host Controller] 11:24:57,780 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014612: Operation ("remove") failed - address: ([
> [Host Controller]     ("core-service" => "management"),
> [Host Controller]     ("access" => "authorization"),
> [Host Controller]     ("host-scoped-role" => "master-Monitior")
> [Host Controller] ]): java.lang.IllegalArgumentException: JBAS013470: Unknown role 'MASTER-MONITIOR'
> [Host Controller] 	at org.jboss.as.controller.access.rbac.DefaultPermissionFactory.getUserPermissions(DefaultPermissionFactory.java:134) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.access.rbac.DefaultPermissionFactory.getUserPermissions(DefaultPermissionFactory.java:107) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.access.permission.ManagementPermissionAuthorizer.authorize(ManagementPermissionAuthorizer.java:99) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.access.management.DelegatingConfigurableAuthorizer.authorize(DelegatingConfigurableAuthorizer.java:98) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.OperationContextImpl.getBasicAuthorizationResponse(OperationContextImpl.java:1157) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1059) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.OperationContextImpl.readResourceFromRoot(OperationContextImpl.java:542) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationResolver.getServerOperations(ServerOperationResolver.java:232)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.getServerOperations(ServerOperationsResolverHandler.java:149)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.access$000(ServerOperationsResolverHandler.java:58)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler$2.getServerOperations(ServerOperationsResolverHandler.java:113)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.HostControllerExecutionSupport$Factory$DomainOpExecutionSupport.getServerOps(HostControllerExecutionSupport.java:265)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.execute(ServerOperationsResolverHandler.java:124)
> [Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:609) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:487) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:258) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:143) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:205) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:110) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:157) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:153) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_17]
> [Host Controller] 	at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_17]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [wildfly-protocol-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [wildfly-protocol-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> [Host Controller] 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> [Host Controller] 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> {code}
> At this point I believe that role removal is actually successful, however a subsequent operation is failing as the role previously associated with the user no longer exists.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 07:00:05 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 9 Oct 2013 07:00:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1547) deploy directories not
	cleaned up
In-Reply-To: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479851.1353935247000.27387.1381316405012@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812621#comment-12812621 ] 

RH Bugzilla Integration commented on WFLY-1547:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> made a comment on [bug 901210|https://bugzilla.redhat.com/show_bug.cgi?id=901210]

$JBOSS_HOME/standalone/tmp/vfs/
$JBOSS_HOME/domain/servers/$SERVER_NAME/tmp/vfs/
folders are now correctly cleaned up.

Additional info:
User shouldn't use "-Xrs" opt as this limits OS signals processing -> size of tmp/vfs keeps growing.

Verified on EAP 6.2.0.ER5.
                
> deploy directories not cleaned up
> ---------------------------------
>
>                 Key: WFLY-1547
>                 URL: https://issues.jboss.org/browse/WFLY-1547
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Shaun Appleton
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Beta1
>
>         Attachments: deployment_with_hack_no_hook.txt
>
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 07:00:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 9 Oct 2013 07:00:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1547) deploy directories not
	cleaned up
In-Reply-To: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479851.1353935247000.27374.1381316404341@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812619#comment-12812619 ] 

RH Bugzilla Integration commented on WFLY-1547:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> changed the Status of [bug 901210|https://bugzilla.redhat.com/show_bug.cgi?id=901210] from ON_QA to VERIFIED
                
> deploy directories not cleaned up
> ---------------------------------
>
>                 Key: WFLY-1547
>                 URL: https://issues.jboss.org/browse/WFLY-1547
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Shaun Appleton
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Beta1
>
>         Attachments: deployment_with_hack_no_hook.txt
>
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 07:00:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 9 Oct 2013 07:00:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2271) A problem setting include-all
 on a role mapping is failing getting rolled back.
In-Reply-To: <JIRA.12502544.1381316379039@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502544.1381316379039@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502544.1381316379039.27361.1381316403682@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-2271:
--------------------------------------

             Summary: A problem setting include-all on a role mapping is failing getting rolled back.
                 Key: WFLY-2271
                 URL: https://issues.jboss.org/browse/WFLY-2271
             Project: WildFly
          Issue Type: Bug
          Components: Domain Management
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 8.0.0.CR1


As a side effect of another bug the following failure occurs: -

{code}
[domain at localhost:9990 /] ./core-service=management/access=authorization/role-mapping=test:add
{
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => {"main-server-group" => {"host" => {"master" => {
        "server-one" => {"response" => {"outcome" => "success"}},
        "server-two" => {"response" => {"outcome" => "success"}}
    }}}}
}
[domain at localhost:9990 /] ./core-service=management/access=authorization/role-mapping=test:write-attribute(name=include-all, value=true)
{
    "outcome" => "failed",
    "failure-description" => {"domain-failure-description" => "JBAS014749: Operation handler failed: JBAS013470: Unknown role 'TEST'"},
    "rolled-back" => true
}
{code}

Roll back however fails with this error: -

{code}
[Host Controller] 11:47:25,216 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 11) JBAS014603:  caught exception attempting to revert operation write-attribute at address [
[Host Controller]     ("core-service" => "management"),
[Host Controller]     ("access" => "authorization"),
[Host Controller]     ("role-mapping" => "test")
[Host Controller] ]: java.lang.IllegalArgumentException
[Host Controller] 	at org.jboss.dmr.ModelValue.asBoolean(ModelValue.java:66) [jboss-dmr-1.2.0.Final.jar:1.2.0.Final]
[Host Controller] 	at org.jboss.dmr.ModelNode.asBoolean(ModelNode.java:262) [jboss-dmr-1.2.0.Final.jar:1.2.0.Final]
[Host Controller] 	at org.jboss.as.domain.management.access.RoleIncludeAllWriteAttributeHander.revertUpdateToRuntime(RoleIncludeAllWriteAttributeHander.java:65)
[Host Controller] 	at org.jboss.as.domain.management.access.RoleIncludeAllWriteAttributeHander.revertUpdateToRuntime(RoleIncludeAllWriteAttributeHander.java:35)
{code}

Two issues here: -
1 - "rolled-back" should not be true as it failed.
2 - The failure during rollback needs to be fixed, the default for this attribute if not set is 'false'.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 07:04:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 9 Oct 2013 07:04:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2271) A problem setting include-all
 on a role mapping is failing getting rolled back.
In-Reply-To: <JIRA.12502544.1381316379000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502544.1381316379000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502544.1381316379000.27396.1381316642656@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2271:
-----------------------------------

        Parent: WFLY-490
    Issue Type: Sub-task  (was: Bug)

    
> A problem setting include-all on a role mapping is failing getting rolled back.
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-2271
>                 URL: https://issues.jboss.org/browse/WFLY-2271
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> As a side effect of another bug the following failure occurs: -
> {code}
> [domain at localhost:9990 /] ./core-service=management/access=authorization/role-mapping=test:add
> {
>     "outcome" => "success",
>     "result" => undefined,
>     "server-groups" => {"main-server-group" => {"host" => {"master" => {
>         "server-one" => {"response" => {"outcome" => "success"}},
>         "server-two" => {"response" => {"outcome" => "success"}}
>     }}}}
> }
> [domain at localhost:9990 /] ./core-service=management/access=authorization/role-mapping=test:write-attribute(name=include-all, value=true)
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "JBAS014749: Operation handler failed: JBAS013470: Unknown role 'TEST'"},
>     "rolled-back" => true
> }
> {code}
> Roll back however fails with this error: -
> {code}
> [Host Controller] 11:47:25,216 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 11) JBAS014603:  caught exception attempting to revert operation write-attribute at address [
> [Host Controller]     ("core-service" => "management"),
> [Host Controller]     ("access" => "authorization"),
> [Host Controller]     ("role-mapping" => "test")
> [Host Controller] ]: java.lang.IllegalArgumentException
> [Host Controller] 	at org.jboss.dmr.ModelValue.asBoolean(ModelValue.java:66) [jboss-dmr-1.2.0.Final.jar:1.2.0.Final]
> [Host Controller] 	at org.jboss.dmr.ModelNode.asBoolean(ModelNode.java:262) [jboss-dmr-1.2.0.Final.jar:1.2.0.Final]
> [Host Controller] 	at org.jboss.as.domain.management.access.RoleIncludeAllWriteAttributeHander.revertUpdateToRuntime(RoleIncludeAllWriteAttributeHander.java:65)
> [Host Controller] 	at org.jboss.as.domain.management.access.RoleIncludeAllWriteAttributeHander.revertUpdateToRuntime(RoleIncludeAllWriteAttributeHander.java:35)
> {code}
> Two issues here: -
> 1 - "rolled-back" should not be true as it failed.
> 2 - The failure during rollback needs to be fixed, the default for this attribute if not set is 'false'.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 07:04:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 9 Oct 2013 07:04:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2270) Attempt to remove scoped role
 current user is a member of results in failure.
In-Reply-To: <JIRA.12502541.1381314949000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502541.1381314949000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502541.1381314949000.27399.1381316642800@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2270:
-----------------------------------

                    Parent: WFLY-490
    Workaround Description:   (was: Edit the role assignment so the user is no longer a member of that role before attempting to remove the scoped role.
)
                Issue Type: Sub-task  (was: Bug)
                Workaround:   (was: Workaround Exists)

    
> Attempt to remove scoped role current user is a member of results in failure.
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-2270
>                 URL: https://issues.jboss.org/browse/WFLY-2270
>             Project: WildFly
>          Issue Type: Sub-task
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Take the following scoped role definition and assignment: -
> {code}
>             <host-scoped-roles>
>                 <role name="master-Monitior" base-role="MONITOR">
>                     <host name="master"/>
>                 </role>
>             </host-scoped-roles>
> {code}
> {code}
>  <role name="master-Monitior" include-all="true"/>
> {code}
> Removal results in the following: -
> {code}
> [domain at localhost:9990 /] ./core-service=management/access=authorization/host-scoped-role=master-Monitior:remove
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "JBAS014749: Operation handler failed: JBAS013470: Unknown role 'MASTER-MONITIOR'"},
>     "rolled-back" => true
> }
> {code}
> Server side this is reported as: -
> {code}
> [Host Controller] 11:24:57,780 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014612: Operation ("remove") failed - address: ([
> [Host Controller]     ("core-service" => "management"),
> [Host Controller]     ("access" => "authorization"),
> [Host Controller]     ("host-scoped-role" => "master-Monitior")
> [Host Controller] ]): java.lang.IllegalArgumentException: JBAS013470: Unknown role 'MASTER-MONITIOR'
> [Host Controller] 	at org.jboss.as.controller.access.rbac.DefaultPermissionFactory.getUserPermissions(DefaultPermissionFactory.java:134) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.access.rbac.DefaultPermissionFactory.getUserPermissions(DefaultPermissionFactory.java:107) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.access.permission.ManagementPermissionAuthorizer.authorize(ManagementPermissionAuthorizer.java:99) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.access.management.DelegatingConfigurableAuthorizer.authorize(DelegatingConfigurableAuthorizer.java:98) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.OperationContextImpl.getBasicAuthorizationResponse(OperationContextImpl.java:1157) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1059) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.OperationContextImpl.readResourceFromRoot(OperationContextImpl.java:542) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationResolver.getServerOperations(ServerOperationResolver.java:232)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.getServerOperations(ServerOperationsResolverHandler.java:149)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.access$000(ServerOperationsResolverHandler.java:58)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler$2.getServerOperations(ServerOperationsResolverHandler.java:113)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.HostControllerExecutionSupport$Factory$DomainOpExecutionSupport.getServerOps(HostControllerExecutionSupport.java:265)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.execute(ServerOperationsResolverHandler.java:124)
> [Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:609) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:487) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:258) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:143) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:205) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:110) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:157) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:153) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_17]
> [Host Controller] 	at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_17]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [wildfly-protocol-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [wildfly-protocol-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> [Host Controller] 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> [Host Controller] 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> {code}
> At this point I believe that role removal is actually successful, however a subsequent operation is failing as the role previously associated with the user no longer exists.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 07:06:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 9 Oct 2013 07:06:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2270) Attempt to remove scoped role
 current user is a member of results in failure.
In-Reply-To: <JIRA.12502541.1381314949000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502541.1381314949000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502541.1381314949000.27402.1381316762637@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812623#comment-12812623 ] 

Darran Lofthouse commented on WFLY-2270:
----------------------------------------

*Workaround (Which may actually become the required steps anyway)*

  Remove the role-mapping associated with the scoped role first.
                
> Attempt to remove scoped role current user is a member of results in failure.
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-2270
>                 URL: https://issues.jboss.org/browse/WFLY-2270
>             Project: WildFly
>          Issue Type: Sub-task
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Take the following scoped role definition and assignment: -
> {code}
>             <host-scoped-roles>
>                 <role name="master-Monitior" base-role="MONITOR">
>                     <host name="master"/>
>                 </role>
>             </host-scoped-roles>
> {code}
> {code}
>  <role name="master-Monitior" include-all="true"/>
> {code}
> Removal results in the following: -
> {code}
> [domain at localhost:9990 /] ./core-service=management/access=authorization/host-scoped-role=master-Monitior:remove
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "JBAS014749: Operation handler failed: JBAS013470: Unknown role 'MASTER-MONITIOR'"},
>     "rolled-back" => true
> }
> {code}
> Server side this is reported as: -
> {code}
> [Host Controller] 11:24:57,780 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014612: Operation ("remove") failed - address: ([
> [Host Controller]     ("core-service" => "management"),
> [Host Controller]     ("access" => "authorization"),
> [Host Controller]     ("host-scoped-role" => "master-Monitior")
> [Host Controller] ]): java.lang.IllegalArgumentException: JBAS013470: Unknown role 'MASTER-MONITIOR'
> [Host Controller] 	at org.jboss.as.controller.access.rbac.DefaultPermissionFactory.getUserPermissions(DefaultPermissionFactory.java:134) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.access.rbac.DefaultPermissionFactory.getUserPermissions(DefaultPermissionFactory.java:107) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.access.permission.ManagementPermissionAuthorizer.authorize(ManagementPermissionAuthorizer.java:99) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.access.management.DelegatingConfigurableAuthorizer.authorize(DelegatingConfigurableAuthorizer.java:98) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.OperationContextImpl.getBasicAuthorizationResponse(OperationContextImpl.java:1157) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1059) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.OperationContextImpl.readResourceFromRoot(OperationContextImpl.java:542) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationResolver.getServerOperations(ServerOperationResolver.java:232)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.getServerOperations(ServerOperationsResolverHandler.java:149)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.access$000(ServerOperationsResolverHandler.java:58)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler$2.getServerOperations(ServerOperationsResolverHandler.java:113)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.HostControllerExecutionSupport$Factory$DomainOpExecutionSupport.getServerOps(HostControllerExecutionSupport.java:265)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.execute(ServerOperationsResolverHandler.java:124)
> [Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:609) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:487) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:258) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:143) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:205) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:110) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:157) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:153) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_17]
> [Host Controller] 	at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_17]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [wildfly-protocol-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [wildfly-protocol-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> [Host Controller] 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> [Host Controller] 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> {code}
> At this point I believe that role removal is actually successful, however a subsequent operation is failing as the role previously associated with the user no longer exists.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 07:12:03 2013
From: jira-events at lists.jboss.org (Bartosz Baranowski (JIRA))
Date: Wed, 9 Oct 2013 07:12:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2217) Enable reload tests
In-Reply-To: <JIRA.12502203.1380888864000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502203.1380888864000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502203.1380888864000.27417.1381317123074@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812624#comment-12812624 ] 

Bartosz Baranowski commented on WFLY-2217:
------------------------------------------

CustomBootstrapContextTestCase fix is in. Only thing lingering is IJ fix.
                
> Enable reload tests
> -------------------
>
>                 Key: WFLY-2217
>                 URL: https://issues.jboss.org/browse/WFLY-2217
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Test Suite
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Bartosz Baranowski
>            Assignee: Bartosz Baranowski
>
> Tests need not stay ignored any longer!
> Some tests which :reload are still ignored, even though :reload has been fixed ( well, it seems there is more to it due to other code changes )

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 07:18:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 9 Oct 2013 07:18:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1511)
 RemoteDomainConnection.close() will block forever if the master HC is not
 running
In-Reply-To: <JIRA.12494131.1371059684000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494131.1371059684000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494131.1371059684000.27434.1381317482658@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812627#comment-12812627 ] 

RH Bugzilla Integration commented on WFLY-1511:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> made a comment on [bug 1012850|https://bugzilla.redhat.com/show_bug.cgi?id=1012850]

Verified on EAP 6.2.0.ER5.
                
> RemoteDomainConnection.close() will block forever if the master HC is not running 
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-1511
>                 URL: https://issues.jboss.org/browse/WFLY-1511
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Brian Stansberry
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.Beta1
>
>
> RemoteDomainConnection.close() overrides FutureManagementChannel.close() to first send a "unregister" message to the master HC before calling the superclass functionality.
> Problem is this call tries to open a connection to the master and will block forever waiting for it to connect if the master isn't available, as seen at http://fpaste.org/18232/37105700/
> That example was from AutoIgnoredResourcesDomainTestCase which is concurrently shutting down the hosts in the domain, meaning the master can be shutting down in the middle of or prior to slave shutdown.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 07:18:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 9 Oct 2013 07:18:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1511)
 RemoteDomainConnection.close() will block forever if the master HC is not
 running
In-Reply-To: <JIRA.12494131.1371059684000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494131.1371059684000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494131.1371059684000.27437.1381317482795@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812628#comment-12812628 ] 

RH Bugzilla Integration commented on WFLY-1511:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> changed the Status of [bug 1012850|https://bugzilla.redhat.com/show_bug.cgi?id=1012850] from ON_QA to VERIFIED
                
> RemoteDomainConnection.close() will block forever if the master HC is not running 
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-1511
>                 URL: https://issues.jboss.org/browse/WFLY-1511
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Brian Stansberry
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.Beta1
>
>
> RemoteDomainConnection.close() overrides FutureManagementChannel.close() to first send a "unregister" message to the master HC before calling the superclass functionality.
> Problem is this call tries to open a connection to the master and will block forever waiting for it to connect if the master isn't available, as seen at http://fpaste.org/18232/37105700/
> That example was from AutoIgnoredResourcesDomainTestCase which is concurrently shutting down the hosts in the domain, meaning the master can be shutting down in the middle of or prior to slave shutdown.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 07:18:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Wed, 9 Oct 2013 07:18:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-293) Out of order RightTuples
 when adding rules dynamically
In-Reply-To: <JIRA.12502549.1381317479469@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502549.1381317479469@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502549.1381317479469.27441.1381317482978@jira02.app.mwc.hst.phx2.redhat.com>

Mario Fusco created DROOLS-293:
----------------------------------

             Summary: Out of order RightTuples when adding rules dynamically
                 Key: DROOLS-293
                 URL: https://issues.jboss.org/browse/DROOLS-293
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  6.0.0.CR4, 5.5.0.Final
            Reporter: Mario Fusco
            Assignee: Mario Fusco


When a a rule is dynamically added to the rule base the otnId for the newly created nodes is set on them lazily. In some cases this otnId setting is done too late causing the RightTuples, created as consequence of the addition of the new rule itself, to be added out of order in the respective FactHandles.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 07:36:02 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 9 Oct 2013 07:36:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1086) ant -Das=true clean jars
	failed
In-Reply-To: <JIRA.12501690.1380248503000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501690.1380248503000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501690.1380248503000.27481.1381318562680@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated JBJCA-1086:
-----------------------------------

    Fix Version/s: 1.1.1.Final

    
> ant -Das=true clean jars failed 
> --------------------------------
>
>                 Key: JBJCA-1086
>                 URL: https://issues.jboss.org/browse/JBJCA-1086
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Build
>    Affects Versions: 1.1.0.Final
>            Reporter: Lin Gao
>            Assignee: Lin Gao
>             Fix For: 1.1.1.Final
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 08:21:03 2013
From: jira-events at lists.jboss.org (Martin Kouba (JIRA))
Date: Wed, 9 Oct 2013 08:21:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1960) CDI @Inject of @Stateless
 @WebService cause WELD-001408 Unsatisfied dependencies
In-Reply-To: <JIRA.12499428.1377603560000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499428.1377603560000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499428.1377603560000.27560.1381321263110@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Kouba resolved WFLY-1960.
--------------------------------

    Resolution: Rejected

    
> CDI @Inject of @Stateless @WebService cause WELD-001408 Unsatisfied dependencies
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-1960
>                 URL: https://issues.jboss.org/browse/WFLY-1960
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld, EJB, Web Services
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Aslak Knutsen
>            Assignee: Martin Kouba
>
> CDI @Inject of @WebService does not work. 
> {code}
> import javax.ejb.Stateless;
> import javax.jws.WebService;
>  
> @Stateless
> @WebService
> public class TestBean {
> }
>  
>  
> import javax.inject.Inject;
>  
> import org.jboss.arquillian.container.test.api.Deployment;
> import org.jboss.arquillian.junit.Arquillian;
> import org.jboss.shrinkwrap.api.ShrinkWrap;
> import org.jboss.shrinkwrap.api.asset.EmptyAsset;
> import org.jboss.shrinkwrap.api.spec.WebArchive;
> import org.junit.Test;
> import org.junit.runner.RunWith;
>  
>  
> @RunWith(Arquillian.class)
> public class TestBeanIT {
>  
>     @Inject
>     TestBean bean;
>  
>     @Deployment
>     public static WebArchive createDeployment() {
>         WebArchive arch =  ShrinkWrap.create(WebArchive.class);
>         arch.addClass(TestBean.class);
>         arch.addAsWebInfResource(EmptyAsset.INSTANCE, "beans.xml");
>         return arch;
>     }
>  
>     @Test
>     public void fooTest() throws Exception {
>  
>     }
> }
> {code}
> Using CDI to do a non contextual injection on a class where @EJB is used instead of @Inject works.
> {code}
> @RunWith(Arquillian.class)
> public class TestBeanIT {
>  
>     @EJB
>     TestBean bean;
>     ...
> }
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 08:25:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 9 Oct 2013 08:25:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2173) Get subsystem test framework
 working with AS 7.2.0 legacy controller
In-Reply-To: <JIRA.12501755.1380296954000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501755.1380296954000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501755.1380296954000.27600.1381321502853@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812645#comment-12812645 ] 

RH Bugzilla Integration commented on WFLY-2173:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> made a comment on [bug 1015245|https://bugzilla.redhat.com/show_bug.cgi?id=1015245]

Backport PR is here: https://github.com/jbossas/jboss-eap/pull/523
                
> Get subsystem test framework working with AS 7.2.0 legacy controller
> --------------------------------------------------------------------
>
>                 Key: WFLY-2173
>                 URL: https://issues.jboss.org/browse/WFLY-2173
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 08:25:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 9 Oct 2013 08:25:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2185) Get core model test framework
 working with 7.2.0.Final legacy controller
In-Reply-To: <JIRA.12501848.1380553676000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501848.1380553676000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501848.1380553676000.27603.1381321503008@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812646#comment-12812646 ] 

RH Bugzilla Integration commented on WFLY-2185:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> made a comment on [bug 1015245|https://bugzilla.redhat.com/show_bug.cgi?id=1015245]

Backport PR is here: https://github.com/jbossas/jboss-eap/pull/523
                
> Get core model test framework working with 7.2.0.Final legacy controller
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2185
>                 URL: https://issues.jboss.org/browse/WFLY-2185
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 08:37:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 9 Oct 2013 08:37:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2217) Enable reload tests
In-Reply-To: <JIRA.12502203.1380888864000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502203.1380888864000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502203.1380888864000.27747.1381322223840@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2217:
------------------------------------------

    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=900065, https://bugzilla.redhat.com/show_bug.cgi?id=1017199  (was: https://bugzilla.redhat.com/show_bug.cgi?id=900065)

    
> Enable reload tests
> -------------------
>
>                 Key: WFLY-2217
>                 URL: https://issues.jboss.org/browse/WFLY-2217
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Test Suite
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Bartosz Baranowski
>            Assignee: Bartosz Baranowski
>
> Tests need not stay ignored any longer!
> Some tests which :reload are still ignored, even though :reload has been fixed ( well, it seems there is more to it due to other code changes )

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 08:39:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 9 Oct 2013 08:39:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2217) Enable reload tests
In-Reply-To: <JIRA.12502203.1380888864000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502203.1380888864000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502203.1380888864000.27769.1381322343568@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2217:
------------------------------------------

    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=900065  (was: https://bugzilla.redhat.com/show_bug.cgi?id=900065, https://bugzilla.redhat.com/show_bug.cgi?id=1017199)

    
> Enable reload tests
> -------------------
>
>                 Key: WFLY-2217
>                 URL: https://issues.jboss.org/browse/WFLY-2217
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Test Suite
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Bartosz Baranowski
>            Assignee: Bartosz Baranowski
>
> Tests need not stay ignored any longer!
> Some tests which :reload are still ignored, even though :reload has been fixed ( well, it seems there is more to it due to other code changes )

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 08:39:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 9 Oct 2013 08:39:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2271) A problem setting include-all
 on a role mapping is failing getting rolled back.
In-Reply-To: <JIRA.12502544.1381316379000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502544.1381316379000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502544.1381316379000.27771.1381322343648@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2271:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1017199

    
> A problem setting include-all on a role mapping is failing getting rolled back.
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-2271
>                 URL: https://issues.jboss.org/browse/WFLY-2271
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> As a side effect of another bug the following failure occurs: -
> {code}
> [domain at localhost:9990 /] ./core-service=management/access=authorization/role-mapping=test:add
> {
>     "outcome" => "success",
>     "result" => undefined,
>     "server-groups" => {"main-server-group" => {"host" => {"master" => {
>         "server-one" => {"response" => {"outcome" => "success"}},
>         "server-two" => {"response" => {"outcome" => "success"}}
>     }}}}
> }
> [domain at localhost:9990 /] ./core-service=management/access=authorization/role-mapping=test:write-attribute(name=include-all, value=true)
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "JBAS014749: Operation handler failed: JBAS013470: Unknown role 'TEST'"},
>     "rolled-back" => true
> }
> {code}
> Roll back however fails with this error: -
> {code}
> [Host Controller] 11:47:25,216 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 11) JBAS014603:  caught exception attempting to revert operation write-attribute at address [
> [Host Controller]     ("core-service" => "management"),
> [Host Controller]     ("access" => "authorization"),
> [Host Controller]     ("role-mapping" => "test")
> [Host Controller] ]: java.lang.IllegalArgumentException
> [Host Controller] 	at org.jboss.dmr.ModelValue.asBoolean(ModelValue.java:66) [jboss-dmr-1.2.0.Final.jar:1.2.0.Final]
> [Host Controller] 	at org.jboss.dmr.ModelNode.asBoolean(ModelNode.java:262) [jboss-dmr-1.2.0.Final.jar:1.2.0.Final]
> [Host Controller] 	at org.jboss.as.domain.management.access.RoleIncludeAllWriteAttributeHander.revertUpdateToRuntime(RoleIncludeAllWriteAttributeHander.java:65)
> [Host Controller] 	at org.jboss.as.domain.management.access.RoleIncludeAllWriteAttributeHander.revertUpdateToRuntime(RoleIncludeAllWriteAttributeHander.java:35)
> {code}
> Two issues here: -
> 1 - "rolled-back" should not be true as it failed.
> 2 - The failure during rollback needs to be fixed, the default for this attribute if not set is 'false'.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 09:19:02 2013
From: jira-events at lists.jboss.org (Thomas Sartissohn (JIRA))
Date: Wed, 9 Oct 2013 09:19:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-280) ChunkedInputFilter returning
 EOF when client closes connection without sending end chunk
In-Reply-To: <JIRA.12502562.1381324659684@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502562.1381324659684@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502562.1381324659684.27956.1381324742724@jira02.app.mwc.hst.phx2.redhat.com>

Thomas Sartissohn created JBWEB-280:
---------------------------------------

             Summary: ChunkedInputFilter returning EOF when client closes connection without sending end chunk
                 Key: JBWEB-280
                 URL: https://issues.jboss.org/browse/JBWEB-280
             Project: JBoss Web
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Tomcat
    Affects Versions: JBossWeb-7.0.13.GA
            Reporter: Thomas Sartissohn
            Assignee: Remy Maucherat


I have the case a client is sending the http request in chunks to the server. The server reads the incoming stream till EOF.

When the connection gets broken while I am reading the stream on the server, I do not get any exception. Instead I get an EOF. So in my case it seems I have already received the whole file, but at the end some bytes are missing.

The ChunkedInputFilter is just returning -1 instead of throwing some exception.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 10:23:02 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Wed, 9 Oct 2013 10:23:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2246) Weld subsystem transformers
	for 7.2.0
In-Reply-To: <JIRA.12502332.1381146729000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502332.1381146729000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502332.1381146729000.28175.1381328582910@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812716#comment-12812716 ] 

Kabir Khan commented on WFLY-2246:
----------------------------------

These have been implemented but I am not sure if discard if undefined + reject is defined for the two new attributes is totally correct. It might be better to discard if undefined, and to reject if it does not have the value assumed in the legacy version (false?)
                
> Weld subsystem transformers for 7.2.0
> -------------------------------------
>
>                 Key: WFLY-2246
>                 URL: https://issues.jboss.org/browse/WFLY-2246
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: CDI / Weld
>            Reporter: Kabir Khan
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 10:53:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 9 Oct 2013 10:53:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1487) Unable to read nested
 resource in WAR archive
In-Reply-To: <JIRA.12493917.1370849764000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493917.1370849764000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493917.1370849764000.28235.1381330383079@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812725#comment-12812725 ] 

RH Bugzilla Integration commented on WFLY-1487:
-----------------------------------------------

Ladislav Thon <lthon at redhat.com> made a comment on [bug 1017282|https://bugzilla.redhat.com/show_bug.cgi?id=1017282]

Description of problem:

If in WAR archive I have a resource in META-INF/properties/nested.properties, I am unable to access it using

  classLoader.getResource("META-INF/properties/nested.properties");

In a JAR archive, it works.

Version-Release number of selected component (if applicable):

EAP 6.2.0.ER5

How reproducible:

Always

Steps to Reproduce:
1. classLoader.getResource("META-INF/properties/nested.properties");

Actual results:

Correct URL.

Expected results:

null

Additional info:

This blocks bug 999663.
                
> Unable to read nested resource in WAR archive
> ---------------------------------------------
>
>                 Key: WFLY-1487
>                 URL: https://issues.jboss.org/browse/WFLY-1487
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (JBoss Web), Web (Undertow)
>            Reporter: Radim Hatlapatka
>            Assignee: David Lloyd
>             Fix For: 8.0.0.Alpha2
>
>
> Unable to retrieve resources which are nested in additional directory in META-INF. The same works for JAR, only for WAR archive it doesn't.
> Example:
> If in WAR archive I have a resource in META-INF/properties/nested.properties, I am unable to access it using
> {code}
> classLoader.getResource("META-INF/properties/nested.properties");
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 10:53:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 9 Oct 2013 10:53:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1487) Unable to read nested
 resource in WAR archive
In-Reply-To: <JIRA.12493917.1370849764000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493917.1370849764000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493917.1370849764000.28231.1381330382937@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-1487:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1017282

    
> Unable to read nested resource in WAR archive
> ---------------------------------------------
>
>                 Key: WFLY-1487
>                 URL: https://issues.jboss.org/browse/WFLY-1487
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (JBoss Web), Web (Undertow)
>            Reporter: Radim Hatlapatka
>            Assignee: David Lloyd
>             Fix For: 8.0.0.Alpha2
>
>
> Unable to retrieve resources which are nested in additional directory in META-INF. The same works for JAR, only for WAR archive it doesn't.
> Example:
> If in WAR archive I have a resource in META-INF/properties/nested.properties, I am unable to access it using
> {code}
> classLoader.getResource("META-INF/properties/nested.properties");
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 10:55:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 9 Oct 2013 10:55:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1487) Unable to read nested
 resource in WAR archive
In-Reply-To: <JIRA.12493917.1370849764000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493917.1370849764000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493917.1370849764000.28242.1381330502642@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812726#comment-12812726 ] 

RH Bugzilla Integration commented on WFLY-1487:
-----------------------------------------------

Ladislav Thon <lthon at redhat.com> made a comment on [bug 1017282|https://bugzilla.redhat.com/show_bug.cgi?id=1017282]

Oh man! I always swap the "actual" and "expected" results :-(
                
> Unable to read nested resource in WAR archive
> ---------------------------------------------
>
>                 Key: WFLY-1487
>                 URL: https://issues.jboss.org/browse/WFLY-1487
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (JBoss Web), Web (Undertow)
>            Reporter: Radim Hatlapatka
>            Assignee: David Lloyd
>             Fix For: 8.0.0.Alpha2
>
>
> Unable to retrieve resources which are nested in additional directory in META-INF. The same works for JAR, only for WAR archive it doesn't.
> Example:
> If in WAR archive I have a resource in META-INF/properties/nested.properties, I am unable to access it using
> {code}
> classLoader.getResource("META-INF/properties/nested.properties");
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 11:29:03 2013
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Wed, 9 Oct 2013 11:29:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-405) Patching system
In-Reply-To: <JIRA.12414447.1279060149000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12414447.1279060149000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12414447.1279060149000.28477.1381332543429@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emanuel Muckenhuber resolved WFLY-405.
--------------------------------------

    Resolution: Done


This should be mainly done now. New issues should be tracked as a separate issue.
                
> Patching system
> ---------------
>
>                 Key: WFLY-405
>                 URL: https://issues.jboss.org/browse/WFLY-405
>             Project: WildFly
>          Issue Type: Task
>          Components: Domain Management, Patching
>            Reporter: Brian Stansberry
>            Assignee: Emanuel Muckenhuber
>            Priority: Blocker
>              Labels: rhq
>             Fix For: 8.0.0.CR1
>
>
> "Server" side of the patching system. Server not in the sense of the domain model Server, but rather client-server where the client is whatever tool (JON) determines there are patches available and asks the server to apply them.
> This does not need to implemented until M2 but thinking about it during the design of the InstalledImage is good.
> Links to the current wiki articles:
> https://community.jboss.org/wiki/LayeredDistributionsAndModulePathOrganization
> https://community.jboss.org/wiki/SingleInstallationPatching
> https://community.jboss.org/wiki/ExperimentingWithSingleInstallationPatching

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 11:43:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 9 Oct 2013 11:43:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2270) Attempt to remove scoped role
 current user is a member of results in failure.
In-Reply-To: <JIRA.12502541.1381314949000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502541.1381314949000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502541.1381314949000.28605.1381333383048@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812782#comment-12812782 ] 

Darran Lofthouse commented on WFLY-2270:
----------------------------------------

The solution for this issue is going to be to enforce that for a role mapping to be defined either a standard role of the same name must exist or a scoped role of the same name must exist, a scoped role will then only be removable after the related role mapping has been removed.

                
> Attempt to remove scoped role current user is a member of results in failure.
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-2270
>                 URL: https://issues.jboss.org/browse/WFLY-2270
>             Project: WildFly
>          Issue Type: Sub-task
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Take the following scoped role definition and assignment: -
> {code}
>             <host-scoped-roles>
>                 <role name="master-Monitior" base-role="MONITOR">
>                     <host name="master"/>
>                 </role>
>             </host-scoped-roles>
> {code}
> {code}
>  <role name="master-Monitior" include-all="true"/>
> {code}
> Removal results in the following: -
> {code}
> [domain at localhost:9990 /] ./core-service=management/access=authorization/host-scoped-role=master-Monitior:remove
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "JBAS014749: Operation handler failed: JBAS013470: Unknown role 'MASTER-MONITIOR'"},
>     "rolled-back" => true
> }
> {code}
> Server side this is reported as: -
> {code}
> [Host Controller] 11:24:57,780 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014612: Operation ("remove") failed - address: ([
> [Host Controller]     ("core-service" => "management"),
> [Host Controller]     ("access" => "authorization"),
> [Host Controller]     ("host-scoped-role" => "master-Monitior")
> [Host Controller] ]): java.lang.IllegalArgumentException: JBAS013470: Unknown role 'MASTER-MONITIOR'
> [Host Controller] 	at org.jboss.as.controller.access.rbac.DefaultPermissionFactory.getUserPermissions(DefaultPermissionFactory.java:134) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.access.rbac.DefaultPermissionFactory.getUserPermissions(DefaultPermissionFactory.java:107) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.access.permission.ManagementPermissionAuthorizer.authorize(ManagementPermissionAuthorizer.java:99) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.access.management.DelegatingConfigurableAuthorizer.authorize(DelegatingConfigurableAuthorizer.java:98) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.OperationContextImpl.getBasicAuthorizationResponse(OperationContextImpl.java:1157) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1059) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.OperationContextImpl.readResourceFromRoot(OperationContextImpl.java:542) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationResolver.getServerOperations(ServerOperationResolver.java:232)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.getServerOperations(ServerOperationsResolverHandler.java:149)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.access$000(ServerOperationsResolverHandler.java:58)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler$2.getServerOperations(ServerOperationsResolverHandler.java:113)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.HostControllerExecutionSupport$Factory$DomainOpExecutionSupport.getServerOps(HostControllerExecutionSupport.java:265)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.execute(ServerOperationsResolverHandler.java:124)
> [Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:609) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:487) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:258) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:143) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:205) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:110) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:157) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:153) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_17]
> [Host Controller] 	at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_17]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [wildfly-protocol-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [wildfly-protocol-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> [Host Controller] 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> [Host Controller] 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> {code}
> At this point I believe that role removal is actually successful, however a subsequent operation is failing as the role previously associated with the user no longer exists.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 11:53:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 9 Oct 2013 11:53:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-369) Domain mode: kill an
	unresponsive JVM
In-Reply-To: <JIRA.12480351.1354566315000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12480351.1354566315000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12480351.1354566315000.28650.1381333983634@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812793#comment-12812793 ] 

RH Bugzilla Integration commented on WFLY-369:
----------------------------------------------

Emanuel Muckenhuber <emuckenh at redhat.com> changed the Status of [bug 901232|https://bugzilla.redhat.com/show_bug.cgi?id=901232] from NEW to ASSIGNED
                
> Domain mode: kill an unresponsive JVM
> -------------------------------------
>
>                 Key: WFLY-369
>                 URL: https://issues.jboss.org/browse/WFLY-369
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Dennis Reed
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.Alpha1
>
>
> If an AS instance gets into a state where it cannot be controlled normally by the host controller, local OS commands must be used to kill it.
> It would be helpful to be able to kill an unresponsive JVM through the management interface.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 12:04:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 9 Oct 2013 12:04:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-283) SegmentMemory staged
 LeftTuples not always accessed correctly
In-Reply-To: <JIRA.12502137.1380816662000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502137.1380816662000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502137.1380816662000.28693.1381334642768@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812799#comment-12812799 ] 

RH Bugzilla Integration commented on DROOLS-283:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> changed the Status of [bug 1015208|https://bugzilla.redhat.com/show_bug.cgi?id=1015208] from ASSIGNED to MODIFIED
                
> SegmentMemory staged LeftTuples not always accessed correctly
> -------------------------------------------------------------
>
>                 Key: DROOLS-283
>                 URL: https://issues.jboss.org/browse/DROOLS-283
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>            Assignee: Mark Proctor
>             Fix For: 6.0.0.CR5
>
>
> Some times it accesses the current staging list, instead of the one in the segment memory.
> The NotNode should use the passed staging list, and not retrieve it directly.
> They should always use takeAll, to ensure they are thread safe.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 12:04:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 9 Oct 2013 12:04:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-283) SegmentMemory staged
 LeftTuples not always accessed correctly
In-Reply-To: <JIRA.12502137.1380816662000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502137.1380816662000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502137.1380816662000.28695.1381334642977@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812800#comment-12812800 ] 

RH Bugzilla Integration commented on DROOLS-283:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> made a comment on [bug 1015208|https://bugzilla.redhat.com/show_bug.cgi?id=1015208]

Fixed by https://github.com/droolsjbpm/drools/commit/eca450ead9250116d2822b57eeae5cd2449a638e
                
> SegmentMemory staged LeftTuples not always accessed correctly
> -------------------------------------------------------------
>
>                 Key: DROOLS-283
>                 URL: https://issues.jboss.org/browse/DROOLS-283
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>            Assignee: Mark Proctor
>             Fix For: 6.0.0.CR5
>
>
> Some times it accesses the current staging list, instead of the one in the segment memory.
> The NotNode should use the passed staging list, and not retrieve it directly.
> They should always use takeAll, to ensure they are thread safe.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 12:17:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 9 Oct 2013 12:17:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-101) JMSService.start is doing
	blocking I/O
In-Reply-To: <JIRA.12489128.1365693199000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489128.1365693199000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489128.1365693199000.28719.1381335422826@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812803#comment-12812803 ] 

RH Bugzilla Integration commented on WFLY-101:
----------------------------------------------

Miroslav Novak <mnovak at redhat.com> changed the Status of [bug 1003913|https://bugzilla.redhat.com/show_bug.cgi?id=1003913] from ON_QA to VERIFIED
                
> JMSService.start is doing blocking I/O
> --------------------------------------
>
>                 Key: WFLY-101
>                 URL: https://issues.jboss.org/browse/WFLY-101
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.Alpha1
>
>
> flag the start context as asynchronous

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 12:17:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 9 Oct 2013 12:17:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-101) JMSService.start is doing
	blocking I/O
In-Reply-To: <JIRA.12489128.1365693199000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489128.1365693199000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489128.1365693199000.28721.1381335422896@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812804#comment-12812804 ] 

RH Bugzilla Integration commented on WFLY-101:
----------------------------------------------

Miroslav Novak <mnovak at redhat.com> made a comment on [bug 1003913|https://bugzilla.redhat.com/show_bug.cgi?id=1003913]

I could not verify this BZ using debugger but based on code review (also from D. Loyd) this fix is ok.

Verified in EAP 6.2.0.ER3.
                
> JMSService.start is doing blocking I/O
> --------------------------------------
>
>                 Key: WFLY-101
>                 URL: https://issues.jboss.org/browse/WFLY-101
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.Alpha1
>
>
> flag the start context as asynchronous

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 12:25:02 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 9 Oct 2013 12:25:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1087) Leak of WorkManager and
	BootstrapContext
In-Reply-To: <JIRA.12502210.1380891451000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502210.1380891451000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502210.1380891451000.28741.1381335902593@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBJCA-1087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812807#comment-12812807 ] 

Jesper Pedersen commented on JBJCA-1087:
----------------------------------------

That trace is from the :messaging: subsystem, but I'll verify the core behaviour of the BC/WM shutdown
                
> Leak of WorkManager and BootstrapContext
> ----------------------------------------
>
>                 Key: JBJCA-1087
>                 URL: https://issues.jboss.org/browse/JBJCA-1087
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.1.0.Final
>            Reporter: Bartosz Baranowski
>            Assignee: Jesper Pedersen
>
> There seems to be a leak of WorkManager and BootstrapContext clones. 
> NOTE: The clones are not standalone, for instance WorkManagerImpl.shutdown reference is shared among all clones, if one is shutdown, all of them are.
> The coordinators have an internal map of name/id -> [ BootstrapContext | WorkManager ]. They keep clones of default instance in it. In IJ code, deployers invoke coordinator.remove() method to keep it clean. However this does not happen in WFLY/AS7 ( only create is called ). 
> Here is a step by step scenario( more or less ):
> 1. WFLY boots
> 2. WorkManagerService is created( along with WorkManager instance, the default used in WMCoordinator )
> 3. RA is deployed/activated
> 4. IJ checks if there is BootstrapContext/WorkManager under "X", there is none, IJ creates clone of WM from #2 and BootstrapContext,  its stored under "X" in coordinators
> 5. Normal operations, msgs exchange, etc.
> 6. WFLY reload is called
> 7. WM from #2 shutdown() is called, this renders the clone stored under "X" as shutdown as well.
> 8. WFLY boots again
> 9. new WorkManagerService is created( along with WorkManager instance, the default used in WMCoordinator )
> 10. RA is deployed/activate
> 11. IJ checks if there is BootstrapContext/WorkManager under "X", there is, this instance is returned. 
> #11 old instance, which is shutdown since #7, is passed as WorkManager. This explodes:
> {noformat}
> ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 29) MSC000001: Failed to start service jboss.deployment.unit."mdb.jar".component.MDBLifecycleCallback.START: org.jboss.msc.service.StartException in service jboss.deployment.unit."mdb.jar".component.MDBLifecycleCallback.START: java.lang.RuntimeException: javax.resource.spi.work.WorkRejectedException: IJ000263: WorkManager is shutting down
> 	at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:57)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: java.lang.RuntimeException: javax.resource.spi.work.WorkRejectedException: IJ000263: WorkManager is shutting down
> 	at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent.activate(MessageDrivenComponent.java:218)
> 	at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent.start(MessageDrivenComponent.java:189)
> 	at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
> 	... 7 more
> Caused by: javax.resource.spi.work.WorkRejectedException: IJ000263: WorkManager is shutting down
> 	at org.jboss.jca.core.workmanager.WorkManagerImpl.doFirstChecks(WorkManagerImpl.java:776)
> 	at org.jboss.jca.core.workmanager.WorkManagerImpl.scheduleWork(WorkManagerImpl.java:617)
> 	at org.jboss.jca.core.workmanager.WorkManagerImpl.scheduleWork(WorkManagerImpl.java:602)
> 	at org.hornetq.ra.inflow.HornetQActivation.start(HornetQActivation.java:259)
> 	at org.hornetq.ra.HornetQResourceAdapter.endpointActivation(HornetQResourceAdapter.java:167)
> 	at org.jboss.jca.core.rar.EndpointImpl.activate(EndpointImpl.java:191)
> 	at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent.activate(MessageDrivenComponent.java:216)
> 	... 9 more
> {noformat}
> Steps to reproduce:
> 1. Setup an adapter deployment
> 2. reload
> 3. deploy MDB
> The reload OP has small bug, this branch (https://github.com/baranowb/wildfly/tree/WFLY-2217) has it fixed.
> Example test set: 
> {noformat}
> mvn clean install -DallTest -Dtest=CustomBootstrapContextTestCase,GetCallerPrincipalTestCase
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 12:58:03 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Wed, 9 Oct 2013 12:58:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2263) Access control meta data:
 Instance references
In-Reply-To: <JIRA.12502494.1381255726000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502494.1381255726000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502494.1381255726000.28963.1381337883769@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812826#comment-12812826 ] 

Kabir Khan commented on WFLY-2263:
----------------------------------

Or is it better to have a normal map of instance names, which then contain a list each? e.g.

{code}
    public static void main(String[] args) {
        ModelNode node = new ModelNode();

        node.get("HostA").add(createEntry("Server-1", "HostA"));
        node.get("HostA").add(createEntry("Server-2", "HostA"));
        node.get("HostB").add(createEntry("Server-2", "HostB"));

        System.out.println(node);
    }

    private static ModelNode createEntry(String server, String host) {
        ModelNode node = new ModelNode();
        node.get("addresss").add("subsystem", "datasources");
        node.get("addresss").add("server", server);
        node.get("addresss").add("host", host);
        node.get("read").set(true);
        node.get("write").set(true);
        return node;
    }
{code}

{code}
{
    "HostA" => [
        {
            "addresss" => [
                ("subsystem" => "datasources"),
                ("server" => "Server-1"),
                ("host" => "HostA")
            ],
            "read" => true,
            "write" => true
        },
        {
            "addresss" => [
                ("subsystem" => "datasources"),
                ("server" => "Server-2"),
                ("host" => "HostA")
            ],
            "read" => true,
            "write" => true
        }
    ],
    "HostB" => [{
        "addresss" => [
            ("subsystem" => "datasources"),
            ("server" => "Server-2"),
            ("host" => "HostB")
        ],
        "read" => true,
        "write" => true
    }]
}
{code}
If you want anything else, just let me know. It should be trivial to do once I know the format to do
                
> Access control meta data: Instance references
> ---------------------------------------------
>
>                 Key: WFLY-2263
>                 URL: https://issues.jboss.org/browse/WFLY-2263
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 13:00:02 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Wed, 9 Oct 2013 13:00:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2263) Access control meta data:
 Instance references
In-Reply-To: <JIRA.12502494.1381255726000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502494.1381255726000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502494.1381255726000.28969.1381338002739@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812826#comment-12812826 ] 

Kabir Khan edited comment on WFLY-2263 at 10/9/13 12:58 PM:
------------------------------------------------------------

Or is it better to have a normal map of instance names, which then contain a list each? e.g.

{code}
    public static void main(String[] args) {
        ModelNode node = new ModelNode();

        node.get("HostA").add(createEntry("Server-1", "HostA"));
        node.get("HostA").add(createEntry("Server-2", "HostA"));
        node.get("HostB").add(createEntry("Server-2", "HostB"));

        System.out.println(node);
    }

    private static ModelNode createEntry(String server, String host) {
        ModelNode node = new ModelNode();
        node.get("addresss").add("subsystem", "undertow");
        node.get("addresss").add("server", server);
        node.get("addresss").add("host", host);
        node.get("read").set(true);
        node.get("write").set(true);
        return node;
    }
{code}

{code}
{
    "HostA" => [
        {
            "addresss" => [
                ("subsystem" => "undertow"),
                ("server" => "Server-1"),
                ("host" => "HostA")
            ],
            "read" => true,
            "write" => true
        },
        {
            "addresss" => [
                ("subsystem" => "undertow"),
                ("server" => "Server-2"),
                ("host" => "HostA")
            ],
            "read" => true,
            "write" => true
        }
    ],
    "HostB" => [{
        "addresss" => [
            ("subsystem" => "undertow"),
            ("server" => "Server-2"),
            ("host" => "HostB")
        ],
        "read" => true,
        "write" => true
    }]
}
{code}
If you want anything else, just let me know. It should be trivial to do once I know the format to do
                
      was (Author: kabirkhan):
    Or is it better to have a normal map of instance names, which then contain a list each? e.g.

{code}
    public static void main(String[] args) {
        ModelNode node = new ModelNode();

        node.get("HostA").add(createEntry("Server-1", "HostA"));
        node.get("HostA").add(createEntry("Server-2", "HostA"));
        node.get("HostB").add(createEntry("Server-2", "HostB"));

        System.out.println(node);
    }

    private static ModelNode createEntry(String server, String host) {
        ModelNode node = new ModelNode();
        node.get("addresss").add("subsystem", "datasources");
        node.get("addresss").add("server", server);
        node.get("addresss").add("host", host);
        node.get("read").set(true);
        node.get("write").set(true);
        return node;
    }
{code}

{code}
{
    "HostA" => [
        {
            "addresss" => [
                ("subsystem" => "datasources"),
                ("server" => "Server-1"),
                ("host" => "HostA")
            ],
            "read" => true,
            "write" => true
        },
        {
            "addresss" => [
                ("subsystem" => "datasources"),
                ("server" => "Server-2"),
                ("host" => "HostA")
            ],
            "read" => true,
            "write" => true
        }
    ],
    "HostB" => [{
        "addresss" => [
            ("subsystem" => "datasources"),
            ("server" => "Server-2"),
            ("host" => "HostB")
        ],
        "read" => true,
        "write" => true
    }]
}
{code}
If you want anything else, just let me know. It should be trivial to do once I know the format to do
                  
> Access control meta data: Instance references
> ---------------------------------------------
>
>                 Key: WFLY-2263
>                 URL: https://issues.jboss.org/browse/WFLY-2263
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 13:00:03 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Wed, 9 Oct 2013 13:00:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2263) Access control meta data:
 Instance references
In-Reply-To: <JIRA.12502494.1381255726000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502494.1381255726000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502494.1381255726000.28975.1381338003244@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812469#comment-12812469 ] 

Kabir Khan edited comment on WFLY-2263 at 10/9/13 12:58 PM:
------------------------------------------------------------

Ah right, not a map like I thought when I looked quickly. So a list of property, where each property entry has the full address, and the access control. That should be possible. Something like this?
{code}
    public static void main(String[] args) {
        ModelNode node = new ModelNode();

        node.add("HostA", createEntry("Server-1", "HostA"));
        node.add("HostA", createEntry("Server-2", "HostA"));
        node.add("HostB", createEntry("Server-2", "HostB"));
        System.out.println(node);
    }

    private static ModelNode createEntry(String server, String host) {
        ModelNode node = new ModelNode();
        node.get("addresss").add("subsystem", "undertow");
        node.get("addresss").add("server", server);
        node.get("addresss").add("host", host);
        node.get("read").set(true);
        node.get("write").set(true);
        return node;
    }
{code}
Giving:
{code}
[
    ("HostA" => {
    "addresss" => [
        ("subsystem" => "undertow"),
        ("server" => "Server-1"),
        ("host" => "HostA")
    ],
    "read" => true,
    "write" => true
}),
    ("HostA" => {
    "addresss" => [
        ("subsystem" => "undertow"),
        ("server" => "Server-2"),
        ("host" => "HostA")
    ],
    "read" => true,
    "write" => true
}),
    ("HostB" => {
    "addresss" => [
        ("subsystem" => "undertow"),
        ("server" => "Server-2"),
        ("host" => "HostB")
    ],
    "read" => true,
    "write" => true
})
]
{code}

                
      was (Author: kabirkhan):
    Ah right, not a map like I thought when I looked quickly. So a list of property, where each property entry has the full address, and the access control. That should be possible. Something like this?
{code}
    public static void main(String[] args) {
        ModelNode node = new ModelNode();

        node.add("HostA", createEntry("Server-1", "HostA"));
        node.add("HostA", createEntry("Server-2", "HostA"));
        node.add("HostB", createEntry("Server-2", "HostB"));
        System.out.println(node);
    }

    private static ModelNode createEntry(String server, String host) {
        ModelNode node = new ModelNode();
        node.get("addresss").add("subsystem", "datasources");
        node.get("addresss").add("server", server);
        node.get("addresss").add("host", host);
        node.get("read").set(true);
        node.get("write").set(true);
        return node;
    }
{code}
Giving:
{code}
[
    ("HostA" => {
    "addresss" => [
        ("subsystem" => "undertow"),
        ("server" => "Server-1"),
        ("host" => "HostA")
    ],
    "read" => true,
    "write" => true
}),
    ("HostA" => {
    "addresss" => [
        ("subsystem" => "undertow"),
        ("server" => "Server-2"),
        ("host" => "HostA")
    ],
    "read" => true,
    "write" => true
}),
    ("HostB" => {
    "addresss" => [
        ("subsystem" => "undertow"),
        ("server" => "Server-2"),
        ("host" => "HostB")
    ],
    "read" => true,
    "write" => true
})
]
{code}

                  
> Access control meta data: Instance references
> ---------------------------------------------
>
>                 Key: WFLY-2263
>                 URL: https://issues.jboss.org/browse/WFLY-2263
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 13:08:02 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Wed, 9 Oct 2013 13:08:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2263) Access control meta data:
 Instance references
In-Reply-To: <JIRA.12502494.1381255726000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502494.1381255726000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502494.1381255726000.29004.1381338482743@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812833#comment-12812833 ] 

Heiko Braun commented on WFLY-2263:
-----------------------------------

It would be not to change overall structure in an incompatible way. So I would prefer we keep the properties (just simple keys) and introduce another address child at the property value level. But be aware that "address" not work, since we already use it for the "addressable" constraint.


                
> Access control meta data: Instance references
> ---------------------------------------------
>
>                 Key: WFLY-2263
>                 URL: https://issues.jboss.org/browse/WFLY-2263
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 13:08:02 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 9 Oct 2013 13:08:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2263) Access control meta data:
 Instance references
In-Reply-To: <JIRA.12502494.1381255726000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502494.1381255726000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502494.1381255726000.29006.1381338482801@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812834#comment-12812834 ] 

Brian Stansberry commented on WFLY-2263:
----------------------------------------

I'm sorry; I can't interpret those examples. Can you use examples that follow the actual model structure? That is, server is not a child of subsystem and host is not a child of server.
                
> Access control meta data: Instance references
> ---------------------------------------------
>
>                 Key: WFLY-2263
>                 URL: https://issues.jboss.org/browse/WFLY-2263
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 13:12:02 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Wed, 9 Oct 2013 13:12:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2263) Access control meta data:
 Instance references
In-Reply-To: <JIRA.12502494.1381255726000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502494.1381255726000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502494.1381255726000.29025.1381338722742@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812429#comment-12812429 ] 

Heiko Braun edited comment on WFLY-2263 at 10/9/13 1:10 PM:
------------------------------------------------------------

when requesting access control meta data, we return a the 'default' policy per resource type and 'exceptions' (instance specific) 

Here's an 'exception': 

{noformat}
[("subsystem" => "datasources"),("data-source" => "ExampleDS")]={
    "read" => true,
    "write" => false,
   
    [...]
}
{noformat}

As you can see it uses the string representation of the instance address as the property key. This makes it really hard to match that key against requested resources (property keys are just String in the DMR API). 

I would prefer the instance name to become the key, and instead provide an inline address represenation, of proper ModelType.LIST (like all other address attributes):

{noformat}
"ExampleDS"={
    instanceAddress = [("subsystem" => "datasources"),("data-source" => "ExampleDS")],
     "read" => true,
    "write" => false,
   
    [...]
}
{noformat}
                
      was (Author: heiko.braun):
    when requesting access control meta data, we return a the 'default' policy per resource type and 'exceptions' (instance specific) 

Here's an 'exception': 

{noformat}
[("subsystem" => "datasources"),("data-source" => "ExampleDS")]={
    "read" => true,
    "write" => false,
   
    [...]
}
{noformat}

As you can see it uses the string representation of the instance address as the property key. This makes it really hard to match that key against requested resources (property keys are just String in the DMR API). 

I would prefer the instance name to become the key, and instead provide an inline address represenation, of proper ModelType.LIST (like all other address attributes):

{noformat}
["ExampleDS"={
    instanceAddress = [("subsystem" => "datasources"),("data-source" => "ExampleDS")],
     "read" => true,
    "write" => false,
   
    [...]
}
{noformat}
                  
> Access control meta data: Instance references
> ---------------------------------------------
>
>                 Key: WFLY-2263
>                 URL: https://issues.jboss.org/browse/WFLY-2263
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 13:12:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Wed, 9 Oct 2013 13:12:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2263) Access control meta data:
 Instance references
In-Reply-To: <JIRA.12502494.1381255726000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502494.1381255726000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502494.1381255726000.29035.1381338723145@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812838#comment-12812838 ] 

Heiko Braun commented on WFLY-2263:
-----------------------------------

When I say "properties" i mean response structures that are key/value pairs. In the Java API we refer to those as dmr.Property.class



                
> Access control meta data: Instance references
> ---------------------------------------------
>
>                 Key: WFLY-2263
>                 URL: https://issues.jboss.org/browse/WFLY-2263
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 13:16:04 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Wed, 9 Oct 2013 13:16:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2263) Access control meta data:
 Instance references
In-Reply-To: <JIRA.12502494.1381255726000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502494.1381255726000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502494.1381255726000.29046.1381338964242@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812840#comment-12812840 ] 

Kabir Khan commented on WFLY-2263:
----------------------------------

o kkhan
18:06 hbraun
kkhan: just added my thought to https://issues.jboss.org/browse/WFLY-2263
18:06 jbossbot
jira [WFLY-2263] Access control meta data: Instance references [Open (Unresolved) Enhancement, Major, Brian Stansberry] https://issues.jboss.org/browse/WFLY-2263
18:06 hbraun
the least modifications the better
18:07
idealy in a compatible way with the structure we currently expect (adding child nodes is fone though)
18:07 ctomc has left IRC (Ping timeout: 240 seconds)
18:08 kkhan
hbraun: I don't totally get your reply - define 'properties (just simple keys)'
18:08 hbraun
kkhan: think kharder
18:09
kkhan: the response structure is a list of property model nodes (key value pairs)
18:09
kes sense now?
18:09 kkhan
Yes, so the key should be?
18:10
Since as mentioned if you have /subsystem=thing/parent=ONE/child=A and /subsystem=thing/parent=TWO/child=A
18:10
it cannot be simply 'A'
18:10
unless we change the structure
18:11
hbraun: ^
18:12 hbraun
kkhan: ok so we need distinct keys
18:12
that's what you mean
18:12
kkhan: in that case we can leave it as is, but simply add a child "address" note?
18:12 kkhan
hbraun: yes, so are you fine with the keys as they are now - but simply want a nicer/standard representation of the address in the value
18:13
sounds like we have agreement

18:13 hbraun
yes, i need a more simple (standard) way work with those addresses
18:13
+1
18:13
now we are the same page
18:13
can you add this to the issues description?
                
> Access control meta data: Instance references
> ---------------------------------------------
>
>                 Key: WFLY-2263
>                 URL: https://issues.jboss.org/browse/WFLY-2263
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 13:35:02 2013
From: jira-events at lists.jboss.org (Rob Stryker (JIRA))
Date: Wed, 9 Oct 2013 13:35:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2072) Build controller-client
 module and its dependencies for JDK 6
In-Reply-To: <JIRA.12500702.1379090464000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500702.1379090464000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500702.1379090464000.29146.1381340102641@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rob Stryker reopened WFLY-2072:
-------------------------------



re-opening due to failing tests that show xnio has an API requirement on java7. 

java.lang.NoClassDefFoundError: java/lang/ReflectiveOperationException
        at org.xnio.ssl.JsseXnioSsl.<init>(JsseXnioSsl.java:81)
        at org.xnio.Xnio.getSslProvider(Xnio.java:221)
        at org.jboss.remoting3.remote.RemoteConnectionProvider.connect(RemoteConnectionProvider.java:188)
        at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:296)
        at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:251)
        at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:349)
        at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:337)

                
> Build controller-client module and its dependencies for JDK 6
> -------------------------------------------------------------
>
>                 Key: WFLY-2072
>                 URL: https://issues.jboss.org/browse/WFLY-2072
>             Project: WildFly
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>
> WildFly is built for JDK 7, but the controller-client lib and its dependencies within the WF codebase do not need JDK 7 features and should be built with source and compile targets set to JDK 6. This will help prevent the need for running a different management client for WF 8 vs AS7/EAP6 due to the need to support JDK for the the latter.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 13:43:02 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Wed, 9 Oct 2013 13:43:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2263) Access control meta data:
 Instance references
In-Reply-To: <JIRA.12502494.1381255726000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502494.1381255726000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502494.1381255726000.29168.1381340582621@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan reassigned WFLY-2263:
--------------------------------

    Assignee: Kabir Khan  (was: Brian Stansberry)

    
> Access control meta data: Instance references
> ---------------------------------------------
>
>                 Key: WFLY-2263
>                 URL: https://issues.jboss.org/browse/WFLY-2263
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 13:49:02 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Wed, 9 Oct 2013 13:49:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2263) Access control meta data:
 Instance references
In-Reply-To: <JIRA.12502494.1381255726000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502494.1381255726000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502494.1381255726000.29196.1381340942660@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812851#comment-12812851 ] 

Kabir Khan commented on WFLY-2263:
----------------------------------

I'm not sure if this sends out mails when PRs are linked, so Heiko see ^^ for the PR
                
> Access control meta data: Instance references
> ---------------------------------------------
>
>                 Key: WFLY-2263
>                 URL: https://issues.jboss.org/browse/WFLY-2263
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 14:38:02 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Wed, 9 Oct 2013 14:38:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2072) Build controller-client
 module and its dependencies for JDK 6
In-Reply-To: <JIRA.12500702.1379090464000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500702.1379090464000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500702.1379090464000.29406.1381343882840@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812862#comment-12812862 ] 

David Lloyd commented on WFLY-2072:
-----------------------------------

Interesting: there is nothing in that class file that refers to that exception type.  It must be coming from someplace else... is there more context to the exception than that?
                
> Build controller-client module and its dependencies for JDK 6
> -------------------------------------------------------------
>
>                 Key: WFLY-2072
>                 URL: https://issues.jboss.org/browse/WFLY-2072
>             Project: WildFly
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>
> WildFly is built for JDK 7, but the controller-client lib and its dependencies within the WF codebase do not need JDK 7 features and should be built with source and compile targets set to JDK 6. This will help prevent the need for running a different management client for WF 8 vs AS7/EAP6 due to the need to support JDK for the the latter.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 14:42:02 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 9 Oct 2013 14:42:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2072) Build controller-client
 module and its dependencies for JDK 6
In-Reply-To: <JIRA.12500702.1379090464000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500702.1379090464000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500702.1379090464000.29456.1381344122886@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812863#comment-12812863 ] 

Brian Stansberry commented on WFLY-2072:
----------------------------------------

I've opened https://issues.jboss.org/browse/XNIO-207 to track the XNIO bug.

I'm leaving this open for now even though the specific task here (involving modules in the WF codebase itself) was done for Beta1. Easier than creating another JIRA to remind us to bring in the XNIO fix.

Thanks for the report!
                
> Build controller-client module and its dependencies for JDK 6
> -------------------------------------------------------------
>
>                 Key: WFLY-2072
>                 URL: https://issues.jboss.org/browse/WFLY-2072
>             Project: WildFly
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>
> WildFly is built for JDK 7, but the controller-client lib and its dependencies within the WF codebase do not need JDK 7 features and should be built with source and compile targets set to JDK 6. This will help prevent the need for running a different management client for WF 8 vs AS7/EAP6 due to the need to support JDK for the the latter.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 14:44:02 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Wed, 9 Oct 2013 14:44:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2072) Build controller-client
 module and its dependencies for JDK 6
In-Reply-To: <JIRA.12500702.1379090464000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500702.1379090464000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500702.1379090464000.29498.1381344242935@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812864#comment-12812864 ] 

David Lloyd commented on WFLY-2072:
-----------------------------------

Never mind, I found the spot where the compiler decided to be "clever".
                
> Build controller-client module and its dependencies for JDK 6
> -------------------------------------------------------------
>
>                 Key: WFLY-2072
>                 URL: https://issues.jboss.org/browse/WFLY-2072
>             Project: WildFly
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>
> WildFly is built for JDK 7, but the controller-client lib and its dependencies within the WF codebase do not need JDK 7 features and should be built with source and compile targets set to JDK 6. This will help prevent the need for running a different management client for WF 8 vs AS7/EAP6 due to the need to support JDK for the the latter.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 15:07:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 9 Oct 2013 15:07:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-78) Intermittent failures in
	RespawnTestCase
In-Reply-To: <JIRA.12483133.1358904844000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12483133.1358904844000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12483133.1358904844000.29750.1381345622940@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812869#comment-12812869 ] 

RH Bugzilla Integration commented on WFLY-78:
---------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1012809|https://bugzilla.redhat.com/show_bug.cgi?id=1012809] from POST to MODIFIED
                
> Intermittent failures in RespawnTestCase
> ----------------------------------------
>
>                 Key: WFLY-78
>                 URL: https://issues.jboss.org/browse/WFLY-78
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.Alpha1
>
>
> Problems like [1] still pop up fairly frequently. It seems the same 3 tests fail.
> Failed tests:   testReloadHcButNotServers(org.jboss.as.test.integration.respawn.RespawnTestCase)
> testReloadHcButNotServersWithFailedServer(org.jboss.as.test.integration.respawn.RespawnTestCase)  testHCReloadAbortPreservesServers(org.jboss.as.test.integration.respawn.RespawnTestCase)
> [1] http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-master-ignore/327/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 15:30:02 2013
From: jira-events at lists.jboss.org (William Siqueira (JIRA))
Date: Wed, 9 Oct 2013 15:30:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-294) Include Sample output for
 the REST API documentation
In-Reply-To: <JIRA.12502610.1381346936405@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502610.1381346936405@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502610.1381346936405.29795.1381347002664@jira02.app.mwc.hst.phx2.redhat.com>

William Siqueira created DROOLS-294:
---------------------------------------

             Summary: Include Sample output for the REST API documentation
                 Key: DROOLS-294
                 URL: https://issues.jboss.org/browse/DROOLS-294
             Project: Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: 5.5.0.Final
            Reporter: William Siqueira
            Assignee: Mark Proctor
            Priority: Minor


The documentation for the Drools REST API is good, but it would be better if it included some sample outputs for all the mentioned methods in some choose format.

This way we can see the fields that we can access and how they related to each other. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 15:45:02 2013
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Wed, 9 Oct 2013 15:45:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-141) JSR-115,
 JACC version changed from 1.4 to 1.5 in Maintenance Release 3 for
 Java EE 7 platform
In-Reply-To: <JIRA.12501330.1379963000000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501330.1379963000000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501330.1379963000000.29801.1381347902522@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBEE-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812874#comment-12812874 ] 

Shelly McGowan commented on JBEE-141:
-------------------------------------

https://repository.jboss.org/nexus/content/groups/public/org/jboss/spec/javax/security/jacc/jboss-jacc-api_1.5_spec/1.0.0.Beta1/

has been released.
                
> JSR-115, JACC version changed from 1.4 to 1.5 in Maintenance Release 3 for Java EE 7 platform
> ---------------------------------------------------------------------------------------------
>
>                 Key: JBEE-141
>                 URL: https://issues.jboss.org/browse/JBEE-141
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Sub-task
>          Components: jboss-javaee-specs
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>             Fix For: JavaEE 7 Spec APIs 1.0.0.Beta1
>
>
> http://jcp.org/en/jsr/detail?id=115

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 15:57:02 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Wed, 9 Oct 2013 15:57:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2272) component upgrade to
 Hibernate ORM 4.3.0.Beta5
In-Reply-To: <JIRA.12502612.1381348561824@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502612.1381348561824@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502612.1381348561824.29807.1381348622523@jira02.app.mwc.hst.phx2.redhat.com>

Scott Marlow created WFLY-2272:
----------------------------------

             Summary: component upgrade to Hibernate ORM 4.3.0.Beta5
                 Key: WFLY-2272
                 URL: https://issues.jboss.org/browse/WFLY-2272
             Project: WildFly
          Issue Type: Task
          Components: JPA / Hibernate
            Reporter: Scott Marlow
            Assignee: Scott Marlow
             Fix For: 8.0.0.CR1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 16:17:02 2013
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Wed, 9 Oct 2013 16:17:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-127) Java EE Connector Architecture
	(JSR-322)
In-Reply-To: <JIRA.12485874.1362013522000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485874.1362013522000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485874.1362013522000.29823.1381349822612@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBEE-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan resolved JBEE-127.
---------------------------------

    Resolution: Done


1.0.0.Beta1 promoted to Final:
https://repository.jboss.org/nexus/content/groups/public/org/jboss/spec/javax/resource/jboss-connector-api_1.7_spec/1.0.0.Final/
                
> Java EE Connector Architecture (JSR-322)
> ----------------------------------------
>
>                 Key: JBEE-127
>                 URL: https://issues.jboss.org/browse/JBEE-127
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Sub-task
>          Components: jboss-connector-api
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>             Fix For: JavaEE 7 Spec APIs 1.0.0.Beta1
>
>
> Project repo exists:
> https://github.com/jboss/jboss-connector-api_spec
> Need updates to for v1.7.
> {code}
>   <groupId>org.jboss.spec.javax.resource</groupId>
>   <artifactId>jboss-connector-api_1.7_spec</artifactId>
>   <version>1.0.0-SNAPSHOT</version>
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 16:19:02 2013
From: jira-events at lists.jboss.org (Patson Luk (JIRA))
Date: Wed, 9 Oct 2013 16:19:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-210) MethodCall.replace() throws
 inconsistent stack height in certain scenarios
In-Reply-To: <JIRA.12502614.1381349908060@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502614.1381349908060@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502614.1381349908060.29826.1381349942663@jira02.app.mwc.hst.phx2.redhat.com>

Patson Luk created JASSIST-210:
----------------------------------

             Summary: MethodCall.replace() throws inconsistent stack height in certain scenarios
                 Key: JASSIST-210
                 URL: https://issues.jboss.org/browse/JASSIST-210
             Project: Javassist
          Issue Type: Bug
            Reporter: Patson Luk
            Assignee: Shigeru Chiba


Tested on 3.16.1-GA

This is similar to https://issues.jboss.org/browse/JASSIST-52, but the try-catch block usage is different (not wrapping the $proceed($$))

Based on the javassist tutorial,  the substituted code for MethodCall.replace():
{{Note that the substituted code is not an expression but a statement or a block. It cannot be or contain a try-catch statement.}}

However in the case that try-catch does not wrap the $_=$proceed($$);
It seems to work properly. For example:

ctClass.instrument(new ExprEditor() {
    public void edit(MethodCall m) throws CannotCompileException {
        if (m.getMethodName().equals("testMethod2")) {
            String newBlock = "{ try { System.out.println(\"injected\"); } catch (Exception e) { e.printStackTrace(); } $_ = $proceed($$); }";
            m.replace(newBlock);
        }
    }
});

{{which ctClass is class TestReplace, which has code as below:}}

public class TestReplace {
    public static void main(String[] args) {
        RefClass ref = new RefClass();
        ref.testMethod2();
    }
}

class RefClass {
    public void testMethod1(Object o) {}
    public Object testMethod2() { return null; }
}

{{running TestReplace with the modified bytecode correctly prints "injected" to the screen. However if I add one more line to the TestReplace's main() method}}

ref.testMethod1(ref.testMethod2());

{{It throws exception as below}}
javassist.bytecode.BadBytecode: inconsistent stack height -1
javassist.bytecode.stackmap.Tracer.doOpcode(Tracer.java:106)

*So is try-catch acceptable if it does not wrap the $_=$proceed($$)? If so, is it a bug if it does not work properly for method invocation within another method invocation?*

Many thanks in advance!


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 16:19:02 2013
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Wed, 9 Oct 2013 16:19:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-132) Update jboss-jta-api_spec to
	version 1.2
In-Reply-To: <JIRA.12486565.1362585237000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12486565.1362585237000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12486565.1362585237000.29829.1381349942802@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBEE-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan resolved JBEE-132.
---------------------------------

    Resolution: Done


https://repository.jboss.org/nexus/content/groups/public/org/jboss/spec/javax/transaction/jboss-transaction-api_1.2_spec/1.0.0.Final/ has been released.  Once the CDI issue referenced is addressed, we can update the dependency version.
                
> Update jboss-jta-api_spec to version 1.2
> ----------------------------------------
>
>                 Key: JBEE-132
>                 URL: https://issues.jboss.org/browse/JBEE-132
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Sub-task
>          Components: jboss-javaee-specs
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>             Fix For: JavaEE 7 Spec APIs 1.0.0.Beta1
>
>
> From the Change Log of JSR-970, the API additions are annotations for Transactional and TransactionScoped.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 16:21:02 2013
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Wed, 9 Oct 2013 16:21:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-121) Tracker JIRA for APIs required
 by the Java EE 7 Platform Specification
In-Reply-To: <JIRA.12485867.1362012695000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485867.1362012695000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485867.1362012695000.29835.1381350062719@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBEE-121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12760038#comment-12760038 ] 

Shelly McGowan edited comment on JBEE-121 at 10/9/13 4:19 PM:
--------------------------------------------------------------

Other EE 7 API releases:
Bean Validation 1.1:
http://repo1.maven.org/maven2/javax/validation/validation-api/1.1.0.Final/

CDI 1.1:
http://repo1.maven.org/maven2/javax/enterprise/cdi-api/1.1/

JPA 2.1 (Hibernate):
https://repository.jboss.org/nexus/content/groups/public/org/hibernate/javax/persistence/hibernate-jpa-2.1-api/1.0.0.Final/
                
      was (Author: shelly.mcgowan):
    Other EE 7 API releases:
Bean Validation 1.1:
http://repo1.maven.org/maven2/javax/validation/validation-api/1.1.0.Final/

CDI 1.1:
http://repo1.maven.org/maven2/javax/enterprise/cdi-api/1.1/

JPA 2.1 (Hibernate):
https://repository.jboss.org/nexus/content/groups/public/org/hibernate/javax/persistence/hibernate-jpa-2.1-api/1.0.0.Draft-16/
                  
> Tracker JIRA for APIs required by the Java EE 7 Platform Specification
> ----------------------------------------------------------------------
>
>                 Key: JBEE-121
>                 URL: https://issues.jboss.org/browse/JBEE-121
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: jboss-javaee-specs
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>             Fix For: JavaEE 7 Spec APIs 1.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 16:21:03 2013
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Wed, 9 Oct 2013 16:21:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-122) Concurrency Utilities for Java
	EE (JSR-236)
In-Reply-To: <JIRA.12485868.1362012798000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485868.1362012798000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485868.1362012798000.29844.1381350063098@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBEE-122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812881#comment-12812881 ] 

Shelly McGowan commented on JBEE-122:
-------------------------------------

1.0.0.Final release of EE Concurrency APIs has been performed:
https://repository.jboss.org/nexus/content/groups/public/org/jboss/spec/javax/enterprise/concurrent/jboss-concurrency-api_1.0_spec/1.0.0.Final/
                
> Concurrency Utilities for Java EE (JSR-236) 
> --------------------------------------------
>
>                 Key: JBEE-122
>                 URL: https://issues.jboss.org/browse/JBEE-122
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Sub-task
>          Components: jboss-javaee-concurrency-api
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>             Fix For: JavaEE 7 Spec APIs 1.0.0.Beta1
>
>
> These APIs are required as part of our Java EE 7 implementation.
> They should be added to the org.jboss.spec project:
> {code}
> <dependency>
>     <groupId>org.jboss.spec.javax.enterprise.concurrent</groupId>
>     <artifactId>jboss-concurrent-api_1.0_spec</artifactId>
>     <version>1.0.0.Final-SNAPSHOT</version>
> </dependency>
> {code}
> Project can be created in http://github.com/jboss/jboss-concurrent-api_spec

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 16:23:03 2013
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Wed, 9 Oct 2013 16:23:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-129) Common Annotations for the
 JavaTM Platform 1.2 (JSR-250)
In-Reply-To: <JIRA.12486215.1362424640000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12486215.1362424640000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12486215.1362424640000.29857.1381350183241@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBEE-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812883#comment-12812883 ] 

Shelly McGowan commented on JBEE-129:
-------------------------------------

1.0.0.Final has been released:
https://repository.jboss.org/nexus/content/groups/public/org/jboss/spec/javax/annotation/jboss-annotations-api_1.2_spec/1.0.0.Final/
                
> Common Annotations for the JavaTM Platform 1.2 (JSR-250)
> --------------------------------------------------------
>
>                 Key: JBEE-129
>                 URL: https://issues.jboss.org/browse/JBEE-129
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Sub-task
>          Components: jboss-javaee-specs
>            Reporter: Jozef Hartinger
>            Assignee: Shelly McGowan
>             Fix For: JavaEE 7 Spec APIs 1.0.0.Beta1
>
>
> http://jcp.org/aboutJava/communityprocess/maintenance/jsr250/jsr250changelog_2.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 16:23:03 2013
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Wed, 9 Oct 2013 16:23:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-130) Interceptors 1.2
In-Reply-To: <JIRA.12486223.1362429292000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12486223.1362429292000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12486223.1362429292000.29868.1381350183875@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBEE-130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812884#comment-12812884 ] 

Shelly McGowan commented on JBEE-130:
-------------------------------------

1.0.0.Final has been released:
https://repository.jboss.org/nexus/content/groups/public/org/jboss/spec/javax/interceptor/jboss-interceptors-api_1.2_spec/1.0.0.Final/
                
> Interceptors 1.2
> ----------------
>
>                 Key: JBEE-130
>                 URL: https://issues.jboss.org/browse/JBEE-130
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Sub-task
>          Components: jboss-interceptors-api
>            Reporter: Jozef Hartinger
>            Assignee: Jozef Hartinger
>             Fix For: JavaEE 7 Spec APIs 1.0.0.Beta1
>
>
> http://java.net/projects/interceptors-spec/sources/interceptors-spec-repository/content/1.2/Interceptors-1.2-changes.txt?rev=17

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 16:25:03 2013
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Wed, 9 Oct 2013 16:25:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-125) Batch Applications for the
 Java Platform (JSR-352)
In-Reply-To: <JIRA.12485871.1362012984000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485871.1362012984000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485871.1362012984000.29883.1381350303144@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBEE-125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812885#comment-12812885 ] 

Shelly McGowan commented on JBEE-125:
-------------------------------------

1.0.0.Beta1 has been promoted to 1.0.0.Final:
https://repository.jboss.org/nexus/content/groups/public/org/jboss/spec/javax/batch/jboss-batch-api_1.0_spec/1.0.0.Final/
with a few minor JavaDoc updates:
https://github.com/jboss/jboss-batch-api_spec/commit/accd912d1187ec78509b9e26e8edea8565cf5ed3

                
> Batch Applications for the Java Platform (JSR-352) 
> ---------------------------------------------------
>
>                 Key: JBEE-125
>                 URL: https://issues.jboss.org/browse/JBEE-125
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Sub-task
>          Components: jboss-batch-api
>            Reporter: Shelly McGowan
>            Assignee: Cheng Fang
>             Fix For: JavaEE 7 Spec APIs 1.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 16:27:02 2013
From: jira-events at lists.jboss.org (sean galway (JIRA))
Date: Wed, 9 Oct 2013 16:27:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2273) Error message in the log on
 every click within the console in domain mode.
In-Reply-To: <JIRA.12502615.1381350328939@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502615.1381350328939@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502615.1381350328939.29886.1381350422631@jira02.app.mwc.hst.phx2.redhat.com>

sean galway created WFLY-2273:
---------------------------------

             Summary: Error message in the log on every click within the console in domain mode.
                 Key: WFLY-2273
                 URL: https://issues.jboss.org/browse/WFLY-2273
             Project: WildFly
          Issue Type: Bug
          Components: Web Console
    Affects Versions: 8.0.0.Beta1
         Environment: Rhel 2.6.18-348.18.1.e15 x86-64, two cpus
            Reporter: sean galway
            Assignee: Heiko Braun


While running Wildfly in domain mode (i.e domain.sh) every click within the admin console produces and error message in the server log. 


[Host Controller] 13:53:38,148 ERROR [org.jboss.as.controller.client] (XNIO-1 task-12) JBAS014781: Step handler org.jboss.as.domain.controller.operations.coordination.DomainFinalResultHandler at 576bca9e for operation composite at address [] failed handling operation rollback -- null

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 16:27:02 2013
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Wed, 9 Oct 2013 16:27:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-126) Java Message Service 2.0
	(JSR-343)
In-Reply-To: <JIRA.12485873.1362013278000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485873.1362013278000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485873.1362013278000.29892.1381350422919@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBEE-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812887#comment-12812887 ] 

Shelly McGowan commented on JBEE-126:
-------------------------------------

JMS 2.0 APIs have been released .Final:
https://repository.jboss.org/nexus/content/groups/public/org/jboss/spec/javax/jms/jboss-jms-api_2.0_spec/1.0.0.Final/
                
> Java Message Service 2.0 (JSR-343) 
> -----------------------------------
>
>                 Key: JBEE-126
>                 URL: https://issues.jboss.org/browse/JBEE-126
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Sub-task
>          Components: jboss-jms-api
>            Reporter: Shelly McGowan
>            Assignee: Jeff Mesnil
>             Fix For: JavaEE 7 Spec APIs 1.0.0.Beta1
>
>
> Project repo exists:
> https://github.com/jboss/jboss-jms-api_spec
> Need updates/release for v2.0 of the Java Message Service APIs
> {code}
>   <groupId>org.jboss.spec.javax.jms</groupId>
>   <artifactId>jboss-jms-api_2.0_spec</artifactId>
>   <version>1.0.0-SNAPSHOT</version>
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 16:27:02 2013
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Wed, 9 Oct 2013 16:27:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-128) EJB 3.2 API (JSR-345) for EE7
In-Reply-To: <JIRA.12486003.1362122889000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12486003.1362122889000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12486003.1362122889000.29890.1381350422847@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBEE-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812886#comment-12812886 ] 

Shelly McGowan commented on JBEE-128:
-------------------------------------

EJB 3.2 APIs have been released .Final:
https://repository.jboss.org/nexus/content/groups/public/org/jboss/spec/javax/ejb/jboss-ejb-api_3.2_spec/1.0.0.Final/
                
> EJB 3.2 API (JSR-345) for EE7 
> ------------------------------
>
>                 Key: JBEE-128
>                 URL: https://issues.jboss.org/browse/JBEE-128
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Sub-task
>          Components: jboss-ejb-api, jboss-javaee-specs
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For: JavaEE 7 Spec APIs 1.0.0.Beta1
>
>
> Update the Java EE EJB API to incorporate the EJB 3.2 updates.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 17:56:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 9 Oct 2013 17:56:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2255) ManagedAuditLoggerImpl
 doesn't replace handlers correctly
In-Reply-To: <JIRA.12502407.1381207161000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502407.1381207161000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502407.1381207161000.29951.1381355762577@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2255:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1017441

    
> ManagedAuditLoggerImpl doesn't replace handlers correctly
> ---------------------------------------------------------
>
>                 Key: WFLY-2255
>                 URL: https://issues.jboss.org/browse/WFLY-2255
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Josef Cacek
>            Assignee: Josef Cacek
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 17:58:02 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 9 Oct 2013 17:58:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2274) Expose the list of standard
 role names and of all role names
In-Reply-To: <JIRA.12502621.1381355785815@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502621.1381355785815@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502621.1381355785815.29954.1381355882545@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-2274:
--------------------------------------

             Summary: Expose the list of standard role names and of all role names
                 Key: WFLY-2274
                 URL: https://issues.jboss.org/browse/WFLY-2274
             Project: WildFly
          Issue Type: Sub-task
            Reporter: Brian Stansberry




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 17:58:02 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 9 Oct 2013 17:58:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2274) Expose the list of standard
 role names and of all role names
In-Reply-To: <JIRA.12502621.1381355785000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502621.1381355785000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502621.1381355785000.29955.1381355882617@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFLY-2274:
--------------------------------------

    Assignee: Brian Stansberry

    
> Expose the list of standard role names and of all role names
> ------------------------------------------------------------
>
>                 Key: WFLY-2274
>                 URL: https://issues.jboss.org/browse/WFLY-2274
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 18:02:02 2013
From: jira-events at lists.jboss.org (Josef Cacek (JIRA))
Date: Wed, 9 Oct 2013 18:02:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2255) ManagedAuditLoggerImpl
 doesn't replace handlers correctly
In-Reply-To: <JIRA.12502407.1381207161000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502407.1381207161000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502407.1381207161000.29970.1381356122644@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Josef Cacek updated WFLY-2255:
------------------------------

    Bugzilla Update:   (was: Perform)

    
> ManagedAuditLoggerImpl doesn't replace handlers correctly
> ---------------------------------------------------------
>
>                 Key: WFLY-2255
>                 URL: https://issues.jboss.org/browse/WFLY-2255
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Josef Cacek
>            Assignee: Josef Cacek
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 18:02:02 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Wed, 9 Oct 2013 18:02:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2272) component upgrade to
 Hibernate ORM 4.3.0.Beta5
In-Reply-To: <JIRA.12502612.1381348561000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502612.1381348561000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502612.1381348561000.29973.1381356122828@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812911#comment-12812911 ] 

Scott Marlow commented on WFLY-2272:
------------------------------------

getting a CCE http://pastie.org/8390672 
                
> component upgrade to Hibernate ORM 4.3.0.Beta5
> ----------------------------------------------
>
>                 Key: WFLY-2272
>                 URL: https://issues.jboss.org/browse/WFLY-2272
>             Project: WildFly
>          Issue Type: Task
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 19:01:02 2013
From: jira-events at lists.jboss.org (Josef Cacek (JIRA))
Date: Wed, 9 Oct 2013 19:01:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2255) ManagedAuditLoggerImpl
 doesn't replace handlers correctly
In-Reply-To: <JIRA.12502407.1381207161000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502407.1381207161000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502407.1381207161000.30015.1381359662543@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Josef Cacek updated WFLY-2255:
------------------------------

    Git Pull Request: https://github.com/wildfly/wildfly/pull/5237  (was: https://github.com/wildfly/wildfly/pull/5230)

    
> ManagedAuditLoggerImpl doesn't replace handlers correctly
> ---------------------------------------------------------
>
>                 Key: WFLY-2255
>                 URL: https://issues.jboss.org/browse/WFLY-2255
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Josef Cacek
>            Assignee: Josef Cacek
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 19:03:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 9 Oct 2013 19:03:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2268) Add Generic JMS RA
In-Reply-To: <JIRA.12502537.1381312737000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502537.1381312737000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502537.1381312737000.30018.1381359782587@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812916#comment-12812916 ] 

RH Bugzilla Integration commented on WFLY-2268:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1016762|https://bugzilla.redhat.com/show_bug.cgi?id=1016762] from NEW to MODIFIED
                
> Add Generic JMS RA
> ------------------
>
>                 Key: WFLY-2268
>                 URL: https://issues.jboss.org/browse/WFLY-2268
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JCA, JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.CR1
>
>
> WildFly could integrate the Generic JMS RA[1] to be able to use JMS brokers that does not provide a resource adapter.
> [1] https://github.com/jms-ra/generic-jms-ra

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 19:03:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 9 Oct 2013 19:03:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1487) Unable to read nested
 resource in WAR archive
In-Reply-To: <JIRA.12493917.1370849764000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493917.1370849764000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493917.1370849764000.30021.1381359782709@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812918#comment-12812918 ] 

RH Bugzilla Integration commented on WFLY-1487:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1017282|https://bugzilla.redhat.com/show_bug.cgi?id=1017282] from NEW to MODIFIED
                
> Unable to read nested resource in WAR archive
> ---------------------------------------------
>
>                 Key: WFLY-1487
>                 URL: https://issues.jboss.org/browse/WFLY-1487
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (JBoss Web), Web (Undertow)
>            Reporter: Radim Hatlapatka
>            Assignee: David Lloyd
>             Fix For: 8.0.0.Alpha2
>
>
> Unable to retrieve resources which are nested in additional directory in META-INF. The same works for JAR, only for WAR archive it doesn't.
> Example:
> If in WAR archive I have a resource in META-INF/properties/nested.properties, I am unable to access it using
> {code}
> classLoader.getResource("META-INF/properties/nested.properties");
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 23:23:02 2013
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Wed, 9 Oct 2013 23:23:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-141) JSR-115,
 JACC version changed from 1.4 to 1.5 in Maintenance Release 3 for
 Java EE 7 platform
In-Reply-To: <JIRA.12501330.1379963000000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501330.1379963000000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501330.1379963000000.30145.1381375382590@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBEE-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan reassigned JBEE-141:
-----------------------------------

    Assignee: Stefan Guilhen  (was: Shelly McGowan)


Reassigning to Stefan as he has some JavaDoc updates pending.     Reassign back to me and I'll do the release.
                
> JSR-115, JACC version changed from 1.4 to 1.5 in Maintenance Release 3 for Java EE 7 platform
> ---------------------------------------------------------------------------------------------
>
>                 Key: JBEE-141
>                 URL: https://issues.jboss.org/browse/JBEE-141
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Sub-task
>          Components: jboss-javaee-specs
>            Reporter: Shelly McGowan
>            Assignee: Stefan Guilhen
>             Fix For: JavaEE 7 Spec APIs 1.0.0.Beta1
>
>
> http://jcp.org/en/jsr/detail?id=115

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 23:25:02 2013
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Wed, 9 Oct 2013 23:25:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-140) Java Authentication Service
 Provider Interface for Containers 1.1 (JSR-196)
In-Reply-To: <JIRA.12498523.1376434986000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498523.1376434986000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498523.1376434986000.30149.1381375502562@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBEE-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan reassigned JBEE-140:
-----------------------------------

    Assignee: Stefan Guilhen  (was: Shelly McGowan)


JavaDoc updates pending.  Reassigning to Stefan.  Once complete, reassign back to do the Final release.
                
> Java Authentication Service Provider Interface for Containers 1.1 (JSR-196)
> ---------------------------------------------------------------------------
>
>                 Key: JBEE-140
>                 URL: https://issues.jboss.org/browse/JBEE-140
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Sub-task
>          Components: jboss-jaspi-api
>            Reporter: Shelly McGowan
>            Assignee: Stefan Guilhen
>             Fix For: JavaEE 7 Spec APIs 1.0.0.Beta1
>
>
> Updates needed for JASPIC 1.1.
> See linked issue.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct  9 23:36:02 2013
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Wed, 9 Oct 2013 23:36:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-121) Tracker JIRA for APIs required
 by the Java EE 7 Platform Specification
In-Reply-To: <JIRA.12485867.1362012695000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485867.1362012695000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485867.1362012695000.30155.1381376162681@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBEE-121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812931#comment-12812931 ] 

Shelly McGowan commented on JBEE-121:
-------------------------------------

Pull request sent to update APIs to Final:
https://github.com/wildfly/wildfly/pull/5249
                
> Tracker JIRA for APIs required by the Java EE 7 Platform Specification
> ----------------------------------------------------------------------
>
>                 Key: JBEE-121
>                 URL: https://issues.jboss.org/browse/JBEE-121
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: jboss-javaee-specs
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>             Fix For: JavaEE 7 Spec APIs 1.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 03:21:02 2013
From: jira-events at lists.jboss.org (Bartosz Baranowski (JIRA))
Date: Thu, 10 Oct 2013 03:21:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1087) Leak of WorkManager and
	BootstrapContext
In-Reply-To: <JIRA.12502210.1380891451000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502210.1380891451000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502210.1380891451000.30263.1381389662580@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBJCA-1087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812951#comment-12812951 ] 

Bartosz Baranowski commented on JBJCA-1087:
-------------------------------------------

Indeed, trace is from messaging. However, WM/BC comes from IJ.
                
> Leak of WorkManager and BootstrapContext
> ----------------------------------------
>
>                 Key: JBJCA-1087
>                 URL: https://issues.jboss.org/browse/JBJCA-1087
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.1.0.Final
>            Reporter: Bartosz Baranowski
>            Assignee: Jesper Pedersen
>
> There seems to be a leak of WorkManager and BootstrapContext clones. 
> NOTE: The clones are not standalone, for instance WorkManagerImpl.shutdown reference is shared among all clones, if one is shutdown, all of them are.
> The coordinators have an internal map of name/id -> [ BootstrapContext | WorkManager ]. They keep clones of default instance in it. In IJ code, deployers invoke coordinator.remove() method to keep it clean. However this does not happen in WFLY/AS7 ( only create is called ). 
> Here is a step by step scenario( more or less ):
> 1. WFLY boots
> 2. WorkManagerService is created( along with WorkManager instance, the default used in WMCoordinator )
> 3. RA is deployed/activated
> 4. IJ checks if there is BootstrapContext/WorkManager under "X", there is none, IJ creates clone of WM from #2 and BootstrapContext,  its stored under "X" in coordinators
> 5. Normal operations, msgs exchange, etc.
> 6. WFLY reload is called
> 7. WM from #2 shutdown() is called, this renders the clone stored under "X" as shutdown as well.
> 8. WFLY boots again
> 9. new WorkManagerService is created( along with WorkManager instance, the default used in WMCoordinator )
> 10. RA is deployed/activate
> 11. IJ checks if there is BootstrapContext/WorkManager under "X", there is, this instance is returned. 
> #11 old instance, which is shutdown since #7, is passed as WorkManager. This explodes:
> {noformat}
> ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 29) MSC000001: Failed to start service jboss.deployment.unit."mdb.jar".component.MDBLifecycleCallback.START: org.jboss.msc.service.StartException in service jboss.deployment.unit."mdb.jar".component.MDBLifecycleCallback.START: java.lang.RuntimeException: javax.resource.spi.work.WorkRejectedException: IJ000263: WorkManager is shutting down
> 	at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:57)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: java.lang.RuntimeException: javax.resource.spi.work.WorkRejectedException: IJ000263: WorkManager is shutting down
> 	at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent.activate(MessageDrivenComponent.java:218)
> 	at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent.start(MessageDrivenComponent.java:189)
> 	at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
> 	... 7 more
> Caused by: javax.resource.spi.work.WorkRejectedException: IJ000263: WorkManager is shutting down
> 	at org.jboss.jca.core.workmanager.WorkManagerImpl.doFirstChecks(WorkManagerImpl.java:776)
> 	at org.jboss.jca.core.workmanager.WorkManagerImpl.scheduleWork(WorkManagerImpl.java:617)
> 	at org.jboss.jca.core.workmanager.WorkManagerImpl.scheduleWork(WorkManagerImpl.java:602)
> 	at org.hornetq.ra.inflow.HornetQActivation.start(HornetQActivation.java:259)
> 	at org.hornetq.ra.HornetQResourceAdapter.endpointActivation(HornetQResourceAdapter.java:167)
> 	at org.jboss.jca.core.rar.EndpointImpl.activate(EndpointImpl.java:191)
> 	at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent.activate(MessageDrivenComponent.java:216)
> 	... 9 more
> {noformat}
> Steps to reproduce:
> 1. Setup an adapter deployment
> 2. reload
> 3. deploy MDB
> The reload OP has small bug, this branch (https://github.com/baranowb/wildfly/tree/WFLY-2217) has it fixed.
> Example test set: 
> {noformat}
> mvn clean install -DallTest -Dtest=CustomBootstrapContextTestCase,GetCallerPrincipalTestCase
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 03:49:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 10 Oct 2013 03:49:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1374) Unable to start JBoss server
 after issuing kill -9
In-Reply-To: <JIRA.12492408.1369213708000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12492408.1369213708000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12492408.1369213708000.30279.1381391343348@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-1374:
------------------------------------------

    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=965374, https://bugzilla.redhat.com/show_bug.cgi?id=1017563  (was: https://bugzilla.redhat.com/show_bug.cgi?id=965374)

    
> Unable to start JBoss server after issuing kill -9
> --------------------------------------------------
>
>                 Key: WFLY-1374
>                 URL: https://issues.jboss.org/browse/WFLY-1374
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Emanuel Muckenhuber
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.Beta1
>
>
> After manually killing a server it fails on subsequent start attempt using the management console or CLI.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 03:49:03 2013
From: jira-events at lists.jboss.org (Jari Juslin (JIRA))
Date: Thu, 10 Oct 2013 03:49:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2267) Persisting a new entity bean
 with certain patterns fails to ARJUNA016082 on flush stage.
In-Reply-To: <JIRA.12502535.1381312028000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502535.1381312028000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502535.1381312028000.30283.1381391343715@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812953#comment-12812953 ] 

Jari Juslin commented on WFLY-2267:
-----------------------------------

Looking at the JBoss process with a debugger and at the trace level loggings, it would seem that late on the flush stage a new sub-transaction is created for the update (after persist) operation, and the newly created sub-transaction does not see the previous ones. Thus, when this new sub-transaction is added to the main transaction, Exception is thrown.

Log from the flush stage:

2013-10-10 10:23:23,912 TRACE [org.jboss.as.jpa.messages] (default task-1:) persist entityClass 'bugrepro2.BugReproEntity' took 103ms
2013-10-10 10:23:23,912 TRACE [org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization] (default task-1:) JTA sync : beforeCompletion()
2013-10-10 10:23:23,912 TRACE [org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl] (default task-1:) Transaction before completion callback
2013-10-10 10:23:23,912 TRACE [org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl] (default task-1:) Automatically flushing session
2013-10-10 10:23:23,912 TRACE [org.hibernate.internal.SessionImpl] (default task-1:) Automatically flushing session
2013-10-10 10:23:23,912 TRACE [org.hibernate.event.internal.AbstractFlushingEventListener] (default task-1:) Flushing session
2013-10-10 10:23:23,913 DEBUG [org.hibernate.event.internal.AbstractFlushingEventListener] (default task-1:) Processing flush-time cascades
2013-10-10 10:23:23,913 TRACE [org.hibernate.engine.internal.Cascade] (default task-1:) Processing cascade ACTION_PERSIST_ON_FLUSH for: bugrepro2.BugReproEntity
2013-10-10 10:23:23,913 TRACE [org.hibernate.engine.internal.Cascade] (default task-1:) Done processing cascade ACTION_PERSIST_ON_FLUSH for: bugrepro2.BugReproEntity
2013-10-10 10:23:23,913 DEBUG [org.hibernate.event.internal.AbstractFlushingEventListener] (default task-1:) Dirty checking collections
2013-10-10 10:23:23,913 TRACE [org.hibernate.event.internal.AbstractFlushingEventListener] (default task-1:) Flushing entities and processing referenced collections
2013-10-10 10:23:23,914 TRACE [org.hibernate.persister.entity.AbstractEntityPersister] (default task-1:) bugrepro2.BugReproEntity.hasChanges is dirty
2013-10-10 10:23:23,915 TRACE [org.hibernate.event.internal.DefaultFlushEntityEventListener] (default task-1:) Found dirty properties [[bugrepro2.BugReproEntity#21]] : [Ljava.lang.String;@40fc3733
2013-10-10 10:23:23,915 TRACE [org.hibernate.event.internal.DefaultFlushEntityEventListener] (default task-1:) Updating entity: [bugrepro2.BugReproEntity#21]
2013-10-10 10:23:23,916 TRACE [org.hibernate.event.internal.AbstractFlushingEventListener] (default task-1:) Processing unreferenced collections
2013-10-10 10:23:23,916 TRACE [org.hibernate.event.internal.AbstractFlushingEventListener] (default task-1:) Scheduling collection removes/(re)creates/updates
2013-10-10 10:23:23,916 DEBUG [org.hibernate.event.internal.AbstractFlushingEventListener] (default task-1:) Flushed: 0 insertions, 1 updates, 0 deletions to 1 objects
2013-10-10 10:23:23,916 DEBUG [org.hibernate.event.internal.AbstractFlushingEventListener] (default task-1:) Flushed: 0 (re)creations, 0 updates, 0 removals to 0 collections
2013-10-10 10:23:23,917 DEBUG [org.hibernate.internal.util.EntityPrinter] (default task-1:) Listing entities:
2013-10-10 10:23:23,917 DEBUG [org.hibernate.internal.util.EntityPrinter] (default task-1:) bugrepro2.BugReproEntity{id=21, hasChanges=true}
2013-10-10 10:23:23,917 TRACE [org.hibernate.event.internal.AbstractFlushingEventListener] (default task-1:) Executing flush
2013-10-10 10:23:23,920 TRACE [org.hibernate.persister.entity.AbstractEntityPersister] (default task-1:) Updating entity: [bugrepro2.BugReproEntity#21]
2013-10-10 10:23:23,920 TRACE [org.hibernate.service.internal.AbstractServiceRegistryImpl] (default task-1:) Initializing service [role=org.hibernate.engine.jdbc.batch.spi.BatchBuilder]
2013-10-10 10:23:23,922 TRACE [org.hibernate.service.internal.AbstractServiceRegistryImpl] (default task-1:) Initializing service [role=org.hibernate.jmx.spi.JmxService]
2013-10-10 10:23:23,923 TRACE [org.hibernate.engine.jdbc.batch.internal.BatchBuilderImpl] (default task-1:) Building batch [size=1]
2013-10-10 10:23:23,924 DEBUG [org.hibernate.SQL] (default task-1:) update bugrepro_entity set has_changes=? where id=?
2013-10-10 10:23:23,924 DEBUG [org.hibernate.engine.jdbc.internal.LogicalConnectionImpl] (default task-1:) Obtaining JDBC connection
2013-10-10 10:23:23,924 DEBUG [org.hibernate.engine.jdbc.internal.LogicalConnectionImpl] (default task-1:) Obtained JDBC connection
2013-10-10 10:23:23,925 TRACE [org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl] (default task-1:) Registering statement [org.jboss.jca.adapters.jdbc.jdk7.WrappedPreparedStatementJDK7 at 62d019c]
2013-10-10 10:23:23,925 TRACE [org.hibernate.persister.entity.AbstractEntityPersister] (default task-1:) Dehydrating entity: [bugrepro2.BugReproEntity#21]
2013-10-10 10:23:23,925 TRACE [org.hibernate.type.descriptor.sql.BasicBinder] (default task-1:) binding parameter [1] as [BOOLEAN] - true
2013-10-10 10:23:23,925 TRACE [org.hibernate.type.descriptor.sql.BasicBinder] (default task-1:) binding parameter [2] as [INTEGER] - 21
2013-10-10 10:23:23,930 TRACE [org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl] (default task-1:) Releasing statement [org.jboss.jca.adapters.jdbc.jdk7.WrappedPreparedStatementJDK7 at 62d019c]
2013-10-10 10:23:23,930 TRACE [org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl] (default task-1:) Closing prepared statement [org.jboss.jca.adapters.jdbc.jdk7.WrappedPreparedStatementJDK7 at 62d019c]
2013-10-10 10:23:23,930 TRACE [org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl] (default task-1:) Starting after statement execution processing [AFTER_STATEMENT]
2013-10-10 10:23:23,930 DEBUG [org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl] (default task-1:) Skipping aggressive release due to manual disabling
2013-10-10 10:23:23,932 TRACE [org.infinispan.interceptors.InvocationContextInterceptor] (default task-1:infinispan_bug_reproduction2.war#persistence_context2.bugrepro2.BugReproEntity) Invoked with command PutKeyValueCommand{key=bugrepro2.BugReproEntity#21, value=CacheEnt
ry(bugrepro2.BugReproEntity)[true], flags=[SKIP_CACHE_LOAD, SKIP_REMOTE_LOOKUP], putIfAbsent=false, metadata=EmbeddedExpirableMetadata{lifespan=-1, maxIdle=100000, version=null}, successful=true, ignorePreviousValue=false} and InvocationContext [org.infinispan.context.imp
l.LocalTxInvocationContext at 3f58b8c0]
2013-10-10 10:23:23,934 TRACE [org.infinispan.transaction.TransactionTable] (default task-1:infinispan_bug_reproduction2.war#persistence_context2.bugrepro2.BugReproEntity) Created a new local transaction: LocalTransaction{remoteLockedNodes=null, isMarkedForRollback=false,
 lockedKeys=null, backupKeyLocks=null, topologyId=-1, isFromStateTransfer=false} org.infinispan.transaction.synchronization.SyncLocalTransaction at 1
2013-10-10 10:23:23,936 WARN  [org.infinispan.transaction.TransactionTable] (default task-1:infinispan_bug_reproduction2.war#persistence_context2.bugrepro2.BugReproEntity) ISPN000101: Failed synchronization registration: java.lang.IllegalStateException: ARJUNA016082: Synchronizations are not allowed! Transaction status isActionStatus.RUNNING
        at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronizationImple(TransactionImple.java:379)
        at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronization(TransactionImple.java:356)
        at org.infinispan.transaction.TransactionTable.enlist(TransactionTable.java:196)

                
> Persisting a new entity bean with certain patterns fails to ARJUNA016082 on flush stage.
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-2267
>                 URL: https://issues.jboss.org/browse/WFLY-2267
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>    Affects Versions: 8.0.0.Alpha4, 8.0.0.Beta1
>         Environment: Ubuntu Linux 13.04, JDK 1.7.0u40 64-bit.
>            Reporter: Jari Juslin
>            Assignee: jaikiran pai
>         Attachments: infinispan_bug_repro.zip, infinispan_bug_repro2.zip
>
>
> Persisting a new entity inside a CMT and then exiting the transactional method throws ARJUNA016082 in certain cases.
> I have extracted two cases where the bug manifests.
> 1) Creating a new entity bean and then changing one field after the persist call.
> 2) Creating a new entity bean that has another entity linked to it, and the newly created entity is on the blind side of the relationship.
> Here is the RESTeasy service and the entity bean needed to replicate this (also packaged to the attached test case):
> package bugrepro2;
> import javax.ejb.LocalBean;
> import javax.ejb.Stateless;
> import javax.persistence.EntityManager;
> import javax.persistence.PersistenceContext;
> import javax.ws.rs.POST;
> import javax.ws.rs.Path;
> /**
>  * @author Jari Juslin, zds at ecolane.com
>  */
> @Stateless
> @LocalBean
> @Path("/bug_repro2")
> public class BugRepro2Rest {
>     @PersistenceContext(unitName = "persistence_context2")
>     protected EntityManager entityManager;
>     
>     @POST
>     public String manifestArjunaBug() {
>         BugReproEntity entry = new BugReproEntity();
>         entityManager.persist(entry);
>         
>         entry.setHasChanges(true);
>         
>         return "Success\n";
>     }
> }
> package bugrepro2;
> import javax.persistence.Column;
> import javax.persistence.Entity;
> import javax.persistence.GeneratedValue;
> import javax.persistence.GenerationType;
> import javax.persistence.Id;
> import javax.persistence.Table;
> import org.hibernate.annotations.Cache;
> import org.hibernate.annotations.CacheConcurrencyStrategy;
> @Entity()
> @Table(name = "bugrepro_entity")
> @Cache(usage=CacheConcurrencyStrategy.TRANSACTIONAL)
> public class BugReproEntity {
>     private Integer id;
>     private boolean hasChanges;
>     public BugReproEntity() {
>     }
>     @Id
>     @GeneratedValue(strategy=GenerationType.IDENTITY)
>     @Column(name="id")
>     public Integer getId() {
>         return id;
>     }
>     public void setId(Integer id) {
>         this.id = id;
>     }
>     @Column(name="has_changes")
>     public boolean getHasChanges() {
>         return hasChanges;
>     }
>     public void setHasChanges(boolean hasChanges) {
>         this.hasChanges = hasChanges;
>     }
> }
> The resulting exception:
> 2013-10-09 12:44:07,362 WARN  [org.infinispan.transaction.TransactionTable] (default task-31:) ISPN000101: Failed synchronization registration: java.lang.IllegalStateException: ARJUNA016082: Synchronizations are not allowed! Transaction status isActionStatus.RUNNING
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronizationImple(TransactionImple.java:379)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronization(TransactionImple.java:356)
> 	at org.infinispan.transaction.TransactionTable.enlist(TransactionTable.java:196)
> 	at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:269)
> 	at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:231)
> 	at org.infinispan.interceptors.TxInterceptor.visitPutKeyValueCommand(TxInterceptor.java:177)
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.updateStoreStatistics(CacheMgmtInterceptor.java:148)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:134)
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:106)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:70)
> 	at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32)
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:321)
> 	at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1298)
> 	at org.infinispan.CacheImpl.putInternal(CacheImpl.java:871)
> 	at org.infinispan.CacheImpl.put(CacheImpl.java:863)
> 	at org.infinispan.DecoratedCache.put(DecoratedCache.java:401)
> 	at org.infinispan.AbstractDelegatingCache.put(AbstractDelegatingCache.java:276)
> 	at org.hibernate.cache.infinispan.access.TransactionalAccessDelegate.update(TransactionalAccessDelegate.java:187) [hibernate-infinispan-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.cache.infinispan.entity.TransactionalAccess.update(TransactionalAccess.java:89) [hibernate-infinispan-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.action.internal.EntityUpdateAction.execute(EntityUpdateAction.java:208) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:377) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:369) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:287) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:340) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:52) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1235) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:405) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:113) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:53) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76)
> 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:273)
> 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:93)
> 	at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1170)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
> 	at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:93) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:437)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72)
> 	at bugrepro2.BugRepro2Rest$$$view31.manifestArjunaBug(Unknown Source) [classes:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_40]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_40]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_40]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_40]
> 	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:280) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:234) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:221) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:59) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:218) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:619) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> The datasource definition from standalone.xml:
>                 <datasource jndi-name="java:/BugRepro2DS" pool-name="BugRepro2DS" enabled="true">
>                     <connection-url>jdbc:mysql://localhost:3306/bugrepro2</connection-url>
>                     <driver>mysql</driver>
>                     <security>
>                         <user-name>*******</user-name>
>                         <password>*******</password>
>                     </security>
>                 </datasource>
>                 <drivers>
>                     <driver name="mysql" module="com.mysql">
>                         <xa-datasource-class>com.mysql.jdbc.jdbc2.optional.MysqlXADataSource</xa-datasource-class>
>                     </driver>
>                 </drivers>
> I have reported this also to Infinispan, because I am not sure which party is to blame.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 03:53:02 2013
From: jira-events at lists.jboss.org (Jari Juslin (JIRA))
Date: Thu, 10 Oct 2013 03:53:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2267) Persisting a new entity bean
 with certain patterns fails to ARJUNA016082 on flush stage.
In-Reply-To: <JIRA.12502535.1381312028000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502535.1381312028000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502535.1381312028000.30296.1381391582922@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812955#comment-12812955 ] 

Jari Juslin commented on WFLY-2267:
-----------------------------------

Specifically, for this last sub-transaction, SynchronizationImple._isInterposed is false, while for the earlier records it's true; and by the comments in the code, it's not legal to add non-interposed record after interposed ones.
                
> Persisting a new entity bean with certain patterns fails to ARJUNA016082 on flush stage.
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-2267
>                 URL: https://issues.jboss.org/browse/WFLY-2267
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>    Affects Versions: 8.0.0.Alpha4, 8.0.0.Beta1
>         Environment: Ubuntu Linux 13.04, JDK 1.7.0u40 64-bit.
>            Reporter: Jari Juslin
>            Assignee: jaikiran pai
>         Attachments: infinispan_bug_repro.zip, infinispan_bug_repro2.zip
>
>
> Persisting a new entity inside a CMT and then exiting the transactional method throws ARJUNA016082 in certain cases.
> I have extracted two cases where the bug manifests.
> 1) Creating a new entity bean and then changing one field after the persist call.
> 2) Creating a new entity bean that has another entity linked to it, and the newly created entity is on the blind side of the relationship.
> Here is the RESTeasy service and the entity bean needed to replicate this (also packaged to the attached test case):
> package bugrepro2;
> import javax.ejb.LocalBean;
> import javax.ejb.Stateless;
> import javax.persistence.EntityManager;
> import javax.persistence.PersistenceContext;
> import javax.ws.rs.POST;
> import javax.ws.rs.Path;
> /**
>  * @author Jari Juslin, zds at ecolane.com
>  */
> @Stateless
> @LocalBean
> @Path("/bug_repro2")
> public class BugRepro2Rest {
>     @PersistenceContext(unitName = "persistence_context2")
>     protected EntityManager entityManager;
>     
>     @POST
>     public String manifestArjunaBug() {
>         BugReproEntity entry = new BugReproEntity();
>         entityManager.persist(entry);
>         
>         entry.setHasChanges(true);
>         
>         return "Success\n";
>     }
> }
> package bugrepro2;
> import javax.persistence.Column;
> import javax.persistence.Entity;
> import javax.persistence.GeneratedValue;
> import javax.persistence.GenerationType;
> import javax.persistence.Id;
> import javax.persistence.Table;
> import org.hibernate.annotations.Cache;
> import org.hibernate.annotations.CacheConcurrencyStrategy;
> @Entity()
> @Table(name = "bugrepro_entity")
> @Cache(usage=CacheConcurrencyStrategy.TRANSACTIONAL)
> public class BugReproEntity {
>     private Integer id;
>     private boolean hasChanges;
>     public BugReproEntity() {
>     }
>     @Id
>     @GeneratedValue(strategy=GenerationType.IDENTITY)
>     @Column(name="id")
>     public Integer getId() {
>         return id;
>     }
>     public void setId(Integer id) {
>         this.id = id;
>     }
>     @Column(name="has_changes")
>     public boolean getHasChanges() {
>         return hasChanges;
>     }
>     public void setHasChanges(boolean hasChanges) {
>         this.hasChanges = hasChanges;
>     }
> }
> The resulting exception:
> 2013-10-09 12:44:07,362 WARN  [org.infinispan.transaction.TransactionTable] (default task-31:) ISPN000101: Failed synchronization registration: java.lang.IllegalStateException: ARJUNA016082: Synchronizations are not allowed! Transaction status isActionStatus.RUNNING
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronizationImple(TransactionImple.java:379)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronization(TransactionImple.java:356)
> 	at org.infinispan.transaction.TransactionTable.enlist(TransactionTable.java:196)
> 	at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:269)
> 	at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:231)
> 	at org.infinispan.interceptors.TxInterceptor.visitPutKeyValueCommand(TxInterceptor.java:177)
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.updateStoreStatistics(CacheMgmtInterceptor.java:148)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:134)
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:106)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:70)
> 	at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32)
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:321)
> 	at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1298)
> 	at org.infinispan.CacheImpl.putInternal(CacheImpl.java:871)
> 	at org.infinispan.CacheImpl.put(CacheImpl.java:863)
> 	at org.infinispan.DecoratedCache.put(DecoratedCache.java:401)
> 	at org.infinispan.AbstractDelegatingCache.put(AbstractDelegatingCache.java:276)
> 	at org.hibernate.cache.infinispan.access.TransactionalAccessDelegate.update(TransactionalAccessDelegate.java:187) [hibernate-infinispan-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.cache.infinispan.entity.TransactionalAccess.update(TransactionalAccess.java:89) [hibernate-infinispan-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.action.internal.EntityUpdateAction.execute(EntityUpdateAction.java:208) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:377) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:369) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:287) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:340) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:52) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1235) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:405) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:113) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:53) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76)
> 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:273)
> 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:93)
> 	at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1170)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
> 	at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:93) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:437)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72)
> 	at bugrepro2.BugRepro2Rest$$$view31.manifestArjunaBug(Unknown Source) [classes:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_40]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_40]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_40]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_40]
> 	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:280) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:234) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:221) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:59) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:218) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:619) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> The datasource definition from standalone.xml:
>                 <datasource jndi-name="java:/BugRepro2DS" pool-name="BugRepro2DS" enabled="true">
>                     <connection-url>jdbc:mysql://localhost:3306/bugrepro2</connection-url>
>                     <driver>mysql</driver>
>                     <security>
>                         <user-name>*******</user-name>
>                         <password>*******</password>
>                     </security>
>                 </datasource>
>                 <drivers>
>                     <driver name="mysql" module="com.mysql">
>                         <xa-datasource-class>com.mysql.jdbc.jdbc2.optional.MysqlXADataSource</xa-datasource-class>
>                     </driver>
>                 </drivers>
> I have reported this also to Infinispan, because I am not sure which party is to blame.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 03:58:02 2013
From: jira-events at lists.jboss.org (Jari Juslin (JIRA))
Date: Thu, 10 Oct 2013 03:58:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2267) Persisting a new entity bean
 with certain patterns fails to ARJUNA016082 on flush stage.
In-Reply-To: <JIRA.12502535.1381312028000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502535.1381312028000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502535.1381312028000.30300.1381391882706@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812956#comment-12812956 ] 

Jari Juslin commented on WFLY-2267:
-----------------------------------

Also, changing the @Cache(usage=CacheConcurrencyStrategy.TRANSACTIONAL) to @Cacheable(true) does not change anything; the bug occurs just the same.
                
> Persisting a new entity bean with certain patterns fails to ARJUNA016082 on flush stage.
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-2267
>                 URL: https://issues.jboss.org/browse/WFLY-2267
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>    Affects Versions: 8.0.0.Alpha4, 8.0.0.Beta1
>         Environment: Ubuntu Linux 13.04, JDK 1.7.0u40 64-bit.
>            Reporter: Jari Juslin
>            Assignee: jaikiran pai
>         Attachments: infinispan_bug_repro.zip, infinispan_bug_repro2.zip
>
>
> Persisting a new entity inside a CMT and then exiting the transactional method throws ARJUNA016082 in certain cases.
> I have extracted two cases where the bug manifests.
> 1) Creating a new entity bean and then changing one field after the persist call.
> 2) Creating a new entity bean that has another entity linked to it, and the newly created entity is on the blind side of the relationship.
> Here is the RESTeasy service and the entity bean needed to replicate this (also packaged to the attached test case):
> package bugrepro2;
> import javax.ejb.LocalBean;
> import javax.ejb.Stateless;
> import javax.persistence.EntityManager;
> import javax.persistence.PersistenceContext;
> import javax.ws.rs.POST;
> import javax.ws.rs.Path;
> /**
>  * @author Jari Juslin, zds at ecolane.com
>  */
> @Stateless
> @LocalBean
> @Path("/bug_repro2")
> public class BugRepro2Rest {
>     @PersistenceContext(unitName = "persistence_context2")
>     protected EntityManager entityManager;
>     
>     @POST
>     public String manifestArjunaBug() {
>         BugReproEntity entry = new BugReproEntity();
>         entityManager.persist(entry);
>         
>         entry.setHasChanges(true);
>         
>         return "Success\n";
>     }
> }
> package bugrepro2;
> import javax.persistence.Column;
> import javax.persistence.Entity;
> import javax.persistence.GeneratedValue;
> import javax.persistence.GenerationType;
> import javax.persistence.Id;
> import javax.persistence.Table;
> import org.hibernate.annotations.Cache;
> import org.hibernate.annotations.CacheConcurrencyStrategy;
> @Entity()
> @Table(name = "bugrepro_entity")
> @Cache(usage=CacheConcurrencyStrategy.TRANSACTIONAL)
> public class BugReproEntity {
>     private Integer id;
>     private boolean hasChanges;
>     public BugReproEntity() {
>     }
>     @Id
>     @GeneratedValue(strategy=GenerationType.IDENTITY)
>     @Column(name="id")
>     public Integer getId() {
>         return id;
>     }
>     public void setId(Integer id) {
>         this.id = id;
>     }
>     @Column(name="has_changes")
>     public boolean getHasChanges() {
>         return hasChanges;
>     }
>     public void setHasChanges(boolean hasChanges) {
>         this.hasChanges = hasChanges;
>     }
> }
> The resulting exception:
> 2013-10-09 12:44:07,362 WARN  [org.infinispan.transaction.TransactionTable] (default task-31:) ISPN000101: Failed synchronization registration: java.lang.IllegalStateException: ARJUNA016082: Synchronizations are not allowed! Transaction status isActionStatus.RUNNING
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronizationImple(TransactionImple.java:379)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronization(TransactionImple.java:356)
> 	at org.infinispan.transaction.TransactionTable.enlist(TransactionTable.java:196)
> 	at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:269)
> 	at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:231)
> 	at org.infinispan.interceptors.TxInterceptor.visitPutKeyValueCommand(TxInterceptor.java:177)
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.updateStoreStatistics(CacheMgmtInterceptor.java:148)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:134)
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:106)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:70)
> 	at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32)
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:321)
> 	at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1298)
> 	at org.infinispan.CacheImpl.putInternal(CacheImpl.java:871)
> 	at org.infinispan.CacheImpl.put(CacheImpl.java:863)
> 	at org.infinispan.DecoratedCache.put(DecoratedCache.java:401)
> 	at org.infinispan.AbstractDelegatingCache.put(AbstractDelegatingCache.java:276)
> 	at org.hibernate.cache.infinispan.access.TransactionalAccessDelegate.update(TransactionalAccessDelegate.java:187) [hibernate-infinispan-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.cache.infinispan.entity.TransactionalAccess.update(TransactionalAccess.java:89) [hibernate-infinispan-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.action.internal.EntityUpdateAction.execute(EntityUpdateAction.java:208) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:377) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:369) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:287) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:340) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:52) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1235) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:405) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:113) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:53) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76)
> 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:273)
> 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:93)
> 	at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1170)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
> 	at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:93) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:437)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72)
> 	at bugrepro2.BugRepro2Rest$$$view31.manifestArjunaBug(Unknown Source) [classes:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_40]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_40]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_40]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_40]
> 	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:280) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:234) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:221) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:59) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:218) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:619) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> The datasource definition from standalone.xml:
>                 <datasource jndi-name="java:/BugRepro2DS" pool-name="BugRepro2DS" enabled="true">
>                     <connection-url>jdbc:mysql://localhost:3306/bugrepro2</connection-url>
>                     <driver>mysql</driver>
>                     <security>
>                         <user-name>*******</user-name>
>                         <password>*******</password>
>                     </security>
>                 </datasource>
>                 <drivers>
>                     <driver name="mysql" module="com.mysql">
>                         <xa-datasource-class>com.mysql.jdbc.jdbc2.optional.MysqlXADataSource</xa-datasource-class>
>                     </driver>
>                 </drivers>
> I have reported this also to Infinispan, because I am not sure which party is to blame.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 05:01:02 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Thu, 10 Oct 2013 05:01:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2273) Error message in the log on
 every click within the console in domain mode.
In-Reply-To: <JIRA.12502615.1381350328000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502615.1381350328000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502615.1381350328000.30465.1381395662964@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun updated WFLY-2273:
------------------------------

    Assignee: Brian Stansberry  (was: Heiko Braun)

    
> Error message in the log on every click within the console in domain mode.
> --------------------------------------------------------------------------
>
>                 Key: WFLY-2273
>                 URL: https://issues.jboss.org/browse/WFLY-2273
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web Console
>    Affects Versions: 8.0.0.Beta1
>         Environment: Rhel 2.6.18-348.18.1.e15 x86-64, two cpus
>            Reporter: sean galway
>            Assignee: Brian Stansberry
>
> While running Wildfly in domain mode (i.e domain.sh) every click within the admin console produces and error message in the server log. 
> [Host Controller] 13:53:38,148 ERROR [org.jboss.as.controller.client] (XNIO-1 task-12) JBAS014781: Step handler org.jboss.as.domain.controller.operations.coordination.DomainFinalResultHandler at 576bca9e for operation composite at address [] failed handling operation rollback -- null

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 05:01:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Thu, 10 Oct 2013 05:01:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2273) Error message in the log on
 every click within the console in domain mode.
In-Reply-To: <JIRA.12502615.1381350328000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502615.1381350328000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502615.1381350328000.30469.1381395663158@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun updated WFLY-2273:
------------------------------

    Component/s: Domain Management

    
> Error message in the log on every click within the console in domain mode.
> --------------------------------------------------------------------------
>
>                 Key: WFLY-2273
>                 URL: https://issues.jboss.org/browse/WFLY-2273
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, Web Console
>    Affects Versions: 8.0.0.Beta1
>         Environment: Rhel 2.6.18-348.18.1.e15 x86-64, two cpus
>            Reporter: sean galway
>            Assignee: Brian Stansberry
>
> While running Wildfly in domain mode (i.e domain.sh) every click within the admin console produces and error message in the server log. 
> [Host Controller] 13:53:38,148 ERROR [org.jboss.as.controller.client] (XNIO-1 task-12) JBAS014781: Step handler org.jboss.as.domain.controller.operations.coordination.DomainFinalResultHandler at 576bca9e for operation composite at address [] failed handling operation rollback -- null

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 05:01:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Thu, 10 Oct 2013 05:01:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2273) Error message in the log on
 every click within the console in domain mode.
In-Reply-To: <JIRA.12502615.1381350328000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502615.1381350328000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502615.1381350328000.30472.1381395663310@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun updated WFLY-2273:
------------------------------

    Fix Version/s: 8.0.0.CR1

    
> Error message in the log on every click within the console in domain mode.
> --------------------------------------------------------------------------
>
>                 Key: WFLY-2273
>                 URL: https://issues.jboss.org/browse/WFLY-2273
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, Web Console
>    Affects Versions: 8.0.0.Beta1
>         Environment: Rhel 2.6.18-348.18.1.e15 x86-64, two cpus
>            Reporter: sean galway
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> While running Wildfly in domain mode (i.e domain.sh) every click within the admin console produces and error message in the server log. 
> [Host Controller] 13:53:38,148 ERROR [org.jboss.as.controller.client] (XNIO-1 task-12) JBAS014781: Step handler org.jboss.as.domain.controller.operations.coordination.DomainFinalResultHandler at 576bca9e for operation composite at address [] failed handling operation rollback -- null

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 05:05:02 2013
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Thu, 10 Oct 2013 05:05:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2275) StackOverflowError on
 DataSource resource injection
In-Reply-To: <JIRA.12502663.1381395783236@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502663.1381395783236@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502663.1381395783236.30479.1381395902646@jira02.app.mwc.hst.phx2.redhat.com>

Thomas Diesler created WFLY-2275:
------------------------------------

             Summary: StackOverflowError on DataSource resource injection
                 Key: WFLY-2275
                 URL: https://issues.jboss.org/browse/WFLY-2275
             Project: WildFly
          Issue Type: Bug
          Components: Naming
    Affects Versions: 8.0.0.Beta1
            Reporter: Thomas Diesler
            Assignee: Eduardo Martins


{code}
    @Resource(name="java:comp/DefaultDataSource")
    public DataSource ds;
{code}

leads to 

{code}
10:59:21,901 INFO  [org.jboss.osgi.framework] (MSC service thread 1-3) JBOSGI011001: Bundle installed: resource-injection.jar:0.0.0
10:59:21,937 INFO  [org.jboss.as.arquillian] (MSC service thread 1-3) Arquillian deployment detected: ArquillianConfig[service=jboss.arquillian.config."resource-injection.jar",unit=resource-injection.jar,tests=[org.jboss.test.osgi.example.resource.ResourceInjectionTestCase]]
10:59:21,993 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."resource-injection.jar".Activate: org.jboss.msc.service.StartException in service jboss.deployment.unit."resource-injection.jar".Activate: Failed to start service
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1900) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
Caused by: java.lang.StackOverflowError
	at java.util.Vector.<init>(Vector.java:127) [rt.jar:1.7.0_25]
	at java.util.Vector.<init>(Vector.java:144) [rt.jar:1.7.0_25]
	at java.util.Vector.<init>(Vector.java:153) [rt.jar:1.7.0_25]
	at javax.naming.NameImpl.<init>(NameImpl.java:273) [rt.jar:1.7.0_25]
	at javax.naming.NameImpl.<init>(NameImpl.java:277) [rt.jar:1.7.0_25]
	at javax.naming.CompositeName.<init>(CompositeName.java:231) [rt.jar:1.7.0_25]
	at org.jboss.as.naming.util.NameParser.parse(NameParser.java:49)
	at org.jboss.as.naming.NamingContext.parseName(NamingContext.java:496)
	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188)
	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184)
	at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:302)
	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:140)
	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:81)
	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:202)
	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188)
	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184)
	at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:302)
	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:140)
	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:81)
	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:202)
	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188)
	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184)
	at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:302)
	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:140)
	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:81)
{code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 05:11:03 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 10 Oct 2013 05:11:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2260) Vault tests pollute tmp dir
In-Reply-To: <JIRA.12502480.1381248164000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502480.1381248164000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502480.1381248164000.30493.1381396263434@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-2260:
------------------------------

    Issue Type: Bug  (was: Feature Request)

    
> Vault tests pollute tmp dir
> ---------------------------
>
>                 Key: WFLY-2260
>                 URL: https://issues.jboss.org/browse/WFLY-2260
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Kabir Khan
>            Assignee: Peter Skopek
>             Fix For: 8.0.0.CR1
>
>
> SlaveHostControllerAuthenticationTestCase often fails. On inspection this seems to be that the wrong version of the vault file is being used from the tmp directory.
> One way to see this is to clear out the tmp directory, and to run 
> $mvn clean install -pl testsuite/domain/  -DallTests -Dtest=org.jboss.as.test.integration.domain.SlaveHostControllerAuthenticationTestCase
> a few times, most likely from the second time it will fail. This happens during setup of the test, so you can reproduce more easily by adding a simple class
> {code}
> public class __Throwaway {
>    public static void main(String[] args) throws Exception{
>        SlaveHostControllerAuthenticationTestCase test = new SlaveHostControllerAuthenticationTestCase();
>        test.setupVault();
>        test.slaveWithVaultPasswordTest();
>    }
> }
> {code}
> and adjusting the visiblity of the SlaveHostControllerAuthenticationTestCase
> methods. There are also other tests using the vault which also seem to pollute the tmp dir.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 05:11:03 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 10 Oct 2013 05:11:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2260) Vault tests pollute tmp dir
In-Reply-To: <JIRA.12502480.1381248164000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502480.1381248164000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502480.1381248164000.30498.1381396263970@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-2260:
------------------------------

    Affects Version/s: 8.0.0.Beta1

    
> Vault tests pollute tmp dir
> ---------------------------
>
>                 Key: WFLY-2260
>                 URL: https://issues.jboss.org/browse/WFLY-2260
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Kabir Khan
>            Assignee: Peter Skopek
>             Fix For: 8.0.0.CR1
>
>
> SlaveHostControllerAuthenticationTestCase often fails. On inspection this seems to be that the wrong version of the vault file is being used from the tmp directory.
> One way to see this is to clear out the tmp directory, and to run 
> $mvn clean install -pl testsuite/domain/  -DallTests -Dtest=org.jboss.as.test.integration.domain.SlaveHostControllerAuthenticationTestCase
> a few times, most likely from the second time it will fail. This happens during setup of the test, so you can reproduce more easily by adding a simple class
> {code}
> public class __Throwaway {
>    public static void main(String[] args) throws Exception{
>        SlaveHostControllerAuthenticationTestCase test = new SlaveHostControllerAuthenticationTestCase();
>        test.setupVault();
>        test.slaveWithVaultPasswordTest();
>    }
> }
> {code}
> and adjusting the visiblity of the SlaveHostControllerAuthenticationTestCase
> methods. There are also other tests using the vault which also seem to pollute the tmp dir.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 05:11:04 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 10 Oct 2013 05:11:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2260) Vault tests pollute tmp dir
In-Reply-To: <JIRA.12502480.1381248164000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502480.1381248164000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502480.1381248164000.30508.1381396264618@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-2260:
------------------------------

    Priority: Blocker  (was: Major)

    
> Vault tests pollute tmp dir
> ---------------------------
>
>                 Key: WFLY-2260
>                 URL: https://issues.jboss.org/browse/WFLY-2260
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security, Test Suite
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Kabir Khan
>            Assignee: Peter Skopek
>            Priority: Blocker
>             Fix For: 8.0.0.CR1
>
>
> SlaveHostControllerAuthenticationTestCase often fails. On inspection this seems to be that the wrong version of the vault file is being used from the tmp directory.
> One way to see this is to clear out the tmp directory, and to run 
> $mvn clean install -pl testsuite/domain/  -DallTests -Dtest=org.jboss.as.test.integration.domain.SlaveHostControllerAuthenticationTestCase
> a few times, most likely from the second time it will fail. This happens during setup of the test, so you can reproduce more easily by adding a simple class
> {code}
> public class __Throwaway {
>    public static void main(String[] args) throws Exception{
>        SlaveHostControllerAuthenticationTestCase test = new SlaveHostControllerAuthenticationTestCase();
>        test.setupVault();
>        test.slaveWithVaultPasswordTest();
>    }
> }
> {code}
> and adjusting the visiblity of the SlaveHostControllerAuthenticationTestCase
> methods. There are also other tests using the vault which also seem to pollute the tmp dir.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 05:11:04 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 10 Oct 2013 05:11:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2260) Vault tests pollute tmp dir
In-Reply-To: <JIRA.12502480.1381248164000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502480.1381248164000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502480.1381248164000.30503.1381396264281@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-2260:
------------------------------

    Component/s: Test Suite

    
> Vault tests pollute tmp dir
> ---------------------------
>
>                 Key: WFLY-2260
>                 URL: https://issues.jboss.org/browse/WFLY-2260
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security, Test Suite
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Kabir Khan
>            Assignee: Peter Skopek
>             Fix For: 8.0.0.CR1
>
>
> SlaveHostControllerAuthenticationTestCase often fails. On inspection this seems to be that the wrong version of the vault file is being used from the tmp directory.
> One way to see this is to clear out the tmp directory, and to run 
> $mvn clean install -pl testsuite/domain/  -DallTests -Dtest=org.jboss.as.test.integration.domain.SlaveHostControllerAuthenticationTestCase
> a few times, most likely from the second time it will fail. This happens during setup of the test, so you can reproduce more easily by adding a simple class
> {code}
> public class __Throwaway {
>    public static void main(String[] args) throws Exception{
>        SlaveHostControllerAuthenticationTestCase test = new SlaveHostControllerAuthenticationTestCase();
>        test.setupVault();
>        test.slaveWithVaultPasswordTest();
>    }
> }
> {code}
> and adjusting the visiblity of the SlaveHostControllerAuthenticationTestCase
> methods. There are also other tests using the vault which also seem to pollute the tmp dir.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 05:18:02 2013
From: jira-events at lists.jboss.org (Radoslav Husar (JIRA))
Date: Thu, 10 Oct 2013 05:18:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2241) Naming subsystem transformers
	for 7.2.0
In-Reply-To: <JIRA.12502327.1381146366000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502327.1381146366000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502327.1381146366000.30527.1381396682597@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-2241:
---------------------------------

    Fix Version/s: 8.0.0.CR1

    
> Naming subsystem transformers for 7.2.0
> ---------------------------------------
>
>                 Key: WFLY-2241
>                 URL: https://issues.jboss.org/browse/WFLY-2241
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Naming
>            Reporter: Kabir Khan
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 05:22:02 2013
From: jira-events at lists.jboss.org (Radoslav Husar (JIRA))
Date: Thu, 10 Oct 2013 05:22:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2218) Subsystem transformers
	against 7.2.0
In-Reply-To: <JIRA.12502213.1380892269000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502213.1380892269000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502213.1380892269000.30533.1381396922783@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12812993#comment-12812993 ] 

Radoslav Husar commented on WFLY-2218:
--------------------------------------

BTW in the deleteMeWhenDone() test, I had to explicitly setExtensionClassName() otherwise I was getting CCE.
                
> Subsystem transformers against 7.2.0
> ------------------------------------
>
>                 Key: WFLY-2218
>                 URL: https://issues.jboss.org/browse/WFLY-2218
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>    Affects Versions: 8.0.0.CR1
>            Reporter: Kabir Khan
>            Assignee: Brian Stansberry
>
> We have not tested the majority of subsystem transformers against AS 7.2.0. I have attempted to document why we need subsystem transformation here, and also how to use the framework: 
> https://docs.jboss.org/author/display/WFLY8/Domain+Mode+Subsystem+Transformers
> This document is WIP, and I will be updating it a bit more over the next few days.
> https://gist.github.com/kabir/6825607 contains the difference of a running WildFly instance against AS 7.2.0 in domain mode (for subsystems you don't really need to bother about this one)
> https://gist.github.com/kabir/6825559 contains the difference of a running WildFly instance against AS 7.2.0 in standalone mode, here you can see what has changed in the subsystems.
> When creating a new subsystem transformers test against 7.2.0, you will need the resource definition for the ModelVersion your subsystem uses in 7.2.0. If this is not found, you need to add a test to your subsystem, which you can delete once you have the .dmr file containing the resource defintion. Here is what I did to generate the file for JMX
> {code}
>     @Test
>     public void deleteMeWhenDone() throws Exception {
>         ModelTestControllerVersion controllerVersion = ModelTestControllerVersion.V7_2_0_FINAL;
>         ModelVersion modelVersion = ModelVersion.create(1, 1, 0); //Whatever version of your subsystem 7.2.0.Final has
>         KernelServicesBuilder builder = createKernelServicesBuilder(null);
>         builder.createLegacyKernelServicesBuilder(null, controllerVersion, modelVersion)
>             .addMavenResourceURL("org.jboss.as:jboss-as-jmx:" + controllerVersion.getMavenGavVersion());
>         KernelServices services = builder.build();
>         generateLegacySubsystemResourceRegistrationDmr(services, modelVersion);
>     }
> {code}
> Now run the test and delete it. The legacy .dmr file should be in {{target/test-classes/org/jboss/as/subsystem/test/<your-subsystem-name>-<your-version>.dmr}}. Copy this .dmr file to {{subsystem-test/framework/src/main/resources/org/jboss/as/subsystem/test}}.
> You will likely also need to update org.jboss.as.subsystem.test.KnownVersions to include your latest subsystem version, once you start doing real testing.
> Bear in mind that if you need to add some transformation to 7.2.0 due to some new feature in WildFly 8, you will probably also need to add the same transformation to 7.1.x as well!
> Although some subsystems already have added transformers, we still need to add tests.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 05:29:02 2013
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Thu, 10 Oct 2013 05:29:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1995) Allow property substitution
 in EJB Annotations with configurable option
In-Reply-To: <JIRA.12499889.1378281896000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499889.1378281896000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499889.1378281896000.30546.1381397342911@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carlo de Wolf reassigned WFLY-1995:
-----------------------------------

    Assignee: Carlo de Wolf  (was: jaikiran pai)

    
> Allow property substitution in EJB Annotations with configurable option
> -----------------------------------------------------------------------
>
>                 Key: WFLY-1995
>                 URL: https://issues.jboss.org/browse/WFLY-1995
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EJB
>            Reporter: Carlo de Wolf
>            Assignee: Carlo de Wolf
>
> Create a configuration option which enables property substitution in EJB annotations.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 05:29:03 2013
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Thu, 10 Oct 2013 05:29:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1995) Allow property substitution
 in EJB Annotations with configurable option
In-Reply-To: <JIRA.12499889.1378281896000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499889.1378281896000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499889.1378281896000.30549.1381397343114@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carlo de Wolf reassigned WFLY-1995:
-----------------------------------

    Assignee: JBoss SET  (was: Carlo de Wolf)

    
> Allow property substitution in EJB Annotations with configurable option
> -----------------------------------------------------------------------
>
>                 Key: WFLY-1995
>                 URL: https://issues.jboss.org/browse/WFLY-1995
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EJB
>            Reporter: Carlo de Wolf
>            Assignee: JBoss SET
>
> Create a configuration option which enables property substitution in EJB annotations.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 05:47:02 2013
From: jira-events at lists.jboss.org (Juergen Zimmermann (JIRA))
Date: Thu, 10 Oct 2013 05:47:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2249) NPE during redeployment of a
	war
In-Reply-To: <JIRA.12502347.1381151954000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502347.1381151954000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502347.1381151954000.30639.1381398422688@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813009#comment-12813009 ] 

Juergen Zimmermann commented on WFLY-2249:
------------------------------------------

The NPE occurred with the Beta 1 snapshot I built last week. With the new Beta1 snapshot the NPE didn't occur at all.
                
> NPE during redeployment of a war
> --------------------------------
>
>                 Key: WFLY-2249
>                 URL: https://issues.jboss.org/browse/WFLY-2249
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Juergen Zimmermann
>            Assignee: Scott Marlow
>
> When I redeploy an already running war, then I get the following NPE. The (re-) deployment is done via the Maven plugin org.jboss.as.plugins:jboss-as-maven-plugin:7.4.Final. It looks like the redployment was successful anyway. Hmm...
> {code}
> ERROR [org.jboss.msc.service.fail] MSC000001: Failed to start service jboss.deployment.unit."shop.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."shop.war".PARSE: JBAS018733: Failed to process phase PARSE of deployment "shop.war"
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> Caused by: java.lang.NullPointerException
> 	at org.jboss.as.jpa.processor.PersistenceUnitParseProcessor.handleWarDeployment(PersistenceUnitParseProcessor.java:126)
> 	at org.jboss.as.jpa.processor.PersistenceUnitParseProcessor.deploy(PersistenceUnitParseProcessor.java:83)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	... 5 more
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 05:51:02 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Thu, 10 Oct 2013 05:51:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2218) Subsystem transformers
	against 7.2.0
In-Reply-To: <JIRA.12502213.1380892269000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502213.1380892269000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502213.1380892269000.30656.1381398662757@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813014#comment-12813014 ] 

Kabir Khan commented on WFLY-2218:
----------------------------------

I had assumed the method would be added in an existing subsystem test. If in a new class, I guess you would have to call setExtensionClassName()
                
> Subsystem transformers against 7.2.0
> ------------------------------------
>
>                 Key: WFLY-2218
>                 URL: https://issues.jboss.org/browse/WFLY-2218
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>    Affects Versions: 8.0.0.CR1
>            Reporter: Kabir Khan
>            Assignee: Brian Stansberry
>
> We have not tested the majority of subsystem transformers against AS 7.2.0. I have attempted to document why we need subsystem transformation here, and also how to use the framework: 
> https://docs.jboss.org/author/display/WFLY8/Domain+Mode+Subsystem+Transformers
> This document is WIP, and I will be updating it a bit more over the next few days.
> https://gist.github.com/kabir/6825607 contains the difference of a running WildFly instance against AS 7.2.0 in domain mode (for subsystems you don't really need to bother about this one)
> https://gist.github.com/kabir/6825559 contains the difference of a running WildFly instance against AS 7.2.0 in standalone mode, here you can see what has changed in the subsystems.
> When creating a new subsystem transformers test against 7.2.0, you will need the resource definition for the ModelVersion your subsystem uses in 7.2.0. If this is not found, you need to add a test to your subsystem, which you can delete once you have the .dmr file containing the resource defintion. Here is what I did to generate the file for JMX
> {code}
>     @Test
>     public void deleteMeWhenDone() throws Exception {
>         ModelTestControllerVersion controllerVersion = ModelTestControllerVersion.V7_2_0_FINAL;
>         ModelVersion modelVersion = ModelVersion.create(1, 1, 0); //Whatever version of your subsystem 7.2.0.Final has
>         KernelServicesBuilder builder = createKernelServicesBuilder(null);
>         builder.createLegacyKernelServicesBuilder(null, controllerVersion, modelVersion)
>             .addMavenResourceURL("org.jboss.as:jboss-as-jmx:" + controllerVersion.getMavenGavVersion());
>         KernelServices services = builder.build();
>         generateLegacySubsystemResourceRegistrationDmr(services, modelVersion);
>     }
> {code}
> Now run the test and delete it. The legacy .dmr file should be in {{target/test-classes/org/jboss/as/subsystem/test/<your-subsystem-name>-<your-version>.dmr}}. Copy this .dmr file to {{subsystem-test/framework/src/main/resources/org/jboss/as/subsystem/test}}.
> You will likely also need to update org.jboss.as.subsystem.test.KnownVersions to include your latest subsystem version, once you start doing real testing.
> Bear in mind that if you need to add some transformation to 7.2.0 due to some new feature in WildFly 8, you will probably also need to add the same transformation to 7.1.x as well!
> Although some subsystems already have added transformers, we still need to add tests.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 07:28:02 2013
From: jira-events at lists.jboss.org (alexandre xypas (JIRA))
Date: Thu, 10 Oct 2013 07:28:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2276) URI ENCODING does not work in
 the beta1 version (UTF-8)
In-Reply-To: <JIRA.12502684.1381404449348@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502684.1381404449348@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502684.1381404449348.30950.1381404482904@jira02.app.mwc.hst.phx2.redhat.com>

alexandre xypas created WFLY-2276:
-------------------------------------

             Summary: URI ENCODING does not work in the beta1 version (UTF-8)
                 Key: WFLY-2276
                 URL: https://issues.jboss.org/browse/WFLY-2276
             Project: WildFly
          Issue Type: Bug
    Affects Versions: 8.0.0.Beta1
            Reporter: alexandre xypas




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 07:32:02 2013
From: jira-events at lists.jboss.org (alexandre xypas (JIRA))
Date: Thu, 10 Oct 2013 07:32:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2276) URI ENCODING does not work in
 the beta1 version (UTF-8)
In-Reply-To: <JIRA.12502684.1381404449000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502684.1381404449000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502684.1381404449000.30963.1381404722589@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

alexandre xypas updated WFLY-2276:
----------------------------------

         Labels: encoding utf-8  (was: )
    Environment: Java 7, ubuntu 12.04
    Description: 
In standalone.xml, the following is working in Alpha4, but not anymore in Beta1.

<property name="org.apache.catalina.connector.URI_ENCODING" value="UTF-8"/>
<property name="org.apache.catalina.connector.USE_BODY_ENCODING_FOR_QUERY_STRING" value="true"/>
    Component/s: Web (JBoss Web)

    
> URI ENCODING does not work in the beta1 version (UTF-8)
> -------------------------------------------------------
>
>                 Key: WFLY-2276
>                 URL: https://issues.jboss.org/browse/WFLY-2276
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (JBoss Web)
>    Affects Versions: 8.0.0.Beta1
>         Environment: Java 7, ubuntu 12.04
>            Reporter: alexandre xypas
>              Labels: encoding, utf-8
>
> In standalone.xml, the following is working in Alpha4, but not anymore in Beta1.
> <property name="org.apache.catalina.connector.URI_ENCODING" value="UTF-8"/>
> <property name="org.apache.catalina.connector.USE_BODY_ENCODING_FOR_QUERY_STRING" value="true"/>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 07:43:02 2013
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Thu, 10 Oct 2013 07:43:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2275) StackOverflowError on
 DataSource resource injection
In-Reply-To: <JIRA.12502663.1381395783000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502663.1381395783000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502663.1381395783000.30993.1381405382960@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813067#comment-12813067 ] 

Thomas Diesler commented on WFLY-2275:
--------------------------------------

When using 

{code}
    @Resource(lookup = "java:jboss/datasources/ExampleDS")
{code}

it works - thanks.

Please note however that this is regression when moving to 8.0.0.Beta1. It has always worked with 'name' instead of 'lookup'.

This issue is also about a stack overflow, which should not happen under any circumstances IMHO
                
> StackOverflowError on DataSource resource injection
> ---------------------------------------------------
>
>                 Key: WFLY-2275
>                 URL: https://issues.jboss.org/browse/WFLY-2275
>             Project: WildFly
>          Issue Type: Bug
>          Components: Naming
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Thomas Diesler
>            Assignee: Eduardo Martins
>
> {code}
>     @Resource(name="java:comp/DefaultDataSource")
>     public DataSource ds;
> {code}
> leads to 
> {code}
> 10:59:21,901 INFO  [org.jboss.osgi.framework] (MSC service thread 1-3) JBOSGI011001: Bundle installed: resource-injection.jar:0.0.0
> 10:59:21,937 INFO  [org.jboss.as.arquillian] (MSC service thread 1-3) Arquillian deployment detected: ArquillianConfig[service=jboss.arquillian.config."resource-injection.jar",unit=resource-injection.jar,tests=[org.jboss.test.osgi.example.resource.ResourceInjectionTestCase]]
> 10:59:21,993 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."resource-injection.jar".Activate: org.jboss.msc.service.StartException in service jboss.deployment.unit."resource-injection.jar".Activate: Failed to start service
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1900) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: java.lang.StackOverflowError
> 	at java.util.Vector.<init>(Vector.java:127) [rt.jar:1.7.0_25]
> 	at java.util.Vector.<init>(Vector.java:144) [rt.jar:1.7.0_25]
> 	at java.util.Vector.<init>(Vector.java:153) [rt.jar:1.7.0_25]
> 	at javax.naming.NameImpl.<init>(NameImpl.java:273) [rt.jar:1.7.0_25]
> 	at javax.naming.NameImpl.<init>(NameImpl.java:277) [rt.jar:1.7.0_25]
> 	at javax.naming.CompositeName.<init>(CompositeName.java:231) [rt.jar:1.7.0_25]
> 	at org.jboss.as.naming.util.NameParser.parse(NameParser.java:49)
> 	at org.jboss.as.naming.NamingContext.parseName(NamingContext.java:496)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184)
> 	at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:302)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:140)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:81)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:202)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184)
> 	at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:302)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:140)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:81)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:202)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184)
> 	at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:302)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:140)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:81)
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 07:45:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 10 Oct 2013 07:45:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-369) Domain mode: kill an
	unresponsive JVM
In-Reply-To: <JIRA.12480351.1354566315000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12480351.1354566315000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12480351.1354566315000.31002.1381405503303@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813071#comment-12813071 ] 

RH Bugzilla Integration commented on WFLY-369:
----------------------------------------------

Emanuel Muckenhuber <emuckenh at redhat.com> changed the Status of [bug 901232|https://bugzilla.redhat.com/show_bug.cgi?id=901232] from ASSIGNED to POST
                
> Domain mode: kill an unresponsive JVM
> -------------------------------------
>
>                 Key: WFLY-369
>                 URL: https://issues.jboss.org/browse/WFLY-369
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Dennis Reed
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.Alpha1
>
>
> If an AS instance gets into a state where it cannot be controlled normally by the host controller, local OS commands must be used to kill it.
> It would be helpful to be able to kill an unresponsive JVM through the management interface.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 07:50:02 2013
From: jira-events at lists.jboss.org (Eduardo Martins (JIRA))
Date: Thu, 10 Oct 2013 07:50:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2275) StackOverflowError on
 DataSource resource injection
In-Reply-To: <JIRA.12502663.1381395783000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502663.1381395783000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502663.1381395783000.31008.1381405802574@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813076#comment-12813076 ] 

Eduardo Martins commented on WFLY-2275:
---------------------------------------

We did not have java:comp/DefaultDataSource bound before, but note that even if it's incorrect that still works, there is no regression, I tried it.

Please attach the server xml configuration, I suspect the stack overflow originates from there. I need to replicate the error to fix the name parser so it doesn't happen again.
                
> StackOverflowError on DataSource resource injection
> ---------------------------------------------------
>
>                 Key: WFLY-2275
>                 URL: https://issues.jboss.org/browse/WFLY-2275
>             Project: WildFly
>          Issue Type: Bug
>          Components: Naming
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Thomas Diesler
>            Assignee: Eduardo Martins
>
> {code}
>     @Resource(name="java:comp/DefaultDataSource")
>     public DataSource ds;
> {code}
> leads to 
> {code}
> 10:59:21,901 INFO  [org.jboss.osgi.framework] (MSC service thread 1-3) JBOSGI011001: Bundle installed: resource-injection.jar:0.0.0
> 10:59:21,937 INFO  [org.jboss.as.arquillian] (MSC service thread 1-3) Arquillian deployment detected: ArquillianConfig[service=jboss.arquillian.config."resource-injection.jar",unit=resource-injection.jar,tests=[org.jboss.test.osgi.example.resource.ResourceInjectionTestCase]]
> 10:59:21,993 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."resource-injection.jar".Activate: org.jboss.msc.service.StartException in service jboss.deployment.unit."resource-injection.jar".Activate: Failed to start service
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1900) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: java.lang.StackOverflowError
> 	at java.util.Vector.<init>(Vector.java:127) [rt.jar:1.7.0_25]
> 	at java.util.Vector.<init>(Vector.java:144) [rt.jar:1.7.0_25]
> 	at java.util.Vector.<init>(Vector.java:153) [rt.jar:1.7.0_25]
> 	at javax.naming.NameImpl.<init>(NameImpl.java:273) [rt.jar:1.7.0_25]
> 	at javax.naming.NameImpl.<init>(NameImpl.java:277) [rt.jar:1.7.0_25]
> 	at javax.naming.CompositeName.<init>(CompositeName.java:231) [rt.jar:1.7.0_25]
> 	at org.jboss.as.naming.util.NameParser.parse(NameParser.java:49)
> 	at org.jboss.as.naming.NamingContext.parseName(NamingContext.java:496)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184)
> 	at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:302)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:140)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:81)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:202)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184)
> 	at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:302)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:140)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:81)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:202)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184)
> 	at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:302)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:140)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:81)
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 08:37:02 2013
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Thu, 10 Oct 2013 08:37:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2275) StackOverflowError on
 DataSource resource injection
In-Reply-To: <JIRA.12502663.1381395783000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502663.1381395783000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502663.1381395783000.31060.1381408622616@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Diesler updated WFLY-2275:
---------------------------------

    Attachment: standalone-osgi.xml


To reproduce this you can run

{code}
mvn -Dtarget.container=wildlfy800 clean install -Dtest=ResourceInjectionTestCase
{code}

with https://github.com/tdiesler/jbosgi
                
> StackOverflowError on DataSource resource injection
> ---------------------------------------------------
>
>                 Key: WFLY-2275
>                 URL: https://issues.jboss.org/browse/WFLY-2275
>             Project: WildFly
>          Issue Type: Bug
>          Components: Naming
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Thomas Diesler
>            Assignee: Eduardo Martins
>         Attachments: standalone-osgi.xml
>
>
> {code}
>     @Resource(name="java:comp/DefaultDataSource")
>     public DataSource ds;
> {code}
> leads to 
> {code}
> 10:59:21,901 INFO  [org.jboss.osgi.framework] (MSC service thread 1-3) JBOSGI011001: Bundle installed: resource-injection.jar:0.0.0
> 10:59:21,937 INFO  [org.jboss.as.arquillian] (MSC service thread 1-3) Arquillian deployment detected: ArquillianConfig[service=jboss.arquillian.config."resource-injection.jar",unit=resource-injection.jar,tests=[org.jboss.test.osgi.example.resource.ResourceInjectionTestCase]]
> 10:59:21,993 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."resource-injection.jar".Activate: org.jboss.msc.service.StartException in service jboss.deployment.unit."resource-injection.jar".Activate: Failed to start service
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1900) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: java.lang.StackOverflowError
> 	at java.util.Vector.<init>(Vector.java:127) [rt.jar:1.7.0_25]
> 	at java.util.Vector.<init>(Vector.java:144) [rt.jar:1.7.0_25]
> 	at java.util.Vector.<init>(Vector.java:153) [rt.jar:1.7.0_25]
> 	at javax.naming.NameImpl.<init>(NameImpl.java:273) [rt.jar:1.7.0_25]
> 	at javax.naming.NameImpl.<init>(NameImpl.java:277) [rt.jar:1.7.0_25]
> 	at javax.naming.CompositeName.<init>(CompositeName.java:231) [rt.jar:1.7.0_25]
> 	at org.jboss.as.naming.util.NameParser.parse(NameParser.java:49)
> 	at org.jboss.as.naming.NamingContext.parseName(NamingContext.java:496)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184)
> 	at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:302)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:140)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:81)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:202)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184)
> 	at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:302)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:140)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:81)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:202)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184)
> 	at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:302)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:140)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:81)
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 08:39:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 10 Oct 2013 08:39:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1740) ManagedSocketBinding class
 Impossible cast from java.net.InetAddress to java.net.InetSocketAddress
In-Reply-To: <JIRA.12497092.1374526330000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497092.1374526330000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497092.1374526330000.31072.1381408743299@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-1740:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1017747

    
> ManagedSocketBinding class Impossible cast from java.net.InetAddress to java.net.InetSocketAddress
> --------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1740
>                 URL: https://issues.jboss.org/browse/WFLY-1740
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Cheng Fang
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.CR1
>
>
> Reported by FindBugs:
> Impossible cast from java.net.InetAddress to java.net.InetSocketAddress
> Class:
> ManagedSocketBinding (org.jboss.as.network) line 55
> Method:
> getBindAddress (org.jboss.as.network.ManagedSocketBinding.getBindAddress())
> Priority:
> ? ? ?High Confidence Correctness
> ?
> Problem classification:
> Correctness (Bad casts of object references)
> BC_IMPOSSIBLE_CAST (Impossible cast)
> Notes:
> Actual type java.net.InetAddress
> Expected java.net.InetSocketAddress
> Return value of Class.cast(Object)
> FindBadCast2 (BC|NP)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Thu Oct 10 08:39:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 10 Oct 2013 08:39:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1740) ManagedSocketBinding class
 Impossible cast from java.net.InetAddress to java.net.InetSocketAddress
In-Reply-To: <JIRA.12497092.1374526330000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497092.1374526330000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497092.1374526330000.31075.1381408743489@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813083#comment-12813083 ] 

RH Bugzilla Integration commented on WFLY-1740:
-----------------------------------------------

Emanuel Muckenhuber <emuckenh at redhat.com> made a comment on [bug 1017747|https://bugzilla.redhat.com/show_bug.cgi?id=1017747]

Port fix for https://issues.jboss.org/browse/WFLY-1740 to EAP.

ManagedSocketBinding class Impossible cast from java.net.InetAddress to java.net.InetSocketAddress
                
> ManagedSocketBinding class Impossible cast from java.net.InetAddress to java.net.InetSocketAddress
> --------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1740
>                 URL: https://issues.jboss.org/browse/WFLY-1740
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Cheng Fang
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.CR1
>
>
> Reported by FindBugs:
> Impossible cast from java.net.InetAddress to java.net.InetSocketAddress
> Class:
> ManagedSocketBinding (org.jboss.as.network) line 55
> Method:
> getBindAddress (org.jboss.as.network.ManagedSocketBinding.getBindAddress())
> Priority:
> ? ? ?High Confidence Correctness
> ?
> Problem classification:
> Correctness (Bad casts of object references)
> BC_IMPOSSIBLE_CAST (Impossible cast)
> Notes:
> Actual type java.net.InetAddress
> Expected java.net.InetSocketAddress
> Return value of Class.cast(Object)
> FindBadCast2 (BC|NP)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Thu Oct 10 08:59:02 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Thu, 10 Oct 2013 08:59:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2277) application client jars in
 ear should be able to have persistence units deployed
In-Reply-To: <JIRA.12502689.1381409863427@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502689.1381409863427@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502689.1381409863427.31159.1381409942735@jira02.app.mwc.hst.phx2.redhat.com>

Scott Marlow created WFLY-2277:
----------------------------------

             Summary: application client jars in ear should be able to have persistence units deployed
                 Key: WFLY-2277
                 URL: https://issues.jboss.org/browse/WFLY-2277
             Project: WildFly
          Issue Type: Feature Request
          Components: JPA / Hibernate
    Affects Versions: 8.0.0.Beta1
            Reporter: Scott Marlow
            Assignee: Scott Marlow
             Fix For: 8.0.0.CR1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 09:01:05 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Thu, 10 Oct 2013 09:01:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2277) application client jars in
 ear should be able to have persistence units deployed
In-Reply-To: <JIRA.12502689.1381409863000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502689.1381409863000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502689.1381409863000.31171.1381410065228@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813098#comment-12813098 ] 

Scott Marlow commented on WFLY-2277:
------------------------------------

WFLY-2151 caused this to stop working (I'd link these issues but I can't link from firefox anymore)
                
> application client jars in ear should be able to have persistence units deployed
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-2277
>                 URL: https://issues.jboss.org/browse/WFLY-2277
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 09:23:03 2013
From: jira-events at lists.jboss.org (Duncan Doyle (JIRA))
Date: Thu, 10 Oct 2013 09:23:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-295) Phreak mode does not
 evaluate 'from collect' correctly.
In-Reply-To: <JIRA.12502695.1381411324588@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502695.1381411324588@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502695.1381411324588.31295.1381411383123@jira02.app.mwc.hst.phx2.redhat.com>

Duncan Doyle created DROOLS-295:
-----------------------------------

             Summary: Phreak mode does not evaluate 'from collect' correctly.
                 Key: DROOLS-295
                 URL: https://issues.jboss.org/browse/DROOLS-295
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  6.0.0.CR4
         Environment: Mac OS-X 10.8.5, Oracle Hotspot 1.7.0_40, Drools 6.1.0-SNAPSHOT
            Reporter: Duncan Doyle
            Assignee: Mark Proctor


Reproducer project at: https://github.com/DuncanDoyle/Drools6PhreakFromCollectIssue

Run 'mvn clean test'. There are 2 tests which execute exactly the same thing against the same ruleset, one in ReteOO mode and one in Phreak. The result of the Phreak test is incorrect. There seems to be an issue with the 'from collect' in Phreak mode.

Please note that I'm using Drools 6.0.0-SNAPSHOT, as 6.0.0.Cr4-Pre1 contains a bug which causes the 'from collect' to go into an infinite loop. See Drools-276
 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 09:30:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 10 Oct 2013 09:30:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-292) Current AgendaGroup does not
 give way when setFocus is called
In-Reply-To: <JIRA.12502473.1381244876000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502473.1381244876000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502473.1381244876000.31371.1381411803369@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813118#comment-12813118 ] 

RH Bugzilla Integration commented on DROOLS-292:
------------------------------------------------

Edson Tirelli <etirelli at redhat.com> changed the Status of [bug 1016727|https://bugzilla.redhat.com/show_bug.cgi?id=1016727] from NEW to ASSIGNED
                
> Current AgendaGroup does not give way when setFocus is called
> -------------------------------------------------------------
>
>                 Key: DROOLS-292
>                 URL: https://issues.jboss.org/browse/DROOLS-292
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>            Reporter: Mark Proctor
>            Assignee: Mark Proctor
>             Fix For: 6.0.0.CR5
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 09:34:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 10 Oct 2013 09:34:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-292) Current AgendaGroup does not
 give way when setFocus is called
In-Reply-To: <JIRA.12502473.1381244876000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502473.1381244876000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502473.1381244876000.31383.1381412042602@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813120#comment-12813120 ] 

RH Bugzilla Integration commented on DROOLS-292:
------------------------------------------------

Edson Tirelli <etirelli at redhat.com> made a comment on [bug 1016727|https://bugzilla.redhat.com/show_bug.cgi?id=1016727]

Mark fixed this one:

6.0.x: https://github.com/droolsjbpm/drools/commit/a550d5ea54c8e816a5bade7d87d8e65e65ac37a2

master:
https://github.com/droolsjbpm/drools/commit/be1444020f71277207743d708238c05253b494a9
                
> Current AgendaGroup does not give way when setFocus is called
> -------------------------------------------------------------
>
>                 Key: DROOLS-292
>                 URL: https://issues.jboss.org/browse/DROOLS-292
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>            Reporter: Mark Proctor
>            Assignee: Mark Proctor
>             Fix For: 6.0.0.CR5
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 09:34:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 10 Oct 2013 09:34:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-292) Current AgendaGroup does not
 give way when setFocus is called
In-Reply-To: <JIRA.12502473.1381244876000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502473.1381244876000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502473.1381244876000.31386.1381412042762@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813121#comment-12813121 ] 

RH Bugzilla Integration commented on DROOLS-292:
------------------------------------------------

Edson Tirelli <etirelli at redhat.com> changed the Status of [bug 1016727|https://bugzilla.redhat.com/show_bug.cgi?id=1016727] from ASSIGNED to MODIFIED
                
> Current AgendaGroup does not give way when setFocus is called
> -------------------------------------------------------------
>
>                 Key: DROOLS-292
>                 URL: https://issues.jboss.org/browse/DROOLS-292
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>            Reporter: Mark Proctor
>            Assignee: Mark Proctor
>             Fix For: 6.0.0.CR5
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 09:34:02 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Thu, 10 Oct 2013 09:34:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2267) Persisting a new entity bean
 with certain patterns fails to ARJUNA016082 on flush stage.
In-Reply-To: <JIRA.12502535.1381312028000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502535.1381312028000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502535.1381312028000.31390.1381412042983@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow updated WFLY-2267:
-------------------------------

       Assignee: Scott Marlow  (was: jaikiran pai)
    Component/s: JPA / Hibernate
                     (was: Transactions)


This looks more like a JPA issue than transactions, reassigning.
                
> Persisting a new entity bean with certain patterns fails to ARJUNA016082 on flush stage.
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-2267
>                 URL: https://issues.jboss.org/browse/WFLY-2267
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Alpha4, 8.0.0.Beta1
>         Environment: Ubuntu Linux 13.04, JDK 1.7.0u40 64-bit.
>            Reporter: Jari Juslin
>            Assignee: Scott Marlow
>         Attachments: infinispan_bug_repro.zip, infinispan_bug_repro2.zip
>
>
> Persisting a new entity inside a CMT and then exiting the transactional method throws ARJUNA016082 in certain cases.
> I have extracted two cases where the bug manifests.
> 1) Creating a new entity bean and then changing one field after the persist call.
> 2) Creating a new entity bean that has another entity linked to it, and the newly created entity is on the blind side of the relationship.
> Here is the RESTeasy service and the entity bean needed to replicate this (also packaged to the attached test case):
> package bugrepro2;
> import javax.ejb.LocalBean;
> import javax.ejb.Stateless;
> import javax.persistence.EntityManager;
> import javax.persistence.PersistenceContext;
> import javax.ws.rs.POST;
> import javax.ws.rs.Path;
> /**
>  * @author Jari Juslin, zds at ecolane.com
>  */
> @Stateless
> @LocalBean
> @Path("/bug_repro2")
> public class BugRepro2Rest {
>     @PersistenceContext(unitName = "persistence_context2")
>     protected EntityManager entityManager;
>     
>     @POST
>     public String manifestArjunaBug() {
>         BugReproEntity entry = new BugReproEntity();
>         entityManager.persist(entry);
>         
>         entry.setHasChanges(true);
>         
>         return "Success\n";
>     }
> }
> package bugrepro2;
> import javax.persistence.Column;
> import javax.persistence.Entity;
> import javax.persistence.GeneratedValue;
> import javax.persistence.GenerationType;
> import javax.persistence.Id;
> import javax.persistence.Table;
> import org.hibernate.annotations.Cache;
> import org.hibernate.annotations.CacheConcurrencyStrategy;
> @Entity()
> @Table(name = "bugrepro_entity")
> @Cache(usage=CacheConcurrencyStrategy.TRANSACTIONAL)
> public class BugReproEntity {
>     private Integer id;
>     private boolean hasChanges;
>     public BugReproEntity() {
>     }
>     @Id
>     @GeneratedValue(strategy=GenerationType.IDENTITY)
>     @Column(name="id")
>     public Integer getId() {
>         return id;
>     }
>     public void setId(Integer id) {
>         this.id = id;
>     }
>     @Column(name="has_changes")
>     public boolean getHasChanges() {
>         return hasChanges;
>     }
>     public void setHasChanges(boolean hasChanges) {
>         this.hasChanges = hasChanges;
>     }
> }
> The resulting exception:
> 2013-10-09 12:44:07,362 WARN  [org.infinispan.transaction.TransactionTable] (default task-31:) ISPN000101: Failed synchronization registration: java.lang.IllegalStateException: ARJUNA016082: Synchronizations are not allowed! Transaction status isActionStatus.RUNNING
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronizationImple(TransactionImple.java:379)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronization(TransactionImple.java:356)
> 	at org.infinispan.transaction.TransactionTable.enlist(TransactionTable.java:196)
> 	at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:269)
> 	at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:231)
> 	at org.infinispan.interceptors.TxInterceptor.visitPutKeyValueCommand(TxInterceptor.java:177)
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.updateStoreStatistics(CacheMgmtInterceptor.java:148)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:134)
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:106)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:70)
> 	at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32)
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:321)
> 	at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1298)
> 	at org.infinispan.CacheImpl.putInternal(CacheImpl.java:871)
> 	at org.infinispan.CacheImpl.put(CacheImpl.java:863)
> 	at org.infinispan.DecoratedCache.put(DecoratedCache.java:401)
> 	at org.infinispan.AbstractDelegatingCache.put(AbstractDelegatingCache.java:276)
> 	at org.hibernate.cache.infinispan.access.TransactionalAccessDelegate.update(TransactionalAccessDelegate.java:187) [hibernate-infinispan-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.cache.infinispan.entity.TransactionalAccess.update(TransactionalAccess.java:89) [hibernate-infinispan-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.action.internal.EntityUpdateAction.execute(EntityUpdateAction.java:208) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:377) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:369) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:287) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:340) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:52) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1235) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:405) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:113) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:53) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76)
> 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:273)
> 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:93)
> 	at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1170)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
> 	at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:93) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:437)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72)
> 	at bugrepro2.BugRepro2Rest$$$view31.manifestArjunaBug(Unknown Source) [classes:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_40]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_40]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_40]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_40]
> 	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:280) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:234) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:221) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:59) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:218) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:619) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> The datasource definition from standalone.xml:
>                 <datasource jndi-name="java:/BugRepro2DS" pool-name="BugRepro2DS" enabled="true">
>                     <connection-url>jdbc:mysql://localhost:3306/bugrepro2</connection-url>
>                     <driver>mysql</driver>
>                     <security>
>                         <user-name>*******</user-name>
>                         <password>*******</password>
>                     </security>
>                 </datasource>
>                 <drivers>
>                     <driver name="mysql" module="com.mysql">
>                         <xa-datasource-class>com.mysql.jdbc.jdbc2.optional.MysqlXADataSource</xa-datasource-class>
>                     </driver>
>                 </drivers>
> I have reported this also to Infinispan, because I am not sure which party is to blame.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 09:47:02 2013
From: jira-events at lists.jboss.org (Jari Juslin (JIRA))
Date: Thu, 10 Oct 2013 09:47:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2267) Persisting a new entity bean
 with certain patterns fails to ARJUNA016082 on flush stage.
In-Reply-To: <JIRA.12502535.1381312028000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502535.1381312028000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502535.1381312028000.31419.1381412822712@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813126#comment-12813126 ] 

Jari Juslin commented on WFLY-2267:
-----------------------------------

I found that getting the EntityManager manually from EntityManagerFactory also fixes the problem:

    // This works
    @PUT
    public String customEntityManager() {
        EntityManager em = emf.createEntityManager();
        
        BugReproEntity entry = new BugReproEntity();

        em.persist(entry);
        
        entry.setHasChanges(true);
        
        em.flush();
        em.close();
        
        return "Success\n";
    }

This of course makes sense, as the EntityManager is already closed when the transactional session bean call exits.

Further:
Changing the <transaction mode="FULL_XA"/> to <transaction mode="NONE"/> on the standalone.xml makes the problem go away.
                
> Persisting a new entity bean with certain patterns fails to ARJUNA016082 on flush stage.
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-2267
>                 URL: https://issues.jboss.org/browse/WFLY-2267
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Alpha4, 8.0.0.Beta1
>         Environment: Ubuntu Linux 13.04, JDK 1.7.0u40 64-bit.
>            Reporter: Jari Juslin
>            Assignee: Scott Marlow
>         Attachments: infinispan_bug_repro.zip, infinispan_bug_repro2.zip
>
>
> Persisting a new entity inside a CMT and then exiting the transactional method throws ARJUNA016082 in certain cases.
> I have extracted two cases where the bug manifests.
> 1) Creating a new entity bean and then changing one field after the persist call.
> 2) Creating a new entity bean that has another entity linked to it, and the newly created entity is on the blind side of the relationship.
> Here is the RESTeasy service and the entity bean needed to replicate this (also packaged to the attached test case):
> package bugrepro2;
> import javax.ejb.LocalBean;
> import javax.ejb.Stateless;
> import javax.persistence.EntityManager;
> import javax.persistence.PersistenceContext;
> import javax.ws.rs.POST;
> import javax.ws.rs.Path;
> /**
>  * @author Jari Juslin, zds at ecolane.com
>  */
> @Stateless
> @LocalBean
> @Path("/bug_repro2")
> public class BugRepro2Rest {
>     @PersistenceContext(unitName = "persistence_context2")
>     protected EntityManager entityManager;
>     
>     @POST
>     public String manifestArjunaBug() {
>         BugReproEntity entry = new BugReproEntity();
>         entityManager.persist(entry);
>         
>         entry.setHasChanges(true);
>         
>         return "Success\n";
>     }
> }
> package bugrepro2;
> import javax.persistence.Column;
> import javax.persistence.Entity;
> import javax.persistence.GeneratedValue;
> import javax.persistence.GenerationType;
> import javax.persistence.Id;
> import javax.persistence.Table;
> import org.hibernate.annotations.Cache;
> import org.hibernate.annotations.CacheConcurrencyStrategy;
> @Entity()
> @Table(name = "bugrepro_entity")
> @Cache(usage=CacheConcurrencyStrategy.TRANSACTIONAL)
> public class BugReproEntity {
>     private Integer id;
>     private boolean hasChanges;
>     public BugReproEntity() {
>     }
>     @Id
>     @GeneratedValue(strategy=GenerationType.IDENTITY)
>     @Column(name="id")
>     public Integer getId() {
>         return id;
>     }
>     public void setId(Integer id) {
>         this.id = id;
>     }
>     @Column(name="has_changes")
>     public boolean getHasChanges() {
>         return hasChanges;
>     }
>     public void setHasChanges(boolean hasChanges) {
>         this.hasChanges = hasChanges;
>     }
> }
> The resulting exception:
> 2013-10-09 12:44:07,362 WARN  [org.infinispan.transaction.TransactionTable] (default task-31:) ISPN000101: Failed synchronization registration: java.lang.IllegalStateException: ARJUNA016082: Synchronizations are not allowed! Transaction status isActionStatus.RUNNING
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronizationImple(TransactionImple.java:379)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronization(TransactionImple.java:356)
> 	at org.infinispan.transaction.TransactionTable.enlist(TransactionTable.java:196)
> 	at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:269)
> 	at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:231)
> 	at org.infinispan.interceptors.TxInterceptor.visitPutKeyValueCommand(TxInterceptor.java:177)
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.updateStoreStatistics(CacheMgmtInterceptor.java:148)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:134)
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:106)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:70)
> 	at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32)
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:321)
> 	at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1298)
> 	at org.infinispan.CacheImpl.putInternal(CacheImpl.java:871)
> 	at org.infinispan.CacheImpl.put(CacheImpl.java:863)
> 	at org.infinispan.DecoratedCache.put(DecoratedCache.java:401)
> 	at org.infinispan.AbstractDelegatingCache.put(AbstractDelegatingCache.java:276)
> 	at org.hibernate.cache.infinispan.access.TransactionalAccessDelegate.update(TransactionalAccessDelegate.java:187) [hibernate-infinispan-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.cache.infinispan.entity.TransactionalAccess.update(TransactionalAccess.java:89) [hibernate-infinispan-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.action.internal.EntityUpdateAction.execute(EntityUpdateAction.java:208) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:377) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:369) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:287) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:340) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:52) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1235) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:405) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:113) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:53) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76)
> 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:273)
> 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:93)
> 	at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1170)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
> 	at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:93) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:437)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72)
> 	at bugrepro2.BugRepro2Rest$$$view31.manifestArjunaBug(Unknown Source) [classes:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_40]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_40]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_40]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_40]
> 	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:280) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:234) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:221) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:59) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:218) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:619) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> The datasource definition from standalone.xml:
>                 <datasource jndi-name="java:/BugRepro2DS" pool-name="BugRepro2DS" enabled="true">
>                     <connection-url>jdbc:mysql://localhost:3306/bugrepro2</connection-url>
>                     <driver>mysql</driver>
>                     <security>
>                         <user-name>*******</user-name>
>                         <password>*******</password>
>                     </security>
>                 </datasource>
>                 <drivers>
>                     <driver name="mysql" module="com.mysql">
>                         <xa-datasource-class>com.mysql.jdbc.jdbc2.optional.MysqlXADataSource</xa-datasource-class>
>                     </driver>
>                 </drivers>
> I have reported this also to Infinispan, because I am not sure which party is to blame.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 09:49:02 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Thu, 10 Oct 2013 09:49:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2278) Deployer can't modify data
 source when datasources set as application resources
In-Reply-To: <JIRA.12502701.1381412857954@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502701.1381412857954@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502701.1381412857954.31423.1381412942669@jira02.app.mwc.hst.phx2.redhat.com>

Ladislav Thon created WFLY-2278:
-----------------------------------

             Summary: Deployer can't modify data source when datasources set as application resources
                 Key: WFLY-2278
                 URL: https://issues.jboss.org/browse/WFLY-2278
             Project: WildFly
          Issue Type: Bug
          Components: Domain Management
            Reporter: Ladislav Thon
            Assignee: Brian Stansberry


When data sources are made application resources, deployer should be able to modify them. This doesn't work, as opposed to e.g. mail sessions. For example:

{code}
/core-service=management/access=authorization/constraint=application-classification/type=datasources/classification=data-source:write-attribute(name=configured-application, value=true)
{"outcome" => "success"}
[standalone at localhost:9990 /] /subsystem=datasources/data-source=ExampleDS:write-attribute(name=jndi-name, value="java:jboss/datasources/ExampleDS_XXX"){roles=deployer}
{
    "outcome" => "failed",
    "failure-description" => "JBAS013456: Unauthorized to execute operation 'write-attribute' for resource '[
    (\"subsystem\" => \"datasources\"),
    (\"data-source\" => \"ExampleDS\")
]' -- \"JBAS013475: Permission denied\"",
    "rolled-back" => true
}
[standalone at localhost:9990 /] /core-service=management/access=authorization/constraint=application-classification/type=mail/classification=mail-session:write-attribute(name=configured-application, value=true)
{"outcome" => "success"}
[standalone at localhost:9990 /] /subsystem=mail/mail-session=java\:jboss\/mail\/Default:write-attribute(name=jndi-name, value="java:jboss/mail/Default_XXX"){roles=deployer} 
{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    }
}
{code}

I have a test case for this as a last commit in my branch https://github.com/Ladicek/wildfly/commits/rbac (that is the commit called _RBAC test case for application types_).

Brian, in case you are not the right assignee, please reassign.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 09:49:02 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Thu, 10 Oct 2013 09:49:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2278) Deployer can't modify data
 source when datasources set as application resources
In-Reply-To: <JIRA.12502701.1381412857000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502701.1381412857000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502701.1381412857000.31425.1381412942761@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ladislav Thon updated WFLY-2278:
--------------------------------

        Parent: WFLY-490
    Issue Type: Sub-task  (was: Bug)

    
> Deployer can't modify data source when datasources set as application resources
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-2278
>                 URL: https://issues.jboss.org/browse/WFLY-2278
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Brian Stansberry
>              Labels: rbac-filed-by-qa
>
> When data sources are made application resources, deployer should be able to modify them. This doesn't work, as opposed to e.g. mail sessions. For example:
> {code}
> /core-service=management/access=authorization/constraint=application-classification/type=datasources/classification=data-source:write-attribute(name=configured-application, value=true)
> {"outcome" => "success"}
> [standalone at localhost:9990 /] /subsystem=datasources/data-source=ExampleDS:write-attribute(name=jndi-name, value="java:jboss/datasources/ExampleDS_XXX"){roles=deployer}
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS013456: Unauthorized to execute operation 'write-attribute' for resource '[
>     (\"subsystem\" => \"datasources\"),
>     (\"data-source\" => \"ExampleDS\")
> ]' -- \"JBAS013475: Permission denied\"",
>     "rolled-back" => true
> }
> [standalone at localhost:9990 /] /core-service=management/access=authorization/constraint=application-classification/type=mail/classification=mail-session:write-attribute(name=configured-application, value=true)
> {"outcome" => "success"}
> [standalone at localhost:9990 /] /subsystem=mail/mail-session=java\:jboss\/mail\/Default:write-attribute(name=jndi-name, value="java:jboss/mail/Default_XXX"){roles=deployer} 
> {
>     "outcome" => "success",
>     "response-headers" => {
>         "operation-requires-reload" => true,
>         "process-state" => "reload-required"
>     }
> }
> {code}
> I have a test case for this as a last commit in my branch https://github.com/Ladicek/wildfly/commits/rbac (that is the commit called _RBAC test case for application types_).
> Brian, in case you are not the right assignee, please reassign.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 09:52:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 10 Oct 2013 09:52:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2278) Deployer can't modify data
 source when datasources set as application resources
In-Reply-To: <JIRA.12502701.1381412857000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502701.1381412857000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502701.1381412857000.31430.1381413122743@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2278:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1017786

    
> Deployer can't modify data source when datasources set as application resources
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-2278
>                 URL: https://issues.jboss.org/browse/WFLY-2278
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Brian Stansberry
>              Labels: rbac-filed-by-qa
>
> When data sources are made application resources, deployer should be able to modify them. This doesn't work, as opposed to e.g. mail sessions. For example:
> {code}
> /core-service=management/access=authorization/constraint=application-classification/type=datasources/classification=data-source:write-attribute(name=configured-application, value=true)
> {"outcome" => "success"}
> [standalone at localhost:9990 /] /subsystem=datasources/data-source=ExampleDS:write-attribute(name=jndi-name, value="java:jboss/datasources/ExampleDS_XXX"){roles=deployer}
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS013456: Unauthorized to execute operation 'write-attribute' for resource '[
>     (\"subsystem\" => \"datasources\"),
>     (\"data-source\" => \"ExampleDS\")
> ]' -- \"JBAS013475: Permission denied\"",
>     "rolled-back" => true
> }
> [standalone at localhost:9990 /] /core-service=management/access=authorization/constraint=application-classification/type=mail/classification=mail-session:write-attribute(name=configured-application, value=true)
> {"outcome" => "success"}
> [standalone at localhost:9990 /] /subsystem=mail/mail-session=java\:jboss\/mail\/Default:write-attribute(name=jndi-name, value="java:jboss/mail/Default_XXX"){roles=deployer} 
> {
>     "outcome" => "success",
>     "response-headers" => {
>         "operation-requires-reload" => true,
>         "process-state" => "reload-required"
>     }
> }
> {code}
> I have a test case for this as a last commit in my branch https://github.com/Ladicek/wildfly/commits/rbac (that is the commit called _RBAC test case for application types_).
> Brian, in case you are not the right assignee, please reassign.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 09:52:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 10 Oct 2013 09:52:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2278) Deployer can't modify data
 source when datasources set as application resources
In-Reply-To: <JIRA.12502701.1381412857000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502701.1381412857000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502701.1381412857000.31434.1381413122987@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813127#comment-12813127 ] 

RH Bugzilla Integration commented on WFLY-2278:
-----------------------------------------------

Ladislav Thon <lthon at redhat.com> made a comment on [bug 1017786|https://bugzilla.redhat.com/show_bug.cgi?id=1017786]

When data sources are made application resources, deployer should be able to modify them. This doesn't work, as opposed to e.g. mail sessions. For example:

/core-service=management/access=authorization/constraint=application-classification/type=datasources/classification=data-source:write-attribute(name=configured-application, value=true)
{"outcome" => "success"}

/subsystem=datasources/data-source=ExampleDS:write-attribute(name=jndi-name, value="java:jboss/datasources/ExampleDS_XXX"){roles=deployer}
{
    "outcome" => "failed",
    "failure-description" => "JBAS013456: Unauthorized to execute operation 'write-attribute' for resource '[
    (\"subsystem\" => \"datasources\"),
    (\"data-source\" => \"ExampleDS\")
]' -- \"JBAS013475: Permission denied\"",
    "rolled-back" => true
}

/core-service=management/access=authorization/constraint=application-classification/type=mail/classification=mail-session:write-attribute(name=configured-application, value=true)
{"outcome" => "success"}

/subsystem=mail/mail-session=java\:jboss\/mail\/Default:write-attribute(name=jndi-name, value="java:jboss/mail/Default_XXX"){roles=deployer} 
{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    }
}

I have a test case for this as a last commit in my branch https://github.com/Ladicek/wildfly/commits/rbac (that is the commit called "RBAC test case for application types").
                
> Deployer can't modify data source when datasources set as application resources
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-2278
>                 URL: https://issues.jboss.org/browse/WFLY-2278
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Brian Stansberry
>              Labels: rbac-filed-by-qa
>
> When data sources are made application resources, deployer should be able to modify them. This doesn't work, as opposed to e.g. mail sessions. For example:
> {code}
> /core-service=management/access=authorization/constraint=application-classification/type=datasources/classification=data-source:write-attribute(name=configured-application, value=true)
> {"outcome" => "success"}
> [standalone at localhost:9990 /] /subsystem=datasources/data-source=ExampleDS:write-attribute(name=jndi-name, value="java:jboss/datasources/ExampleDS_XXX"){roles=deployer}
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS013456: Unauthorized to execute operation 'write-attribute' for resource '[
>     (\"subsystem\" => \"datasources\"),
>     (\"data-source\" => \"ExampleDS\")
> ]' -- \"JBAS013475: Permission denied\"",
>     "rolled-back" => true
> }
> [standalone at localhost:9990 /] /core-service=management/access=authorization/constraint=application-classification/type=mail/classification=mail-session:write-attribute(name=configured-application, value=true)
> {"outcome" => "success"}
> [standalone at localhost:9990 /] /subsystem=mail/mail-session=java\:jboss\/mail\/Default:write-attribute(name=jndi-name, value="java:jboss/mail/Default_XXX"){roles=deployer} 
> {
>     "outcome" => "success",
>     "response-headers" => {
>         "operation-requires-reload" => true,
>         "process-state" => "reload-required"
>     }
> }
> {code}
> I have a test case for this as a last commit in my branch https://github.com/Ladicek/wildfly/commits/rbac (that is the commit called _RBAC test case for application types_).
> Brian, in case you are not the right assignee, please reassign.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 09:54:02 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Thu, 10 Oct 2013 09:54:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2249) NPE during redeployment of a
	war
In-Reply-To: <JIRA.12502347.1381151954000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502347.1381151954000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502347.1381151954000.31439.1381413242685@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813128#comment-12813128 ] 

Scott Marlow commented on WFLY-2249:
------------------------------------

Yes, please close the issue.  We can reopen or create a new one if the npe occurs again.
                
> NPE during redeployment of a war
> --------------------------------
>
>                 Key: WFLY-2249
>                 URL: https://issues.jboss.org/browse/WFLY-2249
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Juergen Zimmermann
>            Assignee: Scott Marlow
>
> When I redeploy an already running war, then I get the following NPE. The (re-) deployment is done via the Maven plugin org.jboss.as.plugins:jboss-as-maven-plugin:7.4.Final. It looks like the redployment was successful anyway. Hmm...
> {code}
> ERROR [org.jboss.msc.service.fail] MSC000001: Failed to start service jboss.deployment.unit."shop.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."shop.war".PARSE: JBAS018733: Failed to process phase PARSE of deployment "shop.war"
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> Caused by: java.lang.NullPointerException
> 	at org.jboss.as.jpa.processor.PersistenceUnitParseProcessor.handleWarDeployment(PersistenceUnitParseProcessor.java:126)
> 	at org.jboss.as.jpa.processor.PersistenceUnitParseProcessor.deploy(PersistenceUnitParseProcessor.java:83)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	... 5 more
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 10:18:02 2013
From: jira-events at lists.jboss.org (Juergen Zimmermann (JIRA))
Date: Thu, 10 Oct 2013 10:18:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2249) NPE during redeployment of a
	war
In-Reply-To: <JIRA.12502347.1381151954000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502347.1381151954000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502347.1381151954000.31501.1381414682813@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Juergen Zimmermann closed WFLY-2249.
------------------------------------

    Resolution: Out of Date

    
> NPE during redeployment of a war
> --------------------------------
>
>                 Key: WFLY-2249
>                 URL: https://issues.jboss.org/browse/WFLY-2249
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Juergen Zimmermann
>            Assignee: Scott Marlow
>
> When I redeploy an already running war, then I get the following NPE. The (re-) deployment is done via the Maven plugin org.jboss.as.plugins:jboss-as-maven-plugin:7.4.Final. It looks like the redployment was successful anyway. Hmm...
> {code}
> ERROR [org.jboss.msc.service.fail] MSC000001: Failed to start service jboss.deployment.unit."shop.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."shop.war".PARSE: JBAS018733: Failed to process phase PARSE of deployment "shop.war"
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> Caused by: java.lang.NullPointerException
> 	at org.jboss.as.jpa.processor.PersistenceUnitParseProcessor.handleWarDeployment(PersistenceUnitParseProcessor.java:126)
> 	at org.jboss.as.jpa.processor.PersistenceUnitParseProcessor.deploy(PersistenceUnitParseProcessor.java:83)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	... 5 more
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 10:18:03 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Thu, 10 Oct 2013 10:18:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2279) Make it possible to
 unintrusively be able to test transformers against legacy EAP release
In-Reply-To: <JIRA.12502706.1381414636547@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502706.1381414636547@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502706.1381414636547.31506.1381414683019@jira02.app.mwc.hst.phx2.redhat.com>

Kabir Khan created WFLY-2279:
--------------------------------

             Summary: Make it possible to unintrusively be able to test transformers against legacy EAP release
                 Key: WFLY-2279
                 URL: https://issues.jboss.org/browse/WFLY-2279
             Project: WildFly
          Issue Type: Feature Request
          Components: Domain Management
            Reporter: Kabir Khan
            Assignee: Kabir Khan
             Fix For: 8.0.0.CR1


We need to test transformation of subsystems and core-model against old EAP releases, which means fetching artifacts from the internal EAP repository. External contributors will not have access to this repository, so we need to be able to disable the transformers tests for legacy EAP versions if not on the VPN.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 10:44:02 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 10 Oct 2013 10:44:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1088) Bean validation needs to be
 added to the validator scripts
In-Reply-To: <JIRA.12502708.1381416213022@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502708.1381416213022@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502708.1381416213022.31621.1381416242780@jira02.app.mwc.hst.phx2.redhat.com>

Jesper Pedersen created JBJCA-1088:
--------------------------------------

             Summary: Bean validation needs to be added to the validator scripts
                 Key: JBJCA-1088
                 URL: https://issues.jboss.org/browse/JBJCA-1088
             Project: IronJacamar
          Issue Type: Bug
          Components: AS
    Affects Versions: 1.1.0.Final
            Reporter: Jesper Pedersen
            Assignee: Jeff Zhang
             Fix For: 1.1.1.Final


The validation-api.jar and hibernate-validator.jar files needs to be added to the validator scripts (.sh / .bat)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 10:48:03 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 10 Oct 2013 10:48:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1089) AOReferenceable check
In-Reply-To: <JIRA.12502709.1381416427914@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502709.1381416427914@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502709.1381416427914.31649.1381416483413@jira02.app.mwc.hst.phx2.redhat.com>

Jesper Pedersen created JBJCA-1089:
--------------------------------------

             Summary: AOReferenceable check
                 Key: JBJCA-1089
                 URL: https://issues.jboss.org/browse/JBJCA-1089
             Project: IronJacamar
          Issue Type: Task
          Components: Validator
            Reporter: Jesper Pedersen
            Assignee: Jeff Zhang
             Fix For: 1.1.1.Final


Add a check to the validator which verifies that an AdminObject implements javax.naming.Referenceable

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 10:48:03 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 10 Oct 2013 10:48:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1088) Bean validation needs to be
 added to the validator scripts
In-Reply-To: <JIRA.12502708.1381416213000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502708.1381416213000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502708.1381416213000.31657.1381416483770@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated JBJCA-1088:
-----------------------------------

    Component/s: Validator
                     (was: AS)

    
> Bean validation needs to be added to the validator scripts
> ----------------------------------------------------------
>
>                 Key: JBJCA-1088
>                 URL: https://issues.jboss.org/browse/JBJCA-1088
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Validator
>    Affects Versions: 1.1.0.Final
>            Reporter: Jesper Pedersen
>            Assignee: Jeff Zhang
>             Fix For: 1.1.1.Final
>
>
> The validation-api.jar and hibernate-validator.jar files needs to be added to the validator scripts (.sh / .bat)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 10:52:03 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 10 Oct 2013 10:52:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1090) Bean validation needs to be
 added to the RAR info tool scripts
In-Reply-To: <JIRA.12502711.1381416638152@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502711.1381416638152@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502711.1381416638152.31685.1381416723046@jira02.app.mwc.hst.phx2.redhat.com>

Jesper Pedersen created JBJCA-1090:
--------------------------------------

             Summary: Bean validation needs to be added to the RAR info tool scripts
                 Key: JBJCA-1090
                 URL: https://issues.jboss.org/browse/JBJCA-1090
             Project: IronJacamar
          Issue Type: Bug
          Components: AS
    Affects Versions: 1.1.0.Final
            Reporter: Jesper Pedersen
            Assignee: Jeff Zhang
             Fix For: 1.1.1.Final


The validation-api.jar and hibernate-validator.jar files needs to be added to the RAR info tool scripts (.sh / .bat)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 10:52:03 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Thu, 10 Oct 2013 10:52:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-97) Object value passed to
 JBossLogManagerProvider.putMdc(String,
 Object) should be returned from getMdc(final String)
In-Reply-To: <JIRA.12502712.1381416719985@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502712.1381416719985@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502712.1381416719985.31702.1381416723827@jira02.app.mwc.hst.phx2.redhat.com>

Scott Marlow created JBLOGGING-97:
-------------------------------------

             Summary: Object value passed to JBossLogManagerProvider.putMdc(String, Object) should be returned from getMdc(final String)
                 Key: JBLOGGING-97
                 URL: https://issues.jboss.org/browse/JBLOGGING-97
             Project: JBoss Logging
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: slf4j-jboss-logmanager
    Affects Versions: 3.1.3.GA
            Reporter: Scott Marlow
            Assignee: David Lloyd
             Fix For: 3.1.4.GA


Change JBossLogManagerProvider.putMdc(final String key, final Object value) to call MDC.put(key, value) instead of MDC.put(key, String.valueOf(value))

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 10:58:03 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Thu, 10 Oct 2013 10:58:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-97) Object value passed to
 JBossLogManagerProvider.putMdc(String,
 Object) should be returned from getMdc(final String)
In-Reply-To: <JIRA.12502712.1381416719000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502712.1381416719000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502712.1381416719000.31739.1381417083171@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBLOGGING-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow updated JBLOGGING-97:
----------------------------------

    Priority: Blocker  (was: Major)

    
> Object value passed to JBossLogManagerProvider.putMdc(String, Object) should be returned from getMdc(final String)
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBLOGGING-97
>                 URL: https://issues.jboss.org/browse/JBLOGGING-97
>             Project: JBoss Logging
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: slf4j-jboss-logmanager
>    Affects Versions: 3.1.3.GA
>            Reporter: Scott Marlow
>            Assignee: David Lloyd
>            Priority: Blocker
>             Fix For: 3.1.4.GA
>
>
> Change JBossLogManagerProvider.putMdc(final String key, final Object value) to call MDC.put(key, value) instead of MDC.put(key, String.valueOf(value))

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 10:58:03 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Thu, 10 Oct 2013 10:58:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-97) Object value passed to
 JBossLogManagerProvider.putMdc(String,
 Object) should be returned from getMdc(final String)
In-Reply-To: <JIRA.12502712.1381416719000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502712.1381416719000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502712.1381416719000.31744.1381417083529@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBLOGGING-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813170#comment-12813170 ] 

Scott Marlow commented on JBLOGGING-97:
---------------------------------------

changed to blocker since its blocking the upgrade to Hibernate ORM 4.3.0.Beta5
                
> Object value passed to JBossLogManagerProvider.putMdc(String, Object) should be returned from getMdc(final String)
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBLOGGING-97
>                 URL: https://issues.jboss.org/browse/JBLOGGING-97
>             Project: JBoss Logging
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: slf4j-jboss-logmanager
>    Affects Versions: 3.1.3.GA
>            Reporter: Scott Marlow
>            Assignee: David Lloyd
>            Priority: Blocker
>             Fix For: 3.1.4.GA
>
>
> Change JBossLogManagerProvider.putMdc(final String key, final Object value) to call MDC.put(key, value) instead of MDC.put(key, String.valueOf(value))

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 11:08:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 10 Oct 2013 11:08:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1489) Incorrect heap description in
 VM metrics view
In-Reply-To: <JIRA.12493929.1370859389000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493929.1370859389000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493929.1370859389000.31828.1381417683186@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813177#comment-12813177 ] 

RH Bugzilla Integration commented on WFLY-1489:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 880648|https://bugzilla.redhat.com/show_bug.cgi?id=880648] from MODIFIED to ON_QA
                
> Incorrect heap description in VM metrics view
> ---------------------------------------------
>
>                 Key: WFLY-1489
>                 URL: https://issues.jboss.org/browse/WFLY-1489
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web Console
>            Reporter: Heiko Braun
>            Assignee: Chao Wang
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 11:10:02 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 10 Oct 2013 11:10:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1089) AOReferenceable check
In-Reply-To: <JIRA.12502709.1381416427000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502709.1381416427000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502709.1381416427000.31833.1381417802601@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen closed JBJCA-1089.
----------------------------------

         Assignee: Jesper Pedersen  (was: Jeff Zhang)
    Fix Version/s:     (was: 1.1.1.Final)
       Resolution: Rejected

    
> AOReferenceable check
> ---------------------
>
>                 Key: JBJCA-1089
>                 URL: https://issues.jboss.org/browse/JBJCA-1089
>             Project: IronJacamar
>          Issue Type: Task
>          Components: Validator
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>
> Add a check to the validator which verifies that an AdminObject implements javax.naming.Referenceable

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 11:27:02 2013
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 10 Oct 2013 11:27:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2276) URI ENCODING does not work in
 the beta1 version (UTF-8)
In-Reply-To: <JIRA.12502684.1381404449000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502684.1381404449000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502684.1381404449000.31878.1381418822652@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813186#comment-12813186 ] 

jaikiran pai commented on WFLY-2276:
------------------------------------

Are you really using JBoss Web subsystem? That's no longer shipped.

                
> URI ENCODING does not work in the beta1 version (UTF-8)
> -------------------------------------------------------
>
>                 Key: WFLY-2276
>                 URL: https://issues.jboss.org/browse/WFLY-2276
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (JBoss Web)
>    Affects Versions: 8.0.0.Beta1
>         Environment: Java 7, ubuntu 12.04
>            Reporter: alexandre xypas
>              Labels: encoding, utf-8
>
> In standalone.xml, the following is working in Alpha4, but not anymore in Beta1.
> <property name="org.apache.catalina.connector.URI_ENCODING" value="UTF-8"/>
> <property name="org.apache.catalina.connector.USE_BODY_ENCODING_FOR_QUERY_STRING" value="true"/>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 11:29:02 2013
From: jira-events at lists.jboss.org (Matti Linnanvuori (JIRA))
Date: Thu, 10 Oct 2013 11:29:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1091) Wrong XA Datasource selected
In-Reply-To: <JIRA.12502716.1381418849309@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502716.1381418849309@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502716.1381418849309.31880.1381418942664@jira02.app.mwc.hst.phx2.redhat.com>

Matti Linnanvuori created JBJCA-1091:
----------------------------------------

             Summary: Wrong XA Datasource selected
                 Key: JBJCA-1091
                 URL: https://issues.jboss.org/browse/JBJCA-1091
             Project: IronJacamar
          Issue Type: Bug
          Components: JDBC
    Affects Versions: 1.0.17.Final
         Environment: Wildfly 8, Debian Linux
            Reporter: Matti Linnanvuori
            Assignee: Jesper Pedersen


A wrong XA datasource OperationalDS instead of specified FrontendDS is chosen for a database query.

ESC[0mESC[33m10:53:47,089 WARN  [com.arjuna.ats.jta] (default task-24) ARJUNA016089: TransactionImple.enlistResource - xa_start  - caught: XAException.XAER_INVAL for < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff90cae62c:4e8567e5:5256b6f0:2894, node_name=1, branch_uid=0:ffff90cae62c:4e8567e5:5256b6f0:2899, subordinatenodename=null, eis_name=java:/OperationalDS >: com.mysql.jdbc.jdbc2.optional.MysqlXAException: XAER_INVAL: Invalid arguments (or unsupported command)
        at com.mysql.jdbc.jdbc2.optional.MysqlXAConnection.mapXAExceptionFromSQLException(MysqlXAConnection.java:600) [mysql-connector-java-5.1.26-bin.jar:]
        at com.mysql.jdbc.jdbc2.optional.MysqlXAConnection.dispatchCommand(MysqlXAConnection.java:583) [mysql-connector-java-5.1.26-bin.jar:]
        at com.mysql.jdbc.jdbc2.optional.MysqlXAConnection.start(MysqlXAConnection.java:523) [mysql-connector-java-5.1.26-bin.jar:]
        at org.jboss.jca.adapters.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:259)
        at org.jboss.jca.core.tx.jbossts.XAResourceWrapperImpl.start(XAResourceWrapperImpl.java:191)
        at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:715) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
        at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:397) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
        at org.jboss.jca.core.connectionmanager.listener.TxConnectionListener$TransactionSynchronization.enlist(TxConnectionListener.java:607)
        at org.jboss.jca.core.connectionmanager.listener.TxConnectionListener.enlist(TxConnectionListener.java:265)
        at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.managedConnectionReconnected(TxConnectionManagerImpl.java:467)
        at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.reconnectManagedConnection(AbstractConnectionManager.java:599)
        at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:467)
        at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:139)
        at org.hibernate.engine.jdbc.connections.internal.DatasourceConnectionProviderImpl.getConnection(DatasourceConnectionProviderImpl.java:138) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.internal.AbstractSessionImpl$NonContextualJdbcConnectionAccess.obtainConnection(AbstractSessionImpl.java:359) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.engine.jdbc.internal.LogicalConnectionImpl.obtainConnection(LogicalConnectionImpl.java:227) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.engine.jdbc.internal.LogicalConnectionImpl.getConnection(LogicalConnectionImpl.java:170) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.engine.jdbc.internal.StatementPreparerImpl.connection(StatementPreparerImpl.java:63) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.engine.jdbc.internal.StatementPreparerImpl$5.doPrepare(StatementPreparerImpl.java:164) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.engine.jdbc.internal.StatementPreparerImpl$StatementPreparationTemplate.prepareStatement(StatementPreparerImpl.java:185) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.engine.jdbc.internal.StatementPreparerImpl.prepareQueryStatement(StatementPreparerImpl.java:162) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1859) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1836) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1813) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.loader.Loader.doQuery(Loader.java:895) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:340) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.loader.Loader.doList(Loader.java:2523) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.loader.Loader.doList(Loader.java:2509) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2339) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]

        at org.hibernate.loader.Loader.list(Loader.java:2334) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:491) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:369) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:222) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1270) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.internal.QueryImpl.list(QueryImpl.java:101) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.jpa.internal.QueryImpl.getSingleResult(QueryImpl.java:381) [hibernate-entitymanager-4.3.0.Beta3.jar:4.3.0.Beta3]
        at com.ecolane.mpk.frontend.beans.FrontendLiaisonBean.getOurFeService(FrontendLiaisonBean.java:123) [k3-main.jar:]
        at com.ecolane.mpk.frontend.beans.FrontendLiaisonBean.synchOneCustomerToFrontend(FrontendLiaisonBean.java:362) [k3-main.jar:]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_03]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_03]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_03]
        at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_03]
        at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
        at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:130) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:138) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
        at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
        at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
        at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:251) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:342) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:90) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:55)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
        at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:419)
        at org.wildfly.security.manager.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
        at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_03]
        at org.jboss.invocation.PrivilegedInterceptor.processInvocation(PrivilegedInterceptor.java:75)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
        at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
        at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
        at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72)
        at com.ecolane.mpk.frontend.beans.FrontendLiaisonLocal$$$view296.synchOneCustomerToFrontend(Unknown Source) [k3-main.jar:]
        at com.ecolane.mpk.apps.beans.ToolBackendBean.synchOneCustomerToFrontend(ToolBackendBean.java:717) [k3-main.jar:]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_03]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_03]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_03]
        at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_03]
        at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
        at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:130) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:138) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
        at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
        at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
        at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:251) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:342) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]

    @PersistenceContext(unitName=K3Configuration.PERSISTENCE_CONTEXT_FRONTEND_NAME)
    private transient EntityManager entityManager;


                <xa-datasource jndi-name="java:/FrontendDS" pool-name="MpkDemoUsFrontendDS" enabled="true">
                    <xa-datasource-property name="ServerName">
                        localhost
                    </xa-datasource-property>
                    <xa-datasource-property name="DatabaseName">
                        production
                    </xa-datasource-property>
                    <driver>mysql</driver>
                    <security>
                        <user-name>frontend</user-name>
                        <password>fghfghfghfh</password>
                    </security>
                </xa-datasource>

<?xml version="1.0" encoding="UTF-8"?>
<persistence xmlns="http://java.sun.com/xml/ns/persistence"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd"
    version="2.0">
    <persistence-unit name="k3_frontend_persistence" transaction-type="JTA">
        <jta-data-source>@DATASOURCE_FRONTEND@</jta-data-source>
        <shared-cache-mode>ENABLE_SELECTIVE</shared-cache-mode>
                <properties>
            <property name="hibernate.dialect" value="com.ecolane.mpk.persistence.util.Mysql5BitBooleanInnoDBDialect" />
                        <property name="jboss.entity.manager.jndi.name" value="K3FrontendEntityManager" />
                        <property name="jboss.entity.manager.factory.jndi.name"
                                value="K3FrontendEntityManagerFactory" />
            <property name="hibernate.hbm2ddl.auto" value="validate"/>
            
            <!-- Infinispan conf -->
            <property name="hibernate.cache.use_second_level_cache" value="true"/>
            <property name="hibernate.cache.use_query_cache" value="true"/>
<!--             <property name="hibernate.cache.region.factory_class" -->
/>
            <property name="hibernate.cache.use_query_cache" value="true"/>
<!--             <property name="hibernate.cache.region.factory_class" -->
<!--                 value="org.hibernate.cache.infinispan.JndiInfinispanRegionFactory"/> -->
<!--             <property name="hibernate.cache.region.factory_class" -->
<!--                 value="org.hibernate.cache.infinispan.InfinispanRegionFactory"/> -->
<!--             <property name="hibernate.cache.infinispan.cfg" value="infinispan-configs.xml" />   -->
<!--             <property name="hibernate.cache.infinispan.cachemanager" value="java:CacheManager/entity"/> -->
            <property name="hibernate.generate_statistics" value="true" />
<!--             <property name="hibernate.cache.use_structured_entries" value="false" /> -->
            <!-- property name="hibernate.cache.infinispan.statistics" value="true"/-->
<!--             <property name="hibernate.transaction.manager_lookup_class" -->
<!--                 value="org.hibernate.transaction.JBossTransactionManagerLookup"/> -->
                </properties>
        </persistence-unit>
</persistence>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 11:32:02 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 10 Oct 2013 11:32:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2280) Wrong XA Datasource selected
In-Reply-To: <JIRA.12502716.1381418849000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502716.1381418849000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502716.1381418849000.31884.1381419122701@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen moved JBJCA-1091 to WFLY-2280:
----------------------------------------------

              Project: WildFly  (was: IronJacamar)
                  Key: WFLY-2280  (was: JBJCA-1091)
             Workflow: GIT Pull Request workflow   (was: classic default workflow)
    Affects Version/s:     (was: 1.0.17.Final)
          Component/s: JPA / Hibernate
                           (was: JDBC)

    
> Wrong XA Datasource selected
> ----------------------------
>
>                 Key: WFLY-2280
>                 URL: https://issues.jboss.org/browse/WFLY-2280
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>         Environment: Wildfly 8, Debian Linux
>            Reporter: Matti Linnanvuori
>            Assignee: Jesper Pedersen
>
> A wrong XA datasource OperationalDS instead of specified FrontendDS is chosen for a database query.
> ESC[0mESC[33m10:53:47,089 WARN  [com.arjuna.ats.jta] (default task-24) ARJUNA016089: TransactionImple.enlistResource - xa_start  - caught: XAException.XAER_INVAL for < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff90cae62c:4e8567e5:5256b6f0:2894, node_name=1, branch_uid=0:ffff90cae62c:4e8567e5:5256b6f0:2899, subordinatenodename=null, eis_name=java:/OperationalDS >: com.mysql.jdbc.jdbc2.optional.MysqlXAException: XAER_INVAL: Invalid arguments (or unsupported command)
>         at com.mysql.jdbc.jdbc2.optional.MysqlXAConnection.mapXAExceptionFromSQLException(MysqlXAConnection.java:600) [mysql-connector-java-5.1.26-bin.jar:]
>         at com.mysql.jdbc.jdbc2.optional.MysqlXAConnection.dispatchCommand(MysqlXAConnection.java:583) [mysql-connector-java-5.1.26-bin.jar:]
>         at com.mysql.jdbc.jdbc2.optional.MysqlXAConnection.start(MysqlXAConnection.java:523) [mysql-connector-java-5.1.26-bin.jar:]
>         at org.jboss.jca.adapters.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:259)
>         at org.jboss.jca.core.tx.jbossts.XAResourceWrapperImpl.start(XAResourceWrapperImpl.java:191)
>         at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:715) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
>         at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:397) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
>         at org.jboss.jca.core.connectionmanager.listener.TxConnectionListener$TransactionSynchronization.enlist(TxConnectionListener.java:607)
>         at org.jboss.jca.core.connectionmanager.listener.TxConnectionListener.enlist(TxConnectionListener.java:265)
>         at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.managedConnectionReconnected(TxConnectionManagerImpl.java:467)
>         at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.reconnectManagedConnection(AbstractConnectionManager.java:599)
>         at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:467)
>         at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:139)
>         at org.hibernate.engine.jdbc.connections.internal.DatasourceConnectionProviderImpl.getConnection(DatasourceConnectionProviderImpl.java:138) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.internal.AbstractSessionImpl$NonContextualJdbcConnectionAccess.obtainConnection(AbstractSessionImpl.java:359) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.LogicalConnectionImpl.obtainConnection(LogicalConnectionImpl.java:227) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.LogicalConnectionImpl.getConnection(LogicalConnectionImpl.java:170) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.StatementPreparerImpl.connection(StatementPreparerImpl.java:63) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.StatementPreparerImpl$5.doPrepare(StatementPreparerImpl.java:164) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.StatementPreparerImpl$StatementPreparationTemplate.prepareStatement(StatementPreparerImpl.java:185) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.StatementPreparerImpl.prepareQueryStatement(StatementPreparerImpl.java:162) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1859) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1836) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1813) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.doQuery(Loader.java:895) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:340) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.doList(Loader.java:2523) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.doList(Loader.java:2509) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2339) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.list(Loader.java:2334) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:491) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:369) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:222) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1270) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.internal.QueryImpl.list(QueryImpl.java:101) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.jpa.internal.QueryImpl.getSingleResult(QueryImpl.java:381) [hibernate-entitymanager-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at com.ecolane.mpk.frontend.beans.FrontendLiaisonBean.getOurFeService(FrontendLiaisonBean.java:123) [k3-main.jar:]
>         at com.ecolane.mpk.frontend.beans.FrontendLiaisonBean.synchOneCustomerToFrontend(FrontendLiaisonBean.java:362) [k3-main.jar:]
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_03]
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_03]
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_03]
>         at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_03]
>         at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
>         at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:130) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:138) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
>         at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
>         at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:251) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:342) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:90) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:55)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
>         at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:419)
>         at org.wildfly.security.manager.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
>         at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_03]
>         at org.jboss.invocation.PrivilegedInterceptor.processInvocation(PrivilegedInterceptor.java:75)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
>         at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72)
>         at com.ecolane.mpk.frontend.beans.FrontendLiaisonLocal$$$view296.synchOneCustomerToFrontend(Unknown Source) [k3-main.jar:]
>         at com.ecolane.mpk.apps.beans.ToolBackendBean.synchOneCustomerToFrontend(ToolBackendBean.java:717) [k3-main.jar:]
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_03]
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_03]
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_03]
>         at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_03]
>         at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
>         at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:130) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:138) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
>         at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
>         at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:251) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:342) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>     @PersistenceContext(unitName=K3Configuration.PERSISTENCE_CONTEXT_FRONTEND_NAME)
>     private transient EntityManager entityManager;
>                 <xa-datasource jndi-name="java:/FrontendDS" pool-name="MpkDemoUsFrontendDS" enabled="true">
>                     <xa-datasource-property name="ServerName">
>                         localhost
>                     </xa-datasource-property>
>                     <xa-datasource-property name="DatabaseName">
>                         production
>                     </xa-datasource-property>
>                     <driver>mysql</driver>
>                     <security>
>                         <user-name>frontend</user-name>
>                         <password>fghfghfghfh</password>
>                     </security>
>                 </xa-datasource>
> <?xml version="1.0" encoding="UTF-8"?>
> <persistence xmlns="http://java.sun.com/xml/ns/persistence"
>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>     xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd"
>     version="2.0">
>     <persistence-unit name="k3_frontend_persistence" transaction-type="JTA">
>         <jta-data-source>@DATASOURCE_FRONTEND@</jta-data-source>
>         <shared-cache-mode>ENABLE_SELECTIVE</shared-cache-mode>
>                 <properties>
>             <property name="hibernate.dialect" value="com.ecolane.mpk.persistence.util.Mysql5BitBooleanInnoDBDialect" />
>                         <property name="jboss.entity.manager.jndi.name" value="K3FrontendEntityManager" />
>                         <property name="jboss.entity.manager.factory.jndi.name"
>                                 value="K3FrontendEntityManagerFactory" />
>             <property name="hibernate.hbm2ddl.auto" value="validate"/>
>             
>             <!-- Infinispan conf -->
>             <property name="hibernate.cache.use_second_level_cache" value="true"/>
>             <property name="hibernate.cache.use_query_cache" value="true"/>
> <!--             <property name="hibernate.cache.region.factory_class" -->
> />
>             <property name="hibernate.cache.use_query_cache" value="true"/>
> <!--             <property name="hibernate.cache.region.factory_class" -->
> <!--                 value="org.hibernate.cache.infinispan.JndiInfinispanRegionFactory"/> -->
> <!--             <property name="hibernate.cache.region.factory_class" -->
> <!--                 value="org.hibernate.cache.infinispan.InfinispanRegionFactory"/> -->
> <!--             <property name="hibernate.cache.infinispan.cfg" value="infinispan-configs.xml" />   -->
> <!--             <property name="hibernate.cache.infinispan.cachemanager" value="java:CacheManager/entity"/> -->
>             <property name="hibernate.generate_statistics" value="true" />
> <!--             <property name="hibernate.cache.use_structured_entries" value="false" /> -->
>             <!-- property name="hibernate.cache.infinispan.statistics" value="true"/-->
> <!--             <property name="hibernate.transaction.manager_lookup_class" -->
> <!--                 value="org.hibernate.transaction.JBossTransactionManagerLookup"/> -->
>                 </properties>
>         </persistence-unit>
> </persistence>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 11:32:03 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 10 Oct 2013 11:32:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2280) Wrong XA Datasource selected
In-Reply-To: <JIRA.12502716.1381418849000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502716.1381418849000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502716.1381418849000.31889.1381419123095@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated WFLY-2280:
----------------------------------

    Assignee: Scott Marlow  (was: Jesper Pedersen)

    
> Wrong XA Datasource selected
> ----------------------------
>
>                 Key: WFLY-2280
>                 URL: https://issues.jboss.org/browse/WFLY-2280
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>         Environment: Wildfly 8, Debian Linux
>            Reporter: Matti Linnanvuori
>            Assignee: Scott Marlow
>
> A wrong XA datasource OperationalDS instead of specified FrontendDS is chosen for a database query.
> ESC[0mESC[33m10:53:47,089 WARN  [com.arjuna.ats.jta] (default task-24) ARJUNA016089: TransactionImple.enlistResource - xa_start  - caught: XAException.XAER_INVAL for < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff90cae62c:4e8567e5:5256b6f0:2894, node_name=1, branch_uid=0:ffff90cae62c:4e8567e5:5256b6f0:2899, subordinatenodename=null, eis_name=java:/OperationalDS >: com.mysql.jdbc.jdbc2.optional.MysqlXAException: XAER_INVAL: Invalid arguments (or unsupported command)
>         at com.mysql.jdbc.jdbc2.optional.MysqlXAConnection.mapXAExceptionFromSQLException(MysqlXAConnection.java:600) [mysql-connector-java-5.1.26-bin.jar:]
>         at com.mysql.jdbc.jdbc2.optional.MysqlXAConnection.dispatchCommand(MysqlXAConnection.java:583) [mysql-connector-java-5.1.26-bin.jar:]
>         at com.mysql.jdbc.jdbc2.optional.MysqlXAConnection.start(MysqlXAConnection.java:523) [mysql-connector-java-5.1.26-bin.jar:]
>         at org.jboss.jca.adapters.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:259)
>         at org.jboss.jca.core.tx.jbossts.XAResourceWrapperImpl.start(XAResourceWrapperImpl.java:191)
>         at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:715) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
>         at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:397) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
>         at org.jboss.jca.core.connectionmanager.listener.TxConnectionListener$TransactionSynchronization.enlist(TxConnectionListener.java:607)
>         at org.jboss.jca.core.connectionmanager.listener.TxConnectionListener.enlist(TxConnectionListener.java:265)
>         at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.managedConnectionReconnected(TxConnectionManagerImpl.java:467)
>         at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.reconnectManagedConnection(AbstractConnectionManager.java:599)
>         at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:467)
>         at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:139)
>         at org.hibernate.engine.jdbc.connections.internal.DatasourceConnectionProviderImpl.getConnection(DatasourceConnectionProviderImpl.java:138) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.internal.AbstractSessionImpl$NonContextualJdbcConnectionAccess.obtainConnection(AbstractSessionImpl.java:359) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.LogicalConnectionImpl.obtainConnection(LogicalConnectionImpl.java:227) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.LogicalConnectionImpl.getConnection(LogicalConnectionImpl.java:170) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.StatementPreparerImpl.connection(StatementPreparerImpl.java:63) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.StatementPreparerImpl$5.doPrepare(StatementPreparerImpl.java:164) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.StatementPreparerImpl$StatementPreparationTemplate.prepareStatement(StatementPreparerImpl.java:185) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.StatementPreparerImpl.prepareQueryStatement(StatementPreparerImpl.java:162) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1859) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1836) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1813) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.doQuery(Loader.java:895) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:340) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.doList(Loader.java:2523) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.doList(Loader.java:2509) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2339) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.list(Loader.java:2334) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:491) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:369) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:222) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1270) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.internal.QueryImpl.list(QueryImpl.java:101) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.jpa.internal.QueryImpl.getSingleResult(QueryImpl.java:381) [hibernate-entitymanager-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at com.ecolane.mpk.frontend.beans.FrontendLiaisonBean.getOurFeService(FrontendLiaisonBean.java:123) [k3-main.jar:]
>         at com.ecolane.mpk.frontend.beans.FrontendLiaisonBean.synchOneCustomerToFrontend(FrontendLiaisonBean.java:362) [k3-main.jar:]
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_03]
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_03]
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_03]
>         at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_03]
>         at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
>         at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:130) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:138) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
>         at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
>         at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:251) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:342) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:90) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:55)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
>         at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:419)
>         at org.wildfly.security.manager.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
>         at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_03]
>         at org.jboss.invocation.PrivilegedInterceptor.processInvocation(PrivilegedInterceptor.java:75)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
>         at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72)
>         at com.ecolane.mpk.frontend.beans.FrontendLiaisonLocal$$$view296.synchOneCustomerToFrontend(Unknown Source) [k3-main.jar:]
>         at com.ecolane.mpk.apps.beans.ToolBackendBean.synchOneCustomerToFrontend(ToolBackendBean.java:717) [k3-main.jar:]
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_03]
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_03]
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_03]
>         at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_03]
>         at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
>         at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:130) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:138) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
>         at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
>         at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:251) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:342) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>     @PersistenceContext(unitName=K3Configuration.PERSISTENCE_CONTEXT_FRONTEND_NAME)
>     private transient EntityManager entityManager;
>                 <xa-datasource jndi-name="java:/FrontendDS" pool-name="MpkDemoUsFrontendDS" enabled="true">
>                     <xa-datasource-property name="ServerName">
>                         localhost
>                     </xa-datasource-property>
>                     <xa-datasource-property name="DatabaseName">
>                         production
>                     </xa-datasource-property>
>                     <driver>mysql</driver>
>                     <security>
>                         <user-name>frontend</user-name>
>                         <password>fghfghfghfh</password>
>                     </security>
>                 </xa-datasource>
> <?xml version="1.0" encoding="UTF-8"?>
> <persistence xmlns="http://java.sun.com/xml/ns/persistence"
>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>     xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd"
>     version="2.0">
>     <persistence-unit name="k3_frontend_persistence" transaction-type="JTA">
>         <jta-data-source>@DATASOURCE_FRONTEND@</jta-data-source>
>         <shared-cache-mode>ENABLE_SELECTIVE</shared-cache-mode>
>                 <properties>
>             <property name="hibernate.dialect" value="com.ecolane.mpk.persistence.util.Mysql5BitBooleanInnoDBDialect" />
>                         <property name="jboss.entity.manager.jndi.name" value="K3FrontendEntityManager" />
>                         <property name="jboss.entity.manager.factory.jndi.name"
>                                 value="K3FrontendEntityManagerFactory" />
>             <property name="hibernate.hbm2ddl.auto" value="validate"/>
>             
>             <!-- Infinispan conf -->
>             <property name="hibernate.cache.use_second_level_cache" value="true"/>
>             <property name="hibernate.cache.use_query_cache" value="true"/>
> <!--             <property name="hibernate.cache.region.factory_class" -->
> />
>             <property name="hibernate.cache.use_query_cache" value="true"/>
> <!--             <property name="hibernate.cache.region.factory_class" -->
> <!--                 value="org.hibernate.cache.infinispan.JndiInfinispanRegionFactory"/> -->
> <!--             <property name="hibernate.cache.region.factory_class" -->
> <!--                 value="org.hibernate.cache.infinispan.InfinispanRegionFactory"/> -->
> <!--             <property name="hibernate.cache.infinispan.cfg" value="infinispan-configs.xml" />   -->
> <!--             <property name="hibernate.cache.infinispan.cachemanager" value="java:CacheManager/entity"/> -->
>             <property name="hibernate.generate_statistics" value="true" />
> <!--             <property name="hibernate.cache.use_structured_entries" value="false" /> -->
>             <!-- property name="hibernate.cache.infinispan.statistics" value="true"/-->
> <!--             <property name="hibernate.transaction.manager_lookup_class" -->
> <!--                 value="org.hibernate.transaction.JBossTransactionManagerLookup"/> -->
>                 </properties>
>         </persistence-unit>
> </persistence>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 11:38:02 2013
From: jira-events at lists.jboss.org (Aleksandar Kostadinov (JIRA))
Date: Thu, 10 Oct 2013 11:38:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1190) Add EC2-specific config files
 to standalone/configuration/
In-Reply-To: <JIRA.12469893.1341418125000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12469893.1341418125000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12469893.1341418125000.31910.1381419482773@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813190#comment-12813190 ] 

Aleksandar Kostadinov commented on WFLY-1190:
---------------------------------------------

FYI we got standalone-gossip-ha*.xml and standalone-ec2-ha*.xml in wildfly.

Next step would be CI of said configuration files. And also mod_cluster counterparts of these configuration files. But for the latter undertow needs to be made workie with mod_cluster.

Farah, I already have a jenkins job that runs integration tests against gossip and ec2 configs. Would be nice if we can chat about what would be a good approach to involve wildfly team.
                
> Add EC2-specific config files to standalone/configuration/
> ----------------------------------------------------------
>
>                 Key: WFLY-1190
>                 URL: https://issues.jboss.org/browse/WFLY-1190
>             Project: WildFly
>          Issue Type: Feature Request
>            Reporter: Ondrej Zizka
>            Assignee: Farah Juma
>
> EC2 needs specific AS config (disabled JMS, disabled UDP, ...)
> These config files should be right in distro to make it easier for the user to use.
> EC2's EAP AMI might use it as well.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 12:08:02 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Thu, 10 Oct 2013 12:08:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2246) Weld subsystem transformers
	for 7.2.0
In-Reply-To: <JIRA.12502332.1381146729000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502332.1381146729000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502332.1381146729000.31993.1381421282671@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan reassigned WFLY-2246:
--------------------------------

    Assignee: Kabir Khan  (was: Stuart Douglas)

    
> Weld subsystem transformers for 7.2.0
> -------------------------------------
>
>                 Key: WFLY-2246
>                 URL: https://issues.jboss.org/browse/WFLY-2246
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: CDI / Weld
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 13:51:03 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Thu, 10 Oct 2013 13:51:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2280) Wrong XA Datasource selected
In-Reply-To: <JIRA.12502716.1381418849000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502716.1381418849000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502716.1381418849000.32203.1381427462998@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813239#comment-12813239 ] 

Scott Marlow commented on WFLY-2280:
------------------------------------

looks like you included a persistence.xml that isn't being used.  Enable TRACE logging for org.jboss.as.jpa and you should get enough information from that.  Jira is for reporting bugs, not asking for help.  Please ask questions in our forums instead, where other users can see the question.

See https://docs.jboss.org/author/display/WFLY8/JPA+Reference+Guide#JPAReferenceGuide-Troubleshooting for how to enable trace logging.

See https://community.jboss.org/discussion/create.jspa?containerType=14&containerID=2303 for asking questions.

If there is a bug in WildFly 8 (with the wrong datasource being used), you can reopen this jira.  

                
> Wrong XA Datasource selected
> ----------------------------
>
>                 Key: WFLY-2280
>                 URL: https://issues.jboss.org/browse/WFLY-2280
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>         Environment: Wildfly 8, Debian Linux
>            Reporter: Matti Linnanvuori
>            Assignee: Scott Marlow
>
> A wrong XA datasource OperationalDS instead of specified FrontendDS is chosen for a database query.
> ESC[0mESC[33m10:53:47,089 WARN  [com.arjuna.ats.jta] (default task-24) ARJUNA016089: TransactionImple.enlistResource - xa_start  - caught: XAException.XAER_INVAL for < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff90cae62c:4e8567e5:5256b6f0:2894, node_name=1, branch_uid=0:ffff90cae62c:4e8567e5:5256b6f0:2899, subordinatenodename=null, eis_name=java:/OperationalDS >: com.mysql.jdbc.jdbc2.optional.MysqlXAException: XAER_INVAL: Invalid arguments (or unsupported command)
>         at com.mysql.jdbc.jdbc2.optional.MysqlXAConnection.mapXAExceptionFromSQLException(MysqlXAConnection.java:600) [mysql-connector-java-5.1.26-bin.jar:]
>         at com.mysql.jdbc.jdbc2.optional.MysqlXAConnection.dispatchCommand(MysqlXAConnection.java:583) [mysql-connector-java-5.1.26-bin.jar:]
>         at com.mysql.jdbc.jdbc2.optional.MysqlXAConnection.start(MysqlXAConnection.java:523) [mysql-connector-java-5.1.26-bin.jar:]
>         at org.jboss.jca.adapters.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:259)
>         at org.jboss.jca.core.tx.jbossts.XAResourceWrapperImpl.start(XAResourceWrapperImpl.java:191)
>         at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:715) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
>         at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:397) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
>         at org.jboss.jca.core.connectionmanager.listener.TxConnectionListener$TransactionSynchronization.enlist(TxConnectionListener.java:607)
>         at org.jboss.jca.core.connectionmanager.listener.TxConnectionListener.enlist(TxConnectionListener.java:265)
>         at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.managedConnectionReconnected(TxConnectionManagerImpl.java:467)
>         at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.reconnectManagedConnection(AbstractConnectionManager.java:599)
>         at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:467)
>         at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:139)
>         at org.hibernate.engine.jdbc.connections.internal.DatasourceConnectionProviderImpl.getConnection(DatasourceConnectionProviderImpl.java:138) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.internal.AbstractSessionImpl$NonContextualJdbcConnectionAccess.obtainConnection(AbstractSessionImpl.java:359) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.LogicalConnectionImpl.obtainConnection(LogicalConnectionImpl.java:227) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.LogicalConnectionImpl.getConnection(LogicalConnectionImpl.java:170) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.StatementPreparerImpl.connection(StatementPreparerImpl.java:63) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.StatementPreparerImpl$5.doPrepare(StatementPreparerImpl.java:164) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.StatementPreparerImpl$StatementPreparationTemplate.prepareStatement(StatementPreparerImpl.java:185) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.StatementPreparerImpl.prepareQueryStatement(StatementPreparerImpl.java:162) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1859) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1836) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1813) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.doQuery(Loader.java:895) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:340) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.doList(Loader.java:2523) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.doList(Loader.java:2509) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2339) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.list(Loader.java:2334) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:491) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:369) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:222) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1270) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.internal.QueryImpl.list(QueryImpl.java:101) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.jpa.internal.QueryImpl.getSingleResult(QueryImpl.java:381) [hibernate-entitymanager-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at com.ecolane.mpk.frontend.beans.FrontendLiaisonBean.getOurFeService(FrontendLiaisonBean.java:123) [k3-main.jar:]
>         at com.ecolane.mpk.frontend.beans.FrontendLiaisonBean.synchOneCustomerToFrontend(FrontendLiaisonBean.java:362) [k3-main.jar:]
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_03]
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_03]
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_03]
>         at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_03]
>         at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
>         at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:130) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:138) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
>         at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
>         at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:251) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:342) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:90) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:55)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
>         at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:419)
>         at org.wildfly.security.manager.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
>         at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_03]
>         at org.jboss.invocation.PrivilegedInterceptor.processInvocation(PrivilegedInterceptor.java:75)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
>         at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72)
>         at com.ecolane.mpk.frontend.beans.FrontendLiaisonLocal$$$view296.synchOneCustomerToFrontend(Unknown Source) [k3-main.jar:]
>         at com.ecolane.mpk.apps.beans.ToolBackendBean.synchOneCustomerToFrontend(ToolBackendBean.java:717) [k3-main.jar:]
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_03]
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_03]
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_03]
>         at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_03]
>         at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
>         at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:130) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:138) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
>         at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
>         at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:251) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:342) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>     @PersistenceContext(unitName=K3Configuration.PERSISTENCE_CONTEXT_FRONTEND_NAME)
>     private transient EntityManager entityManager;
>                 <xa-datasource jndi-name="java:/FrontendDS" pool-name="MpkDemoUsFrontendDS" enabled="true">
>                     <xa-datasource-property name="ServerName">
>                         localhost
>                     </xa-datasource-property>
>                     <xa-datasource-property name="DatabaseName">
>                         production
>                     </xa-datasource-property>
>                     <driver>mysql</driver>
>                     <security>
>                         <user-name>frontend</user-name>
>                         <password>fghfghfghfh</password>
>                     </security>
>                 </xa-datasource>
> <?xml version="1.0" encoding="UTF-8"?>
> <persistence xmlns="http://java.sun.com/xml/ns/persistence"
>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>     xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd"
>     version="2.0">
>     <persistence-unit name="k3_frontend_persistence" transaction-type="JTA">
>         <jta-data-source>@DATASOURCE_FRONTEND@</jta-data-source>
>         <shared-cache-mode>ENABLE_SELECTIVE</shared-cache-mode>
>                 <properties>
>             <property name="hibernate.dialect" value="com.ecolane.mpk.persistence.util.Mysql5BitBooleanInnoDBDialect" />
>                         <property name="jboss.entity.manager.jndi.name" value="K3FrontendEntityManager" />
>                         <property name="jboss.entity.manager.factory.jndi.name"
>                                 value="K3FrontendEntityManagerFactory" />
>             <property name="hibernate.hbm2ddl.auto" value="validate"/>
>             
>             <!-- Infinispan conf -->
>             <property name="hibernate.cache.use_second_level_cache" value="true"/>
>             <property name="hibernate.cache.use_query_cache" value="true"/>
> <!--             <property name="hibernate.cache.region.factory_class" -->
> />
>             <property name="hibernate.cache.use_query_cache" value="true"/>
> <!--             <property name="hibernate.cache.region.factory_class" -->
> <!--                 value="org.hibernate.cache.infinispan.JndiInfinispanRegionFactory"/> -->
> <!--             <property name="hibernate.cache.region.factory_class" -->
> <!--                 value="org.hibernate.cache.infinispan.InfinispanRegionFactory"/> -->
> <!--             <property name="hibernate.cache.infinispan.cfg" value="infinispan-configs.xml" />   -->
> <!--             <property name="hibernate.cache.infinispan.cachemanager" value="java:CacheManager/entity"/> -->
>             <property name="hibernate.generate_statistics" value="true" />
> <!--             <property name="hibernate.cache.use_structured_entries" value="false" /> -->
>             <!-- property name="hibernate.cache.infinispan.statistics" value="true"/-->
> <!--             <property name="hibernate.transaction.manager_lookup_class" -->
> <!--                 value="org.hibernate.transaction.JBossTransactionManagerLookup"/> -->
>                 </properties>
>         </persistence-unit>
> </persistence>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 13:51:03 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Thu, 10 Oct 2013 13:51:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2280) Wrong XA Datasource selected
In-Reply-To: <JIRA.12502716.1381418849000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502716.1381418849000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502716.1381418849000.32207.1381427463242@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow resolved WFLY-2280.
--------------------------------

    Resolution: Rejected

    
> Wrong XA Datasource selected
> ----------------------------
>
>                 Key: WFLY-2280
>                 URL: https://issues.jboss.org/browse/WFLY-2280
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>         Environment: Wildfly 8, Debian Linux
>            Reporter: Matti Linnanvuori
>            Assignee: Scott Marlow
>
> A wrong XA datasource OperationalDS instead of specified FrontendDS is chosen for a database query.
> ESC[0mESC[33m10:53:47,089 WARN  [com.arjuna.ats.jta] (default task-24) ARJUNA016089: TransactionImple.enlistResource - xa_start  - caught: XAException.XAER_INVAL for < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff90cae62c:4e8567e5:5256b6f0:2894, node_name=1, branch_uid=0:ffff90cae62c:4e8567e5:5256b6f0:2899, subordinatenodename=null, eis_name=java:/OperationalDS >: com.mysql.jdbc.jdbc2.optional.MysqlXAException: XAER_INVAL: Invalid arguments (or unsupported command)
>         at com.mysql.jdbc.jdbc2.optional.MysqlXAConnection.mapXAExceptionFromSQLException(MysqlXAConnection.java:600) [mysql-connector-java-5.1.26-bin.jar:]
>         at com.mysql.jdbc.jdbc2.optional.MysqlXAConnection.dispatchCommand(MysqlXAConnection.java:583) [mysql-connector-java-5.1.26-bin.jar:]
>         at com.mysql.jdbc.jdbc2.optional.MysqlXAConnection.start(MysqlXAConnection.java:523) [mysql-connector-java-5.1.26-bin.jar:]
>         at org.jboss.jca.adapters.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:259)
>         at org.jboss.jca.core.tx.jbossts.XAResourceWrapperImpl.start(XAResourceWrapperImpl.java:191)
>         at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:715) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
>         at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:397) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
>         at org.jboss.jca.core.connectionmanager.listener.TxConnectionListener$TransactionSynchronization.enlist(TxConnectionListener.java:607)
>         at org.jboss.jca.core.connectionmanager.listener.TxConnectionListener.enlist(TxConnectionListener.java:265)
>         at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.managedConnectionReconnected(TxConnectionManagerImpl.java:467)
>         at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.reconnectManagedConnection(AbstractConnectionManager.java:599)
>         at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:467)
>         at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:139)
>         at org.hibernate.engine.jdbc.connections.internal.DatasourceConnectionProviderImpl.getConnection(DatasourceConnectionProviderImpl.java:138) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.internal.AbstractSessionImpl$NonContextualJdbcConnectionAccess.obtainConnection(AbstractSessionImpl.java:359) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.LogicalConnectionImpl.obtainConnection(LogicalConnectionImpl.java:227) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.LogicalConnectionImpl.getConnection(LogicalConnectionImpl.java:170) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.StatementPreparerImpl.connection(StatementPreparerImpl.java:63) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.StatementPreparerImpl$5.doPrepare(StatementPreparerImpl.java:164) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.StatementPreparerImpl$StatementPreparationTemplate.prepareStatement(StatementPreparerImpl.java:185) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.StatementPreparerImpl.prepareQueryStatement(StatementPreparerImpl.java:162) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1859) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1836) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1813) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.doQuery(Loader.java:895) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:340) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.doList(Loader.java:2523) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.doList(Loader.java:2509) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2339) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.list(Loader.java:2334) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:491) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:369) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:222) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1270) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.internal.QueryImpl.list(QueryImpl.java:101) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.jpa.internal.QueryImpl.getSingleResult(QueryImpl.java:381) [hibernate-entitymanager-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at com.ecolane.mpk.frontend.beans.FrontendLiaisonBean.getOurFeService(FrontendLiaisonBean.java:123) [k3-main.jar:]
>         at com.ecolane.mpk.frontend.beans.FrontendLiaisonBean.synchOneCustomerToFrontend(FrontendLiaisonBean.java:362) [k3-main.jar:]
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_03]
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_03]
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_03]
>         at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_03]
>         at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
>         at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:130) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:138) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
>         at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
>         at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:251) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:342) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:90) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:55)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
>         at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:419)
>         at org.wildfly.security.manager.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
>         at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_03]
>         at org.jboss.invocation.PrivilegedInterceptor.processInvocation(PrivilegedInterceptor.java:75)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
>         at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72)
>         at com.ecolane.mpk.frontend.beans.FrontendLiaisonLocal$$$view296.synchOneCustomerToFrontend(Unknown Source) [k3-main.jar:]
>         at com.ecolane.mpk.apps.beans.ToolBackendBean.synchOneCustomerToFrontend(ToolBackendBean.java:717) [k3-main.jar:]
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_03]
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_03]
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_03]
>         at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_03]
>         at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
>         at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:130) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:138) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
>         at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
>         at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:251) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:342) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>     @PersistenceContext(unitName=K3Configuration.PERSISTENCE_CONTEXT_FRONTEND_NAME)
>     private transient EntityManager entityManager;
>                 <xa-datasource jndi-name="java:/FrontendDS" pool-name="MpkDemoUsFrontendDS" enabled="true">
>                     <xa-datasource-property name="ServerName">
>                         localhost
>                     </xa-datasource-property>
>                     <xa-datasource-property name="DatabaseName">
>                         production
>                     </xa-datasource-property>
>                     <driver>mysql</driver>
>                     <security>
>                         <user-name>frontend</user-name>
>                         <password>fghfghfghfh</password>
>                     </security>
>                 </xa-datasource>
> <?xml version="1.0" encoding="UTF-8"?>
> <persistence xmlns="http://java.sun.com/xml/ns/persistence"
>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>     xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd"
>     version="2.0">
>     <persistence-unit name="k3_frontend_persistence" transaction-type="JTA">
>         <jta-data-source>@DATASOURCE_FRONTEND@</jta-data-source>
>         <shared-cache-mode>ENABLE_SELECTIVE</shared-cache-mode>
>                 <properties>
>             <property name="hibernate.dialect" value="com.ecolane.mpk.persistence.util.Mysql5BitBooleanInnoDBDialect" />
>                         <property name="jboss.entity.manager.jndi.name" value="K3FrontendEntityManager" />
>                         <property name="jboss.entity.manager.factory.jndi.name"
>                                 value="K3FrontendEntityManagerFactory" />
>             <property name="hibernate.hbm2ddl.auto" value="validate"/>
>             
>             <!-- Infinispan conf -->
>             <property name="hibernate.cache.use_second_level_cache" value="true"/>
>             <property name="hibernate.cache.use_query_cache" value="true"/>
> <!--             <property name="hibernate.cache.region.factory_class" -->
> />
>             <property name="hibernate.cache.use_query_cache" value="true"/>
> <!--             <property name="hibernate.cache.region.factory_class" -->
> <!--                 value="org.hibernate.cache.infinispan.JndiInfinispanRegionFactory"/> -->
> <!--             <property name="hibernate.cache.region.factory_class" -->
> <!--                 value="org.hibernate.cache.infinispan.InfinispanRegionFactory"/> -->
> <!--             <property name="hibernate.cache.infinispan.cfg" value="infinispan-configs.xml" />   -->
> <!--             <property name="hibernate.cache.infinispan.cachemanager" value="java:CacheManager/entity"/> -->
>             <property name="hibernate.generate_statistics" value="true" />
> <!--             <property name="hibernate.cache.use_structured_entries" value="false" /> -->
>             <!-- property name="hibernate.cache.infinispan.statistics" value="true"/-->
> <!--             <property name="hibernate.transaction.manager_lookup_class" -->
> <!--                 value="org.hibernate.transaction.JBossTransactionManagerLookup"/> -->
>                 </properties>
>         </persistence-unit>
> </persistence>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 13:56:02 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Thu, 10 Oct 2013 13:56:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2277) application client jars in
 ear should be able to have persistence units deployed
In-Reply-To: <JIRA.12502689.1381409863000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502689.1381409863000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502689.1381409863000.32214.1381427762547@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow updated WFLY-2277:
-------------------------------

    Comment: was deleted

(was: WFLY-2151 caused this to stop working (I'd link these issues but I can't link from firefox anymore))

    
> application client jars in ear should be able to have persistence units deployed
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-2277
>                 URL: https://issues.jboss.org/browse/WFLY-2277
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 13:58:02 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Thu, 10 Oct 2013 13:58:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2277) application client jars in
 ear should be able to have persistence units deployed
In-Reply-To: <JIRA.12502689.1381409863000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502689.1381409863000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502689.1381409863000.32222.1381427882868@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813242#comment-12813242 ] 

Scott Marlow commented on WFLY-2277:
------------------------------------

The WFLY-2151 change is ignoring ear lib ejb jars in the client container and that is wrong.  

{quote}
>From EE.8.2.1 Bundled Libraries

2. A .ear file may contain a directory that contains libraries packaged in JAR files. The library-directory element of the .ear file?s deployment descriptor contains the name of this directory. If a library-directory element isn?t specified, or if the .ear file does not contain a deployment descriptor, the directory named lib is used. An empty library-directory element may be used to specify that there is no library directory.  All files in this directory (but not subdirectories) with a .jar extension must be made available to all components packaged in the EAR file, including application clients.
...
{quote}

                
> application client jars in ear should be able to have persistence units deployed
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-2277
>                 URL: https://issues.jboss.org/browse/WFLY-2277
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Thu Oct 10 14:21:02 2013
From: jira-events at lists.jboss.org (Patson Luk (JIRA))
Date: Thu, 10 Oct 2013 14:21:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-210) MethodCall.replace() throws
 inconsistent stack height in certain scenarios
In-Reply-To: <JIRA.12502614.1381349908000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502614.1381349908000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502614.1381349908000.32241.1381429262567@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JASSIST-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Patson Luk updated JASSIST-210:
-------------------------------

    Affects Version/s: 3.18.1-GA
                       3.16.1-GA

    
> MethodCall.replace() throws inconsistent stack height in certain scenarios
> --------------------------------------------------------------------------
>
>                 Key: JASSIST-210
>                 URL: https://issues.jboss.org/browse/JASSIST-210
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.16.1-GA, 3.18.1-GA
>            Reporter: Patson Luk
>            Assignee: Shigeru Chiba
>
> Tested on 3.16.1-GA
> This is similar to https://issues.jboss.org/browse/JASSIST-52, but the try-catch block usage is different (not wrapping the $proceed($$))
> Based on the javassist tutorial,  the substituted code for MethodCall.replace():
> {{Note that the substituted code is not an expression but a statement or a block. It cannot be or contain a try-catch statement.}}
> However in the case that try-catch does not wrap the $_=$proceed($$);
> It seems to work properly. For example:
> ctClass.instrument(new ExprEditor() {
>     public void edit(MethodCall m) throws CannotCompileException {
>         if (m.getMethodName().equals("testMethod2")) {
>             String newBlock = "{ try { System.out.println(\"injected\"); } catch (Exception e) { e.printStackTrace(); } $_ = $proceed($$); }";
>             m.replace(newBlock);
>         }
>     }
> });
> {{which ctClass is class TestReplace, which has code as below:}}
> public class TestReplace {
>     public static void main(String[] args) {
>         RefClass ref = new RefClass();
>         ref.testMethod2();
>     }
> }
> class RefClass {
>     public void testMethod1(Object o) {}
>     public Object testMethod2() { return null; }
> }
> {{running TestReplace with the modified bytecode correctly prints "injected" to the screen. However if I add one more line to the TestReplace's main() method}}
> ref.testMethod1(ref.testMethod2());
> {{It throws exception as below}}
> javassist.bytecode.BadBytecode: inconsistent stack height -1
> javassist.bytecode.stackmap.Tracer.doOpcode(Tracer.java:106)
> *So is try-catch acceptable if it does not wrap the $_=$proceed($$)? If so, is it a bug if it does not work properly for method invocation within another method invocation?*
> Many thanks in advance!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 14:23:02 2013
From: jira-events at lists.jboss.org (Patson Luk (JIRA))
Date: Thu, 10 Oct 2013 14:23:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-210) MethodCall.replace() throws
 inconsistent stack height in certain scenarios
In-Reply-To: <JIRA.12502614.1381349908000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502614.1381349908000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502614.1381349908000.32245.1381429382626@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JASSIST-210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813246#comment-12813246 ] 

Patson Luk commented on JASSIST-210:
------------------------------------

Tested on 3.18.1-GA too. Same exception was observed thanks
                
> MethodCall.replace() throws inconsistent stack height in certain scenarios
> --------------------------------------------------------------------------
>
>                 Key: JASSIST-210
>                 URL: https://issues.jboss.org/browse/JASSIST-210
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.16.1-GA, 3.18.1-GA
>            Reporter: Patson Luk
>            Assignee: Shigeru Chiba
>
> Tested on 3.16.1-GA
> This is similar to https://issues.jboss.org/browse/JASSIST-52, but the try-catch block usage is different (not wrapping the $proceed($$))
> Based on the javassist tutorial,  the substituted code for MethodCall.replace():
> {{Note that the substituted code is not an expression but a statement or a block. It cannot be or contain a try-catch statement.}}
> However in the case that try-catch does not wrap the $_=$proceed($$);
> It seems to work properly. For example:
> ctClass.instrument(new ExprEditor() {
>     public void edit(MethodCall m) throws CannotCompileException {
>         if (m.getMethodName().equals("testMethod2")) {
>             String newBlock = "{ try { System.out.println(\"injected\"); } catch (Exception e) { e.printStackTrace(); } $_ = $proceed($$); }";
>             m.replace(newBlock);
>         }
>     }
> });
> {{which ctClass is class TestReplace, which has code as below:}}
> public class TestReplace {
>     public static void main(String[] args) {
>         RefClass ref = new RefClass();
>         ref.testMethod2();
>     }
> }
> class RefClass {
>     public void testMethod1(Object o) {}
>     public Object testMethod2() { return null; }
> }
> {{running TestReplace with the modified bytecode correctly prints "injected" to the screen. However if I add one more line to the TestReplace's main() method}}
> ref.testMethod1(ref.testMethod2());
> {{It throws exception as below}}
> javassist.bytecode.BadBytecode: inconsistent stack height -1
> javassist.bytecode.stackmap.Tracer.doOpcode(Tracer.java:106)
> *So is try-catch acceptable if it does not wrap the $_=$proceed($$)? If so, is it a bug if it does not work properly for method invocation within another method invocation?*
> Many thanks in advance!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 14:32:02 2013
From: jira-events at lists.jboss.org (Matus Abaffy (JIRA))
Date: Thu, 10 Oct 2013 14:32:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2281) Exception from lifecycle
 callback interceptor method intercepting a session bean gets suppressed
 without log message
In-Reply-To: <JIRA.12502724.1381429906497@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502724.1381429906497@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502724.1381429906497.32252.1381429922620@jira02.app.mwc.hst.phx2.redhat.com>

Matus Abaffy created WFLY-2281:
----------------------------------

             Summary: Exception from lifecycle callback interceptor method intercepting a session bean gets suppressed without log message
                 Key: WFLY-2281
                 URL: https://issues.jboss.org/browse/WFLY-2281
             Project: WildFly
          Issue Type: Bug
          Components: CDI / Weld, EJB
    Affects Versions: 8.0.0.Beta1
            Reporter: Matus Abaffy
            Assignee: Stuart Douglas


>From EJB spec., "9.3.3 Exceptions from AroundConstruct, PostConstruct and PreDestroy Lifecycle Callbacks", "Table 11" it follows that the container should log the exception or error thrown by a lifecycle callback interceptor method of a session bean or a message-driven bean.

The thrown throwable gets suppressed. However, I cannot find any sign of it in the server log (using default settings - debug level).

I'm not a spec. expert, but I think if the exception is not logged, it should at least not get suppressed. I made some tests that might be of help (available at https://github.com/bafco/wildfly/commits/WFLY-2281) - according to the spec., they probably don't have to pass.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 15:31:02 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 10 Oct 2013 15:31:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1092) Naming checks for
 AdminObject are too strict
In-Reply-To: <JIRA.12502731.1381433342452@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502731.1381433342452@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502731.1381433342452.32297.1381433462583@jira02.app.mwc.hst.phx2.redhat.com>

Jesper Pedersen created JBJCA-1092:
--------------------------------------

             Summary: Naming checks for AdminObject are too strict
                 Key: JBJCA-1092
                 URL: https://issues.jboss.org/browse/JBJCA-1092
             Project: IronJacamar
          Issue Type: Bug
          Components: Deployer
    Affects Versions: 1.1.0.Final, 1.0.21.Final
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
            Priority: Critical
             Fix For: 1.0.22.Final, 1.1.1.Final


Plain AdminObjects that doesn't implement the standard naming contracts won't be bound in JNDI

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 15:35:02 2013
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Thu, 10 Oct 2013 15:35:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-835) @Resource UserTransaction
 error when file passivation store is selected
In-Reply-To: <JIRA.12486327.1362495445000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12486327.1362495445000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12486327.1362495445000.32312.1381433702774@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813255#comment-12813255 ] 

Paul Ferraro commented on WFLY-835:
-----------------------------------

This is still a problem in master.
                
> @Resource UserTransaction error when file passivation store is selected
> -----------------------------------------------------------------------
>
>                 Key: WFLY-835
>                 URL: https://issues.jboss.org/browse/WFLY-835
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>         Environment: Ubuntu 11.10, Intel? Core? i3-2120 CPU @ 3.30GHz ? 4 
>            Reporter: Abraham Cabanillas Piera
>            Assignee: jaikiran pai
>            Priority: Critical
>              Labels: jboss
>
> The following exception is launched when the server tries to passivate into the file passivation storage a stateful EJB session with UserTransaction injected as a resource:
> {noformat}
> [org.jboss.as.ejb3.cache.spi.impl.PassivateTask] (pool-10-thread-1) JBAS014538: Failed to passivate {[-36, 0, 14, -43, 72, 10, 76, -28, -105, -108, 24, 45, -70, -58, -48, -107]}: java.lang.RuntimeException: JBAS014538: Failed to passivate {[-36, 0, 14, -43, 72, 10, 76, -28, -105, -108, 24, 45, -70, -58, -48, -107]}
> 	at org.jboss.as.ejb3.cache.spi.impl.FilePersistentObjectStore.store(FilePersistentObjectStore.java:248) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	at org.jboss.as.ejb3.cache.spi.impl.FilePersistentObjectStore.store(FilePersistentObjectStore.java:52) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	at org.jboss.as.ejb3.cache.impl.backing.SimpleBackingCacheEntryStore.passivate(SimpleBackingCacheEntryStore.java:155) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberContainer.passivate(SerializationGroupMemberContainer.java:288) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberContainer.passivate(SerializationGroupMemberContainer.java:50) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	at org.jboss.as.ejb3.cache.impl.backing.PassivatingBackingCacheImpl.passivate(PassivatingBackingCacheImpl.java:190) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	at org.jboss.as.ejb3.cache.impl.backing.PassivatingBackingCacheImpl.passivate(PassivatingBackingCacheImpl.java:60) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	at org.jboss.as.ejb3.cache.spi.impl.PassivateTask.run(PassivateTask.java:45) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_13]
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_13]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_13]
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) [rt.jar:1.7.0_13]
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) [rt.jar:1.7.0_13]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_13]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_13]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_13]
> Caused by: java.io.NotSerializableException: org.jboss.tm.usertx.client.ServerVMClientUserTransaction
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:891)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> 	at org.jboss.marshalling.river.BlockMarshaller.doWriteObject(BlockMarshaller.java:69)
> 	at org.jboss.marshalling.river.BlockMarshaller.writeObject(BlockMarshaller.java:60)
> 	at org.jboss.marshalling.MarshallerObjectOutputStream.writeObjectOverride(MarshallerObjectOutputStream.java:54)
> 	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:342) [rt.jar:1.7.0_13]
> 	at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberImpl.writeObject(SerializationGroupMemberImpl.java:368) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_13]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_13]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_13]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_13]
> 	at org.jboss.marshalling.reflect.SerializableClass.callWriteObject(SerializableClass.java:175)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1007)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> 	at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62)
> 	at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119)
> 	at org.jboss.as.ejb3.cache.spi.impl.FilePersistentObjectStore.store(FilePersistentObjectStore.java:239) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	... 15 more
> Caused by: an exception which occurred:
> 	in field userTransaction
> 	in field instance
> 	in field instance
> 	in object org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberImpl at 6a4de0c9
> {noformat}
> The EJB subsystem configuration is:
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:ejb3:1.2">
>             <session-bean>
>                 <stateless>
>                     <bean-instance-pool-ref pool-name="slsb-strict-max-pool"/>
>                 </stateless>
>                 <stateful default-access-timeout="10000" cache-ref="passivating"/>
>                 <singleton default-access-timeout="5000"/>
>             </session-bean>
>             <mdb>
>                 <resource-adapter-ref resource-adapter-name="hornetq-ra"/>
>                 <bean-instance-pool-ref pool-name="mdb-strict-max-pool"/>
>             </mdb>
>             <pools>
>                 <bean-instance-pools>
>                     <strict-max-pool name="slsb-strict-max-pool" max-pool-size="50" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
>                     <strict-max-pool name="mdb-strict-max-pool" max-pool-size="20" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
>                 </bean-instance-pools>
>             </pools>
>             <caches>
>                 <cache name="simple" aliases="NoPassivationCache"/>
>                 <cache name="passivating" passivation-store-ref="file" aliases="SimpleStatefulCache"/>
>             </caches>
>             <passivation-stores>
>                 <file-passivation-store name="file" idle-timeout="10" idle-timeout-unit="SECONDS"/>
>             </passivation-stores>
>             <async thread-pool-name="default"/>
>             <timer-service thread-pool-name="default">
>                 <data-store path="timer-service-data" relative-to="jboss.server.data.dir"/>
>             </timer-service>
>             <remote connector-ref="remoting-connector" thread-pool-name="default"/>
>             <thread-pools>
>                 <thread-pool name="default">
>                     <max-threads count="100"/>
>                     <keepalive-time time="100" unit="milliseconds"/>
>                 </thread-pool>
>             </thread-pools>
>             <iiop enable-by-default="false" use-qualified-name="false"/>
>         </subsystem>
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Thu Oct 10 15:40:02 2013
From: jira-events at lists.jboss.org (alexandre xypas (JIRA))
Date: Thu, 10 Oct 2013 15:40:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2276) URI ENCODING does not work in
 the beta1 version (UTF-8)
In-Reply-To: <JIRA.12502684.1381404449000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502684.1381404449000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502684.1381404449000.32325.1381434002494@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813257#comment-12813257 ] 

alexandre xypas commented on WFLY-2276:
---------------------------------------

I am using the <system-properties> as explained in the following link:

http://stackoverflow.com/questions/10226018/jboss-encoding-utf-8
https://community.jboss.org/thread/172379?start=0&tstart=0

It used to work in Alpha4, is there a new way of encoding?
                
> URI ENCODING does not work in the beta1 version (UTF-8)
> -------------------------------------------------------
>
>                 Key: WFLY-2276
>                 URL: https://issues.jboss.org/browse/WFLY-2276
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (JBoss Web)
>    Affects Versions: 8.0.0.Beta1
>         Environment: Java 7, ubuntu 12.04
>            Reporter: alexandre xypas
>              Labels: encoding, utf-8
>
> In standalone.xml, the following is working in Alpha4, but not anymore in Beta1.
> <property name="org.apache.catalina.connector.URI_ENCODING" value="UTF-8"/>
> <property name="org.apache.catalina.connector.USE_BODY_ENCODING_FOR_QUERY_STRING" value="true"/>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 15:53:02 2013
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Thu, 10 Oct 2013 15:53:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2282) SFSB serialization fails if
 containing EntityManager or EntityManagerFactory field w/2LC enabled
In-Reply-To: <JIRA.12502735.1381434775343@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502735.1381434775343@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502735.1381434775343.32332.1381434782609@jira02.app.mwc.hst.phx2.redhat.com>

Paul Ferraro created WFLY-2282:
----------------------------------

             Summary: SFSB serialization fails if containing EntityManager or EntityManagerFactory field w/2LC enabled
                 Key: WFLY-2282
                 URL: https://issues.jboss.org/browse/WFLY-2282
             Project: WildFly
          Issue Type: Bug
          Components: JPA / Hibernate
    Affects Versions: 8.0.0.Beta1
            Reporter: Paul Ferraro
            Assignee: Scott Marlow


2013-10-10 15:03:46,636 WARN  [org.infinispan.factories.ComponentRegistry] (MSC service thread 1-3) ISPN000189: While stopping a cache or cache manager, one of its components failed to stop: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.eviction.PassivationManagerImpl.passivateAll() throws org.infinispan.persistence.CacheLoaderException on object of type PassivationManagerImpl
        at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:185)
        at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
        at org.infinispan.factories.AbstractComponentRegistry.internalStop(AbstractComponentRegistry.java:674)
        at org.infinispan.factories.AbstractComponentRegistry.stop(AbstractComponentRegistry.java:552)
        at org.infinispan.factories.ComponentRegistry.stop(ComponentRegistry.java:241)
        at org.infinispan.CacheImpl.stop(CacheImpl.java:690)
        at org.infinispan.CacheImpl.stop(CacheImpl.java:685)
        at org.infinispan.AbstractDelegatingCache.stop(AbstractDelegatingCache.java:316)
        at org.jboss.as.clustering.infinispan.subsystem.CacheService.stop(CacheService.java:96)
        at org.jboss.as.clustering.msc.AsynchronousService.stop(AsynchronousService.java:114) [wildfly-clustering-common-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
        at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2052) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
        at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2013) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
        at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
Caused by: org.infinispan.persistence.CacheLoaderException: org.infinispan.persistence.CacheLoaderException: org.infinispan.commons.marshall.NotSerializableException: org.jboss.as.clustering.infinispan.DefaultCacheContainer
        at org.infinispan.persistence.file.SingleFileStore.write(SingleFileStore.java:297)
        at org.infinispan.persistence.manager.PersistenceManagerImpl.writeToAllStores(PersistenceManagerImpl.java:430)
        at org.infinispan.eviction.PassivationManagerImpl.passivateAll(PassivationManagerImpl.java:98)
        at sun.reflect.GeneratedMethodAccessor152.invoke(Unknown Source) [:1.7.0_25]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_25]
        at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_25]
        at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:183)
        ... 14 more
Caused by: org.infinispan.persistence.CacheLoaderException: org.infinispan.commons.marshall.NotSerializableException: org.jboss.as.clustering.infinispan.DefaultCacheContainer
        at org.infinispan.marshall.core.MarshalledEntryImpl.marshall(MarshalledEntryImpl.java:107)
        at org.infinispan.marshall.core.MarshalledEntryImpl.getValueBytes(MarshalledEntryImpl.java:88)
        at org.infinispan.persistence.file.SingleFileStore.write(SingleFileStore.java:260)
        ... 20 more
Caused by: org.infinispan.commons.marshall.NotSerializableException: org.jboss.as.clustering.infinispan.DefaultCacheContainer
Caused by: an exception which occurred:
        in field container
        in field instance
        in field instance
        in object java.util.HashMap at 208cab3b
        in object org.jboss.as.clustering.marshalling.SimpleMarshalledValue at 208cab3b


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 18:23:02 2013
From: jira-events at lists.jboss.org (Frank Langelage (JIRA))
Date: Thu, 10 Oct 2013 18:23:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2283) NPE in
 StatefulWithXPCFailoverTestCase(SYNC-tcp)
In-Reply-To: <JIRA.12502740.1381443705056@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502740.1381443705056@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502740.1381443705056.32419.1381443782634@jira02.app.mwc.hst.phx2.redhat.com>

Frank Langelage created WFLY-2283:
-------------------------------------

             Summary: NPE in StatefulWithXPCFailoverTestCase(SYNC-tcp)
                 Key: WFLY-2283
                 URL: https://issues.jboss.org/browse/WFLY-2283
             Project: WildFly
          Issue Type: Bug
          Components: Clustering
    Affects Versions: 8.0.0.CR1
         Environment: Solaris SPARC 10, Oracle JDK 1.7.0_40
            Reporter: Frank Langelage
            Assignee: Paul Ferraro
         Attachments: org.jboss.as.test.clustering.cluster.ejb3.xpc.StatefulWithXPCFailoverTestCase-SYNC-tcp-output.txt, org.jboss.as.test.clustering.cluster.ejb3.xpc.StatefulWithXPCFailoverTestCase-SYNC-tcp.txt, TEST-org.jboss.as.test.clustering.cluster.ejb3.xpc.StatefulWithXPCFailoverTestCase-SYNC-tcp.xml

Running the build of current master with complete testsuite fails with a NPE in clustering testsuite.
See attached files.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 18:23:02 2013
From: jira-events at lists.jboss.org (Frank Langelage (JIRA))
Date: Thu, 10 Oct 2013 18:23:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2283) NPE in
 StatefulWithXPCFailoverTestCase(SYNC-tcp)
In-Reply-To: <JIRA.12502740.1381443705000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502740.1381443705000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502740.1381443705000.32421.1381443782728@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Frank Langelage updated WFLY-2283:
----------------------------------

    Attachment: org.jboss.as.test.clustering.cluster.ejb3.xpc.StatefulWithXPCFailoverTestCase-SYNC-tcp.txt
                org.jboss.as.test.clustering.cluster.ejb3.xpc.StatefulWithXPCFailoverTestCase-SYNC-tcp-output.txt
                TEST-org.jboss.as.test.clustering.cluster.ejb3.xpc.StatefulWithXPCFailoverTestCase-SYNC-tcp.xml

    
> NPE in StatefulWithXPCFailoverTestCase(SYNC-tcp)
> ------------------------------------------------
>
>                 Key: WFLY-2283
>                 URL: https://issues.jboss.org/browse/WFLY-2283
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 8.0.0.CR1
>         Environment: Solaris SPARC 10, Oracle JDK 1.7.0_40
>            Reporter: Frank Langelage
>            Assignee: Paul Ferraro
>         Attachments: org.jboss.as.test.clustering.cluster.ejb3.xpc.StatefulWithXPCFailoverTestCase-SYNC-tcp-output.txt, org.jboss.as.test.clustering.cluster.ejb3.xpc.StatefulWithXPCFailoverTestCase-SYNC-tcp.txt, TEST-org.jboss.as.test.clustering.cluster.ejb3.xpc.StatefulWithXPCFailoverTestCase-SYNC-tcp.xml
>
>
> Running the build of current master with complete testsuite fails with a NPE in clustering testsuite.
> See attached files.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 10 21:36:02 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Thu, 10 Oct 2013 21:36:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2282) SFSB serialization fails if
 containing EntityManager or EntityManagerFactory field w/2LC enabled
In-Reply-To: <JIRA.12502735.1381434775000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502735.1381434775000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502735.1381434775000.32489.1381455362598@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813293#comment-12813293 ] 

Scott Marlow commented on WFLY-2282:
------------------------------------

workaround: @Stateful beans to @Stateful(passivationCapable=false)
                
> SFSB serialization fails if containing EntityManager or EntityManagerFactory field w/2LC enabled
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2282
>                 URL: https://issues.jboss.org/browse/WFLY-2282
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Paul Ferraro
>            Assignee: Scott Marlow
>
> 2013-10-10 15:03:46,636 WARN  [org.infinispan.factories.ComponentRegistry] (MSC service thread 1-3) ISPN000189: While stopping a cache or cache manager, one of its components failed to stop: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.eviction.PassivationManagerImpl.passivateAll() throws org.infinispan.persistence.CacheLoaderException on object of type PassivationManagerImpl
>         at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:185)
>         at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
>         at org.infinispan.factories.AbstractComponentRegistry.internalStop(AbstractComponentRegistry.java:674)
>         at org.infinispan.factories.AbstractComponentRegistry.stop(AbstractComponentRegistry.java:552)
>         at org.infinispan.factories.ComponentRegistry.stop(ComponentRegistry.java:241)
>         at org.infinispan.CacheImpl.stop(CacheImpl.java:690)
>         at org.infinispan.CacheImpl.stop(CacheImpl.java:685)
>         at org.infinispan.AbstractDelegatingCache.stop(AbstractDelegatingCache.java:316)
>         at org.jboss.as.clustering.infinispan.subsystem.CacheService.stop(CacheService.java:96)
>         at org.jboss.as.clustering.msc.AsynchronousService.stop(AsynchronousService.java:114) [wildfly-clustering-common-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
>         at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2052) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>         at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2013) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
>         at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: org.infinispan.persistence.CacheLoaderException: org.infinispan.persistence.CacheLoaderException: org.infinispan.commons.marshall.NotSerializableException: org.jboss.as.clustering.infinispan.DefaultCacheContainer
>         at org.infinispan.persistence.file.SingleFileStore.write(SingleFileStore.java:297)
>         at org.infinispan.persistence.manager.PersistenceManagerImpl.writeToAllStores(PersistenceManagerImpl.java:430)
>         at org.infinispan.eviction.PassivationManagerImpl.passivateAll(PassivationManagerImpl.java:98)
>         at sun.reflect.GeneratedMethodAccessor152.invoke(Unknown Source) [:1.7.0_25]
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_25]
>         at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_25]
>         at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:183)
>         ... 14 more
> Caused by: org.infinispan.persistence.CacheLoaderException: org.infinispan.commons.marshall.NotSerializableException: org.jboss.as.clustering.infinispan.DefaultCacheContainer
>         at org.infinispan.marshall.core.MarshalledEntryImpl.marshall(MarshalledEntryImpl.java:107)
>         at org.infinispan.marshall.core.MarshalledEntryImpl.getValueBytes(MarshalledEntryImpl.java:88)
>         at org.infinispan.persistence.file.SingleFileStore.write(SingleFileStore.java:260)
>         ... 20 more
> Caused by: org.infinispan.commons.marshall.NotSerializableException: org.jboss.as.clustering.infinispan.DefaultCacheContainer
> Caused by: an exception which occurred:
>         in field container
>         in field instance
>         in field instance
>         in object java.util.HashMap at 208cab3b
>         in object org.jboss.as.clustering.marshalling.SimpleMarshalledValue at 208cab3b

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 00:46:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 11 Oct 2013 00:46:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2271) A problem setting include-all
 on a role mapping is failing getting rolled back.
In-Reply-To: <JIRA.12502544.1381316379000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502544.1381316379000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502544.1381316379000.32535.1381466764252@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813298#comment-12813298 ] 

RH Bugzilla Integration commented on WFLY-2271:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1017199|https://bugzilla.redhat.com/show_bug.cgi?id=1017199] from ASSIGNED to MODIFIED
                
> A problem setting include-all on a role mapping is failing getting rolled back.
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-2271
>                 URL: https://issues.jboss.org/browse/WFLY-2271
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> As a side effect of another bug the following failure occurs: -
> {code}
> [domain at localhost:9990 /] ./core-service=management/access=authorization/role-mapping=test:add
> {
>     "outcome" => "success",
>     "result" => undefined,
>     "server-groups" => {"main-server-group" => {"host" => {"master" => {
>         "server-one" => {"response" => {"outcome" => "success"}},
>         "server-two" => {"response" => {"outcome" => "success"}}
>     }}}}
> }
> [domain at localhost:9990 /] ./core-service=management/access=authorization/role-mapping=test:write-attribute(name=include-all, value=true)
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "JBAS014749: Operation handler failed: JBAS013470: Unknown role 'TEST'"},
>     "rolled-back" => true
> }
> {code}
> Roll back however fails with this error: -
> {code}
> [Host Controller] 11:47:25,216 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 11) JBAS014603:  caught exception attempting to revert operation write-attribute at address [
> [Host Controller]     ("core-service" => "management"),
> [Host Controller]     ("access" => "authorization"),
> [Host Controller]     ("role-mapping" => "test")
> [Host Controller] ]: java.lang.IllegalArgumentException
> [Host Controller] 	at org.jboss.dmr.ModelValue.asBoolean(ModelValue.java:66) [jboss-dmr-1.2.0.Final.jar:1.2.0.Final]
> [Host Controller] 	at org.jboss.dmr.ModelNode.asBoolean(ModelNode.java:262) [jboss-dmr-1.2.0.Final.jar:1.2.0.Final]
> [Host Controller] 	at org.jboss.as.domain.management.access.RoleIncludeAllWriteAttributeHander.revertUpdateToRuntime(RoleIncludeAllWriteAttributeHander.java:65)
> [Host Controller] 	at org.jboss.as.domain.management.access.RoleIncludeAllWriteAttributeHander.revertUpdateToRuntime(RoleIncludeAllWriteAttributeHander.java:35)
> {code}
> Two issues here: -
> 1 - "rolled-back" should not be true as it failed.
> 2 - The failure during rollback needs to be fixed, the default for this attribute if not set is 'false'.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 02:27:02 2013
From: jira-events at lists.jboss.org (Madhura Jayaratne (JIRA))
Date: Fri, 11 Oct 2013 02:27:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-296) Drools date coercion and
	conditional OR
In-Reply-To: <JIRA.12502748.1381472788320@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502748.1381472788320@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502748.1381472788320.32570.1381472822565@jira02.app.mwc.hst.phx2.redhat.com>

Madhura Jayaratne created DROOLS-296:
----------------------------------------

             Summary: Drools date coercion and conditional OR
                 Key: DROOLS-296
                 URL: https://issues.jboss.org/browse/DROOLS-296
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 5.5.0.Final
         Environment: Windows 7
            Reporter: Madhura Jayaratne
            Assignee: Mark Proctor


If I try a simple Drools rule with conditions on date type and uses conditional OR (||) I get the following error. If I change || to && it works fine.

Condition
$container: DateContainer( date >= "15-Oct-2013" || date <= "01-Oct-2013"  )

Error
Unable to Analyse Expression date >= "15-Oct-2013" || date <= "01-Oct-2013":
[Error: Comparison operation requires compatible types. Found class java.util.Date and class java.lang.String]
[Near : {... date >= "15-Oct-2013" || date <= "01-Oct-2013" ....}]
                                              ^
[Line: 9, Column: 1] : [Rule name='Test rule']


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 02:54:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 11 Oct 2013 02:54:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1341) Missing charset-related paths
	from sun.jdk
In-Reply-To: <JIRA.12491807.1368584295000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12491807.1368584295000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12491807.1368584295000.32605.1381474442903@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813307#comment-12813307 ] 

RH Bugzilla Integration commented on WFLY-1341:
-----------------------------------------------

Ladislav Thon <lthon at redhat.com> made a comment on [bug 959478|https://bugzilla.redhat.com/show_bug.cgi?id=959478]

I took the liberty to fix this myself. Here's the upstream pull request: https://github.com/wildfly/wildfly/pull/5259
                
> Missing charset-related paths from sun.jdk
> ------------------------------------------
>
>                 Key: WFLY-1341
>                 URL: https://issues.jboss.org/browse/WFLY-1341
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Brad Maxwell
>            Assignee: David Lloyd
>             Fix For: 8.0.0.Alpha1
>
>
> The sun.jdk module needs the sun.nio.ext and sun.nio.cs packages to load charsets from application code properly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 03:17:02 2013
From: jira-events at lists.jboss.org (Christian Kaltepoth (JIRA))
Date: Fri, 11 Oct 2013 03:17:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2284)
 HttpServletRequest.getQueryString() returns null for forwarded requests
In-Reply-To: <JIRA.12502751.1381475769812@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502751.1381475769812@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502751.1381475769812.32633.1381475822927@jira02.app.mwc.hst.phx2.redhat.com>

Christian Kaltepoth created WFLY-2284:
-----------------------------------------

             Summary: HttpServletRequest.getQueryString() returns null for forwarded requests
                 Key: WFLY-2284
                 URL: https://issues.jboss.org/browse/WFLY-2284
             Project: WildFly
          Issue Type: Bug
          Components: Web (Undertow)
    Affects Versions: 8.0.0.Beta1
            Reporter: Christian Kaltepoth
            Assignee: Stuart Douglas
         Attachments: forward-query.zip

When a request gets forwarded to another Servlet, {{HttpServletRequest.getQueryString()}} returns null, even if the original request contains query parameters.

>From Servlet 3.1 spec 9.4.1:

{quote}
The request dispatching mechanism is responsible for aggregating query string parameters when forwarding or including requests.
{quote}

The attached sample project demonstrates the problem:

If you request {{/first?foo=bar}}, the corresponding servlet will forward the request to {{/second}}. The second servlet will get these values:

{code}
request.getRequestURI():      /forward-query/second
request.getParameter("foo"):  bar
request.getQueryString():     null
{code}

In JBoss AS 7.1.1  and Tomcat the result looks like this:

{code}
request.getRequestURI():      /forward-query/second
request.getParameter("foo"):  bar
request.getQueryString():     foo=bar
{code}


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 03:17:03 2013
From: jira-events at lists.jboss.org (Christian Kaltepoth (JIRA))
Date: Fri, 11 Oct 2013 03:17:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2284)
 HttpServletRequest.getQueryString() returns null for forwarded requests
In-Reply-To: <JIRA.12502751.1381475769000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502751.1381475769000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502751.1381475769000.32636.1381475823121@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christian Kaltepoth updated WFLY-2284:
--------------------------------------

    Attachment: forward-query.zip


Project to reproduce the bug
                
> HttpServletRequest.getQueryString() returns null for forwarded requests
> -----------------------------------------------------------------------
>
>                 Key: WFLY-2284
>                 URL: https://issues.jboss.org/browse/WFLY-2284
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Christian Kaltepoth
>            Assignee: Stuart Douglas
>         Attachments: forward-query.zip
>
>
> When a request gets forwarded to another Servlet, {{HttpServletRequest.getQueryString()}} returns null, even if the original request contains query parameters.
> From Servlet 3.1 spec 9.4.1:
> {quote}
> The request dispatching mechanism is responsible for aggregating query string parameters when forwarding or including requests.
> {quote}
> The attached sample project demonstrates the problem:
> If you request {{/first?foo=bar}}, the corresponding servlet will forward the request to {{/second}}. The second servlet will get these values:
> {code}
> request.getRequestURI():      /forward-query/second
> request.getParameter("foo"):  bar
> request.getQueryString():     null
> {code}
> In JBoss AS 7.1.1  and Tomcat the result looks like this:
> {code}
> request.getRequestURI():      /forward-query/second
> request.getParameter("foo"):  bar
> request.getQueryString():     foo=bar
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 03:36:02 2013
From: jira-events at lists.jboss.org (Jari Juslin (JIRA))
Date: Fri, 11 Oct 2013 03:36:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2267) Persisting a new entity bean
 with certain patterns fails to ARJUNA016082 on flush stage.
In-Reply-To: <JIRA.12502535.1381312028000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502535.1381312028000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502535.1381312028000.32644.1381476962811@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813313#comment-12813313 ] 

Jari Juslin commented on WFLY-2267:
-----------------------------------

Testing: Just setting the transaction mode to NON_XA makes the bug go away. So this bug is about FULL_XA mode.
                
> Persisting a new entity bean with certain patterns fails to ARJUNA016082 on flush stage.
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-2267
>                 URL: https://issues.jboss.org/browse/WFLY-2267
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Alpha4, 8.0.0.Beta1
>         Environment: Ubuntu Linux 13.04, JDK 1.7.0u40 64-bit.
>            Reporter: Jari Juslin
>            Assignee: Scott Marlow
>         Attachments: infinispan_bug_repro.zip, infinispan_bug_repro2.zip
>
>
> Persisting a new entity inside a CMT and then exiting the transactional method throws ARJUNA016082 in certain cases.
> I have extracted two cases where the bug manifests.
> 1) Creating a new entity bean and then changing one field after the persist call.
> 2) Creating a new entity bean that has another entity linked to it, and the newly created entity is on the blind side of the relationship.
> Here is the RESTeasy service and the entity bean needed to replicate this (also packaged to the attached test case):
> package bugrepro2;
> import javax.ejb.LocalBean;
> import javax.ejb.Stateless;
> import javax.persistence.EntityManager;
> import javax.persistence.PersistenceContext;
> import javax.ws.rs.POST;
> import javax.ws.rs.Path;
> /**
>  * @author Jari Juslin, zds at ecolane.com
>  */
> @Stateless
> @LocalBean
> @Path("/bug_repro2")
> public class BugRepro2Rest {
>     @PersistenceContext(unitName = "persistence_context2")
>     protected EntityManager entityManager;
>     
>     @POST
>     public String manifestArjunaBug() {
>         BugReproEntity entry = new BugReproEntity();
>         entityManager.persist(entry);
>         
>         entry.setHasChanges(true);
>         
>         return "Success\n";
>     }
> }
> package bugrepro2;
> import javax.persistence.Column;
> import javax.persistence.Entity;
> import javax.persistence.GeneratedValue;
> import javax.persistence.GenerationType;
> import javax.persistence.Id;
> import javax.persistence.Table;
> import org.hibernate.annotations.Cache;
> import org.hibernate.annotations.CacheConcurrencyStrategy;
> @Entity()
> @Table(name = "bugrepro_entity")
> @Cache(usage=CacheConcurrencyStrategy.TRANSACTIONAL)
> public class BugReproEntity {
>     private Integer id;
>     private boolean hasChanges;
>     public BugReproEntity() {
>     }
>     @Id
>     @GeneratedValue(strategy=GenerationType.IDENTITY)
>     @Column(name="id")
>     public Integer getId() {
>         return id;
>     }
>     public void setId(Integer id) {
>         this.id = id;
>     }
>     @Column(name="has_changes")
>     public boolean getHasChanges() {
>         return hasChanges;
>     }
>     public void setHasChanges(boolean hasChanges) {
>         this.hasChanges = hasChanges;
>     }
> }
> The resulting exception:
> 2013-10-09 12:44:07,362 WARN  [org.infinispan.transaction.TransactionTable] (default task-31:) ISPN000101: Failed synchronization registration: java.lang.IllegalStateException: ARJUNA016082: Synchronizations are not allowed! Transaction status isActionStatus.RUNNING
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronizationImple(TransactionImple.java:379)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronization(TransactionImple.java:356)
> 	at org.infinispan.transaction.TransactionTable.enlist(TransactionTable.java:196)
> 	at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:269)
> 	at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:231)
> 	at org.infinispan.interceptors.TxInterceptor.visitPutKeyValueCommand(TxInterceptor.java:177)
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.updateStoreStatistics(CacheMgmtInterceptor.java:148)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:134)
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:106)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:70)
> 	at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32)
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:321)
> 	at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1298)
> 	at org.infinispan.CacheImpl.putInternal(CacheImpl.java:871)
> 	at org.infinispan.CacheImpl.put(CacheImpl.java:863)
> 	at org.infinispan.DecoratedCache.put(DecoratedCache.java:401)
> 	at org.infinispan.AbstractDelegatingCache.put(AbstractDelegatingCache.java:276)
> 	at org.hibernate.cache.infinispan.access.TransactionalAccessDelegate.update(TransactionalAccessDelegate.java:187) [hibernate-infinispan-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.cache.infinispan.entity.TransactionalAccess.update(TransactionalAccess.java:89) [hibernate-infinispan-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.action.internal.EntityUpdateAction.execute(EntityUpdateAction.java:208) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:377) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:369) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:287) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:340) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:52) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1235) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:405) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:113) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:53) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76)
> 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:273)
> 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:93)
> 	at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1170)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
> 	at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:93) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:437)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72)
> 	at bugrepro2.BugRepro2Rest$$$view31.manifestArjunaBug(Unknown Source) [classes:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_40]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_40]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_40]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_40]
> 	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:280) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:234) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:221) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:59) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:218) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:619) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> The datasource definition from standalone.xml:
>                 <datasource jndi-name="java:/BugRepro2DS" pool-name="BugRepro2DS" enabled="true">
>                     <connection-url>jdbc:mysql://localhost:3306/bugrepro2</connection-url>
>                     <driver>mysql</driver>
>                     <security>
>                         <user-name>*******</user-name>
>                         <password>*******</password>
>                     </security>
>                 </datasource>
>                 <drivers>
>                     <driver name="mysql" module="com.mysql">
>                         <xa-datasource-class>com.mysql.jdbc.jdbc2.optional.MysqlXADataSource</xa-datasource-class>
>                     </driver>
>                 </drivers>
> I have reported this also to Infinispan, because I am not sure which party is to blame.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 03:38:02 2013
From: jira-events at lists.jboss.org (Jari Juslin (JIRA))
Date: Fri, 11 Oct 2013 03:38:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2267) Persisting a new entity bean
 with certain patterns fails to ARJUNA016082 on flush stage.
In-Reply-To: <JIRA.12502535.1381312028000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502535.1381312028000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502535.1381312028000.32646.1381477082557@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jari Juslin updated WFLY-2267:
------------------------------

    Description: 
Persisting a new entity inside a CMT and then exiting the transactional method throws ARJUNA016082 in certain cases.

I have extracted two cases where the bug manifests.
1) Creating a new entity bean and then changing one field after the persist call.
2) Creating a new entity bean that has another entity linked to it, and the newly created entity is on the blind side of the relationship.

Here is the RESTeasy service and the entity bean needed to replicate this (also packaged to the attached test case):

package bugrepro2;

import javax.ejb.LocalBean;
import javax.ejb.Stateless;
import javax.persistence.EntityManager;
import javax.persistence.PersistenceContext;
import javax.ws.rs.POST;
import javax.ws.rs.Path;

/**
 * @author Jari Juslin, zds at ecolane.com
 */
@Stateless
@LocalBean
@Path("/bug_repro2")
public class BugRepro2Rest {
    @PersistenceContext(unitName = "persistence_context2")
    protected EntityManager entityManager;
    
    @POST
    public String manifestArjunaBug() {
        BugReproEntity entry = new BugReproEntity();

        entityManager.persist(entry);
        
        entry.setHasChanges(true);
        
        return "Success\n";
    }
}

package bugrepro2;

import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.Table;

import org.hibernate.annotations.Cache;
import org.hibernate.annotations.CacheConcurrencyStrategy;

@Entity()
@Table(name = "bugrepro_entity")
@Cache(usage=CacheConcurrencyStrategy.TRANSACTIONAL)
public class BugReproEntity {
    private Integer id;

    private boolean hasChanges;

    public BugReproEntity() {
    }

    @Id
    @GeneratedValue(strategy=GenerationType.IDENTITY)
    @Column(name="id")
    public Integer getId() {
        return id;
    }

    public void setId(Integer id) {
        this.id = id;
    }

    @Column(name="has_changes")
    public boolean getHasChanges() {
        return hasChanges;
    }

    public void setHasChanges(boolean hasChanges) {
        this.hasChanges = hasChanges;
    }
}

Infinispan config block on standalone.xml:
            <cache-container name="hibernate" default-cache="local-query" module="org.hibernate">
                <local-cache name="entity">
                    <transaction mode="FULL_XA"/>
                    <eviction strategy="LRU" max-entries="10000"/>
                    <expiration max-idle="100000"/>
                    <indexing index="LOCAL">
                        <property name="hibernate.search.default.directory_provider">                                                                                                                                                                                           
                            ram                                                                                                                                                                                                                                                 
                        </property>
                    </indexing>
                </local-cache>
...
            </cache-container>

The resulting exception:
2013-10-09 12:44:07,362 WARN  [org.infinispan.transaction.TransactionTable] (default task-31:) ISPN000101: Failed synchronization registration: java.lang.IllegalStateException: ARJUNA016082: Synchronizations are not allowed! Transaction status isActionStatus.RUNNING
	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronizationImple(TransactionImple.java:379)
	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronization(TransactionImple.java:356)
	at org.infinispan.transaction.TransactionTable.enlist(TransactionTable.java:196)
	at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:269)
	at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:231)
	at org.infinispan.interceptors.TxInterceptor.visitPutKeyValueCommand(TxInterceptor.java:177)
	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
	at org.infinispan.interceptors.CacheMgmtInterceptor.updateStoreStatistics(CacheMgmtInterceptor.java:148)
	at org.infinispan.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:134)
	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:106)
	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:70)
	at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32)
	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:321)
	at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1298)
	at org.infinispan.CacheImpl.putInternal(CacheImpl.java:871)
	at org.infinispan.CacheImpl.put(CacheImpl.java:863)
	at org.infinispan.DecoratedCache.put(DecoratedCache.java:401)
	at org.infinispan.AbstractDelegatingCache.put(AbstractDelegatingCache.java:276)
	at org.hibernate.cache.infinispan.access.TransactionalAccessDelegate.update(TransactionalAccessDelegate.java:187) [hibernate-infinispan-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.cache.infinispan.entity.TransactionalAccess.update(TransactionalAccess.java:89) [hibernate-infinispan-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.action.internal.EntityUpdateAction.execute(EntityUpdateAction.java:208) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:377) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:369) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:287) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:340) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:52) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1235) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:405) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:113) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:53) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76)
	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:273)
	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:93)
	at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1170)
	at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
	at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:93) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:437)
	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72)
	at bugrepro2.BugRepro2Rest$$$view31.manifestArjunaBug(Unknown Source) [classes:]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_40]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_40]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_40]
	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_40]
	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137) [resteasy-jaxrs-3.0.4.Final.jar:]
	at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:280) [resteasy-jaxrs-3.0.4.Final.jar:]
	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:234) [resteasy-jaxrs-3.0.4.Final.jar:]
	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:221) [resteasy-jaxrs-3.0.4.Final.jar:]
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356) [resteasy-jaxrs-3.0.4.Final.jar:]
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179) [resteasy-jaxrs-3.0.4.Final.jar:]
	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) [resteasy-jaxrs-3.0.4.Final.jar:]
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.4.Final.jar:]
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.4.Final.jar:]
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:59) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:218) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:619) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]

The datasource definition from standalone.xml:
                <datasource jndi-name="java:/BugRepro2DS" pool-name="BugRepro2DS" enabled="true">
                    <connection-url>jdbc:mysql://localhost:3306/bugrepro2</connection-url>
                    <driver>mysql</driver>
                    <security>
                        <user-name>*******</user-name>
                        <password>*******</password>
                    </security>
                </datasource>

                <drivers>
                    <driver name="mysql" module="com.mysql">
                        <xa-datasource-class>com.mysql.jdbc.jdbc2.optional.MysqlXADataSource</xa-datasource-class>
                    </driver>
                </drivers>

I have reported this also to Infinispan, because I am not sure which party is to blame.

  was:
Persisting a new entity inside a CMT and then exiting the transactional method throws ARJUNA016082 in certain cases.

I have extracted two cases where the bug manifests.
1) Creating a new entity bean and then changing one field after the persist call.
2) Creating a new entity bean that has another entity linked to it, and the newly created entity is on the blind side of the relationship.

Here is the RESTeasy service and the entity bean needed to replicate this (also packaged to the attached test case):

package bugrepro2;

import javax.ejb.LocalBean;
import javax.ejb.Stateless;
import javax.persistence.EntityManager;
import javax.persistence.PersistenceContext;
import javax.ws.rs.POST;
import javax.ws.rs.Path;

/**
 * @author Jari Juslin, zds at ecolane.com
 */
@Stateless
@LocalBean
@Path("/bug_repro2")
public class BugRepro2Rest {
    @PersistenceContext(unitName = "persistence_context2")
    protected EntityManager entityManager;
    
    @POST
    public String manifestArjunaBug() {
        BugReproEntity entry = new BugReproEntity();

        entityManager.persist(entry);
        
        entry.setHasChanges(true);
        
        return "Success\n";
    }
}

package bugrepro2;

import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.Table;

import org.hibernate.annotations.Cache;
import org.hibernate.annotations.CacheConcurrencyStrategy;

@Entity()
@Table(name = "bugrepro_entity")
@Cache(usage=CacheConcurrencyStrategy.TRANSACTIONAL)
public class BugReproEntity {
    private Integer id;

    private boolean hasChanges;

    public BugReproEntity() {
    }

    @Id
    @GeneratedValue(strategy=GenerationType.IDENTITY)
    @Column(name="id")
    public Integer getId() {
        return id;
    }

    public void setId(Integer id) {
        this.id = id;
    }

    @Column(name="has_changes")
    public boolean getHasChanges() {
        return hasChanges;
    }

    public void setHasChanges(boolean hasChanges) {
        this.hasChanges = hasChanges;
    }
}

The resulting exception:
2013-10-09 12:44:07,362 WARN  [org.infinispan.transaction.TransactionTable] (default task-31:) ISPN000101: Failed synchronization registration: java.lang.IllegalStateException: ARJUNA016082: Synchronizations are not allowed! Transaction status isActionStatus.RUNNING
	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronizationImple(TransactionImple.java:379)
	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronization(TransactionImple.java:356)
	at org.infinispan.transaction.TransactionTable.enlist(TransactionTable.java:196)
	at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:269)
	at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:231)
	at org.infinispan.interceptors.TxInterceptor.visitPutKeyValueCommand(TxInterceptor.java:177)
	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
	at org.infinispan.interceptors.CacheMgmtInterceptor.updateStoreStatistics(CacheMgmtInterceptor.java:148)
	at org.infinispan.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:134)
	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:106)
	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:70)
	at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32)
	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:321)
	at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1298)
	at org.infinispan.CacheImpl.putInternal(CacheImpl.java:871)
	at org.infinispan.CacheImpl.put(CacheImpl.java:863)
	at org.infinispan.DecoratedCache.put(DecoratedCache.java:401)
	at org.infinispan.AbstractDelegatingCache.put(AbstractDelegatingCache.java:276)
	at org.hibernate.cache.infinispan.access.TransactionalAccessDelegate.update(TransactionalAccessDelegate.java:187) [hibernate-infinispan-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.cache.infinispan.entity.TransactionalAccess.update(TransactionalAccess.java:89) [hibernate-infinispan-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.action.internal.EntityUpdateAction.execute(EntityUpdateAction.java:208) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:377) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:369) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:287) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:340) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:52) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1235) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:405) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:113) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:53) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76)
	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:273)
	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:93)
	at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1170)
	at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
	at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:93) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:437)
	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72)
	at bugrepro2.BugRepro2Rest$$$view31.manifestArjunaBug(Unknown Source) [classes:]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_40]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_40]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_40]
	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_40]
	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137) [resteasy-jaxrs-3.0.4.Final.jar:]
	at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:280) [resteasy-jaxrs-3.0.4.Final.jar:]
	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:234) [resteasy-jaxrs-3.0.4.Final.jar:]
	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:221) [resteasy-jaxrs-3.0.4.Final.jar:]
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356) [resteasy-jaxrs-3.0.4.Final.jar:]
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179) [resteasy-jaxrs-3.0.4.Final.jar:]
	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) [resteasy-jaxrs-3.0.4.Final.jar:]
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.4.Final.jar:]
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.4.Final.jar:]
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:59) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:218) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:619) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]

The datasource definition from standalone.xml:
                <datasource jndi-name="java:/BugRepro2DS" pool-name="BugRepro2DS" enabled="true">
                    <connection-url>jdbc:mysql://localhost:3306/bugrepro2</connection-url>
                    <driver>mysql</driver>
                    <security>
                        <user-name>*******</user-name>
                        <password>*******</password>
                    </security>
                </datasource>

                <drivers>
                    <driver name="mysql" module="com.mysql">
                        <xa-datasource-class>com.mysql.jdbc.jdbc2.optional.MysqlXADataSource</xa-datasource-class>
                    </driver>
                </drivers>

I have reported this also to Infinispan, because I am not sure which party is to blame.


    
> Persisting a new entity bean with certain patterns fails to ARJUNA016082 on flush stage.
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-2267
>                 URL: https://issues.jboss.org/browse/WFLY-2267
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Alpha4, 8.0.0.Beta1
>         Environment: Ubuntu Linux 13.04, JDK 1.7.0u40 64-bit.
>            Reporter: Jari Juslin
>            Assignee: Scott Marlow
>         Attachments: infinispan_bug_repro.zip, infinispan_bug_repro2.zip
>
>
> Persisting a new entity inside a CMT and then exiting the transactional method throws ARJUNA016082 in certain cases.
> I have extracted two cases where the bug manifests.
> 1) Creating a new entity bean and then changing one field after the persist call.
> 2) Creating a new entity bean that has another entity linked to it, and the newly created entity is on the blind side of the relationship.
> Here is the RESTeasy service and the entity bean needed to replicate this (also packaged to the attached test case):
> package bugrepro2;
> import javax.ejb.LocalBean;
> import javax.ejb.Stateless;
> import javax.persistence.EntityManager;
> import javax.persistence.PersistenceContext;
> import javax.ws.rs.POST;
> import javax.ws.rs.Path;
> /**
>  * @author Jari Juslin, zds at ecolane.com
>  */
> @Stateless
> @LocalBean
> @Path("/bug_repro2")
> public class BugRepro2Rest {
>     @PersistenceContext(unitName = "persistence_context2")
>     protected EntityManager entityManager;
>     
>     @POST
>     public String manifestArjunaBug() {
>         BugReproEntity entry = new BugReproEntity();
>         entityManager.persist(entry);
>         
>         entry.setHasChanges(true);
>         
>         return "Success\n";
>     }
> }
> package bugrepro2;
> import javax.persistence.Column;
> import javax.persistence.Entity;
> import javax.persistence.GeneratedValue;
> import javax.persistence.GenerationType;
> import javax.persistence.Id;
> import javax.persistence.Table;
> import org.hibernate.annotations.Cache;
> import org.hibernate.annotations.CacheConcurrencyStrategy;
> @Entity()
> @Table(name = "bugrepro_entity")
> @Cache(usage=CacheConcurrencyStrategy.TRANSACTIONAL)
> public class BugReproEntity {
>     private Integer id;
>     private boolean hasChanges;
>     public BugReproEntity() {
>     }
>     @Id
>     @GeneratedValue(strategy=GenerationType.IDENTITY)
>     @Column(name="id")
>     public Integer getId() {
>         return id;
>     }
>     public void setId(Integer id) {
>         this.id = id;
>     }
>     @Column(name="has_changes")
>     public boolean getHasChanges() {
>         return hasChanges;
>     }
>     public void setHasChanges(boolean hasChanges) {
>         this.hasChanges = hasChanges;
>     }
> }
> Infinispan config block on standalone.xml:
>             <cache-container name="hibernate" default-cache="local-query" module="org.hibernate">
>                 <local-cache name="entity">
>                     <transaction mode="FULL_XA"/>
>                     <eviction strategy="LRU" max-entries="10000"/>
>                     <expiration max-idle="100000"/>
>                     <indexing index="LOCAL">
>                         <property name="hibernate.search.default.directory_provider">                                                                                                                                                                                           
>                             ram                                                                                                                                                                                                                                                 
>                         </property>
>                     </indexing>
>                 </local-cache>
> ...
>             </cache-container>
> The resulting exception:
> 2013-10-09 12:44:07,362 WARN  [org.infinispan.transaction.TransactionTable] (default task-31:) ISPN000101: Failed synchronization registration: java.lang.IllegalStateException: ARJUNA016082: Synchronizations are not allowed! Transaction status isActionStatus.RUNNING
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronizationImple(TransactionImple.java:379)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronization(TransactionImple.java:356)
> 	at org.infinispan.transaction.TransactionTable.enlist(TransactionTable.java:196)
> 	at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:269)
> 	at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:231)
> 	at org.infinispan.interceptors.TxInterceptor.visitPutKeyValueCommand(TxInterceptor.java:177)
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.updateStoreStatistics(CacheMgmtInterceptor.java:148)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:134)
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:106)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:70)
> 	at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32)
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:321)
> 	at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1298)
> 	at org.infinispan.CacheImpl.putInternal(CacheImpl.java:871)
> 	at org.infinispan.CacheImpl.put(CacheImpl.java:863)
> 	at org.infinispan.DecoratedCache.put(DecoratedCache.java:401)
> 	at org.infinispan.AbstractDelegatingCache.put(AbstractDelegatingCache.java:276)
> 	at org.hibernate.cache.infinispan.access.TransactionalAccessDelegate.update(TransactionalAccessDelegate.java:187) [hibernate-infinispan-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.cache.infinispan.entity.TransactionalAccess.update(TransactionalAccess.java:89) [hibernate-infinispan-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.action.internal.EntityUpdateAction.execute(EntityUpdateAction.java:208) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:377) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:369) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:287) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:340) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:52) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1235) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:405) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:113) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:53) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76)
> 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:273)
> 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:93)
> 	at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1170)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
> 	at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:93) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:437)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72)
> 	at bugrepro2.BugRepro2Rest$$$view31.manifestArjunaBug(Unknown Source) [classes:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_40]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_40]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_40]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_40]
> 	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:280) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:234) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:221) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:59) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:218) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:619) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> The datasource definition from standalone.xml:
>                 <datasource jndi-name="java:/BugRepro2DS" pool-name="BugRepro2DS" enabled="true">
>                     <connection-url>jdbc:mysql://localhost:3306/bugrepro2</connection-url>
>                     <driver>mysql</driver>
>                     <security>
>                         <user-name>*******</user-name>
>                         <password>*******</password>
>                     </security>
>                 </datasource>
>                 <drivers>
>                     <driver name="mysql" module="com.mysql">
>                         <xa-datasource-class>com.mysql.jdbc.jdbc2.optional.MysqlXADataSource</xa-datasource-class>
>                     </driver>
>                 </drivers>
> I have reported this also to Infinispan, because I am not sure which party is to blame.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 04:21:04 2013
From: jira-events at lists.jboss.org (Matti Linnanvuori (JIRA))
Date: Fri, 11 Oct 2013 04:21:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2280) Wrong XA Datasource selected
In-Reply-To: <JIRA.12502716.1381418849000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502716.1381418849000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502716.1381418849000.32715.1381479664232@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matti Linnanvuori reopened WFLY-2280:
-------------------------------------



ESC[0mESC[32m03:53:31,651 DEBUG [org.jboss.as.jpa] (default task-7) default task-7:[transaction scoped EntityManager]: reuse entity manager session already in tx TransactionImple < ac, BasicAction: 0:ffff90cae62c:25277dea:5257ad7c:6e2 status: ActionStatus.RUNNING >
ESC[0m03:53:31,661 TRACE [org.jboss.as.jpa.messages] (default task-7) merge entityClass 'com.ecolane.mpk.persistence.Customer' took 11ms
ESC[0mESC[32m03:53:31,661 DEBUG [org.jboss.as.jpa] (default task-7) default task-7:[transaction scoped EntityManager]: reuse entity manager session already in tx TransactionImple < ac, BasicAction: 0:ffff90cae62c:25277dea:5257ad7c:6e2 status: ActionStatus.RUNNING >
ESC[0m03:53:31,661 TRACE [org.jboss.as.jpa.messages] (default task-7) createNamedQuery name 'findCustomerByCustomerNumber', resultClass 'com.ecolane.mpk.persistence.Customer' took 0ms
ESC[0mESC[32m03:53:31,669 DEBUG [org.jboss.as.jpa] (default task-7) created new TransactionScopedEntityManager for unit name=k3.ear/k3-operational-entities.jar#k3_operational_persistence
ESC[0mESC[32m03:53:31,672 DEBUG [org.jboss.as.jpa] (default task-7) created new TransactionScopedEntityManager for unit name=k3.ear/k3-frontend-entities.jar#k3_frontend_persistence
ESC[0mESC[32m03:53:31,673 DEBUG [org.jboss.as.jpa] (default task-7) default task-7:[transaction scoped EntityManager]: created entity manager session TransactionImple < ac, BasicAction: 0:ffff90cae62c:25277dea:5257ad7c:6e2 status: ActionStatus.RUNNING >
ESC[0m03:53:31,673 TRACE [org.jboss.as.jpa.messages] (default task-7) createNamedQuery name 'findFeServiceByHostname', resultClass 'com.ecolane.mpk.frontend.persistence.FeService' took 0ms
^[[0m^[[31m03:53:31,749 ERROR [stderr] (default task-7) com.mysql.jdbc.jdbc2.op\
tional.MysqlXAException: XAER_INVAL: Invalid arguments (or unsupported command)
^[[0m^[[31m03:53:31,749 ERROR [stderr] (default task-7)         at com.mysql.jd\
bc.jdbc2.optional.MysqlXAConnection.mapXAExceptionFromSQLException(MysqlXAConne\
ction.java:600)
^[[0m^[[31m03:53:31,750 ERROR [stderr] (default task-7)         at com.mysql.jd\
bc.jdbc2.optional.MysqlXAConnection.dispatchCommand(MysqlXAConnection.java:583)
^[[0m^[[31m03:53:31,750 ERROR [stderr] (default task-7)         at com.mysql.jd\
bc.jdbc2.optional.MysqlXAConnection.start(MysqlXAConnection.java:523)
^[[0m^[[31m03:53:31,750 ERROR [stderr] (default task-7)         at org.jboss.jc\
a.adapters.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:259)
^[[0m^[[31m03:53:31,750 ERROR [stderr] (default task-7)         at org.jboss.jc\
a.core.tx.jbossts.XAResourceWrapperImpl.start(XAResourceWrapperImpl.java:191)
^[[0m^[[31m03:53:31,750 ERROR [stderr] (default task-7)         at com.arjuna.a\
ts.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(Transact\
ionImple.java:715)
^[[0m^[[31m03:53:31,750 ERROR [stderr] (default task-7)         at com.arjuna.a\
ts.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(Transact\
ionImple.java:397)
^[[0m^[[31m03:53:31,751 ERROR [stderr] (default task-7)         at org.jboss.jc\
a.core.connectionmanager.listener.TxConnectionListener$TransactionSynchronizati\
on.enlist(TxConnectionListener.java:607)
^[[0m^[[31m03:53:31,751 ERROR [stderr] (default task-7)         at org.jboss.jc\
a.core.connectionmanager.listener.TxConnectionListener.enlist(TxConnectionListe\
ner.java:265)
^[[0m^[[31m03:53:31,751 ERROR [stderr] (default task-7)         at org.jboss.jc\
a.core.connectionmanager.tx.TxConnectionManagerImpl.managedConnectionReconnecte\
d(TxConnectionManagerImpl.java:467)
^[[0m^[[31m03:53:31,751 ERROR [stderr] (default task-7)         at org.jboss.jc\
a.core.connectionmanager.AbstractConnectionManager.reconnectManagedConnection(A\
bstractConnectionManager.java:599)
^[[0m^[[31m03:53:31,751 ERROR [stderr] (default task-7)         at org.jboss.jc\
a.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractC\
onnectionManager.java:467)
^[[0m^[[31m03:53:31,751 ERROR [stderr] (default task-7)         at org.jboss.jc\
a.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:139)
^[[0m^[[31m03:53:31,752 ERROR [stderr] (default task-7)         at org.hibernat\
e.engine.jdbc.connections.internal.DatasourceConnectionProviderImpl.getConnecti\
on(DatasourceConnectionProviderImpl.java:138)
^[[0m^[[31m03:53:31,752 ERROR [stderr] (default task-7)         at org.hibernat\
e.internal.AbstractSessionImpl$NonContextualJdbcConnectionAccess.obtainConnecti\
on(AbstractSessionImpl.java:359)
^[[0m^[[31m03:53:31,752 ERROR [stderr] (default task-7)         at org.hibernat\
e.engine.jdbc.internal.LogicalConnectionImpl.obtainConnection(LogicalConnection\
Impl.java:227)
^[[0m^[[31m03:53:31,752 ERROR [stderr] (default task-7)         at org.hibernat\
e.engine.jdbc.internal.LogicalConnectionImpl.getConnection(LogicalConnectionImp\
l.java:170)
^[[0m^[[31m03:53:31,752 ERROR [stderr] (default task-7)         at org.hibernat\
e.engine.jdbc.internal.StatementPreparerImpl.connection(StatementPreparerImpl.j\
ava:63)
e.engine.jdbc.internal.StatementPreparerImpl.connection(StatementPreparerImpl.j\
ava:63)
^[[0m^[[31m03:53:31,752 ERROR [stderr] (default task-7)         at org.hibernat\
e.engine.jdbc.internal.StatementPreparerImpl$5.doPrepare(StatementPreparerImpl.\
java:164)
^[[0m^[[31m03:53:31,753 ERROR [stderr] (default task-7)         at org.hibernat\
e.engine.jdbc.internal.StatementPreparerImpl$StatementPreparationTemplate.prepa\
reStatement(StatementPreparerImpl.java:185)
^[[0m^[[31m03:53:31,753 ERROR [stderr] (default task-7)         at org.hibernat\
e.engine.jdbc.internal.StatementPreparerImpl.prepareQueryStatement(StatementPre\
parerImpl.java:162)
^[[0m^[[31m03:53:31,753 ERROR [stderr] (default task-7)         at org.hibernat\
e.loader.Loader.prepareQueryStatement(Loader.java:1859)
^[[0m^[[31m03:53:31,753 ERROR [stderr] (default task-7)         at org.hibernat\
e.loader.Loader.executeQueryStatement(Loader.java:1836)
^[[0m^[[31m03:53:31,753 ERROR [stderr] (default task-7)         at org.hibernat\
e.loader.Loader.executeQueryStatement(Loader.java:1813)
^[[0m^[[31m03:53:31,753 ERROR [stderr] (default task-7)         at org.hibernat\
e.loader.Loader.doQuery(Loader.java:895)
^[[0m^[[31m03:53:31,754 ERROR [stderr] (default task-7)         at org.hibernat\
e.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:340)
^[[0m^[[31m03:53:31,754 ERROR [stderr] (default task-7)         at org.hibernat\
e.loader.Loader.doList(Loader.java:2523)
^[[0m^[[31m03:53:31,754 ERROR [stderr] (default task-7)         at org.hibernat\
e.loader.Loader.doList(Loader.java:2509)
^[[0m^[[31m03:53:31,754 ERROR [stderr] (default task-7)         at org.hibernat\
e.loader.Loader.listIgnoreQueryCache(Loader.java:2339)
^[[0m^[[31m03:53:31,754 ERROR [stderr] (default task-7)         at org.hibernat\
e.loader.Loader.list(Loader.java:2334)
^[[0m^[[31m03:53:31,754 ERROR [stderr] (default task-7)         at org.hibernat\
e.loader.hql.QueryLoader.list(QueryLoader.java:491)
^[[0m^[[31m03:53:31,755 ERROR [stderr] (default task-7)         at org.hibernat\
e.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:369)
^[[0m^[[31m03:53:31,755 ERROR [stderr] (default task-7)         at org.hibernat\
e.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:222)
^[[0m^[[31m03:53:31,755 ERROR [stderr] (default task-7)         at org.hibernat\
e.internal.SessionImpl.list(SessionImpl.java:1270)
^[[0m^[[31m03:53:31,755 ERROR [stderr] (default task-7)         at org.hibernat\
e.internal.QueryImpl.list(QueryImpl.java:101)
^[[0m^[[31m03:53:31,755 ERROR [stderr] (default task-7)         at org.hibernat\
e.jpa.internal.QueryImpl.getSingleResult(QueryImpl.java:381)
^[[0m^[[31m03:53:31,755 ERROR [stderr] (default task-7)         at com.ecolane.\
mpk.frontend.beans.FrontendLiaisonBean.getOurFeService(FrontendLiaisonBean.java\
:123)
^[[0m^[[31m03:53:31,756 ERROR [stderr] (default task-7)         at com.ecolane.\
mpk.frontend.beans.FrontendLiaisonBean.synchOneCustomerToFrontend(FrontendLiais\
onBean.java:362)
^[[0m^[[31m03:53:31,756 ERROR [stderr] (default task-7)         at sun.reflect.\
NativeMethodAccessorImpl.invoke0(Native Method)
^[[0m^[[31m03:53:31,756 ERROR [stderr] (default task-7)         at sun.reflect.\
NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
^[[0m^[[31m03:53:31,756 ERROR [stderr] (default task-7)         at sun.reflect.\
DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
^[[0m^[[31m03:53:31,756 ERROR [stderr] (default task-7)         at java.lang.re\
flect.Method.invoke(Method.java:601)
^[[0m^[[31m03:53:31,756 ERROR [stderr] (default task-7)         at org.jboss.asflect.Method.invoke(Method.java:601)
^[[0m^[[31m03:53:31,756 ERROR [stderr] (default task-7)         at org.jboss.as\
.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodIn\
terceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
^[[0m^[[31m03:53:31,757 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,757 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
^[[0m^[[31m03:53:31,758 ERROR [stderr] (default task-7)         at org.jboss.as\
.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInter\
ceptorFactory.java:63)
^[[0m^[[31m03:53:31,758 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,758 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
^[[0m^[[31m03:53:31,758 ERROR [stderr] (default task-7)         at org.jboss.as\
.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsIntercep\
tor.java:130)
^[[0m^[[31m03:53:31,758 ERROR [stderr] (default task-7)         at org.jboss.as\
.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor\
.java:138)
^[[0m^[[31m03:53:31,758 ERROR [stderr] (default task-7)         at org.jboss.as\
.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInter\
ceptorFactory.java:63)
^[[0m^[[31m03:53:31,759 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,759 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
^[[0m^[[31m03:53:31,759 ERROR [stderr] (default task-7)         at org.jboss.as\
.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInter\
ceptorFactory.java:63)
^[[0m^[[31m03:53:31,759 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,759 ERROR [stderr] (default task-7)         at org.jboss.as\
.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(Ex\
ecutionTimeInterceptor.java:43)
^[[0m^[[31m03:53:31,759 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,760 ERROR [stderr] (default task-7)         at org.jboss.as\
.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationIntercep\
tor.java:47)
^[[0m^[[31m03:53:31,760 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,760 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
^[[0m^[[31m03:53:31,760 ERROR [stderr] (default task-7)         at org.jboss.we\
ld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBReq\
uestScopeActivationInterceptor.java:46)
^[[0m^[[31m03:53:31,760 ERROR [stderr] (default task-7)         at org.jboss.as\
.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScop\
eActivationInterceptor.java:84)
^[[0m^[[31m03:53:31,760 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,761 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
^[[0m^[[31m03:53:31,766 ERROR [stderr] (default task-7)         at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
^[[0m^[[31m03:53:31,766 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,766 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
^[[0m^[[31m03:53:31,766 ERROR [stderr] (default task-7)         at org.jboss.as\
.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(Com\
ponentDispatcherInterceptor.java:53)
^[[0m^[[31m03:53:31,766 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,766 ERROR [stderr] (default task-7)         at org.jboss.as\
.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstance\
Interceptor.java:51)
^[[0m^[[31m03:53:31,767 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,767 ERROR [stderr] (default task-7)         at org.jboss.as\
.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:251)
^[[0m^[[31m03:53:31,767 ERROR [stderr] (default task-7)         at org.jboss.as\
.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:342)
^[[0m^[[31m03:53:31,767 ERROR [stderr] (default task-7)         at org.jboss.as\
.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
^[[0m^[[31m03:53:31,767 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,767 ERROR [stderr] (default task-7)         at org.jboss.as\
.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocat\
ion(CurrentInvocationContextInterceptor.java:41)
^[[0m^[[31m03:53:31,768 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,768 ERROR [stderr] (default task-7)         at org.jboss.as\
.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTim\
eInterceptor.java:43)
^[[0m^[[31m03:53:31,768 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,768 ERROR [stderr] (default task-7)         at org.jboss.as\
.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInte\
rceptor.java:90)
^[[0m^[[31m03:53:31,768 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,768 ERROR [stderr] (default task-7)         at org.jboss.as\
.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(Shu\
tDownInterceptorFactory.java:64)
^[[0m^[[31m03:53:31,769 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,769 ERROR [stderr] (default task-7)         at org.jboss.as\
.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterc\
eptor.java:59)
^[[0m^[[31m03:53:31,769 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,769 ERROR [stderr] (default task-7)         at org.jboss.as\
.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInt\
erceptor.java:50)
^[[0m^[[31m03:53:31,769 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,769 ERROR [stderr] (default task-7)         at org.jboss.as\
.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55)
.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(Addit\
ionalSetupInterceptor.java:55)
^[[0m^[[31m03:53:31,770 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,770 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInte\
rceptor.java:55)
^[[0m^[[31m03:53:31,770 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,770 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.run(InterceptorContext.java:325)
^[[0m^[[31m03:53:31,770 ERROR [stderr] (default task-7)         at org.wildfly.\
security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:4\
19)
^[[0m^[[31m03:53:31,770 ERROR [stderr] (default task-7)         at org.wildfly.\
security.manager.AccessCheckingInterceptor.processInvocation(AccessCheckingInte\
rceptor.java:63)
^[[0m^[[31m03:53:31,771 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,771 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.run(InterceptorContext.java:325)
^[[0m^[[31m03:53:31,771 ERROR [stderr] (default task-7)         at java.securit\
y.AccessController.doPrivileged(Native Method)
^[[0m^[[31m03:53:31,771 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.PrivilegedInterceptor.processInvocation(PrivilegedInterceptor.java:75)
^[[0m^[[31m03:53:31,771 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,771 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
^[[0m^[[31m03:53:31,772 ERROR [stderr] (default task-7)         at org.jboss.as\
.ee.component.ViewService$View.invoke(ViewService.java:165)
^[[0m^[[31m03:53:31,772 ERROR [stderr] (default task-7)         at org.jboss.as\
.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
^[[0m^[[31m03:53:31,776 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,776 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
^[[0m^[[31m03:53:31,777 ERROR [stderr] (default task-7)         at org.jboss.as\
.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72)
^[[0m^[[31m03:53:31,777 ERROR [stderr] (default task-7)         at com.ecolane.\
mpk.frontend.beans.FrontendLiaisonLocal$$$view98.synchOneCustomerToFrontend(Unk\
nown Source)
^[[0m^[[31m03:53:31,777 ERROR [stderr] (default task-7)         at com.ecolane.\
mpk.apps.beans.ToolBackendBean.synchOneCustomerToFrontend(ToolBackendBean.java:\
717)
^[[0m^[[31m03:53:31,777 ERROR [stderr] (default task-7)         at sun.reflect.\
NativeMethodAccessorImpl.invoke0(Native Method)
^[[0m^[[31m03:53:31,777 ERROR [stderr] (default task-7)         at sun.reflect.\
NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
^[[0m^[[31m03:53:31,777 ERROR [stderr] (default task-7)         at sun.reflect.\
DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
^[[0m^[[31m03:53:31,777 ERROR [stderr] (default task-7)         at java.lang.re\
flect.Method.invoke(Method.java:601)
^[[0m^[[31m03:53:31,778 ERROR [stderr] (default task-7)         at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodIn\
terceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
^[[0m^[[31m03:53:31,778 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,778 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
^[[0m^[[31m03:53:31,778 ERROR [stderr] (default task-7)         at org.jboss.as\
.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInter\
ceptorFactory.java:63)
^[[0m^[[31m03:53:31,778 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,778 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
^[[0m^[[31m03:53:31,779 ERROR [stderr] (default task-7)         at org.jboss.as\
.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsIntercep\
tor.java:130)
^[[0m^[[31m03:53:31,779 ERROR [stderr] (default task-7)         at org.jboss.as\
.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor\
.java:138)
^[[0m^[[31m03:53:31,779 ERROR [stderr] (default task-7)         at org.jboss.as\
.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInter\
ceptorFactory.java:63)
^[[0m^[[31m03:53:31,779 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,779 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
^[[0m^[[31m03:53:31,779 ERROR [stderr] (default task-7)         at org.jboss.as\
.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInter\
ceptorFactory.java:63)
^[[0m^[[31m03:53:31,780 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,780 ERROR [stderr] (default task-7)         at org.jboss.as\
.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(Ex\
ecutionTimeInterceptor.java:43)
^[[0m^[[31m03:53:31,780 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,780 ERROR [stderr] (default task-7)         at org.jboss.as\
.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationIntercep\
tor.java:47)
^[[0m^[[31m03:53:31,780 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,780 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
^[[0m^[[31m03:53:31,780 ERROR [stderr] (default task-7)         at org.jboss.we\
ld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBReq\
uestScopeActivationInterceptor.java:46)
^[[0m^[[31m03:53:31,781 ERROR [stderr] (default task-7)         at org.jboss.as\
.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScop\
eActivationInterceptor.java:84)
^[[0m^[[31m03:53:31,781 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,781 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
^[[0m^[[31m03:53:31,781 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,781 ERROR [stderr] (default task-7)         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,781 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
^[[0m^[[31m03:53:31,781 ERROR [stderr] (default task-7)         at org.jboss.as\
.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(Com\
ponentDispatcherInterceptor.java:53)
^[[0m^[[31m03:53:31,782 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,782 ERROR [stderr] (default task-7)         at org.jboss.as\
.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstance\
Interceptor.java:51)
^[[0m^[[31m03:53:31,782 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,784 ERROR [stderr] (default task-7)         at org.jboss.as\
.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:251)
^[[0m^[[31m03:53:31,784 ERROR [stderr] (default task-7)         at org.jboss.as\
.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:342)
^[[0m^[[31m03:53:31,784 ERROR [stderr] (default task-7)         at org.jboss.as\
.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
^[[0m^[[31m03:53:31,784 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,785 ERROR [stderr] (default task-7)         at org.jboss.as\
.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocat\
ion(CurrentInvocationContextInterceptor.java:41)
^[[0m^[[31m03:53:31,785 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,785 ERROR [stderr] (default task-7)         at org.jboss.as\
.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTim\
eInterceptor.java:43)
^[[0m^[[31m03:53:31,785 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,785 ERROR [stderr] (default task-7)         at org.jboss.as\
.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInte\
rceptor.java:90)
^[[0m^[[31m03:53:31,785 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,786 ERROR [stderr] (default task-7)         at org.jboss.as\
.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(Shu\
tDownInterceptorFactory.java:64)
^[[0m^[[31m03:53:31,786 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,786 ERROR [stderr] (default task-7)         at org.jboss.as\
.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterc\
eptor.java:59)
^[[0m^[[31m03:53:31,786 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,786 ERROR [stderr] (default task-7)         at org.jboss.as\
.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInt\
erceptor.java:50)
^[[0m^[[31m03:53:31,786 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,786 ERROR [stderr] (default task-7)         at org.jboss.as\
.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(Addit\
ionalSetupInterceptor.java:55)
^[[0m^[[31m03:53:31,787 ERROR [stderr] (default task-7)         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,787 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,787 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInte\
rceptor.java:55)
^[[0m^[[31m03:53:31,787 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,787 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.run(InterceptorContext.java:325)
^[[0m^[[31m03:53:31,787 ERROR [stderr] (default task-7)         at org.wildfly.\
security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:4\
19)
^[[0m^[[31m03:53:31,787 ERROR [stderr] (default task-7)         at org.wildfly.\
security.manager.AccessCheckingInterceptor.processInvocation(AccessCheckingInte\
rceptor.java:63)
^[[0m^[[31m03:53:31,788 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,788 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.run(InterceptorContext.java:325)
^[[0m^[[31m03:53:31,788 ERROR [stderr] (default task-7)         at java.securit\
y.AccessController.doPrivileged(Native Method)
^[[0m^[[31m03:53:31,788 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.PrivilegedInterceptor.processInvocation(PrivilegedInterceptor.java:75)
^[[0m^[[31m03:53:31,788 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,788 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
^[[0m^[[31m03:53:31,788 ERROR [stderr] (default task-7)         at org.jboss.as\
.ee.component.ViewService$View.invoke(ViewService.java:165)
^[[0m^[[31m03:53:31,789 ERROR [stderr] (default task-7)         at org.jboss.as\
.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
^[[0m^[[31m03:53:31,789 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,789 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
^[[0m^[[31m03:53:31,789 ERROR [stderr] (default task-7)         at org.jboss.as\
.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72)
^[[0m^[[31m03:53:31,789 ERROR [stderr] (default task-7)         at com.ecolane.\
mpk.apps.interfaces.ToolBackendLocal$$$view1.synchOneCustomerToFrontend(Unknown\
 Source)
^[[0m^[[31m03:53:31,789 ERROR [stderr] (default task-7)         at com.ecolane.\
mpk.routing.beans.OrderingToolsBackendBean.persistUpdatedCustomerData(OrderingT\
oolsBackendBean.java:352)
^[[0m^[[31m03:53:31,790 ERROR [stderr] (default task-7)         at sun.reflect.\
NativeMethodAccessorImpl.invoke0(Native Method)
^[[0m^[[31m03:53:31,790 ERROR [stderr] (default task-7)         at sun.reflect.\
NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
^[[0m^[[31m03:53:31,790 ERROR [stderr] (default task-7)         at sun.reflect.\
DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
^[[0m^[[31m03:53:31,790 ERROR [stderr] (default task-7)         at java.lang.re\
flect.Method.invoke(Method.java:601)
^[[0m^[[31m03:53:31,790 ERROR [stderr] (default task-7)         at org.jboss.as\
.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodIn\
terceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
^[[0m^[[31m03:53:31,790 ERROR [stderr] (default task-7)         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,790 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,791 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
^[[0m^[[31m03:53:31,791 ERROR [stderr] (default task-7)         at org.jboss.as\
.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInter\
ceptorFactory.java:63)
^[[0m^[[31m03:53:31,791 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,791 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
^[[0m^[[31m03:53:31,791 ERROR [stderr] (default task-7)         at org.jboss.as\
.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsIntercep\
tor.java:130)
^[[0m^[[31m03:53:31,791 ERROR [stderr] (default task-7)         at org.jboss.as\
.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor\
.java:138)
^[[0m^[[31m03:53:31,791 ERROR [stderr] (default task-7)         at org.jboss.as\
.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInter\
ceptorFactory.java:63)
^[[0m^[[31m03:53:31,792 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,792 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
^[[0m^[[31m03:53:31,792 ERROR [stderr] (default task-7)         at org.jboss.as\
.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInter\
ceptorFactory.java:63)
^[[0m^[[31m03:53:31,792 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,792 ERROR [stderr] (default task-7)         at org.jboss.as\
.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(Ex\
ecutionTimeInterceptor.java:43)
^[[0m^[[31m03:53:31,792 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,793 ERROR [stderr] (default task-7)         at org.jboss.as\
.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationIntercep\
tor.java:47)
^[[0m^[[31m03:53:31,793 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,793 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
^[[0m^[[31m03:53:31,793 ERROR [stderr] (default task-7)         at org.jboss.we\
ld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBReq\
uestScopeActivationInterceptor.java:46)
^[[0m^[[31m03:53:31,793 ERROR [stderr] (default task-7)         at org.jboss.as\
.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScop\
eActivationInterceptor.java:84)
^[[0m^[[31m03:53:31,793 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,794 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
^[[0m^[[31m03:53:31,794 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,794 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
^[[0m^[[31m03:53:31,794 ERROR [stderr] (default task-7)         at org.jboss.asvocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
^[[0m^[[31m03:53:31,794 ERROR [stderr] (default task-7)         at org.jboss.as\
.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(Com\
ponentDispatcherInterceptor.java:53)
^[[0m^[[31m03:53:31,794 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,794 ERROR [stderr] (default task-7)         at org.jboss.as\
.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstance\
Interceptor.java:51)
^[[0m^[[31m03:53:31,794 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,795 ERROR [stderr] (default task-7)         at org.jboss.as\
.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:251)
^[[0m^[[31m03:53:31,795 ERROR [stderr] (default task-7)         at org.jboss.as\
.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:342)
^[[0m^[[31m03:53:31,795 ERROR [stderr] (default task-7)         at org.jboss.as\
.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
^[[0m^[[31m03:53:31,795 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,795 ERROR [stderr] (default task-7)         at org.jboss.as\
.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocat\
ion(CurrentInvocationContextInterceptor.java:41)
^[[0m^[[31m03:53:31,795 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,796 ERROR [stderr] (default task-7)         at org.jboss.as\
.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTim\
eInterceptor.java:43)
^[[0m^[[31m03:53:31,796 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,796 ERROR [stderr] (default task-7)         at org.jboss.as\
.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInte\
rceptor.java:90)
^[[0m^[[31m03:53:31,796 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,796 ERROR [stderr] (default task-7)         at org.jboss.as\
.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(Shu\
tDownInterceptorFactory.java:64)
^[[0m^[[31m03:53:31,796 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,796 ERROR [stderr] (default task-7)         at org.jboss.as\
.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterc\
eptor.java:59)
^[[0m^[[31m03:53:31,797 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,797 ERROR [stderr] (default task-7)         at org.jboss.as\
.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInt\
erceptor.java:50)
^[[0m^[[31m03:53:31,797 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,797 ERROR [stderr] (default task-7)         at org.jboss.as\
.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(Addit\
ionalSetupInterceptor.java:55)
^[[0m^[[31m03:53:31,797 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,797 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInte^[[0m^[[31m03:53:31,797 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInte\
rceptor.java:55)
^[[0m^[[31m03:53:31,798 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,798 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.run(InterceptorContext.java:325)
^[[0m^[[31m03:53:31,798 ERROR [stderr] (default task-7)         at org.wildfly.\
security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:4\
19)
^[[0m^[[31m03:53:31,798 ERROR [stderr] (default task-7)         at org.wildfly.\
security.manager.AccessCheckingInterceptor.processInvocation(AccessCheckingInte\
rceptor.java:63)
^[[0m^[[31m03:53:31,798 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,798 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.run(InterceptorContext.java:325)
^[[0m^[[31m03:53:31,799 ERROR [stderr] (default task-7)         at java.securit\
y.AccessController.doPrivileged(Native Method)
^[[0m^[[31m03:53:31,799 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.PrivilegedInterceptor.processInvocation(PrivilegedInterceptor.java:75)
^[[0m^[[31m03:53:31,799 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,799 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
^[[0m^[[31m03:53:31,799 ERROR [stderr] (default task-7)         at org.jboss.as\
.ee.component.ViewService$View.invoke(ViewService.java:165)
^[[0m^[[31m03:53:31,799 ERROR [stderr] (default task-7)         at org.jboss.as\
.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
^[[0m^[[31m03:53:31,799 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,802 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
^[[0m^[[31m03:53:31,809 ERROR [stderr] (default task-7)         at org.jboss.as\
.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72)
^[[0m^[[31m03:53:31,809 ERROR [stderr] (default task-7)         at com.ecolane.\
mpk.routing.interfaces.OrderingToolsBackendLocal$$$view72.persistUpdatedCustome\
rData(Unknown Source)
^[[0m^[[31m03:53:31,809 ERROR [stderr] (default task-7)         at com.ecolane.\
mpk.ccagent.beans.CcAgentBackendBean.persistUpdatedCustomerData(CcAgentBackendB\
ean.java:2534)
^[[0m^[[31m03:53:31,809 ERROR [stderr] (default task-7)         at sun.reflect.\
NativeMethodAccessorImpl.invoke0(Native Method)
^[[0m^[[31m03:53:31,809 ERROR [stderr] (default task-7)         at sun.reflect.\
NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
^[[0m^[[31m03:53:31,809 ERROR [stderr] (default task-7)         at sun.reflect.\
DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
^[[0m^[[31m03:53:31,810 ERROR [stderr] (default task-7)         at java.lang.re\
flect.Method.invoke(Method.java:601)
^[[0m^[[31m03:53:31,810 ERROR [stderr] (default task-7)         at org.jboss.as\
.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodIn\
terceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
^[[0m^[[31m03:53:31,810 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,810 ERROR [stderr] (default task-7)         at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
^[[0m^[[31m03:53:31,810 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
^[[0m^[[31m03:53:31,810 ERROR [stderr] (default task-7)         at org.jboss.as\
.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInter\
ceptorFactory.java:63)
^[[0m^[[31m03:53:31,810 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,811 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
^[[0m^[[31m03:53:31,811 ERROR [stderr] (default task-7)         at org.jboss.as\
.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsIntercep\
tor.java:130)
^[[0m^[[31m03:53:31,811 ERROR [stderr] (default task-7)         at org.jboss.as\
.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor\
.java:138)
^[[0m^[[31m03:53:31,811 ERROR [stderr] (default task-7)         at org.jboss.as\
.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInter\
ceptorFactory.java:63)
^[[0m^[[31m03:53:31,811 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,811 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
^[[0m^[[31m03:53:31,812 ERROR [stderr] (default task-7)         at org.jboss.as\
.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInter\
ceptorFactory.java:63)
^[[0m^[[31m03:53:31,812 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,812 ERROR [stderr] (default task-7)         at org.jboss.as\
.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(Ex\
ecutionTimeInterceptor.java:43)
^[[0m^[[31m03:53:31,812 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,812 ERROR [stderr] (default task-7)         at org.jboss.as\
.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationIntercep\
tor.java:47)
^[[0m^[[31m03:53:31,812 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,812 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
^[[0m^[[31m03:53:31,813 ERROR [stderr] (default task-7)         at org.jboss.we\
ld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBReq\
uestScopeActivationInterceptor.java:55)
^[[0m^[[31m03:53:31,813 ERROR [stderr] (default task-7)         at org.jboss.as\
.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScop\
eActivationInterceptor.java:84)
^[[0m^[[31m03:53:31,813 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,813 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
^[[0m^[[31m03:53:31,813 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,813 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
^[[0m^[[31m03:53:31,813 ERROR [stderr] (default task-7)         at org.jboss.as\
.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
^[[0m^[[31m03:53:31,814 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,814 ERROR [stderr] (default task-7)         at org.jboss.as\
.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstance\
Interceptor.java:51)
^[[0m^[[31m03:53:31,814 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,814 ERROR [stderr] (default task-7)         at org.jboss.as\
.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:273)
^[[0m^[[31m03:53:31,814 ERROR [stderr] (default task-7)         at org.jboss.as\
.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340)
^[[0m^[[31m03:53:31,814 ERROR [stderr] (default task-7)         at org.jboss.as\
.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
^[[0m^[[31m03:53:31,815 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,815 ERROR [stderr] (default task-7)         at org.jboss.as\
.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocat\
ion(CurrentInvocationContextInterceptor.java:41)
^[[0m^[[31m03:53:31,815 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,815 ERROR [stderr] (default task-7)         at org.jboss.as\
.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTim\
eInterceptor.java:43)
^[[0m^[[31m03:53:31,815 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,815 ERROR [stderr] (default task-7)         at org.jboss.as\
.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInte\
rceptor.java:90)
^[[0m^[[31m03:53:31,815 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,816 ERROR [stderr] (default task-7)         at org.jboss.as\
.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(Shu\
tDownInterceptorFactory.java:64)
^[[0m^[[31m03:53:31,816 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,816 ERROR [stderr] (default task-7)         at org.jboss.as\
.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterc\
eptor.java:59)
^[[0m^[[31m03:53:31,816 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,816 ERROR [stderr] (default task-7)         at org.jboss.as\
.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInt\
erceptor.java:50)
^[[0m^[[31m03:53:31,816 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,817 ERROR [stderr] (default task-7)         at org.jboss.as\
.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(Addit\
ionalSetupInterceptor.java:55)
^[[0m^[[31m03:53:31,817 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,817 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInte\
rceptor.java:55)
^[[0m^[[31m03:53:31,817 ERROR [stderr] (default task-7)         at org.jboss.inrceptor.java:55)
^[[0m^[[31m03:53:31,817 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,817 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.run(InterceptorContext.java:325)
^[[0m^[[31m03:53:31,817 ERROR [stderr] (default task-7)         at org.wildfly.\
security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:4\
28)
^[[0m^[[31m03:53:31,817 ERROR [stderr] (default task-7)         at org.wildfly.\
security.manager.AccessCheckingInterceptor.processInvocation(AccessCheckingInte\
rceptor.java:63)
^[[0m^[[31m03:53:31,818 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,818 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.run(InterceptorContext.java:325)
^[[0m^[[31m03:53:31,818 ERROR [stderr] (default task-7)         at java.securit\
y.AccessController.doPrivileged(Native Method)
^[[0m^[[31m03:53:31,818 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.PrivilegedInterceptor.processInvocation(PrivilegedInterceptor.java:75)
^[[0m^[[31m03:53:31,818 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,818 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
^[[0m^[[31m03:53:31,818 ERROR [stderr] (default task-7)         at org.jboss.as\
.ee.component.ViewService$View.invoke(ViewService.java:165)
^[[0m^[[31m03:53:31,819 ERROR [stderr] (default task-7)         at org.jboss.as\
.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
^[[0m^[[31m03:53:31,819 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.InterceptorContext.proceed(InterceptorContext.java:309)
^[[0m^[[31m03:53:31,819 ERROR [stderr] (default task-7)         at org.jboss.in\
vocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
^[[0m^[[31m03:53:31,819 ERROR [stderr] (default task-7)         at org.jboss.as\
.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72)
^[[0m^[[31m03:53:31,819 ERROR [stderr] (default task-7)         at com.ecolane.\
mpk.ccagent.interfaces.CcAgentBackendLocal$$$view33.persistUpdatedCustomerData(\
Unknown Source)
^[[0m^[[31m03:53:31,819 ERROR [stderr] (default task-7)         at com.ecolane.\
mpk.ccagent.pages.ClientProfileEdit.save(ClientProfileEdit.java:553)
^[[0m^[[31m03:53:31,820 ERROR [stderr] (default task-7)         at sun.reflect.\
NativeMethodAccessorImpl.invoke0(Native Method)
^[[0m^[[31m03:53:31,820 ERROR [stderr] (default task-7)         at sun.reflect.\
NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
^[[0m^[[31m03:53:31,820 ERROR [stderr] (default task-7)         at sun.reflect.\
DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
^[[0m^[[31m03:53:31,820 ERROR [stderr] (default task-7)         at java.lang.re\
flect.Method.invoke(Method.java:601)
^[[0m^[[31m03:53:31,820 ERROR [stderr] (default task-7)         at org.apache.t\
apestry.listener.ListenerMethodInvokerImpl.invokeTargetMethod(ListenerMethodInv\
okerImpl.java:276)
^[[0m^[[31m03:53:31,820 ERROR [stderr] (default task-7)         at org.apache.t\
apestry.listener.ListenerMethodInvokerImpl.invokeListenerMethod(ListenerMethodI\
nvokerImpl.java:221)
^[[0m^[[31m03:53:31,820 ERROR [stderr] (default task-7)         at org.apache.t\
apestry.listener.ListenerMethodInvokerImpl.searchAndInvoke(ListenerMethodInvoke\
rImpl.java:157)
^[[0m^[[31m03:53:31,821 ERROR [stderr] (default task-7)         at org.apache.trImpl.java:157)
^[[0m^[[31m03:53:31,821 ERROR [stderr] (default task-7)         at org.apache.t\
apestry.listener.ListenerMethodInvokerImpl.invokeListenerMethod(ListenerMethodI\
nvokerImpl.java:80)
^[[0m^[[31m03:53:31,821 ERROR [stderr] (default task-7)         at org.apache.t\
apestry.listener.SyntheticListener.actionTriggered(SyntheticListener.java:52)
^[[0m^[[31m03:53:31,821 ERROR [stderr] (default task-7)         at org.apache.t\
apestry.binding.ListenerMethodBinding.actionTriggered(ListenerMethodBinding.jav\
a:77)
^[[0m^[[31m03:53:31,821 ERROR [stderr] (default task-7)         at org.apache.t\
apestry.listener.ListenerInvokerTerminator.invokeListener(ListenerInvokerTermin\
ator.java:50)
^[[0m^[[31m03:53:31,821 ERROR [stderr] (default task-7)         at $ListenerInv\
oker_141a6814600.invokeListener($ListenerInvoker_141a6814600.java)
^[[0m^[[31m03:53:31,821 ERROR [stderr] (default task-7)         at org.apache.t\
apestry.form.AbstractSubmit$1.run(AbstractSubmit.java:106)
^[[0m^[[31m03:53:31,822 ERROR [stderr] (default task-7)         at org.apache.t\
apestry.form.FormSupportImpl.runDeferredRunnables(FormSupportImpl.java:673)
^[[0m^[[31m03:53:31,822 ERROR [stderr] (default task-7)         at org.apache.t\
apestry.form.FormSupportImpl.rewind(FormSupportImpl.java:646)
^[[0m^[[31m03:53:31,822 ERROR [stderr] (default task-7)         at org.apache.t\
apestry.form.Form.renderComponent(Form.java:196)
^[[0m^[[31m03:53:31,822 ERROR [stderr] (default task-7)         at org.apache.t\
apestry.AbstractComponent.render(AbstractComponent.java:724)
^[[0m^[[31m03:53:31,822 ERROR [stderr] (default task-7)         at org.apache.t\
apestry.services.impl.DefaultResponseBuilder.render(DefaultResponseBuilder.java\
:187)
^[[0m^[[31m03:53:31,822 ERROR [stderr] (default task-7)         at org.apache.t\
apestry.form.Form.rewind(Form.java:269)
^[[0m^[[31m03:53:31,822 ERROR [stderr] (default task-7)         at org.apache.t\
apestry.engine.RequestCycle.rewindForm(RequestCycle.java:469)
^[[0m^[[31m03:53:31,823 ERROR [stderr] (default task-7)         at org.apache.t\
apestry.form.Form.trigger(Form.java:280)
^[[0m^[[31m03:53:31,823 ERROR [stderr] (default task-7)         at org.apache.t\
apestry.engine.DirectService.triggerComponent(DirectService.java:166)
^[[0m^[[31m03:53:31,823 ERROR [stderr] (default task-7)         at org.apache.t\
apestry.engine.DirectService.service(DirectService.java:142)
^[[0m^[[31m03:53:31,823 ERROR [stderr] (default task-7)         at $IEngineServ\
ice_141a6814679.service($IEngineService_141a6814679.java)
^[[0m^[[31m03:53:31,823 ERROR [stderr] (default task-7)         at org.apache.t\
apestry.services.impl.EngineServiceOuterProxy.service(EngineServiceOuterProxy.j\
ava:72)
^[[0m^[[31m03:53:31,823 ERROR [stderr] (default task-7)         at org.apache.t\
apestry.engine.AbstractEngine.service(AbstractEngine.java:241)
^[[0m^[[31m03:53:31,823 ERROR [stderr] (default task-7)         at org.apache.t\
apestry.services.impl.InvokeEngineTerminator.service(InvokeEngineTerminator.jav\
a:54)
^[[0m^[[31m03:53:31,824 ERROR [stderr] (default task-7)         at $WebRequestS\
ervicer_141a6814652.service($WebRequestServicer_141a6814652.java)
^[[0m^[[31m03:53:31,824 ERROR [stderr] (default task-7)         at $WebRequestS\
ervicer_141a681464e.service($WebRequestServicer_141a681464e.java)
^[[0m^[[31m03:53:31,824 ERROR [stderr] (default task-7)         at org.apache.t\
apestry.services.impl.WebRequestServicerPipelineBridge.service(WebRequestServic\
erPipelineBridge.java:61)
^[[0m^[[31m03:53:31,824 ERROR [stderr] (default task-7)         at $ServletRequ\
estServicer_141a6814634.service($ServletRequestServicer_141a6814634.java)

^[[0m^[[31m03:53:31,824 ERROR [stderr] (default task-7)         at $ServletRequ\
estServicer_141a6814634.service($ServletRequestServicer_141a6814634.java)
^[[0m^[[31m03:53:31,824 ERROR [stderr] (default task-7)         at org.apache.t\
apestry.request.DecodedRequestInjector.service(DecodedRequestInjector.java:55)
^[[0m^[[31m03:53:31,824 ERROR [stderr] (default task-7)         at $ServletRequ\
estServicerFilter_141a6814630.service($ServletRequestServicerFilter_141a6814630\
.java)
^[[0m^[[31m03:53:31,825 ERROR [stderr] (default task-7)         at $ServletRequ\
estServicer_141a6814636.service($ServletRequestServicer_141a6814636.java)
^[[0m^[[31m03:53:31,825 ERROR [stderr] (default task-7)         at org.apache.t\
apestry.multipart.MultipartDecoderFilter.service(MultipartDecoderFilter.java:52\
)
^[[0m^[[31m03:53:31,825 ERROR [stderr] (default task-7)         at $ServletRequ\
estServicerFilter_141a681462e.service($ServletRequestServicerFilter_141a681462e\
.java)
^[[0m^[[31m03:53:31,825 ERROR [stderr] (default task-7)         at $ServletRequ\
estServicer_141a6814636.service($ServletRequestServicer_141a6814636.java)
^[[0m^[[31m03:53:31,825 ERROR [stderr] (default task-7)         at org.apache.t\
apestry.services.impl.SetupRequestEncoding.service(SetupRequestEncoding.java:53\
)
^[[0m^[[31m03:53:31,825 ERROR [stderr] (default task-7)         at $ServletRequ\
estServicerFilter_141a6814632.service($ServletRequestServicerFilter_141a6814632\
.java)
^[[0m^[[31m03:53:31,825 ERROR [stderr] (default task-7)         at $ServletRequ\
estServicer_141a6814636.service($ServletRequestServicer_141a6814636.java)
^[[0m^[[31m03:53:31,826 ERROR [stderr] (default task-7)         at $ServletRequ\
estServicer_141a6814628.service($ServletRequestServicer_141a6814628.java)
^[[0m^[[31m03:53:31,826 ERROR [stderr] (default task-7)         at org.apache.t\
apestry.ApplicationServlet.doService(ApplicationServlet.java:126)
^[[0m^[[31m03:53:31,826 ERROR [stderr] (default task-7)         at org.apache.t\
apestry.ApplicationServlet.doPost(ApplicationServlet.java:171)
^[[0m^[[31m03:53:31,826 ERROR [stderr] (default task-7)         at javax.servle\
t.http.HttpServlet.service(HttpServlet.java:707)
^[[0m^[[31m03:53:31,826 ERROR [stderr] (default task-7)         at javax.servle\
t.http.HttpServlet.service(HttpServlet.java:790)
^[[0m^[[31m03:53:31,826 ERROR [stderr] (default task-7)         at io.undertow.\
servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87)
^[[0m^[[31m03:53:31,827 ERROR [stderr] (default task-7)         at io.undertow.\
servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130)
^[[0m^[[31m03:53:31,827 ERROR [stderr] (default task-7)         at io.undertow.\
websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136)
^[[0m^[[31m03:53:31,827 ERROR [stderr] (default task-7)         at io.undertow.\
servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56)
^[[0m^[[31m03:53:31,827 ERROR [stderr] (default task-7)         at io.undertow.\
servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
^[[0m^[[31m03:53:31,827 ERROR [stderr] (default task-7)         at io.undertow.\
websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136)
^[[0m^[[31m03:53:31,827 ERROR [stderr] (default task-7)         at io.undertow.\
servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56)
^[[0m^[[31m03:53:31,827 ERROR [stderr] (default task-7)         at io.undertow.\
servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
^[[0m^[[31m03:53:31,828 ERROR [stderr] (default task-7)         at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
^[[0m^[[31m03:53:31,828 ERROR [stderr] (default task-7)         at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:56)
^[[0m^[[31m03:53:31,828 ERROR [stderr] (default task-7)         at io.undertow.\
servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHand\
ler.java:36)
^[[0m^[[31m03:53:31,828 ERROR [stderr] (default task-7)         at org.wildfly.\
extension.undertow.security.SecurityContextAssociationHandler.handleRequest(Sec\
urityContextAssociationHandler.java:78)
^[[0m^[[31m03:53:31,828 ERROR [stderr] (default task-7)         at io.undertow.\
servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInf\
ormationAssociationHandler.java:113)
^[[0m^[[31m03:53:31,828 ERROR [stderr] (default task-7)         at io.undertow.\
security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHan\
dler.java:52)
^[[0m^[[31m03:53:31,829 ERROR [stderr] (default task-7)         at io.undertow.\
security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfiden\
tialityHandler.java:45)
^[[0m^[[31m03:53:31,829 ERROR [stderr] (default task-7)         at io.undertow.\
servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(Cache\
dAuthenticatedSessionHandler.java:65)
^[[0m^[[31m03:53:31,829 ERROR [stderr] (default task-7)         at io.undertow.\
security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.j\
ava:70)
^[[0m^[[31m03:53:31,829 ERROR [stderr] (default task-7)         at io.undertow.\
server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
^[[0m^[[31m03:53:31,829 ERROR [stderr] (default task-7)         at org.wildfly.\
extension.undertow.security.SecurityContextCreationHandler.handleRequest(Securi\
tyContextCreationHandler.java:54)
^[[0m^[[31m03:53:31,829 ERROR [stderr] (default task-7)         at io.undertow.\
server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
^[[0m^[[31m03:53:31,830 ERROR [stderr] (default task-7)         at io.undertow.\
servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler\
.java:207)
^[[0m^[[31m03:53:31,830 ERROR [stderr] (default task-7)         at io.undertow.\
servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.ja\
va:194)
^[[0m^[[31m03:53:31,830 ERROR [stderr] (default task-7)         at io.undertow.\
servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:72\
)
^[[0m^[[31m03:53:31,830 ERROR [stderr] (default task-7)         at io.undertow.\
servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.ja\
va:128)
^[[0m^[[31m03:53:31,830 ERROR [stderr] (default task-7)         at io.undertow.\
server.HttpHandlers.executeRootHandler(HttpHandlers.java:36)
^[[0m^[[31m03:53:31,830 ERROR [stderr] (default task-7)         at io.undertow.\
server.HttpServerExchange$1.run(HttpServerExchange.java:628)
^[[0m^[[31m03:53:31,830 ERROR [stderr] (default task-7)         at java.util.co\
ncurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
^[[0m^[[31m03:53:31,831 ERROR [stderr] (default task-7)         at java.util.co\
ncurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
^[[0m^[[31m03:53:31,831 ERROR [stderr] (default task-7)         at java.lang.Th\
read.run(Thread.java:722)
^[[0m^[[33m03:53:31,832 WARN  [org.hibernate.engine.jdbc.spi.SqlExceptionHelper\
] (default task-7) SQL Error: 0, SQLState: null
^[[0m^[[31m03:53:31,832 ERROR [org.hibernate.engine.jdbc.spi.SqlExceptionHelper\
] (default task-7) javax.resource.ResourceException: IJ000457: Unchecked throwable in managedConnectionReconnected() cl=org.jboss.jca.core.connectionmanager.l\
istener.TxConnectionListener at 3bd9aed0[state=NORMAL managed connection=org.jboss\
.jca.adapters.jdbc.xa.XAManagedConnection at ca83b59 connection handles=0 lastUse=\
1381478011832 trackByTx=false pool=org.jboss.jca.core.connectionmanager.pool.st\
rategy.OnePool at 166e94c2 pool internal context=SemaphoreArrayListManagedConnecti\
onPool at 6a594c6b[pool=MpkDemoUsFrontendDS] xaResource=XAResourceWrapperImpl at 35e8\
580f[xaResource=org.jboss.jca.adapters.jdbc.xa.XAManagedConnection at ca83b59 pad=\
false overrideRmValue=null productName=MySQL productVersion=5.5.24-5-log jndiNa\
me=java:/FrontendDS] txSync=null]
^[[0m^[[31m03:53:31,835 ERROR [org.jboss.as.ejb3] (default task-7) javax.ejb.EJ\
BTransactionRolledbackException: org.hibernate.exception.GenericJDBCException: \
Could not open connection
^[[0m^[[31m03:53:31,836 ERROR [org.jboss.as.ejb3.invocation] (default task-7) J\
BAS014134: EJB Invocation failed on component FrontendLiaisonBean for method pu\
blic abstract void com.ecolane.mpk.frontend.beans.FrontendLiaisonLocal.synchOne\
CustomerToFrontend(com.ecolane.mpk.persistence.Customer): javax.ejb.EJBTransact\
ionRolledbackException: org.hibernate.exception.GenericJDBCException: Could not\
 open connection
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleInCallerTx(CMTTxIntercep\
tor.java:163) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxIntercep\
tor.java:253) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java\
:342) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterce\
ptor.java:239) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInt\
erceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfl\
y-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.pr\
ocessInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0\
.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocat\
ion(SecurityContextInterceptor.java:90) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Al\
pha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$\
1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Alp\
ha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processI\
nvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alph\
a4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocatava:309)
        at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocat\
ion(NamespaceContextInterceptor.java:50)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.\
processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Alpha\
4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation\
(ContextClassLoaderInterceptor.java:55)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:\
325)
        at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFl\
ySecurityManager.java:419)
        at org.wildfly.security.manager.AccessCheckingInterceptor.processInvoca\
tion(AccessCheckingInterceptor.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:\
325)
        at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1\
.7.0_03]
        at org.jboss.invocation.PrivilegedInterceptor.processInvocation(Privile\
gedInterceptor.java:75)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInt\
erceptor.java:61)
        at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:1\
65)
        at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDe\
scription.java:182)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInt\
erceptor.java:61)
        at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocat\
ionHandler.java:72)
        at com.ecolane.mpk.frontend.beans.FrontendLiaisonLocal$$$view98.synchOn\
eCustomerToFrontend(Unknown Source) [k3-main.jar:]
        at com.ecolane.mpk.apps.beans.ToolBackendBean.synchOneCustomerToFronten\
d(ToolBackendBean.java:717) [k3-main.jar:]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:\
1.7.0_03]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl\
.java:57) [rt.jar:1.7.0_03]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcce\
ssorImpl.java:43) [rt.jar:1.7.0_03]
        at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_03]
        at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInter\
ceptor.java:53)
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.proc\
essInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext$Invocation.proceed(Intercept\
orContext.java:406)
        at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception\
(Jsr299BindingsInterceptor.java:130) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha\
4]
        at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Js\
r299BindingsInterceptor.java:138) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.proc\
essInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInter\
ceptor.java:53)
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.proc\
essInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeIntercept\
or.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alph\
a4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocati\
on(SBInvocationInterceptor.java:47) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext$Invocation.proceed(Intercept\
orContext.java:406)
        at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.arou\
ndInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46) [weld-core-impl-\
2.0.3.Final.jar:2013-07-17 09:29]
        at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processIn\
vocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.Alph\
a4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInt\
erceptor.java:21)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInt\
erceptor.java:61)
        at org.jboss.as.ee.component.interceptors.ComponentDispatcherIntercepto\
r.processInvocation(ComponentDispatcherInterceptor.java:53)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processIn\
vocation(PooledInstanceInterceptor.java:51) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.\
0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxIntercep\
tor.java:251) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java\
:342) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterce\
ptor.java:239) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInt\
erceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfl\
y-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.pr\
ocessInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0\
.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocat\
ion(SecurityContextInterceptor.java:90) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Al\
pha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$\
1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Alp\
ha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processI\
nvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alph\
a4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocat\
ion(NamespaceContextInterceptor.java:50)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.\
processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Alpha\
4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation\
(ContextClassLoaderInterceptor.java:55)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:\
325)
        at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFl325)
        at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFl\
ySecurityManager.java:419)
        at org.wildfly.security.manager.AccessCheckingInterceptor.processInvoca\
tion(AccessCheckingInterceptor.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:\
325)
        at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1\
.7.0_03]
        at org.jboss.invocation.PrivilegedInterceptor.processInvocation(Privile\
gedInterceptor.java:75)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInt\
erceptor.java:61)
        at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:1\
65)
        at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDe\
scription.java:182)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInt\
erceptor.java:61)
        at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocat\
ionHandler.java:72)
        at com.ecolane.mpk.apps.interfaces.ToolBackendLocal$$$view1.synchOneCus\
tomerToFrontend(Unknown Source) [k3-main.jar:]
        at com.ecolane.mpk.routing.beans.OrderingToolsBackendBean.persistUpdate\
dCustomerData(OrderingToolsBackendBean.java:352) [k3-main.jar:]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:\
1.7.0_03]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl\
.java:57) [rt.jar:1.7.0_03]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcce\
ssorImpl.java:43) [rt.jar:1.7.0_03]
        at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_03]
        at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$M\
anagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterc\
eptorFactory.java:72)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInter\
ceptor.java:53)
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.proc\
essInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext$Invocation.proceed(Intercept\
orContext.java:406)
        at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception\
(Jsr299BindingsInterceptor.java:130) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha\
4]
        at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Js\
r299BindingsInterceptor.java:138) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Js\
r299BindingsInterceptor.java:138) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.proc\
essInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInter\
ceptor.java:53)
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.proc\
essInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeIntercept\
or.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alph\
a4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocati\
on(SBInvocationInterceptor.java:47) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext$Invocation.proceed(Intercept\
orContext.java:406)
        at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.arou\
ndInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46) [weld-core-impl-\
2.0.3.Final.jar:2013-07-17 09:29]
        at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processIn\
vocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.Alph\
a4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInt\
erceptor.java:21)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInt\
erceptor.java:61)
        at org.jboss.as.ee.component.interceptors.ComponentDispatcherIntercepto\
r.processInvocation(ComponentDispatcherInterceptor.java:53)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processIn\
vocation(PooledInstanceInterceptor.java:51) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.\
0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxIntercep\
tor.java:251) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java\
:342) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterce\
ptor.java:239) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInt\
erceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfl        at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInt\
erceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfl\
y-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.pr\
ocessInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0\
.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocat\
ion(SecurityContextInterceptor.java:90) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Al\
pha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$\
1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Alp\
ha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processI\
nvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alph\
a4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocat\
ion(NamespaceContextInterceptor.java:50)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.\
processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Alpha\
4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation\
(ContextClassLoaderInterceptor.java:55)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:\
325)
        at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFl\
ySecurityManager.java:419)
        at org.wildfly.security.manager.AccessCheckingInterceptor.processInvoca\
tion(AccessCheckingInterceptor.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:\
325)
        at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1\
.7.0_03]
        at org.jboss.invocation.PrivilegedInterceptor.processInvocation(Privile\
gedInterceptor.java:75)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInt\
erceptor.java:61)
        at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:1\
65)
        at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDe\
scription.java:182)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInt\
erceptor.java:61)
        at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocat\
ionHandler.java:72)
        at com.ecolane.mpk.routing.interfaces.OrderingToolsBackendLocal$$$view7\
2.persistUpdatedCustomerData(Unknown Source) [k3-main.jar:]
        at com.ecolane.mpk.ccagent.beans.CcAgentBackendBean.persistUpdatedCusto\
merData(CcAgentBackendBean.java:2534) [k3-main.jar:]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:\
1.7.0_03]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl\
.java:57) [rt.jar:1.7.0_03]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcce\
ssorImpl.java:43) [rt.jar:1.7.0_03]
        at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_03]
        at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$M\
anagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterc\
eptorFactory.java:72)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInter\
ceptor.java:53)
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.proc\
essInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext$Invocation.proceed(Intercept\
orContext.java:406)
        at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception\
(Jsr299BindingsInterceptor.java:130) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha\
4]
        at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Js\
r299BindingsInterceptor.java:138) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.proc\
essInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInter\
ceptor.java:53)
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.proc\
essInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeIntercept\
or.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alph\
a4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocati\
on(SBInvocationInterceptor.java:47) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext$Invocation.proceed(Intercept\
orContext.java:406)
        at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.arou\
ndInvoke(AbstractEJBRequestScopeActivationInterceptor.java:55) [weld-core-impl-\
2.0.3.Final.jar:2013-07-17 09:29]
        at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processIn\
vocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.Alph\
a4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInt\
erceptor.java:21)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInt\
erceptor.java:61)
        at org.jboss.as.ee.component.interceptors.ComponentDispatcherIntercepto\
r.processInvocation(ComponentDispatcherInterceptor.java:53)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processIn\
vocation(PooledInstanceInterceptor.java:51) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.\
0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor\
.java:273) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java\
:340) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterce\
ptor.java:239) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInt\
erceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfl\
y-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.pr\
ocessInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0\
.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocat\
ion(SecurityContextInterceptor.java:90) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Al\
pha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$\
1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Alp        at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$\
1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Alp\
ha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processI\
nvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alph\
a4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocat\
ion(NamespaceContextInterceptor.java:50)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.\
processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Alpha\
4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation\
(ContextClassLoaderInterceptor.java:55)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:\
325)
        at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFl\
ySecurityManager.java:428)
        at org.wildfly.security.manager.AccessCheckingInterceptor.processInvoca\
tion(AccessCheckingInterceptor.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:\
325)
        at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1\
.7.0_03]
        at org.jboss.invocation.PrivilegedInterceptor.processInvocation(Privile\
gedInterceptor.java:75)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInt\
erceptor.java:61)
        at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:1\
65)
        at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDe\
scription.java:182)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInt\
erceptor.java:61)
        at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocat\
ionHandler.java:72)
        at com.ecolane.mpk.ccagent.interfaces.CcAgentBackendLocal$$$view33.pers\
istUpdatedCustomerData(Unknown Source) [k3-main.jar:]
        at com.ecolane.mpk.ccagent.pages.ClientProfileEdit.save(ClientProfileEd\
it.java:553)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:it.java:553)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:\
1.7.0_03]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl\
.java:57) [rt.jar:1.7.0_03]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcce\
ssorImpl.java:43) [rt.jar:1.7.0_03]
        at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_03]
        at org.apache.tapestry.listener.ListenerMethodInvokerImpl.invokeTargetM\
ethod(ListenerMethodInvokerImpl.java:276) [tapestry-framework-4.1.7-SNAPSHOT.ja\
r:4.1.7-SNAPSHOT]
        at org.apache.tapestry.listener.ListenerMethodInvokerImpl.invokeListene\
rMethod(ListenerMethodInvokerImpl.java:221) [tapestry-framework-4.1.7-SNAPSHOT.\
jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.listener.ListenerMethodInvokerImpl.searchAndInvo\
ke(ListenerMethodInvokerImpl.java:157) [tapestry-framework-4.1.7-SNAPSHOT.jar:4\
.1.7-SNAPSHOT]
        at org.apache.tapestry.listener.ListenerMethodInvokerImpl.invokeListene\
rMethod(ListenerMethodInvokerImpl.java:80) [tapestry-framework-4.1.7-SNAPSHOT.j\
ar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.listener.SyntheticListener.actionTriggered(Synth\
eticListener.java:52) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.binding.ListenerMethodBinding.actionTriggered(Li\
stenerMethodBinding.java:77) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPS\
HOT]
        at org.apache.tapestry.listener.ListenerInvokerTerminator.invokeListene\
r(ListenerInvokerTerminator.java:50) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1\
.7-SNAPSHOT]
        at $ListenerInvoker_141a6814600.invokeListener($ListenerInvoker_141a681\
4600.java)       at org.apache.tapestry.form.AbstractSubmit$1.run(AbstractSubmi\
t.java:106) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.form.FormSupportImpl.runDeferredRunnables(FormSu\
pportImpl.java:673) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.form.FormSupportImpl.rewind(FormSupportImpl.java\
:646) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.form.Form.renderComponent(Form.java:196) [tapest\
ry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.AbstractComponent.render(AbstractComponent.java:\
724) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.services.impl.DefaultResponseBuilder.render(Defa\
ultResponseBuilder.java:187) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPS\
HOT]
        at org.apache.tapestry.form.Form.rewind(Form.java:269) [tapestry-framew\
ork-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.engine.RequestCycle.rewindForm(RequestCycle.java\
:469) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.form.Form.trigger(Form.java:280) [tapestry-frame\
work-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.engine.DirectService.triggerComponent(DirectServ\
ice.java:166) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.engine.DirectService.service(DirectService.java:\
142) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at $IEngineService_141a6814679.service($IEngineService_141a6814679.java\
)        at org.apache.tapestry.services.impl.EngineServiceOuterProxy.service(E\
ngineServiceOuterProxy.java:72) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.engine.AbstractEngine.service(AbstractEngine.jav\
a:241) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.services.impl.InvokeEngineTerminator.service(Inv\
okeEngineTerminator.java:54) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPS\
HOT]
        at $WebRequestServicer_141a6814652.service($WebRequestServicer_141a6814\
652.java)        at $WebRequestServicer_141a681464e.service($WebRequestServicer\
_141a681464e.java)        at org.apache.tapestry.services.impl.WebRequestServic\
erPipelineBridge.service(WebRequestServicerPipelineBridge.java:61) [tapestry-fr\
amework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at $ServletRequestServicer_141a6814634.service($ServletRequestServicer_\
141a6814634.java)        at org.apache.tapestry.request.DecodedRequestInjector.\
service(DecodedRequestInjector.java:55) [tapestry-framework-4.1.7-SNAPSHOT.jar:\
4.1.7-SNAPSHOT]
        at $ServletRequestServicerFilter_141a6814630.service($ServletRequestSer\
vicerFilter_141a6814630.java)    at $ServletRequestServicer_141a6814636.service\
($ServletRequestServicer_141a6814636.java)        at org.apache.tapestry.multip\
art.MultipartDecoderFilter.service(MultipartDecoderFilter.java:52) [tapestry-fr\
amework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at $ServletRequestServicerFilter_141a681462e.service($ServletRequestSer\
vicerFilter_141a681462e.java)    at $ServletRequestServicer_141a6814636.service\
($ServletRequestServicer_141a6814636.java)        at org.apache.tapestry.servic\
es.impl.SetupRequestEncoding.service(SetupRequestEncoding.java:53) [tapestry-fr\
amework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at $ServletRequestServicerFilter_141a6814632.service($ServletRequestSer\
vicerFilter_141a6814632.java)    at $ServletRequestServicer_141a6814636.service\
($ServletRequestServicer_141a6814636.java)        at $ServletRequestServicer_14\
1a6814628.service($ServletRequestServicer_141a6814628.java)        at org.apach\
e.tapestry.ApplicationServlet.doService(ApplicationServlet.java:126) [tapestry-\
framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.ApplicationServlet.doPost(ApplicationServlet.jav\
a:171) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) [jboss-\
servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-\
servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
        at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHan\
dler.java:87)
        at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(\
FilterHandler.java:130)
        at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketF\
ilter.java:136)
        at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:5\
6)
        at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(\
FilterHandler.java:132)
        at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketF\
ilter.java:136)
        at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:5\
6)
        at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(\
FilterHandler.java:132)
        at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandl\
er.java:85)
        at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.han\
dleRequest(ServletSecurityRoleHandler.java:56)
        at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest\
(ServletDispatchingHandler.java:36)
        at org.wildfly.extension.undertow.security.SecurityContextAssociationHa\
ndler.handleRequest(SecurityContextAssociationHandler.java:78)
        at io.undertow.servlet.handlers.security.SSLInformationAssociationHandl\
er.handleRequest(SSLInformationAssociationHandler.java:113)
        at io.undertow.security.handlers.AuthenticationCallHandler.handleReques\
t(AuthenticationCallHandler.java:52)
        at io.undertow.security.handlers.AbstractConfidentialityHandler.handleR\
equest(AbstractConfidentialityHandler.java:45)
        at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHand\
ler.handleRequest(CachedAuthenticatedSessionHandler.java:65)
        at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(S\
ecurityInitialHandler.java:70)
        at io.undertow.server.handlers.PredicateHandler.handleRequest(Predicate\
Handler.java:25)
        at org.wildfly.extension.undertow.security.SecurityContextCreationHandl\
er.handleRequest(SecurityContextCreationHandler.java:54)
        at io.undertow.server.handlers.PredicateHandler.handleRequest(Predicate\
Handler.java:25)
        at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstReques\
t(ServletInitialHandler.java:207)
        at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(S\
ervletInitialHandler.java:194)
        at io.undertow.servlet.handlers.ServletInitialHandler.access$000(Servle\
tInitialHandler.java:72)
        at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(S\
ervletInitialHandler.java:128)
        at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java\
:36)
        at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:\
628)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor\
.java:1145) [rt.jar:1.7.0_03]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecuto\
r.java:615) [rt.jar:1.7.0_03]
        at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_03]
Caused by: javax.persistence.PersistenceException: org.hibernate.exception.Gene\
ricJDBCException: Could not open connection
        at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEnti\
tyManagerImpl.java:1587) [hibernate-entitymanager-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEnti\
tyManagerImpl.java:1512) [hibernate-entitymanager-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.jpa.internal.QueryImpl.getSingleResult(QueryImpl.java:\
410) [hibernate-entitymanager-4.3.0.Beta3.jar:4.3.0.Beta3]
        at com.ecolane.mpk.frontend.beans.FrontendLiaisonBean.getOurFeService(F\
rontendLiaisonBean.java:123) [k3-main.jar:]
        at com.ecolane.mpk.frontend.beans.FrontendLiaisonBean.synchOneCustomerT\
oFrontend(FrontendLiaisonBean.java:362) [k3-main.jar:]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:\
1.7.0_03]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_03]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcce\
ssorImpl.java:43) [rt.jar:1.7.0_03]
        at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_03]
        at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$M\
anagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterc\
eptorFactory.java:72)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInter\
ceptor.java:53)
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.proc\
essInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext$Invocation.proceed(Intercept\
orContext.java:406)
        at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception\
(Jsr299BindingsInterceptor.java:130) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha\
4]
        at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Js\
r299BindingsInterceptor.java:138) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.proc\
essInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInter\
ceptor.java:53)
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.proc\
essInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeIntercept\
or.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alph\
a4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocati\
on(SBInvocationInterceptor.java:47) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext$Invocation.proceed(Intercept\
orContext.java:406)
        at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.arou\
ndInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46) [weld-core-impl-\
2.0.3.Final.jar:2013-07-17 09:29]
        at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processIn\
vocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.Alph\
a4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInt\
erceptor.java:21)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInt\
erceptor.java:61)
        at org.jboss.as.ee.component.interceptors.ComponentDispatcherIntercepto\
r.processInvocation(ComponentDispatcherInterceptor.java:53)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processIn\
vocation(PooledInstanceInterceptor.java:51) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.\
0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxIntercep\
tor.java:251) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        ... 313 more
Caused by: org.hibernate.exception.GenericJDBCException: Could not open connect\
ion
        at org.hibernate.exception.internal.StandardSQLExceptionConverter.conve\
rt(StandardSQLExceptionConverter.java:54) [hibernate-core-4.3.0.Beta3.jar:4.3.0\
.Beta3]
        at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptio\
nHelper.java:126) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptio\
nHelper.java:112) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.engine.jdbc.internal.LogicalConnectionImpl.obtainConne\
ction(LogicalConnectionImpl.java:234) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Bet\
a3]
        at org.hibernate.engine.jdbc.internal.LogicalConnectionImpl.getConnecti\
on(LogicalConnectionImpl.java:170) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.engine.jdbc.internal.StatementPreparerImpl.connection(\
StatementPreparerImpl.java:63) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.engine.jdbc.internal.StatementPreparerImpl$5.doPrepare\
(StatementPreparerImpl.java:164) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.engine.jdbc.internal.StatementPreparerImpl$StatementPr\
eparationTemplate.prepareStatement(StatementPreparerImpl.java:185) [hibernate-c\
ore-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.engine.jdbc.internal.StatementPreparerImpl.prepareQuer\
yStatement(StatementPreparerImpl.java:162) [hibernate-core-4.3.0.Beta3.jar:4.3.\
0.Beta3]
        at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1859) \
[hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1836) \
[hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1813) \
[hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.loader.Loader.doQuery(Loader.java:895) [hibernate-core\
-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(L\
oader.java:340) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.loader.Loader.doList(Loader.java:2523) [hibernate-core\
-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.loader.Loader.doList(Loader.java:2509) [hibernate-core\
-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2339) [-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2339) [\
hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.loader.Loader.list(Loader.java:2334) [hibernate-core-4\
.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:491) [hib\
ernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTransla\
torImpl.java:369) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan\
.java:222) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1270) [hibe\
rnate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.internal.QueryImpl.list(QueryImpl.java:101) [hibernate\
-core-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.jpa.internal.QueryImpl.getSingleResult(QueryImpl.java:\
381) [hibernate-entitymanager-4.3.0.Beta3.jar:4.3.0.Beta3]
        ... 348 more
Caused by: java.sql.SQLException: javax.resource.ResourceException: IJ000457: U\
nchecked throwable in managedConnectionReconnected() cl=org.jboss.jca.core.conn\
ectionmanager.listener.TxConnectionListener at 3bd9aed0[state=NORMAL managed conne\
ction=org.jboss.jca.adapters.jdbc.xa.XAManagedConnection at ca83b59 connection han\
dles=0 lastUse=1381478011832 trackByTx=false pool=org.jboss.jca.core.connection\
manager.pool.strategy.OnePool at 166e94c2 pool internal context=SemaphoreArrayList\
ManagedConnectionPool at 6a594c6b[pool=MpkDemoUsFrontendDS] xaResource=XAResourceW\
rapperImpl at 35e8580f[xaResource=org.jboss.jca.adapters.jdbc.xa.XAManagedConnecti\
on at ca83b59 pad=false overrideRmValue=null productName=MySQL productVersion=5.5.\
24-5-log jndiName=java:/FrontendDS] txSync=null]
        at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperD\
ataSource.java:147)
        at org.hibernate.engine.jdbc.connections.internal.DatasourceConnectionP\
roviderImpl.getConnection(DatasourceConnectionProviderImpl.java:138) [hibernate\
-core-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.internal.AbstractSessionImpl$NonContextualJdbcConnecti\
onAccess.obtainConnection(AbstractSessionImpl.java:359) [hibernate-core-4.3.0.B\
eta3.jar:4.3.0.Beta3]
        at org.hibernate.engine.jdbc.internal.LogicalConnectionImpl.obtainConne\
ction(LogicalConnectionImpl.java:227) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Bet\
a3]
        ... 368 more
Caused by: javax.resource.ResourceException: IJ000457: Unchecked throwable in m\
anagedConnectionReconnected() cl=org.jboss.jca.core.connectionmanager.listener.\
TxConnectionListener at 3bd9aed0[state=NORMAL managed connection=org.jboss.jca.ada\
pters.jdbc.xa.XAManagedConnection at ca83b59 connection handles=0 lastUse=13814780\
11832 trackByTx=false pool=org.jboss.jca.core.connectionmanager.pool.strategy.O\
nePool at 166e94c2 pool internal context=SemaphoreArrayListManagedConnectionPool at 6\
a594c6b[pool=MpkDemoUsFrontendDS] xaResource=XAResourceWrapperImpl at 35e8580f[xaR\
esource=org.jboss.jca.adapters.jdbc.xa.XAManagedConnection at ca83b59 pad=false ov\
errideRmValue=null productName=MySQL productVersion=5.5.24-5-log jndiName=java:\
/FrontendDS] txSync=null]
        at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.recon\
nectManagedConnection(AbstractConnectionManager.java:604)
        at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.alloc\
ateConnection(AbstractConnectionManager.java:467)
        at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperD
ataSource.java:139)
        ... 371 more
Caused by: javax.resource.ResourceException: IJ000461: Could not enlist in tran\
saction on entering meta-aware object
        at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.mana\
gedConnectionReconnected(TxConnectionManagerImpl.java:474)
        at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.recon\
nectManagedConnection(AbstractConnectionManager.java:599)
        ... 373 more
Caused by: javax.transaction.SystemException: IJ000356: Failed to enlist: java.\
lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=Trans\
actionImple < ac, BasicAction: 0:ffff90cae62c:25277dea:5257ad7c:6e2 status: Act\
ionStatus.ABORT_ONLY >
        at org.jboss.jca.core.connectionmanager.listener.TxConnectionListener$T\
ransactionSynchronization.checkEnlisted(TxConnectionListener.java:572)
        at org.jboss.jca.core.connectionmanager.listener.TxConnectionListener.e\
nlist(TxConnectionListener.java:283)
        at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.mana\
gedConnectionReconnected(TxConnectionManagerImpl.java:467)
        ... 374 more

^[[0m^[[31m03:53:31,857 ERROR [k3.mpk.apps.beans.ToolBackendBean] (default task\
-7) : javax.ejb.EJBTransactionRolledbackException: org.hibernate.exception.Gene\
ricJDBCException: Could not open connection
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleInCallerTx(CMTTxIntercep\
tor.java:163) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxIntercep\
tor.java:253) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java\
:342) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterce\
ptor.java:239) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInt\
erceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfl\
y-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.pr\
ocessInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0\
.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocat\
ion(SecurityContextInterceptor.java:90) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Al\
pha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$\
1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Alp\
ha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alph\
a4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocat\
ion(NamespaceContextInterceptor.java:50)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.\
processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Alpha\
4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation\
(ContextClassLoaderInterceptor.java:55)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:\
325)
    	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFl\
ySecurityManager.java:419)
        at org.wildfly.security.manager.AccessCheckingInterceptor.processInvoca\
tion(AccessCheckingInterceptor.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:\
325)
        at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1\
.7.0_03]
        at org.jboss.invocation.PrivilegedInterceptor.processInvocation(Privile\
gedInterceptor.java:75)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInt\
erceptor.java:61)
        at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:1\
65)
        at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDe\
scription.java:182)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInt\
erceptor.java:61)
        at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocat\
ionHandler.java:72)
        at com.ecolane.mpk.frontend.beans.FrontendLiaisonLocal$$$view98.synchOn\
eCustomerToFrontend(Unknown Source) [k3-main.jar:]
        at com.ecolane.mpk.apps.beans.ToolBackendBean.synchOneCustomerToFronten\
d(ToolBackendBean.java:717) [k3-main.jar:]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:\
1.7.0_03]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl\
.java:57) [rt.jar:1.7.0_03]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_03]
        at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_03]
        at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$M\
anagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterc\
eptorFactory.java:72)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInter\
ceptor.java:53)
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.proc\
essInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext$Invocation.proceed(Intercept\
orContext.java:406)
        at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception\
(Jsr299BindingsInterceptor.java:130) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha\
4]
        at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Js\
r299BindingsInterceptor.java:138) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.proc\
essInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInter\
ceptor.java:53)
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.proc\
essInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeIntercept\
or.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alph\
a4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocati\
on(SBInvocationInterceptor.java:47) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext$Invocation.proceed(Intercept\
orContext.java:406)
        at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.arou\
ndInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46) [weld-core-impl-\
2.0.3.Final.jar:2013-07-17 09:29]
        at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processIn\
vocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.Alph\
a4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInt\
erceptor.java:21)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
        at org.jboss.as.ee.component.interceptors.ComponentDispatcherIntercepto\
r.processInvocation(ComponentDispatcherInterceptor.java:53)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processIn\
vocation(PooledInstanceInterceptor.java:51) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.\
0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxIntercep\
tor.java:251) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java\
:342) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterce\
ptor.java:239) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInt\
erceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfl\
y-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.pr\
ocessInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0\
.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocat\
ion(SecurityContextInterceptor.java:90) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Al\
pha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$\
1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Alp\
ha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processI\
nvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alph\
a4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocat\
ion(NamespaceContextInterceptor.java:50)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.\
processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Alpha\
4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation\
(ContextClassLoaderInterceptor.java:55)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:\
325)
        at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFl\
ySecurityManager.java:419)
        at org.wildfly.security.manager.AccessCheckingInterceptor.processInvoca\
tion(AccessCheckingInterceptor.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:\
325)
        at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1\
.7.0_03]
        at org.jboss.invocation.PrivilegedInterceptor.processInvocation(Privile\
gedInterceptor.java:75)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInt\
erceptor.java:61)
        at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:1\
65)
        at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDe\
scription.java:182)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInt\
erceptor.java:61)
        at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocat\
ionHandler.java:72)
        at com.ecolane.mpk.apps.interfaces.ToolBackendLocal$$$view1.synchOneCus\
tomerToFrontend(Unknown Source) [k3-main.jar:]
        at com.ecolane.mpk.routing.beans.OrderingToolsBackendBean.persistUpdate\
dCustomerData(OrderingToolsBackendBean.java:352) [k3-main.jar:]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:\
1.7.0_03]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl\
.java:57) [rt.jar:1.7.0_03]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcce\
ssorImpl.java:43) [rt.jar:1.7.0_03]
        at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_03]
        at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$M\
anagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterc\
eptorFactory.java:72)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInter\
ceptor.java:53)
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.proc\
essInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext$Invocation.proceed(Intercept\
orContext.java:406)
        at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception\
(Jsr299BindingsInterceptor.java:130) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha\
4]
        at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Js\
r299BindingsInterceptor.java:138) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.proc\
essInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInter\
ceptor.java:53)
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.proc\
essInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeIntercept\
or.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alph\
a4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocati\
on(SBInvocationInterceptor.java:47) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext$Invocation.proceed(Intercept\
orContext.java:406)
        at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.arou\
ndInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46) [weld-core-impl-\
2.0.3.Final.jar:2013-07-17 09:29]
        at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processIn\
vocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.Alph\
a4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInt\
erceptor.java:21)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInt\
erceptor.java:61)
        at org.jboss.as.ee.component.interceptors.ComponentDispatcherIntercepto\
r.processInvocation(ComponentDispatcherInterceptor.java:53)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processIn\
vocation(PooledInstanceInterceptor.java:51) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.\
0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxIntercep\
tor.java:251) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java\
:342) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInt\
erceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfl\
y-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.pr\
ocessInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0\
.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocat\
ion(SecurityContextInterceptor.java:90) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Al\
pha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$\
1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Alp\
ha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processI\
nvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alph\
a4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocat\
ion(NamespaceContextInterceptor.java:50)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.\
processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Alpha\
4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation\
(ContextClassLoaderInterceptor.java:55)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:\
325)
        at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFl\
ySecurityManager.java:419)
        at org.wildfly.security.manager.AccessCheckingInterceptor.processInvoca\
tion(AccessCheckingInterceptor.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:\
325)
        at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1\
.7.0_03]
        at org.jboss.invocation.PrivilegedInterceptor.processInvocation(PrivilegedInterceptor.java:75)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInt\
erceptor.java:61)
        at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:1\
65)
        at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDe\
scription.java:182)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInt\
erceptor.java:61)
        at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocat\
ionHandler.java:72)
        at com.ecolane.mpk.routing.interfaces.OrderingToolsBackendLocal$$$view7\
2.persistUpdatedCustomerData(Unknown Source) [k3-main.jar:]
        at com.ecolane.mpk.ccagent.beans.CcAgentBackendBean.persistUpdatedCusto\
merData(CcAgentBackendBean.java:2534) [k3-main.jar:]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:\
1.7.0_03]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl\
.java:57) [rt.jar:1.7.0_03]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcce\
ssorImpl.java:43) [rt.jar:1.7.0_03]
        at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_03]
        at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$M\
anagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterc\
eptorFactory.java:72)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInter\
ceptor.java:53)
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.proc\
essInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext$Invocation.proceed(Intercept\
orContext.java:406)
        at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception\
(Jsr299BindingsInterceptor.java:130) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha\
4]
        at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Js\
r299BindingsInterceptor.java:138) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.proc\
essInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInter\
ceptor.java:53)
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.proc\
essInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeIntercept\
or.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alph\
a4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocati\
on(SBInvocationInterceptor.java:47) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext$Invocation.proceed(Intercept\
orContext.java:406)
        at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.arou\
ndInvoke(AbstractEJBRequestScopeActivationInterceptor.java:55) [weld-core-impl-\
2.0.3.Final.jar:2013-07-17 09:29]
        at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processIn\
vocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.Alph\
a4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInt\
erceptor.java:21)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInt\
erceptor.java:61)
        at org.jboss.as.ee.component.interceptors.ComponentDispatcherIntercepto\
r.processInvocation(ComponentDispatcherInterceptor.java:53)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processIn\
vocation(PooledInstanceInterceptor.java:51) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.\
0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor\
.java:273) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java\
:340) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterce\
ptor.java:239) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInt\
erceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfl\
y-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.pr\
ocessInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0\
.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocat\
ion(SecurityContextInterceptor.java:90) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$\
1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Alp\
ha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processI\
nvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alph\
a4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocat\
ion(NamespaceContextInterceptor.java:50)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.\
processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Alpha\
4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation\
(ContextClassLoaderInterceptor.java:55)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:\
325)
        at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFl\
ySecurityManager.java:428)
        at org.wildfly.security.manager.AccessCheckingInterceptor.processInvoca\
tion(AccessCheckingInterceptor.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:\
325)
        at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1\
.7.0_03]
        at org.jboss.invocation.PrivilegedInterceptor.processInvocation(Privile\
gedInterceptor.java:75)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInt\
erceptor.java:61)
        at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:1\
65)
        at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDe\
scription.java:182)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInt\
erceptor.java:61)
        at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocat\
ionHandler.java:72)
        at com.ecolane.mpk.ccagent.interfaces.CcAgentBackendLocal$$$view33.pers\
istUpdatedCustomerData(Unknown Source) [k3-main.jar:]
        at com.ecolane.mpk.ccagent.pages.ClientProfileEdit.save(ClientProfileEd\
it.java:553)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:\
1.7.0_03]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl\
.java:57) [rt.jar:1.7.0_03]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcce\
ssorImpl.java:43) [rt.jar:1.7.0_03]
        at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_03]
        at org.apache.tapestry.listener.ListenerMethodInvokerImpl.invokeTargetM\
ethod(ListenerMethodInvokerImpl.java:276) [tapestry-framework-4.1.7-SNAPSHOT.ja\
r:4.1.7-SNAPSHOT]
        at org.apache.tapestry.listener.ListenerMethodInvokerImpl.invokeListene\
rMethod(ListenerMethodInvokerImpl.java:221) [tapestry-framework-4.1.7-SNAPSHOT.\
jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.listener.ListenerMethodInvokerImpl.searchAndInvo\
ke(ListenerMethodInvokerImpl.java:157) [tapestry-framework-4.1.7-SNAPSHOT.jar:4\
.1.7-SNAPSHOT]
        at org.apache.tapestry.listener.ListenerMethodInvokerImpl.invokeListene\
rMethod(ListenerMethodInvokerImpl.java:80) [tapestry-framework-4.1.7-SNAPSHOT.j\
ar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.listener.SyntheticListener.actionTriggered(Synth\
eticListener.java:52) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.binding.ListenerMethodBinding.actionTriggered(Li\
stenerMethodBinding.java:77) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPS\
HOT]
        at org.apache.tapestry.listener.ListenerInvokerTerminator.invokeListene\
r(ListenerInvokerTerminator.java:50) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1\
.7-SNAPSHOT]
        at $ListenerInvoker_141a6814600.invokeListener($ListenerInvoker_141a681\
4600.java)       at org.apache.tapestry.form.AbstractSubmit$1.run(AbstractSubmi\
t.java:106) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.form.FormSupportImpl.runDeferredRunnables(FormSu\
pportImpl.java:673) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.form.FormSupportImpl.rewind(FormSupportImpl.java\
:646) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.form.Form.renderComponent(Form.java:196) [tapest\
ry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.AbstractComponent.render(AbstractComponent.java:\
724) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.services.impl.DefaultResponseBuilder.render(Defa\
ultResponseBuilder.java:187) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPS\
HOT]
        at org.apache.tapestry.form.Form.rewind(Form.java:269) [tapestry-framew\
ork-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.engine.RequestCycle.rewindForm(RequestCycle.java\
:469) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.form.Form.trigger(Form.java:280) [tapestry-frame\
work-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.engine.DirectService.triggerComponent(DirectServ\
ice.java:166) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.engine.DirectService.service(DirectService.java:142) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at $IEngineService_141a6814679.service($IEngineService_141a6814679.java\
)        at org.apache.tapestry.services.impl.EngineServiceOuterProxy.service(E\
ngineServiceOuterProxy.java:72) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SN\
APSHOT]
        at org.apache.tapestry.engine.AbstractEngine.service(AbstractEngine.jav\
a:241) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.services.impl.InvokeEngineTerminator.service(Inv\
okeEngineTerminator.java:54) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPS\
HOT]
        at $WebRequestServicer_141a6814652.service($WebRequestServicer_141a6814\
652.java)        at $WebRequestServicer_141a681464e.service($WebRequestServicer\
_141a681464e.java)        at org.apache.tapestry.services.impl.WebRequestServic\
erPipelineBridge.service(WebRequestServicerPipelineBridge.java:61) [tapestry-fr\
amework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at $ServletRequestServicer_141a6814634.service($ServletRequestServicer_\
141a6814634.java)        at org.apache.tapestry.request.DecodedRequestInjector.\
service(DecodedRequestInjector.java:55) [tapestry-framework-4.1.7-SNAPSHOT.jar:\
4.1.7-SNAPSHOT]
        at $ServletRequestServicerFilter_141a6814630.service($ServletRequestSer\
vicerFilter_141a6814630.java)    at $ServletRequestServicer_141a6814636.service\
($ServletRequestServicer_141a6814636.java)        at org.apache.tapestry.multip\
art.MultipartDecoderFilter.service(MultipartDecoderFilter.java:52) [tapestry-fr\
amework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at $ServletRequestServicerFilter_141a681462e.service($ServletRequestSer\
vicerFilter_141a681462e.java)    at $ServletRequestServicer_141a6814636.service\
($ServletRequestServicer_141a6814636.java)        at org.apache.tapestry.servic\
es.impl.SetupRequestEncoding.service(SetupRequestEncoding.java:53) [tapestry-fr\
amework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at $ServletRequestServicerFilter_141a6814632.service($ServletRequestSer\
vicerFilter_141a6814632.java)    at $ServletRequestServicer_141a6814636.service\
($ServletRequestServicer_141a6814636.java)        at $ServletRequestServicer_14\
1a6814628.service($ServletRequestServicer_141a6814628.java)        at org.apach\
e.tapestry.ApplicationServlet.doService(ApplicationServlet.java:126) [tapestry-\
framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.ApplicationServlet.doPost(ApplicationServlet.jav\
a:171) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) [jboss-\
servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-\
servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
        at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHan\
dler.java:87)
        at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(\
FilterHandler.java:130)
        at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketF\
ilter.java:136)
        at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:5\
6)
        at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(\
FilterHandler.java:132)
        at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketF\
ilter.java:136)
        at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56)
        at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(\
FilterHandler.java:132)
        at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandl\
er.java:85)
        at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.han\
dleRequest(ServletSecurityRoleHandler.java:56)
        at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest\
(ServletDispatchingHandler.java:36)
        at org.wildfly.extension.undertow.security.SecurityContextAssociationHa\
ndler.handleRequest(SecurityContextAssociationHandler.java:78)
        at io.undertow.servlet.handlers.security.SSLInformationAssociationHandl\
er.handleRequest(SSLInformationAssociationHandler.java:113)
        at io.undertow.security.handlers.AuthenticationCallHandler.handleReques\
t(AuthenticationCallHandler.java:52)
        at io.undertow.security.handlers.AbstractConfidentialityHandler.handleR\
equest(AbstractConfidentialityHandler.java:45)
        at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHand\
ler.handleRequest(CachedAuthenticatedSessionHandler.java:65)
        at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(S\
ecurityInitialHandler.java:70)
        at io.undertow.server.handlers.PredicateHandler.handleRequest(Predicate\
Handler.java:25)
        at org.wildfly.extension.undertow.security.SecurityContextCreationHandl\
er.handleRequest(SecurityContextCreationHandler.java:54)
        at io.undertow.server.handlers.PredicateHandler.handleRequest(Predicate\
Handler.java:25)
        at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstReques\
t(ServletInitialHandler.java:207)
        at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(S\
ervletInitialHandler.java:194)
        at io.undertow.servlet.handlers.ServletInitialHandler.access$000(Servle\
tInitialHandler.java:72)
        at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(S\
ervletInitialHandler.java:128)
        at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java\
:36)
        at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:\
628)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor\
.java:1145) [rt.jar:1.7.0_03]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecuto\
r.java:615) [rt.jar:1.7.0_03]
        at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_03]
Caused by: javax.persistence.PersistenceException: org.hibernate.exception.Gene\
ricJDBCException: Could not open connection
        at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEnti\
tyManagerImpl.java:1587) [hibernate-entitymanager-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEnti\
tyManagerImpl.java:1512) [hibernate-entitymanager-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.jpa.internal.QueryImpl.getSingleResult(QueryImpl.java:\
410) [hibernate-entitymanager-4.3.0.Beta3.jar:4.3.0.Beta3]
        at com.ecolane.mpk.frontend.beans.FrontendLiaisonBean.getOurFeService(FrontendLiaisonBean.java:123) [k3-main.jar:]
        at com.ecolane.mpk.frontend.beans.FrontendLiaisonBean.synchOneCustomerT\
oFrontend(FrontendLiaisonBean.java:362) [k3-main.jar:]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:\
1.7.0_03]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl\
.java:57) [rt.jar:1.7.0_03]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcce\
ssorImpl.java:43) [rt.jar:1.7.0_03]
        at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_03]
        at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$M\
anagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterc\
eptorFactory.java:72)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInter\
ceptor.java:53)
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.proc\
essInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext$Invocation.proceed(Intercept\
orContext.java:406)
        at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception\
(Jsr299BindingsInterceptor.java:130) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha\
4]
        at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Js\
r299BindingsInterceptor.java:138) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.proc\
essInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInter\
ceptor.java:53)
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.proc\
essInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeIntercept\
or.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alph\
a4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocati\
on(SBInvocationInterceptor.java:47) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext$Invocation.proceed(Intercept\
orContext.java:406)
        at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.arou\
ndInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
        at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processIn\
vocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInt\
erceptor.java:21)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInt\
erceptor.java:61)
        at org.jboss.as.ee.component.interceptors.ComponentDispatcherIntercepto\
r.processInvocation(ComponentDispatcherInterceptor.java:53)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processIn\
vocation(PooledInstanceInterceptor.java:51) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.\
0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxIntercep\
tor.java:251) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        ... 313 more
Caused by: org.hibernate.exception.GenericJDBCException: Could not open connect\
ion
        at org.hibernate.exception.internal.StandardSQLExceptionConverter.conve\
rt(StandardSQLExceptionConverter.java:54) [hibernate-core-4.3.0.Beta3.jar:4.3.0\
.Beta3]
        at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptio\
nHelper.java:126) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptio\
nHelper.java:112) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.engine.jdbc.internal.LogicalConnectionImpl.obtainConne\
ction(LogicalConnectionImpl.java:234) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Bet\
a3]
        at org.hibernate.engine.jdbc.internal.LogicalConnectionImpl.getConnecti\
on(LogicalConnectionImpl.java:170) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.engine.jdbc.internal.StatementPreparerImpl.connection(\
StatementPreparerImpl.java:63) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.engine.jdbc.internal.StatementPreparerImpl$5.doPrepare\
(StatementPreparerImpl.java:164) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.engine.jdbc.internal.StatementPreparerImpl$StatementPr\
eparationTemplate.prepareStatement(StatementPreparerImpl.java:185) [hibernate-c\
ore-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.engine.jdbc.internal.StatementPreparerImpl.prepareQuer\
yStatement(StatementPreparerImpl.java:162) [hibernate-core-4.3.0.Beta3.jar:4.3.\
0.Beta3]
        at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1859) \
[hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1836) \
[hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1813) \
[hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.loader.Loader.doQuery(Loader.java:895) [hibernate-core\
-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(L\
oader.java:340) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.loader.Loader.doList(Loader.java:2523) [hibernate-core\
-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.loader.Loader.doList(Loader.java:2509) [hibernate-core\
-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2339) [\
hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.loader.Loader.list(Loader.java:2334) [hibernate-core-4\
.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:491) [hib\
ernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTransla\
torImpl.java:369) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan\
.java:222) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1270) [hibe\
rnate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.internal.QueryImpl.list(QueryImpl.java:101) [hibernate\
-core-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.jpa.internal.QueryImpl.getSingleResult(QueryImpl.java:\
381) [hibernate-entitymanager-4.3.0.Beta3.jar:4.3.0.Beta3]
        ... 348 more
Caused by: java.sql.SQLException: javax.resource.ResourceException: IJ000457: U\
nchecked throwable in managedConnectionReconnected() cl=org.jboss.jca.core.conn\
ectionmanager.listener.TxConnectionListener at 3bd9aed0[state=NORMAL managed conne\
ction=org.jboss.jca.adapters.jdbc.xa.XAManagedConnection at ca83b59 connection han\
dles=0 lastUse=1381478011832 trackByTx=false pool=org.jboss.jca.core.connection\
manager.pool.strategy.OnePool at 166e94c2 pool internal context=SemaphoreArrayList\
ManagedConnectionPool at 6a594c6b[pool=MpkDemoUsFrontendDS] xaResource=XAResourceW\
rapperImpl at 35e8580f[xaResource=org.jboss.jca.adapters.jdbc.xa.XAManagedConnecti\
on at ca83b59 pad=false overrideRmValue=null productName=MySQL productVersion=5.5.\
24-5-log jndiName=java:/FrontendDS] txSync=null]
        at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperD\
ataSource.java:147)
        at org.hibernate.engine.jdbc.connections.internal.DatasourceConnectionP\
roviderImpl.getConnection(DatasourceConnectionProviderImpl.java:138) [hibernate\
-core-4.3.0.Beta3.jar:4.3.0.Beta3]
        at org.hibernate.internal.AbstractSessionImpl$NonContextualJdbcConnecti\
onAccess.obtainConnection(AbstractSessionImpl.java:359) [hibernate-core-4.3.0.B\
eta3.jar:4.3.0.Beta3]
        at org.hibernate.engine.jdbc.internal.LogicalConnectionImpl.obtainConne\
ction(LogicalConnectionImpl.java:227) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Bet\
a3]
        ... 368 more
Caused by: javax.resource.ResourceException: IJ000457: Unchecked throwable in m\
anagedConnectionReconnected() cl=org.jboss.jca.core.connectionmanager.listener.\
TxConnectionListener at 3bd9aed0[state=NORMAL managed connection=org.jboss.jca.ada\
pters.jdbc.xa.XAManagedConnection at ca83b59 connection handles=0 lastUse=13814780\
11832 trackByTx=false pool=org.jboss.jca.core.connectionmanager.pool.strategy.O\
nePool at 166e94c2 pool internal context=SemaphoreArrayListManagedConnectionPool at 6\
a594c6b[pool=MpkDemoUsFrontendDS] xaResource=XAResourceWrapperImpl at 35e8580f[xaR\
esource=org.jboss.jca.adapters.jdbc.xa.XAManagedConnection at ca83b59 pad=false ov\
errideRmValue=null productName=MySQL productVersion=5.5.24-5-log jndiName=java:\
/FrontendDS] txSync=null]
        at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.reconnectManagedConnection(AbstractConnectionManager.java:604)
        at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.alloc\
ateConnection(AbstractConnectionManager.java:467)
        at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperD\
ataSource.java:139)
        ... 371 more
Caused by: javax.resource.ResourceException: IJ000461: Could not enlist in tran\
saction on entering meta-aware object
        at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.mana\
gedConnectionReconnected(TxConnectionManagerImpl.java:474)
        at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.recon\
nectManagedConnection(AbstractConnectionManager.java:599)
        ... 373 more
Caused by: javax.transaction.SystemException: IJ000356: Failed to enlist: java.\
lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=Trans\
actionImple < ac, BasicAction: 0:ffff90cae62c:25277dea:5257ad7c:6e2 status: Act\
ionStatus.ABORT_ONLY >
        at org.jboss.jca.core.connectionmanager.listener.TxConnectionListener$T\
ransactionSynchronization.checkEnlisted(TxConnectionListener.java:572)
        at org.jboss.jca.core.connectionmanager.listener.TxConnectionListener.e\
nlist(TxConnectionListener.java:283)
        at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.mana\
gedConnectionReconnected(TxConnectionManagerImpl.java:467)
        ... 374 more

^[[0m^[[31m03:53:31,874 ERROR [org.jboss.as.ejb3] (default task-7) javax.ejb.EJ\
BTransactionRolledbackException: org.hibernate.exception.GenericJDBCException: \
Could not open connection
^[[0m^[[31m03:53:31,875 ERROR [org.jboss.as.ejb3.invocation] (default task-7) J\
BAS014134: EJB Invocation failed on component ToolBackendBean for method public\
 abstract void com.ecolane.mpk.apps.interfaces.ToolBackendLocal.synchOneCustome\
rToFrontend(com.ecolane.mpk.persistence.Customer): javax.ejb.EJBTransactionRoll\
edbackException: org.hibernate.exception.GenericJDBCException: Could not open c\
onnection
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleInCallerTx(CMTTxIntercep\
tor.java:163) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxIntercep\
tor.java:253) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java\
:342) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterce\
ptor.java:239) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInt\
erceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfl\
y-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.pr\
ocessInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0\
.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocat\
ion(SecurityContextInterceptor.java:90) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Al\
pha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$\
1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Alp\
ha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processI\
nvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alph\
a4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocat\
ion(NamespaceContextInterceptor.java:50)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.\
processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Alpha\
4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation\
(ContextClassLoaderInterceptor.java:55)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:\
325)
        at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFl\
ySecurityManager.java:419)
        at org.wildfly.security.manager.AccessCheckingInterceptor.processInvoca\
tion(AccessCheckingInterceptor.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:\
325)
        at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1\
.7.0_03]
        at org.jboss.invocation.PrivilegedInterceptor.processInvocation(Privile\
gedInterceptor.java:75)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInt\
erceptor.java:61)
        at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:1\
65)
        at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDe\
scription.java:182)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInt\
erceptor.java:61)
        at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocat\
ionHandler.java:72)
        at com.ecolane.mpk.apps.interfaces.ToolBackendLocal$$$view1.synchOneCus\
tomerToFrontend(Unknown Source) [k3-main.jar:]
        at com.ecolane.mpk.routing.beans.OrderingToolsBackendBean.persistUpdate\
dCustomerData(OrderingToolsBackendBean.java:352) [k3-main.jar:]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:\
1.7.0_03]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl\
.java:57) [rt.jar:1.7.0_03]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcce\
ssorImpl.java:43) [rt.jar:1.7.0_03]
        at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_03]
        at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$M\
anagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterc\
eptorFactory.java:72)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInter\
ceptor.java:53)
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.proc\
essInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext$Invocation.proceed(Intercept\
orContext.java:406)
        at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception\
(Jsr299BindingsInterceptor.java:130) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha\
4]
        at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Js\
r299BindingsInterceptor.java:138) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.proc\
essInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInter\
ceptor.java:53)
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.proc\
essInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeIntercept\
or.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alph\
a4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocati\
on(SBInvocationInterceptor.java:47) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext$Invocation.proceed(Intercept\
orContext.java:406)
        at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.arou\
ndInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
        at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processIn\
vocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.Alph\
a4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInt\
erceptor.java:21)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInt\
erceptor.java:61)
        at org.jboss.as.ee.component.interceptors.ComponentDispatcherIntercepto\
r.processInvocation(ComponentDispatcherInterceptor.java:53)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processIn\
vocation(PooledInstanceInterceptor.java:51) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.\
0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxIntercep\
tor.java:251) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java\
:342) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterce\
ptor.java:239) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInt\
erceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfl\
y-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.pr\
ocessInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0\
.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocat\
ion(SecurityContextInterceptor.java:90) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Al\
pha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$\
1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Alp\
ha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processI\
nvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alph\
a4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocat\
ion(NamespaceContextInterceptor.java:50)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.\
processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Alpha\
4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation\
(ContextClassLoaderInterceptor.java:55)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:\
325)
        at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFl\
ySecurityManager.java:419)
        at org.wildfly.security.manager.AccessCheckingInterceptor.processInvoca\
tion(AccessCheckingInterceptor.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:\
325)
        at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1\
.7.0_03]
        at org.jboss.invocation.PrivilegedInterceptor.processInvocation(Privile\
gedInterceptor.java:75)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInt\
erceptor.java:61)
        at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:1\
65)
        at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDe\
scription.java:182)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInt\
erceptor.java:61)
        at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocat\
ionHandler.java:72)
        at com.ecolane.mpk.routing.interfaces.OrderingToolsBackendLocal$$$view7\
2.persistUpdatedCustomerData(Unknown Source) [k3-main.jar:]
        at com.ecolane.mpk.ccagent.beans.CcAgentBackendBean.persistUpdatedCusto\
merData(CcAgentBackendBean.java:2534) [k3-main.jar:]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:\
1.7.0_03]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl\
.java:57) [rt.jar:1.7.0_03]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcce\
ssorImpl.java:43) [rt.jar:1.7.0_03]
        at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_03]
        at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$M\
anagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInter\
ceptor.java:53)
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.proc\
essInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext$Invocation.proceed(Intercept\
orContext.java:406)
        at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception\
(Jsr299BindingsInterceptor.java:130) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha\
4]
        at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Js\
r299BindingsInterceptor.java:138) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.proc\
essInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInter\
ceptor.java:53)
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.proc\
essInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeIntercept\
or.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alph\
a4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocati\
on(SBInvocationInterceptor.java:47) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext$Invocation.proceed(Intercept\
orContext.java:406)
        at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.arou\
ndInvoke(AbstractEJBRequestScopeActivationInterceptor.java:55) [weld-core-impl-\
2.0.3.Final.jar:2013-07-17 09:29]
        at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processIn\
vocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.Alph\
a4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInt\
erceptor.java:21)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInt\
erceptor.java:61)
        at org.jboss.as.ee.component.interceptors.ComponentDispatcherIntercepto\
r.processInvocation(ComponentDispatcherInterceptor.java:53)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processIn\
vocation(PooledInstanceInterceptor.java:51) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.\
0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor\
.java:273) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java\
:340) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterce\
ptor.java:239) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInt\
erceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfl\
y-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.pr\
ocessInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0\
.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocat\
ion(SecurityContextInterceptor.java:90) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Al\
pha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$\
1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Alp\
ha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processI\
nvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alph\
a4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocat\
ion(NamespaceContextInterceptor.java:50)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.\
processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Alpha\
4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation\
(ContextClassLoaderInterceptor.java:55)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:\
325)
        at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFl\
ySecurityManager.java:428)
        at org.wildfly.security.manager.AccessCheckingInterceptor.processInvoca\
tion(AccessCheckingInterceptor.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:\
325)
        at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1\
.7.0_03]
        at org.jboss.invocation.PrivilegedInterceptor.processInvocation(Privile\
gedInterceptor.java:75)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInt\
erceptor.java:61)
        at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:1\
65)
        at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDe\
scription.java:182)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInt\
erceptor.java:61)
        at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocat\
ionHandler.java:72)
        at com.ecolane.mpk.ccagent.interfaces.CcAgentBackendLocal$$$view33.pers\
istUpdatedCustomerData(Unknown Source) [k3-main.jar:]
        at com.ecolane.mpk.ccagent.pages.ClientProfileEdit.save(ClientProfileEd\
it.java:553)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:\
1.7.0_03]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl\
.java:57) [rt.jar:1.7.0_03]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcce\
ssorImpl.java:43) [rt.jar:1.7.0_03]
        at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_03]
        at org.apache.tapestry.listener.ListenerMethodInvokerImpl.invokeTargetM\
ethod(ListenerMethodInvokerImpl.java:276) [tapestry-framework-4.1.7-SNAPSHOT.ja\
r:4.1.7-SNAPSHOT]
        at org.apache.tapestry.listener.ListenerMethodInvokerImpl.invokeListene\
rMethod(ListenerMethodInvokerImpl.java:221) [tapestry-framework-4.1.7-SNAPSHOT.\
jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.listener.ListenerMethodInvokerImpl.searchAndInvo\
ke(ListenerMethodInvokerImpl.java:157) [tapestry-framework-4.1.7-SNAPSHOT.jar:4\
.1.7-SNAPSHOT]
        at org.apache.tapestry.listener.ListenerMethodInvokerImpl.invokeListene\
rMethod(ListenerMethodInvokerImpl.java:80) [tapestry-framework-4.1.7-SNAPSHOT.j\
ar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.listener.SyntheticListener.actionTriggered(SyntheticListener.java:52) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.binding.ListenerMethodBinding.actionTriggered(Li\
stenerMethodBinding.java:77) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.listener.ListenerInvokerTerminator.invokeListene\
r(ListenerInvokerTerminator.java:50) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1\
.7-SNAPSHOT]
        at $ListenerInvoker_141a6814600.invokeListener($ListenerInvoker_141a681\
4600.java)       at org.apache.tapestry.form.AbstractSubmit$1.run(AbstractSubmi\
t.java:106) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.form.FormSupportImpl.runDeferredRunnables(FormSu\
pportImpl.java:673) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.form.FormSupportImpl.rewind(FormSupportImpl.java\
:646) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.form.Form.renderComponent(Form.java:196) [tapest\
ry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.AbstractComponent.render(AbstractComponent.java:\
724) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.services.impl.DefaultResponseBuilder.render(Defa\
ultResponseBuilder.java:187) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPS\
HOT]
        at org.apache.tapestry.form.Form.rewind(Form.java:269) [tapestry-framew\
ork-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.engine.RequestCycle.rewindForm(RequestCycle.java\
:469) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.form.Form.trigger(Form.java:280) [tapestry-frame\
work-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.engine.DirectService.triggerComponent(DirectServ\
ice.java:166) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.engine.DirectService.service(DirectService.java:\
142) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at $IEngineService_141a6814679.service($IEngineService_141a6814679.java\
)        at org.apache.tapestry.services.impl.EngineServiceOuterProxy.service(E\
ngineServiceOuterProxy.java:72) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SN\
APSHOT]
        at org.apache.tapestry.engine.AbstractEngine.service(AbstractEngine.jav\
a:241) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.services.impl.InvokeEngineTerminator.service(Inv\
okeEngineTerminator.java:54) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPS\
HOT]
        at $WebRequestServicer_141a6814652.service($WebRequestServicer_141a6814\
652.java)        at $WebRequestServicer_141a681464e.service($WebRequestServicer\
_141a681464e.java)        at org.apache.tapestry.services.impl.WebRequestServic\
erPipelineBridge.service(WebRequestServicerPipelineBridge.java:61) [tapestry-fr\
amework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at $ServletRequestServicer_141a6814634.service($ServletRequestServicer_\
141a6814634.java)        at org.apache.tapestry.request.DecodedRequestInjector.\
service(DecodedRequestInjector.java:55) [tapestry-framework-4.1.7-SNAPSHOT.jar:\
4.1.7-SNAPSHOT]
        at $ServletRequestServicerFilter_141a6814630.service($ServletRequestSer\
vicerFilter_141a6814630.java)    at $ServletRequestServicer_141a6814636.service\
($ServletRequestServicer_141a6814636.java)        at org.apache.tapestry.multip\
art.MultipartDecoderFilter.service(MultipartDecoderFilter.java:52) [tapestry-fr\
amework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at $ServletRequestServicerFilter_141a681462e.service($ServletRequestSer\
vicerFilter_141a681462e.java)    at $ServletRequestServicer_141a6814636.service\
($ServletRequestServicer_141a6814636.java)        at org.apache.tapestry.servic\
es.impl.SetupRequestEncoding.service(SetupRequestEncoding.java:53) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at $ServletRequestServicerFilter_141a6814632.service($ServletRequestSer\
vicerFilter_141a6814632.java)    at $ServletRequestServicer_141a6814636.service\
($ServletRequestServicer_141a6814636.java)        at $ServletRequestServicer_14\
1a6814628.service($ServletRequestServicer_141a6814628.java)        at org.apach\
e.tapestry.ApplicationServlet.doService(ApplicationServlet.java:126) [tapestry-\
framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.ApplicationServlet.doPost(ApplicationServlet.jav\
a:171) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) [jboss-\
servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-\
servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
        at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHan\
dler.java:87)
        at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(\
FilterHandler.java:130)
        at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketF\
ilter.java:136)
        at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:5\
6)
        at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(\
FilterHandler.java:132)
        at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketF\
ilter.java:136)
        at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:5\
6)
        at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(\
FilterHandler.java:132)
        at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandl\
er.java:85)
        at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.han\
dleRequest(ServletSecurityRoleHandler.java:56)
        at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest\
(ServletDispatchingHandler.java:36)
        at org.wildfly.extension.undertow.security.SecurityContextAssociationHa\
ndler.handleRequest(SecurityContextAssociationHandler.java:78)
        at io.undertow.servlet.handlers.security.SSLInformationAssociationHandl\
er.handleRequest(SSLInformationAssociationHandler.java:113)
        at io.undertow.security.handlers.AuthenticationCallHandler.handleReques\
t(AuthenticationCallHandler.java:52)
        at io.undertow.security.handlers.AbstractConfidentialityHandler.handleR\
equest(AbstractConfidentialityHandler.java:45)
        at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHand\
ler.handleRequest(CachedAuthenticatedSessionHandler.java:65)
        at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(S\
ecurityInitialHandler.java:70)
        at io.undertow.server.handlers.PredicateHandler.handleRequest(Predicate\
Handler.java:25)
        at org.wildfly.extension.undertow.security.SecurityContextCreationHandl\
er.handleRequest(SecurityContextCreationHandler.java:54)
        at io.undertow.server.handlers.PredicateHandler.handleRequest(Predicate\
Handler.java:25)
        at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:207)
        at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(S\
ervletInitialHandler.java:194)
        at io.undertow.servlet.handlers.ServletInitialHandler.access$000(Servle\
tInitialHandler.java:72)
        at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(S\
ervletInitialHandler.java:128)
        at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java\
:36)
        at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:\
628)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor\
.java:1145) [rt.jar:1.7.0_03]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecuto\
r.java:615) [rt.jar:1.7.0_03]
        at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_03]
Caused by: com.ecolane.k3.db.DatabaseEJBException: org.hibernate.exception.Gene\
ricJDBCException: Could not open connection
        at com.ecolane.mpk.apps.beans.ToolBackendBean.synchOneCustomerToFronten\
d(ToolBackendBean.java:720) [k3-main.jar:]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:\
1.7.0_03]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl\
.java:57) [rt.jar:1.7.0_03]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcce\
ssorImpl.java:43) [rt.jar:1.7.0_03]
        at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_03]
        at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$M\
anagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterc\
eptorFactory.java:72)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInter\
ceptor.java:53)
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.proc\
essInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext$Invocation.proceed(Intercept\
orContext.java:406)
        at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception\
(Jsr299BindingsInterceptor.java:130) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha\
4]
        at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Js\
r299BindingsInterceptor.java:138) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.proc\
essInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInter\
ceptor.java:53)
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.proc\
essInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeIntercept\
or.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alph\
a4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocati\
on(SBInvocationInterceptor.java:47) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext$Invocation.proceed(Intercept\
orContext.java:406)
        at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.arou\
ndInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46) [weld-core-impl-\
2.0.3.Final.jar:2013-07-17 09:29]
        at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processIn\
vocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.Alph\
a4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInt\
erceptor.java:21)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInt\
erceptor.java:61)
        at org.jboss.as.ee.component.interceptors.ComponentDispatcherIntercepto\
r.processInvocation(ComponentDispatcherInterceptor.java:53)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processIn\
vocation(PooledInstanceInterceptor.java:51) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.\
0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxIntercep\
tor.java:251) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        ... 245 more

^[[0m^[[31m03:53:31,888 ERROR [org.jboss.as.ejb3] (default task-7) javax.ejb.EJ\
BTransactionRolledbackException: org.hibernate.exception.GenericJDBCException: \
Could not open connection
^[[0m^[[31m03:53:31,888 ERROR [org.jboss.as.ejb3.invocation] (default task-7) J\
BAS014134: EJB Invocation failed on component OrderingToolsBackendBean for meth\
od public abstract void com.ecolane.mpk.routing.interfaces.OrderingToolsBackend\
Local.persistUpdatedCustomerData(com.ecolane.mpk.persistence.Customer,java.lang\
.String): javax.ejb.EJBTransactionRolledbackException: org.hibernate.exception.\
GenericJDBCException: Could not open connection
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleInCallerTx(CMTTxInterceptor.java:163) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:253) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:342) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterce\
ptor.java:239) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInt\
erceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfl\
y-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.pr\
ocessInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0\
.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocat\
ion(SecurityContextInterceptor.java:90) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Al\
pha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$\
1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Alp\
ha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processI\
nvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alph\
a4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocat\
ion(NamespaceContextInterceptor.java:50)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.\
processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Alpha\
4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation\
(ContextClassLoaderInterceptor.java:55)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:\
325)
        at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFl\
ySecurityManager.java:419)
        at org.wildfly.security.manager.AccessCheckingInterceptor.processInvoca\
tion(AccessCheckingInterceptor.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:\
325)
        at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_03]
        at org.jboss.invocation.PrivilegedInterceptor.processInvocation(Privile\
gedInterceptor.java:75)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInt\
erceptor.java:61)
        at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:1\
65)
        at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDe\
scription.java:182)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInt\
erceptor.java:61)
        at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocat\
ionHandler.java:72)
        at com.ecolane.mpk.apps.interfaces.ToolBackendLocal$$$view1.synchOneCus\
tomerToFrontend(Unknown Source) [k3-main.jar:]
        at com.ecolane.mpk.routing.beans.OrderingToolsBackendBean.persistUpdate\
dCustomerData(OrderingToolsBackendBean.java:352) [k3-main.jar:]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:\
1.7.0_03]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl\
.java:57) [rt.jar:1.7.0_03]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcce\
ssorImpl.java:43) [rt.jar:1.7.0_03]
        at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_03]
        at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$M\
anagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterc\
eptorFactory.java:72)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInter\
ceptor.java:53)
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.proc\
essInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext$Invocation.proceed(Intercept\
orContext.java:406)
        at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception\
(Jsr299BindingsInterceptor.java:130) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha\
4]
        at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Js\
r299BindingsInterceptor.java:138) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.proc\
essInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInter\
ceptor.java:53)
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.proc\
essInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeIntercept\
or.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alph\
a4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocati\
on(SBInvocationInterceptor.java:47) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext$Invocation.proceed(Intercept\
orContext.java:406)
        at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.arou\
ndInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46) [weld-core-impl-\
2.0.3.Final.jar:2013-07-17 09:29]
        at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processIn\
vocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.Alph\
a4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInt\
erceptor.java:21)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInt\
erceptor.java:61)
        at org.jboss.as.ee.component.interceptors.ComponentDispatcherIntercepto\
r.processInvocation(ComponentDispatcherInterceptor.java:53)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processIn\
vocation(PooledInstanceInterceptor.java:51) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.\
0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxIntercep\
tor.java:251) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java\
:342) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterce\
ptor.java:239) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInt\
erceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfl\
y-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.pr\
ocessInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0\
.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:90) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Al\
pha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$\
1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Alp\
ha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processI\
nvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alph\
a4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocat\
ion(NamespaceContextInterceptor.java:50)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.\
processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Alpha\
4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation\
(ContextClassLoaderInterceptor.java:55)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:\
325)
        at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFl\
ySecurityManager.java:419)
        at org.wildfly.security.manager.AccessCheckingInterceptor.processInvoca\
tion(AccessCheckingInterceptor.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:\
325)
        at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1\
.7.0_03]
        at org.jboss.invocation.PrivilegedInterceptor.processInvocation(Privile\
gedInterceptor.java:75)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInt\
erceptor.java:61)
        at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:1\
65)
        at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDe\
scription.java:182)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
        at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72)
        at com.ecolane.mpk.routing.interfaces.OrderingToolsBackendLocal$$$view7\
2.persistUpdatedCustomerData(Unknown Source) [k3-main.jar:]
        at com.ecolane.mpk.ccagent.beans.CcAgentBackendBean.persistUpdatedCusto\
merData(CcAgentBackendBean.java:2534) [k3-main.jar:]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:\
1.7.0_03]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl\
.java:57) [rt.jar:1.7.0_03]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcce\
ssorImpl.java:43) [rt.jar:1.7.0_03]
        at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_03]
        at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$M\
anagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterc\
eptorFactory.java:72)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInter\
ceptor.java:53)
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.proc\
essInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext$Invocation.proceed(Intercept\
orContext.java:406)
        at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception\
(Jsr299BindingsInterceptor.java:130) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha\
4]
        at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Js\
r299BindingsInterceptor.java:138) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.proc\
essInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInter\
ceptor.java:53)
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.proc\
essInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeIntercept\
or.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alph\
a4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocati\
on(SBInvocationInterceptor.java:47) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
        at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.arou\
ndInvoke(AbstractEJBRequestScopeActivationInterceptor.java:55) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
        at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processIn\
vocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.Alph\
a4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInt\
erceptor.java:21)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInt\
erceptor.java:61)
        at org.jboss.as.ee.component.interceptors.ComponentDispatcherIntercepto\
r.processInvocation(ComponentDispatcherInterceptor.java:53)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processIn\
vocation(PooledInstanceInterceptor.java:51) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.\
0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor\
.java:273) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java\
:340) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterce\
ptor.java:239) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInt\
erceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfl\
y-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.pr\
ocessInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0\
.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocat\
ion(SecurityContextInterceptor.java:90) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Al\
pha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$\
1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Alp\
ha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processI\
nvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alph\
a4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.\
processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Alpha\
4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation\
(ContextClassLoaderInterceptor.java:55)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:\
325)
        at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFl\
ySecurityManager.java:428)
        at org.wildfly.security.manager.AccessCheckingInterceptor.processInvoca\
tion(AccessCheckingInterceptor.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:\
325)
        at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1\
.7.0_03]
        at org.jboss.invocation.PrivilegedInterceptor.processInvocation(Privile\
gedInterceptor.java:75)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInt\
erceptor.java:61)
        at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:1\
65)
        at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDe\
scription.java:182)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInt\
erceptor.java:61)
        at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocat\
ionHandler.java:72)
        at com.ecolane.mpk.ccagent.interfaces.CcAgentBackendLocal$$$view33.pers\
istUpdatedCustomerData(Unknown Source) [k3-main.jar:]
        at com.ecolane.mpk.ccagent.pages.ClientProfileEdit.save(ClientProfileEd\
it.java:553)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:\
1.7.0_03]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl\
.java:57) [rt.jar:1.7.0_03]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcce\
ssorImpl.java:43) [rt.jar:1.7.0_03]
        at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_03]
        at org.apache.tapestry.listener.ListenerMethodInvokerImpl.invokeTargetM\
ethod(ListenerMethodInvokerImpl.java:276) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.listener.ListenerMethodInvokerImpl.invokeListene\
rMethod(ListenerMethodInvokerImpl.java:221) [tapestry-framework-4.1.7-SNAPSHOT.\
jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.listener.ListenerMethodInvokerImpl.searchAndInvo\
ke(ListenerMethodInvokerImpl.java:157) [tapestry-framework-4.1.7-SNAPSHOT.jar:4\
.1.7-SNAPSHOT]
        at org.apache.tapestry.listener.ListenerMethodInvokerImpl.invokeListene\
rMethod(ListenerMethodInvokerImpl.java:80) [tapestry-framework-4.1.7-SNAPSHOT.j\
ar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.listener.SyntheticListener.actionTriggered(Synth\
eticListener.java:52) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.binding.ListenerMethodBinding.actionTriggered(Li\
stenerMethodBinding.java:77) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPS\
HOT]
        at org.apache.tapestry.listener.ListenerInvokerTerminator.invokeListene\
r(ListenerInvokerTerminator.java:50) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1\
.7-SNAPSHOT]
        at $ListenerInvoker_141a6814600.invokeListener($ListenerInvoker_141a681\
4600.java)       at org.apache.tapestry.form.AbstractSubmit$1.run(AbstractSubmi\
t.java:106) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.form.FormSupportImpl.runDeferredRunnables(FormSu\
pportImpl.java:673) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.form.FormSupportImpl.rewind(FormSupportImpl.java\
:646) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.form.Form.renderComponent(Form.java:196) [tapest\
ry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.AbstractComponent.render(AbstractComponent.java:\
724) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.services.impl.DefaultResponseBuilder.render(Defa\
ultResponseBuilder.java:187) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPS\
HOT]
        at org.apache.tapestry.form.Form.rewind(Form.java:269) [tapestry-framew\
ork-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.engine.RequestCycle.rewindForm(RequestCycle.java\
:469) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.form.Form.trigger(Form.java:280) [tapestry-frame\
work-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.engine.DirectService.triggerComponent(DirectServ\
ice.java:166) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.engine.DirectService.service(DirectService.java:\
142) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at $IEngineService_141a6814679.service($IEngineService_141a6814679.java\
)        at org.apache.tapestry.services.impl.EngineServiceOuterProxy.service(E\
ngineServiceOuterProxy.java:72) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SN\
APSHOT]
        at org.apache.tapestry.engine.AbstractEngine.service(AbstractEngine.jav\
a:241) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.services.impl.InvokeEngineTerminator.service(Inv\
okeEngineTerminator.java:54) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPS\
HOT]
        at $WebRequestServicer_141a6814652.service($WebRequestServicer_141a6814\
652.java)        at $WebRequestServicer_141a681464e.service($WebRequestServicer\
_141a681464e.java)        at org.apache.tapestry.services.impl.WebRequestServic\
erPipelineBridge.service(WebRequestServicerPipelineBridge.java:61) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at $ServletRequestServicer_141a6814634.service($ServletRequestServicer_\
141a6814634.java)        at org.apache.tapestry.request.DecodedRequestInjector.\
service(DecodedRequestInjector.java:55) [tapestry-framework-4.1.7-SNAPSHOT.jar:\
4.1.7-SNAPSHOT]
        at $ServletRequestServicerFilter_141a6814630.service($ServletRequestSer\
vicerFilter_141a6814630.java)    at $ServletRequestServicer_141a6814636.service\
($ServletRequestServicer_141a6814636.java)        at org.apache.tapestry.multip\
art.MultipartDecoderFilter.service(MultipartDecoderFilter.java:52) [tapestry-fr\
amework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at $ServletRequestServicerFilter_141a681462e.service($ServletRequestSer\
vicerFilter_141a681462e.java)    at $ServletRequestServicer_141a6814636.service\
($ServletRequestServicer_141a6814636.java)        at org.apache.tapestry.servic\
es.impl.SetupRequestEncoding.service(SetupRequestEncoding.java:53) [tapestry-fr\
amework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at $ServletRequestServicerFilter_141a6814632.service($ServletRequestSer\
vicerFilter_141a6814632.java)    at $ServletRequestServicer_141a6814636.service\
($ServletRequestServicer_141a6814636.java)        at $ServletRequestServicer_14\
1a6814628.service($ServletRequestServicer_141a6814628.java)        at org.apach\
e.tapestry.ApplicationServlet.doService(ApplicationServlet.java:126) [tapestry-\
framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.ApplicationServlet.doPost(ApplicationServlet.jav\
a:171) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) [jboss-\
servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-\
servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
        at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHan\
dler.java:87)
        at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(\
FilterHandler.java:130)
        at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketF\
ilter.java:136)
        at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:5\
6)
        at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(\
FilterHandler.java:132)
        at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketF\
ilter.java:136)
        at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:5\
6)
        at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(\
FilterHandler.java:132)
        at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandl\
er.java:85)
        at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.han\
dleRequest(ServletSecurityRoleHandler.java:56)
        at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest\
(ServletDispatchingHandler.java:36)
        at org.wildfly.extension.undertow.security.SecurityContextAssociationHa\
ndler.handleRequest(SecurityContextAssociationHandler.java:78)
        at io.undertow.servlet.handlers.security.SSLInformationAssociationHandl\
er.handleRequest(SSLInformationAssociationHandler.java:113)
        at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
        at io.undertow.security.handlers.AbstractConfidentialityHandler.handleR\
equest(AbstractConfidentialityHandler.java:45)
        at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHand\
ler.handleRequest(CachedAuthenticatedSessionHandler.java:65)
        at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(S\
ecurityInitialHandler.java:70)
        at io.undertow.server.handlers.PredicateHandler.handleRequest(Predicate\
Handler.java:25)
        at org.wildfly.extension.undertow.security.SecurityContextCreationHandl\
er.handleRequest(SecurityContextCreationHandler.java:54)
        at io.undertow.server.handlers.PredicateHandler.handleRequest(Predicate\
Handler.java:25)
        at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstReques\
t(ServletInitialHandler.java:207)
        at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(S\
ervletInitialHandler.java:194)
        at io.undertow.servlet.handlers.ServletInitialHandler.access$000(Servle\
tInitialHandler.java:72)
        at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(S\
ervletInitialHandler.java:128)
        at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java\
:36)
        at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:\
628)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor\
.java:1145) [rt.jar:1.7.0_03]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecuto\
r.java:615) [rt.jar:1.7.0_03]
        at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_03]
Caused by: com.ecolane.k3.db.DatabaseEJBException: org.hibernate.exception.Gene\
ricJDBCException: Could not open connection
        at com.ecolane.mpk.apps.beans.ToolBackendBean.synchOneCustomerToFronten\
d(ToolBackendBean.java:720) [k3-main.jar:]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:\
1.7.0_03]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl\
.java:57) [rt.jar:1.7.0_03]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcce\
ssorImpl.java:43) [rt.jar:1.7.0_03]
        at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_03]
        at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$M\
anagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterc\
eptorFactory.java:72)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInter\
ceptor.java:53)
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
        at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception\
(Jsr299BindingsInterceptor.java:130) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha\
4]
        at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Js\
r299BindingsInterceptor.java:138) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.proc\
essInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInter\
ceptor.java:53)
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.proc\
essInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeIntercept\
or.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alph\
a4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocati\
on(SBInvocationInterceptor.java:47) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext$Invocation.proceed(Intercept\
orContext.java:406)
        at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.arou\
ndInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46) [weld-core-impl-\
2.0.3.Final.jar:2013-07-17 09:29]
        at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processIn\
vocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.Alph\
a4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInt\
erceptor.java:21)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInt\
erceptor.java:61)
        at org.jboss.as.ee.component.interceptors.ComponentDispatcherIntercepto\
r.processInvocation(ComponentDispatcherInterceptor.java:53)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processIn\
vocation(PooledInstanceInterceptor.java:51) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.\
0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxIntercep\
tor.java:251) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        ... 245 more

^[[0m^[[32m03:53:31,909 DEBUG [org.jboss.as.jpa] (default task-7) default task-\
7:[transaction scoped EntityManager]: closing entity managersession
^[[0m^[[32m03:53:31,910 DEBUG [org.jboss.as.jpa] (default task-7) default task-\
7:[transaction scoped EntityManager]: closing entity managersession
^[[0m^[[31m03:53:31,910 ERROR [org.jboss.as.ejb3.invocation] (default task-7) J\
BAS014134: EJB Invocation failed on component CcAgentBackendBean for method pub\
lic abstract void com.ecolane.mpk.ccagent.interfaces.CcAgentBackendLocal.persis\
tUpdatedCustomerData(com.ecolane.mpk.persistence.Customer,java.lang.String): ja\
vax.ejb.EJBTransactionRolledbackException: org.hibernate.exception.GenericJDBCE\
xception: Could not open connection
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleInCallerTx(CMTTxIntercep\
tor.java:163) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxIntercep\
tor.java:253) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java\
:342) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterce\
ptor.java:239) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInt\
erceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfl\
y-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.pr\
ocessInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0\
.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocat\
ion(SecurityContextInterceptor.java:90) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Al\
pha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$\
1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Alp\
ha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processI\
nvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alph\
a4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocat\
ion(NamespaceContextInterceptor.java:50)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:55)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:\
325)
        at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFl\
ySecurityManager.java:419)
        at org.wildfly.security.manager.AccessCheckingInterceptor.processInvoca\
tion(AccessCheckingInterceptor.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:\
325)
        at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1\
.7.0_03]
        at org.jboss.invocation.PrivilegedInterceptor.processInvocation(Privile\
gedInterceptor.java:75)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInt\
erceptor.java:61)
        at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:1\
65)
        at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDe\
scription.java:182)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInt\
erceptor.java:61)
        at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocat\
ionHandler.java:72)
        at com.ecolane.mpk.apps.interfaces.ToolBackendLocal$$$view1.synchOneCus\
tomerToFrontend(Unknown Source) [k3-main.jar:]
        at com.ecolane.mpk.routing.beans.OrderingToolsBackendBean.persistUpdate\
dCustomerData(OrderingToolsBackendBean.java:352) [k3-main.jar:]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:\
1.7.0_03]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl\
.java:57) [rt.jar:1.7.0_03]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcce\
ssorImpl.java:43) [rt.jar:1.7.0_03]
        at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_03]
        at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$M\
anagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterc\
eptorFactory.java:72)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInter\
ceptor.java:53)
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.proc\
essInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
        at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception\
(Jsr299BindingsInterceptor.java:130) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha\
4]
        at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Js\
r299BindingsInterceptor.java:138) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.proc\
essInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInter\
ceptor.java:53)
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.proc\
essInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeIntercept\
or.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alph\
a4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocati\
on(SBInvocationInterceptor.java:47) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext$Invocation.proceed(Intercept\
orContext.java:406)
        at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.arou\
ndInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46) [weld-core-impl-\
2.0.3.Final.jar:2013-07-17 09:29]
        at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processIn\
vocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.Alph\
a4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInt\
erceptor.java:21)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInt\
erceptor.java:61)
        at org.jboss.as.ee.component.interceptors.ComponentDispatcherIntercepto\
r.processInvocation(ComponentDispatcherInterceptor.java:53)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processIn\
vocation(PooledInstanceInterceptor.java:51) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.\
0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:251) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:342) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterce\
ptor.java:239) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInt\
erceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfl\
y-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.pr\
ocessInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0\
.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocat\
ion(SecurityContextInterceptor.java:90) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Al\
pha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$\
1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Alp\
ha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processI\
nvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alph\
a4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocat\
ion(NamespaceContextInterceptor.java:50)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.\
processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Alpha\
4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation\
(ContextClassLoaderInterceptor.java:55)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:\
325)
        at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFl\
ySecurityManager.java:419)
        at org.wildfly.security.manager.AccessCheckingInterceptor.processInvoca\
tion(AccessCheckingInterceptor.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
        at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_03]
        at org.jboss.invocation.PrivilegedInterceptor.processInvocation(Privile\
gedInterceptor.java:75)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInt\
erceptor.java:61)
        at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:1\
65)
        at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDe\
scription.java:182)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInt\
erceptor.java:61)
        at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocat\
ionHandler.java:72)
        at com.ecolane.mpk.routing.interfaces.OrderingToolsBackendLocal$$$view7\
2.persistUpdatedCustomerData(Unknown Source) [k3-main.jar:]
        at com.ecolane.mpk.ccagent.beans.CcAgentBackendBean.persistUpdatedCusto\
merData(CcAgentBackendBean.java:2534) [k3-main.jar:]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:\
1.7.0_03]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl\
.java:57) [rt.jar:1.7.0_03]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcce\
ssorImpl.java:43) [rt.jar:1.7.0_03]
        at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_03]
        at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$M\
anagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterc\
eptorFactory.java:72)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInter\
ceptor.java:53)
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.proc\
essInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext$Invocation.proceed(Intercept\
orContext.java:406)
        at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception\
(Jsr299BindingsInterceptor.java:130) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha\
4]
        at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Js\
r299BindingsInterceptor.java:138) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.proc\
essInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInter\
ceptor.java:53)
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.proc\
essInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeIntercept\
or.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alph\
a4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocati\
on(SBInvocationInterceptor.java:47) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext$Invocation.proceed(Intercept\
orContext.java:406)
        at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.arou\
ndInvoke(AbstractEJBRequestScopeActivationInterceptor.java:55) [weld-core-impl-\
2.0.3.Final.jar:2013-07-17 09:29]
        at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processIn\
vocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.Alph\
a4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInt\
erceptor.java:21)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInt\
erceptor.java:61)
        at org.jboss.as.ee.component.interceptors.ComponentDispatcherIntercepto\
r.processInvocation(ComponentDispatcherInterceptor.java:53)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processIn\
vocation(PooledInstanceInterceptor.java:51) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.\
0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor\
.java:273) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java\
:340) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterce\
ptor.java:239) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInt\
erceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfl\
y-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.pr\
ocessInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:90) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Al\
pha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$\
1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Alp\
ha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processI\
nvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alph\
a4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocat\
ion(NamespaceContextInterceptor.java:50)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.\
processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Alpha\
4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation\
(ContextClassLoaderInterceptor.java:55)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:\
325)
        at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFl\
ySecurityManager.java:428)
        at org.wildfly.security.manager.AccessCheckingInterceptor.processInvoca\
tion(AccessCheckingInterceptor.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:\
325)
        at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1\
.7.0_03]
        at org.jboss.invocation.PrivilegedInterceptor.processInvocation(Privile\
gedInterceptor.java:75)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInt\
erceptor.java:61)
        at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:1\
65)
        at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDe\
scription.java:182)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInt\
erceptor.java:61)
        at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72)
        at com.ecolane.mpk.ccagent.interfaces.CcAgentBackendLocal$$$view33.pers\
istUpdatedCustomerData(Unknown Source) [k3-main.jar:]
        at com.ecolane.mpk.ccagent.pages.ClientProfileEdit.save(ClientProfileEd\
it.java:553)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:\
1.7.0_03]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl\
.java:57) [rt.jar:1.7.0_03]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcce\
ssorImpl.java:43) [rt.jar:1.7.0_03]
        at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_03]
        at org.apache.tapestry.listener.ListenerMethodInvokerImpl.invokeTargetM\
ethod(ListenerMethodInvokerImpl.java:276) [tapestry-framework-4.1.7-SNAPSHOT.ja\
r:4.1.7-SNAPSHOT]
        at org.apache.tapestry.listener.ListenerMethodInvokerImpl.invokeListene\
rMethod(ListenerMethodInvokerImpl.java:221) [tapestry-framework-4.1.7-SNAPSHOT.\
jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.listener.ListenerMethodInvokerImpl.searchAndInvo\
ke(ListenerMethodInvokerImpl.java:157) [tapestry-framework-4.1.7-SNAPSHOT.jar:4\
.1.7-SNAPSHOT]
        at org.apache.tapestry.listener.ListenerMethodInvokerImpl.invokeListene\
rMethod(ListenerMethodInvokerImpl.java:80) [tapestry-framework-4.1.7-SNAPSHOT.j\
ar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.listener.SyntheticListener.actionTriggered(Synth\
eticListener.java:52) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.binding.ListenerMethodBinding.actionTriggered(Li\
stenerMethodBinding.java:77) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPS\
HOT]
        at org.apache.tapestry.listener.ListenerInvokerTerminator.invokeListene\
r(ListenerInvokerTerminator.java:50) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1\
.7-SNAPSHOT]
        at $ListenerInvoker_141a6814600.invokeListener($ListenerInvoker_141a681\
4600.java)       at org.apache.tapestry.form.AbstractSubmit$1.run(AbstractSubmi\
t.java:106) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.form.FormSupportImpl.runDeferredRunnables(FormSu\
pportImpl.java:673) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.form.FormSupportImpl.rewind(FormSupportImpl.java\
:646) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.form.Form.renderComponent(Form.java:196) [tapest\
ry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.AbstractComponent.render(AbstractComponent.java:\
724) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.services.impl.DefaultResponseBuilder.render(Defa\
ultResponseBuilder.java:187) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPS\
HOT]
        at org.apache.tapestry.form.Form.rewind(Form.java:269) [tapestry-framew\
ork-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.engine.RequestCycle.rewindForm(RequestCycle.java
:469) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.form.Form.trigger(Form.java:280) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.engine.DirectService.triggerComponent(DirectService.java:166) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.engine.DirectService.service(DirectService.java:\
142) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at $IEngineService_141a6814679.service($IEngineService_141a6814679.java\
)        at org.apache.tapestry.services.impl.EngineServiceOuterProxy.service(E\
ngineServiceOuterProxy.java:72) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SN\
APSHOT]
        at org.apache.tapestry.engine.AbstractEngine.service(AbstractEngine.jav\
a:241) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.services.impl.InvokeEngineTerminator.service(Inv\
okeEngineTerminator.java:54) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPS\
HOT]
        at $WebRequestServicer_141a6814652.service($WebRequestServicer_141a6814\
652.java)        at $WebRequestServicer_141a681464e.service($WebRequestServicer\
_141a681464e.java)        at org.apache.tapestry.services.impl.WebRequestServic\
erPipelineBridge.service(WebRequestServicerPipelineBridge.java:61) [tapestry-fr\
amework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at $ServletRequestServicer_141a6814634.service($ServletRequestServicer_\
141a6814634.java)        at org.apache.tapestry.request.DecodedRequestInjector.\
service(DecodedRequestInjector.java:55) [tapestry-framework-4.1.7-SNAPSHOT.jar:\
4.1.7-SNAPSHOT]
        at $ServletRequestServicerFilter_141a6814630.service($ServletRequestSer\
vicerFilter_141a6814630.java)    at $ServletRequestServicer_141a6814636.service\
($ServletRequestServicer_141a6814636.java)        at org.apache.tapestry.multip\
art.MultipartDecoderFilter.service(MultipartDecoderFilter.java:52) [tapestry-fr\
amework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at $ServletRequestServicerFilter_141a681462e.service($ServletRequestSer\
vicerFilter_141a681462e.java)    at $ServletRequestServicer_141a6814636.service\
($ServletRequestServicer_141a6814636.java)        at org.apache.tapestry.servic\
es.impl.SetupRequestEncoding.service(SetupRequestEncoding.java:53) [tapestry-fr\
amework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at $ServletRequestServicerFilter_141a6814632.service($ServletRequestSer\
vicerFilter_141a6814632.java)    at $ServletRequestServicer_141a6814636.service\
($ServletRequestServicer_141a6814636.java)        at $ServletRequestServicer_14\
1a6814628.service($ServletRequestServicer_141a6814628.java)        at org.apach\
e.tapestry.ApplicationServlet.doService(ApplicationServlet.java:126) [tapestry-\
framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at org.apache.tapestry.ApplicationServlet.doPost(ApplicationServlet.jav\
a:171) [tapestry-framework-4.1.7-SNAPSHOT.jar:4.1.7-SNAPSHOT]
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) [jboss-\
servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-\
servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
        at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHan\
dler.java:87)
        at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(\
FilterHandler.java:130)
        at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketF\
ilter.java:136)
        at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56)
        at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
        at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136)
        at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:5\
6)
        at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(\
FilterHandler.java:132)
        at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandl\
er.java:85)
        at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.han\
dleRequest(ServletSecurityRoleHandler.java:56)
        at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest\
(ServletDispatchingHandler.java:36)
        at org.wildfly.extension.undertow.security.SecurityContextAssociationHa\
ndler.handleRequest(SecurityContextAssociationHandler.java:78)
        at io.undertow.servlet.handlers.security.SSLInformationAssociationHandl\
er.handleRequest(SSLInformationAssociationHandler.java:113)
        at io.undertow.security.handlers.AuthenticationCallHandler.handleReques\
t(AuthenticationCallHandler.java:52)
        at io.undertow.security.handlers.AbstractConfidentialityHandler.handleR\
equest(AbstractConfidentialityHandler.java:45)
        at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHand\
ler.handleRequest(CachedAuthenticatedSessionHandler.java:65)
        at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(S\
ecurityInitialHandler.java:70)
        at io.undertow.server.handlers.PredicateHandler.handleRequest(Predicate\
Handler.java:25)
        at org.wildfly.extension.undertow.security.SecurityContextCreationHandl\
er.handleRequest(SecurityContextCreationHandler.java:54)
        at io.undertow.server.handlers.PredicateHandler.handleRequest(Predicate\
Handler.java:25)
        at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstReques\
t(ServletInitialHandler.java:207)
        at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(S\
ervletInitialHandler.java:194)
        at io.undertow.servlet.handlers.ServletInitialHandler.access$000(Servle\
tInitialHandler.java:72)
        at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(S\
ervletInitialHandler.java:128)
        at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java\
:36)
        at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:\
628)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor\
.java:1145) [rt.jar:1.7.0_03]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecuto\
r.java:615) [rt.jar:1.7.0_03]
        at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_03]
Caused by: com.ecolane.k3.db.DatabaseEJBException: org.hibernate.exception.Gene\
ricJDBCException: Could not open connection
        at com.ecolane.mpk.apps.beans.ToolBackendBean.synchOneCustomerToFronten\
d(ToolBackendBean.java:720) [k3-main.jar:]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:\
1.7.0_03]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl\
.java:57) [rt.jar:1.7.0_03]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_03]
        at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_03]
        at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$M\
anagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterc\
eptorFactory.java:72)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInter\
ceptor.java:53)
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.proc\
essInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext$Invocation.proceed(Intercept\
orContext.java:406)
        at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception\
(Jsr299BindingsInterceptor.java:130) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha\
4]
        at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Js\
r299BindingsInterceptor.java:138) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.proc\
essInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInter\
ceptor.java:53)
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.proc\
essInvocation(UserInterceptorFactory.java:63)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeIntercept\
or.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alph\
a4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocati\
on(SBInvocationInterceptor.java:47) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.invocation.InterceptorContext$Invocation.proceed(Intercept\
orContext.java:406)
        at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.arou\
ndInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46) [weld-core-impl-\
2.0.3.Final.jar:2013-07-17 09:29]
        at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processIn\
vocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.Alph\
a4.jar:8.0.0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
        at org.jboss.as.ee.component.interceptors.ComponentDispatcherIntercepto\
r.processInvocation(ComponentDispatcherInterceptor.java:53)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processIn\
vocation(PooledInstanceInterceptor.java:51) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.\
0.Alpha4]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.j\
ava:309)
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxIntercep\
tor.java:251) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
        ... 245 more

^[[0m^[[32m03:53:32,079 DEBUG [hivemind.lib.StrategyFactory] (default task-7) C\
reating SingletonProxy for service hivemind.lib.StrategyFactory
^[[0m^[[32m03:53:32,082 DEBUG [hivemind.lib.StrategyFactory] (default task-7) C\
onstructing core service implementation for service hivemind.lib.StrategyFactor\
y
^[[0m^[[32m03:53:32,083 DEBUG [hivemind.lib.StrategyFactory] (default task-7) S\
et property classFactory to org.apache.tapestry.enhance.ClassFactoryImpl at 760191\
a5
^[[0m^[[32m03:53:32,083 DEBUG [org.apache.hivemind.impl.ConfigurationPointImpl]\
 (default task-7) Constructing extension point tapestry.describe.RenderStrategi\
es
^[[0m^[[32m03:53:32,101 DEBUG [org.apache.hivemind.impl.ConfigurationPointImpl]\
 (default task-7) Constructing extension point tapestry.describe.DescribableStr\
ategies
^[[0m^[[32m03:53:32,146 DEBUG [org.apache.hivemind.impl.ConfigurationPointImpl]\
 (default task-7) Constructing extension point tapestry.coerce.ListConverters
^[[0m03:53:32,206 TRACE [org.jboss.as.jpa.messages] (default task-7) returning \
global (module) Persistence Provider org.hibernate.jpa.HibernatePersistenceProv\
ider
^[[0m03:53:32,208 TRACE [org.jboss.as.jpa.messages] (default task-7) returning \
global (module) Persistence Provider org.hibernate.jpa.HibernatePersistenceProv\
ider
^[[0m^[[32m03:53:32,570 DEBUG [org.jboss.as.jpa] (k3-ExternalDispatch) k3-Exter\
nalDispatch:[transaction scoped EntityManager]: created entity manager session \
TransactionImple < ac, BasicAction: 0:ffff90cae62c:25277dea:5257ad7c:6f4 status\
: ActionStatus.RUNNING >
^[[0m03:53:32,570 TRACE [org.jboss.as.jpa.messages] (k3-ExternalDispatch) createNamedQuery name 'findAllNeedingHandling', resultClass 'com.ecolane.mpk.persistence.RouteDispatchStatus' took 1ms
^[[0m^[[32m03:53:32,572 DEBUG [org.jboss.as.jpa] (k3-ExternalDispatch) k3-ExternalDispatch:[transaction scoped EntityManager]: closing entity managersession



                
> Wrong XA Datasource selected
> ----------------------------
>
>                 Key: WFLY-2280
>                 URL: https://issues.jboss.org/browse/WFLY-2280
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>         Environment: Wildfly 8, Debian Linux
>            Reporter: Matti Linnanvuori
>            Assignee: Scott Marlow
>
> A wrong XA datasource OperationalDS instead of specified FrontendDS is chosen for a database query.
> ESC[0mESC[33m10:53:47,089 WARN  [com.arjuna.ats.jta] (default task-24) ARJUNA016089: TransactionImple.enlistResource - xa_start  - caught: XAException.XAER_INVAL for < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff90cae62c:4e8567e5:5256b6f0:2894, node_name=1, branch_uid=0:ffff90cae62c:4e8567e5:5256b6f0:2899, subordinatenodename=null, eis_name=java:/OperationalDS >: com.mysql.jdbc.jdbc2.optional.MysqlXAException: XAER_INVAL: Invalid arguments (or unsupported command)
>         at com.mysql.jdbc.jdbc2.optional.MysqlXAConnection.mapXAExceptionFromSQLException(MysqlXAConnection.java:600) [mysql-connector-java-5.1.26-bin.jar:]
>         at com.mysql.jdbc.jdbc2.optional.MysqlXAConnection.dispatchCommand(MysqlXAConnection.java:583) [mysql-connector-java-5.1.26-bin.jar:]
>         at com.mysql.jdbc.jdbc2.optional.MysqlXAConnection.start(MysqlXAConnection.java:523) [mysql-connector-java-5.1.26-bin.jar:]
>         at org.jboss.jca.adapters.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:259)
>         at org.jboss.jca.core.tx.jbossts.XAResourceWrapperImpl.start(XAResourceWrapperImpl.java:191)
>         at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:715) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
>         at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:397) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
>         at org.jboss.jca.core.connectionmanager.listener.TxConnectionListener$TransactionSynchronization.enlist(TxConnectionListener.java:607)
>         at org.jboss.jca.core.connectionmanager.listener.TxConnectionListener.enlist(TxConnectionListener.java:265)
>         at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.managedConnectionReconnected(TxConnectionManagerImpl.java:467)
>         at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.reconnectManagedConnection(AbstractConnectionManager.java:599)
>         at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:467)
>         at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:139)
>         at org.hibernate.engine.jdbc.connections.internal.DatasourceConnectionProviderImpl.getConnection(DatasourceConnectionProviderImpl.java:138) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.internal.AbstractSessionImpl$NonContextualJdbcConnectionAccess.obtainConnection(AbstractSessionImpl.java:359) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.LogicalConnectionImpl.obtainConnection(LogicalConnectionImpl.java:227) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.LogicalConnectionImpl.getConnection(LogicalConnectionImpl.java:170) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.StatementPreparerImpl.connection(StatementPreparerImpl.java:63) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.StatementPreparerImpl$5.doPrepare(StatementPreparerImpl.java:164) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.StatementPreparerImpl$StatementPreparationTemplate.prepareStatement(StatementPreparerImpl.java:185) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.StatementPreparerImpl.prepareQueryStatement(StatementPreparerImpl.java:162) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1859) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1836) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1813) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.doQuery(Loader.java:895) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:340) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.doList(Loader.java:2523) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.doList(Loader.java:2509) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2339) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.list(Loader.java:2334) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:491) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:369) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:222) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1270) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.internal.QueryImpl.list(QueryImpl.java:101) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.jpa.internal.QueryImpl.getSingleResult(QueryImpl.java:381) [hibernate-entitymanager-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at com.ecolane.mpk.frontend.beans.FrontendLiaisonBean.getOurFeService(FrontendLiaisonBean.java:123) [k3-main.jar:]
>         at com.ecolane.mpk.frontend.beans.FrontendLiaisonBean.synchOneCustomerToFrontend(FrontendLiaisonBean.java:362) [k3-main.jar:]
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_03]
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_03]
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_03]
>         at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_03]
>         at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
>         at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:130) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:138) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
>         at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
>         at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:251) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:342) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:90) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:55)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
>         at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:419)
>         at org.wildfly.security.manager.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
>         at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_03]
>         at org.jboss.invocation.PrivilegedInterceptor.processInvocation(PrivilegedInterceptor.java:75)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
>         at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72)
>         at com.ecolane.mpk.frontend.beans.FrontendLiaisonLocal$$$view296.synchOneCustomerToFrontend(Unknown Source) [k3-main.jar:]
>         at com.ecolane.mpk.apps.beans.ToolBackendBean.synchOneCustomerToFrontend(ToolBackendBean.java:717) [k3-main.jar:]
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_03]
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_03]
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_03]
>         at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_03]
>         at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
>         at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:130) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:138) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
>         at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
>         at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:251) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:342) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>     @PersistenceContext(unitName=K3Configuration.PERSISTENCE_CONTEXT_FRONTEND_NAME)
>     private transient EntityManager entityManager;
>                 <xa-datasource jndi-name="java:/FrontendDS" pool-name="MpkDemoUsFrontendDS" enabled="true">
>                     <xa-datasource-property name="ServerName">
>                         localhost
>                     </xa-datasource-property>
>                     <xa-datasource-property name="DatabaseName">
>                         production
>                     </xa-datasource-property>
>                     <driver>mysql</driver>
>                     <security>
>                         <user-name>frontend</user-name>
>                         <password>fghfghfghfh</password>
>                     </security>
>                 </xa-datasource>
> <?xml version="1.0" encoding="UTF-8"?>
> <persistence xmlns="http://java.sun.com/xml/ns/persistence"
>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>     xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd"
>     version="2.0">
>     <persistence-unit name="k3_frontend_persistence" transaction-type="JTA">
>         <jta-data-source>@DATASOURCE_FRONTEND@</jta-data-source>
>         <shared-cache-mode>ENABLE_SELECTIVE</shared-cache-mode>
>                 <properties>
>             <property name="hibernate.dialect" value="com.ecolane.mpk.persistence.util.Mysql5BitBooleanInnoDBDialect" />
>                         <property name="jboss.entity.manager.jndi.name" value="K3FrontendEntityManager" />
>                         <property name="jboss.entity.manager.factory.jndi.name"
>                                 value="K3FrontendEntityManagerFactory" />
>             <property name="hibernate.hbm2ddl.auto" value="validate"/>
>             
>             <!-- Infinispan conf -->
>             <property name="hibernate.cache.use_second_level_cache" value="true"/>
>             <property name="hibernate.cache.use_query_cache" value="true"/>
> <!--             <property name="hibernate.cache.region.factory_class" -->
> />
>             <property name="hibernate.cache.use_query_cache" value="true"/>
> <!--             <property name="hibernate.cache.region.factory_class" -->
> <!--                 value="org.hibernate.cache.infinispan.JndiInfinispanRegionFactory"/> -->
> <!--             <property name="hibernate.cache.region.factory_class" -->
> <!--                 value="org.hibernate.cache.infinispan.InfinispanRegionFactory"/> -->
> <!--             <property name="hibernate.cache.infinispan.cfg" value="infinispan-configs.xml" />   -->
> <!--             <property name="hibernate.cache.infinispan.cachemanager" value="java:CacheManager/entity"/> -->
>             <property name="hibernate.generate_statistics" value="true" />
> <!--             <property name="hibernate.cache.use_structured_entries" value="false" /> -->
>             <!-- property name="hibernate.cache.infinispan.statistics" value="true"/-->
> <!--             <property name="hibernate.transaction.manager_lookup_class" -->
> <!--                 value="org.hibernate.transaction.JBossTransactionManagerLookup"/> -->
>                 </properties>
>         </persistence-unit>
> </persistence>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 05:07:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Fri, 11 Oct 2013 05:07:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2190) Priviledge alignment for
	scoped resources
In-Reply-To: <JIRA.12501904.1380621634000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501904.1380621634000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501904.1380621634000.32818.1381482423171@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun reopened WFLY-2190:
-------------------------------



I am reopening this,since the permissions seem to have changed. See my comments on the HAL issues, that's linked.
                
> Priviledge alignment for scoped resources
> -----------------------------------------
>
>                 Key: WFLY-2190
>                 URL: https://issues.jboss.org/browse/WFLY-2190
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> server-groups show different privildges for {{server-group=*}} and {{server-group=<specific instance>}}. when accessing these as a scoped role we use the <specific instance> to determine the operation priviledges. 
> Would it be possible that the operation permissions for {{server-group=<specific instance>:<add|remove>}} show the same permissions as {{server-group=*:<add|remove>}}? 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 05:34:02 2013
From: jira-events at lists.jboss.org (Gytis Trikleris (JIRA))
Date: Fri, 11 Oct 2013 05:34:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2285) Upgrade Narayana to 5.0.0.M6
In-Reply-To: <JIRA.12502762.1381483950620@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502762.1381483950620@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502762.1381483950620.32868.1381484042564@jira02.app.mwc.hst.phx2.redhat.com>

Gytis Trikleris created WFLY-2285:
-------------------------------------

             Summary: Upgrade Narayana to 5.0.0.M6
                 Key: WFLY-2285
                 URL: https://issues.jboss.org/browse/WFLY-2285
             Project: WildFly
          Issue Type: Component  Upgrade
          Components: Transactions
            Reporter: Gytis Trikleris
            Assignee: Gytis Trikleris
             Fix For: 8.0.0.CR1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 05:51:03 2013
From: jira-events at lists.jboss.org (=?UTF-8?Q?Daniel_G=C3=B6ring_=28JIRA=29?=)
Date: Fri, 11 Oct 2013 05:51:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (EJBTHREE-558) Memory Leak in
 AuthenticationInterceptor
In-Reply-To: <JIRA.12325522.1147272322000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12325522.1147272322000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12325522.1147272322000.32896.1381485063047@jira02.app.mwc.hst.phx2.redhat.com>

An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-jira/attachments/20131011/05fcfb4b/attachment.html 

From jira-events at lists.jboss.org  Fri Oct 11 06:28:03 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Fri, 11 Oct 2013 06:28:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2286) Chunking performance issues
In-Reply-To: <JIRA.12502765.1381487225378@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502765.1381487225378@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502765.1381487225378.32938.1381487283024@jira02.app.mwc.hst.phx2.redhat.com>

Stuart Douglas created WFLY-2286:
------------------------------------

             Summary: Chunking performance issues
                 Key: WFLY-2286
                 URL: https://issues.jboss.org/browse/WFLY-2286
             Project: WildFly
          Issue Type: Bug
            Reporter: Stuart Douglas


Chunking currently has a few performance issues compared to jboss web:

- The chunk end byte is written out as a separate write() operation, as the buffer sits above the chunking operation
- flush() will always cause a write(), so flush( ) followed by close() will cause two write ops, even if the issue above is resolved. 

JBoss web worked around this via a second output buffer, below the chunking implementation (the socket buffer). I don't really want to have to double buffer unless it is absolutely necessary however. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 06:49:02 2013
From: jira-events at lists.jboss.org (=?UTF-8?Q?Daniel_G=C3=B6ring_=28JIRA=29?=)
Date: Fri, 11 Oct 2013 06:49:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (EJBTHREE-1891) ServiceContainer may not
 be popping the Principal
In-Reply-To: <JIRA.12392047.1250589432000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12392047.1250589432000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12392047.1250589432000.32949.1381488542842@jira02.app.mwc.hst.phx2.redhat.com>

An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-jira/attachments/20131011/233a8cb1/attachment.html 

From jira-events at lists.jboss.org  Fri Oct 11 07:10:02 2013
From: jira-events at lists.jboss.org (Daniel Sachse (JIRA))
Date: Fri, 11 Oct 2013 07:10:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2287) Java 8 Class files not
	loading in Beta1
In-Reply-To: <JIRA.12502769.1381489732481@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502769.1381489732481@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502769.1381489732481.32985.1381489802524@jira02.app.mwc.hst.phx2.redhat.com>

Daniel Sachse created WFLY-2287:
-----------------------------------

             Summary: Java 8 Class files not loading in Beta1
                 Key: WFLY-2287
                 URL: https://issues.jboss.org/browse/WFLY-2287
             Project: WildFly
          Issue Type: Bug
    Affects Versions: 8.0.0.Beta1
            Reporter: Daniel Sachse


As soon as I try to deploy a Java EE webapp that contains classes with Java 8 Lambda expressions, Wildfly throws an Exception e.g. "java.lang.IllegalStateException: Unknown tag! pos=12 poolCount = 130".

[~jason.greene] proposed a working workaround (see workaround section)

Sample application can be found at: https://github.com/wombatsoftware/Omikron

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 07:23:02 2013
From: jira-events at lists.jboss.org (Daniel Sachse (JIRA))
Date: Fri, 11 Oct 2013 07:23:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2287) Java 8 Class files not
	loading in Beta1
In-Reply-To: <JIRA.12502769.1381489732000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502769.1381489732000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502769.1381489732000.32993.1381490582524@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Daniel Sachse updated WFLY-2287:
--------------------------------

    Git Pull Request: https://github.com/wildfly/wildfly/pull/5261

    
> Java 8 Class files not loading in Beta1
> ---------------------------------------
>
>                 Key: WFLY-2287
>                 URL: https://issues.jboss.org/browse/WFLY-2287
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Daniel Sachse
>
> As soon as I try to deploy a Java EE webapp that contains classes with Java 8 Lambda expressions, Wildfly throws an Exception e.g. "java.lang.IllegalStateException: Unknown tag! pos=12 poolCount = 130".
> [~jason.greene] proposed a working workaround (see workaround section)
> Sample application can be found at: https://github.com/wombatsoftware/Omikron

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 07:23:02 2013
From: jira-events at lists.jboss.org (S BH (JIRA))
Date: Fri, 11 Oct 2013 07:23:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (AS7-4265) cli command to add/remove AS
	modules
In-Reply-To: <JIRA.12462275.1332435368000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12462275.1332435368000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12462275.1332435368000.32998.1381490582827@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-4265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813375#comment-12813375 ] 

S BH commented on AS7-4265:
---------------------------

Not working, giving exception:

[standalone at localhost:9999 /] module add --name=com.mysql --resources=mysql-connector-java-5.1.13-bin.jar --dependencies=javax.api,javax.transaction.a
pi
Unexpected command 'module add --name=com.mysql --resources=mysql-connector-java-5.1.13-bin.jar --dependencies=javax.api,javax.transaction.api'. Type
'help --commands' for the list of supported commands.
                
> cli command to add/remove AS modules
> ------------------------------------
>
>                 Key: AS7-4265
>                 URL: https://issues.jboss.org/browse/AS7-4265
>             Project: Application Server 7
>          Issue Type: Task
>          Components: CLI
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: 7.1.2.Final (EAP)
>
>
> I think it'd be useful to have a command to add modules to the AS which given the jars, dependencies, etc would generate the structure in the modules dir, copy the jars and generate the xml.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 07:25:02 2013
From: jira-events at lists.jboss.org (S BH (JIRA))
Date: Fri, 11 Oct 2013 07:25:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (AS7-4265) cli command to add/remove AS
	modules
In-Reply-To: <JIRA.12462275.1332435368000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12462275.1332435368000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12462275.1332435368000.33005.1381490702874@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-4265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813375#comment-12813375 ] 

S BH edited comment on AS7-4265 at 10/11/13 7:23 AM:
-----------------------------------------------------

Not working, giving exception:

[standalone at localhost:9999 /] module add --name=com.mysql --resources=mysql-connector-java-5.1.13-bin.jar --dependencies=javax.api,javax.transaction.api

Unexpected command 'module add --name=com.mysql --resources=mysql-connector-java-5.1.13-bin.jar --dependencies=javax.api,javax.transaction.api'. Type
'help --commands' for the list of supported commands.
                
      was (Author: spbhosale):
    Not working, giving exception:

[standalone at localhost:9999 /] module add --name=com.mysql --resources=mysql-connector-java-5.1.13-bin.jar --dependencies=javax.api,javax.transaction.a
pi
Unexpected command 'module add --name=com.mysql --resources=mysql-connector-java-5.1.13-bin.jar --dependencies=javax.api,javax.transaction.api'. Type
'help --commands' for the list of supported commands.
                  
> cli command to add/remove AS modules
> ------------------------------------
>
>                 Key: AS7-4265
>                 URL: https://issues.jboss.org/browse/AS7-4265
>             Project: Application Server 7
>          Issue Type: Task
>          Components: CLI
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: 7.1.2.Final (EAP)
>
>
> I think it'd be useful to have a command to add modules to the AS which given the jars, dependencies, etc would generate the structure in the modules dir, copy the jars and generate the xml.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 07:25:03 2013
From: jira-events at lists.jboss.org (S BH (JIRA))
Date: Fri, 11 Oct 2013 07:25:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (AS7-4265) cli command to add/remove AS
	modules
In-Reply-To: <JIRA.12462275.1332435368000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12462275.1332435368000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12462275.1332435368000.33010.1381490703115@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-4265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813375#comment-12813375 ] 

S BH edited comment on AS7-4265 at 10/11/13 7:23 AM:
-----------------------------------------------------

Not working, giving exception:

[standalone at localhost:9999 /] module add --name=com.mysql --resources=mysql-connector-java-5.1.13-bin.jar --dependencies=javax.api,javax.transaction.api

Unexpected command 'module add --name=com.mysql --resources=mysql-connector-java-5.1.13-bin.jar --dependencies=javax.api,javax.transaction.api'. Type 'help --commands' for the list of supported commands.
                
      was (Author: spbhosale):
    Not working, giving exception:

[standalone at localhost:9999 /] module add --name=com.mysql --resources=mysql-connector-java-5.1.13-bin.jar --dependencies=javax.api,javax.transaction.api

Unexpected command 'module add --name=com.mysql --resources=mysql-connector-java-5.1.13-bin.jar --dependencies=javax.api,javax.transaction.api'. Type
'help --commands' for the list of supported commands.
                  
> cli command to add/remove AS modules
> ------------------------------------
>
>                 Key: AS7-4265
>                 URL: https://issues.jboss.org/browse/AS7-4265
>             Project: Application Server 7
>          Issue Type: Task
>          Components: CLI
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: 7.1.2.Final (EAP)
>
>
> I think it'd be useful to have a command to add modules to the AS which given the jars, dependencies, etc would generate the structure in the modules dir, copy the jars and generate the xml.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 07:45:02 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Fri, 11 Oct 2013 07:45:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2280) Wrong XA Datasource selected
In-Reply-To: <JIRA.12502716.1381418849000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502716.1381418849000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502716.1381418849000.33061.1381491902765@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813379#comment-12813379 ] 

Scott Marlow commented on WFLY-2280:
------------------------------------

Why did you reopen this without determining that WildFly is doing something wrong?  It sounds more like a problem in your application. You probably have multiple persistence.xml files that you are not aware of (e.g. look in k3-operational-entities.jar that is in your ear).  

If you need help and have questions about what is wrong with your application, please use the forums.
                
> Wrong XA Datasource selected
> ----------------------------
>
>                 Key: WFLY-2280
>                 URL: https://issues.jboss.org/browse/WFLY-2280
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>         Environment: Wildfly 8, Debian Linux
>            Reporter: Matti Linnanvuori
>            Assignee: Scott Marlow
>
> A wrong XA datasource OperationalDS instead of specified FrontendDS is chosen for a database query.
> ESC[0mESC[33m10:53:47,089 WARN  [com.arjuna.ats.jta] (default task-24) ARJUNA016089: TransactionImple.enlistResource - xa_start  - caught: XAException.XAER_INVAL for < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff90cae62c:4e8567e5:5256b6f0:2894, node_name=1, branch_uid=0:ffff90cae62c:4e8567e5:5256b6f0:2899, subordinatenodename=null, eis_name=java:/OperationalDS >: com.mysql.jdbc.jdbc2.optional.MysqlXAException: XAER_INVAL: Invalid arguments (or unsupported command)
>         at com.mysql.jdbc.jdbc2.optional.MysqlXAConnection.mapXAExceptionFromSQLException(MysqlXAConnection.java:600) [mysql-connector-java-5.1.26-bin.jar:]
>         at com.mysql.jdbc.jdbc2.optional.MysqlXAConnection.dispatchCommand(MysqlXAConnection.java:583) [mysql-connector-java-5.1.26-bin.jar:]
>         at com.mysql.jdbc.jdbc2.optional.MysqlXAConnection.start(MysqlXAConnection.java:523) [mysql-connector-java-5.1.26-bin.jar:]
>         at org.jboss.jca.adapters.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:259)
>         at org.jboss.jca.core.tx.jbossts.XAResourceWrapperImpl.start(XAResourceWrapperImpl.java:191)
>         at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:715) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
>         at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:397) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
>         at org.jboss.jca.core.connectionmanager.listener.TxConnectionListener$TransactionSynchronization.enlist(TxConnectionListener.java:607)
>         at org.jboss.jca.core.connectionmanager.listener.TxConnectionListener.enlist(TxConnectionListener.java:265)
>         at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.managedConnectionReconnected(TxConnectionManagerImpl.java:467)
>         at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.reconnectManagedConnection(AbstractConnectionManager.java:599)
>         at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:467)
>         at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:139)
>         at org.hibernate.engine.jdbc.connections.internal.DatasourceConnectionProviderImpl.getConnection(DatasourceConnectionProviderImpl.java:138) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.internal.AbstractSessionImpl$NonContextualJdbcConnectionAccess.obtainConnection(AbstractSessionImpl.java:359) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.LogicalConnectionImpl.obtainConnection(LogicalConnectionImpl.java:227) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.LogicalConnectionImpl.getConnection(LogicalConnectionImpl.java:170) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.StatementPreparerImpl.connection(StatementPreparerImpl.java:63) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.StatementPreparerImpl$5.doPrepare(StatementPreparerImpl.java:164) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.StatementPreparerImpl$StatementPreparationTemplate.prepareStatement(StatementPreparerImpl.java:185) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.StatementPreparerImpl.prepareQueryStatement(StatementPreparerImpl.java:162) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1859) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1836) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1813) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.doQuery(Loader.java:895) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:340) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.doList(Loader.java:2523) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.doList(Loader.java:2509) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2339) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.list(Loader.java:2334) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:491) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:369) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:222) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1270) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.internal.QueryImpl.list(QueryImpl.java:101) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.jpa.internal.QueryImpl.getSingleResult(QueryImpl.java:381) [hibernate-entitymanager-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at com.ecolane.mpk.frontend.beans.FrontendLiaisonBean.getOurFeService(FrontendLiaisonBean.java:123) [k3-main.jar:]
>         at com.ecolane.mpk.frontend.beans.FrontendLiaisonBean.synchOneCustomerToFrontend(FrontendLiaisonBean.java:362) [k3-main.jar:]
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_03]
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_03]
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_03]
>         at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_03]
>         at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
>         at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:130) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:138) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
>         at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
>         at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:251) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:342) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:90) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:55)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
>         at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:419)
>         at org.wildfly.security.manager.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
>         at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_03]
>         at org.jboss.invocation.PrivilegedInterceptor.processInvocation(PrivilegedInterceptor.java:75)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
>         at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72)
>         at com.ecolane.mpk.frontend.beans.FrontendLiaisonLocal$$$view296.synchOneCustomerToFrontend(Unknown Source) [k3-main.jar:]
>         at com.ecolane.mpk.apps.beans.ToolBackendBean.synchOneCustomerToFrontend(ToolBackendBean.java:717) [k3-main.jar:]
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_03]
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_03]
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_03]
>         at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_03]
>         at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
>         at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:130) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:138) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
>         at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
>         at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:251) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:342) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>     @PersistenceContext(unitName=K3Configuration.PERSISTENCE_CONTEXT_FRONTEND_NAME)
>     private transient EntityManager entityManager;
>                 <xa-datasource jndi-name="java:/FrontendDS" pool-name="MpkDemoUsFrontendDS" enabled="true">
>                     <xa-datasource-property name="ServerName">
>                         localhost
>                     </xa-datasource-property>
>                     <xa-datasource-property name="DatabaseName">
>                         production
>                     </xa-datasource-property>
>                     <driver>mysql</driver>
>                     <security>
>                         <user-name>frontend</user-name>
>                         <password>fghfghfghfh</password>
>                     </security>
>                 </xa-datasource>
> <?xml version="1.0" encoding="UTF-8"?>
> <persistence xmlns="http://java.sun.com/xml/ns/persistence"
>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>     xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd"
>     version="2.0">
>     <persistence-unit name="k3_frontend_persistence" transaction-type="JTA">
>         <jta-data-source>@DATASOURCE_FRONTEND@</jta-data-source>
>         <shared-cache-mode>ENABLE_SELECTIVE</shared-cache-mode>
>                 <properties>
>             <property name="hibernate.dialect" value="com.ecolane.mpk.persistence.util.Mysql5BitBooleanInnoDBDialect" />
>                         <property name="jboss.entity.manager.jndi.name" value="K3FrontendEntityManager" />
>                         <property name="jboss.entity.manager.factory.jndi.name"
>                                 value="K3FrontendEntityManagerFactory" />
>             <property name="hibernate.hbm2ddl.auto" value="validate"/>
>             
>             <!-- Infinispan conf -->
>             <property name="hibernate.cache.use_second_level_cache" value="true"/>
>             <property name="hibernate.cache.use_query_cache" value="true"/>
> <!--             <property name="hibernate.cache.region.factory_class" -->
> />
>             <property name="hibernate.cache.use_query_cache" value="true"/>
> <!--             <property name="hibernate.cache.region.factory_class" -->
> <!--                 value="org.hibernate.cache.infinispan.JndiInfinispanRegionFactory"/> -->
> <!--             <property name="hibernate.cache.region.factory_class" -->
> <!--                 value="org.hibernate.cache.infinispan.InfinispanRegionFactory"/> -->
> <!--             <property name="hibernate.cache.infinispan.cfg" value="infinispan-configs.xml" />   -->
> <!--             <property name="hibernate.cache.infinispan.cachemanager" value="java:CacheManager/entity"/> -->
>             <property name="hibernate.generate_statistics" value="true" />
> <!--             <property name="hibernate.cache.use_structured_entries" value="false" /> -->
>             <!-- property name="hibernate.cache.infinispan.statistics" value="true"/-->
> <!--             <property name="hibernate.transaction.manager_lookup_class" -->
> <!--                 value="org.hibernate.transaction.JBossTransactionManagerLookup"/> -->
>                 </properties>
>         </persistence-unit>
> </persistence>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 07:45:02 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Fri, 11 Oct 2013 07:45:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2280) Wrong XA Datasource selected
In-Reply-To: <JIRA.12502716.1381418849000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502716.1381418849000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502716.1381418849000.33065.1381491902934@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow resolved WFLY-2280.
--------------------------------

    Resolution: Rejected

    
> Wrong XA Datasource selected
> ----------------------------
>
>                 Key: WFLY-2280
>                 URL: https://issues.jboss.org/browse/WFLY-2280
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>         Environment: Wildfly 8, Debian Linux
>            Reporter: Matti Linnanvuori
>            Assignee: Scott Marlow
>
> A wrong XA datasource OperationalDS instead of specified FrontendDS is chosen for a database query.
> ESC[0mESC[33m10:53:47,089 WARN  [com.arjuna.ats.jta] (default task-24) ARJUNA016089: TransactionImple.enlistResource - xa_start  - caught: XAException.XAER_INVAL for < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff90cae62c:4e8567e5:5256b6f0:2894, node_name=1, branch_uid=0:ffff90cae62c:4e8567e5:5256b6f0:2899, subordinatenodename=null, eis_name=java:/OperationalDS >: com.mysql.jdbc.jdbc2.optional.MysqlXAException: XAER_INVAL: Invalid arguments (or unsupported command)
>         at com.mysql.jdbc.jdbc2.optional.MysqlXAConnection.mapXAExceptionFromSQLException(MysqlXAConnection.java:600) [mysql-connector-java-5.1.26-bin.jar:]
>         at com.mysql.jdbc.jdbc2.optional.MysqlXAConnection.dispatchCommand(MysqlXAConnection.java:583) [mysql-connector-java-5.1.26-bin.jar:]
>         at com.mysql.jdbc.jdbc2.optional.MysqlXAConnection.start(MysqlXAConnection.java:523) [mysql-connector-java-5.1.26-bin.jar:]
>         at org.jboss.jca.adapters.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:259)
>         at org.jboss.jca.core.tx.jbossts.XAResourceWrapperImpl.start(XAResourceWrapperImpl.java:191)
>         at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:715) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
>         at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:397) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
>         at org.jboss.jca.core.connectionmanager.listener.TxConnectionListener$TransactionSynchronization.enlist(TxConnectionListener.java:607)
>         at org.jboss.jca.core.connectionmanager.listener.TxConnectionListener.enlist(TxConnectionListener.java:265)
>         at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.managedConnectionReconnected(TxConnectionManagerImpl.java:467)
>         at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.reconnectManagedConnection(AbstractConnectionManager.java:599)
>         at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:467)
>         at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:139)
>         at org.hibernate.engine.jdbc.connections.internal.DatasourceConnectionProviderImpl.getConnection(DatasourceConnectionProviderImpl.java:138) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.internal.AbstractSessionImpl$NonContextualJdbcConnectionAccess.obtainConnection(AbstractSessionImpl.java:359) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.LogicalConnectionImpl.obtainConnection(LogicalConnectionImpl.java:227) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.LogicalConnectionImpl.getConnection(LogicalConnectionImpl.java:170) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.StatementPreparerImpl.connection(StatementPreparerImpl.java:63) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.StatementPreparerImpl$5.doPrepare(StatementPreparerImpl.java:164) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.StatementPreparerImpl$StatementPreparationTemplate.prepareStatement(StatementPreparerImpl.java:185) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.StatementPreparerImpl.prepareQueryStatement(StatementPreparerImpl.java:162) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1859) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1836) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1813) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.doQuery(Loader.java:895) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:340) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.doList(Loader.java:2523) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.doList(Loader.java:2509) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2339) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.list(Loader.java:2334) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:491) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:369) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:222) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1270) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.internal.QueryImpl.list(QueryImpl.java:101) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.jpa.internal.QueryImpl.getSingleResult(QueryImpl.java:381) [hibernate-entitymanager-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at com.ecolane.mpk.frontend.beans.FrontendLiaisonBean.getOurFeService(FrontendLiaisonBean.java:123) [k3-main.jar:]
>         at com.ecolane.mpk.frontend.beans.FrontendLiaisonBean.synchOneCustomerToFrontend(FrontendLiaisonBean.java:362) [k3-main.jar:]
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_03]
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_03]
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_03]
>         at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_03]
>         at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
>         at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:130) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:138) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
>         at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
>         at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:251) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:342) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:90) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:55)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
>         at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:419)
>         at org.wildfly.security.manager.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
>         at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_03]
>         at org.jboss.invocation.PrivilegedInterceptor.processInvocation(PrivilegedInterceptor.java:75)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
>         at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72)
>         at com.ecolane.mpk.frontend.beans.FrontendLiaisonLocal$$$view296.synchOneCustomerToFrontend(Unknown Source) [k3-main.jar:]
>         at com.ecolane.mpk.apps.beans.ToolBackendBean.synchOneCustomerToFrontend(ToolBackendBean.java:717) [k3-main.jar:]
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_03]
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_03]
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_03]
>         at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_03]
>         at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
>         at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:130) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:138) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
>         at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
>         at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:251) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:342) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>     @PersistenceContext(unitName=K3Configuration.PERSISTENCE_CONTEXT_FRONTEND_NAME)
>     private transient EntityManager entityManager;
>                 <xa-datasource jndi-name="java:/FrontendDS" pool-name="MpkDemoUsFrontendDS" enabled="true">
>                     <xa-datasource-property name="ServerName">
>                         localhost
>                     </xa-datasource-property>
>                     <xa-datasource-property name="DatabaseName">
>                         production
>                     </xa-datasource-property>
>                     <driver>mysql</driver>
>                     <security>
>                         <user-name>frontend</user-name>
>                         <password>fghfghfghfh</password>
>                     </security>
>                 </xa-datasource>
> <?xml version="1.0" encoding="UTF-8"?>
> <persistence xmlns="http://java.sun.com/xml/ns/persistence"
>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>     xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd"
>     version="2.0">
>     <persistence-unit name="k3_frontend_persistence" transaction-type="JTA">
>         <jta-data-source>@DATASOURCE_FRONTEND@</jta-data-source>
>         <shared-cache-mode>ENABLE_SELECTIVE</shared-cache-mode>
>                 <properties>
>             <property name="hibernate.dialect" value="com.ecolane.mpk.persistence.util.Mysql5BitBooleanInnoDBDialect" />
>                         <property name="jboss.entity.manager.jndi.name" value="K3FrontendEntityManager" />
>                         <property name="jboss.entity.manager.factory.jndi.name"
>                                 value="K3FrontendEntityManagerFactory" />
>             <property name="hibernate.hbm2ddl.auto" value="validate"/>
>             
>             <!-- Infinispan conf -->
>             <property name="hibernate.cache.use_second_level_cache" value="true"/>
>             <property name="hibernate.cache.use_query_cache" value="true"/>
> <!--             <property name="hibernate.cache.region.factory_class" -->
> />
>             <property name="hibernate.cache.use_query_cache" value="true"/>
> <!--             <property name="hibernate.cache.region.factory_class" -->
> <!--                 value="org.hibernate.cache.infinispan.JndiInfinispanRegionFactory"/> -->
> <!--             <property name="hibernate.cache.region.factory_class" -->
> <!--                 value="org.hibernate.cache.infinispan.InfinispanRegionFactory"/> -->
> <!--             <property name="hibernate.cache.infinispan.cfg" value="infinispan-configs.xml" />   -->
> <!--             <property name="hibernate.cache.infinispan.cachemanager" value="java:CacheManager/entity"/> -->
>             <property name="hibernate.generate_statistics" value="true" />
> <!--             <property name="hibernate.cache.use_structured_entries" value="false" /> -->
>             <!-- property name="hibernate.cache.infinispan.statistics" value="true"/-->
> <!--             <property name="hibernate.transaction.manager_lookup_class" -->
> <!--                 value="org.hibernate.transaction.JBossTransactionManagerLookup"/> -->
>                 </properties>
>         </persistence-unit>
> </persistence>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 08:43:26 2013
From: jira-events at lists.jboss.org (Radoslav Husar (JIRA))
Date: Fri, 11 Oct 2013 08:43:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2280) Wrong XA Datasource selected
In-Reply-To: <JIRA.12502716.1381418849000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502716.1381418849000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502716.1381418849000.58.1381495406894@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813410#comment-12813410 ] 

Radoslav Husar commented on WFLY-2280:
--------------------------------------

WildFly forums for user questions: https://community.jboss.org/en/wildfly
                
> Wrong XA Datasource selected
> ----------------------------
>
>                 Key: WFLY-2280
>                 URL: https://issues.jboss.org/browse/WFLY-2280
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>         Environment: Wildfly 8, Debian Linux
>            Reporter: Matti Linnanvuori
>            Assignee: Scott Marlow
>
> A wrong XA datasource OperationalDS instead of specified FrontendDS is chosen for a database query.
> ESC[0mESC[33m10:53:47,089 WARN  [com.arjuna.ats.jta] (default task-24) ARJUNA016089: TransactionImple.enlistResource - xa_start  - caught: XAException.XAER_INVAL for < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff90cae62c:4e8567e5:5256b6f0:2894, node_name=1, branch_uid=0:ffff90cae62c:4e8567e5:5256b6f0:2899, subordinatenodename=null, eis_name=java:/OperationalDS >: com.mysql.jdbc.jdbc2.optional.MysqlXAException: XAER_INVAL: Invalid arguments (or unsupported command)
>         at com.mysql.jdbc.jdbc2.optional.MysqlXAConnection.mapXAExceptionFromSQLException(MysqlXAConnection.java:600) [mysql-connector-java-5.1.26-bin.jar:]
>         at com.mysql.jdbc.jdbc2.optional.MysqlXAConnection.dispatchCommand(MysqlXAConnection.java:583) [mysql-connector-java-5.1.26-bin.jar:]
>         at com.mysql.jdbc.jdbc2.optional.MysqlXAConnection.start(MysqlXAConnection.java:523) [mysql-connector-java-5.1.26-bin.jar:]
>         at org.jboss.jca.adapters.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:259)
>         at org.jboss.jca.core.tx.jbossts.XAResourceWrapperImpl.start(XAResourceWrapperImpl.java:191)
>         at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:715) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
>         at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:397) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
>         at org.jboss.jca.core.connectionmanager.listener.TxConnectionListener$TransactionSynchronization.enlist(TxConnectionListener.java:607)
>         at org.jboss.jca.core.connectionmanager.listener.TxConnectionListener.enlist(TxConnectionListener.java:265)
>         at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.managedConnectionReconnected(TxConnectionManagerImpl.java:467)
>         at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.reconnectManagedConnection(AbstractConnectionManager.java:599)
>         at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:467)
>         at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:139)
>         at org.hibernate.engine.jdbc.connections.internal.DatasourceConnectionProviderImpl.getConnection(DatasourceConnectionProviderImpl.java:138) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.internal.AbstractSessionImpl$NonContextualJdbcConnectionAccess.obtainConnection(AbstractSessionImpl.java:359) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.LogicalConnectionImpl.obtainConnection(LogicalConnectionImpl.java:227) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.LogicalConnectionImpl.getConnection(LogicalConnectionImpl.java:170) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.StatementPreparerImpl.connection(StatementPreparerImpl.java:63) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.StatementPreparerImpl$5.doPrepare(StatementPreparerImpl.java:164) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.StatementPreparerImpl$StatementPreparationTemplate.prepareStatement(StatementPreparerImpl.java:185) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.StatementPreparerImpl.prepareQueryStatement(StatementPreparerImpl.java:162) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1859) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1836) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1813) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.doQuery(Loader.java:895) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:340) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.doList(Loader.java:2523) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.doList(Loader.java:2509) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2339) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.list(Loader.java:2334) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:491) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:369) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:222) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1270) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.internal.QueryImpl.list(QueryImpl.java:101) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.jpa.internal.QueryImpl.getSingleResult(QueryImpl.java:381) [hibernate-entitymanager-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at com.ecolane.mpk.frontend.beans.FrontendLiaisonBean.getOurFeService(FrontendLiaisonBean.java:123) [k3-main.jar:]
>         at com.ecolane.mpk.frontend.beans.FrontendLiaisonBean.synchOneCustomerToFrontend(FrontendLiaisonBean.java:362) [k3-main.jar:]
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_03]
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_03]
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_03]
>         at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_03]
>         at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
>         at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:130) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:138) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
>         at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
>         at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:251) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:342) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:90) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:55)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
>         at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:419)
>         at org.wildfly.security.manager.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
>         at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_03]
>         at org.jboss.invocation.PrivilegedInterceptor.processInvocation(PrivilegedInterceptor.java:75)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
>         at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72)
>         at com.ecolane.mpk.frontend.beans.FrontendLiaisonLocal$$$view296.synchOneCustomerToFrontend(Unknown Source) [k3-main.jar:]
>         at com.ecolane.mpk.apps.beans.ToolBackendBean.synchOneCustomerToFrontend(ToolBackendBean.java:717) [k3-main.jar:]
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_03]
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_03]
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_03]
>         at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_03]
>         at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
>         at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:130) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:138) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
>         at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
>         at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:251) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:342) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>     @PersistenceContext(unitName=K3Configuration.PERSISTENCE_CONTEXT_FRONTEND_NAME)
>     private transient EntityManager entityManager;
>                 <xa-datasource jndi-name="java:/FrontendDS" pool-name="MpkDemoUsFrontendDS" enabled="true">
>                     <xa-datasource-property name="ServerName">
>                         localhost
>                     </xa-datasource-property>
>                     <xa-datasource-property name="DatabaseName">
>                         production
>                     </xa-datasource-property>
>                     <driver>mysql</driver>
>                     <security>
>                         <user-name>frontend</user-name>
>                         <password>fghfghfghfh</password>
>                     </security>
>                 </xa-datasource>
> <?xml version="1.0" encoding="UTF-8"?>
> <persistence xmlns="http://java.sun.com/xml/ns/persistence"
>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>     xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd"
>     version="2.0">
>     <persistence-unit name="k3_frontend_persistence" transaction-type="JTA">
>         <jta-data-source>@DATASOURCE_FRONTEND@</jta-data-source>
>         <shared-cache-mode>ENABLE_SELECTIVE</shared-cache-mode>
>                 <properties>
>             <property name="hibernate.dialect" value="com.ecolane.mpk.persistence.util.Mysql5BitBooleanInnoDBDialect" />
>                         <property name="jboss.entity.manager.jndi.name" value="K3FrontendEntityManager" />
>                         <property name="jboss.entity.manager.factory.jndi.name"
>                                 value="K3FrontendEntityManagerFactory" />
>             <property name="hibernate.hbm2ddl.auto" value="validate"/>
>             
>             <!-- Infinispan conf -->
>             <property name="hibernate.cache.use_second_level_cache" value="true"/>
>             <property name="hibernate.cache.use_query_cache" value="true"/>
> <!--             <property name="hibernate.cache.region.factory_class" -->
> />
>             <property name="hibernate.cache.use_query_cache" value="true"/>
> <!--             <property name="hibernate.cache.region.factory_class" -->
> <!--                 value="org.hibernate.cache.infinispan.JndiInfinispanRegionFactory"/> -->
> <!--             <property name="hibernate.cache.region.factory_class" -->
> <!--                 value="org.hibernate.cache.infinispan.InfinispanRegionFactory"/> -->
> <!--             <property name="hibernate.cache.infinispan.cfg" value="infinispan-configs.xml" />   -->
> <!--             <property name="hibernate.cache.infinispan.cachemanager" value="java:CacheManager/entity"/> -->
>             <property name="hibernate.generate_statistics" value="true" />
> <!--             <property name="hibernate.cache.use_structured_entries" value="false" /> -->
>             <!-- property name="hibernate.cache.infinispan.statistics" value="true"/-->
> <!--             <property name="hibernate.transaction.manager_lookup_class" -->
> <!--                 value="org.hibernate.transaction.JBossTransactionManagerLookup"/> -->
>                 </properties>
>         </persistence-unit>
> </persistence>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 08:45:27 2013
From: jira-events at lists.jboss.org (Jean-Frederic Clere (JIRA))
Date: Fri, 11 Oct 2013 08:45:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2288) mod_cluster advertise doesn't
 wokr without advertise-security-key
In-Reply-To: <JIRA.12502816.1381495485626@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502816.1381495485626@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502816.1381495485626.68.1381495527500@jira02.app.mwc.hst.phx2.redhat.com>

Jean-Frederic Clere created WFLY-2288:
-----------------------------------------

             Summary: mod_cluster advertise doesn't wokr without advertise-security-key
                 Key: WFLY-2288
                 URL: https://issues.jboss.org/browse/WFLY-2288
             Project: WildFly
          Issue Type: Bug
    Affects Versions: 8.0.0.Beta1
            Reporter: Jean-Frederic Clere




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 08:47:26 2013
From: jira-events at lists.jboss.org (Jean-Frederic Clere (JIRA))
Date: Fri, 11 Oct 2013 08:47:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2289) deployed webapp before
 mod_cluster httpd discovery aren't see by httpd.
In-Reply-To: <JIRA.12502817.1381495589549@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502817.1381495589549@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502817.1381495589549.85.1381495646912@jira02.app.mwc.hst.phx2.redhat.com>

Jean-Frederic Clere created WFLY-2289:
-----------------------------------------

             Summary: deployed webapp before mod_cluster httpd discovery aren't see by httpd.
                 Key: WFLY-2289
                 URL: https://issues.jboss.org/browse/WFLY-2289
             Project: WildFly
          Issue Type: Bug
            Reporter: Jean-Frederic Clere




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 08:47:26 2013
From: jira-events at lists.jboss.org (Jean-Frederic Clere (JIRA))
Date: Fri, 11 Oct 2013 08:47:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2288) mod_cluster advertise doesn't
 work without advertise-security-key
In-Reply-To: <JIRA.12502816.1381495485000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502816.1381495485000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502816.1381495485000.87.1381495646990@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jean-Frederic Clere updated WFLY-2288:
--------------------------------------

    Summary: mod_cluster advertise doesn't work without advertise-security-key  (was: mod_cluster advertise doesn't wokr without advertise-security-key)

    
> mod_cluster advertise doesn't work without advertise-security-key
> -----------------------------------------------------------------
>
>                 Key: WFLY-2288
>                 URL: https://issues.jboss.org/browse/WFLY-2288
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Jean-Frederic Clere
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 09:43:26 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 11 Oct 2013 09:43:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1088) Bean validation needs to be
 added to the validator scripts
In-Reply-To: <JIRA.12502708.1381416213000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502708.1381416213000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502708.1381416213000.215.1381499006728@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-1088.
------------------------------------

    Resolution: Done

    
> Bean validation needs to be added to the validator scripts
> ----------------------------------------------------------
>
>                 Key: JBJCA-1088
>                 URL: https://issues.jboss.org/browse/JBJCA-1088
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Validator
>    Affects Versions: 1.1.0.Final
>            Reporter: Jesper Pedersen
>            Assignee: Jeff Zhang
>             Fix For: 1.1.1.Final
>
>
> The validation-api.jar and hibernate-validator.jar files needs to be added to the validator scripts (.sh / .bat)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 09:43:26 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 11 Oct 2013 09:43:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1090) Bean validation needs to be
 added to the RAR info tool scripts
In-Reply-To: <JIRA.12502711.1381416638000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502711.1381416638000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502711.1381416638000.219.1381499006903@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-1090.
------------------------------------

    Resolution: Done

    
> Bean validation needs to be added to the RAR info tool scripts
> --------------------------------------------------------------
>
>                 Key: JBJCA-1090
>                 URL: https://issues.jboss.org/browse/JBJCA-1090
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: AS
>    Affects Versions: 1.1.0.Final
>            Reporter: Jesper Pedersen
>            Assignee: Jeff Zhang
>             Fix For: 1.1.1.Final
>
>
> The validation-api.jar and hibernate-validator.jar files needs to be added to the RAR info tool scripts (.sh / .bat)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 09:43:27 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 11 Oct 2013 09:43:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1092) Naming checks for
 AdminObject are too strict
In-Reply-To: <JIRA.12502731.1381433342000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502731.1381433342000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502731.1381433342000.224.1381499007148@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-1092.
------------------------------------

    Resolution: Done

    
> Naming checks for AdminObject are too strict
> --------------------------------------------
>
>                 Key: JBJCA-1092
>                 URL: https://issues.jboss.org/browse/JBJCA-1092
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Deployer
>    Affects Versions: 1.0.21.Final, 1.1.0.Final
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>            Priority: Critical
>             Fix For: 1.0.22.Final, 1.1.1.Final
>
>
> Plain AdminObjects that doesn't implement the standard naming contracts won't be bound in JNDI

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 09:49:26 2013
From: jira-events at lists.jboss.org (Radoslav Husar (JIRA))
Date: Fri, 11 Oct 2013 09:49:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2289) deployed webapp before
 mod_cluster httpd discovery aren't see by httpd.
In-Reply-To: <JIRA.12502817.1381495589000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502817.1381495589000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502817.1381495589000.250.1381499366766@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-2289:
---------------------------------

       Assignee: Radoslav Husar
    Component/s: Clustering


https://github.com/wildfly/wildfly/pull/5164 needs to be pulled before testing :-/
                
> deployed webapp before mod_cluster httpd discovery aren't see by httpd.
> -----------------------------------------------------------------------
>
>                 Key: WFLY-2289
>                 URL: https://issues.jboss.org/browse/WFLY-2289
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>            Reporter: Jean-Frederic Clere
>            Assignee: Radoslav Husar
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 09:49:26 2013
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Fri, 11 Oct 2013 09:49:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (AS7-4265) cli command to add/remove AS
	modules
In-Reply-To: <JIRA.12462275.1332435368000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12462275.1332435368000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12462275.1332435368000.251.1381499366818@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-4265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813438#comment-12813438 ] 

Alexey Loubyansky commented on AS7-4265:
----------------------------------------

Which version?
                
> cli command to add/remove AS modules
> ------------------------------------
>
>                 Key: AS7-4265
>                 URL: https://issues.jboss.org/browse/AS7-4265
>             Project: Application Server 7
>          Issue Type: Task
>          Components: CLI
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: 7.1.2.Final (EAP)
>
>
> I think it'd be useful to have a command to add modules to the AS which given the jars, dependencies, etc would generate the structure in the modules dir, copy the jars and generate the xml.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 09:51:26 2013
From: jira-events at lists.jboss.org (Radoslav Husar (JIRA))
Date: Fri, 11 Oct 2013 09:51:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2288) mod_cluster advertise doesn't
 work without advertise-security-key
In-Reply-To: <JIRA.12502816.1381495485000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502816.1381495485000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502816.1381495485000.258.1381499486633@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-2288:
---------------------------------

    Assignee: Radoslav Husar


In 1.3 SNAPSHOT the key checking is required if its sent by the HTTPD. So in this case both parts would need 1.3.x generation.
                
> mod_cluster advertise doesn't work without advertise-security-key
> -----------------------------------------------------------------
>
>                 Key: WFLY-2288
>                 URL: https://issues.jboss.org/browse/WFLY-2288
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Jean-Frederic Clere
>            Assignee: Radoslav Husar
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 09:51:26 2013
From: jira-events at lists.jboss.org (Radoslav Husar (JIRA))
Date: Fri, 11 Oct 2013 09:51:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2288) mod_cluster advertise doesn't
 work without advertise-security-key
In-Reply-To: <JIRA.12502816.1381495485000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502816.1381495485000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502816.1381495485000.262.1381499486849@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-2288:
---------------------------------

    Component/s: Clustering

    
> mod_cluster advertise doesn't work without advertise-security-key
> -----------------------------------------------------------------
>
>                 Key: WFLY-2288
>                 URL: https://issues.jboss.org/browse/WFLY-2288
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Jean-Frederic Clere
>            Assignee: Radoslav Husar
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 09:51:27 2013
From: jira-events at lists.jboss.org (Radoslav Husar (JIRA))
Date: Fri, 11 Oct 2013 09:51:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2289) deployed webapp before
 mod_cluster httpd discovery aren't see by httpd.
In-Reply-To: <JIRA.12502817.1381495589000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502817.1381495589000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502817.1381495589000.267.1381499487104@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-2289:
---------------------------------

    Affects Version/s: 8.0.0.Beta1

    
> deployed webapp before mod_cluster httpd discovery aren't see by httpd.
> -----------------------------------------------------------------------
>
>                 Key: WFLY-2289
>                 URL: https://issues.jboss.org/browse/WFLY-2289
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Jean-Frederic Clere
>            Assignee: Radoslav Husar
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 09:59:26 2013
From: jira-events at lists.jboss.org (Radoslav Husar (JIRA))
Date: Fri, 11 Oct 2013 09:59:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2290) SubsystemTests should produce
 some logging to help identify the problem
In-Reply-To: <JIRA.12502827.1381499881673@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502827.1381499881673@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502827.1381499881673.347.1381499966900@jira02.app.mwc.hst.phx2.redhat.com>

Radoslav Husar created WFLY-2290:
------------------------------------

             Summary: SubsystemTests should produce some logging to help identify the problem
                 Key: WFLY-2290
                 URL: https://issues.jboss.org/browse/WFLY-2290
             Project: WildFly
          Issue Type: Feature Request
          Components: Domain Management
    Affects Versions: 8.0.0.Beta1
            Reporter: Radoslav Husar
            Assignee: Kabir Khan


...as its pretty impossible from such log:

-------------------------------------------------------------------------------
Test set: org.wildfly.extension.mod_cluster.ModClusterSubsystemTestCase
-------------------------------------------------------------------------------
Tests run: 10, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 14.054 sec <<< FAILURE!
testTransformers720(org.wildfly.extension.mod_cluster.ModClusterSubsystemTestCase)  Time elapsed: 0.219 sec  <<< FAILURE!
java.lang.AssertionError
        at org.junit.Assert.fail(Assert.java:86)
        at org.junit.Assert.assertTrue(Assert.java:41)
        at org.junit.Assert.assertTrue(Assert.java:52)
        at org.jboss.as.subsystem.test.SubsystemTestDelegate$LegacyKernelServiceInitializerImpl.bootCurrentVersionWithLegacyBootOperations(SubsystemTestDelegate.java:798)
        at org.jboss.as.subsystem.test.SubsystemTestDelegate$LegacyKernelServiceInitializerImpl.install(SubsystemTestDelegate.java:721)
        at org.jboss.as.subsystem.test.SubsystemTestDelegate$LegacyKernelServiceInitializerImpl.access$700(SubsystemTestDelegate.java:627)
        at org.jboss.as.subsystem.test.SubsystemTestDelegate$KernelServicesBuilderImpl.build(SubsystemTestDelegate.java:599)
        at org.wildfly.extension.mod_cluster.ModClusterSubsystemTestCase.testTransformers_1_3_0(ModClusterSubsystemTestCase.java:115)
        at org.wildfly.extension.mod_cluster.ModClusterSubsystemTestCase.testTransformers720(ModClusterSubsystemTestCase.java:103)
        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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
        at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
        at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
        at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
        at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
        at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
        at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
        at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
        at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
        at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
        at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
        at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
        at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
        at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
        at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
        at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133)
        at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114)
        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.invokeMethodWithArray(ReflectionUtils.java:188)
        at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166)
        at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
        at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101)
        at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 09:59:27 2013
From: jira-events at lists.jboss.org (Jean-Frederic Clere (JIRA))
Date: Fri, 11 Oct 2013 09:59:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2288) mod_cluster advertise doesn't
 work without advertise-security-key
In-Reply-To: <JIRA.12502816.1381495485000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502816.1381495485000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502816.1381495485000.350.1381499967028@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813456#comment-12813456 ] 

Jean-Frederic Clere commented on WFLY-2288:
-------------------------------------------

Of course I have tried without a security key in httpd.conf
                
> mod_cluster advertise doesn't work without advertise-security-key
> -----------------------------------------------------------------
>
>                 Key: WFLY-2288
>                 URL: https://issues.jboss.org/browse/WFLY-2288
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Jean-Frederic Clere
>            Assignee: Radoslav Husar
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 10:03:26 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Fri, 11 Oct 2013 10:03:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2290) SubsystemTests should produce
 some logging to help identify the problem
In-Reply-To: <JIRA.12502827.1381499881000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502827.1381499881000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502827.1381499881000.361.1381500206767@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan resolved WFLY-2290.
------------------------------

    Resolution: Rejected


I agree wholeheartedly, I probably run into this problem more than anybody else. However, we use the real AS controller, and there is not logging functionality in there, and as far as I know there are no plans to add any.

The thing that can help is to put a breakpoint in the catch block of AbstractOperationContext.executeStep()
                
> SubsystemTests should produce some logging to help identify the problem
> -----------------------------------------------------------------------
>
>                 Key: WFLY-2290
>                 URL: https://issues.jboss.org/browse/WFLY-2290
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Radoslav Husar
>            Assignee: Kabir Khan
>
> ...as its pretty impossible from such log:
> -------------------------------------------------------------------------------
> Test set: org.wildfly.extension.mod_cluster.ModClusterSubsystemTestCase
> -------------------------------------------------------------------------------
> Tests run: 10, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 14.054 sec <<< FAILURE!
> testTransformers720(org.wildfly.extension.mod_cluster.ModClusterSubsystemTestCase)  Time elapsed: 0.219 sec  <<< FAILURE!
> java.lang.AssertionError
>         at org.junit.Assert.fail(Assert.java:86)
>         at org.junit.Assert.assertTrue(Assert.java:41)
>         at org.junit.Assert.assertTrue(Assert.java:52)
>         at org.jboss.as.subsystem.test.SubsystemTestDelegate$LegacyKernelServiceInitializerImpl.bootCurrentVersionWithLegacyBootOperations(SubsystemTestDelegate.java:798)
>         at org.jboss.as.subsystem.test.SubsystemTestDelegate$LegacyKernelServiceInitializerImpl.install(SubsystemTestDelegate.java:721)
>         at org.jboss.as.subsystem.test.SubsystemTestDelegate$LegacyKernelServiceInitializerImpl.access$700(SubsystemTestDelegate.java:627)
>         at org.jboss.as.subsystem.test.SubsystemTestDelegate$KernelServicesBuilderImpl.build(SubsystemTestDelegate.java:599)
>         at org.wildfly.extension.mod_cluster.ModClusterSubsystemTestCase.testTransformers_1_3_0(ModClusterSubsystemTestCase.java:115)
>         at org.wildfly.extension.mod_cluster.ModClusterSubsystemTestCase.testTransformers720(ModClusterSubsystemTestCase.java:103)
>         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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>         at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>         at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>         at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>         at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>         at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>         at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>         at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>         at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>         at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>         at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>         at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>         at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>         at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>         at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114)
>         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.invokeMethodWithArray(ReflectionUtils.java:188)
>         at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166)
>         at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
>         at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101)
>         at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 10:05:26 2013
From: jira-events at lists.jboss.org (Radoslav Husar (JIRA))
Date: Fri, 11 Oct 2013 10:05:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2290) SubsystemTests should produce
 some logging to help identify the problem
In-Reply-To: <JIRA.12502827.1381499881000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502827.1381499881000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502827.1381499881000.369.1381500326518@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-2290:
---------------------------------


:-(
                
> SubsystemTests should produce some logging to help identify the problem
> -----------------------------------------------------------------------
>
>                 Key: WFLY-2290
>                 URL: https://issues.jboss.org/browse/WFLY-2290
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Radoslav Husar
>            Assignee: Kabir Khan
>
> ...as its pretty impossible from such log:
> -------------------------------------------------------------------------------
> Test set: org.wildfly.extension.mod_cluster.ModClusterSubsystemTestCase
> -------------------------------------------------------------------------------
> Tests run: 10, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 14.054 sec <<< FAILURE!
> testTransformers720(org.wildfly.extension.mod_cluster.ModClusterSubsystemTestCase)  Time elapsed: 0.219 sec  <<< FAILURE!
> java.lang.AssertionError
>         at org.junit.Assert.fail(Assert.java:86)
>         at org.junit.Assert.assertTrue(Assert.java:41)
>         at org.junit.Assert.assertTrue(Assert.java:52)
>         at org.jboss.as.subsystem.test.SubsystemTestDelegate$LegacyKernelServiceInitializerImpl.bootCurrentVersionWithLegacyBootOperations(SubsystemTestDelegate.java:798)
>         at org.jboss.as.subsystem.test.SubsystemTestDelegate$LegacyKernelServiceInitializerImpl.install(SubsystemTestDelegate.java:721)
>         at org.jboss.as.subsystem.test.SubsystemTestDelegate$LegacyKernelServiceInitializerImpl.access$700(SubsystemTestDelegate.java:627)
>         at org.jboss.as.subsystem.test.SubsystemTestDelegate$KernelServicesBuilderImpl.build(SubsystemTestDelegate.java:599)
>         at org.wildfly.extension.mod_cluster.ModClusterSubsystemTestCase.testTransformers_1_3_0(ModClusterSubsystemTestCase.java:115)
>         at org.wildfly.extension.mod_cluster.ModClusterSubsystemTestCase.testTransformers720(ModClusterSubsystemTestCase.java:103)
>         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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>         at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>         at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>         at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>         at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>         at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>         at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>         at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>         at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>         at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>         at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>         at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>         at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>         at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>         at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114)
>         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.invokeMethodWithArray(ReflectionUtils.java:188)
>         at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166)
>         at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
>         at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101)
>         at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 10:08:26 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 11 Oct 2013 10:08:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2290) SubsystemTests should produce
 some logging to help identify the problem
In-Reply-To: <JIRA.12502827.1381499881000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502827.1381499881000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502827.1381499881000.375.1381500506612@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813464#comment-12813464 ] 

Brian Stansberry commented on WFLY-2290:
----------------------------------------

AbstractOperationContext.executeStep() logs appropriately. If you guys disagree with that, please let me know.

I don't object to additional debug level logging in the controller. Even higher levels if its correct for the normal use case and not just for testing.
                
> SubsystemTests should produce some logging to help identify the problem
> -----------------------------------------------------------------------
>
>                 Key: WFLY-2290
>                 URL: https://issues.jboss.org/browse/WFLY-2290
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Radoslav Husar
>            Assignee: Kabir Khan
>
> ...as its pretty impossible from such log:
> -------------------------------------------------------------------------------
> Test set: org.wildfly.extension.mod_cluster.ModClusterSubsystemTestCase
> -------------------------------------------------------------------------------
> Tests run: 10, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 14.054 sec <<< FAILURE!
> testTransformers720(org.wildfly.extension.mod_cluster.ModClusterSubsystemTestCase)  Time elapsed: 0.219 sec  <<< FAILURE!
> java.lang.AssertionError
>         at org.junit.Assert.fail(Assert.java:86)
>         at org.junit.Assert.assertTrue(Assert.java:41)
>         at org.junit.Assert.assertTrue(Assert.java:52)
>         at org.jboss.as.subsystem.test.SubsystemTestDelegate$LegacyKernelServiceInitializerImpl.bootCurrentVersionWithLegacyBootOperations(SubsystemTestDelegate.java:798)
>         at org.jboss.as.subsystem.test.SubsystemTestDelegate$LegacyKernelServiceInitializerImpl.install(SubsystemTestDelegate.java:721)
>         at org.jboss.as.subsystem.test.SubsystemTestDelegate$LegacyKernelServiceInitializerImpl.access$700(SubsystemTestDelegate.java:627)
>         at org.jboss.as.subsystem.test.SubsystemTestDelegate$KernelServicesBuilderImpl.build(SubsystemTestDelegate.java:599)
>         at org.wildfly.extension.mod_cluster.ModClusterSubsystemTestCase.testTransformers_1_3_0(ModClusterSubsystemTestCase.java:115)
>         at org.wildfly.extension.mod_cluster.ModClusterSubsystemTestCase.testTransformers720(ModClusterSubsystemTestCase.java:103)
>         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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>         at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>         at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>         at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>         at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>         at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>         at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>         at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>         at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>         at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>         at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>         at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>         at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>         at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>         at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114)
>         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.invokeMethodWithArray(ReflectionUtils.java:188)
>         at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166)
>         at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
>         at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101)
>         at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 10:19:26 2013
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 11 Oct 2013 10:19:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2276) URI ENCODING does not work in
 the beta1 version (UTF-8)
In-Reply-To: <JIRA.12502684.1381404449000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502684.1381404449000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502684.1381404449000.405.1381501166630@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813472#comment-12813472 ] 

jaikiran pai commented on WFLY-2276:
------------------------------------

WildFly 8 now ships with Undertow http://undertow.io/ web container and those properties aren't used in Undertow so have no effect. If you are having problems with encoding, please explain what the exact problems are.

                
> URI ENCODING does not work in the beta1 version (UTF-8)
> -------------------------------------------------------
>
>                 Key: WFLY-2276
>                 URL: https://issues.jboss.org/browse/WFLY-2276
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (JBoss Web)
>    Affects Versions: 8.0.0.Beta1
>         Environment: Java 7, ubuntu 12.04
>            Reporter: alexandre xypas
>              Labels: encoding, utf-8
>
> In standalone.xml, the following is working in Alpha4, but not anymore in Beta1.
> <property name="org.apache.catalina.connector.URI_ENCODING" value="UTF-8"/>
> <property name="org.apache.catalina.connector.USE_BODY_ENCODING_FOR_QUERY_STRING" value="true"/>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 10:23:26 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Fri, 11 Oct 2013 10:23:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2290) SubsystemTests should produce
 some logging to help identify the problem
In-Reply-To: <JIRA.12502827.1381499881000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502827.1381499881000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502827.1381499881000.422.1381501406996@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813477#comment-12813477 ] 

Kabir Khan commented on WFLY-2290:
----------------------------------

The nice thing to have for the testing would be the stacktrace in the catch block in AbstractOperationContext.executeStep() so you know which boot operation failed.
For the transformers tests, I don't think we can do much about legacy controllers <= 7.2.0 short of forking the controller module for previous releases and re-releasing under a different name e.g. jboss.as:jboss-as-controller:7.1.2.Final would add it on jboss.as:jboss-as-controller:7.1.2.Final-subsystem-test
                
> SubsystemTests should produce some logging to help identify the problem
> -----------------------------------------------------------------------
>
>                 Key: WFLY-2290
>                 URL: https://issues.jboss.org/browse/WFLY-2290
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Radoslav Husar
>            Assignee: Kabir Khan
>
> ...as its pretty impossible from such log:
> -------------------------------------------------------------------------------
> Test set: org.wildfly.extension.mod_cluster.ModClusterSubsystemTestCase
> -------------------------------------------------------------------------------
> Tests run: 10, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 14.054 sec <<< FAILURE!
> testTransformers720(org.wildfly.extension.mod_cluster.ModClusterSubsystemTestCase)  Time elapsed: 0.219 sec  <<< FAILURE!
> java.lang.AssertionError
>         at org.junit.Assert.fail(Assert.java:86)
>         at org.junit.Assert.assertTrue(Assert.java:41)
>         at org.junit.Assert.assertTrue(Assert.java:52)
>         at org.jboss.as.subsystem.test.SubsystemTestDelegate$LegacyKernelServiceInitializerImpl.bootCurrentVersionWithLegacyBootOperations(SubsystemTestDelegate.java:798)
>         at org.jboss.as.subsystem.test.SubsystemTestDelegate$LegacyKernelServiceInitializerImpl.install(SubsystemTestDelegate.java:721)
>         at org.jboss.as.subsystem.test.SubsystemTestDelegate$LegacyKernelServiceInitializerImpl.access$700(SubsystemTestDelegate.java:627)
>         at org.jboss.as.subsystem.test.SubsystemTestDelegate$KernelServicesBuilderImpl.build(SubsystemTestDelegate.java:599)
>         at org.wildfly.extension.mod_cluster.ModClusterSubsystemTestCase.testTransformers_1_3_0(ModClusterSubsystemTestCase.java:115)
>         at org.wildfly.extension.mod_cluster.ModClusterSubsystemTestCase.testTransformers720(ModClusterSubsystemTestCase.java:103)
>         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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>         at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>         at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>         at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>         at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>         at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>         at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>         at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>         at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>         at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>         at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>         at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>         at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>         at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>         at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114)
>         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.invokeMethodWithArray(ReflectionUtils.java:188)
>         at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166)
>         at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
>         at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101)
>         at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 10:45:27 2013
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Fri, 11 Oct 2013 10:45:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2291) Bump messaging XML namespace
	to 2.0
In-Reply-To: <JIRA.12502832.1381502689681@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502832.1381502689681@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502832.1381502689681.473.1381502727464@jira02.app.mwc.hst.phx2.redhat.com>

Jeff Mesnil created WFLY-2291:
---------------------------------

             Summary: Bump messaging XML namespace to 2.0
                 Key: WFLY-2291
                 URL: https://issues.jboss.org/browse/WFLY-2291
             Project: WildFly
          Issue Type: Bug
          Components: JMS
    Affects Versions: 8.0.0.Beta1
            Reporter: Jeff Mesnil
            Assignee: Jeff Mesnil
            Priority: Critical
             Fix For: 8.0.0.CR1


The XML namespace for the messaging subsystem was erroneously bumped from 1.3 to 1.4 for WildFly 8.

This is an error as the 1.x version must be reserved for AS7 7.x releases.
WildFly 8 will use a 2.0 namespace. 

This means that configurations written against WildFly 8.0.0 Alpha and Beta will break once the XML namespace is corrected to 2.0.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 10:53:26 2013
From: jira-events at lists.jboss.org (Pete Muir (JIRA))
Date: Fri, 11 Oct 2013 10:53:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2292) Add config option to fail
 deployment if private API is used
In-Reply-To: <JIRA.12502834.1381503135473@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502834.1381503135473@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502834.1381503135473.482.1381503206468@jira02.app.mwc.hst.phx2.redhat.com>

Pete Muir created WFLY-2292:
-------------------------------

             Summary: Add config option to fail deployment if private API is used
                 Key: WFLY-2292
                 URL: https://issues.jboss.org/browse/WFLY-2292
             Project: WildFly
          Issue Type: Feature Request
            Reporter: Pete Muir


This would allow users to have continuous integration jobs check if their app uses a private API by mistake, and have the job fail if it does.

Needed to automate the check that quickstarts only use public API.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 10:55:26 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 11 Oct 2013 10:55:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2292) Add config option to fail
 deployment if private API is used
In-Reply-To: <JIRA.12502834.1381503135000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502834.1381503135000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502834.1381503135000.488.1381503326868@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2292:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1018260

    
> Add config option to fail deployment if private API is used
> -----------------------------------------------------------
>
>                 Key: WFLY-2292
>                 URL: https://issues.jboss.org/browse/WFLY-2292
>             Project: WildFly
>          Issue Type: Feature Request
>            Reporter: Pete Muir
>
> This would allow users to have continuous integration jobs check if their app uses a private API by mistake, and have the job fail if it does.
> Needed to automate the check that quickstarts only use public API.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 10:55:27 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 11 Oct 2013 10:55:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2292) Add config option to fail
 deployment if private API is used
In-Reply-To: <JIRA.12502834.1381503135000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502834.1381503135000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502834.1381503135000.491.1381503326997@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813496#comment-12813496 ] 

RH Bugzilla Integration commented on WFLY-2292:
-----------------------------------------------

Pete Muir <pmuir at redhat.com> made a comment on [bug 1018260|https://bugzilla.redhat.com/show_bug.cgi?id=1018260]

Upstream issue is https://issues.jboss.org/browse/WFLY-2292
                
> Add config option to fail deployment if private API is used
> -----------------------------------------------------------
>
>                 Key: WFLY-2292
>                 URL: https://issues.jboss.org/browse/WFLY-2292
>             Project: WildFly
>          Issue Type: Feature Request
>            Reporter: Pete Muir
>
> This would allow users to have continuous integration jobs check if their app uses a private API by mistake, and have the job fail if it does.
> Needed to automate the check that quickstarts only use public API.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 10:55:27 2013
From: jira-events at lists.jboss.org (Radoslav Husar (JIRA))
Date: Fri, 11 Oct 2013 10:55:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2290) SubsystemTests should produce
 some logging to help identify the problem
In-Reply-To: <JIRA.12502827.1381499881000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502827.1381499881000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502827.1381499881000.494.1381503327207@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813497#comment-12813497 ] 

Radoslav Husar commented on WFLY-2290:
--------------------------------------

One suggestion I have for adding additional debug logging is to log in 'assert' statement and in the test harness start the process with -ea. This was the runtime gets unaffected -- if that's the problem with introduction of new logging statements.

Spoofing and re-releasing legacy controllers would be useful too.
                
> SubsystemTests should produce some logging to help identify the problem
> -----------------------------------------------------------------------
>
>                 Key: WFLY-2290
>                 URL: https://issues.jboss.org/browse/WFLY-2290
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Radoslav Husar
>            Assignee: Kabir Khan
>
> ...as its pretty impossible from such log:
> -------------------------------------------------------------------------------
> Test set: org.wildfly.extension.mod_cluster.ModClusterSubsystemTestCase
> -------------------------------------------------------------------------------
> Tests run: 10, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 14.054 sec <<< FAILURE!
> testTransformers720(org.wildfly.extension.mod_cluster.ModClusterSubsystemTestCase)  Time elapsed: 0.219 sec  <<< FAILURE!
> java.lang.AssertionError
>         at org.junit.Assert.fail(Assert.java:86)
>         at org.junit.Assert.assertTrue(Assert.java:41)
>         at org.junit.Assert.assertTrue(Assert.java:52)
>         at org.jboss.as.subsystem.test.SubsystemTestDelegate$LegacyKernelServiceInitializerImpl.bootCurrentVersionWithLegacyBootOperations(SubsystemTestDelegate.java:798)
>         at org.jboss.as.subsystem.test.SubsystemTestDelegate$LegacyKernelServiceInitializerImpl.install(SubsystemTestDelegate.java:721)
>         at org.jboss.as.subsystem.test.SubsystemTestDelegate$LegacyKernelServiceInitializerImpl.access$700(SubsystemTestDelegate.java:627)
>         at org.jboss.as.subsystem.test.SubsystemTestDelegate$KernelServicesBuilderImpl.build(SubsystemTestDelegate.java:599)
>         at org.wildfly.extension.mod_cluster.ModClusterSubsystemTestCase.testTransformers_1_3_0(ModClusterSubsystemTestCase.java:115)
>         at org.wildfly.extension.mod_cluster.ModClusterSubsystemTestCase.testTransformers720(ModClusterSubsystemTestCase.java:103)
>         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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>         at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>         at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>         at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>         at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>         at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>         at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>         at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>         at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>         at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>         at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>         at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>         at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>         at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>         at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114)
>         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.invokeMethodWithArray(ReflectionUtils.java:188)
>         at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166)
>         at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
>         at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101)
>         at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 11:00:27 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 11 Oct 2013 11:00:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2290) SubsystemTests should produce
 some logging to help identify the problem
In-Reply-To: <JIRA.12502827.1381499881000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502827.1381499881000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502827.1381499881000.506.1381503627249@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813499#comment-12813499 ] 

Brian Stansberry commented on WFLY-2290:
----------------------------------------

-1 to using assert statements as a logging API.
                
> SubsystemTests should produce some logging to help identify the problem
> -----------------------------------------------------------------------
>
>                 Key: WFLY-2290
>                 URL: https://issues.jboss.org/browse/WFLY-2290
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Radoslav Husar
>            Assignee: Kabir Khan
>
> ...as its pretty impossible from such log:
> -------------------------------------------------------------------------------
> Test set: org.wildfly.extension.mod_cluster.ModClusterSubsystemTestCase
> -------------------------------------------------------------------------------
> Tests run: 10, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 14.054 sec <<< FAILURE!
> testTransformers720(org.wildfly.extension.mod_cluster.ModClusterSubsystemTestCase)  Time elapsed: 0.219 sec  <<< FAILURE!
> java.lang.AssertionError
>         at org.junit.Assert.fail(Assert.java:86)
>         at org.junit.Assert.assertTrue(Assert.java:41)
>         at org.junit.Assert.assertTrue(Assert.java:52)
>         at org.jboss.as.subsystem.test.SubsystemTestDelegate$LegacyKernelServiceInitializerImpl.bootCurrentVersionWithLegacyBootOperations(SubsystemTestDelegate.java:798)
>         at org.jboss.as.subsystem.test.SubsystemTestDelegate$LegacyKernelServiceInitializerImpl.install(SubsystemTestDelegate.java:721)
>         at org.jboss.as.subsystem.test.SubsystemTestDelegate$LegacyKernelServiceInitializerImpl.access$700(SubsystemTestDelegate.java:627)
>         at org.jboss.as.subsystem.test.SubsystemTestDelegate$KernelServicesBuilderImpl.build(SubsystemTestDelegate.java:599)
>         at org.wildfly.extension.mod_cluster.ModClusterSubsystemTestCase.testTransformers_1_3_0(ModClusterSubsystemTestCase.java:115)
>         at org.wildfly.extension.mod_cluster.ModClusterSubsystemTestCase.testTransformers720(ModClusterSubsystemTestCase.java:103)
>         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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>         at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>         at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>         at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>         at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>         at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>         at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>         at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>         at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>         at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>         at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>         at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>         at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>         at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>         at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114)
>         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.invokeMethodWithArray(ReflectionUtils.java:188)
>         at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166)
>         at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
>         at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101)
>         at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 11:17:26 2013
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Fri, 11 Oct 2013 11:17:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-297) The release procedure should
 validate there are no snapshot dependencies with the enforcer plugin
In-Reply-To: <JIRA.12502838.1381504617082@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502838.1381504617082@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502838.1381504617082.543.1381504646633@jira02.app.mwc.hst.phx2.redhat.com>

Geoffrey De Smet created DROOLS-297:
---------------------------------------

             Summary: The release procedure should validate there are no snapshot dependencies with the enforcer plugin
                 Key: DROOLS-297
                 URL: https://issues.jboss.org/browse/DROOLS-297
             Project: Drools
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Geoffrey De Smet
            Assignee: Michael Biarnes Kiefer


Apparently, we've been releasing jars which have snapshot dependencies (non-timestamped). For example drools-wb-jcr2vfs-migration-core 6.0.0.CR4 depends on 5.5.1-SNAPSHOT. Why Nexus's validation no longer prevents this is beyond me.

Anyway, we need to prevent this. Luckily the enforcer plugin has a rule to validate this:
http://maven.apache.org/enforcer/enforcer-rules/requireReleaseVersion.html
During normal development this rule shouldn't be active, as jbpm depends on a drools snapshot etc.
But during a release procedure, it must be executed once. For example, after changing the version and before deploying them. Or as part of the actual deploy build - whatever works best.

One way would be to put it in the release profile "jboss-release", similar to what the jboss-parent pom does (which we extend):
  https://github.com/jboss/jboss-parent-pom/blob/master/pom.xml#L700
But I strongly dislike the use of profiles... 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 11:23:26 2013
From: jira-events at lists.jboss.org (Pedro Igor (JIRA))
Date: Fri, 11 Oct 2013 11:23:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2293) Security subsystem is not
 considering the"module attribute for JASPI auth-module elements
In-Reply-To: <JIRA.12502840.1381504933870@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502840.1381504933870@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502840.1381504933870.553.1381505006634@jira02.app.mwc.hst.phx2.redhat.com>

Pedro Igor created WFLY-2293:
--------------------------------

             Summary: Security subsystem is not considering the"module attribute for JASPI auth-module elements
                 Key: WFLY-2293
                 URL: https://issues.jboss.org/browse/WFLY-2293
             Project: WildFly
          Issue Type: Bug
            Reporter: Pedro Igor




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 11:23:26 2013
From: jira-events at lists.jboss.org (Pedro Igor (JIRA))
Date: Fri, 11 Oct 2013 11:23:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2293) Security subsystem is not
 considering the "module" attribute for JASPI "auth-module" elements
In-Reply-To: <JIRA.12502840.1381504933000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502840.1381504933000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502840.1381504933000.556.1381505006806@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pedro Igor updated WFLY-2293:
-----------------------------

              Summary: Security subsystem is not considering the "module" attribute for JASPI "auth-module" elements  (was: Security subsystem is not considering the"module attribute for JASPI auth-module elements)
    Affects Version/s: 8.0.0.Beta1
          Component/s: Security

    
> Security subsystem is not considering the "module" attribute for JASPI "auth-module" elements
> ---------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2293
>                 URL: https://issues.jboss.org/browse/WFLY-2293
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Pedro Igor
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 11:25:26 2013
From: jira-events at lists.jboss.org (Matti Linnanvuori (JIRA))
Date: Fri, 11 Oct 2013 11:25:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2280) Wrong XA Datasource selected
In-Reply-To: <JIRA.12502716.1381418849000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502716.1381418849000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502716.1381418849000.563.1381505126712@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813508#comment-12813508 ] 

Matti Linnanvuori commented on WFLY-2280:
-----------------------------------------

I determined that WildFly is doing something wrong. FrontendLiaisonBean has
@PersistenceContext(unitName=K3Configuration.PERSISTENCE_CONTEXT_FRONTEND_NAME)
    private transient EntityManager entityManager;

WildFly correctly noted that FrontendLiaisonBean refers to k3_frontend_persistence.
ESC[0mESC[32m2013-10-11 10:17:14,628 DEBUG [org.jboss.as.jpa.messages] (MSC service thread 1-4:) persistence unit search for unitName=k3_frontend_persistence referenced from class=com.ecolane.mpk.frontend.beans.FrontendLiaisonBean (annotation=@javax.persistence.PersistenceContext(unitName = "k3_frontend_persistence") on javax.persistence.EntityManager com.ecolane.mpk.frontend.beans.FrontendLiaisonBean.entityManager)

But when the bean tries to get a result of a named query by calling that entityManager, it fails. 
            service = entityManager.createNamedQuery("findFeServiceByHostname", FeService.class)
                    .setParameter("hostname", serviceHostname)
                    .getSingleResult();

I do have multiple persistence.xml files but WildFly should follow the unitName and make it work.

Named queries work for other persistence units.

This a regression from JBoss AS 7.
                
> Wrong XA Datasource selected
> ----------------------------
>
>                 Key: WFLY-2280
>                 URL: https://issues.jboss.org/browse/WFLY-2280
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>         Environment: Wildfly 8, Debian Linux
>            Reporter: Matti Linnanvuori
>            Assignee: Scott Marlow
>
> A wrong XA datasource OperationalDS instead of specified FrontendDS is chosen for a database query.
> ESC[0mESC[33m10:53:47,089 WARN  [com.arjuna.ats.jta] (default task-24) ARJUNA016089: TransactionImple.enlistResource - xa_start  - caught: XAException.XAER_INVAL for < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff90cae62c:4e8567e5:5256b6f0:2894, node_name=1, branch_uid=0:ffff90cae62c:4e8567e5:5256b6f0:2899, subordinatenodename=null, eis_name=java:/OperationalDS >: com.mysql.jdbc.jdbc2.optional.MysqlXAException: XAER_INVAL: Invalid arguments (or unsupported command)
>         at com.mysql.jdbc.jdbc2.optional.MysqlXAConnection.mapXAExceptionFromSQLException(MysqlXAConnection.java:600) [mysql-connector-java-5.1.26-bin.jar:]
>         at com.mysql.jdbc.jdbc2.optional.MysqlXAConnection.dispatchCommand(MysqlXAConnection.java:583) [mysql-connector-java-5.1.26-bin.jar:]
>         at com.mysql.jdbc.jdbc2.optional.MysqlXAConnection.start(MysqlXAConnection.java:523) [mysql-connector-java-5.1.26-bin.jar:]
>         at org.jboss.jca.adapters.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:259)
>         at org.jboss.jca.core.tx.jbossts.XAResourceWrapperImpl.start(XAResourceWrapperImpl.java:191)
>         at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:715) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
>         at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:397) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
>         at org.jboss.jca.core.connectionmanager.listener.TxConnectionListener$TransactionSynchronization.enlist(TxConnectionListener.java:607)
>         at org.jboss.jca.core.connectionmanager.listener.TxConnectionListener.enlist(TxConnectionListener.java:265)
>         at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.managedConnectionReconnected(TxConnectionManagerImpl.java:467)
>         at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.reconnectManagedConnection(AbstractConnectionManager.java:599)
>         at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:467)
>         at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:139)
>         at org.hibernate.engine.jdbc.connections.internal.DatasourceConnectionProviderImpl.getConnection(DatasourceConnectionProviderImpl.java:138) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.internal.AbstractSessionImpl$NonContextualJdbcConnectionAccess.obtainConnection(AbstractSessionImpl.java:359) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.LogicalConnectionImpl.obtainConnection(LogicalConnectionImpl.java:227) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.LogicalConnectionImpl.getConnection(LogicalConnectionImpl.java:170) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.StatementPreparerImpl.connection(StatementPreparerImpl.java:63) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.StatementPreparerImpl$5.doPrepare(StatementPreparerImpl.java:164) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.StatementPreparerImpl$StatementPreparationTemplate.prepareStatement(StatementPreparerImpl.java:185) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.StatementPreparerImpl.prepareQueryStatement(StatementPreparerImpl.java:162) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1859) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1836) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1813) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.doQuery(Loader.java:895) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:340) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.doList(Loader.java:2523) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.doList(Loader.java:2509) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2339) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.list(Loader.java:2334) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:491) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:369) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:222) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1270) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.internal.QueryImpl.list(QueryImpl.java:101) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.jpa.internal.QueryImpl.getSingleResult(QueryImpl.java:381) [hibernate-entitymanager-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at com.ecolane.mpk.frontend.beans.FrontendLiaisonBean.getOurFeService(FrontendLiaisonBean.java:123) [k3-main.jar:]
>         at com.ecolane.mpk.frontend.beans.FrontendLiaisonBean.synchOneCustomerToFrontend(FrontendLiaisonBean.java:362) [k3-main.jar:]
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_03]
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_03]
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_03]
>         at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_03]
>         at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
>         at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:130) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:138) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
>         at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
>         at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:251) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:342) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:90) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:55)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
>         at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:419)
>         at org.wildfly.security.manager.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
>         at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_03]
>         at org.jboss.invocation.PrivilegedInterceptor.processInvocation(PrivilegedInterceptor.java:75)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
>         at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72)
>         at com.ecolane.mpk.frontend.beans.FrontendLiaisonLocal$$$view296.synchOneCustomerToFrontend(Unknown Source) [k3-main.jar:]
>         at com.ecolane.mpk.apps.beans.ToolBackendBean.synchOneCustomerToFrontend(ToolBackendBean.java:717) [k3-main.jar:]
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_03]
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_03]
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_03]
>         at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_03]
>         at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
>         at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:130) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:138) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
>         at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
>         at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:251) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:342) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>     @PersistenceContext(unitName=K3Configuration.PERSISTENCE_CONTEXT_FRONTEND_NAME)
>     private transient EntityManager entityManager;
>                 <xa-datasource jndi-name="java:/FrontendDS" pool-name="MpkDemoUsFrontendDS" enabled="true">
>                     <xa-datasource-property name="ServerName">
>                         localhost
>                     </xa-datasource-property>
>                     <xa-datasource-property name="DatabaseName">
>                         production
>                     </xa-datasource-property>
>                     <driver>mysql</driver>
>                     <security>
>                         <user-name>frontend</user-name>
>                         <password>fghfghfghfh</password>
>                     </security>
>                 </xa-datasource>
> <?xml version="1.0" encoding="UTF-8"?>
> <persistence xmlns="http://java.sun.com/xml/ns/persistence"
>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>     xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd"
>     version="2.0">
>     <persistence-unit name="k3_frontend_persistence" transaction-type="JTA">
>         <jta-data-source>@DATASOURCE_FRONTEND@</jta-data-source>
>         <shared-cache-mode>ENABLE_SELECTIVE</shared-cache-mode>
>                 <properties>
>             <property name="hibernate.dialect" value="com.ecolane.mpk.persistence.util.Mysql5BitBooleanInnoDBDialect" />
>                         <property name="jboss.entity.manager.jndi.name" value="K3FrontendEntityManager" />
>                         <property name="jboss.entity.manager.factory.jndi.name"
>                                 value="K3FrontendEntityManagerFactory" />
>             <property name="hibernate.hbm2ddl.auto" value="validate"/>
>             
>             <!-- Infinispan conf -->
>             <property name="hibernate.cache.use_second_level_cache" value="true"/>
>             <property name="hibernate.cache.use_query_cache" value="true"/>
> <!--             <property name="hibernate.cache.region.factory_class" -->
> />
>             <property name="hibernate.cache.use_query_cache" value="true"/>
> <!--             <property name="hibernate.cache.region.factory_class" -->
> <!--                 value="org.hibernate.cache.infinispan.JndiInfinispanRegionFactory"/> -->
> <!--             <property name="hibernate.cache.region.factory_class" -->
> <!--                 value="org.hibernate.cache.infinispan.InfinispanRegionFactory"/> -->
> <!--             <property name="hibernate.cache.infinispan.cfg" value="infinispan-configs.xml" />   -->
> <!--             <property name="hibernate.cache.infinispan.cachemanager" value="java:CacheManager/entity"/> -->
>             <property name="hibernate.generate_statistics" value="true" />
> <!--             <property name="hibernate.cache.use_structured_entries" value="false" /> -->
>             <!-- property name="hibernate.cache.infinispan.statistics" value="true"/-->
> <!--             <property name="hibernate.transaction.manager_lookup_class" -->
> <!--                 value="org.hibernate.transaction.JBossTransactionManagerLookup"/> -->
>                 </properties>
>         </persistence-unit>
> </persistence>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 11:25:26 2013
From: jira-events at lists.jboss.org (Pedro Igor (JIRA))
Date: Fri, 11 Oct 2013 11:25:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2293) Security subsystem is not
 considering the "module" attribute for JASPI "auth-module" elements
In-Reply-To: <JIRA.12502840.1381504933000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502840.1381504933000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502840.1381504933000.564.1381505126788@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pedro Igor updated WFLY-2293:
-----------------------------

    Description: This issue impacts users from using their own ServerAuthModule implementations from other modules.

    
> Security subsystem is not considering the "module" attribute for JASPI "auth-module" elements
> ---------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2293
>                 URL: https://issues.jboss.org/browse/WFLY-2293
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Pedro Igor
>
> This issue impacts users from using their own ServerAuthModule implementations from other modules.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 11:48:26 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Fri, 11 Oct 2013 11:48:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2280) Wrong XA Datasource selected
In-Reply-To: <JIRA.12502716.1381418849000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502716.1381418849000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502716.1381418849000.616.1381506506737@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813518#comment-12813518 ] 

Scott Marlow commented on WFLY-2280:
------------------------------------

Can you create a forum post on https://community.jboss.org/en/wildfly?  That is a better place to first discuss whether you have discovered a bug in WildFly, before creating the bug report (so that others will see the discussion and also benefit from it).  I don't yet have a full understanding of the problem and don't want to ask you further questions in this jira, when we should have that discussion in the forums first.  If there is a bug that needs to be fixed in WildFly, we can then reopen this jira.  

                
> Wrong XA Datasource selected
> ----------------------------
>
>                 Key: WFLY-2280
>                 URL: https://issues.jboss.org/browse/WFLY-2280
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>         Environment: Wildfly 8, Debian Linux
>            Reporter: Matti Linnanvuori
>            Assignee: Scott Marlow
>
> A wrong XA datasource OperationalDS instead of specified FrontendDS is chosen for a database query.
> ESC[0mESC[33m10:53:47,089 WARN  [com.arjuna.ats.jta] (default task-24) ARJUNA016089: TransactionImple.enlistResource - xa_start  - caught: XAException.XAER_INVAL for < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff90cae62c:4e8567e5:5256b6f0:2894, node_name=1, branch_uid=0:ffff90cae62c:4e8567e5:5256b6f0:2899, subordinatenodename=null, eis_name=java:/OperationalDS >: com.mysql.jdbc.jdbc2.optional.MysqlXAException: XAER_INVAL: Invalid arguments (or unsupported command)
>         at com.mysql.jdbc.jdbc2.optional.MysqlXAConnection.mapXAExceptionFromSQLException(MysqlXAConnection.java:600) [mysql-connector-java-5.1.26-bin.jar:]
>         at com.mysql.jdbc.jdbc2.optional.MysqlXAConnection.dispatchCommand(MysqlXAConnection.java:583) [mysql-connector-java-5.1.26-bin.jar:]
>         at com.mysql.jdbc.jdbc2.optional.MysqlXAConnection.start(MysqlXAConnection.java:523) [mysql-connector-java-5.1.26-bin.jar:]
>         at org.jboss.jca.adapters.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:259)
>         at org.jboss.jca.core.tx.jbossts.XAResourceWrapperImpl.start(XAResourceWrapperImpl.java:191)
>         at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:715) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
>         at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:397) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
>         at org.jboss.jca.core.connectionmanager.listener.TxConnectionListener$TransactionSynchronization.enlist(TxConnectionListener.java:607)
>         at org.jboss.jca.core.connectionmanager.listener.TxConnectionListener.enlist(TxConnectionListener.java:265)
>         at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.managedConnectionReconnected(TxConnectionManagerImpl.java:467)
>         at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.reconnectManagedConnection(AbstractConnectionManager.java:599)
>         at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:467)
>         at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:139)
>         at org.hibernate.engine.jdbc.connections.internal.DatasourceConnectionProviderImpl.getConnection(DatasourceConnectionProviderImpl.java:138) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.internal.AbstractSessionImpl$NonContextualJdbcConnectionAccess.obtainConnection(AbstractSessionImpl.java:359) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.LogicalConnectionImpl.obtainConnection(LogicalConnectionImpl.java:227) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.LogicalConnectionImpl.getConnection(LogicalConnectionImpl.java:170) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.StatementPreparerImpl.connection(StatementPreparerImpl.java:63) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.StatementPreparerImpl$5.doPrepare(StatementPreparerImpl.java:164) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.StatementPreparerImpl$StatementPreparationTemplate.prepareStatement(StatementPreparerImpl.java:185) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.StatementPreparerImpl.prepareQueryStatement(StatementPreparerImpl.java:162) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1859) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1836) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1813) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.doQuery(Loader.java:895) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:340) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.doList(Loader.java:2523) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.doList(Loader.java:2509) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2339) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.list(Loader.java:2334) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:491) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:369) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:222) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1270) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.internal.QueryImpl.list(QueryImpl.java:101) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.jpa.internal.QueryImpl.getSingleResult(QueryImpl.java:381) [hibernate-entitymanager-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at com.ecolane.mpk.frontend.beans.FrontendLiaisonBean.getOurFeService(FrontendLiaisonBean.java:123) [k3-main.jar:]
>         at com.ecolane.mpk.frontend.beans.FrontendLiaisonBean.synchOneCustomerToFrontend(FrontendLiaisonBean.java:362) [k3-main.jar:]
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_03]
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_03]
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_03]
>         at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_03]
>         at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
>         at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:130) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:138) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
>         at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
>         at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:251) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:342) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:90) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:55)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
>         at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:419)
>         at org.wildfly.security.manager.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
>         at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_03]
>         at org.jboss.invocation.PrivilegedInterceptor.processInvocation(PrivilegedInterceptor.java:75)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
>         at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72)
>         at com.ecolane.mpk.frontend.beans.FrontendLiaisonLocal$$$view296.synchOneCustomerToFrontend(Unknown Source) [k3-main.jar:]
>         at com.ecolane.mpk.apps.beans.ToolBackendBean.synchOneCustomerToFrontend(ToolBackendBean.java:717) [k3-main.jar:]
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_03]
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_03]
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_03]
>         at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_03]
>         at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
>         at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:130) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:138) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
>         at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
>         at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:251) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:342) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>     @PersistenceContext(unitName=K3Configuration.PERSISTENCE_CONTEXT_FRONTEND_NAME)
>     private transient EntityManager entityManager;
>                 <xa-datasource jndi-name="java:/FrontendDS" pool-name="MpkDemoUsFrontendDS" enabled="true">
>                     <xa-datasource-property name="ServerName">
>                         localhost
>                     </xa-datasource-property>
>                     <xa-datasource-property name="DatabaseName">
>                         production
>                     </xa-datasource-property>
>                     <driver>mysql</driver>
>                     <security>
>                         <user-name>frontend</user-name>
>                         <password>fghfghfghfh</password>
>                     </security>
>                 </xa-datasource>
> <?xml version="1.0" encoding="UTF-8"?>
> <persistence xmlns="http://java.sun.com/xml/ns/persistence"
>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>     xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd"
>     version="2.0">
>     <persistence-unit name="k3_frontend_persistence" transaction-type="JTA">
>         <jta-data-source>@DATASOURCE_FRONTEND@</jta-data-source>
>         <shared-cache-mode>ENABLE_SELECTIVE</shared-cache-mode>
>                 <properties>
>             <property name="hibernate.dialect" value="com.ecolane.mpk.persistence.util.Mysql5BitBooleanInnoDBDialect" />
>                         <property name="jboss.entity.manager.jndi.name" value="K3FrontendEntityManager" />
>                         <property name="jboss.entity.manager.factory.jndi.name"
>                                 value="K3FrontendEntityManagerFactory" />
>             <property name="hibernate.hbm2ddl.auto" value="validate"/>
>             
>             <!-- Infinispan conf -->
>             <property name="hibernate.cache.use_second_level_cache" value="true"/>
>             <property name="hibernate.cache.use_query_cache" value="true"/>
> <!--             <property name="hibernate.cache.region.factory_class" -->
> />
>             <property name="hibernate.cache.use_query_cache" value="true"/>
> <!--             <property name="hibernate.cache.region.factory_class" -->
> <!--                 value="org.hibernate.cache.infinispan.JndiInfinispanRegionFactory"/> -->
> <!--             <property name="hibernate.cache.region.factory_class" -->
> <!--                 value="org.hibernate.cache.infinispan.InfinispanRegionFactory"/> -->
> <!--             <property name="hibernate.cache.infinispan.cfg" value="infinispan-configs.xml" />   -->
> <!--             <property name="hibernate.cache.infinispan.cachemanager" value="java:CacheManager/entity"/> -->
>             <property name="hibernate.generate_statistics" value="true" />
> <!--             <property name="hibernate.cache.use_structured_entries" value="false" /> -->
>             <!-- property name="hibernate.cache.infinispan.statistics" value="true"/-->
> <!--             <property name="hibernate.transaction.manager_lookup_class" -->
> <!--                 value="org.hibernate.transaction.JBossTransactionManagerLookup"/> -->
>                 </properties>
>         </persistence-unit>
> </persistence>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 11:56:27 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 11 Oct 2013 11:56:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-295) Phreak mode does not
 evaluate 'from collect' correctly.
In-Reply-To: <JIRA.12502695.1381411324000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502695.1381411324000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502695.1381411324000.671.1381506987075@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813525#comment-12813525 ] 

RH Bugzilla Integration commented on DROOLS-295:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> made a comment on [bug 1018296|https://bugzilla.redhat.com/show_bug.cgi?id=1018296]

Reproducer project at: https://github.com/DuncanDoyle/Drools6PhreakFromCollectIssue

Run 'mvn clean test'. There are 2 tests which execute exactly the same thing against the same ruleset, one in ReteOO mode and one in Phreak. The result of the Phreak test is incorrect. There seems to be an issue with the 'from collect' in Phreak mode.
                
> Phreak mode does not evaluate 'from collect' correctly.
> -------------------------------------------------------
>
>                 Key: DROOLS-295
>                 URL: https://issues.jboss.org/browse/DROOLS-295
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>         Environment: Mac OS-X 10.8.5, Oracle Hotspot 1.7.0_40, Drools 6.1.0-SNAPSHOT
>            Reporter: Duncan Doyle
>            Assignee: Mark Proctor
>
> Reproducer project at: https://github.com/DuncanDoyle/Drools6PhreakFromCollectIssue
> Run 'mvn clean test'. There are 2 tests which execute exactly the same thing against the same ruleset, one in ReteOO mode and one in Phreak. The result of the Phreak test is incorrect. There seems to be an issue with the 'from collect' in Phreak mode.
> Please note that I'm using Drools 6.0.0-SNAPSHOT, as 6.0.0.Cr4-Pre1 contains a bug which causes the 'from collect' to go into an infinite loop. See Drools-276
>  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 11:56:27 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 11 Oct 2013 11:56:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-295) Phreak mode does not
 evaluate 'from collect' correctly.
In-Reply-To: <JIRA.12502695.1381411324000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502695.1381411324000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502695.1381411324000.674.1381506987210@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated DROOLS-295:
-------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1018296

    
> Phreak mode does not evaluate 'from collect' correctly.
> -------------------------------------------------------
>
>                 Key: DROOLS-295
>                 URL: https://issues.jboss.org/browse/DROOLS-295
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>         Environment: Mac OS-X 10.8.5, Oracle Hotspot 1.7.0_40, Drools 6.1.0-SNAPSHOT
>            Reporter: Duncan Doyle
>            Assignee: Mark Proctor
>
> Reproducer project at: https://github.com/DuncanDoyle/Drools6PhreakFromCollectIssue
> Run 'mvn clean test'. There are 2 tests which execute exactly the same thing against the same ruleset, one in ReteOO mode and one in Phreak. The result of the Phreak test is incorrect. There seems to be an issue with the 'from collect' in Phreak mode.
> Please note that I'm using Drools 6.0.0-SNAPSHOT, as 6.0.0.Cr4-Pre1 contains a bug which causes the 'from collect' to go into an infinite loop. See Drools-276
>  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 12:04:26 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 11 Oct 2013 12:04:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-295) Phreak mode does not
 evaluate 'from collect' correctly.
In-Reply-To: <JIRA.12502695.1381411324000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502695.1381411324000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502695.1381411324000.694.1381507466831@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813530#comment-12813530 ] 

RH Bugzilla Integration commented on DROOLS-295:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> made a comment on [bug 1018296|https://bugzilla.redhat.com/show_bug.cgi?id=1018296]

Fixed by https://github.com/droolsjbpm/drools/commit/d4ff4d31f
                
> Phreak mode does not evaluate 'from collect' correctly.
> -------------------------------------------------------
>
>                 Key: DROOLS-295
>                 URL: https://issues.jboss.org/browse/DROOLS-295
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>         Environment: Mac OS-X 10.8.5, Oracle Hotspot 1.7.0_40, Drools 6.1.0-SNAPSHOT
>            Reporter: Duncan Doyle
>            Assignee: Mark Proctor
>
> Reproducer project at: https://github.com/DuncanDoyle/Drools6PhreakFromCollectIssue
> Run 'mvn clean test'. There are 2 tests which execute exactly the same thing against the same ruleset, one in ReteOO mode and one in Phreak. The result of the Phreak test is incorrect. There seems to be an issue with the 'from collect' in Phreak mode.
> Please note that I'm using Drools 6.0.0-SNAPSHOT, as 6.0.0.Cr4-Pre1 contains a bug which causes the 'from collect' to go into an infinite loop. See Drools-276
>  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 12:04:27 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 11 Oct 2013 12:04:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-295) Phreak mode does not
 evaluate 'from collect' correctly.
In-Reply-To: <JIRA.12502695.1381411324000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502695.1381411324000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502695.1381411324000.699.1381507467094@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813531#comment-12813531 ] 

RH Bugzilla Integration commented on DROOLS-295:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> changed the Status of [bug 1018296|https://bugzilla.redhat.com/show_bug.cgi?id=1018296] from NEW to MODIFIED
                
> Phreak mode does not evaluate 'from collect' correctly.
> -------------------------------------------------------
>
>                 Key: DROOLS-295
>                 URL: https://issues.jboss.org/browse/DROOLS-295
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>         Environment: Mac OS-X 10.8.5, Oracle Hotspot 1.7.0_40, Drools 6.1.0-SNAPSHOT
>            Reporter: Duncan Doyle
>            Assignee: Mark Proctor
>
> Reproducer project at: https://github.com/DuncanDoyle/Drools6PhreakFromCollectIssue
> Run 'mvn clean test'. There are 2 tests which execute exactly the same thing against the same ruleset, one in ReteOO mode and one in Phreak. The result of the Phreak test is incorrect. There seems to be an issue with the 'from collect' in Phreak mode.
> Please note that I'm using Drools 6.0.0-SNAPSHOT, as 6.0.0.Cr4-Pre1 contains a bug which causes the 'from collect' to go into an infinite loop. See Drools-276
>  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 12:04:27 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 11 Oct 2013 12:04:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-295) Phreak mode does not
 evaluate 'from collect' correctly.
In-Reply-To: <JIRA.12502695.1381411324000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502695.1381411324000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502695.1381411324000.704.1381507467300@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813532#comment-12813532 ] 

RH Bugzilla Integration commented on DROOLS-295:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> made a comment on [bug 1018296|https://bugzilla.redhat.com/show_bug.cgi?id=1018296]

Fixed by https://github.com/droolsjbpm/drools/commit/d4ff4d31f
                
> Phreak mode does not evaluate 'from collect' correctly.
> -------------------------------------------------------
>
>                 Key: DROOLS-295
>                 URL: https://issues.jboss.org/browse/DROOLS-295
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>         Environment: Mac OS-X 10.8.5, Oracle Hotspot 1.7.0_40, Drools 6.1.0-SNAPSHOT
>            Reporter: Duncan Doyle
>            Assignee: Mark Proctor
>
> Reproducer project at: https://github.com/DuncanDoyle/Drools6PhreakFromCollectIssue
> Run 'mvn clean test'. There are 2 tests which execute exactly the same thing against the same ruleset, one in ReteOO mode and one in Phreak. The result of the Phreak test is incorrect. There seems to be an issue with the 'from collect' in Phreak mode.
> Please note that I'm using Drools 6.0.0-SNAPSHOT, as 6.0.0.Cr4-Pre1 contains a bug which causes the 'from collect' to go into an infinite loop. See Drools-276
>  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 12:04:27 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 11 Oct 2013 12:04:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-295) Phreak mode does not
 evaluate 'from collect' correctly.
In-Reply-To: <JIRA.12502695.1381411324000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502695.1381411324000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502695.1381411324000.709.1381507467591@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813533#comment-12813533 ] 

RH Bugzilla Integration commented on DROOLS-295:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> changed the Status of [bug 1018296|https://bugzilla.redhat.com/show_bug.cgi?id=1018296] from NEW to MODIFIED
                
> Phreak mode does not evaluate 'from collect' correctly.
> -------------------------------------------------------
>
>                 Key: DROOLS-295
>                 URL: https://issues.jboss.org/browse/DROOLS-295
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>         Environment: Mac OS-X 10.8.5, Oracle Hotspot 1.7.0_40, Drools 6.1.0-SNAPSHOT
>            Reporter: Duncan Doyle
>            Assignee: Mark Proctor
>
> Reproducer project at: https://github.com/DuncanDoyle/Drools6PhreakFromCollectIssue
> Run 'mvn clean test'. There are 2 tests which execute exactly the same thing against the same ruleset, one in ReteOO mode and one in Phreak. The result of the Phreak test is incorrect. There seems to be an issue with the 'from collect' in Phreak mode.
> Please note that I'm using Drools 6.0.0-SNAPSHOT, as 6.0.0.Cr4-Pre1 contains a bug which causes the 'from collect' to go into an infinite loop. See Drools-276
>  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 12:04:28 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 11 Oct 2013 12:04:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-295) Phreak mode does not
 evaluate 'from collect' correctly.
In-Reply-To: <JIRA.12502695.1381411324000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502695.1381411324000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502695.1381411324000.715.1381507468013@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813534#comment-12813534 ] 

RH Bugzilla Integration commented on DROOLS-295:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> made a comment on [bug 1018296|https://bugzilla.redhat.com/show_bug.cgi?id=1018296]

Fixed by https://github.com/droolsjbpm/drools/commit/d4ff4d31f
                
> Phreak mode does not evaluate 'from collect' correctly.
> -------------------------------------------------------
>
>                 Key: DROOLS-295
>                 URL: https://issues.jboss.org/browse/DROOLS-295
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>         Environment: Mac OS-X 10.8.5, Oracle Hotspot 1.7.0_40, Drools 6.1.0-SNAPSHOT
>            Reporter: Duncan Doyle
>            Assignee: Mark Proctor
>
> Reproducer project at: https://github.com/DuncanDoyle/Drools6PhreakFromCollectIssue
> Run 'mvn clean test'. There are 2 tests which execute exactly the same thing against the same ruleset, one in ReteOO mode and one in Phreak. The result of the Phreak test is incorrect. There seems to be an issue with the 'from collect' in Phreak mode.
> Please note that I'm using Drools 6.0.0-SNAPSHOT, as 6.0.0.Cr4-Pre1 contains a bug which causes the 'from collect' to go into an infinite loop. See Drools-276
>  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 12:06:26 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Fri, 11 Oct 2013 12:06:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-295) Phreak mode does not
 evaluate 'from collect' correctly.
In-Reply-To: <JIRA.12502695.1381411324000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502695.1381411324000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502695.1381411324000.726.1381507586788@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-295:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> Phreak mode does not evaluate 'from collect' correctly.
> -------------------------------------------------------
>
>                 Key: DROOLS-295
>                 URL: https://issues.jboss.org/browse/DROOLS-295
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>         Environment: Mac OS-X 10.8.5, Oracle Hotspot 1.7.0_40, Drools 6.1.0-SNAPSHOT
>            Reporter: Duncan Doyle
>            Assignee: Mario Fusco
>
> Reproducer project at: https://github.com/DuncanDoyle/Drools6PhreakFromCollectIssue
> Run 'mvn clean test'. There are 2 tests which execute exactly the same thing against the same ruleset, one in ReteOO mode and one in Phreak. The result of the Phreak test is incorrect. There seems to be an issue with the 'from collect' in Phreak mode.
> Please note that I'm using Drools 6.0.0-SNAPSHOT, as 6.0.0.Cr4-Pre1 contains a bug which causes the 'from collect' to go into an infinite loop. See Drools-276
>  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 12:06:26 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Fri, 11 Oct 2013 12:06:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-295) Phreak mode does not
 evaluate 'from collect' correctly.
In-Reply-To: <JIRA.12502695.1381411324000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502695.1381411324000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502695.1381411324000.729.1381507586917@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-295.
--------------------------------

    Fix Version/s: 6.0.0.Final
       Resolution: Done

    
> Phreak mode does not evaluate 'from collect' correctly.
> -------------------------------------------------------
>
>                 Key: DROOLS-295
>                 URL: https://issues.jboss.org/browse/DROOLS-295
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>         Environment: Mac OS-X 10.8.5, Oracle Hotspot 1.7.0_40, Drools 6.1.0-SNAPSHOT
>            Reporter: Duncan Doyle
>            Assignee: Mario Fusco
>             Fix For: 6.0.0.Final
>
>
> Reproducer project at: https://github.com/DuncanDoyle/Drools6PhreakFromCollectIssue
> Run 'mvn clean test'. There are 2 tests which execute exactly the same thing against the same ruleset, one in ReteOO mode and one in Phreak. The result of the Phreak test is incorrect. There seems to be an issue with the 'from collect' in Phreak mode.
> Please note that I'm using Drools 6.0.0-SNAPSHOT, as 6.0.0.Cr4-Pre1 contains a bug which causes the 'from collect' to go into an infinite loop. See Drools-276
>  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 12:43:26 2013
From: jira-events at lists.jboss.org (Denis Kostousov (JIRA))
Date: Fri, 11 Oct 2013 12:43:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2294) jandex-1.1.0.Alpha1.jar
 doesn't support JDK 8
In-Reply-To: <JIRA.12502848.1381509782261@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502848.1381509782261@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502848.1381509782261.796.1381509806540@jira02.app.mwc.hst.phx2.redhat.com>

Denis Kostousov created WFLY-2294:
-------------------------------------

             Summary: jandex-1.1.0.Alpha1.jar doesn't support JDK 8
                 Key: WFLY-2294
                 URL: https://issues.jboss.org/browse/WFLY-2294
             Project: WildFly
          Issue Type: Bug
    Affects Versions: 8.0.0.Beta1, 8.0.0.Alpha4
            Reporter: Denis Kostousov


Wildfly 8.0.0.Beta1 uses jandex-1.1.0.Alpha1.jar This library doesn't support JDK8. It should be replaced by jandex-1.1.0.Final

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 12:47:26 2013
From: jira-events at lists.jboss.org (Pedro Igor (JIRA))
Date: Fri, 11 Oct 2013 12:47:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2293) Security subsystem is not
 considering the "module" attribute for JASPI "auth-module" elements
In-Reply-To: <JIRA.12502840.1381504933000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502840.1381504933000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502840.1381504933000.798.1381510046549@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813546#comment-12813546 ] 

Pedro Igor commented on WFLY-2293:
----------------------------------

Impacts the configuration of security domains with JASPI support.
                
> Security subsystem is not considering the "module" attribute for JASPI "auth-module" elements
> ---------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2293
>                 URL: https://issues.jboss.org/browse/WFLY-2293
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Pedro Igor
>
> This issue impacts users from using their own ServerAuthModule implementations from other modules.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 12:49:27 2013
From: jira-events at lists.jboss.org (Pedro Igor (JIRA))
Date: Fri, 11 Oct 2013 12:49:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2293) Security subsystem is not
 considering the "module" attribute for JASPI "auth-module" elements
In-Reply-To: <JIRA.12502840.1381504933000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502840.1381504933000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502840.1381504933000.813.1381510167121@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813546#comment-12813546 ] 

Pedro Igor edited comment on WFLY-2293 at 10/11/13 12:48 PM:
-------------------------------------------------------------

Impacts the configuration of security domains with JASPI support.

There is new integration test that covers this issue. Once WFLY-531 is merged, you can check:

org.jboss.as.test.integration.security.jaspi.JASPIHttpSchemeServerAuthModelTestCase
                
      was (Author: pcraveiro):
    Impacts the configuration of security domains with JASPI support.
                  
> Security subsystem is not considering the "module" attribute for JASPI "auth-module" elements
> ---------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2293
>                 URL: https://issues.jboss.org/browse/WFLY-2293
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Pedro Igor
>
> This issue impacts users from using their own ServerAuthModule implementations from other modules.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 14:20:26 2013
From: jira-events at lists.jboss.org (Maciej Swiderski (JIRA))
Date: Fri, 11 Oct 2013 14:20:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-298) kie-ci support for custom
 location of m2 local repository
In-Reply-To: <JIRA.12502855.1381515583908@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502855.1381515583908@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502855.1381515583908.921.1381515626542@jira02.app.mwc.hst.phx2.redhat.com>

Maciej Swiderski created DROOLS-298:
---------------------------------------

             Summary: kie-ci support for custom location of m2 local repository
                 Key: DROOLS-298
                 URL: https://issues.jboss.org/browse/DROOLS-298
             Project: Drools
          Issue Type: Enhancement
      Security Level: Public (Everyone can see)
    Affects Versions:  6.0.0.CR4
            Reporter: Maciej Swiderski
            Assignee: Mark Proctor


currently kie-ci assumes that local m2 repo is stored in ~/.m2/repository which is not always the case as it can be configured via settings.xml. This is common case in many organization due to limitations of data that can be stored in user home directory or backup routines. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 14:24:26 2013
From: jira-events at lists.jboss.org (alexandre xypas (JIRA))
Date: Fri, 11 Oct 2013 14:24:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2276) URI ENCODING does not work in
 the beta1 version (UTF-8)
In-Reply-To: <JIRA.12502684.1381404449000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502684.1381404449000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502684.1381404449000.926.1381515866596@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813561#comment-12813561 ] 

alexandre xypas commented on WFLY-2276:
---------------------------------------

I am using jsf 2 that is shipped with Wildfly Beta1, during validation, the rendered response is not utf-8 encoded. The following filter is used to encode in UTF-8:

@WebFilter(urlPatterns= "/*", filterName="characterEncodingFilter" )
public class CharacterEncodingFilter implements Filter {
	
	@Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws ServletException, IOException {
        // To fix a bug in Primefaces
	request.setCharacterEncoding("UTF-8");
        
        //For the javascript to be encoded as UTF-8
        response.setCharacterEncoding("UTF-8");
        chain.doFilter(request, response);
    }
...

}
Is there a way to force Undertow to encode the response as UTF-8? Thanks.
                
> URI ENCODING does not work in the beta1 version (UTF-8)
> -------------------------------------------------------
>
>                 Key: WFLY-2276
>                 URL: https://issues.jboss.org/browse/WFLY-2276
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (JBoss Web)
>    Affects Versions: 8.0.0.Beta1
>         Environment: Java 7, ubuntu 12.04
>            Reporter: alexandre xypas
>              Labels: encoding, utf-8
>
> In standalone.xml, the following is working in Alpha4, but not anymore in Beta1.
> <property name="org.apache.catalina.connector.URI_ENCODING" value="UTF-8"/>
> <property name="org.apache.catalina.connector.USE_BODY_ENCODING_FOR_QUERY_STRING" value="true"/>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 15:31:26 2013
From: jira-events at lists.jboss.org (Marco Rietveld (JIRA))
Date: Fri, 11 Oct 2013 15:31:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-298) kie-ci support for custom
 location of m2 local repository
In-Reply-To: <JIRA.12502855.1381515583000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502855.1381515583000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502855.1381515583000.1023.1381519886622@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marco Rietveld updated DROOLS-298:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> kie-ci support for custom location of m2 local repository
> ---------------------------------------------------------
>
>                 Key: DROOLS-298
>                 URL: https://issues.jboss.org/browse/DROOLS-298
>             Project: Drools
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>            Reporter: Maciej Swiderski
>            Assignee: Mario Fusco
>
> currently kie-ci assumes that local m2 repo is stored in ~/.m2/repository which is not always the case as it can be configured via settings.xml. This is common case in many organization due to limitations of data that can be stored in user home directory or backup routines. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 17:20:26 2013
From: jira-events at lists.jboss.org (Jonathan Fuerth (JIRA))
Date: Fri, 11 Oct 2013 17:20:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1992) Invalid deployment in WildFly
 8 - Errai, Weld, TicketMonster
In-Reply-To: <JIRA.12499827.1378213572000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499827.1378213572000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499827.1378213572000.1335.1381526426564@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813606#comment-12813606 ] 

Jonathan Fuerth commented on WFLY-1992:
---------------------------------------

I've had success deploying Errai and UberFire apps to WildFly 8 Beta1. I think it's safe to mark this one resolved.
                
> Invalid deployment in WildFly 8 - Errai, Weld, TicketMonster
> ------------------------------------------------------------
>
>                 Key: WFLY-1992
>                 URL: https://issues.jboss.org/browse/WFLY-1992
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Emmanuel Bernard
>
> I am deploying TicketMonster which includes Errai and receives a deployment error that is not happening in JBoss AS 7.x nor EAP 6.x.
> Note that it could be
> - a WildFly error per se
> - a Weld error or change
> - an Errai error
> I am opening the issue here to track the problem down to its cause.
> {code}
> 15:00:17,818 INFO  [org.jboss.errai.cdi.server.CDIExtensionPoints] (MSC service thread 1-5) starting errai cdi ...
> 15:00:18,731 INFO  [org.jboss.errai.reflections.Reflections] (Thread-106) Reflections took 346 ms to scan 7 urls, producing 387 keys and 1384 values [using 2 cores]
> 15:00:18,815 WARN  [org.jboss.weld.Bean] (MSC service thread 1-5) WELD-001529 An InjectionTarget is created for a class org.jboss.errai.bus.server.service.ErraiServiceImpl which does not have any appropriate constructor.
> 15:00:18,828 INFO  [org.jboss.errai.cdi.server.CDIExtensionPoints] (pool-20-thread-1) all services registered successfully
> 15:00:18,928 WARN  [org.jboss.weld.Bootstrap] (weld-worker-2) WELD-001473 javax.enterprise.inject.spi.Bean implementation org.jboss.errai.cdi.server.ErraiServiceBean at 7adf1c57 declared a normal scope but does not implement javax.enterprise.inject.spi.PassivationCapable. It won't be possible to inject this bean into a bean with passivating scope (@SessionScoped, @ConversationScoped). This can be fixed by assigning the Bean implementation a unique id by implementing the PassivationCapable interface.
> 15:00:18,928 WARN  [org.jboss.weld.Bootstrap] (weld-worker-3) WELD-001473 javax.enterprise.inject.spi.Bean implementation org.jboss.errai.cdi.server.MessageBusBean at 19b6b8f5 declared a normal scope but does not implement javax.enterprise.inject.spi.PassivationCapable. It won't be possible to inject this bean into a bean with passivating scope (@SessionScoped, @ConversationScoped). This can be fixed by assigning the Bean implementation a unique id by implementing the PassivationCapable interface.
> 15:00:18,945 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."ticket-monster.war".component."org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1".WeldInstantiator: org.jboss.msc.service.StartException in service jboss.deployment.unit."ticket-monster.war".component."org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1".WeldInstantiator: Failed to start service
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1900) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000070 Simple bean [EnhancedAnnotatedTypeImpl]  class org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1 cannot be a non-static inner class
> 	at org.jboss.weld.injection.producer.BasicInjectionTarget.checkType(BasicInjectionTarget.java:81)
> 	at org.jboss.weld.injection.producer.BasicInjectionTarget.<init>(BasicInjectionTarget.java:69)
> 	at org.jboss.as.weld.injection.NonContextualComponentInjectionTarget.<init>(NonContextualComponentInjectionTarget.java:48)
> 	at org.jboss.as.weld.injection.NonContextualComponentInjectionTarget.<init>(NonContextualComponentInjectionTarget.java:44)
> 	at org.jboss.as.weld.injection.WeldComponentService.start(WeldComponentService.java:129)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	... 3 more
> 15:00:18,975 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "ticket-monster.war")]) - failure description: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"ticket-monster.war\".component.\"org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1\".WeldInstantiator" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"ticket-monster.war\".component.\"org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1\".WeldInstantiator: Failed to start service
>     Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000070 Simple bean [EnhancedAnnotatedTypeImpl]  class org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1 cannot be a non-static inner class"}}
> 15:00:18,977 ERROR [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS015870: Deploy of deployment "ticket-monster.war" was rolled back with the following failure message: 
> {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"ticket-monster.war\".component.\"org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1\".WeldInstantiator" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"ticket-monster.war\".component.\"org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1\".WeldInstantiator: Failed to start service
>     Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000070 Simple bean [EnhancedAnnotatedTypeImpl]  class org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1 cannot be a non-static inner class"}}
> 15:00:18,986 INFO  [org.jboss.as.jpa] (ServerService Thread Pool -- 73) JBAS011410: Stopping Persistence Unit (phase 2 of 2) Service 'ticket-monster.war#primary'
> 15:00:18,987 INFO  [org.hibernate.tool.hbm2ddl.SchemaExport] (ServerService Thread Pool -- 73) HHH000227: Running hbm2ddl schema export
> 15:00:19,004 INFO  [org.hibernate.tool.hbm2ddl.SchemaExport] (ServerService Thread Pool -- 73) HHH000230: Schema export complete
> 15:00:19,007 INFO  [org.jboss.weld.deployer] (MSC service thread 1-4) JBAS016009: Stopping weld service for deployment ticket-monster.war
> 15:00:19,021 INFO  [org.jboss.as.jpa] (ServerService Thread Pool -- 73) JBAS011410: Stopping Persistence Unit (phase 1 of 2) Service 'ticket-monster.war#primary'
> 15:00:19,022 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-6) JBAS010409: Unbound data source [java:jboss/datasources/ticket-monsterDS]
> 15:00:19,050 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015877: Stopped deployment ticket-monster.war (runtime-name: ticket-monster.war) in 72ms
> 15:00:19,052 INFO  [org.jboss.as.controller] (DeploymentScanner-threads - 1) JBAS014774: Service status report
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.deployment.unit."ticket-monster.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START (missing) dependents: [service jboss.deployment.unit."ticket-monster.war".deploymentCompleteService, service jboss.undertow.deployment.default-host./ticket-monster] 
> JBAS014776:    Newly corrected services:
>       service jboss.deployment.unit."ticket-monster.war".ee.ComponentRegistry (no longer required)
> JBAS014777:   Services which failed to start:      service jboss.deployment.unit."ticket-monster.war".component."org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1".WeldInstantiator
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 18:25:26 2013
From: jira-events at lists.jboss.org (Pedro Igor (JIRA))
Date: Fri, 11 Oct 2013 18:25:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-140) Java Authentication Service
 Provider Interface for Containers 1.1 (JSR-196)
In-Reply-To: <JIRA.12498523.1376434986000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498523.1376434986000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498523.1376434986000.1361.1381530326687@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBEE-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813610#comment-12813610 ] 

Pedro Igor commented on JBEE-140:
---------------------------------

Hi Shelly,

I've being working with the JBoss JASPI 1.1 API review, specially the javadocs. The following PR holds all javadoc changes:

https://github.com/jboss/jboss-jaspi-api_spec/pull/2

I've discussed with Stefan about the TCK signature tests. How can we run them considering all changes I did ? I could not find a way to run them locally.

Thanks in advance. 
                
> Java Authentication Service Provider Interface for Containers 1.1 (JSR-196)
> ---------------------------------------------------------------------------
>
>                 Key: JBEE-140
>                 URL: https://issues.jboss.org/browse/JBEE-140
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Sub-task
>          Components: jboss-jaspi-api
>            Reporter: Shelly McGowan
>            Assignee: Stefan Guilhen
>             Fix For: JavaEE 7 Spec APIs 1.0.0.Beta1
>
>
> Updates needed for JASPIC 1.1.
> See linked issue.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 11 22:51:26 2013
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Fri, 11 Oct 2013 22:51:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-140) Java Authentication Service
 Provider Interface for Containers 1.1 (JSR-196)
In-Reply-To: <JIRA.12498523.1376434986000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498523.1376434986000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498523.1376434986000.1382.1381546286577@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBEE-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan reassigned JBEE-140:
-----------------------------------

    Assignee: Shelly McGowan  (was: Stefan Guilhen)


I'll merge the pull request and do a local signature test run against the SNAPHOT.   My environment is set up to easily perform that testing.  I'll also generate the JavaDocs for review as well.
                
> Java Authentication Service Provider Interface for Containers 1.1 (JSR-196)
> ---------------------------------------------------------------------------
>
>                 Key: JBEE-140
>                 URL: https://issues.jboss.org/browse/JBEE-140
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Sub-task
>          Components: jboss-jaspi-api
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>             Fix For: JavaEE 7 Spec APIs 1.0.0.Beta1
>
>
> Updates needed for JASPIC 1.1.
> See linked issue.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 12 02:02:26 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Sat, 12 Oct 2013 02:02:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1992) Invalid deployment in WildFly
 8 - Errai, Weld, TicketMonster
In-Reply-To: <JIRA.12499827.1378213572000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499827.1378213572000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499827.1378213572000.1389.1381557746749@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-1992.
----------------------------------

    Fix Version/s: 8.0.0.Beta1
       Resolution: Done


Sounds like this has been resolved
                
> Invalid deployment in WildFly 8 - Errai, Weld, TicketMonster
> ------------------------------------------------------------
>
>                 Key: WFLY-1992
>                 URL: https://issues.jboss.org/browse/WFLY-1992
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Emmanuel Bernard
>             Fix For: 8.0.0.Beta1
>
>
> I am deploying TicketMonster which includes Errai and receives a deployment error that is not happening in JBoss AS 7.x nor EAP 6.x.
> Note that it could be
> - a WildFly error per se
> - a Weld error or change
> - an Errai error
> I am opening the issue here to track the problem down to its cause.
> {code}
> 15:00:17,818 INFO  [org.jboss.errai.cdi.server.CDIExtensionPoints] (MSC service thread 1-5) starting errai cdi ...
> 15:00:18,731 INFO  [org.jboss.errai.reflections.Reflections] (Thread-106) Reflections took 346 ms to scan 7 urls, producing 387 keys and 1384 values [using 2 cores]
> 15:00:18,815 WARN  [org.jboss.weld.Bean] (MSC service thread 1-5) WELD-001529 An InjectionTarget is created for a class org.jboss.errai.bus.server.service.ErraiServiceImpl which does not have any appropriate constructor.
> 15:00:18,828 INFO  [org.jboss.errai.cdi.server.CDIExtensionPoints] (pool-20-thread-1) all services registered successfully
> 15:00:18,928 WARN  [org.jboss.weld.Bootstrap] (weld-worker-2) WELD-001473 javax.enterprise.inject.spi.Bean implementation org.jboss.errai.cdi.server.ErraiServiceBean at 7adf1c57 declared a normal scope but does not implement javax.enterprise.inject.spi.PassivationCapable. It won't be possible to inject this bean into a bean with passivating scope (@SessionScoped, @ConversationScoped). This can be fixed by assigning the Bean implementation a unique id by implementing the PassivationCapable interface.
> 15:00:18,928 WARN  [org.jboss.weld.Bootstrap] (weld-worker-3) WELD-001473 javax.enterprise.inject.spi.Bean implementation org.jboss.errai.cdi.server.MessageBusBean at 19b6b8f5 declared a normal scope but does not implement javax.enterprise.inject.spi.PassivationCapable. It won't be possible to inject this bean into a bean with passivating scope (@SessionScoped, @ConversationScoped). This can be fixed by assigning the Bean implementation a unique id by implementing the PassivationCapable interface.
> 15:00:18,945 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."ticket-monster.war".component."org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1".WeldInstantiator: org.jboss.msc.service.StartException in service jboss.deployment.unit."ticket-monster.war".component."org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1".WeldInstantiator: Failed to start service
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1900) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000070 Simple bean [EnhancedAnnotatedTypeImpl]  class org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1 cannot be a non-static inner class
> 	at org.jboss.weld.injection.producer.BasicInjectionTarget.checkType(BasicInjectionTarget.java:81)
> 	at org.jboss.weld.injection.producer.BasicInjectionTarget.<init>(BasicInjectionTarget.java:69)
> 	at org.jboss.as.weld.injection.NonContextualComponentInjectionTarget.<init>(NonContextualComponentInjectionTarget.java:48)
> 	at org.jboss.as.weld.injection.NonContextualComponentInjectionTarget.<init>(NonContextualComponentInjectionTarget.java:44)
> 	at org.jboss.as.weld.injection.WeldComponentService.start(WeldComponentService.java:129)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	... 3 more
> 15:00:18,975 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "ticket-monster.war")]) - failure description: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"ticket-monster.war\".component.\"org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1\".WeldInstantiator" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"ticket-monster.war\".component.\"org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1\".WeldInstantiator: Failed to start service
>     Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000070 Simple bean [EnhancedAnnotatedTypeImpl]  class org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1 cannot be a non-static inner class"}}
> 15:00:18,977 ERROR [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS015870: Deploy of deployment "ticket-monster.war" was rolled back with the following failure message: 
> {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"ticket-monster.war\".component.\"org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1\".WeldInstantiator" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"ticket-monster.war\".component.\"org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1\".WeldInstantiator: Failed to start service
>     Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000070 Simple bean [EnhancedAnnotatedTypeImpl]  class org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1 cannot be a non-static inner class"}}
> 15:00:18,986 INFO  [org.jboss.as.jpa] (ServerService Thread Pool -- 73) JBAS011410: Stopping Persistence Unit (phase 2 of 2) Service 'ticket-monster.war#primary'
> 15:00:18,987 INFO  [org.hibernate.tool.hbm2ddl.SchemaExport] (ServerService Thread Pool -- 73) HHH000227: Running hbm2ddl schema export
> 15:00:19,004 INFO  [org.hibernate.tool.hbm2ddl.SchemaExport] (ServerService Thread Pool -- 73) HHH000230: Schema export complete
> 15:00:19,007 INFO  [org.jboss.weld.deployer] (MSC service thread 1-4) JBAS016009: Stopping weld service for deployment ticket-monster.war
> 15:00:19,021 INFO  [org.jboss.as.jpa] (ServerService Thread Pool -- 73) JBAS011410: Stopping Persistence Unit (phase 1 of 2) Service 'ticket-monster.war#primary'
> 15:00:19,022 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-6) JBAS010409: Unbound data source [java:jboss/datasources/ticket-monsterDS]
> 15:00:19,050 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015877: Stopped deployment ticket-monster.war (runtime-name: ticket-monster.war) in 72ms
> 15:00:19,052 INFO  [org.jboss.as.controller] (DeploymentScanner-threads - 1) JBAS014774: Service status report
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.deployment.unit."ticket-monster.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START (missing) dependents: [service jboss.deployment.unit."ticket-monster.war".deploymentCompleteService, service jboss.undertow.deployment.default-host./ticket-monster] 
> JBAS014776:    Newly corrected services:
>       service jboss.deployment.unit."ticket-monster.war".ee.ComponentRegistry (no longer required)
> JBAS014777:   Services which failed to start:      service jboss.deployment.unit."ticket-monster.war".component."org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1".WeldInstantiator
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 12 08:20:35 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Sat, 12 Oct 2013 08:20:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-236) NPE when ksession is
 serialized with facts logically inserted
In-Reply-To: <JIRA.12499263.1377254187000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499263.1377254187000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499263.1377254187000.4.1381580435703@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813710#comment-12813710 ] 

RH Bugzilla Integration commented on DROOLS-236:
------------------------------------------------

Ryan Zhang <rzhang at redhat.com> changed the Status of [bug 1000384|https://bugzilla.redhat.com/show_bug.cgi?id=1000384] from MODIFIED to ON_QA
                
> NPE when ksession is serialized with facts logically inserted
> -------------------------------------------------------------
>
>                 Key: DROOLS-236
>                 URL: https://issues.jboss.org/browse/DROOLS-236
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.CR1
>            Reporter: Toshiya Kobayashi
>            Assignee: Edson Tirelli
>
> Reproduce steps:
> Assuming Employee is a subclass of Person...
> 1. Insert an Employee (say, 'Alice')
> 2. InsertLogical a Person (say, 'Bob')
> 3. Serialize and deserialize ksession
> 4. Insert an Employee (say, 'Claire')
> 5. Update 'Claire'
> It throws an NEP:
> {noformat}
> Exception executing consequence for rule "Promote" in defaultpkg: java.lang.NullPointerException
> 	at org.drools.core.runtime.rule.impl.DefaultConsequenceExceptionHandler.handleException(DefaultConsequenceExceptionHandler.java:39)
> 	at org.drools.core.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1026)
> ...
> Caused by: java.lang.NullPointerException
> 	at org.drools.core.common.NamedEntryPoint.update(NamedEntryPoint.java:434)
> 	at org.drools.core.base.DefaultKnowledgeHelper.update(DefaultKnowledgeHelper.java:367)
> 	at defaultpkg.Rule_Promote139773612.defaultConsequence(Rule_Promote139773612.java:9)
> 	at defaultpkg.Rule_Promote139773612DefaultConsequenceInvokerGenerated.evaluate(Unknown Source)
> 	at defaultpkg.Rule_Promote139773612DefaultConsequenceInvoker.evaluate(Unknown Source)
> 	at org.drools.core.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1016)
> 	... 37 more
> {noformat}
> In the step 2, ClassObjectTypeConf of Person[Bob] enables TMS. But at that time, Employee[Alice] creates its EqualityKey and put it to TMS.
> NamedEntryPoint.java:
> {code:java}
>     private void enableTMS(Object object, ObjectTypeConf conf) {
>         
>         final Rete source = this.ruleBase.getRete();
>         final ClassObjectType cot = new ClassObjectType( object.getClass() );
>         final Map<ObjectType, ObjectTypeNode> map = source.getObjectTypeNodes( EntryPointId.DEFAULT );
>         final ObjectTypeNode node = map.get( cot );
>         final ObjectHashSet memory = ((ObjectTypeNodeMemory) this.wm.getNodeMemory( node )).memory;
>       
>         // All objects of this type that are already there were certainly stated,
>         // since this method call happens at the first logical insert, for any given type.
>         org.drools.core.util.Iterator it = memory.iterator();
>         for ( Object obj = it.next(); obj != null; obj = it.next() ) {
>           
>             org.drools.core.util.ObjectHashSet.ObjectEntry holder = (org.drools.core.util.ObjectHashSet.ObjectEntry) obj;
>     
>             InternalFactHandle handle = (InternalFactHandle) holder.getValue();
>             
>             if ( handle != null) {
>                 EqualityKey key = new EqualityKey( handle );
>                 handle.setEqualityKey( key );
>                 key.setStatus(EqualityKey.STATED);
>                 getTruthMaintenanceSystem().put(key);
>             }
>         }
>       
>         // Enable TMS for this type.
>         conf.enableTMS();
>       
>     }
> {code}
> Then during deserialization, ProtobufInputMarshaller enables TMS for ClassObjectTypeConf of Employee[Alice] and ClassObjectTypeConf of Person[Bob]. 
> ProtobufInputMarshaller.java:
> {code:java}
>     public static void readTruthMaintenanceSystem( MarshallerReaderContext context, 
>                                                    RuleData _session ) throws IOException {
>         TruthMaintenanceSystem tms = context.wm.getTruthMaintenanceSystem();
>         ProtobufMessages.TruthMaintenanceSystem _tms = _session.getTms();
>         
>         for( ProtobufMessages.EqualityKey _key : _tms.getKeyList() ) {
>             InternalFactHandle handle = (InternalFactHandle) context.handles.get( _key.getHandleId() );
>             // ObjectTypeConf state is not marshalled, so it needs to be re-determined
>             ObjectTypeConf typeConf = context.wm.getObjectTypeConfigurationRegistry().getObjectTypeConf( ((NamedEntryPoint)handle.getEntryPoint()).getEntryPoint(),
>                                                                                                          handle.getObject() );
>             if (!typeConf.isTMSEnabled()) {
>                 typeConf.enableTMS();
>             }
> {code}
> Finally, Employee(Claire) is updated. ClassObjectTypeConf of Employee is under TMS but Claire doesn't have EqualityKey hence NPE is thrown.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 12 08:20:36 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Sat, 12 Oct 2013 08:20:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-253) Importing a domain class
 named "Exception" raises an ambiguity exception during RHS compilation
In-Reply-To: <JIRA.12500159.1378411795000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500159.1378411795000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500159.1378411795000.15.1381580436308@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813713#comment-12813713 ] 

RH Bugzilla Integration commented on DROOLS-253:
------------------------------------------------

Ryan Zhang <rzhang at redhat.com> changed the Status of [bug 1010281|https://bugzilla.redhat.com/show_bug.cgi?id=1010281] from MODIFIED to ON_QA
                
> Importing a domain class named "Exception" raises an ambiguity exception during RHS compilation
> -----------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-253
>                 URL: https://issues.jboss.org/browse/DROOLS-253
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final,  6.0.0.CR3
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Blocker
>             Fix For:  6.0.0.CR4
>
>
> If a user class named Exception is used,
> import my.own.domain.Exception
> rule "Foo"
> when then end
> the RHS compilation process resolves "Exception" to that name
> rather than to java.lang.Exception
> >> Rule compilation error [Rule name=Foo] : 
>    {if import * is used } The type Exception is ambiguous
>    {if explicit import is used } Exception is not Throwable

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 12 08:20:36 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Sat, 12 Oct 2013 08:20:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBRULES-3666) kbase holds multiple
 KnowledgeBaseEventListenerWrapper instances when adding the same
 KnowledgeBaseEventListener multiple times
In-Reply-To: <JIRA.12477585.1350909161000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12477585.1350909161000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12477585.1350909161000.18.1381580436478@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBRULES-3666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813714#comment-12813714 ] 

RH Bugzilla Integration commented on JBRULES-3666:
--------------------------------------------------

Ryan Zhang <rzhang at redhat.com> changed the Status of [bug 958394|https://bugzilla.redhat.com/show_bug.cgi?id=958394] from MODIFIED to ON_QA
                
> kbase holds multiple KnowledgeBaseEventListenerWrapper instances when adding the same KnowledgeBaseEventListener multiple times
> -------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-3666
>                 URL: https://issues.jboss.org/browse/JBRULES-3666
>             Project: JBRULES
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.5.0.Beta1
>            Reporter: Toshiya Kobayashi
>            Assignee: Mario Fusco
>             Fix For: 5.5.0.Final
>
>
> When you add the same KnowledgeBaseEventListener to kbase twice, kbase holds both KnowledgeBaseEventListenerWrapper instances. I'm not 100% sure if this is a bug but I guess KnowledgeBaseEventListenerWrapper should implement equals() method like StatefulKnowledgeSessionImpl$AgendaEventListenerWrapper.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 12 12:29:35 2013
From: jira-events at lists.jboss.org (Pierantonio Cangianiello (JIRA))
Date: Sat, 12 Oct 2013 12:29:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1715) NullPointerException in
 MessageDispatcher.handleUpEvent
In-Reply-To: <JIRA.12502910.1381595328826@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502910.1381595328826@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502910.1381595328826.235.1381595375510@jira02.app.mwc.hst.phx2.redhat.com>

Pierantonio Cangianiello created JGRP-1715:
----------------------------------------------

             Summary: NullPointerException in MessageDispatcher.handleUpEvent
                 Key: JGRP-1715
                 URL: https://issues.jboss.org/browse/JGRP-1715
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 3.4
         Environment: Windows 7 x64 - JDK 1.7.0_40
            Reporter: Pierantonio Cangianiello
            Assignee: Bela Ban


1) Node A starts and becomes master.
2) Node B starts and Node A crashes.
3) Before becoming the new master, Node B calls channel.getState()
4) NullPointer occurs

Stacktrace:

java.lang.NullPointerException
	at java.io.ByteArrayInputStream.<init>(ByteArrayInputStream.java:106)
	at org.jgroups.blocks.MessageDispatcher.handleUpEvent(MessageDispatcher.java:567)
	at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:667)
	at org.jgroups.JChannel.up(JChannel.java:643)
	at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1015)
	at org.jgroups.protocols.Locking.up(Locking.java:269)
	at org.jgroups.protocols.pbcast.STATE_TRANSFER.handleViewChange(STATE_TRANSFER.java:293)
	at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:168)
	at org.jgroups.protocols.RSVP.up(RSVP.java:187)
	at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
	at org.jgroups.protocols.FlowControl.up(FlowControl.java:381)
	at org.jgroups.protocols.FlowControl.up(FlowControl.java:381)
	at org.jgroups.protocols.pbcast.GMS.castViewChange(GMS.java:574)
	at org.jgroups.protocols.pbcast.CoordGmsImpl.handleMembershipChange(CoordGmsImpl.java:219)
	at org.jgroups.protocols.pbcast.GMS$ViewHandler.process(GMS.java:1633)
	at org.jgroups.protocols.pbcast.GMS$ViewHandler.run(GMS.java:1587)
	at java.lang.Thread.run(Thread.java:724)

The issue seems to be related to this:

in STATE_TRANSFER, line 292-293:
Exception ex=new EOFException("state provider " + old_coord + " left");
            up_prot.up(new Event(Event.GET_STATE_OK, new StateTransferResult(ex)));
(buffer field is not set on event object)

after, in MessageDispatcher 567:
ByteArrayInputStream input=new ByteArrayInputStream(result.getBuffer());
causes NullPointer, since result.getBuffer() returns null.

A null-check here should resolve this issue, or an empty buffer could be set in STATE_TRANSFER class.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 12 12:42:35 2013
From: jira-events at lists.jboss.org (Pierantonio Cangianiello (JIRA))
Date: Sat, 12 Oct 2013 12:42:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1715) NullPointerException in
 MessageDispatcher.handleUpEvent
In-Reply-To: <JIRA.12502910.1381595328000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502910.1381595328000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502910.1381595328000.245.1381596155928@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pierantonio Cangianiello updated JGRP-1715:
-------------------------------------------

    Description: 
1) Node A starts and becomes master.
2) Node B starts and Node A crashes.
3) Before becoming the new master, Node B calls channel.getState()
4) NullPointer occurs

Stacktrace:

java.lang.NullPointerException
	at java.io.ByteArrayInputStream.<init>(ByteArrayInputStream.java:106)
	at org.jgroups.blocks.MessageDispatcher.handleUpEvent(MessageDispatcher.java:567)
	at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:667)
	at org.jgroups.JChannel.up(JChannel.java:643)
	at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1015)
	at org.jgroups.protocols.Locking.up(Locking.java:269)
	at org.jgroups.protocols.pbcast.STATE_TRANSFER.handleViewChange(STATE_TRANSFER.java:293)
	at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:168)
	at org.jgroups.protocols.RSVP.up(RSVP.java:187)
	at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
	at org.jgroups.protocols.FlowControl.up(FlowControl.java:381)
	at org.jgroups.protocols.FlowControl.up(FlowControl.java:381)
	at org.jgroups.protocols.pbcast.GMS.castViewChange(GMS.java:574)
	at org.jgroups.protocols.pbcast.CoordGmsImpl.handleMembershipChange(CoordGmsImpl.java:219)
	at org.jgroups.protocols.pbcast.GMS$ViewHandler.process(GMS.java:1633)
	at org.jgroups.protocols.pbcast.GMS$ViewHandler.run(GMS.java:1587)
	at java.lang.Thread.run(Thread.java:724)

The issue seems to be related to this:

in STATE_TRANSFER, line 292-293:
Exception ex=new EOFException("state provider " + old_coord + " left");
            up_prot.up(new Event(Event.GET_STATE_OK, new StateTransferResult(ex)));
(buffer field is not set on event object)

after, in MessageDispatcher 567:
ByteArrayInputStream input=new ByteArrayInputStream(result.getBuffer());
causes NullPointer, since result.getBuffer() returns null.

A null-check here should resolve this issue, or an empty buffer could be set in StateTransferResult class.

  was:
1) Node A starts and becomes master.
2) Node B starts and Node A crashes.
3) Before becoming the new master, Node B calls channel.getState()
4) NullPointer occurs

Stacktrace:

java.lang.NullPointerException
	at java.io.ByteArrayInputStream.<init>(ByteArrayInputStream.java:106)
	at org.jgroups.blocks.MessageDispatcher.handleUpEvent(MessageDispatcher.java:567)
	at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:667)
	at org.jgroups.JChannel.up(JChannel.java:643)
	at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1015)
	at org.jgroups.protocols.Locking.up(Locking.java:269)
	at org.jgroups.protocols.pbcast.STATE_TRANSFER.handleViewChange(STATE_TRANSFER.java:293)
	at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:168)
	at org.jgroups.protocols.RSVP.up(RSVP.java:187)
	at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
	at org.jgroups.protocols.FlowControl.up(FlowControl.java:381)
	at org.jgroups.protocols.FlowControl.up(FlowControl.java:381)
	at org.jgroups.protocols.pbcast.GMS.castViewChange(GMS.java:574)
	at org.jgroups.protocols.pbcast.CoordGmsImpl.handleMembershipChange(CoordGmsImpl.java:219)
	at org.jgroups.protocols.pbcast.GMS$ViewHandler.process(GMS.java:1633)
	at org.jgroups.protocols.pbcast.GMS$ViewHandler.run(GMS.java:1587)
	at java.lang.Thread.run(Thread.java:724)

The issue seems to be related to this:

in STATE_TRANSFER, line 292-293:
Exception ex=new EOFException("state provider " + old_coord + " left");
            up_prot.up(new Event(Event.GET_STATE_OK, new StateTransferResult(ex)));
(buffer field is not set on event object)

after, in MessageDispatcher 567:
ByteArrayInputStream input=new ByteArrayInputStream(result.getBuffer());
causes NullPointer, since result.getBuffer() returns null.

A null-check here should resolve this issue, or an empty buffer could be set in STATE_TRANSFER class.


    
> NullPointerException in MessageDispatcher.handleUpEvent
> -------------------------------------------------------
>
>                 Key: JGRP-1715
>                 URL: https://issues.jboss.org/browse/JGRP-1715
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>         Environment: Windows 7 x64 - JDK 1.7.0_40
>            Reporter: Pierantonio Cangianiello
>            Assignee: Bela Ban
>
> 1) Node A starts and becomes master.
> 2) Node B starts and Node A crashes.
> 3) Before becoming the new master, Node B calls channel.getState()
> 4) NullPointer occurs
> Stacktrace:
> java.lang.NullPointerException
> 	at java.io.ByteArrayInputStream.<init>(ByteArrayInputStream.java:106)
> 	at org.jgroups.blocks.MessageDispatcher.handleUpEvent(MessageDispatcher.java:567)
> 	at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:667)
> 	at org.jgroups.JChannel.up(JChannel.java:643)
> 	at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1015)
> 	at org.jgroups.protocols.Locking.up(Locking.java:269)
> 	at org.jgroups.protocols.pbcast.STATE_TRANSFER.handleViewChange(STATE_TRANSFER.java:293)
> 	at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:168)
> 	at org.jgroups.protocols.RSVP.up(RSVP.java:187)
> 	at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> 	at org.jgroups.protocols.FlowControl.up(FlowControl.java:381)
> 	at org.jgroups.protocols.FlowControl.up(FlowControl.java:381)
> 	at org.jgroups.protocols.pbcast.GMS.castViewChange(GMS.java:574)
> 	at org.jgroups.protocols.pbcast.CoordGmsImpl.handleMembershipChange(CoordGmsImpl.java:219)
> 	at org.jgroups.protocols.pbcast.GMS$ViewHandler.process(GMS.java:1633)
> 	at org.jgroups.protocols.pbcast.GMS$ViewHandler.run(GMS.java:1587)
> 	at java.lang.Thread.run(Thread.java:724)
> The issue seems to be related to this:
> in STATE_TRANSFER, line 292-293:
> Exception ex=new EOFException("state provider " + old_coord + " left");
>             up_prot.up(new Event(Event.GET_STATE_OK, new StateTransferResult(ex)));
> (buffer field is not set on event object)
> after, in MessageDispatcher 567:
> ByteArrayInputStream input=new ByteArrayInputStream(result.getBuffer());
> causes NullPointer, since result.getBuffer() returns null.
> A null-check here should resolve this issue, or an empty buffer could be set in StateTransferResult class.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 12 15:20:35 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Sat, 12 Oct 2013 15:20:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-369) Domain mode: kill an
	unresponsive JVM
In-Reply-To: <JIRA.12480351.1354566315000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12480351.1354566315000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12480351.1354566315000.260.1381605635824@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813740#comment-12813740 ] 

RH Bugzilla Integration commented on WFLY-369:
----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> made a comment on [bug 901232|https://bugzilla.redhat.com/show_bug.cgi?id=901232]

Emanuel's server side patch is merged for ER6, adding "destroy" and "kill" operations to the management API. I would move this BZ to MODIFIED but will await incorporation of the HAL version that uses this. If QE wants to test the operations via the CLI though, that will be possible in ER6.
                
> Domain mode: kill an unresponsive JVM
> -------------------------------------
>
>                 Key: WFLY-369
>                 URL: https://issues.jboss.org/browse/WFLY-369
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Dennis Reed
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.Alpha1
>
>
> If an AS instance gets into a state where it cannot be controlled normally by the host controller, local OS commands must be used to kill it.
> It would be helpful to be able to kill an unresponsive JVM through the management interface.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 12 15:26:35 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Sat, 12 Oct 2013 15:26:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-490) Domain Management Role Based
	Access Control
In-Reply-To: <JIRA.12444306.1313084297000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12444306.1313084297000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12444306.1313084297000.262.1381605995526@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-490:
----------------------------------

    Git Pull Request:   (was: https://github.com/wildfly/wildfly/pull/5267)

    
> Domain Management Role Based Access Control
> -------------------------------------------
>
>                 Key: WFLY-490
>                 URL: https://issues.jboss.org/browse/WFLY-490
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>              Labels: Authorization
>             Fix For: 8.0.0.CR1
>
>
> Implement some coarse permissions for domain operations.  Possibly allowing a break down for subsystem, profile, server, server-group - maybe read - write - execute. 
> Also consider confidentiality in exchange e.g. Can read metrics over http but must use https to add new server.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 12 17:42:36 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Sat, 12 Oct 2013 17:42:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2278) Deployer can't modify data
 source when datasources set as application resources
In-Reply-To: <JIRA.12502701.1381412857000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502701.1381412857000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502701.1381412857000.286.1381614156057@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813744#comment-12813744 ] 

RH Bugzilla Integration commented on WFLY-2278:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1017786|https://bugzilla.redhat.com/show_bug.cgi?id=1017786] from NEW to POST
                
> Deployer can't modify data source when datasources set as application resources
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-2278
>                 URL: https://issues.jboss.org/browse/WFLY-2278
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Brian Stansberry
>              Labels: rbac-filed-by-qa
>
> When data sources are made application resources, deployer should be able to modify them. This doesn't work, as opposed to e.g. mail sessions. For example:
> {code}
> /core-service=management/access=authorization/constraint=application-classification/type=datasources/classification=data-source:write-attribute(name=configured-application, value=true)
> {"outcome" => "success"}
> [standalone at localhost:9990 /] /subsystem=datasources/data-source=ExampleDS:write-attribute(name=jndi-name, value="java:jboss/datasources/ExampleDS_XXX"){roles=deployer}
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS013456: Unauthorized to execute operation 'write-attribute' for resource '[
>     (\"subsystem\" => \"datasources\"),
>     (\"data-source\" => \"ExampleDS\")
> ]' -- \"JBAS013475: Permission denied\"",
>     "rolled-back" => true
> }
> [standalone at localhost:9990 /] /core-service=management/access=authorization/constraint=application-classification/type=mail/classification=mail-session:write-attribute(name=configured-application, value=true)
> {"outcome" => "success"}
> [standalone at localhost:9990 /] /subsystem=mail/mail-session=java\:jboss\/mail\/Default:write-attribute(name=jndi-name, value="java:jboss/mail/Default_XXX"){roles=deployer} 
> {
>     "outcome" => "success",
>     "response-headers" => {
>         "operation-requires-reload" => true,
>         "process-state" => "reload-required"
>     }
> }
> {code}
> I have a test case for this as a last commit in my branch https://github.com/Ladicek/wildfly/commits/rbac (that is the commit called _RBAC test case for application types_).
> Brian, in case you are not the right assignee, please reassign.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 12 17:46:35 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Sat, 12 Oct 2013 17:46:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2278) Deployer can't modify data
 source when datasources set as application resources
In-Reply-To: <JIRA.12502701.1381412857000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502701.1381412857000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502701.1381412857000.289.1381614395967@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813745#comment-12813745 ] 

RH Bugzilla Integration commented on WFLY-2278:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> made a comment on [bug 1017786|https://bugzilla.redhat.com/show_bug.cgi?id=1017786]

The fix resolves the issue with the CLI, but I see that in the console the Deployer role still doesn't have permissions. The output of the access control metadata is correct though; the deployer role has write perms for all non-sensitive attributes and execute perms for all operations.
                
> Deployer can't modify data source when datasources set as application resources
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-2278
>                 URL: https://issues.jboss.org/browse/WFLY-2278
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Brian Stansberry
>              Labels: rbac-filed-by-qa
>
> When data sources are made application resources, deployer should be able to modify them. This doesn't work, as opposed to e.g. mail sessions. For example:
> {code}
> /core-service=management/access=authorization/constraint=application-classification/type=datasources/classification=data-source:write-attribute(name=configured-application, value=true)
> {"outcome" => "success"}
> [standalone at localhost:9990 /] /subsystem=datasources/data-source=ExampleDS:write-attribute(name=jndi-name, value="java:jboss/datasources/ExampleDS_XXX"){roles=deployer}
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS013456: Unauthorized to execute operation 'write-attribute' for resource '[
>     (\"subsystem\" => \"datasources\"),
>     (\"data-source\" => \"ExampleDS\")
> ]' -- \"JBAS013475: Permission denied\"",
>     "rolled-back" => true
> }
> [standalone at localhost:9990 /] /core-service=management/access=authorization/constraint=application-classification/type=mail/classification=mail-session:write-attribute(name=configured-application, value=true)
> {"outcome" => "success"}
> [standalone at localhost:9990 /] /subsystem=mail/mail-session=java\:jboss\/mail\/Default:write-attribute(name=jndi-name, value="java:jboss/mail/Default_XXX"){roles=deployer} 
> {
>     "outcome" => "success",
>     "response-headers" => {
>         "operation-requires-reload" => true,
>         "process-state" => "reload-required"
>     }
> }
> {code}
> I have a test case for this as a last commit in my branch https://github.com/Ladicek/wildfly/commits/rbac (that is the commit called _RBAC test case for application types_).
> Brian, in case you are not the right assignee, please reassign.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Oct 13 19:57:35 2013
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Sun, 13 Oct 2013 19:57:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-140) Java Authentication Service
 Provider Interface for Containers 1.1 (JSR-196)
In-Reply-To: <JIRA.12498523.1376434986000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498523.1376434986000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498523.1376434986000.410.1381708655537@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBEE-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan reassigned JBEE-140:
-----------------------------------

    Assignee: Stefan Guilhen  (was: Shelly McGowan)


The JASPIC API signature tests pass after merging pull request #2 for the JavaDoc updates.  However, there are still JavaDoc WARNings seen during JavaDoc generation.  I'll attach an output of the WARNings as well as the generated JavaDoc against current master, v 1.0.0.Beta1-SNAPSHOT for your reference.
                
> Java Authentication Service Provider Interface for Containers 1.1 (JSR-196)
> ---------------------------------------------------------------------------
>
>                 Key: JBEE-140
>                 URL: https://issues.jboss.org/browse/JBEE-140
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Sub-task
>          Components: jboss-jaspi-api
>            Reporter: Shelly McGowan
>            Assignee: Stefan Guilhen
>             Fix For: JavaEE 7 Spec APIs 1.0.0.Beta1
>
>
> Updates needed for JASPIC 1.1.
> See linked issue.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Oct 13 19:59:35 2013
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Sun, 13 Oct 2013 19:59:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-140) Java Authentication Service
 Provider Interface for Containers 1.1 (JSR-196)
In-Reply-To: <JIRA.12498523.1376434986000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498523.1376434986000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498523.1376434986000.413.1381708775552@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBEE-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBEE-140:
--------------------------------

    Attachment: javadoc-warnings.txt
                jboss-jaspi-api_1.1_spec-1.0.0.Beta1-SNAPSHOT-javadoc.jar

    
> Java Authentication Service Provider Interface for Containers 1.1 (JSR-196)
> ---------------------------------------------------------------------------
>
>                 Key: JBEE-140
>                 URL: https://issues.jboss.org/browse/JBEE-140
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Sub-task
>          Components: jboss-jaspi-api
>            Reporter: Shelly McGowan
>            Assignee: Stefan Guilhen
>             Fix For: JavaEE 7 Spec APIs 1.0.0.Beta1
>
>         Attachments: javadoc-warnings.txt, jboss-jaspi-api_1.1_spec-1.0.0.Beta1-SNAPSHOT-javadoc.jar
>
>
> Updates needed for JASPIC 1.1.
> See linked issue.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Oct 13 20:20:35 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Sun, 13 Oct 2013 20:20:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2278) Deployer can't modify data
 source when datasources set as application resources
In-Reply-To: <JIRA.12502701.1381412857000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502701.1381412857000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502701.1381412857000.418.1381710035561@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813769#comment-12813769 ] 

RH Bugzilla Integration commented on WFLY-2278:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1017786|https://bugzilla.redhat.com/show_bug.cgi?id=1017786] from POST to MODIFIED
                
> Deployer can't modify data source when datasources set as application resources
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-2278
>                 URL: https://issues.jboss.org/browse/WFLY-2278
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Brian Stansberry
>              Labels: rbac-filed-by-qa
>
> When data sources are made application resources, deployer should be able to modify them. This doesn't work, as opposed to e.g. mail sessions. For example:
> {code}
> /core-service=management/access=authorization/constraint=application-classification/type=datasources/classification=data-source:write-attribute(name=configured-application, value=true)
> {"outcome" => "success"}
> [standalone at localhost:9990 /] /subsystem=datasources/data-source=ExampleDS:write-attribute(name=jndi-name, value="java:jboss/datasources/ExampleDS_XXX"){roles=deployer}
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS013456: Unauthorized to execute operation 'write-attribute' for resource '[
>     (\"subsystem\" => \"datasources\"),
>     (\"data-source\" => \"ExampleDS\")
> ]' -- \"JBAS013475: Permission denied\"",
>     "rolled-back" => true
> }
> [standalone at localhost:9990 /] /core-service=management/access=authorization/constraint=application-classification/type=mail/classification=mail-session:write-attribute(name=configured-application, value=true)
> {"outcome" => "success"}
> [standalone at localhost:9990 /] /subsystem=mail/mail-session=java\:jboss\/mail\/Default:write-attribute(name=jndi-name, value="java:jboss/mail/Default_XXX"){roles=deployer} 
> {
>     "outcome" => "success",
>     "response-headers" => {
>         "operation-requires-reload" => true,
>         "process-state" => "reload-required"
>     }
> }
> {code}
> I have a test case for this as a last commit in my branch https://github.com/Ladicek/wildfly/commits/rbac (that is the commit called _RBAC test case for application types_).
> Brian, in case you are not the right assignee, please reassign.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 14 02:34:35 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Mon, 14 Oct 2013 02:34:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2278) Deployer can't modify data
 source when datasources set as application resources
In-Reply-To: <JIRA.12502701.1381412857000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502701.1381412857000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502701.1381412857000.524.1381732475627@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813784#comment-12813784 ] 

Ladislav Thon commented on WFLY-2278:
-------------------------------------

If the console still has a problem, do we want to file a HAL issue? Or is it enough to cc [~heiko.braun]?
                
> Deployer can't modify data source when datasources set as application resources
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-2278
>                 URL: https://issues.jboss.org/browse/WFLY-2278
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Brian Stansberry
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.CR1
>
>
> When data sources are made application resources, deployer should be able to modify them. This doesn't work, as opposed to e.g. mail sessions. For example:
> {code}
> /core-service=management/access=authorization/constraint=application-classification/type=datasources/classification=data-source:write-attribute(name=configured-application, value=true)
> {"outcome" => "success"}
> [standalone at localhost:9990 /] /subsystem=datasources/data-source=ExampleDS:write-attribute(name=jndi-name, value="java:jboss/datasources/ExampleDS_XXX"){roles=deployer}
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS013456: Unauthorized to execute operation 'write-attribute' for resource '[
>     (\"subsystem\" => \"datasources\"),
>     (\"data-source\" => \"ExampleDS\")
> ]' -- \"JBAS013475: Permission denied\"",
>     "rolled-back" => true
> }
> [standalone at localhost:9990 /] /core-service=management/access=authorization/constraint=application-classification/type=mail/classification=mail-session:write-attribute(name=configured-application, value=true)
> {"outcome" => "success"}
> [standalone at localhost:9990 /] /subsystem=mail/mail-session=java\:jboss\/mail\/Default:write-attribute(name=jndi-name, value="java:jboss/mail/Default_XXX"){roles=deployer} 
> {
>     "outcome" => "success",
>     "response-headers" => {
>         "operation-requires-reload" => true,
>         "process-state" => "reload-required"
>     }
> }
> {code}
> I have a test case for this as a last commit in my branch https://github.com/Ladicek/wildfly/commits/rbac (that is the commit called _RBAC test case for application types_).
> Brian, in case you are not the right assignee, please reassign.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 14 02:38:36 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Mon, 14 Oct 2013 02:38:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2278) Deployer can't modify data
 source when datasources set as application resources
In-Reply-To: <JIRA.12502701.1381412857000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502701.1381412857000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502701.1381412857000.538.1381732716871@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813787#comment-12813787 ] 

Heiko Braun commented on WFLY-2278:
-----------------------------------

See https://issues.jboss.org/browse/HAL-273
                
> Deployer can't modify data source when datasources set as application resources
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-2278
>                 URL: https://issues.jboss.org/browse/WFLY-2278
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Brian Stansberry
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.CR1
>
>
> When data sources are made application resources, deployer should be able to modify them. This doesn't work, as opposed to e.g. mail sessions. For example:
> {code}
> /core-service=management/access=authorization/constraint=application-classification/type=datasources/classification=data-source:write-attribute(name=configured-application, value=true)
> {"outcome" => "success"}
> [standalone at localhost:9990 /] /subsystem=datasources/data-source=ExampleDS:write-attribute(name=jndi-name, value="java:jboss/datasources/ExampleDS_XXX"){roles=deployer}
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS013456: Unauthorized to execute operation 'write-attribute' for resource '[
>     (\"subsystem\" => \"datasources\"),
>     (\"data-source\" => \"ExampleDS\")
> ]' -- \"JBAS013475: Permission denied\"",
>     "rolled-back" => true
> }
> [standalone at localhost:9990 /] /core-service=management/access=authorization/constraint=application-classification/type=mail/classification=mail-session:write-attribute(name=configured-application, value=true)
> {"outcome" => "success"}
> [standalone at localhost:9990 /] /subsystem=mail/mail-session=java\:jboss\/mail\/Default:write-attribute(name=jndi-name, value="java:jboss/mail/Default_XXX"){roles=deployer} 
> {
>     "outcome" => "success",
>     "response-headers" => {
>         "operation-requires-reload" => true,
>         "process-state" => "reload-required"
>     }
> }
> {code}
> I have a test case for this as a last commit in my branch https://github.com/Ladicek/wildfly/commits/rbac (that is the commit called _RBAC test case for application types_).
> Brian, in case you are not the right assignee, please reassign.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 14 03:17:35 2013
From: jira-events at lists.jboss.org (Matti Linnanvuori (JIRA))
Date: Mon, 14 Oct 2013 03:17:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2280) Wrong XA Datasource selected
In-Reply-To: <JIRA.12502716.1381418849000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502716.1381418849000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502716.1381418849000.562.1381735055730@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813791#comment-12813791 ] 

Matti Linnanvuori commented on WFLY-2280:
-----------------------------------------

I started a forum thread:
https://community.jboss.org/thread/233509
                
> Wrong XA Datasource selected
> ----------------------------
>
>                 Key: WFLY-2280
>                 URL: https://issues.jboss.org/browse/WFLY-2280
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>         Environment: Wildfly 8, Debian Linux
>            Reporter: Matti Linnanvuori
>            Assignee: Scott Marlow
>
> A wrong XA datasource OperationalDS instead of specified FrontendDS is chosen for a database query.
> ESC[0mESC[33m10:53:47,089 WARN  [com.arjuna.ats.jta] (default task-24) ARJUNA016089: TransactionImple.enlistResource - xa_start  - caught: XAException.XAER_INVAL for < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff90cae62c:4e8567e5:5256b6f0:2894, node_name=1, branch_uid=0:ffff90cae62c:4e8567e5:5256b6f0:2899, subordinatenodename=null, eis_name=java:/OperationalDS >: com.mysql.jdbc.jdbc2.optional.MysqlXAException: XAER_INVAL: Invalid arguments (or unsupported command)
>         at com.mysql.jdbc.jdbc2.optional.MysqlXAConnection.mapXAExceptionFromSQLException(MysqlXAConnection.java:600) [mysql-connector-java-5.1.26-bin.jar:]
>         at com.mysql.jdbc.jdbc2.optional.MysqlXAConnection.dispatchCommand(MysqlXAConnection.java:583) [mysql-connector-java-5.1.26-bin.jar:]
>         at com.mysql.jdbc.jdbc2.optional.MysqlXAConnection.start(MysqlXAConnection.java:523) [mysql-connector-java-5.1.26-bin.jar:]
>         at org.jboss.jca.adapters.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:259)
>         at org.jboss.jca.core.tx.jbossts.XAResourceWrapperImpl.start(XAResourceWrapperImpl.java:191)
>         at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:715) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
>         at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:397) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
>         at org.jboss.jca.core.connectionmanager.listener.TxConnectionListener$TransactionSynchronization.enlist(TxConnectionListener.java:607)
>         at org.jboss.jca.core.connectionmanager.listener.TxConnectionListener.enlist(TxConnectionListener.java:265)
>         at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.managedConnectionReconnected(TxConnectionManagerImpl.java:467)
>         at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.reconnectManagedConnection(AbstractConnectionManager.java:599)
>         at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:467)
>         at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:139)
>         at org.hibernate.engine.jdbc.connections.internal.DatasourceConnectionProviderImpl.getConnection(DatasourceConnectionProviderImpl.java:138) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.internal.AbstractSessionImpl$NonContextualJdbcConnectionAccess.obtainConnection(AbstractSessionImpl.java:359) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.LogicalConnectionImpl.obtainConnection(LogicalConnectionImpl.java:227) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.LogicalConnectionImpl.getConnection(LogicalConnectionImpl.java:170) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.StatementPreparerImpl.connection(StatementPreparerImpl.java:63) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.StatementPreparerImpl$5.doPrepare(StatementPreparerImpl.java:164) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.StatementPreparerImpl$StatementPreparationTemplate.prepareStatement(StatementPreparerImpl.java:185) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.jdbc.internal.StatementPreparerImpl.prepareQueryStatement(StatementPreparerImpl.java:162) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1859) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1836) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1813) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.doQuery(Loader.java:895) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:340) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.doList(Loader.java:2523) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.doList(Loader.java:2509) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2339) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.Loader.list(Loader.java:2334) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:491) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:369) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:222) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1270) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.internal.QueryImpl.list(QueryImpl.java:101) [hibernate-core-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at org.hibernate.jpa.internal.QueryImpl.getSingleResult(QueryImpl.java:381) [hibernate-entitymanager-4.3.0.Beta3.jar:4.3.0.Beta3]
>         at com.ecolane.mpk.frontend.beans.FrontendLiaisonBean.getOurFeService(FrontendLiaisonBean.java:123) [k3-main.jar:]
>         at com.ecolane.mpk.frontend.beans.FrontendLiaisonBean.synchOneCustomerToFrontend(FrontendLiaisonBean.java:362) [k3-main.jar:]
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_03]
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_03]
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_03]
>         at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_03]
>         at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
>         at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:130) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:138) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
>         at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
>         at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:251) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:342) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:90) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:55)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
>         at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:419)
>         at org.wildfly.security.manager.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
>         at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_03]
>         at org.jboss.invocation.PrivilegedInterceptor.processInvocation(PrivilegedInterceptor.java:75)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
>         at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72)
>         at com.ecolane.mpk.frontend.beans.FrontendLiaisonLocal$$$view296.synchOneCustomerToFrontend(Unknown Source) [k3-main.jar:]
>         at com.ecolane.mpk.apps.beans.ToolBackendBean.synchOneCustomerToFrontend(ToolBackendBean.java:717) [k3-main.jar:]
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_03]
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_03]
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_03]
>         at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_03]
>         at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
>         at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:130) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:138) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
>         at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
>         at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:251) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:342) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
>     @PersistenceContext(unitName=K3Configuration.PERSISTENCE_CONTEXT_FRONTEND_NAME)
>     private transient EntityManager entityManager;
>                 <xa-datasource jndi-name="java:/FrontendDS" pool-name="MpkDemoUsFrontendDS" enabled="true">
>                     <xa-datasource-property name="ServerName">
>                         localhost
>                     </xa-datasource-property>
>                     <xa-datasource-property name="DatabaseName">
>                         production
>                     </xa-datasource-property>
>                     <driver>mysql</driver>
>                     <security>
>                         <user-name>frontend</user-name>
>                         <password>fghfghfghfh</password>
>                     </security>
>                 </xa-datasource>
> <?xml version="1.0" encoding="UTF-8"?>
> <persistence xmlns="http://java.sun.com/xml/ns/persistence"
>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>     xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd"
>     version="2.0">
>     <persistence-unit name="k3_frontend_persistence" transaction-type="JTA">
>         <jta-data-source>@DATASOURCE_FRONTEND@</jta-data-source>
>         <shared-cache-mode>ENABLE_SELECTIVE</shared-cache-mode>
>                 <properties>
>             <property name="hibernate.dialect" value="com.ecolane.mpk.persistence.util.Mysql5BitBooleanInnoDBDialect" />
>                         <property name="jboss.entity.manager.jndi.name" value="K3FrontendEntityManager" />
>                         <property name="jboss.entity.manager.factory.jndi.name"
>                                 value="K3FrontendEntityManagerFactory" />
>             <property name="hibernate.hbm2ddl.auto" value="validate"/>
>             
>             <!-- Infinispan conf -->
>             <property name="hibernate.cache.use_second_level_cache" value="true"/>
>             <property name="hibernate.cache.use_query_cache" value="true"/>
> <!--             <property name="hibernate.cache.region.factory_class" -->
> />
>             <property name="hibernate.cache.use_query_cache" value="true"/>
> <!--             <property name="hibernate.cache.region.factory_class" -->
> <!--                 value="org.hibernate.cache.infinispan.JndiInfinispanRegionFactory"/> -->
> <!--             <property name="hibernate.cache.region.factory_class" -->
> <!--                 value="org.hibernate.cache.infinispan.InfinispanRegionFactory"/> -->
> <!--             <property name="hibernate.cache.infinispan.cfg" value="infinispan-configs.xml" />   -->
> <!--             <property name="hibernate.cache.infinispan.cachemanager" value="java:CacheManager/entity"/> -->
>             <property name="hibernate.generate_statistics" value="true" />
> <!--             <property name="hibernate.cache.use_structured_entries" value="false" /> -->
>             <!-- property name="hibernate.cache.infinispan.statistics" value="true"/-->
> <!--             <property name="hibernate.transaction.manager_lookup_class" -->
> <!--                 value="org.hibernate.transaction.JBossTransactionManagerLookup"/> -->
>                 </properties>
>         </persistence-unit>
> </persistence>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 14 03:29:35 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 14 Oct 2013 03:29:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2093) No any log generated after
 changing periodic-rotating-file-handler to size-rotating-file-handler
In-Reply-To: <JIRA.12500810.1379401775000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500810.1379401775000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500810.1379401775000.572.1381735775668@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813793#comment-12813793 ] 

RH Bugzilla Integration commented on WFLY-2093:
-----------------------------------------------

xiaohui Wu <xiwu at redhat.com> made a comment on [bug 1008806|https://bugzilla.redhat.com/show_bug.cgi?id=1008806]

These lines are generated by logging system automatically after modified the handler from size-rotating-file-handler to periodic-rotating-file-handler or vice versa. I  modified these handlers several times from one to another. But did not touch the logging.properties file.
                
> No any log generated after changing periodic-rotating-file-handler to size-rotating-file-handler
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2093
>                 URL: https://issues.jboss.org/browse/WFLY-2093
>             Project: WildFly
>          Issue Type: Bug
>          Components: Logging
>            Reporter: Xiaohui Wu
>            Assignee: James Perkins
>
> There is no any log in the server.log after changing periodic-rotating-file-handler to size-rotating-file-handler.
> The reproduce steps:
> 1. remove the part periodic-rotating-file-handler in standalone.xml
>             <periodic-rotating-file-handler name="FILE">
>                 <formatter>
>                     <pattern-formatter pattern="%d{HH:mm:ss.SSS} %-5p [%c] (%t) %s%E%n"/>
>                 </formatter>
>                 <file relative-to="jboss.server.log.dir" path="server.log"/>
>                 <suffix value=".yyyy-MM-dd"/>
>                 <append value="true"/>
>             </periodic-rotating-file-handler>
> 2. add one size-rotating-file-handler
>             <size-rotating-file-handler name="FILE" autoflush="true">
>                 <formatter>
>                     <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p (%c) [%t] %s%E%n"/>
>                 </formatter>
>                 <file relative-to="jboss.server.log.dir" path="server.log"/>
>                 <rotate-size value="500k"/>
>                 <max-backup-index value="15"/>
>                 <append value="true"/>
>             </size-rotating-file-handler>
> 3. start the jboss server, then you will see there is a warning in the server.log and no any further logs in the server.log.
> 13:23:28,205 WARN  [org.jboss.as.logging] (Controller Boot Thread) JBAS011511: Replacing handler 'FILE' during add operation. Either the handler type or the module name differs from the initial configuration.
> The possible fix: 
> https://issues.jboss.org/browse/WFLY-178 the code change is in https://github.com/wildfly/wildfly/pull/4137 
> and the bugzilla is in EAP6.1.0: 
> https://bugzilla.redhat.com/show_bug.cgi?id=918103
> But this issue still exists in 6.1.1
> Best Regards,
> Vicky

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 14 04:16:36 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 14 Oct 2013 04:16:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-169) Evaluator 'str' does not
 work wit logical or
In-Reply-To: <JIRA.12494317.1371223916000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494317.1371223916000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494317.1371223916000.606.1381738596949@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813798#comment-12813798 ] 

RH Bugzilla Integration commented on DROOLS-169:
------------------------------------------------

Tomas Schlosser <tschloss at redhat.com> changed the Status of [bug 971282|https://bugzilla.redhat.com/show_bug.cgi?id=971282] from ON_QA to VERIFIED
                
> Evaluator 'str' does not work wit logical or
> --------------------------------------------
>
>                 Key: DROOLS-169
>                 URL: https://issues.jboss.org/browse/DROOLS-169
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>             Fix For: 6.0.0.Beta4
>
>
> The str custom evaluator when used in conjuction of other constraints connected with logical or, like in the following example:
> {code}
> RoutingMessage( routingValue == "R2" || routingValue str[startsWith] "R1" )
> {code}
> throws a ClassCastException when evaluated.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 14 04:16:37 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 14 Oct 2013 04:16:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-169) Evaluator 'str' does not
 work wit logical or
In-Reply-To: <JIRA.12494317.1371223916000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494317.1371223916000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494317.1371223916000.608.1381738597072@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813799#comment-12813799 ] 

RH Bugzilla Integration commented on DROOLS-169:
------------------------------------------------

Tomas Schlosser <tschloss at redhat.com> made a comment on [bug 971282|https://bugzilla.redhat.com/show_bug.cgi?id=971282]

Verified in BRMS.6.0.0.ER4
                
> Evaluator 'str' does not work wit logical or
> --------------------------------------------
>
>                 Key: DROOLS-169
>                 URL: https://issues.jboss.org/browse/DROOLS-169
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>             Fix For: 6.0.0.Beta4
>
>
> The str custom evaluator when used in conjuction of other constraints connected with logical or, like in the following example:
> {code}
> RoutingMessage( routingValue == "R2" || routingValue str[startsWith] "R1" )
> {code}
> throws a ClassCastException when evaluated.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 14 04:37:35 2013
From: jira-events at lists.jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Petrovick=C3=BD_=28JIRA=29?=)
Date: Mon, 14 Oct 2013 04:37:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-298) kie-ci support for custom
 location of m2 local repository
In-Reply-To: <JIRA.12502855.1381515583000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502855.1381515583000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502855.1381515583000.644.1381739855583@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813801#comment-12813801 ] 

Luk?? Petrovick? commented on DROOLS-298:
-----------------------------------------

This issue is actually a bit more severe than it seems:

1) When "user.home" property is not set (for whatever reason), MavenRepository may fail with an obscure exception:

java.lang.NoClassDefFoundError: Could not initialize class org.kie.scanner.MavenRepository
	at org.kie.scanner.ArtifactResolver.getMavenProjectForGAV(ArtifactResolver.java:78)

2) You will get the same exception when the POM you're trying to parse cannot be parsed. (Or when some of the dependencies cannot be located.) This comes from the way how .embedder.MavenProjectLoader parses the POM - when the parsing fails in the static inner class, you won't find out why (the POM error), you just get the above.

3) You should be able to provide a settings.xml to the parser; since that is (AFAIK) the only way to tell Maven that you have additional repositories with additional dependencies. (Think in-house applications.)
                
> kie-ci support for custom location of m2 local repository
> ---------------------------------------------------------
>
>                 Key: DROOLS-298
>                 URL: https://issues.jboss.org/browse/DROOLS-298
>             Project: Drools
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>            Reporter: Maciej Swiderski
>            Assignee: Mario Fusco
>
> currently kie-ci assumes that local m2 repo is stored in ~/.m2/repository which is not always the case as it can be configured via settings.xml. This is common case in many organization due to limitations of data that can be stored in user home directory or backup routines. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Mon Oct 14 06:11:35 2013
From: jira-events at lists.jboss.org (Bartosz Baranowski (JIRA))
Date: Mon, 14 Oct 2013 06:11:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-261) Add way to properly parse JNDI
 urls in AS codebase
In-Reply-To: <JIRA.12489917.1366378061000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489917.1366378061000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489917.1366378061000.757.1381745495923@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bartosz Baranowski updated WFLY-261:
------------------------------------

    Git Pull Request: https://github.com/wildfly/wildfly/pull/5207  (was: https://github.com/wildfly/wildfly/pull/5094)

    
> Add way to properly parse JNDI urls in AS codebase
> --------------------------------------------------
>
>                 Key: WFLY-261
>                 URL: https://issues.jboss.org/browse/WFLY-261
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Naming
>            Reporter: Bartosz Baranowski
>            Assignee: Bartosz Baranowski
>             Fix For: 8.0.0.CR1
>
>
> This is a followup of  AS7-2138. Original code, in case no URL context threw NamingException. The  AS7-2138  introduced a fallback to NamingContext in case AS7 does not provide custom hack for url( like EJB ). However the fallback did not fail with NamingException in case it did not locate Context. This essentially made it go knee deep into AS7 service lookups, which hides real cause of failure.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 14 06:37:35 2013
From: jira-events at lists.jboss.org (Harald Pehl (JIRA))
Date: Mon, 14 Oct 2013 06:37:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2295) Role mappings created through
 the CLI do not use formal role names
In-Reply-To: <JIRA.12502938.1381747044732@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502938.1381747044732@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502938.1381747044732.799.1381747055476@jira02.app.mwc.hst.phx2.redhat.com>

Harald Pehl created WFLY-2295:
---------------------------------

             Summary: Role mappings created through the CLI do not use formal role names
                 Key: WFLY-2295
                 URL: https://issues.jboss.org/browse/WFLY-2295
             Project: WildFly
          Issue Type: Bug
          Components: Domain Management
            Reporter: Harald Pehl
            Assignee: Brian Stansberry


When creating a role mapping through the CLI using a non-formal role name like "AUDITOR", that role name is used as-is in the persistent configuration: 

{code}
cd /core-service=management/access=authorization
/role-mapping=AUDITOR:add
./role-mapping=AUDITOR/include=johndoe:add(name=johndoe,type=user)
{code}

The persistent configuration should map non-formal role names to formal role names, as other management clients (the console) rely on the formal names.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 14 06:39:35 2013
From: jira-events at lists.jboss.org (Harald Pehl (JIRA))
Date: Mon, 14 Oct 2013 06:39:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2295) Role mappings created through
 the CLI do not use formal role names
In-Reply-To: <JIRA.12502938.1381747044000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502938.1381747044000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502938.1381747044000.803.1381747175587@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Harald Pehl updated WFLY-2295:
------------------------------

    Description: 
When creating a role mapping through the CLI using a non-formal role name like "AUDITOR", that role name is used as-is in the persistent configuration: 

{code}
cd /core-service=management/access=authorization
./role-mapping=AUDITOR:add
./role-mapping=AUDITOR/include=johndoe:add(name=johndoe,type=user)
{code}

The persistent configuration should map non-formal role names to formal role names, as other management clients (the console) rely on the formal names.

  was:
When creating a role mapping through the CLI using a non-formal role name like "AUDITOR", that role name is used as-is in the persistent configuration: 

{code}
cd /core-service=management/access=authorization
/role-mapping=AUDITOR:add
./role-mapping=AUDITOR/include=johndoe:add(name=johndoe,type=user)
{code}

The persistent configuration should map non-formal role names to formal role names, as other management clients (the console) rely on the formal names.


    
> Role mappings created through the CLI do not use formal role names
> ------------------------------------------------------------------
>
>                 Key: WFLY-2295
>                 URL: https://issues.jboss.org/browse/WFLY-2295
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Harald Pehl
>            Assignee: Brian Stansberry
>
> When creating a role mapping through the CLI using a non-formal role name like "AUDITOR", that role name is used as-is in the persistent configuration: 
> {code}
> cd /core-service=management/access=authorization
> ./role-mapping=AUDITOR:add
> ./role-mapping=AUDITOR/include=johndoe:add(name=johndoe,type=user)
> {code}
> The persistent configuration should map non-formal role names to formal role names, as other management clients (the console) rely on the formal names.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 14 06:41:35 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 14 Oct 2013 06:41:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2295) Role mappings created through
 the CLI do not use formal role names
In-Reply-To: <JIRA.12502938.1381747044000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502938.1381747044000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502938.1381747044000.812.1381747295595@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2295:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1018738

    
> Role mappings created through the CLI do not use formal role names
> ------------------------------------------------------------------
>
>                 Key: WFLY-2295
>                 URL: https://issues.jboss.org/browse/WFLY-2295
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Harald Pehl
>            Assignee: Brian Stansberry
>
> When creating a role mapping through the CLI using a non-formal role name like "AUDITOR", that role name is used as-is in the persistent configuration: 
> {code}
> cd /core-service=management/access=authorization
> ./role-mapping=AUDITOR:add
> ./role-mapping=AUDITOR/include=johndoe:add(name=johndoe,type=user)
> {code}
> The persistent configuration should map non-formal role names to formal role names, as other management clients (the console) rely on the formal names.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 14 06:43:35 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 14 Oct 2013 06:43:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2295) Role mappings created through
 the CLI do not use formal role names
In-Reply-To: <JIRA.12502938.1381747044000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502938.1381747044000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502938.1381747044000.817.1381747415526@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse reassigned WFLY-2295:
--------------------------------------

    Assignee: Darran Lofthouse  (was: Brian Stansberry)

    
> Role mappings created through the CLI do not use formal role names
> ------------------------------------------------------------------
>
>                 Key: WFLY-2295
>                 URL: https://issues.jboss.org/browse/WFLY-2295
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Harald Pehl
>            Assignee: Darran Lofthouse
>
> When creating a role mapping through the CLI using a non-formal role name like "AUDITOR", that role name is used as-is in the persistent configuration: 
> {code}
> cd /core-service=management/access=authorization
> ./role-mapping=AUDITOR:add
> ./role-mapping=AUDITOR/include=johndoe:add(name=johndoe,type=user)
> {code}
> The persistent configuration should map non-formal role names to formal role names, as other management clients (the console) rely on the formal names.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 14 06:47:35 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 14 Oct 2013 06:47:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2295) Role mappings created through
 the CLI do not use formal role names
In-Reply-To: <JIRA.12502938.1381747044000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502938.1381747044000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502938.1381747044000.821.1381747655542@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved WFLY-2295.
------------------------------------

    Fix Version/s: 8.0.0.CR1
       Resolution: Duplicate Issue


For WFLY-2270 the underlying issue there was that role mappings could exist that do not correspond to either a standard role or to a scoped role, the solution on that issue is: -
 - Only accept role mappings where the name specified is equal using a case sensitive comparison to either a standard role or to a previously defined scoped role.
 - At the same time we will also prevent the removal of a scoped role if the role mapping still exists.

As a result it will no longer be possible to define roles in the CLI that do not use the formal role names.

                
> Role mappings created through the CLI do not use formal role names
> ------------------------------------------------------------------
>
>                 Key: WFLY-2295
>                 URL: https://issues.jboss.org/browse/WFLY-2295
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Harald Pehl
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> When creating a role mapping through the CLI using a non-formal role name like "AUDITOR", that role name is used as-is in the persistent configuration: 
> {code}
> cd /core-service=management/access=authorization
> ./role-mapping=AUDITOR:add
> ./role-mapping=AUDITOR/include=johndoe:add(name=johndoe,type=user)
> {code}
> The persistent configuration should map non-formal role names to formal role names, as other management clients (the console) rely on the formal names.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 14 07:11:35 2013
From: jira-events at lists.jboss.org (R Searls (JIRA))
Date: Mon, 14 Oct 2013 07:11:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-703) Valve configuration for EJB3
 Webservice Endpoints
In-Reply-To: <JIRA.12469749.1341217769000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12469749.1341217769000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12469749.1341217769000.894.1381749095775@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

R Searls reassigned WFLY-703:
-----------------------------

    Assignee: R Searls

    
> Valve configuration for EJB3 Webservice Endpoints
> -------------------------------------------------
>
>                 Key: WFLY-703
>                 URL: https://issues.jboss.org/browse/WFLY-703
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web Services
>            Reporter: Sebastian Maurer
>            Assignee: R Searls
>             Fix For: Awaiting Volunteers
>
>
> Please add a way to configure valves for EJB3 endpoints packaged in an ejb-jar.
> At the moment theres no option in any of the ejb deployment descriptors and of course it isn't possible to configure valves globally.
> The only way to configure valves is in the jboss-web.xml which is only available for web archives.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 14 07:21:36 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 14 Oct 2013 07:21:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2093) No any log generated after
 changing periodic-rotating-file-handler to size-rotating-file-handler
In-Reply-To: <JIRA.12500810.1379401775000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500810.1379401775000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500810.1379401775000.960.1381749696008@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813836#comment-12813836 ] 

RH Bugzilla Integration commented on WFLY-2093:
-----------------------------------------------

Josef Cacek <jcacek at redhat.com> made a comment on [bug 1008806|https://bugzilla.redhat.com/show_bug.cgi?id=1008806]

Verified in 6.2.0.ER5.
                
> No any log generated after changing periodic-rotating-file-handler to size-rotating-file-handler
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2093
>                 URL: https://issues.jboss.org/browse/WFLY-2093
>             Project: WildFly
>          Issue Type: Bug
>          Components: Logging
>            Reporter: Xiaohui Wu
>            Assignee: James Perkins
>
> There is no any log in the server.log after changing periodic-rotating-file-handler to size-rotating-file-handler.
> The reproduce steps:
> 1. remove the part periodic-rotating-file-handler in standalone.xml
>             <periodic-rotating-file-handler name="FILE">
>                 <formatter>
>                     <pattern-formatter pattern="%d{HH:mm:ss.SSS} %-5p [%c] (%t) %s%E%n"/>
>                 </formatter>
>                 <file relative-to="jboss.server.log.dir" path="server.log"/>
>                 <suffix value=".yyyy-MM-dd"/>
>                 <append value="true"/>
>             </periodic-rotating-file-handler>
> 2. add one size-rotating-file-handler
>             <size-rotating-file-handler name="FILE" autoflush="true">
>                 <formatter>
>                     <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p (%c) [%t] %s%E%n"/>
>                 </formatter>
>                 <file relative-to="jboss.server.log.dir" path="server.log"/>
>                 <rotate-size value="500k"/>
>                 <max-backup-index value="15"/>
>                 <append value="true"/>
>             </size-rotating-file-handler>
> 3. start the jboss server, then you will see there is a warning in the server.log and no any further logs in the server.log.
> 13:23:28,205 WARN  [org.jboss.as.logging] (Controller Boot Thread) JBAS011511: Replacing handler 'FILE' during add operation. Either the handler type or the module name differs from the initial configuration.
> The possible fix: 
> https://issues.jboss.org/browse/WFLY-178 the code change is in https://github.com/wildfly/wildfly/pull/4137 
> and the bugzilla is in EAP6.1.0: 
> https://bugzilla.redhat.com/show_bug.cgi?id=918103
> But this issue still exists in 6.1.1
> Best Regards,
> Vicky

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 14 07:21:36 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 14 Oct 2013 07:21:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2093) No any log generated after
 changing periodic-rotating-file-handler to size-rotating-file-handler
In-Reply-To: <JIRA.12500810.1379401775000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500810.1379401775000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500810.1379401775000.966.1381749696266@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813837#comment-12813837 ] 

RH Bugzilla Integration commented on WFLY-2093:
-----------------------------------------------

Josef Cacek <jcacek at redhat.com> changed the Status of [bug 1008806|https://bugzilla.redhat.com/show_bug.cgi?id=1008806] from ON_QA to VERIFIED
                
> No any log generated after changing periodic-rotating-file-handler to size-rotating-file-handler
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2093
>                 URL: https://issues.jboss.org/browse/WFLY-2093
>             Project: WildFly
>          Issue Type: Bug
>          Components: Logging
>            Reporter: Xiaohui Wu
>            Assignee: James Perkins
>
> There is no any log in the server.log after changing periodic-rotating-file-handler to size-rotating-file-handler.
> The reproduce steps:
> 1. remove the part periodic-rotating-file-handler in standalone.xml
>             <periodic-rotating-file-handler name="FILE">
>                 <formatter>
>                     <pattern-formatter pattern="%d{HH:mm:ss.SSS} %-5p [%c] (%t) %s%E%n"/>
>                 </formatter>
>                 <file relative-to="jboss.server.log.dir" path="server.log"/>
>                 <suffix value=".yyyy-MM-dd"/>
>                 <append value="true"/>
>             </periodic-rotating-file-handler>
> 2. add one size-rotating-file-handler
>             <size-rotating-file-handler name="FILE" autoflush="true">
>                 <formatter>
>                     <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p (%c) [%t] %s%E%n"/>
>                 </formatter>
>                 <file relative-to="jboss.server.log.dir" path="server.log"/>
>                 <rotate-size value="500k"/>
>                 <max-backup-index value="15"/>
>                 <append value="true"/>
>             </size-rotating-file-handler>
> 3. start the jboss server, then you will see there is a warning in the server.log and no any further logs in the server.log.
> 13:23:28,205 WARN  [org.jboss.as.logging] (Controller Boot Thread) JBAS011511: Replacing handler 'FILE' during add operation. Either the handler type or the module name differs from the initial configuration.
> The possible fix: 
> https://issues.jboss.org/browse/WFLY-178 the code change is in https://github.com/wildfly/wildfly/pull/4137 
> and the bugzilla is in EAP6.1.0: 
> https://bugzilla.redhat.com/show_bug.cgi?id=918103
> But this issue still exists in 6.1.1
> Best Regards,
> Vicky

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 14 07:45:35 2013
From: jira-events at lists.jboss.org (Radim Vansa (JIRA))
Date: Mon, 14 Oct 2013 07:45:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1675) Threads stuck in
 FlowControl.decrementIfEnoughCredits
In-Reply-To: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498385.1376295331000.1025.1381751135752@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radim Vansa updated JGRP-1675:
------------------------------

    Summary: Threads stuck in FlowControl.decrementIfEnoughCredits  (was: CreditRequest in FlowControl is not OOB)

    
> Threads stuck in FlowControl.decrementIfEnoughCredits
> -----------------------------------------------------
>
>                 Key: JGRP-1675
>                 URL: https://issues.jboss.org/browse/JGRP-1675
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> I have recently observed a repeated situation where many (or all) threads have been stuck waiting for credits in FlowControl protocol.
> The credit request was not handled on the other node as this is non-oob message and some (actually many of them - cause unknown) messages before the request have been lost - therefore the request was waiting for them to be re-sent.
> However, these have not been re-sent properly as the retransmission request was not received - all OOB threads were stuck in the FlowControl protocol as these handled some other request and tried to send a response - but the response could not be sent until FlowControl gets the credits.
> The probability of such situation could be lowered by tagging the credit request to be OOB - then it would be handled immediately. If the credit replenish message would then be processed in regular OOB pool, this could get already depleted by many requests, but setting up the internal thread pool would solve the problem.
> Other consideration would be to allow releasing thread from FlowControl (let it send the message even without credits) if it waits there for too long.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 14 07:51:35 2013
From: jira-events at lists.jboss.org (Radim Vansa (JIRA))
Date: Mon, 14 Oct 2013 07:51:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1675) Threads stuck in
 FlowControl.decrementIfEnoughCredits
In-Reply-To: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498385.1376295331000.1097.1381751495996@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radim Vansa updated JGRP-1675:
------------------------------

    Description: 
I have recently observed a repeated situation where many (or all) threads have been stuck waiting for credits in FlowControl protocol.

The credit request was not handled on the other node as this is non-oob message and some (actually many of them - cause unknown) messages before the request have been lost - therefore the request was waiting for them to be re-sent.

However, these have not been re-sent properly as the retransmission request was not received - all OOB threads were stuck in the FlowControl protocol as these handled some other request and tried to send a response - but the response could not be sent until FlowControl gets the credits.

The probability of such situation could be lowered by tagging the credit request to be OOB - then it would be handled immediately. If the credit replenish message would then be processed in regular OOB pool, this could get already depleted by many requests, but setting up the internal thread pool would solve the problem.

Other consideration would be to allow releasing thread from FlowControl (let it send the message even without credits) if it waits there for too long.

h3. Workaround
It appears that setting MFC and UFC max_credits to 10M or removing these protocols at all is a workaround for this issue.

  was:
I have recently observed a repeated situation where many (or all) threads have been stuck waiting for credits in FlowControl protocol.

The credit request was not handled on the other node as this is non-oob message and some (actually many of them - cause unknown) messages before the request have been lost - therefore the request was waiting for them to be re-sent.

However, these have not been re-sent properly as the retransmission request was not received - all OOB threads were stuck in the FlowControl protocol as these handled some other request and tried to send a response - but the response could not be sent until FlowControl gets the credits.

The probability of such situation could be lowered by tagging the credit request to be OOB - then it would be handled immediately. If the credit replenish message would then be processed in regular OOB pool, this could get already depleted by many requests, but setting up the internal thread pool would solve the problem.

Other consideration would be to allow releasing thread from FlowControl (let it send the message even without credits) if it waits there for too long.


    
> Threads stuck in FlowControl.decrementIfEnoughCredits
> -----------------------------------------------------
>
>                 Key: JGRP-1675
>                 URL: https://issues.jboss.org/browse/JGRP-1675
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> I have recently observed a repeated situation where many (or all) threads have been stuck waiting for credits in FlowControl protocol.
> The credit request was not handled on the other node as this is non-oob message and some (actually many of them - cause unknown) messages before the request have been lost - therefore the request was waiting for them to be re-sent.
> However, these have not been re-sent properly as the retransmission request was not received - all OOB threads were stuck in the FlowControl protocol as these handled some other request and tried to send a response - but the response could not be sent until FlowControl gets the credits.
> The probability of such situation could be lowered by tagging the credit request to be OOB - then it would be handled immediately. If the credit replenish message would then be processed in regular OOB pool, this could get already depleted by many requests, but setting up the internal thread pool would solve the problem.
> Other consideration would be to allow releasing thread from FlowControl (let it send the message even without credits) if it waits there for too long.
> h3. Workaround
> It appears that setting MFC and UFC max_credits to 10M or removing these protocols at all is a workaround for this issue.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 14 07:51:36 2013
From: jira-events at lists.jboss.org (Radim Vansa (JIRA))
Date: Mon, 14 Oct 2013 07:51:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1675) Threads stuck in
 FlowControl.decrementIfEnoughCredits
In-Reply-To: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498385.1376295331000.1112.1381751496717@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radim Vansa updated JGRP-1675:
------------------------------

    Description: 
I have recently observed a repeated situation where many (or all) threads have been stuck waiting for credits in FlowControl protocol.

The credit request was not handled on the other node as this is non-oob message and some (actually many of them - cause unknown) messages before the request have been lost - therefore the request was waiting for them to be re-sent.

However, these have not been re-sent properly as the retransmission request was not received - all OOB threads were stuck in the FlowControl protocol as these handled some other request and tried to send a response - but the response could not be sent until FlowControl gets the credits.

The probability of such situation could be lowered by tagging the credit request to be OOB - then it would be handled immediately. If the credit replenish message would then be processed in regular OOB pool, this could get already depleted by many requests, but setting up the internal thread pool would solve the problem.

Other consideration would be to allow releasing thread from FlowControl (let it send the message even without credits) if it waits there for too long.

h3. Workaround
It appears that setting MFC and UFC max_credits to 10M or removing these protocols at all is a workaround for this issue.

  was:
I have recently observed a repeated situation where many (or all) threads have been stuck waiting for credits in FlowControl protocol.

The credit request was not handled on the other node as this is non-oob message and some (actually many of them - cause unknown) messages before the request have been lost - therefore the request was waiting for them to be re-sent.

However, these have not been re-sent properly as the retransmission request was not received - all OOB threads were stuck in the FlowControl protocol as these handled some other request and tried to send a response - but the response could not be sent until FlowControl gets the credits.

The probability of such situation could be lowered by tagging the credit request to be OOB - then it would be handled immediately. If the credit replenish message would then be processed in regular OOB pool, this could get already depleted by many requests, but setting up the internal thread pool would solve the problem.

Other consideration would be to allow releasing thread from FlowControl (let it send the message even without credits) if it waits there for too long.


    
> Threads stuck in FlowControl.decrementIfEnoughCredits
> -----------------------------------------------------
>
>                 Key: JGRP-1675
>                 URL: https://issues.jboss.org/browse/JGRP-1675
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> I have recently observed a repeated situation where many (or all) threads have been stuck waiting for credits in FlowControl protocol.
> The credit request was not handled on the other node as this is non-oob message and some (actually many of them - cause unknown) messages before the request have been lost - therefore the request was waiting for them to be re-sent.
> However, these have not been re-sent properly as the retransmission request was not received - all OOB threads were stuck in the FlowControl protocol as these handled some other request and tried to send a response - but the response could not be sent until FlowControl gets the credits.
> The probability of such situation could be lowered by tagging the credit request to be OOB - then it would be handled immediately. If the credit replenish message would then be processed in regular OOB pool, this could get already depleted by many requests, but setting up the internal thread pool would solve the problem.
> Other consideration would be to allow releasing thread from FlowControl (let it send the message even without credits) if it waits there for too long.
> h3. Workaround
> It appears that setting MFC and UFC max_credits to 10M or removing these protocols at all is a workaround for this issue.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 14 07:51:36 2013
From: jira-events at lists.jboss.org (Radim Vansa (JIRA))
Date: Mon, 14 Oct 2013 07:51:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1675) Threads stuck in
 FlowControl.decrementIfEnoughCredits
In-Reply-To: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498385.1376295331000.1109.1381751496611@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radim Vansa updated JGRP-1675:
------------------------------

    Description: 
I have recently observed a repeated situation where many (or all) threads have been stuck waiting for credits in FlowControl protocol.

The credit request was not handled on the other node as this is non-oob message and some (actually many of them - cause unknown) messages before the request have been lost - therefore the request was waiting for them to be re-sent.

However, these have not been re-sent properly as the retransmission request was not received - all OOB threads were stuck in the FlowControl protocol as these handled some other request and tried to send a response - but the response could not be sent until FlowControl gets the credits.

The probability of such situation could be lowered by tagging the credit request to be OOB - then it would be handled immediately. If the credit replenish message would then be processed in regular OOB pool, this could get already depleted by many requests, but setting up the internal thread pool would solve the problem.

Other consideration would be to allow releasing thread from FlowControl (let it send the message even without credits) if it waits there for too long.

  was:
I have recently observed a repeated situation where many (or all) threads have been stuck waiting for credits in FlowControl protocol.

The credit request was not handled on the other node as this is non-oob message and some (actually many of them - cause unknown) messages before the request have been lost - therefore the request was waiting for them to be re-sent.

However, these have not been re-sent properly as the retransmission request was not received - all OOB threads were stuck in the FlowControl protocol as these handled some other request and tried to send a response - but the response could not be sent until FlowControl gets the credits.

The probability of such situation could be lowered by tagging the credit request to be OOB - then it would be handled immediately. If the credit replenish message would then be processed in regular OOB pool, this could get already depleted by many requests, but setting up the internal thread pool would solve the problem.

Other consideration would be to allow releasing thread from FlowControl (let it send the message even without credits) if it waits there for too long.

h3. Workaround
It appears that setting MFC and UFC max_credits to 10M or removing these protocols at all is a workaround for this issue.


    
> Threads stuck in FlowControl.decrementIfEnoughCredits
> -----------------------------------------------------
>
>                 Key: JGRP-1675
>                 URL: https://issues.jboss.org/browse/JGRP-1675
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> I have recently observed a repeated situation where many (or all) threads have been stuck waiting for credits in FlowControl protocol.
> The credit request was not handled on the other node as this is non-oob message and some (actually many of them - cause unknown) messages before the request have been lost - therefore the request was waiting for them to be re-sent.
> However, these have not been re-sent properly as the retransmission request was not received - all OOB threads were stuck in the FlowControl protocol as these handled some other request and tried to send a response - but the response could not be sent until FlowControl gets the credits.
> The probability of such situation could be lowered by tagging the credit request to be OOB - then it would be handled immediately. If the credit replenish message would then be processed in regular OOB pool, this could get already depleted by many requests, but setting up the internal thread pool would solve the problem.
> Other consideration would be to allow releasing thread from FlowControl (let it send the message even without credits) if it waits there for too long.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 14 07:51:36 2013
From: jira-events at lists.jboss.org (Radim Vansa (JIRA))
Date: Mon, 14 Oct 2013 07:51:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1675) Threads stuck in
 FlowControl.decrementIfEnoughCredits
In-Reply-To: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498385.1376295331000.1100.1381751496179@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radim Vansa updated JGRP-1675:
------------------------------

    Workaround Description: It appears that setting MFC and UFC max_credits to 10M or removing these protocols at all is a workaround for this issue.
                Workaround: Workaround Exists

    
> Threads stuck in FlowControl.decrementIfEnoughCredits
> -----------------------------------------------------
>
>                 Key: JGRP-1675
>                 URL: https://issues.jboss.org/browse/JGRP-1675
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> I have recently observed a repeated situation where many (or all) threads have been stuck waiting for credits in FlowControl protocol.
> The credit request was not handled on the other node as this is non-oob message and some (actually many of them - cause unknown) messages before the request have been lost - therefore the request was waiting for them to be re-sent.
> However, these have not been re-sent properly as the retransmission request was not received - all OOB threads were stuck in the FlowControl protocol as these handled some other request and tried to send a response - but the response could not be sent until FlowControl gets the credits.
> The probability of such situation could be lowered by tagging the credit request to be OOB - then it would be handled immediately. If the credit replenish message would then be processed in regular OOB pool, this could get already depleted by many requests, but setting up the internal thread pool would solve the problem.
> Other consideration would be to allow releasing thread from FlowControl (let it send the message even without credits) if it waits there for too long.
> h3. Workaround
> It appears that setting MFC and UFC max_credits to 10M or removing these protocols at all is a workaround for this issue.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 14 07:53:36 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 14 Oct 2013 07:53:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1675) Threads stuck in
 FlowControl.decrementIfEnoughCredits
In-Reply-To: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498385.1376295331000.1139.1381751616455@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated JGRP-1675:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1017376

    
> Threads stuck in FlowControl.decrementIfEnoughCredits
> -----------------------------------------------------
>
>                 Key: JGRP-1675
>                 URL: https://issues.jboss.org/browse/JGRP-1675
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> I have recently observed a repeated situation where many (or all) threads have been stuck waiting for credits in FlowControl protocol.
> The credit request was not handled on the other node as this is non-oob message and some (actually many of them - cause unknown) messages before the request have been lost - therefore the request was waiting for them to be re-sent.
> However, these have not been re-sent properly as the retransmission request was not received - all OOB threads were stuck in the FlowControl protocol as these handled some other request and tried to send a response - but the response could not be sent until FlowControl gets the credits.
> The probability of such situation could be lowered by tagging the credit request to be OOB - then it would be handled immediately. If the credit replenish message would then be processed in regular OOB pool, this could get already depleted by many requests, but setting up the internal thread pool would solve the problem.
> Other consideration would be to allow releasing thread from FlowControl (let it send the message even without credits) if it waits there for too long.
> h3. Workaround
> It appears that setting MFC and UFC max_credits to 10M or removing these protocols at all is a workaround for this issue.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 14 07:55:36 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 14 Oct 2013 07:55:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1675) Threads stuck in
 FlowControl.decrementIfEnoughCredits
In-Reply-To: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498385.1376295331000.1157.1381751736310@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813855#comment-12813855 ] 

RH Bugzilla Integration commented on JGRP-1675:
-----------------------------------------------

Martin Gencur <mgencur at redhat.com> made a comment on [bug 1017376|https://bugzilla.redhat.com/show_bug.cgi?id=1017376]

It appears that setting MFC and UFC max_credits to 10M or removing these protocols at all is a workaround for this issue. Removing this issues from Beta blockers as it has a workaround.
                
> Threads stuck in FlowControl.decrementIfEnoughCredits
> -----------------------------------------------------
>
>                 Key: JGRP-1675
>                 URL: https://issues.jboss.org/browse/JGRP-1675
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> I have recently observed a repeated situation where many (or all) threads have been stuck waiting for credits in FlowControl protocol.
> The credit request was not handled on the other node as this is non-oob message and some (actually many of them - cause unknown) messages before the request have been lost - therefore the request was waiting for them to be re-sent.
> However, these have not been re-sent properly as the retransmission request was not received - all OOB threads were stuck in the FlowControl protocol as these handled some other request and tried to send a response - but the response could not be sent until FlowControl gets the credits.
> The probability of such situation could be lowered by tagging the credit request to be OOB - then it would be handled immediately. If the credit replenish message would then be processed in regular OOB pool, this could get already depleted by many requests, but setting up the internal thread pool would solve the problem.
> Other consideration would be to allow releasing thread from FlowControl (let it send the message even without credits) if it waits there for too long.
> h3. Workaround
> It appears that setting MFC and UFC max_credits to 10M or removing these protocols at all is a workaround for this issue.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 14 07:55:36 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 14 Oct 2013 07:55:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2295) Role mappings created through
 the CLI do not use formal role names
In-Reply-To: <JIRA.12502938.1381747044000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502938.1381747044000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502938.1381747044000.1167.1381751736794@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2295:
------------------------------------------

        Bugzilla Update:   (was: Perform)
    Bugzilla References:   (was: https://bugzilla.redhat.com/show_bug.cgi?id=1018738)

    
> Role mappings created through the CLI do not use formal role names
> ------------------------------------------------------------------
>
>                 Key: WFLY-2295
>                 URL: https://issues.jboss.org/browse/WFLY-2295
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Harald Pehl
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> When creating a role mapping through the CLI using a non-formal role name like "AUDITOR", that role name is used as-is in the persistent configuration: 
> {code}
> cd /core-service=management/access=authorization
> ./role-mapping=AUDITOR:add
> ./role-mapping=AUDITOR/include=johndoe:add(name=johndoe,type=user)
> {code}
> The persistent configuration should map non-formal role names to formal role names, as other management clients (the console) rely on the formal names.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 14 07:55:36 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 14 Oct 2013 07:55:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2270) Attempt to remove scoped role
 current user is a member of results in failure.
In-Reply-To: <JIRA.12502541.1381314949000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502541.1381314949000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502541.1381314949000.1170.1381751736942@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2270:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1018738

    
> Attempt to remove scoped role current user is a member of results in failure.
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-2270
>                 URL: https://issues.jboss.org/browse/WFLY-2270
>             Project: WildFly
>          Issue Type: Sub-task
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Take the following scoped role definition and assignment: -
> {code}
>             <host-scoped-roles>
>                 <role name="master-Monitior" base-role="MONITOR">
>                     <host name="master"/>
>                 </role>
>             </host-scoped-roles>
> {code}
> {code}
>  <role name="master-Monitior" include-all="true"/>
> {code}
> Removal results in the following: -
> {code}
> [domain at localhost:9990 /] ./core-service=management/access=authorization/host-scoped-role=master-Monitior:remove
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "JBAS014749: Operation handler failed: JBAS013470: Unknown role 'MASTER-MONITIOR'"},
>     "rolled-back" => true
> }
> {code}
> Server side this is reported as: -
> {code}
> [Host Controller] 11:24:57,780 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014612: Operation ("remove") failed - address: ([
> [Host Controller]     ("core-service" => "management"),
> [Host Controller]     ("access" => "authorization"),
> [Host Controller]     ("host-scoped-role" => "master-Monitior")
> [Host Controller] ]): java.lang.IllegalArgumentException: JBAS013470: Unknown role 'MASTER-MONITIOR'
> [Host Controller] 	at org.jboss.as.controller.access.rbac.DefaultPermissionFactory.getUserPermissions(DefaultPermissionFactory.java:134) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.access.rbac.DefaultPermissionFactory.getUserPermissions(DefaultPermissionFactory.java:107) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.access.permission.ManagementPermissionAuthorizer.authorize(ManagementPermissionAuthorizer.java:99) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.access.management.DelegatingConfigurableAuthorizer.authorize(DelegatingConfigurableAuthorizer.java:98) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.OperationContextImpl.getBasicAuthorizationResponse(OperationContextImpl.java:1157) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1059) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.OperationContextImpl.readResourceFromRoot(OperationContextImpl.java:542) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationResolver.getServerOperations(ServerOperationResolver.java:232)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.getServerOperations(ServerOperationsResolverHandler.java:149)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.access$000(ServerOperationsResolverHandler.java:58)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler$2.getServerOperations(ServerOperationsResolverHandler.java:113)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.HostControllerExecutionSupport$Factory$DomainOpExecutionSupport.getServerOps(HostControllerExecutionSupport.java:265)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.execute(ServerOperationsResolverHandler.java:124)
> [Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:609) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:487) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:258) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:143) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:205) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:110) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:157) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:153) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_17]
> [Host Controller] 	at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_17]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [wildfly-protocol-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [wildfly-protocol-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> [Host Controller] 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> [Host Controller] 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> {code}
> At this point I believe that role removal is actually successful, however a subsequent operation is failing as the role previously associated with the user no longer exists.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 14 08:01:37 2013
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Mon, 14 Oct 2013 08:01:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2296) Patched state does is missing
 the updated resulting version
In-Reply-To: <JIRA.12502946.1381752036100@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502946.1381752036100@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502946.1381752036100.1187.1381752097776@jira02.app.mwc.hst.phx2.redhat.com>

Emanuel Muckenhuber created WFLY-2296:
-----------------------------------------

             Summary: Patched state does is missing the updated resulting version
                 Key: WFLY-2296
                 URL: https://issues.jboss.org/browse/WFLY-2296
             Project: WildFly
          Issue Type: Bug
          Components: Patching
    Affects Versions: 8.0.0.Beta1
            Reporter: Emanuel Muckenhuber
            Assignee: Emanuel Muckenhuber
             Fix For: 8.0.0.CR1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 14 08:01:38 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 14 Oct 2013 08:01:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2270) Lack of model integrity
 checking regarding role mappings, standard role names and scoped role names.
In-Reply-To: <JIRA.12502541.1381314949000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502541.1381314949000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502541.1381314949000.1197.1381752098216@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2270:
-----------------------------------

    Summary: Lack of model integrity checking regarding role mappings, standard role names and scoped role names.  (was: Attempt to remove scoped role current user is a member of results in failure.)

    
> Lack of model integrity checking regarding role mappings, standard role names and scoped role names.
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2270
>                 URL: https://issues.jboss.org/browse/WFLY-2270
>             Project: WildFly
>          Issue Type: Sub-task
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Take the following scoped role definition and assignment: -
> {code}
>             <host-scoped-roles>
>                 <role name="master-Monitior" base-role="MONITOR">
>                     <host name="master"/>
>                 </role>
>             </host-scoped-roles>
> {code}
> {code}
>  <role name="master-Monitior" include-all="true"/>
> {code}
> Removal results in the following: -
> {code}
> [domain at localhost:9990 /] ./core-service=management/access=authorization/host-scoped-role=master-Monitior:remove
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "JBAS014749: Operation handler failed: JBAS013470: Unknown role 'MASTER-MONITIOR'"},
>     "rolled-back" => true
> }
> {code}
> Server side this is reported as: -
> {code}
> [Host Controller] 11:24:57,780 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014612: Operation ("remove") failed - address: ([
> [Host Controller]     ("core-service" => "management"),
> [Host Controller]     ("access" => "authorization"),
> [Host Controller]     ("host-scoped-role" => "master-Monitior")
> [Host Controller] ]): java.lang.IllegalArgumentException: JBAS013470: Unknown role 'MASTER-MONITIOR'
> [Host Controller] 	at org.jboss.as.controller.access.rbac.DefaultPermissionFactory.getUserPermissions(DefaultPermissionFactory.java:134) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.access.rbac.DefaultPermissionFactory.getUserPermissions(DefaultPermissionFactory.java:107) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.access.permission.ManagementPermissionAuthorizer.authorize(ManagementPermissionAuthorizer.java:99) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.access.management.DelegatingConfigurableAuthorizer.authorize(DelegatingConfigurableAuthorizer.java:98) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.OperationContextImpl.getBasicAuthorizationResponse(OperationContextImpl.java:1157) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1059) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.OperationContextImpl.readResourceFromRoot(OperationContextImpl.java:542) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationResolver.getServerOperations(ServerOperationResolver.java:232)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.getServerOperations(ServerOperationsResolverHandler.java:149)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.access$000(ServerOperationsResolverHandler.java:58)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler$2.getServerOperations(ServerOperationsResolverHandler.java:113)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.HostControllerExecutionSupport$Factory$DomainOpExecutionSupport.getServerOps(HostControllerExecutionSupport.java:265)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.execute(ServerOperationsResolverHandler.java:124)
> [Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:609) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:487) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:258) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:143) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:205) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:110) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:157) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:153) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_17]
> [Host Controller] 	at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_17]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [wildfly-protocol-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [wildfly-protocol-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> [Host Controller] 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> [Host Controller] 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> {code}
> At this point I believe that role removal is actually successful, however a subsequent operation is failing as the role previously associated with the user no longer exists.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 14 08:01:38 2013
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Mon, 14 Oct 2013 08:01:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2296) Patched state is missing the
 updated resulting version
In-Reply-To: <JIRA.12502946.1381752036000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502946.1381752036000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502946.1381752036000.1194.1381752098070@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emanuel Muckenhuber updated WFLY-2296:
--------------------------------------

    Summary: Patched state is missing the updated resulting version  (was: Patched state does is missing the updated resulting version)

    
> Patched state is missing the updated resulting version
> ------------------------------------------------------
>
>                 Key: WFLY-2296
>                 URL: https://issues.jboss.org/browse/WFLY-2296
>             Project: WildFly
>          Issue Type: Bug
>          Components: Patching
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Emanuel Muckenhuber
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 14 08:08:35 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 14 Oct 2013 08:08:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1341) Missing charset-related paths
	from sun.jdk
In-Reply-To: <JIRA.12491807.1368584295000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12491807.1368584295000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12491807.1368584295000.1225.1381752515970@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813863#comment-12813863 ] 

RH Bugzilla Integration commented on WFLY-1341:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 959478|https://bugzilla.redhat.com/show_bug.cgi?id=959478] from ASSIGNED to MODIFIED
                
> Missing charset-related paths from sun.jdk
> ------------------------------------------
>
>                 Key: WFLY-1341
>                 URL: https://issues.jboss.org/browse/WFLY-1341
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Brad Maxwell
>            Assignee: David Lloyd
>             Fix For: 8.0.0.Alpha1
>
>
> The sun.jdk module needs the sun.nio.ext and sun.nio.cs packages to load charsets from application code properly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 14 08:58:35 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 14 Oct 2013 08:58:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-236) NPE when ksession is
 serialized with facts logically inserted
In-Reply-To: <JIRA.12499263.1377254187000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499263.1377254187000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499263.1377254187000.1627.1381755515719@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813875#comment-12813875 ] 

RH Bugzilla Integration commented on DROOLS-236:
------------------------------------------------

Tomas Schlosser <tschloss at redhat.com> changed the Status of [bug 1000384|https://bugzilla.redhat.com/show_bug.cgi?id=1000384] from ON_QA to VERIFIED
                
> NPE when ksession is serialized with facts logically inserted
> -------------------------------------------------------------
>
>                 Key: DROOLS-236
>                 URL: https://issues.jboss.org/browse/DROOLS-236
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.CR1
>            Reporter: Toshiya Kobayashi
>            Assignee: Edson Tirelli
>
> Reproduce steps:
> Assuming Employee is a subclass of Person...
> 1. Insert an Employee (say, 'Alice')
> 2. InsertLogical a Person (say, 'Bob')
> 3. Serialize and deserialize ksession
> 4. Insert an Employee (say, 'Claire')
> 5. Update 'Claire'
> It throws an NEP:
> {noformat}
> Exception executing consequence for rule "Promote" in defaultpkg: java.lang.NullPointerException
> 	at org.drools.core.runtime.rule.impl.DefaultConsequenceExceptionHandler.handleException(DefaultConsequenceExceptionHandler.java:39)
> 	at org.drools.core.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1026)
> ...
> Caused by: java.lang.NullPointerException
> 	at org.drools.core.common.NamedEntryPoint.update(NamedEntryPoint.java:434)
> 	at org.drools.core.base.DefaultKnowledgeHelper.update(DefaultKnowledgeHelper.java:367)
> 	at defaultpkg.Rule_Promote139773612.defaultConsequence(Rule_Promote139773612.java:9)
> 	at defaultpkg.Rule_Promote139773612DefaultConsequenceInvokerGenerated.evaluate(Unknown Source)
> 	at defaultpkg.Rule_Promote139773612DefaultConsequenceInvoker.evaluate(Unknown Source)
> 	at org.drools.core.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1016)
> 	... 37 more
> {noformat}
> In the step 2, ClassObjectTypeConf of Person[Bob] enables TMS. But at that time, Employee[Alice] creates its EqualityKey and put it to TMS.
> NamedEntryPoint.java:
> {code:java}
>     private void enableTMS(Object object, ObjectTypeConf conf) {
>         
>         final Rete source = this.ruleBase.getRete();
>         final ClassObjectType cot = new ClassObjectType( object.getClass() );
>         final Map<ObjectType, ObjectTypeNode> map = source.getObjectTypeNodes( EntryPointId.DEFAULT );
>         final ObjectTypeNode node = map.get( cot );
>         final ObjectHashSet memory = ((ObjectTypeNodeMemory) this.wm.getNodeMemory( node )).memory;
>       
>         // All objects of this type that are already there were certainly stated,
>         // since this method call happens at the first logical insert, for any given type.
>         org.drools.core.util.Iterator it = memory.iterator();
>         for ( Object obj = it.next(); obj != null; obj = it.next() ) {
>           
>             org.drools.core.util.ObjectHashSet.ObjectEntry holder = (org.drools.core.util.ObjectHashSet.ObjectEntry) obj;
>     
>             InternalFactHandle handle = (InternalFactHandle) holder.getValue();
>             
>             if ( handle != null) {
>                 EqualityKey key = new EqualityKey( handle );
>                 handle.setEqualityKey( key );
>                 key.setStatus(EqualityKey.STATED);
>                 getTruthMaintenanceSystem().put(key);
>             }
>         }
>       
>         // Enable TMS for this type.
>         conf.enableTMS();
>       
>     }
> {code}
> Then during deserialization, ProtobufInputMarshaller enables TMS for ClassObjectTypeConf of Employee[Alice] and ClassObjectTypeConf of Person[Bob]. 
> ProtobufInputMarshaller.java:
> {code:java}
>     public static void readTruthMaintenanceSystem( MarshallerReaderContext context, 
>                                                    RuleData _session ) throws IOException {
>         TruthMaintenanceSystem tms = context.wm.getTruthMaintenanceSystem();
>         ProtobufMessages.TruthMaintenanceSystem _tms = _session.getTms();
>         
>         for( ProtobufMessages.EqualityKey _key : _tms.getKeyList() ) {
>             InternalFactHandle handle = (InternalFactHandle) context.handles.get( _key.getHandleId() );
>             // ObjectTypeConf state is not marshalled, so it needs to be re-determined
>             ObjectTypeConf typeConf = context.wm.getObjectTypeConfigurationRegistry().getObjectTypeConf( ((NamedEntryPoint)handle.getEntryPoint()).getEntryPoint(),
>                                                                                                          handle.getObject() );
>             if (!typeConf.isTMSEnabled()) {
>                 typeConf.enableTMS();
>             }
> {code}
> Finally, Employee(Claire) is updated. ClassObjectTypeConf of Employee is under TMS but Claire doesn't have EqualityKey hence NPE is thrown.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 14 08:58:35 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 14 Oct 2013 08:58:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-236) NPE when ksession is
 serialized with facts logically inserted
In-Reply-To: <JIRA.12499263.1377254187000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499263.1377254187000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499263.1377254187000.1630.1381755515788@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813876#comment-12813876 ] 

RH Bugzilla Integration commented on DROOLS-236:
------------------------------------------------

Tomas Schlosser <tschloss at redhat.com> made a comment on [bug 1000384|https://bugzilla.redhat.com/show_bug.cgi?id=1000384]

Verified in BRMS.6.0.0.ER4
                
> NPE when ksession is serialized with facts logically inserted
> -------------------------------------------------------------
>
>                 Key: DROOLS-236
>                 URL: https://issues.jboss.org/browse/DROOLS-236
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.CR1
>            Reporter: Toshiya Kobayashi
>            Assignee: Edson Tirelli
>
> Reproduce steps:
> Assuming Employee is a subclass of Person...
> 1. Insert an Employee (say, 'Alice')
> 2. InsertLogical a Person (say, 'Bob')
> 3. Serialize and deserialize ksession
> 4. Insert an Employee (say, 'Claire')
> 5. Update 'Claire'
> It throws an NEP:
> {noformat}
> Exception executing consequence for rule "Promote" in defaultpkg: java.lang.NullPointerException
> 	at org.drools.core.runtime.rule.impl.DefaultConsequenceExceptionHandler.handleException(DefaultConsequenceExceptionHandler.java:39)
> 	at org.drools.core.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1026)
> ...
> Caused by: java.lang.NullPointerException
> 	at org.drools.core.common.NamedEntryPoint.update(NamedEntryPoint.java:434)
> 	at org.drools.core.base.DefaultKnowledgeHelper.update(DefaultKnowledgeHelper.java:367)
> 	at defaultpkg.Rule_Promote139773612.defaultConsequence(Rule_Promote139773612.java:9)
> 	at defaultpkg.Rule_Promote139773612DefaultConsequenceInvokerGenerated.evaluate(Unknown Source)
> 	at defaultpkg.Rule_Promote139773612DefaultConsequenceInvoker.evaluate(Unknown Source)
> 	at org.drools.core.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1016)
> 	... 37 more
> {noformat}
> In the step 2, ClassObjectTypeConf of Person[Bob] enables TMS. But at that time, Employee[Alice] creates its EqualityKey and put it to TMS.
> NamedEntryPoint.java:
> {code:java}
>     private void enableTMS(Object object, ObjectTypeConf conf) {
>         
>         final Rete source = this.ruleBase.getRete();
>         final ClassObjectType cot = new ClassObjectType( object.getClass() );
>         final Map<ObjectType, ObjectTypeNode> map = source.getObjectTypeNodes( EntryPointId.DEFAULT );
>         final ObjectTypeNode node = map.get( cot );
>         final ObjectHashSet memory = ((ObjectTypeNodeMemory) this.wm.getNodeMemory( node )).memory;
>       
>         // All objects of this type that are already there were certainly stated,
>         // since this method call happens at the first logical insert, for any given type.
>         org.drools.core.util.Iterator it = memory.iterator();
>         for ( Object obj = it.next(); obj != null; obj = it.next() ) {
>           
>             org.drools.core.util.ObjectHashSet.ObjectEntry holder = (org.drools.core.util.ObjectHashSet.ObjectEntry) obj;
>     
>             InternalFactHandle handle = (InternalFactHandle) holder.getValue();
>             
>             if ( handle != null) {
>                 EqualityKey key = new EqualityKey( handle );
>                 handle.setEqualityKey( key );
>                 key.setStatus(EqualityKey.STATED);
>                 getTruthMaintenanceSystem().put(key);
>             }
>         }
>       
>         // Enable TMS for this type.
>         conf.enableTMS();
>       
>     }
> {code}
> Then during deserialization, ProtobufInputMarshaller enables TMS for ClassObjectTypeConf of Employee[Alice] and ClassObjectTypeConf of Person[Bob]. 
> ProtobufInputMarshaller.java:
> {code:java}
>     public static void readTruthMaintenanceSystem( MarshallerReaderContext context, 
>                                                    RuleData _session ) throws IOException {
>         TruthMaintenanceSystem tms = context.wm.getTruthMaintenanceSystem();
>         ProtobufMessages.TruthMaintenanceSystem _tms = _session.getTms();
>         
>         for( ProtobufMessages.EqualityKey _key : _tms.getKeyList() ) {
>             InternalFactHandle handle = (InternalFactHandle) context.handles.get( _key.getHandleId() );
>             // ObjectTypeConf state is not marshalled, so it needs to be re-determined
>             ObjectTypeConf typeConf = context.wm.getObjectTypeConfigurationRegistry().getObjectTypeConf( ((NamedEntryPoint)handle.getEntryPoint()).getEntryPoint(),
>                                                                                                          handle.getObject() );
>             if (!typeConf.isTMSEnabled()) {
>                 typeConf.enableTMS();
>             }
> {code}
> Finally, Employee(Claire) is updated. ClassObjectTypeConf of Employee is under TMS but Claire doesn't have EqualityKey hence NPE is thrown.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 14 09:16:37 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 14 Oct 2013 09:16:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1914) Application client container
	doesn't start
In-Reply-To: <JIRA.12499060.1377081913000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499060.1377081913000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499060.1377081913000.1743.1381756597012@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813889#comment-12813889 ] 

RH Bugzilla Integration commented on WFLY-1914:
-----------------------------------------------

Aleksandar Kostadinov <akostadi at redhat.com> changed the Status of [bug 999465|https://bugzilla.redhat.com/show_bug.cgi?id=999465] from MODIFIED to VERIFIED
                
> Application client container doesn't start
> ------------------------------------------
>
>                 Key: WFLY-1914
>                 URL: https://issues.jboss.org/browse/WFLY-1914
>             Project: WildFly
>          Issue Type: Bug
>          Components: Application Client
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Beta1
>
>
> Application client container fails to start with the following exception:
> {code}
> 16:23:40,742 INFO  [org.jboss.as.jacorb] (MSC service thread 1-7) JBAS016328: CORBA Naming Service started
> 16:23:40,744 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("add") failed - address: ([
>     ("subsystem" => "naming"),
>     ("service" => "remote-naming")
> ]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.naming.remote is missing [jboss.remoting.endpoint.subsystem]"]}
> 16:23:40,779 INFO  [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.remoting.endpoint.subsystem (missing) dependents: [service jboss.naming.remote] 
> 16:23:40,782 ERROR [org.jboss.as] (Controller Boot Thread) JBAS015875: WildFly 8.0.0.Beta1-SNAPSHOT "WildFly" started (with errors) in 1471ms - Started 99 of 103 services (1 services failed or missing dependencies, 9 services are lazy, passive or on-demand)
> {code}
> when started using the following command:
> {code}
> JBOSS_HOME/bin/appclient.sh /foo/bar/some.jar
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 14 09:16:37 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 14 Oct 2013 09:16:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1914) Application client container
	doesn't start
In-Reply-To: <JIRA.12499060.1377081913000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499060.1377081913000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499060.1377081913000.1751.1381756597404@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813890#comment-12813890 ] 

RH Bugzilla Integration commented on WFLY-1914:
-----------------------------------------------

Aleksandar Kostadinov <akostadi at redhat.com> made a comment on [bug 999465|https://bugzilla.redhat.com/show_bug.cgi?id=999465]

I do not see the issue with ER5.
                
> Application client container doesn't start
> ------------------------------------------
>
>                 Key: WFLY-1914
>                 URL: https://issues.jboss.org/browse/WFLY-1914
>             Project: WildFly
>          Issue Type: Bug
>          Components: Application Client
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Beta1
>
>
> Application client container fails to start with the following exception:
> {code}
> 16:23:40,742 INFO  [org.jboss.as.jacorb] (MSC service thread 1-7) JBAS016328: CORBA Naming Service started
> 16:23:40,744 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("add") failed - address: ([
>     ("subsystem" => "naming"),
>     ("service" => "remote-naming")
> ]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.naming.remote is missing [jboss.remoting.endpoint.subsystem]"]}
> 16:23:40,779 INFO  [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.remoting.endpoint.subsystem (missing) dependents: [service jboss.naming.remote] 
> 16:23:40,782 ERROR [org.jboss.as] (Controller Boot Thread) JBAS015875: WildFly 8.0.0.Beta1-SNAPSHOT "WildFly" started (with errors) in 1471ms - Started 99 of 103 services (1 services failed or missing dependencies, 9 services are lazy, passive or on-demand)
> {code}
> when started using the following command:
> {code}
> JBOSS_HOME/bin/appclient.sh /foo/bar/some.jar
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 14 09:33:35 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Mon, 14 Oct 2013 09:33:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2297) Log reasons for implicit
	dependencies
In-Reply-To: <JIRA.12502954.1381757546745@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502954.1381757546745@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502954.1381757546745.1866.1381757615905@jira02.app.mwc.hst.phx2.redhat.com>

David Lloyd created WFLY-2297:
---------------------------------

             Summary: Log reasons for implicit dependencies
                 Key: WFLY-2297
                 URL: https://issues.jboss.org/browse/WFLY-2297
             Project: WildFly
          Issue Type: Enhancement
            Reporter: David Lloyd
            Priority: Minor
             Fix For: 9.0.0.CR1


We should log a {{DEBUG}} or {{TRACE}} message whenever we add an implicit dependency to a module, documenting the reason for the addition (e.g. adding because it's a servlet deployment, or because a particular annotation was used, etc.)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 14 10:27:36 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Mon, 14 Oct 2013 10:27:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-97) Object value passed to
 JBossLogManagerProvider.putMdc(String,
 Object) should be returned from getMdc(final String)
In-Reply-To: <JIRA.12502712.1381416719000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502712.1381416719000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502712.1381416719000.2076.1381760856470@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBLOGGING-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow reassigned JBLOGGING-97:
-------------------------------------

    Assignee: James Perkins  (was: David Lloyd)

    
> Object value passed to JBossLogManagerProvider.putMdc(String, Object) should be returned from getMdc(final String)
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBLOGGING-97
>                 URL: https://issues.jboss.org/browse/JBLOGGING-97
>             Project: JBoss Logging
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: slf4j-jboss-logmanager
>    Affects Versions: 3.1.3.GA
>            Reporter: Scott Marlow
>            Assignee: James Perkins
>            Priority: Blocker
>             Fix For: 3.1.4.GA
>
>
> Change JBossLogManagerProvider.putMdc(final String key, final Object value) to call MDC.put(key, value) instead of MDC.put(key, String.valueOf(value))

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 14 11:29:35 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Mon, 14 Oct 2013 11:29:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-298) kie-ci support for custom
 location of m2 local repository
In-Reply-To: <JIRA.12502855.1381515583000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502855.1381515583000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502855.1381515583000.2241.1381764575594@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-298.
--------------------------------

    Fix Version/s: 6.0.0.Final
       Resolution: Done


I also added the possibility to use a custom maven settings file by setting it in the property "kie.maven.settings.custom".
                
> kie-ci support for custom location of m2 local repository
> ---------------------------------------------------------
>
>                 Key: DROOLS-298
>                 URL: https://issues.jboss.org/browse/DROOLS-298
>             Project: Drools
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>            Reporter: Maciej Swiderski
>            Assignee: Mario Fusco
>             Fix For: 6.0.0.Final
>
>
> currently kie-ci assumes that local m2 repo is stored in ~/.m2/repository which is not always the case as it can be configured via settings.xml. This is common case in many organization due to limitations of data that can be stored in user home directory or backup routines. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 14 11:42:36 2013
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Mon, 14 Oct 2013 11:42:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2298) Redesign @Stateful EJB
	clustering
In-Reply-To: <JIRA.12502968.1381765293427@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502968.1381765293427@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502968.1381765293427.2264.1381765356097@jira02.app.mwc.hst.phx2.redhat.com>

Paul Ferraro created WFLY-2298:
----------------------------------

             Summary: Redesign @Stateful EJB clustering
                 Key: WFLY-2298
                 URL: https://issues.jboss.org/browse/WFLY-2298
             Project: WildFly
          Issue Type: Enhancement
          Components: Clustering
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro
             Fix For: 9.0.0.CR1


The current @Stateful EJB clustering design has a number of flaws:
* The current implementation is very slow.  Each EJB invocation results in 4 Infinispan transactions!  Cache.get(...) and Cache.release(...) result in 2 transactions each, 1 for bean cache and 1 for group cache
* An external locking mechanism is required to lock the SFSB against access from other nodes between Cache.get(...) and Cache.release(...)
* Because the current design uses 2 separate cache instances, data is not correctly isolated and can cause integrity issues
* The current design uses a global group cache, which results in classloader leaks when a server has multiple EJB deployments
* The lifecycle of the global group cache is not correctly handled by the MSC and is prone to race conditions
* State changes that occur to the SFSB during activation/passivation callbacks are not correctly replicated.
* The @Clustered annotation currently has 2 orthogonal meanings:
  - If applied to a @Stateful EJB, then a specific cache will be used (as defined by the EJB subsystem)
  - If applied to a @Stateless or @Stateful EJB, remote EJB clients will have a dynamic view of the EJB's topology.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 14 11:48:35 2013
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Mon, 14 Oct 2013 11:48:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2298) Redesign @Stateful EJB
	clustering
In-Reply-To: <JIRA.12502968.1381765293000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502968.1381765293000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502968.1381765293000.2271.1381765715980@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro updated WFLY-2298:
-------------------------------

    Description: 
The current @Stateful EJB clustering design has a number of flaws:
* The current implementation is very slow.  Each EJB invocation results in 4 Infinispan transactions!  Cache.get(...) and Cache.release(...) result in 2 transactions each, 1 for bean cache and 1 for group cache
* An external locking mechanism is required to lock the SFSB against access from other nodes between Cache.get(...) and Cache.release(...)
* Because the current design uses 2 separate cache instances, data is not correctly isolated and can cause integrity issues
* The current design uses a global group cache, which results in classloader leaks when a server has multiple EJB deployments
* The lifecycle of the global group cache is not correctly handled by the MSC and is prone to race conditions
* State changes that occur to the SFSB during activation/passivation callbacks are not correctly replicated.
* The @Clustered annotation currently has 2 orthogonal meanings:
    + If applied to a @Stateful EJB, then a specific cache will be used (as defined by the EJB subsystem)
    + If applied to a @Stateless or @Stateful EJB, remote EJB clients will have a dynamic view of the EJB's topology.

  was:
The current @Stateful EJB clustering design has a number of flaws:
* The current implementation is very slow.  Each EJB invocation results in 4 Infinispan transactions!  Cache.get(...) and Cache.release(...) result in 2 transactions each, 1 for bean cache and 1 for group cache
* An external locking mechanism is required to lock the SFSB against access from other nodes between Cache.get(...) and Cache.release(...)
* Because the current design uses 2 separate cache instances, data is not correctly isolated and can cause integrity issues
* The current design uses a global group cache, which results in classloader leaks when a server has multiple EJB deployments
* The lifecycle of the global group cache is not correctly handled by the MSC and is prone to race conditions
* State changes that occur to the SFSB during activation/passivation callbacks are not correctly replicated.
* The @Clustered annotation currently has 2 orthogonal meanings:
  - If applied to a @Stateful EJB, then a specific cache will be used (as defined by the EJB subsystem)
  - If applied to a @Stateless or @Stateful EJB, remote EJB clients will have a dynamic view of the EJB's topology.


    
> Redesign @Stateful EJB clustering
> ---------------------------------
>
>                 Key: WFLY-2298
>                 URL: https://issues.jboss.org/browse/WFLY-2298
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Clustering
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 9.0.0.CR1
>
>
> The current @Stateful EJB clustering design has a number of flaws:
> * The current implementation is very slow.  Each EJB invocation results in 4 Infinispan transactions!  Cache.get(...) and Cache.release(...) result in 2 transactions each, 1 for bean cache and 1 for group cache
> * An external locking mechanism is required to lock the SFSB against access from other nodes between Cache.get(...) and Cache.release(...)
> * Because the current design uses 2 separate cache instances, data is not correctly isolated and can cause integrity issues
> * The current design uses a global group cache, which results in classloader leaks when a server has multiple EJB deployments
> * The lifecycle of the global group cache is not correctly handled by the MSC and is prone to race conditions
> * State changes that occur to the SFSB during activation/passivation callbacks are not correctly replicated.
> * The @Clustered annotation currently has 2 orthogonal meanings:
>     + If applied to a @Stateful EJB, then a specific cache will be used (as defined by the EJB subsystem)
>     + If applied to a @Stateless or @Stateful EJB, remote EJB clients will have a dynamic view of the EJB's topology.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 14 11:48:36 2013
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Mon, 14 Oct 2013 11:48:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2298) Redesign @Stateful EJB
	clustering
In-Reply-To: <JIRA.12502968.1381765293000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502968.1381765293000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502968.1381765293000.2276.1381765716243@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro updated WFLY-2298:
-------------------------------

    Description: 
The current @Stateful EJB clustering design has a number of flaws:
* The current implementation is very slow.  Each EJB invocation results in 4 Infinispan transactions!  Cache.get(...) and Cache.release(...) result in 2 transactions each, 1 for bean cache and 1 for group cache
* An external locking mechanism is required to lock the SFSB against access from other nodes between Cache.get(...) and Cache.release(...)
* Because the current design uses 2 separate cache instances, data is not correctly isolated and can cause integrity issues
* The current design uses a global group cache, which results in classloader leaks when a server has multiple EJB deployments
* The lifecycle of the global group cache is not correctly handled by the MSC and is prone to race conditions
* State changes that occur to the SFSB during activation/passivation callbacks are not correctly replicated.
* The @Clustered annotation currently has 2 orthogonal meanings:
    * If applied to a @Stateful EJB, then a specific cache will be used (as defined by the EJB subsystem)
    * If applied to a @Stateless or @Stateful EJB, remote EJB clients will have a dynamic view of the EJB's topology.

  was:
The current @Stateful EJB clustering design has a number of flaws:
* The current implementation is very slow.  Each EJB invocation results in 4 Infinispan transactions!  Cache.get(...) and Cache.release(...) result in 2 transactions each, 1 for bean cache and 1 for group cache
* An external locking mechanism is required to lock the SFSB against access from other nodes between Cache.get(...) and Cache.release(...)
* Because the current design uses 2 separate cache instances, data is not correctly isolated and can cause integrity issues
* The current design uses a global group cache, which results in classloader leaks when a server has multiple EJB deployments
* The lifecycle of the global group cache is not correctly handled by the MSC and is prone to race conditions
* State changes that occur to the SFSB during activation/passivation callbacks are not correctly replicated.
* The @Clustered annotation currently has 2 orthogonal meanings:
    + If applied to a @Stateful EJB, then a specific cache will be used (as defined by the EJB subsystem)
    + If applied to a @Stateless or @Stateful EJB, remote EJB clients will have a dynamic view of the EJB's topology.


    
> Redesign @Stateful EJB clustering
> ---------------------------------
>
>                 Key: WFLY-2298
>                 URL: https://issues.jboss.org/browse/WFLY-2298
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Clustering
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 9.0.0.CR1
>
>
> The current @Stateful EJB clustering design has a number of flaws:
> * The current implementation is very slow.  Each EJB invocation results in 4 Infinispan transactions!  Cache.get(...) and Cache.release(...) result in 2 transactions each, 1 for bean cache and 1 for group cache
> * An external locking mechanism is required to lock the SFSB against access from other nodes between Cache.get(...) and Cache.release(...)
> * Because the current design uses 2 separate cache instances, data is not correctly isolated and can cause integrity issues
> * The current design uses a global group cache, which results in classloader leaks when a server has multiple EJB deployments
> * The lifecycle of the global group cache is not correctly handled by the MSC and is prone to race conditions
> * State changes that occur to the SFSB during activation/passivation callbacks are not correctly replicated.
> * The @Clustered annotation currently has 2 orthogonal meanings:
>     * If applied to a @Stateful EJB, then a specific cache will be used (as defined by the EJB subsystem)
>     * If applied to a @Stateless or @Stateful EJB, remote EJB clients will have a dynamic view of the EJB's topology.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 14 11:50:35 2013
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Mon, 14 Oct 2013 11:50:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2298) Redesign @Stateful EJB
	clustering
In-Reply-To: <JIRA.12502968.1381765293000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502968.1381765293000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502968.1381765293000.2279.1381765835551@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro updated WFLY-2298:
-------------------------------

    Description: 
The current @Stateful EJB clustering design has a number of flaws:
* The current implementation is very slow.  Each EJB invocation results in 4 Infinispan transactions!  Cache.get(...) and Cache.release(...) result in 2 transactions each, 1 for bean cache and 1 for group cache
* An external locking mechanism is required to lock the SFSB against access from other nodes between Cache.get(...) and Cache.release(...)
* Because the current design uses 2 separate cache instances, data is not correctly isolated and can cause integrity issues
* The current design uses a global group cache, which results in classloader leaks when a server has multiple EJB deployments
* The lifecycle of the global group cache is not correctly handled by the MSC and is prone to race conditions
* State changes that occur to the SFSB during activation/passivation callbacks are not correctly replicated.
* The @Clustered annotation currently has 2 orthogonal meanings:
	* If applied to a @Stateful EJB, then a specific cache will be used (as defined by the EJB subsystem)
	* If applied to a @Stateless or @Stateful EJB, remote EJB clients will have a dynamic view of the EJB's topology.

  was:
The current @Stateful EJB clustering design has a number of flaws:
* The current implementation is very slow.  Each EJB invocation results in 4 Infinispan transactions!  Cache.get(...) and Cache.release(...) result in 2 transactions each, 1 for bean cache and 1 for group cache
* An external locking mechanism is required to lock the SFSB against access from other nodes between Cache.get(...) and Cache.release(...)
* Because the current design uses 2 separate cache instances, data is not correctly isolated and can cause integrity issues
* The current design uses a global group cache, which results in classloader leaks when a server has multiple EJB deployments
* The lifecycle of the global group cache is not correctly handled by the MSC and is prone to race conditions
* State changes that occur to the SFSB during activation/passivation callbacks are not correctly replicated.
* The @Clustered annotation currently has 2 orthogonal meanings:
    * If applied to a @Stateful EJB, then a specific cache will be used (as defined by the EJB subsystem)
    * If applied to a @Stateless or @Stateful EJB, remote EJB clients will have a dynamic view of the EJB's topology.


    
> Redesign @Stateful EJB clustering
> ---------------------------------
>
>                 Key: WFLY-2298
>                 URL: https://issues.jboss.org/browse/WFLY-2298
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Clustering
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 9.0.0.CR1
>
>
> The current @Stateful EJB clustering design has a number of flaws:
> * The current implementation is very slow.  Each EJB invocation results in 4 Infinispan transactions!  Cache.get(...) and Cache.release(...) result in 2 transactions each, 1 for bean cache and 1 for group cache
> * An external locking mechanism is required to lock the SFSB against access from other nodes between Cache.get(...) and Cache.release(...)
> * Because the current design uses 2 separate cache instances, data is not correctly isolated and can cause integrity issues
> * The current design uses a global group cache, which results in classloader leaks when a server has multiple EJB deployments
> * The lifecycle of the global group cache is not correctly handled by the MSC and is prone to race conditions
> * State changes that occur to the SFSB during activation/passivation callbacks are not correctly replicated.
> * The @Clustered annotation currently has 2 orthogonal meanings:
> 	* If applied to a @Stateful EJB, then a specific cache will be used (as defined by the EJB subsystem)
> 	* If applied to a @Stateless or @Stateful EJB, remote EJB clients will have a dynamic view of the EJB's topology.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 14 11:50:35 2013
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Mon, 14 Oct 2013 11:50:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2298) Redesign @Stateful EJB
	clustering
In-Reply-To: <JIRA.12502968.1381765293000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502968.1381765293000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502968.1381765293000.2283.1381765835700@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro updated WFLY-2298:
-------------------------------

    Description: 
The current @Stateful EJB clustering design has a number of flaws:
* The current implementation is very slow.  Each EJB invocation results in 4 Infinispan transactions!  Cache.get(...) and Cache.release(...) result in 2 transactions each, 1 for bean cache and 1 for group cache
* An external locking mechanism is required to lock the SFSB against access from other nodes between Cache.get(...) and Cache.release(...)
* Because the current design uses 2 separate cache instances, data is not correctly isolated and can cause integrity issues
* The current design uses a global group cache, which results in classloader leaks when a server has multiple EJB deployments
* The lifecycle of the global group cache is not correctly handled by the MSC and is prone to race conditions
* State changes that occur to the SFSB during activation/passivation callbacks are not correctly replicated.
* The @Clustered annotation currently has 2 orthogonal meanings:
	1. If applied to a @Stateful EJB, then a specific cache will be used (as defined by the EJB subsystem)
	2. If applied to a @Stateless or @Stateful EJB, remote EJB clients will have a dynamic view of the EJB's topology.

  was:
The current @Stateful EJB clustering design has a number of flaws:
* The current implementation is very slow.  Each EJB invocation results in 4 Infinispan transactions!  Cache.get(...) and Cache.release(...) result in 2 transactions each, 1 for bean cache and 1 for group cache
* An external locking mechanism is required to lock the SFSB against access from other nodes between Cache.get(...) and Cache.release(...)
* Because the current design uses 2 separate cache instances, data is not correctly isolated and can cause integrity issues
* The current design uses a global group cache, which results in classloader leaks when a server has multiple EJB deployments
* The lifecycle of the global group cache is not correctly handled by the MSC and is prone to race conditions
* State changes that occur to the SFSB during activation/passivation callbacks are not correctly replicated.
* The @Clustered annotation currently has 2 orthogonal meanings:
	* If applied to a @Stateful EJB, then a specific cache will be used (as defined by the EJB subsystem)
	* If applied to a @Stateless or @Stateful EJB, remote EJB clients will have a dynamic view of the EJB's topology.


    
> Redesign @Stateful EJB clustering
> ---------------------------------
>
>                 Key: WFLY-2298
>                 URL: https://issues.jboss.org/browse/WFLY-2298
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Clustering
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 9.0.0.CR1
>
>
> The current @Stateful EJB clustering design has a number of flaws:
> * The current implementation is very slow.  Each EJB invocation results in 4 Infinispan transactions!  Cache.get(...) and Cache.release(...) result in 2 transactions each, 1 for bean cache and 1 for group cache
> * An external locking mechanism is required to lock the SFSB against access from other nodes between Cache.get(...) and Cache.release(...)
> * Because the current design uses 2 separate cache instances, data is not correctly isolated and can cause integrity issues
> * The current design uses a global group cache, which results in classloader leaks when a server has multiple EJB deployments
> * The lifecycle of the global group cache is not correctly handled by the MSC and is prone to race conditions
> * State changes that occur to the SFSB during activation/passivation callbacks are not correctly replicated.
> * The @Clustered annotation currently has 2 orthogonal meanings:
> 	1. If applied to a @Stateful EJB, then a specific cache will be used (as defined by the EJB subsystem)
> 	2. If applied to a @Stateless or @Stateful EJB, remote EJB clients will have a dynamic view of the EJB's topology.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 14 13:07:35 2013
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Mon, 14 Oct 2013 13:07:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2298) Redesign @Stateful EJB
	clustering
In-Reply-To: <JIRA.12502968.1381765293000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502968.1381765293000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502968.1381765293000.2511.1381770455477@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813973#comment-12813973 ] 

Paul Ferraro commented on WFLY-2298:
------------------------------------

Working branch:
https://github.com/pferraro/wildfly/tree/ejb
                
> Redesign @Stateful EJB clustering
> ---------------------------------
>
>                 Key: WFLY-2298
>                 URL: https://issues.jboss.org/browse/WFLY-2298
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Clustering
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 9.0.0.CR1
>
>
> The current @Stateful EJB clustering design has a number of flaws:
> * The current implementation is very slow.  Each EJB invocation results in 4 Infinispan transactions!  Cache.get(...) and Cache.release(...) result in 2 transactions each, 1 for bean cache and 1 for group cache
> * An external locking mechanism is required to lock the SFSB against access from other nodes between Cache.get(...) and Cache.release(...)
> * Because the current design uses 2 separate cache instances, data is not correctly isolated and can cause integrity issues
> * The current design uses a global group cache, which results in classloader leaks when a server has multiple EJB deployments
> * The lifecycle of the global group cache is not correctly handled by the MSC and is prone to race conditions
> * State changes that occur to the SFSB during activation/passivation callbacks are not correctly replicated.
> * The @Clustered annotation currently has 2 orthogonal meanings:
> 	1. If applied to a @Stateful EJB, then a specific cache will be used (as defined by the EJB subsystem)
> 	2. If applied to a @Stateless or @Stateful EJB, remote EJB clients will have a dynamic view of the EJB's topology.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 14 13:26:35 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Mon, 14 Oct 2013 13:26:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2298) Redesign @Stateful EJB
	clustering
In-Reply-To: <JIRA.12502968.1381765293000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502968.1381765293000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502968.1381765293000.2530.1381771595565@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813976#comment-12813976 ] 

David Lloyd commented on WFLY-2298:
-----------------------------------

If you want to discuss any of the finer points of lifecycle/invocation/etc., ping me any time.
                
> Redesign @Stateful EJB clustering
> ---------------------------------
>
>                 Key: WFLY-2298
>                 URL: https://issues.jboss.org/browse/WFLY-2298
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Clustering
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 9.0.0.CR1
>
>
> The current @Stateful EJB clustering design has a number of flaws:
> * The current implementation is very slow.  Each EJB invocation results in 4 Infinispan transactions!  Cache.get(...) and Cache.release(...) result in 2 transactions each, 1 for bean cache and 1 for group cache
> * An external locking mechanism is required to lock the SFSB against access from other nodes between Cache.get(...) and Cache.release(...)
> * Because the current design uses 2 separate cache instances, data is not correctly isolated and can cause integrity issues
> * The current design uses a global group cache, which results in classloader leaks when a server has multiple EJB deployments
> * The lifecycle of the global group cache is not correctly handled by the MSC and is prone to race conditions
> * State changes that occur to the SFSB during activation/passivation callbacks are not correctly replicated.
> * The @Clustered annotation currently has 2 orthogonal meanings:
> 	1. If applied to a @Stateful EJB, then a specific cache will be used (as defined by the EJB subsystem)
> 	2. If applied to a @Stateless or @Stateful EJB, remote EJB clients will have a dynamic view of the EJB's topology.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 14 13:55:35 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 14 Oct 2013 13:55:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2270) Lack of model integrity
 checking regarding role mappings, standard role names and scoped role names.
In-Reply-To: <JIRA.12502541.1381314949000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502541.1381314949000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502541.1381314949000.2590.1381773335885@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813982#comment-12813982 ] 

Darran Lofthouse commented on WFLY-2270:
----------------------------------------

Also adding the following checks: - 
 1 - Ensure a scoped role is not a duplicate, taking into account host scoped roles, server group scoped roles and the standard roles with a case insensitive check.
 2 - The base-role for a scoped role needs to be a standard role - if the user entered the role using an alternative case style it should be converted in the model to the formal style.

                
> Lack of model integrity checking regarding role mappings, standard role names and scoped role names.
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2270
>                 URL: https://issues.jboss.org/browse/WFLY-2270
>             Project: WildFly
>          Issue Type: Sub-task
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Take the following scoped role definition and assignment: -
> {code}
>             <host-scoped-roles>
>                 <role name="master-Monitior" base-role="MONITOR">
>                     <host name="master"/>
>                 </role>
>             </host-scoped-roles>
> {code}
> {code}
>  <role name="master-Monitior" include-all="true"/>
> {code}
> Removal results in the following: -
> {code}
> [domain at localhost:9990 /] ./core-service=management/access=authorization/host-scoped-role=master-Monitior:remove
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "JBAS014749: Operation handler failed: JBAS013470: Unknown role 'MASTER-MONITIOR'"},
>     "rolled-back" => true
> }
> {code}
> Server side this is reported as: -
> {code}
> [Host Controller] 11:24:57,780 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014612: Operation ("remove") failed - address: ([
> [Host Controller]     ("core-service" => "management"),
> [Host Controller]     ("access" => "authorization"),
> [Host Controller]     ("host-scoped-role" => "master-Monitior")
> [Host Controller] ]): java.lang.IllegalArgumentException: JBAS013470: Unknown role 'MASTER-MONITIOR'
> [Host Controller] 	at org.jboss.as.controller.access.rbac.DefaultPermissionFactory.getUserPermissions(DefaultPermissionFactory.java:134) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.access.rbac.DefaultPermissionFactory.getUserPermissions(DefaultPermissionFactory.java:107) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.access.permission.ManagementPermissionAuthorizer.authorize(ManagementPermissionAuthorizer.java:99) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.access.management.DelegatingConfigurableAuthorizer.authorize(DelegatingConfigurableAuthorizer.java:98) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.OperationContextImpl.getBasicAuthorizationResponse(OperationContextImpl.java:1157) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1059) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.OperationContextImpl.readResourceFromRoot(OperationContextImpl.java:542) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationResolver.getServerOperations(ServerOperationResolver.java:232)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.getServerOperations(ServerOperationsResolverHandler.java:149)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.access$000(ServerOperationsResolverHandler.java:58)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler$2.getServerOperations(ServerOperationsResolverHandler.java:113)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.HostControllerExecutionSupport$Factory$DomainOpExecutionSupport.getServerOps(HostControllerExecutionSupport.java:265)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.execute(ServerOperationsResolverHandler.java:124)
> [Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:609) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:487) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:258) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:143) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:205) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:110) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:157) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:153) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_17]
> [Host Controller] 	at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_17]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [wildfly-protocol-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [wildfly-protocol-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> [Host Controller] 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> [Host Controller] 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> {code}
> At this point I believe that role removal is actually successful, however a subsequent operation is failing as the role previously associated with the user no longer exists.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 14 14:26:35 2013
From: jira-events at lists.jboss.org (Pedro Igor (JIRA))
Date: Mon, 14 Oct 2013 14:26:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-140) Java Authentication Service
 Provider Interface for Containers 1.1 (JSR-196)
In-Reply-To: <JIRA.12498523.1376434986000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498523.1376434986000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498523.1376434986000.2679.1381775195562@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBEE-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12813987#comment-12813987 ] 

Pedro Igor commented on JBEE-140:
---------------------------------

Hi Shelly,

Sent a new PR with fixes for the javadoc warnings.

https://github.com/jboss/jboss-jaspi-api_spec/pull/3

Thanks.
  
                
> Java Authentication Service Provider Interface for Containers 1.1 (JSR-196)
> ---------------------------------------------------------------------------
>
>                 Key: JBEE-140
>                 URL: https://issues.jboss.org/browse/JBEE-140
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Sub-task
>          Components: jboss-jaspi-api
>            Reporter: Shelly McGowan
>            Assignee: Stefan Guilhen
>             Fix For: JavaEE 7 Spec APIs 1.0.0.Beta1
>
>         Attachments: javadoc-warnings.txt, jboss-jaspi-api_1.1_spec-1.0.0.Beta1-SNAPSHOT-javadoc.jar
>
>
> Updates needed for JASPIC 1.1.
> See linked issue.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 14 14:30:36 2013
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Mon, 14 Oct 2013 14:30:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-85) Allow MDC to support Object
	value types
In-Reply-To: <JIRA.12502996.1381775316573@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502996.1381775316573@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502996.1381775316573.2685.1381775436000@jira02.app.mwc.hst.phx2.redhat.com>

James Perkins created LOGMGR-85:
-----------------------------------

             Summary: Allow MDC to support Object value types
                 Key: LOGMGR-85
                 URL: https://issues.jboss.org/browse/LOGMGR-85
             Project: JBoss Log Manager
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: James Perkins
            Assignee: James Perkins
            Priority: Minor
             Fix For: 1.5.2.Final


MDC should allow for Object value types and defer converting to a string value until needed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 14 14:47:35 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Mon, 14 Oct 2013 14:47:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2299) SGSR permission are wrong on
	server-config
In-Reply-To: <JIRA.12502998.1381776373411@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502998.1381776373411@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502998.1381776373411.2719.1381776455514@jira02.app.mwc.hst.phx2.redhat.com>

Heiko Braun created WFLY-2299:
---------------------------------

             Summary: SGSR permission are wrong on server-config
                 Key: WFLY-2299
                 URL: https://issues.jboss.org/browse/WFLY-2299
             Project: WildFly
          Issue Type: Bug
          Components: Domain Management
            Reporter: Heiko Braun
            Assignee: Brian Stansberry
             Fix For: 8.0.0.CR1


IMO the permissons are wrong for server group scoped roles:

{noformat}
/host=master/server-config=*
    read-config:true
    write-config:false
{noformat}

With these settings a SGSR cannot add new server configurations, even for the group it's assigned to.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 14 14:51:36 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Mon, 14 Oct 2013 14:51:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2190) Priviledge alignment for
	scoped resources
In-Reply-To: <JIRA.12501904.1380621634000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501904.1380621634000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501904.1380621634000.2741.1381776696042@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun resolved WFLY-2190.
-------------------------------

    Resolution: Done

    
> Priviledge alignment for scoped resources
> -----------------------------------------
>
>                 Key: WFLY-2190
>                 URL: https://issues.jboss.org/browse/WFLY-2190
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> server-groups show different privildges for {{server-group=*}} and {{server-group=<specific instance>}}. when accessing these as a scoped role we use the <specific instance> to determine the operation priviledges. 
> Would it be possible that the operation permissions for {{server-group=<specific instance>:<add|remove>}} show the same permissions as {{server-group=*:<add|remove>}}? 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 14 15:01:36 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Mon, 14 Oct 2013 15:01:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2278) Deployer can't modify data
 source when datasources set as application resources
In-Reply-To: <JIRA.12502701.1381412857000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502701.1381412857000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502701.1381412857000.2755.1381777296012@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814000#comment-12814000 ] 

Heiko Braun commented on WFLY-2278:
-----------------------------------

I don't see these issues in the console master. I would say it's safe to say it works. 
                
> Deployer can't modify data source when datasources set as application resources
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-2278
>                 URL: https://issues.jboss.org/browse/WFLY-2278
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Brian Stansberry
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.CR1
>
>
> When data sources are made application resources, deployer should be able to modify them. This doesn't work, as opposed to e.g. mail sessions. For example:
> {code}
> /core-service=management/access=authorization/constraint=application-classification/type=datasources/classification=data-source:write-attribute(name=configured-application, value=true)
> {"outcome" => "success"}
> [standalone at localhost:9990 /] /subsystem=datasources/data-source=ExampleDS:write-attribute(name=jndi-name, value="java:jboss/datasources/ExampleDS_XXX"){roles=deployer}
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS013456: Unauthorized to execute operation 'write-attribute' for resource '[
>     (\"subsystem\" => \"datasources\"),
>     (\"data-source\" => \"ExampleDS\")
> ]' -- \"JBAS013475: Permission denied\"",
>     "rolled-back" => true
> }
> [standalone at localhost:9990 /] /core-service=management/access=authorization/constraint=application-classification/type=mail/classification=mail-session:write-attribute(name=configured-application, value=true)
> {"outcome" => "success"}
> [standalone at localhost:9990 /] /subsystem=mail/mail-session=java\:jboss\/mail\/Default:write-attribute(name=jndi-name, value="java:jboss/mail/Default_XXX"){roles=deployer} 
> {
>     "outcome" => "success",
>     "response-headers" => {
>         "operation-requires-reload" => true,
>         "process-state" => "reload-required"
>     }
> }
> {code}
> I have a test case for this as a last commit in my branch https://github.com/Ladicek/wildfly/commits/rbac (that is the commit called _RBAC test case for application types_).
> Brian, in case you are not the right assignee, please reassign.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 14 15:05:35 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 14 Oct 2013 15:05:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2299) SGSR permission are wrong on
	server-config
In-Reply-To: <JIRA.12502998.1381776373000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502998.1381776373000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502998.1381776373000.2763.1381777535488@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-2299:
-----------------------------------

        Parent: WFLY-490
    Issue Type: Sub-task  (was: Bug)

    
> SGSR permission are wrong on server-config
> ------------------------------------------
>
>                 Key: WFLY-2299
>                 URL: https://issues.jboss.org/browse/WFLY-2299
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> IMO the permissons are wrong for server group scoped roles:
> {noformat}
> /host=master/server-config=*
>     read-config:true
>     write-config:false
> {noformat}
> With these settings a SGSR cannot add new server configurations, even for the group it's assigned to.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 14 15:33:37 2013
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Mon, 14 Oct 2013 15:33:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-140) Java Authentication Service
 Provider Interface for Containers 1.1 (JSR-196)
In-Reply-To: <JIRA.12498523.1376434986000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498523.1376434986000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498523.1376434986000.2839.1381779217742@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBEE-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814005#comment-12814005 ] 

Shelly McGowan commented on JBEE-140:
-------------------------------------

Pull Request #3 has been merged.  Signature tests are passing and JavaDoc generation is clean.  I've released JASPIC 1.1 APIs, v1.0.0.Beta1 for further testing and review:
https://repository.jboss.org/nexus/content/groups/public/org/jboss/spec/javax/security/auth/message/jboss-jaspi-api_1.1_spec/1.0.0.Beta1/
                
> Java Authentication Service Provider Interface for Containers 1.1 (JSR-196)
> ---------------------------------------------------------------------------
>
>                 Key: JBEE-140
>                 URL: https://issues.jboss.org/browse/JBEE-140
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Sub-task
>          Components: jboss-jaspi-api
>            Reporter: Shelly McGowan
>            Assignee: Stefan Guilhen
>             Fix For: JavaEE 7 Spec APIs 1.0.0.Beta1
>
>         Attachments: javadoc-warnings.txt, jboss-jaspi-api_1.1_spec-1.0.0.Beta1-SNAPSHOT-javadoc.jar
>
>
> Updates needed for JASPIC 1.1.
> See linked issue.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 14 16:38:35 2013
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Mon, 14 Oct 2013 16:38:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-84) LoggingMXBean is not being
 set during log manager initialization
In-Reply-To: <JIRA.12502403.1381188970000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502403.1381188970000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502403.1381188970000.2912.1381783115437@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/LOGMGR-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins closed LOGMGR-84.
-------------------------------

    Resolution: Rejected


I don't see any reason to really support this. The {{java.util.logging.LoggingMXBean}} really should be retrieved from the {{org.jboss.logmanager.LogContext.getLogContext().getLoggingMXBean()}}. This allows for the correct {{LoggingMXBean}} to be used for the context.
                
> LoggingMXBean is not being set during log manager initialization
> ----------------------------------------------------------------
>
>                 Key: LOGMGR-84
>                 URL: https://issues.jboss.org/browse/LOGMGR-84
>             Project: JBoss Log Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: James Perkins
>            Assignee: James Perkins
>
> Debugging seems to show the static {{LoggingMXBean}} being set in the {{org.jboss.logmanager.LogManager}} constructor, but some time later the static instance is reinitialized to {{null}} in the {{java.util.logging.LogManager}}.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 14 16:45:35 2013
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Mon, 14 Oct 2013 16:45:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-88) Support setting the
 logging provider via a resource file
In-Reply-To: <JIRA.12479815.1353849550000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479815.1353849550000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479815.1353849550000.2926.1381783535626@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBLOGGING-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins updated JBLOGGING-88:
-----------------------------------

    Fix Version/s: 3.2.0.Beta1

    
> Support setting the logging provider via a resource file
> --------------------------------------------------------
>
>                 Key: JBLOGGING-88
>                 URL: https://issues.jboss.org/browse/JBLOGGING-88
>             Project: JBoss Logging
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.1.2.GA
>            Reporter: J?r?me Delagnes
>            Assignee: James Perkins
>             Fix For: 3.2.0.Beta1
>
>
> Logging provider can be set via the system property {{org.jboss.logging.provider}}.
> It could be nice if the provider could be also set via the resource {{META-INF/services/org.jboss.logging.provider}} or others.
> The algorithm used to locate the provider:
> # system property
> # resource file
> # existing logic

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Mon Oct 14 16:45:35 2013
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Mon, 14 Oct 2013 16:45:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-88) Support setting the
 logging provider via a resource file
In-Reply-To: <JIRA.12479815.1353849550000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479815.1353849550000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479815.1353849550000.2922.1381783535562@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBLOGGING-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins reassigned JBLOGGING-88:
--------------------------------------

    Assignee: James Perkins  (was: David Lloyd)

    
> Support setting the logging provider via a resource file
> --------------------------------------------------------
>
>                 Key: JBLOGGING-88
>                 URL: https://issues.jboss.org/browse/JBLOGGING-88
>             Project: JBoss Logging
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.1.2.GA
>            Reporter: J?r?me Delagnes
>            Assignee: James Perkins
>
> Logging provider can be set via the system property {{org.jboss.logging.provider}}.
> It could be nice if the provider could be also set via the resource {{META-INF/services/org.jboss.logging.provider}} or others.
> The algorithm used to locate the provider:
> # system property
> # resource file
> # existing logic

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Mon Oct 14 18:20:35 2013
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Mon, 14 Oct 2013 18:20:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-280) lock-on-active broken
In-Reply-To: <JIRA.12501976.1380702873000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501976.1380702873000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501976.1380702873000.3024.1381789235448@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814025#comment-12814025 ] 

Mark Proctor commented on DROOLS-280:
-------------------------------------

Can you submit this as unit test pull request? As per instructions here:
http://docs.jboss.org/drools/release/5.5.0.Final/droolsjbpm-introduction-docs/html/gettingstarted.html

The class to add the test to is this one:
https://github.com/droolsjbpm/drools/blob/master/drools-compiler/src/test/java/org/drools/compiler/integrationtests/ExecutionFlowControlTest.java
                
> lock-on-active broken
> ---------------------
>
>                 Key: DROOLS-280
>                 URL: https://issues.jboss.org/browse/DROOLS-280
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>            Reporter: Anthony Patricio
>
> Hi,
> lock-on-active is not working as expected.
> I seems to work as activation-group.
> Works fine with 5.x
> Fails with 6.0.0 CR3 and CR4
> Fact:
> {code:java}
> public class Poc implements Serializable {
> 	private static final long serialVersionUID = 1L;
> 	private long id = 1;
> 	private boolean test1 = false;
> 	private boolean test2 = false;
> 	private int foundTest = 0;
> ...
> }
> {code}
> Rule:
> {code:java}
> rule "test1"
> lock-on-active 
> dialect "mvel"
>     when
>     	$poc:Poc( isTest1() )
>     then
>     	System.out.println("test1 found");
>     	modify($poc) { setFoundTest($poc.getFoundTest() + 1) }    	
> end
> rule "test2"
> lock-on-active 
> dialect "mvel"
>     when
>     	$poc:Poc( isTest2() )
>     then
>     	System.out.println("test2 found");
>     	modify($poc) { setFoundTest($poc.getFoundTest() + 1) }    	
> end
> {code}
> Test:
> {code:java}
> @Test
> public void lockOnActiveTest() {
> 	// Get the Knowledge base from the DRL file 
> 	KieSession kSession = getSF();
> 			
> 	Poc poc = new Poc();
> 	poc.setTest1(true);
> 	poc.setTest2(true);
> 	
> 	kSession.insert(poc);
> 	
> 	// Fire the rules
> 	kSession.fireAllRules();
> 	
> 	assertTrue("broken",poc.getFoundTest()==2);
> 	
> 	// Clean up
> 	kSession.dispose();
> }
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 14 20:13:35 2013
From: jira-events at lists.jboss.org (Ondrej Zizka (JIRA))
Date: Mon, 14 Oct 2013 20:13:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1299) Arquillian AS 7 managed
 container: Different source and work dir (copy AS for each config)
In-Reply-To: <JIRA.12490669.1367189014000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12490669.1367189014000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12490669.1367189014000.3043.1381796015501@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Zizka updated WFLY-1299:
-------------------------------

    Summary: Arquillian AS 7 managed container: Different source and work dir (copy AS for each config)  (was: AS 7 managed container: Different source and work dir (copy AS for each config))

    
> Arquillian AS 7 managed container: Different source and work dir (copy AS for each config)
> ------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1299
>                 URL: https://issues.jboss.org/browse/WFLY-1299
>             Project: WildFly
>          Issue Type: Feature Request
>            Reporter: Ondrej Zizka
>            Assignee: Ondrej Zizka
>
> In my project (AS config migration), I need to keep the results of every config I run with (one per test).
> This could be handled in Maven or Ant by creating copies in advance.
> But much more ellegant would be to use [multiple containers|https://docs.jboss.org/author/display/ARQ/Multiple+Containers] and to let Arq copy some source dir and run AS from there.
> For this purpose, I propose to add a config property {{jbossAsDist}} and copy it to {{jbossHome}} before launching it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 02:30:35 2013
From: jira-events at lists.jboss.org (Josef Cacek (JIRA))
Date: Tue, 15 Oct 2013 02:30:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2300) ApacheDS used in the
 testsuite registers BouncyCastle security provider,
 but it doesn't unregister it
In-Reply-To: <JIRA.12503035.1381818628592@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503035.1381818628592@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503035.1381818628592.3157.1381818635928@jira02.app.mwc.hst.phx2.redhat.com>

Josef Cacek created WFLY-2300:
---------------------------------

             Summary:  ApacheDS used in the testsuite registers BouncyCastle security provider, but it doesn't unregister it
                 Key: WFLY-2300
                 URL: https://issues.jboss.org/browse/WFLY-2300
             Project: WildFly
          Issue Type: Bug
          Components: Test Suite
    Affects Versions: 8.0.0.Beta1
            Reporter: Josef Cacek
            Assignee: Josef Cacek


We should fix ApacheDS, which registers BouncyCastle security provider and leaves it registered after the directory server shuts down. So other tests are affected by it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 02:32:35 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 15 Oct 2013 02:32:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2300) ApacheDS used in the
 testsuite registers BouncyCastle security provider,
 but it doesn't unregister it
In-Reply-To: <JIRA.12503035.1381818628000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503035.1381818628000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503035.1381818628000.3159.1381818755484@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2300:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1018834

    
>  ApacheDS used in the testsuite registers BouncyCastle security provider, but it doesn't unregister it
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2300
>                 URL: https://issues.jboss.org/browse/WFLY-2300
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Josef Cacek
>            Assignee: Josef Cacek
>
> We should fix ApacheDS, which registers BouncyCastle security provider and leaves it registered after the directory server shuts down. So other tests are affected by it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 02:34:35 2013
From: jira-events at lists.jboss.org (Josef Cacek (JIRA))
Date: Tue, 15 Oct 2013 02:34:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2300) ApacheDS used in the
 testsuite registers BouncyCastle security provider,
 but it doesn't unregister it
In-Reply-To: <JIRA.12503035.1381818628000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503035.1381818628000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503035.1381818628000.3162.1381818875472@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Josef Cacek updated WFLY-2300:
------------------------------

    Bugzilla Update:   (was: Perform)

    
>  ApacheDS used in the testsuite registers BouncyCastle security provider, but it doesn't unregister it
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2300
>                 URL: https://issues.jboss.org/browse/WFLY-2300
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Josef Cacek
>            Assignee: Josef Cacek
>
> We should fix ApacheDS, which registers BouncyCastle security provider and leaves it registered after the directory server shuts down. So other tests are affected by it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 02:44:36 2013
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Tue, 15 Oct 2013 02:44:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2301) Remove jbosgi-metadata from
	system modules
In-Reply-To: <JIRA.12503036.1381819449689@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503036.1381819449689@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503036.1381819449689.3189.1381819476129@jira02.app.mwc.hst.phx2.redhat.com>

Thomas Diesler created WFLY-2301:
------------------------------------

             Summary: Remove jbosgi-metadata from system modules
                 Key: WFLY-2301
                 URL: https://issues.jboss.org/browse/WFLY-2301
             Project: WildFly
          Issue Type: Task
          Components: OSGi, Test Suite
    Affects Versions: 8.0.0.Alpha3
            Reporter: Thomas Diesler
            Assignee: Thomas Diesler


Various tests and the ARQ container use the ManifestBuilder from jbosgi-metadata. This should probably move to shrinkwrap.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 02:46:37 2013
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Tue, 15 Oct 2013 02:46:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1687) Remove dependency on
	jbosgi-metadata
In-Reply-To: <JIRA.12496266.1373625455000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496266.1373625455000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496266.1373625455000.3192.1381819597136@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Diesler resolved WFLY-1687.
----------------------------------

    Resolution: Won't Fix

    
> Remove dependency on jbosgi-metadata
> ------------------------------------
>
>                 Key: WFLY-1687
>                 URL: https://issues.jboss.org/browse/WFLY-1687
>             Project: WildFly
>          Issue Type: Task
>          Components: OSGi, Test Suite
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Thomas Diesler
>            Assignee: Thomas Diesler
>
> Various tests and the ARQ container use the ManifestBuilder from jbosgi-metadata. This should probably move to shrinkwrap.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 03:06:36 2013
From: jira-events at lists.jboss.org (Lin Gao (JIRA))
Date: Tue, 15 Oct 2013 03:06:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1085) Generate aggregated javadoc
In-Reply-To: <JIRA.12501583.1380176984000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501583.1380176984000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501583.1380176984000.3228.1381820796007@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lin Gao resolved JBJCA-1085.
----------------------------

    Resolution: Done

    
> Generate aggregated javadoc
> ---------------------------
>
>                 Key: JBJCA-1085
>                 URL: https://issues.jboss.org/browse/JBJCA-1085
>             Project: IronJacamar
>          Issue Type: Task
>            Reporter: Lin Gao
>            Assignee: Lin Gao
>
> Discussion at: https://groups.google.com/forum/#!topic/ironjacamar-developers/vjBJqmT07o8
> There would be 3 bundles
> All API / SPI packages
> Everything with as=false
> Everything with as=true

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 03:53:35 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 15 Oct 2013 03:53:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2302) Update to HAL 2.0.4.Final
In-Reply-To: <JIRA.12503045.1381823513755@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503045.1381823513755@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503045.1381823513755.3380.1381823615650@jira02.app.mwc.hst.phx2.redhat.com>

Heiko Braun created WFLY-2302:
---------------------------------

             Summary: Update to HAL 2.0.4.Final
                 Key: WFLY-2302
                 URL: https://issues.jboss.org/browse/WFLY-2302
             Project: WildFly
          Issue Type: Bug
          Components: Web Console
            Reporter: Heiko Braun
            Assignee: Heiko Braun
             Fix For: 8.0.0.CR1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 04:18:36 2013
From: jira-events at lists.jboss.org (Rob Stryker (JIRA))
Date: Tue, 15 Oct 2013 04:18:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-59) REMJMX support on wildfly's
 new management port 9990
In-Reply-To: <JIRA.12496261.1373621995000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496261.1373621995000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496261.1373621995000.3452.1381825116188@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/REMJMX-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rob Stryker resolved REMJMX-59.
-------------------------------

    Resolution: Rejected


This was a user-error bug.  Not an error on remjmx's part. Sorry. 
                
> REMJMX support on wildfly's new management port 9990
> ----------------------------------------------------
>
>                 Key: REMJMX-59
>                 URL: https://issues.jboss.org/browse/REMJMX-59
>             Project: Remoting JMX
>          Issue Type: Feature Request
>          Components: Connection
>            Reporter: Rob Stryker
>            Assignee: Darran Lofthouse
>
> In Wildfly alpha2, I am unable to make a connection on port 9990. Only connections via port 9999 work. However, other issues in wildfly fail on port 9999 and only succeed on 9990, making it hard for tools to decide which port to standardize on. 
> Here's the stacktrace, but I'm not sure you'll get much out of it:
> {code}
> Caused by: java.lang.RuntimeException: Operation failed with status WAITING
> 	at org.jboss.remotingjmx.RemotingConnector.internalRemotingConnect(RemotingConnector.java:221)
> 	at org.jboss.remotingjmx.RemotingConnector.internalConnect(RemotingConnector.java:146)
> 	at org.jboss.remotingjmx.RemotingConnector.connect(RemotingConnector.java:97)
> 	at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:267)
> 	at org.jboss.ide.eclipse.as.jmx.integration.JBoss71ServerConnection.createConnection(JBoss71ServerConnection.java:70)
> 	... 6 more
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 04:22:37 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 15 Oct 2013 04:22:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-296) Batch integration management
	API
In-Reply-To: <JIRA.12489438.1366010343000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489438.1366010343000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489438.1366010343000.3492.1381825357554@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun updated WFLY-296:
-----------------------------

    Summary: Batch integration management API  (was: Batch integration API)

    
> Batch integration management API
> --------------------------------
>
>                 Key: WFLY-296
>                 URL: https://issues.jboss.org/browse/WFLY-296
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Cheng Fang
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 04:24:36 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 15 Oct 2013 04:24:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-296) Batch integration management
	API
In-Reply-To: <JIRA.12489438.1366010343000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489438.1366010343000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489438.1366010343000.3501.1381825476121@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814086#comment-12814086 ] 

Heiko Braun commented on WFLY-296:
----------------------------------

Sorry, I meant the management API (DMR operations and attributes)
                
> Batch integration management API
> --------------------------------
>
>                 Key: WFLY-296
>                 URL: https://issues.jboss.org/browse/WFLY-296
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Cheng Fang
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 04:24:36 2013
From: jira-events at lists.jboss.org (Josef Cacek (JIRA))
Date: Tue, 15 Oct 2013 04:24:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2300) ApacheDS used in the
 testsuite registers BouncyCastle security provider,
 but it doesn't unregister it
In-Reply-To: <JIRA.12503035.1381818628000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503035.1381818628000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503035.1381818628000.3504.1381825476310@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Josef Cacek updated WFLY-2300:
------------------------------

    Git Pull Request:   (was: https://github.com/wildfly/wildfly/pull/5270)


PR closed - there seems to be also another piece of code, which registers the BC. 

Then the {{AuditLogToTLSSyslogTestCase}} fails if we don't unregister BC manually.
                
>  ApacheDS used in the testsuite registers BouncyCastle security provider, but it doesn't unregister it
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2300
>                 URL: https://issues.jboss.org/browse/WFLY-2300
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Josef Cacek
>            Assignee: Josef Cacek
>
> We should fix ApacheDS, which registers BouncyCastle security provider and leaves it registered after the directory server shuts down. So other tests are affected by it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 05:22:35 2013
From: jira-events at lists.jboss.org (Shane Bryzak (JIRA))
Date: Tue, 15 Oct 2013 05:22:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-299) Support rule configuration
 in a web archive
In-Reply-To: <JIRA.12503061.1381828954821@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503061.1381828954821@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503061.1381828954821.3632.1381828955797@jira02.app.mwc.hst.phx2.redhat.com>

Shane Bryzak created DROOLS-299:
-----------------------------------

             Summary: Support rule configuration in a web archive
                 Key: DROOLS-299
                 URL: https://issues.jboss.org/browse/DROOLS-299
             Project: Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions:  6.0.0.CR4
            Reporter: Shane Bryzak
            Assignee: Mario Fusco


I'm currently working on integration between PicketLink and Drools to provide rule-based security permissions which control access to protected application resources, similar to a feature that we had in Seam 2:

https://github.com/seam2/jboss-seam/blob/Seam_2_3/jboss-seam/src/main/java/org/jboss/seam/security/permission/RuleBasedPermissionResolver.java

The following quickstart (work in progress) is intended to demonstrate this integration:

https://github.com/picketlink/picketlink-quickstarts/tree/master/picketlink-authorization-drools

Building this quickstart first requires building the latest trunk of PicketLink locally:

https://github.com/picketlink/picketlink

What we would like is to allow the developer to define their security rules in the war project itself.  Currently the quickstart defines the following kmodule.xml file in the src/main/resources/META-INF directory:

<?xml version="1.0" encoding="UTF-8"?>
<kmodule xmlns="http://jboss.org/kie/6.0.0/kmodule">
  <kbase name="security" default="true">
    <ksession name="ksession1" default="true"/>
  </kbase>
</kmodule>

There is also a security-rules.drl file in the src/main/resources/security directory which defines the security rules.

Deployment of the quickstart yields the following errors and partial stacktrace:

18:52:56,036 INFO  [org.drools.compiler.kie.builder.impl.ClasspathKieProject] (MSC service thread 1-7) Found kmodule: vfs:/content/picketlink-authorization-drools.war/WEB-INF/classes/META-INF/kmodule.xml
18:52:56,036 INFO  [org.drools.compiler.kie.builder.impl.ClasspathKieProject] (MSC service thread 1-7) Virtual file physical path = /home/shane/apps/jboss/standalone/tmp/vfs/tempa9983c4071e1249/picketlink-authorization-drools.war-1c243fd87ed695cf/WEB-INF/classes
18:52:56,060 WARN  [org.drools.compiler.kie.builder.impl.ClasspathKieProject] (MSC service thread 1-7) Unable to load pom.properties tried recursing down from/home/shane/apps/jboss/standalone/tmp/vfs/tempa9983c4071e1249/picketlink-authorization-drools.war-1c243fd87ed695cf/WEB-INF/classes
null
18:52:56,061 ERROR [org.drools.compiler.kie.builder.impl.ClasspathKieProject] (MSC service thread 1-7) Unable to build index of kmodule.xml url=vfs:/content/picketlink-authorization-drools.war/WEB-INF/classes/META-INF/kmodule.xml
null
18:52:56,140 ERROR [org.drools.compiler.cdi.KieCDIExtension] (MSC service thread 1-7) Annotation @KSession(ksession1) found, but no KieSessioneModel exist.
Either the required kproject.xml does not exist, was corrupted, or mising the KieBase entry
18:52:56,160 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC00001: Failed to start service jboss.deployment.unit."picketlink-authorization-drools.war".WeldService: org.jboss.msc.service.StartException in service jboss.deployment.unit."picketlink-authorization-drools.war".WeldService: org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [KieSession] with qualifiers [@KSession] at injection point [[field] @Inject @KSession org.jboss.as.quickstarts.picketlink.authorization.drools.PermissionAuthorizer.kSession]
	at org.jboss.as.weld.services.WeldService.start(WeldService.java:83)


Mario indicated (during a discussion on IRC) that the rules are currently expected to be deployed within a separate jar file (which is then packaged as a library in the war), however our users are likely to view this as an extraneous requirement.  It would be far more convenient to allow them to create their rule definitions within the war project itself, and also be easier to promote this integration via tutorials and quickstarts.

Thanks for looking into this!





--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 05:54:35 2013
From: jira-events at lists.jboss.org (Radoslav Husar (JIRA))
Date: Tue, 15 Oct 2013 05:54:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2303) mod_cluster XSD is missing
 property and worker-timeout definitions
In-Reply-To: <JIRA.12503065.1381830758844@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503065.1381830758844@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503065.1381830758844.3790.1381830875969@jira02.app.mwc.hst.phx2.redhat.com>

Radoslav Husar created WFLY-2303:
------------------------------------

             Summary: mod_cluster XSD is missing property and worker-timeout definitions
                 Key: WFLY-2303
                 URL: https://issues.jboss.org/browse/WFLY-2303
             Project: WildFly
          Issue Type: Bug
          Components: Clustering
    Affects Versions: 8.0.0.Beta1
            Reporter: Radoslav Husar
            Assignee: Radoslav Husar
             Fix For: 8.0.0.CR1


* worker-timeout
* property

are missing.

Also missing in 7.x

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 05:56:35 2013
From: jira-events at lists.jboss.org (Radoslav Husar (JIRA))
Date: Tue, 15 Oct 2013 05:56:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2304) SESSION_DRAINING_STRATEGY is
 missing a validator and incorrectly uses setAlternatives()
In-Reply-To: <JIRA.12503066.1381830984387@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503066.1381830984387@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503066.1381830984387.3796.1381830995717@jira02.app.mwc.hst.phx2.redhat.com>

Radoslav Husar created WFLY-2304:
------------------------------------

             Summary: SESSION_DRAINING_STRATEGY is missing a validator and incorrectly uses setAlternatives()
                 Key: WFLY-2304
                 URL: https://issues.jboss.org/browse/WFLY-2304
             Project: WildFly
          Issue Type: Bug
          Components: Clustering
    Affects Versions: 8.0.0.Beta1
            Reporter: Radoslav Husar
            Assignee: Radoslav Husar
             Fix For: 8.0.0.CR1


* this is wrong .setAlternatives("DEFAULT", "ALWAYS" , "NEVER")
* add a proper validator


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 06:12:36 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 15 Oct 2013 06:12:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1023) Use datasource class as
	default
In-Reply-To: <JIRA.12488607.1365093424000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12488607.1365093424000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488607.1365093424000.3868.1381831956437@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBJCA-1023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814123#comment-12814123 ] 

RH Bugzilla Integration commented on JBJCA-1023:
------------------------------------------------

Tom Fonteyne <tfonteyn at redhat.com> made a comment on [bug 1019186|https://bugzilla.redhat.com/show_bug.cgi?id=1019186]

[tom at orac Branch_1_0]$ svn ci adapters/src/main/java/org/jboss/jca/adapters/jdbc/local/LocalManagedConnectionFactory.java -m "[bz-1019186] allow the use of a datasource class when set instead of always using the hardcoded driver class"
Sending        adapters/src/main/java/org/jboss/jca/adapters/jdbc/local/LocalManagedConnectionFactory.java
Transmitting file data.                                                          
Committed revision 114533.
                
> Use datasource class as default
> -------------------------------
>
>                 Key: JBJCA-1023
>                 URL: https://issues.jboss.org/browse/JBJCA-1023
>             Project: IronJacamar
>          Issue Type: Task
>          Components: JDBC
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.1.0.Beta5
>
>
> Switch priority from driver class to datasource class

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 06:16:36 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 15 Oct 2013 06:16:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1023) Use datasource class as
	default
In-Reply-To: <JIRA.12488607.1365093424000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12488607.1365093424000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488607.1365093424000.3877.1381832196112@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBJCA-1023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814124#comment-12814124 ] 

RH Bugzilla Integration commented on JBJCA-1023:
------------------------------------------------

Tom Fonteyne <tfonteyn at redhat.com> made a comment on [bug 1019186|https://bugzilla.redhat.com/show_bug.cgi?id=1019186]

Example setup:

<datasources>
  <datasource jndi-name="java:jboss/datasources/oracleDS" pool-name="oracleDS" enabled="true" use-ccm="true" use-java-context="true" >
  <connection-url>     jdbc:oracle:thin:@oracleserver.redhat.com:1521:oracle</connection-url>
  <datasource-class>oracle.jdbc.pool.OracleDataSource</datasource-class>
  <connection-property name="URL">jdbc:oracle:thin:@oracleserver.redhat.com:1521:oracle</connection-property>
  <driver>oracle</driver>
  <security>
    <user-name>user</user-name>
    <password>pass</password>
  </security>
  <validation>
    <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleValidConnectionChecker"/>
  <stale-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleStaleConnectionChecker"/>
  <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter"/>
                    </validation>
  </datasource>
  <drivers>
    <driver name="oracle" module="com.oracle.jdbc">
      <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>

Note the presence of both:
  connection-url: needed for JBoss
  connection-property name="URL"> : needed for the Oracle driver
Their setting should be identical
                
> Use datasource class as default
> -------------------------------
>
>                 Key: JBJCA-1023
>                 URL: https://issues.jboss.org/browse/JBJCA-1023
>             Project: IronJacamar
>          Issue Type: Task
>          Components: JDBC
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.1.0.Beta5
>
>
> Switch priority from driver class to datasource class

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 06:18:36 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 15 Oct 2013 06:18:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1023) Use datasource class as
	default
In-Reply-To: <JIRA.12488607.1365093424000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12488607.1365093424000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488607.1365093424000.3892.1381832316288@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBJCA-1023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814125#comment-12814125 ] 

RH Bugzilla Integration commented on JBJCA-1023:
------------------------------------------------

Tom Fonteyne <tfonteyn at redhat.com> changed the Status of [bug 1019186|https://bugzilla.redhat.com/show_bug.cgi?id=1019186] from ASSIGNED to MODIFIED
                
> Use datasource class as default
> -------------------------------
>
>                 Key: JBJCA-1023
>                 URL: https://issues.jboss.org/browse/JBJCA-1023
>             Project: IronJacamar
>          Issue Type: Task
>          Components: JDBC
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.1.0.Beta5
>
>
> Switch priority from driver class to datasource class

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 07:34:35 2013
From: jira-events at lists.jboss.org (Tom Fonteyne (JIRA))
Date: Tue, 15 Oct 2013 07:34:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2305) add-user utility reports "No
 java.io.Console available to interact with user." when used silently with
 su and piped to a file.
In-Reply-To: <JIRA.12503071.1381836778503@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503071.1381836778503@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503071.1381836778503.4002.1381836875625@jira02.app.mwc.hst.phx2.redhat.com>

Tom Fonteyne created WFLY-2305:
----------------------------------

             Summary: add-user utility reports "No java.io.Console available to interact with user." when used silently with su and piped to a file.
                 Key: WFLY-2305
                 URL: https://issues.jboss.org/browse/WFLY-2305
             Project: WildFly
          Issue Type: Bug
          Components: Domain Management, Security
    Affects Versions: 8.0.0.Beta1
         Environment: WildFly snapshot of master 15-oct-2013
            Reporter: Tom Fonteyne
            Assignee: Brian Stansberry


Running add-user.sh in silent mode and redirecting the output to a file results in an exception:

Exception in thread "main" java.lang.IllegalStateException: JBAS015232: No java.io.Console available to interact with user.




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 07:34:35 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 15 Oct 2013 07:34:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2305) add-user utility reports "No
 java.io.Console available to interact with user." when used silently with
 su and piped to a file.
In-Reply-To: <JIRA.12503071.1381836778000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503071.1381836778000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503071.1381836778000.4007.1381836875852@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse reassigned WFLY-2305:
--------------------------------------

    Assignee: Darran Lofthouse  (was: Brian Stansberry)

    
> add-user utility reports "No java.io.Console available to interact with user." when used silently with su and piped to a file.
> ------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2305
>                 URL: https://issues.jboss.org/browse/WFLY-2305
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, Security
>    Affects Versions: 8.0.0.Beta1
>         Environment: WildFly snapshot of master 15-oct-2013
>            Reporter: Tom Fonteyne
>            Assignee: Darran Lofthouse
>
> Running add-user.sh in silent mode and redirecting the output to a file results in an exception:
> Exception in thread "main" java.lang.IllegalStateException: JBAS015232: No java.io.Console available to interact with user.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 07:34:36 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 15 Oct 2013 07:34:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2305) add-user utility reports "No
 java.io.Console available to interact with user." when used silently with
 su and piped to a file.
In-Reply-To: <JIRA.12503071.1381836778000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503071.1381836778000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503071.1381836778000.4011.1381836876045@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2305:
-----------------------------------

    Fix Version/s: 8.0.0.CR1

    
> add-user utility reports "No java.io.Console available to interact with user." when used silently with su and piped to a file.
> ------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2305
>                 URL: https://issues.jboss.org/browse/WFLY-2305
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, Security
>    Affects Versions: 8.0.0.Beta1
>         Environment: WildFly snapshot of master 15-oct-2013
>            Reporter: Tom Fonteyne
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Running add-user.sh in silent mode and redirecting the output to a file results in an exception:
> Exception in thread "main" java.lang.IllegalStateException: JBAS015232: No java.io.Console available to interact with user.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 07:34:36 2013
From: jira-events at lists.jboss.org (Tom Fonteyne (JIRA))
Date: Tue, 15 Oct 2013 07:34:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (AS7-5061) add-user utility reports "No
 java.io.Console available to interact with user." when used silently with
 su and piped to a file.
In-Reply-To: <JIRA.12469374.1340396855000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12469374.1340396855000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12469374.1340396855000.4014.1381836876167@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-5061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814142#comment-12814142 ] 

Tom Fonteyne commented on AS7-5061:
-----------------------------------

Issue with redirect still present in WildFly 15-oct-2013. New bug logged: WFLY-2305
                
> add-user utility reports "No java.io.Console available to interact with user." when used silently with su and piped to a file.
> ------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-5061
>                 URL: https://issues.jboss.org/browse/AS7-5061
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management, Security
>    Affects Versions: 7.1.2.Final (EAP)
>            Reporter: Samuel Doyle
>            Assignee: Darran Lofthouse
>             Fix For: 7.1.3.Final (EAP), EAP 6.1.0.Alpha (7.2.0.Final)
>
>
> ./add-user.sh dustin dustin1 does not work anymore. In previous versions it worked. It has to do with the "theConsole" object being null.
> In the same breadth, the --silent=true option in add-user.sh does not work anymore. Again has to do with the need for "theConsole" object being null.
> The --silent=true option was added because in some environments, System.console() returns null[for example when the Izpack installer calls that script] and the add-user.sh script breaks because of its dependence on System.console() object to print stuff.
> [the "theConsole" object calls the System.console() object] 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 07:41:35 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 15 Oct 2013 07:41:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2305) add-user utility reports "No
 java.io.Console available to interact with user." when used silently with
 su and piped to a file.
In-Reply-To: <JIRA.12503071.1381836778000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503071.1381836778000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503071.1381836778000.4034.1381837295621@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2305:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1019264

    
> add-user utility reports "No java.io.Console available to interact with user." when used silently with su and piped to a file.
> ------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2305
>                 URL: https://issues.jboss.org/browse/WFLY-2305
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, Security
>    Affects Versions: 8.0.0.Beta1
>         Environment: WildFly snapshot of master 15-oct-2013
>            Reporter: Tom Fonteyne
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Running add-user.sh in silent mode and redirecting the output to a file results in an exception:
> Exception in thread "main" java.lang.IllegalStateException: JBAS015232: No java.io.Console available to interact with user.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 08:14:35 2013
From: jira-events at lists.jboss.org (Bernard Labno (JIRA))
Date: Tue, 15 Oct 2013 08:14:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2306) NPE in
 UndertowDeploymentInfoService.authMethod
In-Reply-To: <JIRA.12503074.1381839204755@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503074.1381839204755@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503074.1381839204755.4079.1381839275535@jira02.app.mwc.hst.phx2.redhat.com>

Bernard Labno created WFLY-2306:
-----------------------------------

             Summary: NPE in UndertowDeploymentInfoService.authMethod
                 Key: WFLY-2306
                 URL: https://issues.jboss.org/browse/WFLY-2306
             Project: WildFly
          Issue Type: Bug
    Affects Versions: 8.0.0.Beta1
            Reporter: Bernard Labno


If I do not define auth method in web.xml then NPE happens during deployment (Yoda would have saved you)

web.xml:
{code:xml}
    <login-config>
        <realm-name>RestBase</realm-name>
    </login-config>
{code}


Stacktrace:
{code}
java.lang.NullPointerException
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.authMethod(UndertowDeploymentInfoService.java:758)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.createServletConfig(UndertowDeploymentInfoService.java:693)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.start(UndertowDeploymentInfoService.java:214)
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
{code}

Related source code:
{code:java}
    private static String authMethod(String configuredMethod) {
        // TODO - Feels like a candidate for an enum but will hold off until configuration of custom methods and chaining is
        // defined.
        if (configuredMethod.equals("CLIENT-CERT")) { //Speak Yoda here please
            return HttpServletRequest.CLIENT_CERT_AUTH;
        }
        return configuredMethod;
    }
{code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 08:45:36 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 15 Oct 2013 08:45:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2268) Add Generic JMS RA
In-Reply-To: <JIRA.12502537.1381312737000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502537.1381312737000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502537.1381312737000.4148.1381841136468@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814169#comment-12814169 ] 

RH Bugzilla Integration commented on WFLY-2268:
-----------------------------------------------

Dimitris Andreadis <dandread at redhat.com> made a comment on [bug 1016762|https://bugzilla.redhat.com/show_bug.cgi?id=1016762]

Is this already in ER6?
                
> Add Generic JMS RA
> ------------------
>
>                 Key: WFLY-2268
>                 URL: https://issues.jboss.org/browse/WFLY-2268
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JCA, JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.CR1
>
>
> WildFly could integrate the Generic JMS RA[1] to be able to use JMS brokers that does not provide a resource adapter.
> [1] https://github.com/jms-ra/generic-jms-ra

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 08:47:36 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 15 Oct 2013 08:47:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2268) Add Generic JMS RA
In-Reply-To: <JIRA.12502537.1381312737000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502537.1381312737000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502537.1381312737000.4169.1381841256261@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814173#comment-12814173 ] 

RH Bugzilla Integration commented on WFLY-2268:
-----------------------------------------------

Jeff Mesnil <jmesnil at redhat.com> made a comment on [bug 1016762|https://bugzilla.redhat.com/show_bug.cgi?id=1016762]

yes, it was merged before the ER6-dev tag
                
> Add Generic JMS RA
> ------------------
>
>                 Key: WFLY-2268
>                 URL: https://issues.jboss.org/browse/WFLY-2268
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JCA, JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.CR1
>
>
> WildFly could integrate the Generic JMS RA[1] to be able to use JMS brokers that does not provide a resource adapter.
> [1] https://github.com/jms-ra/generic-jms-ra

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 08:53:35 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 15 Oct 2013 08:53:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2278) Deployer can't modify data
 source when datasources set as application resources
In-Reply-To: <JIRA.12502701.1381412857000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502701.1381412857000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502701.1381412857000.4197.1381841615610@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814177#comment-12814177 ] 

RH Bugzilla Integration commented on WFLY-2278:
-----------------------------------------------

Dimitris Andreadis <dandread at redhat.com> made a comment on [bug 1017786|https://bugzilla.redhat.com/show_bug.cgi?id=1017786]

Yes, but does this mean we need yet another console upgrade?
                
> Deployer can't modify data source when datasources set as application resources
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-2278
>                 URL: https://issues.jboss.org/browse/WFLY-2278
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Brian Stansberry
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.CR1
>
>
> When data sources are made application resources, deployer should be able to modify them. This doesn't work, as opposed to e.g. mail sessions. For example:
> {code}
> /core-service=management/access=authorization/constraint=application-classification/type=datasources/classification=data-source:write-attribute(name=configured-application, value=true)
> {"outcome" => "success"}
> [standalone at localhost:9990 /] /subsystem=datasources/data-source=ExampleDS:write-attribute(name=jndi-name, value="java:jboss/datasources/ExampleDS_XXX"){roles=deployer}
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS013456: Unauthorized to execute operation 'write-attribute' for resource '[
>     (\"subsystem\" => \"datasources\"),
>     (\"data-source\" => \"ExampleDS\")
> ]' -- \"JBAS013475: Permission denied\"",
>     "rolled-back" => true
> }
> [standalone at localhost:9990 /] /core-service=management/access=authorization/constraint=application-classification/type=mail/classification=mail-session:write-attribute(name=configured-application, value=true)
> {"outcome" => "success"}
> [standalone at localhost:9990 /] /subsystem=mail/mail-session=java\:jboss\/mail\/Default:write-attribute(name=jndi-name, value="java:jboss/mail/Default_XXX"){roles=deployer} 
> {
>     "outcome" => "success",
>     "response-headers" => {
>         "operation-requires-reload" => true,
>         "process-state" => "reload-required"
>     }
> }
> {code}
> I have a test case for this as a last commit in my branch https://github.com/Ladicek/wildfly/commits/rbac (that is the commit called _RBAC test case for application types_).
> Brian, in case you are not the right assignee, please reassign.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 08:55:35 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 15 Oct 2013 08:55:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2270) Lack of model integrity
 checking regarding role mappings, standard role names and scoped role names.
In-Reply-To: <JIRA.12502541.1381314949000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502541.1381314949000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502541.1381314949000.4200.1381841735947@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814178#comment-12814178 ] 

RH Bugzilla Integration commented on WFLY-2270:
-----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> changed the Status of [bug 1018738|https://bugzilla.redhat.com/show_bug.cgi?id=1018738] from NEW to ASSIGNED
                
> Lack of model integrity checking regarding role mappings, standard role names and scoped role names.
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2270
>                 URL: https://issues.jboss.org/browse/WFLY-2270
>             Project: WildFly
>          Issue Type: Sub-task
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Take the following scoped role definition and assignment: -
> {code}
>             <host-scoped-roles>
>                 <role name="master-Monitior" base-role="MONITOR">
>                     <host name="master"/>
>                 </role>
>             </host-scoped-roles>
> {code}
> {code}
>  <role name="master-Monitior" include-all="true"/>
> {code}
> Removal results in the following: -
> {code}
> [domain at localhost:9990 /] ./core-service=management/access=authorization/host-scoped-role=master-Monitior:remove
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "JBAS014749: Operation handler failed: JBAS013470: Unknown role 'MASTER-MONITIOR'"},
>     "rolled-back" => true
> }
> {code}
> Server side this is reported as: -
> {code}
> [Host Controller] 11:24:57,780 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014612: Operation ("remove") failed - address: ([
> [Host Controller]     ("core-service" => "management"),
> [Host Controller]     ("access" => "authorization"),
> [Host Controller]     ("host-scoped-role" => "master-Monitior")
> [Host Controller] ]): java.lang.IllegalArgumentException: JBAS013470: Unknown role 'MASTER-MONITIOR'
> [Host Controller] 	at org.jboss.as.controller.access.rbac.DefaultPermissionFactory.getUserPermissions(DefaultPermissionFactory.java:134) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.access.rbac.DefaultPermissionFactory.getUserPermissions(DefaultPermissionFactory.java:107) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.access.permission.ManagementPermissionAuthorizer.authorize(ManagementPermissionAuthorizer.java:99) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.access.management.DelegatingConfigurableAuthorizer.authorize(DelegatingConfigurableAuthorizer.java:98) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.OperationContextImpl.getBasicAuthorizationResponse(OperationContextImpl.java:1157) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1059) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.OperationContextImpl.readResourceFromRoot(OperationContextImpl.java:542) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationResolver.getServerOperations(ServerOperationResolver.java:232)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.getServerOperations(ServerOperationsResolverHandler.java:149)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.access$000(ServerOperationsResolverHandler.java:58)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler$2.getServerOperations(ServerOperationsResolverHandler.java:113)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.HostControllerExecutionSupport$Factory$DomainOpExecutionSupport.getServerOps(HostControllerExecutionSupport.java:265)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.execute(ServerOperationsResolverHandler.java:124)
> [Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:609) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:487) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:258) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:143) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:205) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:110) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:157) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:153) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_17]
> [Host Controller] 	at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_17]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [wildfly-protocol-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [wildfly-protocol-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> [Host Controller] 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> [Host Controller] 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> {code}
> At this point I believe that role removal is actually successful, however a subsequent operation is failing as the role previously associated with the user no longer exists.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 08:55:36 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 15 Oct 2013 08:55:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2270) Lack of model integrity
 checking regarding role mappings, standard role names and scoped role names.
In-Reply-To: <JIRA.12502541.1381314949000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502541.1381314949000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502541.1381314949000.4203.1381841736104@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814179#comment-12814179 ] 

RH Bugzilla Integration commented on WFLY-2270:
-----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> made a comment on [bug 1018738|https://bugzilla.redhat.com/show_bug.cgi?id=1018738]

Proposing that the additional verification is added to EAP 6.2, without the verification it is possible to define configuration that breaks the server by locking out authenticated users.
                
> Lack of model integrity checking regarding role mappings, standard role names and scoped role names.
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2270
>                 URL: https://issues.jboss.org/browse/WFLY-2270
>             Project: WildFly
>          Issue Type: Sub-task
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Take the following scoped role definition and assignment: -
> {code}
>             <host-scoped-roles>
>                 <role name="master-Monitior" base-role="MONITOR">
>                     <host name="master"/>
>                 </role>
>             </host-scoped-roles>
> {code}
> {code}
>  <role name="master-Monitior" include-all="true"/>
> {code}
> Removal results in the following: -
> {code}
> [domain at localhost:9990 /] ./core-service=management/access=authorization/host-scoped-role=master-Monitior:remove
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "JBAS014749: Operation handler failed: JBAS013470: Unknown role 'MASTER-MONITIOR'"},
>     "rolled-back" => true
> }
> {code}
> Server side this is reported as: -
> {code}
> [Host Controller] 11:24:57,780 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014612: Operation ("remove") failed - address: ([
> [Host Controller]     ("core-service" => "management"),
> [Host Controller]     ("access" => "authorization"),
> [Host Controller]     ("host-scoped-role" => "master-Monitior")
> [Host Controller] ]): java.lang.IllegalArgumentException: JBAS013470: Unknown role 'MASTER-MONITIOR'
> [Host Controller] 	at org.jboss.as.controller.access.rbac.DefaultPermissionFactory.getUserPermissions(DefaultPermissionFactory.java:134) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.access.rbac.DefaultPermissionFactory.getUserPermissions(DefaultPermissionFactory.java:107) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.access.permission.ManagementPermissionAuthorizer.authorize(ManagementPermissionAuthorizer.java:99) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.access.management.DelegatingConfigurableAuthorizer.authorize(DelegatingConfigurableAuthorizer.java:98) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.OperationContextImpl.getBasicAuthorizationResponse(OperationContextImpl.java:1157) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1059) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.OperationContextImpl.readResourceFromRoot(OperationContextImpl.java:542) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationResolver.getServerOperations(ServerOperationResolver.java:232)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.getServerOperations(ServerOperationsResolverHandler.java:149)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.access$000(ServerOperationsResolverHandler.java:58)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler$2.getServerOperations(ServerOperationsResolverHandler.java:113)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.HostControllerExecutionSupport$Factory$DomainOpExecutionSupport.getServerOps(HostControllerExecutionSupport.java:265)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.execute(ServerOperationsResolverHandler.java:124)
> [Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:609) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:487) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:258) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:143) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:205) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:110) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:157) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:153) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_17]
> [Host Controller] 	at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_17]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [wildfly-protocol-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [wildfly-protocol-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> [Host Controller] 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> [Host Controller] 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> {code}
> At this point I believe that role removal is actually successful, however a subsequent operation is failing as the role previously associated with the user no longer exists.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 09:13:36 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 15 Oct 2013 09:13:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1075)
 ironjacamar-deployers-common.jar contains source files (*.java)
In-Reply-To: <JIRA.12499731.1378101155000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499731.1378101155000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499731.1378101155000.4271.1381842816211@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBJCA-1075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814189#comment-12814189 ] 

RH Bugzilla Integration commented on JBJCA-1075:
------------------------------------------------

Pavel Jelinek <pjelinek at redhat.com> made a comment on [bug 996098|https://bugzilla.redhat.com/show_bug.cgi?id=996098]

Fixed in jboss-eap-6.2.0.ER2.zip/jboss-eap-6.2/modules/system/layers/base/org/jboss/ironjacamar/impl/main/ironjacamar-deployers-common-1.0.20.Final-redhat-1.jar
                
> ironjacamar-deployers-common.jar contains source files (*.java)
> ---------------------------------------------------------------
>
>                 Key: JBJCA-1075
>                 URL: https://issues.jboss.org/browse/JBJCA-1075
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Build
>    Affects Versions: 1.0.20.Final, 1.1.0.Final
>            Reporter: Lin Gao
>            Assignee: Lin Gao
>
> There are .java files included in ironjacamar-deployers-common.jar:
> {code}[lgao at dhcp-192-139 target]$ unzip -l ironjacamar-deployers-common.jar |grep ".java"
>      8739  08-30-2013 16:30   org/jboss/jca/deployers/DeployersBundle_$bundle.java
>      7944  08-30-2013 16:30   org/jboss/jca/deployers/DeployersLogger_$logger.java
> {code}
> The generated java file should not be packaged in the binary jar.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 09:13:36 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 15 Oct 2013 09:13:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1075)
 ironjacamar-deployers-common.jar contains source files (*.java)
In-Reply-To: <JIRA.12499731.1378101155000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499731.1378101155000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499731.1378101155000.4274.1381842816357@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBJCA-1075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814190#comment-12814190 ] 

RH Bugzilla Integration commented on JBJCA-1075:
------------------------------------------------

Pavel Jelinek <pjelinek at redhat.com> changed the Status of [bug 996098|https://bugzilla.redhat.com/show_bug.cgi?id=996098] from ON_QA to VERIFIED
                
> ironjacamar-deployers-common.jar contains source files (*.java)
> ---------------------------------------------------------------
>
>                 Key: JBJCA-1075
>                 URL: https://issues.jboss.org/browse/JBJCA-1075
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Build
>    Affects Versions: 1.0.20.Final, 1.1.0.Final
>            Reporter: Lin Gao
>            Assignee: Lin Gao
>
> There are .java files included in ironjacamar-deployers-common.jar:
> {code}[lgao at dhcp-192-139 target]$ unzip -l ironjacamar-deployers-common.jar |grep ".java"
>      8739  08-30-2013 16:30   org/jboss/jca/deployers/DeployersBundle_$bundle.java
>      7944  08-30-2013 16:30   org/jboss/jca/deployers/DeployersLogger_$logger.java
> {code}
> The generated java file should not be packaged in the binary jar.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 09:23:35 2013
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Tue, 15 Oct 2013 09:23:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2298) Redesign @Stateful EJB
	clustering
In-Reply-To: <JIRA.12502968.1381765293000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502968.1381765293000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502968.1381765293000.4320.1381843415611@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro updated WFLY-2298:
-------------------------------

    Description: 
The current @Stateful EJB clustering design has a number of flaws:
* The current implementation is very slow.  Each EJB invocation results in 4 Infinispan transactions!  Cache.get(...) and Cache.release(...) result in 2 transactions each, 1 for bean cache and 1 for group cache
* An external locking mechanism is required to lock the SFSB against access from other nodes between Cache.get(...) and Cache.release(...)
* Because the current design uses 2 separate cache instances, data is not correctly isolated and can cause integrity issues
* The current design uses a global group cache, which results in classloader leaks when a server has multiple EJB deployments
* The lifecycle of the global group cache does not leverage the MSC and thus is prone to race conditions by multiple SFSB deployments
* State changes that occur to the SFSB during activation/passivation callbacks are not correctly replicated.
* The @Clustered annotation currently has 2 orthogonal meanings:
	1. If applied to a @Stateful EJB, then a specific cache will be used (as defined by the EJB subsystem)
	2. If applied to a @Stateless or @Stateful EJB, remote EJB clients will have a dynamic view of the EJB's topology.

  was:
The current @Stateful EJB clustering design has a number of flaws:
* The current implementation is very slow.  Each EJB invocation results in 4 Infinispan transactions!  Cache.get(...) and Cache.release(...) result in 2 transactions each, 1 for bean cache and 1 for group cache
* An external locking mechanism is required to lock the SFSB against access from other nodes between Cache.get(...) and Cache.release(...)
* Because the current design uses 2 separate cache instances, data is not correctly isolated and can cause integrity issues
* The current design uses a global group cache, which results in classloader leaks when a server has multiple EJB deployments
* The lifecycle of the global group cache is not correctly handled by the MSC and is prone to race conditions
* State changes that occur to the SFSB during activation/passivation callbacks are not correctly replicated.
* The @Clustered annotation currently has 2 orthogonal meanings:
	1. If applied to a @Stateful EJB, then a specific cache will be used (as defined by the EJB subsystem)
	2. If applied to a @Stateless or @Stateful EJB, remote EJB clients will have a dynamic view of the EJB's topology.


    
> Redesign @Stateful EJB clustering
> ---------------------------------
>
>                 Key: WFLY-2298
>                 URL: https://issues.jboss.org/browse/WFLY-2298
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Clustering
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 9.0.0.CR1
>
>
> The current @Stateful EJB clustering design has a number of flaws:
> * The current implementation is very slow.  Each EJB invocation results in 4 Infinispan transactions!  Cache.get(...) and Cache.release(...) result in 2 transactions each, 1 for bean cache and 1 for group cache
> * An external locking mechanism is required to lock the SFSB against access from other nodes between Cache.get(...) and Cache.release(...)
> * Because the current design uses 2 separate cache instances, data is not correctly isolated and can cause integrity issues
> * The current design uses a global group cache, which results in classloader leaks when a server has multiple EJB deployments
> * The lifecycle of the global group cache does not leverage the MSC and thus is prone to race conditions by multiple SFSB deployments
> * State changes that occur to the SFSB during activation/passivation callbacks are not correctly replicated.
> * The @Clustered annotation currently has 2 orthogonal meanings:
> 	1. If applied to a @Stateful EJB, then a specific cache will be used (as defined by the EJB subsystem)
> 	2. If applied to a @Stateless or @Stateful EJB, remote EJB clients will have a dynamic view of the EJB's topology.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 09:39:36 2013
From: jira-events at lists.jboss.org (Radoslav Husar (JIRA))
Date: Tue, 15 Oct 2013 09:39:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1828) Wildfly High Availability
 Guide: Load-balancing (LB) and mod_cluster write up
In-Reply-To: <JIRA.12497989.1375720158000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497989.1375720158000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497989.1375720158000.4334.1381844376193@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814193#comment-12814193 ] 

Radoslav Husar commented on WFLY-1828:
--------------------------------------

Noting to include SSL config 
https://community.jboss.org/message/841651?et=watches.email.thread#841651
                
> Wildfly High Availability Guide: Load-balancing (LB) and mod_cluster write up
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-1828
>                 URL: https://issues.jboss.org/browse/WFLY-1828
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Clustering, Documentation
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.CR1
>
>
> https://docs.jboss.org/author/display/WFLY8/Load+Balancing

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 09:41:35 2013
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Tue, 15 Oct 2013 09:41:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2298) Redesign @Stateful EJB
	clustering
In-Reply-To: <JIRA.12502968.1381765293000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502968.1381765293000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502968.1381765293000.4341.1381844495732@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro updated WFLY-2298:
-------------------------------

    Description: 
The current @Stateful EJB clustering design has a number of flaws:
* The current implementation is very slow.  Each EJB invocation results in 4 Infinispan transactions!  Cache.get(...) and Cache.release(...) result in 2 transactions each, 1 for bean cache and 1 for group cache
* An external locking mechanism is required to lock the SFSB against access from other nodes between Cache.get(...) and Cache.release(...)
* Because the current design uses 2 separate cache instances, data is not correctly isolated and can cause integrity issues
* The current design uses a global group cache, which results in classloader leaks when a server has multiple EJB deployments (MarshalledValues in the group cache, which survives undeployment, can still reference the classloader of an undeployed EJB)
* The lifecycle of the global group cache does not leverage the MSC and thus is prone to race conditions by multiple SFSB deployments
* State changes that occur to the SFSB during activation/passivation callbacks are not correctly replicated.
* The @Clustered annotation currently has 2 orthogonal meanings:
	1. If applied to a @Stateful EJB, then a specific cache will be used (as defined by the EJB subsystem)
	2. If applied to a @Stateless or @Stateful EJB, remote EJB clients will have a dynamic view of the EJB's topology.

  was:
The current @Stateful EJB clustering design has a number of flaws:
* The current implementation is very slow.  Each EJB invocation results in 4 Infinispan transactions!  Cache.get(...) and Cache.release(...) result in 2 transactions each, 1 for bean cache and 1 for group cache
* An external locking mechanism is required to lock the SFSB against access from other nodes between Cache.get(...) and Cache.release(...)
* Because the current design uses 2 separate cache instances, data is not correctly isolated and can cause integrity issues
* The current design uses a global group cache, which results in classloader leaks when a server has multiple EJB deployments
* The lifecycle of the global group cache does not leverage the MSC and thus is prone to race conditions by multiple SFSB deployments
* State changes that occur to the SFSB during activation/passivation callbacks are not correctly replicated.
* The @Clustered annotation currently has 2 orthogonal meanings:
	1. If applied to a @Stateful EJB, then a specific cache will be used (as defined by the EJB subsystem)
	2. If applied to a @Stateless or @Stateful EJB, remote EJB clients will have a dynamic view of the EJB's topology.


    
> Redesign @Stateful EJB clustering
> ---------------------------------
>
>                 Key: WFLY-2298
>                 URL: https://issues.jboss.org/browse/WFLY-2298
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Clustering
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 9.0.0.CR1
>
>
> The current @Stateful EJB clustering design has a number of flaws:
> * The current implementation is very slow.  Each EJB invocation results in 4 Infinispan transactions!  Cache.get(...) and Cache.release(...) result in 2 transactions each, 1 for bean cache and 1 for group cache
> * An external locking mechanism is required to lock the SFSB against access from other nodes between Cache.get(...) and Cache.release(...)
> * Because the current design uses 2 separate cache instances, data is not correctly isolated and can cause integrity issues
> * The current design uses a global group cache, which results in classloader leaks when a server has multiple EJB deployments (MarshalledValues in the group cache, which survives undeployment, can still reference the classloader of an undeployed EJB)
> * The lifecycle of the global group cache does not leverage the MSC and thus is prone to race conditions by multiple SFSB deployments
> * State changes that occur to the SFSB during activation/passivation callbacks are not correctly replicated.
> * The @Clustered annotation currently has 2 orthogonal meanings:
> 	1. If applied to a @Stateful EJB, then a specific cache will be used (as defined by the EJB subsystem)
> 	2. If applied to a @Stateless or @Stateful EJB, remote EJB clients will have a dynamic view of the EJB's topology.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 09:41:35 2013
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Tue, 15 Oct 2013 09:41:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2298) Redesign @Stateful EJB
	clustering
In-Reply-To: <JIRA.12502968.1381765293000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502968.1381765293000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502968.1381765293000.4343.1381844495824@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro updated WFLY-2298:
-------------------------------

    Description: 
The current @Stateful EJB clustering design has a number of flaws:
* The current implementation is very slow.  Each EJB invocation results in 4 Infinispan transactions!  Cache.get(...) and Cache.release(...) result in 2 transactions each, 1 for bean cache and 1 for group cache
* An external locking mechanism is used to guard the SFSB against access from other nodes between Cache.get(...) and Cache.release(...)
* Because the current design uses 2 separate cache instances, data is not correctly isolated and can cause integrity issues
* The current design uses a global group cache, which results in classloader leaks when a server has multiple EJB deployments (MarshalledValues in the group cache, which survives undeployment, can still reference the classloader of an undeployed EJB)
* The lifecycle of the global group cache does not leverage the MSC and thus is prone to race conditions by multiple SFSB deployments
* State changes that occur to the SFSB during activation/passivation callbacks are not correctly replicated.
* The @Clustered annotation currently has 2 orthogonal meanings:
	1. If applied to a @Stateful EJB, then a specific cache will be used (as defined by the EJB subsystem)
	2. If applied to a @Stateless or @Stateful EJB, remote EJB clients will have a dynamic view of the EJB's topology.

  was:
The current @Stateful EJB clustering design has a number of flaws:
* The current implementation is very slow.  Each EJB invocation results in 4 Infinispan transactions!  Cache.get(...) and Cache.release(...) result in 2 transactions each, 1 for bean cache and 1 for group cache
* An external locking mechanism is required to lock the SFSB against access from other nodes between Cache.get(...) and Cache.release(...)
* Because the current design uses 2 separate cache instances, data is not correctly isolated and can cause integrity issues
* The current design uses a global group cache, which results in classloader leaks when a server has multiple EJB deployments (MarshalledValues in the group cache, which survives undeployment, can still reference the classloader of an undeployed EJB)
* The lifecycle of the global group cache does not leverage the MSC and thus is prone to race conditions by multiple SFSB deployments
* State changes that occur to the SFSB during activation/passivation callbacks are not correctly replicated.
* The @Clustered annotation currently has 2 orthogonal meanings:
	1. If applied to a @Stateful EJB, then a specific cache will be used (as defined by the EJB subsystem)
	2. If applied to a @Stateless or @Stateful EJB, remote EJB clients will have a dynamic view of the EJB's topology.


    
> Redesign @Stateful EJB clustering
> ---------------------------------
>
>                 Key: WFLY-2298
>                 URL: https://issues.jboss.org/browse/WFLY-2298
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Clustering
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 9.0.0.CR1
>
>
> The current @Stateful EJB clustering design has a number of flaws:
> * The current implementation is very slow.  Each EJB invocation results in 4 Infinispan transactions!  Cache.get(...) and Cache.release(...) result in 2 transactions each, 1 for bean cache and 1 for group cache
> * An external locking mechanism is used to guard the SFSB against access from other nodes between Cache.get(...) and Cache.release(...)
> * Because the current design uses 2 separate cache instances, data is not correctly isolated and can cause integrity issues
> * The current design uses a global group cache, which results in classloader leaks when a server has multiple EJB deployments (MarshalledValues in the group cache, which survives undeployment, can still reference the classloader of an undeployed EJB)
> * The lifecycle of the global group cache does not leverage the MSC and thus is prone to race conditions by multiple SFSB deployments
> * State changes that occur to the SFSB during activation/passivation callbacks are not correctly replicated.
> * The @Clustered annotation currently has 2 orthogonal meanings:
> 	1. If applied to a @Stateful EJB, then a specific cache will be used (as defined by the EJB subsystem)
> 	2. If applied to a @Stateless or @Stateful EJB, remote EJB clients will have a dynamic view of the EJB's topology.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 09:50:36 2013
From: jira-events at lists.jboss.org (Cheng Fang (JIRA))
Date: Tue, 15 Oct 2013 09:50:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-296) Batch integration management
	API
In-Reply-To: <JIRA.12489438.1366010343000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489438.1366010343000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489438.1366010343000.4361.1381845036979@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Cheng Fang reassigned WFLY-296:
-------------------------------

    Assignee: James Perkins  (was: Cheng Fang)

    
> Batch integration management API
> --------------------------------
>
>                 Key: WFLY-296
>                 URL: https://issues.jboss.org/browse/WFLY-296
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: James Perkins
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 10:17:35 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 15 Oct 2013 10:17:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2305) add-user utility reports "No
 java.io.Console available to interact with user." when used silently with
 su and piped to a file.
In-Reply-To: <JIRA.12503071.1381836778000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503071.1381836778000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503071.1381836778000.4428.1381846655650@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814208#comment-12814208 ] 

Darran Lofthouse commented on WFLY-2305:
----------------------------------------

The actual problem here is that --silent=true is not a valid argument, the valid argument is --silent 

{noformat}
[darranl at localhost bin]$ ./add-user.sh --help
Usage: ./add-user.sh [args...]
where args include:
    -a                                  If set add an application user instead 
                                        of a management user

    -dc <value>                         Define the location of the domain 
                                        config directory.

    -sc <value>                         Define the location the server config 
                                        directory.

    -up, --user-properties <value>      The file name of the user properties 
                                        file which can be an absolute path.

    -g, --group <value>                 Comma-separated list of groups for the 
                                        user.

    -gp, --group-properties <value>     The file name of the group properties 
                                        file which can be an absolute path. (If 
                                        group properties is specified then user 
                                        properties MUST also be specified).

    -p, --password <value>              Password of the user. Should not be 
                                        same as the username

    -u, --user <value>                  Name of the user

    -r, --realm <value>                 Name of the realm used to secure the 
                                        management interfaces (default is 
                                        "ManagementRealm")

    -s, --silent                        Activate the silent mode (no output to 
                                        the console)

    -e, --enable                        Activate the silent mode (no output to 
                                        the console)

    -d, --disable                       Activate the silent mode (no output to 
                                        the console)

    -cw, --confirm-warning              Automatically confirm warning in 
                                        interactive mode

    -h, --help                          Display this message and exit
{noformat}

I will add unofficial support for an argument --silent=true.
                
> add-user utility reports "No java.io.Console available to interact with user." when used silently with su and piped to a file.
> ------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2305
>                 URL: https://issues.jboss.org/browse/WFLY-2305
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, Security
>    Affects Versions: 8.0.0.Beta1
>         Environment: WildFly snapshot of master 15-oct-2013
>            Reporter: Tom Fonteyne
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Running add-user.sh in silent mode and redirecting the output to a file results in an exception:
> Exception in thread "main" java.lang.IllegalStateException: JBAS015232: No java.io.Console available to interact with user.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 10:19:36 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 15 Oct 2013 10:19:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2270) Lack of model integrity
 checking regarding role mappings, standard role names and scoped role names.
In-Reply-To: <JIRA.12502541.1381314949000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502541.1381314949000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502541.1381314949000.4445.1381846776142@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814209#comment-12814209 ] 

RH Bugzilla Integration commented on WFLY-2270:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> made a comment on [bug 1018738|https://bugzilla.redhat.com/show_bug.cgi?id=1018738]

Yes, Darran, it was my intent that your work on this would be backported as part of this BZ.
                
> Lack of model integrity checking regarding role mappings, standard role names and scoped role names.
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2270
>                 URL: https://issues.jboss.org/browse/WFLY-2270
>             Project: WildFly
>          Issue Type: Sub-task
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Take the following scoped role definition and assignment: -
> {code}
>             <host-scoped-roles>
>                 <role name="master-Monitior" base-role="MONITOR">
>                     <host name="master"/>
>                 </role>
>             </host-scoped-roles>
> {code}
> {code}
>  <role name="master-Monitior" include-all="true"/>
> {code}
> Removal results in the following: -
> {code}
> [domain at localhost:9990 /] ./core-service=management/access=authorization/host-scoped-role=master-Monitior:remove
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "JBAS014749: Operation handler failed: JBAS013470: Unknown role 'MASTER-MONITIOR'"},
>     "rolled-back" => true
> }
> {code}
> Server side this is reported as: -
> {code}
> [Host Controller] 11:24:57,780 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014612: Operation ("remove") failed - address: ([
> [Host Controller]     ("core-service" => "management"),
> [Host Controller]     ("access" => "authorization"),
> [Host Controller]     ("host-scoped-role" => "master-Monitior")
> [Host Controller] ]): java.lang.IllegalArgumentException: JBAS013470: Unknown role 'MASTER-MONITIOR'
> [Host Controller] 	at org.jboss.as.controller.access.rbac.DefaultPermissionFactory.getUserPermissions(DefaultPermissionFactory.java:134) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.access.rbac.DefaultPermissionFactory.getUserPermissions(DefaultPermissionFactory.java:107) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.access.permission.ManagementPermissionAuthorizer.authorize(ManagementPermissionAuthorizer.java:99) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.access.management.DelegatingConfigurableAuthorizer.authorize(DelegatingConfigurableAuthorizer.java:98) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.OperationContextImpl.getBasicAuthorizationResponse(OperationContextImpl.java:1157) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1059) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.OperationContextImpl.readResourceFromRoot(OperationContextImpl.java:542) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationResolver.getServerOperations(ServerOperationResolver.java:232)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.getServerOperations(ServerOperationsResolverHandler.java:149)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.access$000(ServerOperationsResolverHandler.java:58)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler$2.getServerOperations(ServerOperationsResolverHandler.java:113)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.HostControllerExecutionSupport$Factory$DomainOpExecutionSupport.getServerOps(HostControllerExecutionSupport.java:265)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.execute(ServerOperationsResolverHandler.java:124)
> [Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:609) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:487) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:258) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:143) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:205) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:110) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:157) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:153) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_17]
> [Host Controller] 	at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_17]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [wildfly-protocol-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [wildfly-protocol-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> [Host Controller] 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> [Host Controller] 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> {code}
> At this point I believe that role removal is actually successful, however a subsequent operation is failing as the role previously associated with the user no longer exists.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 10:21:35 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Tue, 15 Oct 2013 10:21:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2298) Redesign @Stateful EJB
	clustering
In-Reply-To: <JIRA.12502968.1381765293000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502968.1381765293000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502968.1381765293000.4452.1381846895715@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814210#comment-12814210 ] 

David Lloyd commented on WFLY-2298:
-----------------------------------

Can multi-master stateful clustering ever really scale well in cases other than 99% read?  What about maybe also having a single-master mode, where the non-masters have the smarts to redirect to the master?
                
> Redesign @Stateful EJB clustering
> ---------------------------------
>
>                 Key: WFLY-2298
>                 URL: https://issues.jboss.org/browse/WFLY-2298
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Clustering
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 9.0.0.CR1
>
>
> The current @Stateful EJB clustering design has a number of flaws:
> * The current implementation is very slow.  Each EJB invocation results in 4 Infinispan transactions!  Cache.get(...) and Cache.release(...) result in 2 transactions each, 1 for bean cache and 1 for group cache
> * An external locking mechanism is used to guard the SFSB against access from other nodes between Cache.get(...) and Cache.release(...)
> * Because the current design uses 2 separate cache instances, data is not correctly isolated and can cause integrity issues
> * The current design uses a global group cache, which results in classloader leaks when a server has multiple EJB deployments (MarshalledValues in the group cache, which survives undeployment, can still reference the classloader of an undeployed EJB)
> * The lifecycle of the global group cache does not leverage the MSC and thus is prone to race conditions by multiple SFSB deployments
> * State changes that occur to the SFSB during activation/passivation callbacks are not correctly replicated.
> * The @Clustered annotation currently has 2 orthogonal meanings:
> 	1. If applied to a @Stateful EJB, then a specific cache will be used (as defined by the EJB subsystem)
> 	2. If applied to a @Stateless or @Stateful EJB, remote EJB clients will have a dynamic view of the EJB's topology.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 10:25:35 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 15 Oct 2013 10:25:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2305) add-user utility reports "No
 java.io.Console available to interact with user." when used silently with
 su and piped to a file.
In-Reply-To: <JIRA.12503071.1381836778000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503071.1381836778000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503071.1381836778000.4475.1381847135957@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814213#comment-12814213 ] 

RH Bugzilla Integration commented on WFLY-2305:
-----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> made a comment on [bug 1019264|https://bugzilla.redhat.com/show_bug.cgi?id=1019264]

Proposing we make a change here as it is a tiny fix to address a usability issue.

The real issue is that the end user is entering the wrong command and is not setting silent mode as they expect, however a couple of users have been caught by this so adding support for the approach users are using to set silent mode.
                
> add-user utility reports "No java.io.Console available to interact with user." when used silently with su and piped to a file.
> ------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2305
>                 URL: https://issues.jboss.org/browse/WFLY-2305
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, Security
>    Affects Versions: 8.0.0.Beta1
>         Environment: WildFly snapshot of master 15-oct-2013
>            Reporter: Tom Fonteyne
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Running add-user.sh in silent mode and redirecting the output to a file results in an exception:
> Exception in thread "main" java.lang.IllegalStateException: JBAS015232: No java.io.Console available to interact with user.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 10:27:35 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 15 Oct 2013 10:27:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2305) add-user utility reports "No
 java.io.Console available to interact with user." when used silently with
 su and piped to a file.
In-Reply-To: <JIRA.12503071.1381836778000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503071.1381836778000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503071.1381836778000.4484.1381847255801@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814214#comment-12814214 ] 

RH Bugzilla Integration commented on WFLY-2305:
-----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> changed the Status of [bug 1019264|https://bugzilla.redhat.com/show_bug.cgi?id=1019264] from NEW to ASSIGNED
                
> add-user utility reports "No java.io.Console available to interact with user." when used silently with su and piped to a file.
> ------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2305
>                 URL: https://issues.jboss.org/browse/WFLY-2305
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, Security
>    Affects Versions: 8.0.0.Beta1
>         Environment: WildFly snapshot of master 15-oct-2013
>            Reporter: Tom Fonteyne
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Running add-user.sh in silent mode and redirecting the output to a file results in an exception:
> Exception in thread "main" java.lang.IllegalStateException: JBAS015232: No java.io.Console available to interact with user.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 10:27:35 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 15 Oct 2013 10:27:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2278) Deployer can't modify data
 source when datasources set as application resources
In-Reply-To: <JIRA.12502701.1381412857000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502701.1381412857000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502701.1381412857000.4487.1381847255989@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814215#comment-12814215 ] 

RH Bugzilla Integration commented on WFLY-2278:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> made a comment on [bug 1017786|https://bugzilla.redhat.com/show_bug.cgi?id=1017786]

I'm targeting this for ER7. I didn't set it for ER6 because although the server-side change was in, I wasn't seeing the behavior I expected in the console. But it looks like it the console that will be integrated this week doesn't have these problems.
                
> Deployer can't modify data source when datasources set as application resources
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-2278
>                 URL: https://issues.jboss.org/browse/WFLY-2278
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Brian Stansberry
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.CR1
>
>
> When data sources are made application resources, deployer should be able to modify them. This doesn't work, as opposed to e.g. mail sessions. For example:
> {code}
> /core-service=management/access=authorization/constraint=application-classification/type=datasources/classification=data-source:write-attribute(name=configured-application, value=true)
> {"outcome" => "success"}
> [standalone at localhost:9990 /] /subsystem=datasources/data-source=ExampleDS:write-attribute(name=jndi-name, value="java:jboss/datasources/ExampleDS_XXX"){roles=deployer}
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS013456: Unauthorized to execute operation 'write-attribute' for resource '[
>     (\"subsystem\" => \"datasources\"),
>     (\"data-source\" => \"ExampleDS\")
> ]' -- \"JBAS013475: Permission denied\"",
>     "rolled-back" => true
> }
> [standalone at localhost:9990 /] /core-service=management/access=authorization/constraint=application-classification/type=mail/classification=mail-session:write-attribute(name=configured-application, value=true)
> {"outcome" => "success"}
> [standalone at localhost:9990 /] /subsystem=mail/mail-session=java\:jboss\/mail\/Default:write-attribute(name=jndi-name, value="java:jboss/mail/Default_XXX"){roles=deployer} 
> {
>     "outcome" => "success",
>     "response-headers" => {
>         "operation-requires-reload" => true,
>         "process-state" => "reload-required"
>     }
> }
> {code}
> I have a test case for this as a last commit in my branch https://github.com/Ladicek/wildfly/commits/rbac (that is the commit called _RBAC test case for application types_).
> Brian, in case you are not the right assignee, please reassign.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 10:31:36 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 15 Oct 2013 10:31:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2278) Deployer can't modify data
 source when datasources set as application resources
In-Reply-To: <JIRA.12502701.1381412857000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502701.1381412857000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502701.1381412857000.4496.1381847496162@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814218#comment-12814218 ] 

RH Bugzilla Integration commented on WFLY-2278:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1017786|https://bugzilla.redhat.com/show_bug.cgi?id=1017786] from MODIFIED to POST
                
> Deployer can't modify data source when datasources set as application resources
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-2278
>                 URL: https://issues.jboss.org/browse/WFLY-2278
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Brian Stansberry
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.CR1
>
>
> When data sources are made application resources, deployer should be able to modify them. This doesn't work, as opposed to e.g. mail sessions. For example:
> {code}
> /core-service=management/access=authorization/constraint=application-classification/type=datasources/classification=data-source:write-attribute(name=configured-application, value=true)
> {"outcome" => "success"}
> [standalone at localhost:9990 /] /subsystem=datasources/data-source=ExampleDS:write-attribute(name=jndi-name, value="java:jboss/datasources/ExampleDS_XXX"){roles=deployer}
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS013456: Unauthorized to execute operation 'write-attribute' for resource '[
>     (\"subsystem\" => \"datasources\"),
>     (\"data-source\" => \"ExampleDS\")
> ]' -- \"JBAS013475: Permission denied\"",
>     "rolled-back" => true
> }
> [standalone at localhost:9990 /] /core-service=management/access=authorization/constraint=application-classification/type=mail/classification=mail-session:write-attribute(name=configured-application, value=true)
> {"outcome" => "success"}
> [standalone at localhost:9990 /] /subsystem=mail/mail-session=java\:jboss\/mail\/Default:write-attribute(name=jndi-name, value="java:jboss/mail/Default_XXX"){roles=deployer} 
> {
>     "outcome" => "success",
>     "response-headers" => {
>         "operation-requires-reload" => true,
>         "process-state" => "reload-required"
>     }
> }
> {code}
> I have a test case for this as a last commit in my branch https://github.com/Ladicek/wildfly/commits/rbac (that is the commit called _RBAC test case for application types_).
> Brian, in case you are not the right assignee, please reassign.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 11:19:36 2013
From: jira-events at lists.jboss.org (Dan Berindei (JIRA))
Date: Tue, 15 Oct 2013 11:19:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1716) The UDP receiver thread
 parsing messages causes performance regression
In-Reply-To: <JIRA.12503100.1381850347000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503100.1381850347000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503100.1381850347000.4589.1381850376760@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dan Berindei updated JGRP-1716:
-------------------------------

    Attachment: jgroups-udp.pdf

    
> The UDP receiver thread parsing messages causes performance regression
> ----------------------------------------------------------------------
>
>                 Key: JGRP-1716
>                 URL: https://issues.jboss.org/browse/JGRP-1716
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Dan Berindei
>            Assignee: Bela Ban
>         Attachments: jgroups-udp.pdf
>
>
> Comparing JGroups 3.2/3.3/3.4 performance with Radargun, the throughput went down by ~10%. (See the attached chart. "getall" means the get requests are sent to 2 nodes, "getfirst" means they are sent to only 1 node.)
> Erik Salter profiled his application and noticed that the message parsing in the UDP receiver thread seemed to slow things down. He wrote a patch that brought his throughput back to 3.2 levels: https://github.com/an1310/JGroups/compare/t_perfhack
> The UDP receiver thread may not tell the whole story, however: in the Radargun tests, performance with his patch was even lower.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 11:19:36 2013
From: jira-events at lists.jboss.org (Dan Berindei (JIRA))
Date: Tue, 15 Oct 2013 11:19:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1716) The UDP receiver thread
 parsing messages causes performance regression
In-Reply-To: <JIRA.12503100.1381850347442@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503100.1381850347442@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503100.1381850347442.4587.1381850376679@jira02.app.mwc.hst.phx2.redhat.com>

Dan Berindei created JGRP-1716:
----------------------------------

             Summary: The UDP receiver thread parsing messages causes performance regression
                 Key: JGRP-1716
                 URL: https://issues.jboss.org/browse/JGRP-1716
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 3.4
            Reporter: Dan Berindei
            Assignee: Bela Ban
         Attachments: jgroups-udp.pdf

Comparing JGroups 3.2/3.3/3.4 performance with Radargun, the throughput went down by ~10%. (See the attached chart. "getall" means the get requests are sent to 2 nodes, "getfirst" means they are sent to only 1 node.)

Erik Salter profiled his application and noticed that the message parsing in the UDP receiver thread seemed to slow things down. He wrote a patch that brought his throughput back to 3.2 levels: https://github.com/an1310/JGroups/compare/t_perfhack

The UDP receiver thread may not tell the whole story, however: in the Radargun tests, performance with his patch was even lower.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 11:24:35 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 15 Oct 2013 11:24:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-703) HttpHandlers configuration for
 EJB3 Webservice Endpoints
In-Reply-To: <JIRA.12469749.1341217769000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12469749.1341217769000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12469749.1341217769000.4595.1381850675695@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-703:
-----------------------------

        Summary: HttpHandlers configuration for EJB3 Webservice Endpoints  (was: Valve configuration for EJB3 Webservice Endpoints)
    Description: 
Please add a way to configure handlers for EJB3 endpoints packaged in an ejb-jar.
At the moment there is no option in any of the ejb deployment descriptors and of course it isn't possible to configure valves globally.
The only way to configure handlers is by handlers.conf of ServletExcention at the moment, but this is currently limited to web deployments only.

  was:
Please add a way to configure valves for EJB3 endpoints packaged in an ejb-jar.
At the moment theres no option in any of the ejb deployment descriptors and of course it isn't possible to configure valves globally.
The only way to configure valves is in the jboss-web.xml which is only available for web archives.


    
> HttpHandlers configuration for EJB3 Webservice Endpoints
> --------------------------------------------------------
>
>                 Key: WFLY-703
>                 URL: https://issues.jboss.org/browse/WFLY-703
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web Services
>            Reporter: Sebastian Maurer
>            Assignee: R Searls
>             Fix For: Awaiting Volunteers
>
>
> Please add a way to configure handlers for EJB3 endpoints packaged in an ejb-jar.
> At the moment there is no option in any of the ejb deployment descriptors and of course it isn't possible to configure valves globally.
> The only way to configure handlers is by handlers.conf of ServletExcention at the moment, but this is currently limited to web deployments only.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 11:24:36 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 15 Oct 2013 11:24:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1715) NullPointerException in
 MessageDispatcher.handleUpEvent
In-Reply-To: <JIRA.12502910.1381595328000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502910.1381595328000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502910.1381595328000.4602.1381850676067@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1715:
---------------------------

    Fix Version/s: 3.5

    
> NullPointerException in MessageDispatcher.handleUpEvent
> -------------------------------------------------------
>
>                 Key: JGRP-1715
>                 URL: https://issues.jboss.org/browse/JGRP-1715
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>         Environment: Windows 7 x64 - JDK 1.7.0_40
>            Reporter: Pierantonio Cangianiello
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> 1) Node A starts and becomes master.
> 2) Node B starts and Node A crashes.
> 3) Before becoming the new master, Node B calls channel.getState()
> 4) NullPointer occurs
> Stacktrace:
> java.lang.NullPointerException
> 	at java.io.ByteArrayInputStream.<init>(ByteArrayInputStream.java:106)
> 	at org.jgroups.blocks.MessageDispatcher.handleUpEvent(MessageDispatcher.java:567)
> 	at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:667)
> 	at org.jgroups.JChannel.up(JChannel.java:643)
> 	at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1015)
> 	at org.jgroups.protocols.Locking.up(Locking.java:269)
> 	at org.jgroups.protocols.pbcast.STATE_TRANSFER.handleViewChange(STATE_TRANSFER.java:293)
> 	at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:168)
> 	at org.jgroups.protocols.RSVP.up(RSVP.java:187)
> 	at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> 	at org.jgroups.protocols.FlowControl.up(FlowControl.java:381)
> 	at org.jgroups.protocols.FlowControl.up(FlowControl.java:381)
> 	at org.jgroups.protocols.pbcast.GMS.castViewChange(GMS.java:574)
> 	at org.jgroups.protocols.pbcast.CoordGmsImpl.handleMembershipChange(CoordGmsImpl.java:219)
> 	at org.jgroups.protocols.pbcast.GMS$ViewHandler.process(GMS.java:1633)
> 	at org.jgroups.protocols.pbcast.GMS$ViewHandler.run(GMS.java:1587)
> 	at java.lang.Thread.run(Thread.java:724)
> The issue seems to be related to this:
> in STATE_TRANSFER, line 292-293:
> Exception ex=new EOFException("state provider " + old_coord + " left");
>             up_prot.up(new Event(Event.GET_STATE_OK, new StateTransferResult(ex)));
> (buffer field is not set on event object)
> after, in MessageDispatcher 567:
> ByteArrayInputStream input=new ByteArrayInputStream(result.getBuffer());
> causes NullPointer, since result.getBuffer() returns null.
> A null-check here should resolve this issue, or an empty buffer could be set in StateTransferResult class.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 11:35:35 2013
From: jira-events at lists.jboss.org (Radoslav Husar (JIRA))
Date: Tue, 15 Oct 2013 11:35:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-322) TS clustering: test with both
 repl and dist cache modes
In-Reply-To: <JIRA.12461925.1331945943000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12461925.1331945943000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12461925.1331945943000.4618.1381851335697@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-322:
--------------------------------

    Summary: TS clustering: test with both repl and dist cache modes  (was: TS clustering: test with both repl and dist caches)

    
> TS clustering: test with both repl and dist cache modes
> -------------------------------------------------------
>
>                 Key: WFLY-322
>                 URL: https://issues.jboss.org/browse/WFLY-322
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering, Test Suite
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.CR1
>
>
> Just like we did in AS7-3954, but with different cache types.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 11:35:35 2013
From: jira-events at lists.jboss.org (Radoslav Husar (JIRA))
Date: Tue, 15 Oct 2013 11:35:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (AS7-3954) TS clustering: test with
 different JGroups stack
In-Reply-To: <JIRA.12460318.1330456635000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12460318.1330456635000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12460318.1330456635000.4615.1381851335553@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-3954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar closed AS7-3954.
-------------------------------


    
> TS clustering: test with different JGroups stack
> ------------------------------------------------
>
>                 Key: AS7-3954
>                 URL: https://issues.jboss.org/browse/AS7-3954
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Clustering, Test Suite
>    Affects Versions: 7.1.0.Final
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 7.1.2.Final (EAP)
>
>
> Just like we did in AS4/5/6.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 11:35:35 2013
From: jira-events at lists.jboss.org (Radoslav Husar (JIRA))
Date: Tue, 15 Oct 2013 11:35:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-322) TS clustering: test with both
 repl and dist cache modes
In-Reply-To: <JIRA.12461925.1331945943000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12461925.1331945943000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12461925.1331945943000.4620.1381851335806@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-322:
--------------------------------

    Affects Version/s: 8.0.0.Beta1

    
> TS clustering: test with both repl and dist cache modes
> -------------------------------------------------------
>
>                 Key: WFLY-322
>                 URL: https://issues.jboss.org/browse/WFLY-322
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering, Test Suite
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.CR1
>
>
> Just like we did in AS7-3954, but with different cache types.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 11:45:36 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 15 Oct 2013 11:45:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1716) The UDP receiver thread
 parsing messages causes performance regression
In-Reply-To: <JIRA.12503100.1381850347000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503100.1381850347000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503100.1381850347000.4654.1381851936387@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1716:
---------------------------

    Fix Version/s: 3.5

    
> The UDP receiver thread parsing messages causes performance regression
> ----------------------------------------------------------------------
>
>                 Key: JGRP-1716
>                 URL: https://issues.jboss.org/browse/JGRP-1716
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Dan Berindei
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>         Attachments: jgroups-udp.pdf
>
>
> Comparing JGroups 3.2/3.3/3.4 performance with Radargun, the throughput went down by ~10%. (See the attached chart. "getall" means the get requests are sent to 2 nodes, "getfirst" means they are sent to only 1 node.)
> Erik Salter profiled his application and noticed that the message parsing in the UDP receiver thread seemed to slow things down. He wrote a patch that brought his throughput back to 3.2 levels: https://github.com/an1310/JGroups/compare/t_perfhack
> The UDP receiver thread may not tell the whole story, however: in the Radargun tests, performance with his patch was even lower.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 11:47:35 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 15 Oct 2013 11:47:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1716) The UDP receiver thread
 parsing messages causes performance regression
In-Reply-To: <JIRA.12503100.1381850347000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503100.1381850347000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503100.1381850347000.4657.1381852055549@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814241#comment-12814241 ] 

Bela Ban commented on JGRP-1716:
--------------------------------

Can you add steps to reproduce this ? Perhaps we need to ping [~rvansa] ?
Is this the JGroups plugin run with the Radargun benchmark ?
                
> The UDP receiver thread parsing messages causes performance regression
> ----------------------------------------------------------------------
>
>                 Key: JGRP-1716
>                 URL: https://issues.jboss.org/browse/JGRP-1716
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Dan Berindei
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>         Attachments: jgroups-udp.pdf
>
>
> Comparing JGroups 3.2/3.3/3.4 performance with Radargun, the throughput went down by ~10%. (See the attached chart. "getall" means the get requests are sent to 2 nodes, "getfirst" means they are sent to only 1 node.)
> Erik Salter profiled his application and noticed that the message parsing in the UDP receiver thread seemed to slow things down. He wrote a patch that brought his throughput back to 3.2 levels: https://github.com/an1310/JGroups/compare/t_perfhack
> The UDP receiver thread may not tell the whole story, however: in the Radargun tests, performance with his patch was even lower.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 12:11:35 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 15 Oct 2013 12:11:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1697) Fix JPA
 SerializableValidatorFactory memory leak
In-Reply-To: <JIRA.12496481.1373901643000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496481.1373901643000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496481.1373901643000.4729.1381853495566@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814249#comment-12814249 ] 

RH Bugzilla Integration commented on WFLY-1697:
-----------------------------------------------

Tomaz Cerar <tcerar at redhat.com> changed the Status of [bug 1003600|https://bugzilla.redhat.com/show_bug.cgi?id=1003600] from MODIFIED to ON_QA
                
> Fix JPA SerializableValidatorFactory memory leak
> ------------------------------------------------
>
>                 Key: WFLY-1697
>                 URL: https://issues.jboss.org/browse/WFLY-1697
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>
> See http://lists.jboss.org/pipermail/wildfly-dev/2013-July/000466.html for details on recreating the SerializableValidatorFactory leak and Hibernate service loader references to Integreation class/properties.  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 12:57:35 2013
From: jira-events at lists.jboss.org (Architect SoftWeb.ISD (JIRA))
Date: Tue, 15 Oct 2013 12:57:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1660) LockService hangs during
 concurrent access (tryLock/tryLock(timeout)/lock/unlock)
In-Reply-To: <JIRA.12496765.1374141727000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496765.1374141727000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496765.1374141727000.4934.1381856255503@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Architect SoftWeb.ISD reopened JGRP-1660:
-----------------------------------------



it is still actual.
jgroups-3.4.0.Final.jar is used.
It is possible to reproduce the issue with 50 threads on each of two nodes.
I propose you play with the amounts and I am sure you will be able to reproduce it.
                
> LockService hangs during concurrent access (tryLock/tryLock(timeout)/lock/unlock)
> ---------------------------------------------------------------------------------
>
>                 Key: JGRP-1660
>                 URL: https://issues.jboss.org/browse/JGRP-1660
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.4, 3.3.3
>         Environment: Intel(R) Core(TM) i5-2310 CPU @ 2.90GHz
> 6GB RAM
> Windows 7
> JRE 1.6.31
>            Reporter: Architect SoftWeb.ISD
>            Assignee: Bela Ban
>             Fix For: 3.3.5, 3.4
>
>         Attachments: bla2.java, lock.xml, lock.xml, LockServiceStabilityTestCase.java, LockServiceStabilityTestCase.java, LockServiceStabilityTestCase.java, lockservice_stability_testcase.jar
>
>
> We have rather simple test that starts some amount of threads which in turn simultaneously obtain lock through LockService#getLock then perform lock and unlock.
> Each thread works during some time.
> After couple of seconds of work some threads just hang up in Locking$ClientLock(Object).wait() called indirectly from LockService$LockImpl.tryLock().
> Here is stack trace:
> Thread [Thread-ClientImitation-1] (Suspended)                
>                 Object.wait(long) line: not available [native method]      
>                 Locking$ClientLock(Object).wait() line: 485          
>                 Locking$ClientLock.acquireTryLock(long, boolean) line: 1010       
>                 Locking$ClientLock.tryLock() line: 896     
>                 CENTRAL_LOCK(Locking).down(Event) line: 152                
>                 ProtocolStack.down(Event) line: 1025    
>                 JChannel.down(Event) line: 718                
>                 LockService$LockImpl.tryLock() line: 102               
>                 LockServiceStabilityTestCase$ClientImitation.run() line: 167        
>                 Thread.run() line: 662     

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 13:17:35 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 15 Oct 2013 13:17:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2305) add-user utility reports "No
 java.io.Console available to interact with user." when used silently with
 su and piped to a file.
In-Reply-To: <JIRA.12503071.1381836778000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503071.1381836778000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503071.1381836778000.5010.1381857455829@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814299#comment-12814299 ] 

RH Bugzilla Integration commented on WFLY-2305:
-----------------------------------------------

Fernando Nasser <fnasser at redhat.com> changed the Status of [bug 1019264|https://bugzilla.redhat.com/show_bug.cgi?id=1019264] from ASSIGNED to POST
                
> add-user utility reports "No java.io.Console available to interact with user." when used silently with su and piped to a file.
> ------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2305
>                 URL: https://issues.jboss.org/browse/WFLY-2305
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, Security
>    Affects Versions: 8.0.0.Beta1
>         Environment: WildFly snapshot of master 15-oct-2013
>            Reporter: Tom Fonteyne
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Running add-user.sh in silent mode and redirecting the output to a file results in an exception:
> Exception in thread "main" java.lang.IllegalStateException: JBAS015232: No java.io.Console available to interact with user.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 13:21:35 2013
From: jira-events at lists.jboss.org (Radoslav Husar (JIRA))
Date: Tue, 15 Oct 2013 13:21:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-291) Speed up clustering test suite
 using ARQ custom containers
In-Reply-To: <JIRA.12463636.1334097872000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12463636.1334097872000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12463636.1334097872000.5015.1381857695646@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar closed WFLY-291.
-------------------------------


    
> Speed up clustering test suite using ARQ custom containers
> ----------------------------------------------------------
>
>                 Key: WFLY-291
>                 URL: https://issues.jboss.org/browse/WFLY-291
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering, Test Suite
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.Alpha1
>
>
> Leveraging ARQ-850.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 13:21:35 2013
From: jira-events at lists.jboss.org (Radoslav Husar (JIRA))
Date: Tue, 15 Oct 2013 13:21:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-126) DeployableContainer kills the
 managed server instead of regular shutdown in stop() on Windows
In-Reply-To: <JIRA.12485562.1361795845000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485562.1361795845000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485562.1361795845000.5020.1381857695730@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar closed WFLY-126.
-------------------------------


    
> DeployableContainer kills the managed server instead of regular shutdown in stop() on Windows
> ---------------------------------------------------------------------------------------------
>
>                 Key: WFLY-126
>                 URL: https://issues.jboss.org/browse/WFLY-126
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>            Priority: Critical
>             Fix For: 8.0.0.Alpha1
>
>
> This might be due to historical reasons for the TS to run faster, but this messes up clustering tests since shutdown is part of the test.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 13:21:35 2013
From: jira-events at lists.jboss.org (Radoslav Husar (JIRA))
Date: Tue, 15 Oct 2013 13:21:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-284) Get rid of CNFs and NCDFs from
 clustering TS runs
In-Reply-To: <JIRA.12479321.1353000076000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479321.1353000076000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479321.1353000076000.5026.1381857695865@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-284:
--------------------------------

    Issue Type: Bug  (was: Feature Request)

    
> Get rid of CNFs and NCDFs from clustering TS runs
> -------------------------------------------------
>
>                 Key: WFLY-284
>                 URL: https://issues.jboss.org/browse/WFLY-284
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>            Priority: Minor
>             Fix For: 8.0.0.Alpha1
>
>
> &#27;[0m&#27;[0m12:53:07,775 INFO  [org.jboss.weld.ClassLoading] (MSC service thread 1-3) WELD-000119 Not generating any bean definitions from org.jboss.as.test.clustering.ClusterHttpClientUtil because of underlying class loading error
> &#27;[0m&#27;[0m12:53:07,776 INFO  [org.jboss.weld.ClassLoading] (MSC service thread 1-3) catching: org.jboss.weld.resources.spi.ResourceLoadingException: Error loading class org.jboss.as.test.clustering.ClusterHttpClientUtil
>     at org.jboss.weld.resources.ClassTransformer.loadClass(ClassTransformer.java:167) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
>     at org.jboss.weld.bootstrap.BeanDeployer.loadWeldClass(BeanDeployer.java:116) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
>     at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:79) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
>     at org.jboss.weld.bootstrap.BeanDeployer.addClasses(BeanDeployer.java:135) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
>     at org.jboss.weld.bootstrap.BeanDeployment.createBeans(BeanDeployment.java:184) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
>     at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:349) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
>     at org.jboss.as.weld.WeldContainer.start(WeldContainer.java:82) [jboss-as-weld-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>     at org.jboss.as.weld.services.WeldService.start(WeldService.java:76) [jboss-as-weld-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
>     at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_31]
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_31]
>     at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_31]
> Caused by: java.lang.NoClassDefFoundError: org/apache/http/client/methods/HttpUriRequest
>     at java.lang.Class.getDeclaredFields0(Native Method) [rt.jar:1.6.0_31]
>     at java.lang.Class.privateGetDeclaredFields(Class.java:2291) [rt.jar:1.6.0_31]
>     at java.lang.Class.getDeclaredFields(Class.java:1743) [rt.jar:1.6.0_31]
>     at org.jboss.weld.util.reflection.SecureReflections$4.work(SecureReflections.java:105) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
>     at org.jboss.weld.util.reflection.SecureReflections$4.work(SecureReflections.java:102) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
>     at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:52) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
>     at org.jboss.weld.util.reflection.SecureReflectionAccess.runAndWrap(SecureReflectionAccess.java:63) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
>     at org.jboss.weld.util.reflection.SecureReflections.getDeclaredFields(SecureReflections.java:102) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
>     at org.jboss.weld.introspector.jlr.WeldClassImpl.<init>(WeldClassImpl.java:155) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
>     at org.jboss.weld.introspector.jlr.WeldClassImpl.of(WeldClassImpl.java:121) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
>     at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:59) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
>     at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:50) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
>     at com.google.common.collect.ComputingConcurrentHashMap$ComputingValueReference.compute(ComputingConcurrentHashMap.java:355)
>     at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.compute(ComputingConcurrentHashMap.java:184)
>     at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.getOrCompute(ComputingConcurrentHashMap.java:153)
>     at com.google.common.collect.ComputingConcurrentHashMap.getOrCompute(ComputingConcurrentHashMap.java:69)
>     at com.google.common.collect.ComputingConcurrentHashMap$ComputingMapAdapter.get(ComputingConcurrentHashMap.java:393)
>     at org.jboss.weld.resources.ClassTransformer.loadClass(ClassTransformer.java:163) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
>     ... 12 more
> Caused by: java.lang.ClassNotFoundException: org.apache.http.client.methods.HttpUriRequest from [Module "deployment.stateful.war:main" from Service Module Loader]
>     at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190) [jboss-modules.jar:1.1.3.GA]
>     at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468) [jboss-modules.jar:1.1.3.GA]
>     at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456) [jboss-modules.jar:1.1.3.GA]
>     at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:423) [jboss-modules.jar:1.1.3.GA]
>     at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398) [jboss-modules.jar:1.1.3.GA]
>     at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120) [jboss-modules.jar:1.1.3.GA]
>     ... 30 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 13:21:35 2013
From: jira-events at lists.jboss.org (Radoslav Husar (JIRA))
Date: Tue, 15 Oct 2013 13:21:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-284) Get rid of CNFs and NCDFs from
 clustering TS runs
In-Reply-To: <JIRA.12479321.1353000076000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479321.1353000076000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479321.1353000076000.5028.1381857695898@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar closed WFLY-284.
-------------------------------


    
> Get rid of CNFs and NCDFs from clustering TS runs
> -------------------------------------------------
>
>                 Key: WFLY-284
>                 URL: https://issues.jboss.org/browse/WFLY-284
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>            Priority: Minor
>             Fix For: 8.0.0.Alpha1
>
>
> &#27;[0m&#27;[0m12:53:07,775 INFO  [org.jboss.weld.ClassLoading] (MSC service thread 1-3) WELD-000119 Not generating any bean definitions from org.jboss.as.test.clustering.ClusterHttpClientUtil because of underlying class loading error
> &#27;[0m&#27;[0m12:53:07,776 INFO  [org.jboss.weld.ClassLoading] (MSC service thread 1-3) catching: org.jboss.weld.resources.spi.ResourceLoadingException: Error loading class org.jboss.as.test.clustering.ClusterHttpClientUtil
>     at org.jboss.weld.resources.ClassTransformer.loadClass(ClassTransformer.java:167) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
>     at org.jboss.weld.bootstrap.BeanDeployer.loadWeldClass(BeanDeployer.java:116) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
>     at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:79) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
>     at org.jboss.weld.bootstrap.BeanDeployer.addClasses(BeanDeployer.java:135) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
>     at org.jboss.weld.bootstrap.BeanDeployment.createBeans(BeanDeployment.java:184) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
>     at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:349) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
>     at org.jboss.as.weld.WeldContainer.start(WeldContainer.java:82) [jboss-as-weld-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>     at org.jboss.as.weld.services.WeldService.start(WeldService.java:76) [jboss-as-weld-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
>     at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_31]
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_31]
>     at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_31]
> Caused by: java.lang.NoClassDefFoundError: org/apache/http/client/methods/HttpUriRequest
>     at java.lang.Class.getDeclaredFields0(Native Method) [rt.jar:1.6.0_31]
>     at java.lang.Class.privateGetDeclaredFields(Class.java:2291) [rt.jar:1.6.0_31]
>     at java.lang.Class.getDeclaredFields(Class.java:1743) [rt.jar:1.6.0_31]
>     at org.jboss.weld.util.reflection.SecureReflections$4.work(SecureReflections.java:105) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
>     at org.jboss.weld.util.reflection.SecureReflections$4.work(SecureReflections.java:102) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
>     at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:52) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
>     at org.jboss.weld.util.reflection.SecureReflectionAccess.runAndWrap(SecureReflectionAccess.java:63) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
>     at org.jboss.weld.util.reflection.SecureReflections.getDeclaredFields(SecureReflections.java:102) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
>     at org.jboss.weld.introspector.jlr.WeldClassImpl.<init>(WeldClassImpl.java:155) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
>     at org.jboss.weld.introspector.jlr.WeldClassImpl.of(WeldClassImpl.java:121) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
>     at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:59) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
>     at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:50) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
>     at com.google.common.collect.ComputingConcurrentHashMap$ComputingValueReference.compute(ComputingConcurrentHashMap.java:355)
>     at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.compute(ComputingConcurrentHashMap.java:184)
>     at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.getOrCompute(ComputingConcurrentHashMap.java:153)
>     at com.google.common.collect.ComputingConcurrentHashMap.getOrCompute(ComputingConcurrentHashMap.java:69)
>     at com.google.common.collect.ComputingConcurrentHashMap$ComputingMapAdapter.get(ComputingConcurrentHashMap.java:393)
>     at org.jboss.weld.resources.ClassTransformer.loadClass(ClassTransformer.java:163) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
>     ... 12 more
> Caused by: java.lang.ClassNotFoundException: org.apache.http.client.methods.HttpUriRequest from [Module "deployment.stateful.war:main" from Service Module Loader]
>     at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190) [jboss-modules.jar:1.1.3.GA]
>     at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468) [jboss-modules.jar:1.1.3.GA]
>     at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456) [jboss-modules.jar:1.1.3.GA]
>     at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:423) [jboss-modules.jar:1.1.3.GA]
>     at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398) [jboss-modules.jar:1.1.3.GA]
>     at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120) [jboss-modules.jar:1.1.3.GA]
>     ... 30 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 13:21:35 2013
From: jira-events at lists.jboss.org (Radoslav Husar (JIRA))
Date: Tue, 15 Oct 2013 13:21:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-284) Get rid of CNFs and NCDFs from
 clustering TS runs
In-Reply-To: <JIRA.12479321.1353000076000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479321.1353000076000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479321.1353000076000.5023.1381857695805@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-284:
--------------------------------

    Git Pull Request: https://github.com/jbossas/jboss-as/pull/3381, https://github.com/jbossas/jboss-as/pull/3279

    
> Get rid of CNFs and NCDFs from clustering TS runs
> -------------------------------------------------
>
>                 Key: WFLY-284
>                 URL: https://issues.jboss.org/browse/WFLY-284
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>            Priority: Minor
>             Fix For: 8.0.0.Alpha1
>
>
> &#27;[0m&#27;[0m12:53:07,775 INFO  [org.jboss.weld.ClassLoading] (MSC service thread 1-3) WELD-000119 Not generating any bean definitions from org.jboss.as.test.clustering.ClusterHttpClientUtil because of underlying class loading error
> &#27;[0m&#27;[0m12:53:07,776 INFO  [org.jboss.weld.ClassLoading] (MSC service thread 1-3) catching: org.jboss.weld.resources.spi.ResourceLoadingException: Error loading class org.jboss.as.test.clustering.ClusterHttpClientUtil
>     at org.jboss.weld.resources.ClassTransformer.loadClass(ClassTransformer.java:167) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
>     at org.jboss.weld.bootstrap.BeanDeployer.loadWeldClass(BeanDeployer.java:116) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
>     at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:79) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
>     at org.jboss.weld.bootstrap.BeanDeployer.addClasses(BeanDeployer.java:135) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
>     at org.jboss.weld.bootstrap.BeanDeployment.createBeans(BeanDeployment.java:184) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
>     at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:349) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
>     at org.jboss.as.weld.WeldContainer.start(WeldContainer.java:82) [jboss-as-weld-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>     at org.jboss.as.weld.services.WeldService.start(WeldService.java:76) [jboss-as-weld-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
>     at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_31]
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_31]
>     at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_31]
> Caused by: java.lang.NoClassDefFoundError: org/apache/http/client/methods/HttpUriRequest
>     at java.lang.Class.getDeclaredFields0(Native Method) [rt.jar:1.6.0_31]
>     at java.lang.Class.privateGetDeclaredFields(Class.java:2291) [rt.jar:1.6.0_31]
>     at java.lang.Class.getDeclaredFields(Class.java:1743) [rt.jar:1.6.0_31]
>     at org.jboss.weld.util.reflection.SecureReflections$4.work(SecureReflections.java:105) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
>     at org.jboss.weld.util.reflection.SecureReflections$4.work(SecureReflections.java:102) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
>     at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:52) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
>     at org.jboss.weld.util.reflection.SecureReflectionAccess.runAndWrap(SecureReflectionAccess.java:63) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
>     at org.jboss.weld.util.reflection.SecureReflections.getDeclaredFields(SecureReflections.java:102) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
>     at org.jboss.weld.introspector.jlr.WeldClassImpl.<init>(WeldClassImpl.java:155) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
>     at org.jboss.weld.introspector.jlr.WeldClassImpl.of(WeldClassImpl.java:121) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
>     at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:59) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
>     at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:50) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
>     at com.google.common.collect.ComputingConcurrentHashMap$ComputingValueReference.compute(ComputingConcurrentHashMap.java:355)
>     at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.compute(ComputingConcurrentHashMap.java:184)
>     at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.getOrCompute(ComputingConcurrentHashMap.java:153)
>     at com.google.common.collect.ComputingConcurrentHashMap.getOrCompute(ComputingConcurrentHashMap.java:69)
>     at com.google.common.collect.ComputingConcurrentHashMap$ComputingMapAdapter.get(ComputingConcurrentHashMap.java:393)
>     at org.jboss.weld.resources.ClassTransformer.loadClass(ClassTransformer.java:163) [weld-core-1.1.10.Final.jar:2012-10-12 10:00]
>     ... 12 more
> Caused by: java.lang.ClassNotFoundException: org.apache.http.client.methods.HttpUriRequest from [Module "deployment.stateful.war:main" from Service Module Loader]
>     at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190) [jboss-modules.jar:1.1.3.GA]
>     at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468) [jboss-modules.jar:1.1.3.GA]
>     at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456) [jboss-modules.jar:1.1.3.GA]
>     at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:423) [jboss-modules.jar:1.1.3.GA]
>     at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398) [jboss-modules.jar:1.1.3.GA]
>     at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120) [jboss-modules.jar:1.1.3.GA]
>     ... 30 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 13:37:36 2013
From: jira-events at lists.jboss.org (Radoslav Husar (JIRA))
Date: Tue, 15 Oct 2013 13:37:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-215) Clustering tests leave a
 hanging instance if they are run in opposite order
In-Reply-To: <JIRA.12487439.1363626505000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12487439.1363626505000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487439.1363626505000.5072.1381858656038@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814304#comment-12814304 ] 

Radoslav Husar commented on WFLY-215:
-------------------------------------

Seems like something else is breaking it now, will try later:

{noformat}
-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Running org.jboss.as.test.clustering.cluster.singleton.SingletonTestCase
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 62.695 sec
Running org.jboss.as.test.clustering.cluster.ejb3.stateful.StatefulFailoverTestCase
Tests run: 1, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 0.001 sec
Running org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.dd.RemoteEJBClientDDBasedSFSBFailoverTestCase
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 22.648 sec
Running org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.LocalEJBClientFailoverTestCase
Tests run: 1, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 0 sec
Running org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.RemoteEJBClientStatefulBeanFailoverTestCase
Tests run: 1, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 0 sec
Running org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.SlowUndeploymentRemoteFailoverTestCase
Tests run: 3, Failures: 0, Errors: 0, Skipped: 3, Time elapsed: 0.033 sec
Running org.jboss.as.test.clustering.cluster.ejb3.stateful.passivation.ClusterPassivationTestCase
Tests run: 5, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 71.329 sec
Running org.jboss.as.test.clustering.cluster.ejb3.stateless.RemoteStatelessFailoverTestCase
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 68.688 sec
Running org.jboss.as.test.clustering.cluster.ejb3.StatefulTimeoutTestCase
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 34.857 sec
Running org.jboss.as.test.clustering.cluster.ejb3.descriptor.disable.DisableClusteredTestCase
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 41.079 sec
Running org.jboss.as.test.clustering.cluster.ejb3.security.FailoverWithSecurityTestCase
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 72.596 sec
Running org.jboss.as.test.clustering.cluster.ejb3.xpc.StatefulWithXPCFailoverTestCase
Tests run: 3, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 53.521 sec <<< FAILURE!
Running org.jboss.as.test.clustering.cluster.ejb3.deployment.ClusteredBeanDeploymentTestCase
Tests run: 4, Failures: 0, Errors: 4, Skipped: 0, Time elapsed: 37.509 sec <<< FAILURE!
Running org.jboss.as.test.clustering.cluster.management.CacheTestCase
Tests run: 7, Failures: 2, Errors: 4, Skipped: 0, Time elapsed: 24.204 sec <<< FAILURE!
Running org.jboss.as.test.clustering.cluster.session.persistence.SessionClusterDbPersistenceTestCase
Tests run: 4, Failures: 0, Errors: 4, Skipped: 0, Time elapsed: 51.604 sec <<< FAILURE!
Running org.jboss.as.test.clustering.cluster.web.GranularWebFailoverTestCase
Tests run: 4, Failures: 0, Errors: 4, Skipped: 0, Time elapsed: 75.313 sec <<< FAILURE!
Running org.jboss.as.test.clustering.cluster.web.NonHaWebSessionPersistenceTestCase
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 15.959 sec
Running org.jboss.as.test.clustering.cluster.web.passivation.CoarseSessionPassivationTestCase
Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 42.493 sec <<< FAILURE!
Running org.jboss.as.test.clustering.cluster.web.passivation.FineSessionPassivationTestCase
Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 32.747 sec <<< FAILURE!
Running org.jboss.as.test.clustering.cluster.web.ReplicationWebFailoverTestCase
Tests run: 4, Failures: 0, Errors: 4, Skipped: 0, Time elapsed: 91.496 sec <<< FAILURE!
Running org.jboss.as.test.clustering.cluster.web.expiration.CoarseSessionExpirationTestCase
...
{noformat}

Anyway, the branch is ready here:
https://github.com/rhusar/wildfly/compare/WFLY-215;testsuite_reverseorder?expand=1
                
> Clustering tests leave a hanging instance if they are run in opposite order
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-215
>                 URL: https://issues.jboss.org/browse/WFLY-215
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Clustering, Test Suite
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.CR1
>
>
> Interestingly, if the tests are run in the opposite order i.e. alphabetically, one server instance remains running and doesn't shut down.
> I have used a workaround for now
> {code}
> +                                    <!-- Force the order of tests -->
> +                                    <runOrder>reversealphabetical</runOrder>
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 14:07:36 2013
From: jira-events at lists.jboss.org (Radoslav Husar (JIRA))
Date: Tue, 15 Oct 2013 14:07:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1584) Intermittent failures
 SyslogHandlerTestCase
In-Reply-To: <JIRA.12495013.1372108067000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495013.1372108067000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495013.1372108067000.5101.1381860456776@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814317#comment-12814317 ] 

Radoslav Husar commented on WFLY-1584:
--------------------------------------

The PR is merged, should this be closed too?
                
> Intermittent failures SyslogHandlerTestCase
> -------------------------------------------
>
>                 Key: WFLY-1584
>                 URL: https://issues.jboss.org/browse/WFLY-1584
>             Project: WildFly
>          Issue Type: Bug
>          Components: Logging, Test Suite
>            Reporter: James Perkins
>            Assignee: James Perkins
>
> The failure is likely because either the events aren't written within the [one second|https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/logging/operations/SyslogHandlerTestCase.java#L128] sleep. Either it's not flushing in time or the events are processed after check.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 14:32:35 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 15 Oct 2013 14:32:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-300) Add optional start and end
 arguments to timers
In-Reply-To: <JIRA.12503113.1381861876993@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503113.1381861876993@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503113.1381861876993.5165.1381861955679@jira02.app.mwc.hst.phx2.redhat.com>

Mario Fusco created DROOLS-300:
----------------------------------

             Summary: Add optional start and end arguments to timers
                 Key: DROOLS-300
                 URL: https://issues.jboss.org/browse/DROOLS-300
             Project: Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions:  6.0.0.CR4
            Reporter: Mario Fusco
            Assignee: Mario Fusco




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 14:44:36 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 15 Oct 2013 14:44:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2029) access-type attribute
 description and access-control section
In-Reply-To: <JIRA.12500315.1378741350000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500315.1378741350000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500315.1378741350000.5212.1381862676960@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814334#comment-12814334 ] 

Brian Stansberry commented on WFLY-2029:
----------------------------------------

I'm going to revert this behavior. The problem is "access-type" relates to how an attribute is handled *after* the resource is added; e.g. for the write-attribute op. It does not govern whether it is set by the user as part of resource add.

OTOH, the access-control "write" setting covers both add and post-add modification.

Mixing the two leads to things like the console not allowing the Maintainer role to set non-sensitive attributes in the form used for adding resources, e.g. https://bugzilla.redhat.com/show_bug.cgi?id=1017062.
                
> access-type attribute description and access-control section
> ------------------------------------------------------------
>
>                 Key: WFLY-2029
>                 URL: https://issues.jboss.org/browse/WFLY-2029
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Alexey Loubyansky
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Beta1
>
>
> <aloubyansky> bstansberry: i see that for attributes with access-type=read-only, the access-control section contains read=true, write=true
> <bstansberry> aloubyansky: can you file a JIRA, assigned to kabir, subtask of WFLY-490?
> <aloubyansky> bstansberry: you mean attribute's access-type and access-control section should be consistent?
> <bstansberry> aloubyansky: i mean you shouldn't have "write" as part of access control if the attribute isn't writable
> <bstansberry> aloubyansky: I definitely don't mean that the value of access-type should depend on access control

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 14:46:35 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 15 Oct 2013 14:46:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2307) Allow access-control "write"
 metadata to say "true" for read-only attributes
In-Reply-To: <JIRA.12503116.1381862749155@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503116.1381862749155@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503116.1381862749155.5226.1381862795845@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-2307:
--------------------------------------

             Summary: Allow access-control "write" metadata to say "true" for read-only attributes
                 Key: WFLY-2307
                 URL: https://issues.jboss.org/browse/WFLY-2307
             Project: WildFly
          Issue Type: Sub-task
          Components: Domain Management
    Affects Versions: 8.0.0.Beta1
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: 8.0.0.CR1


Revert behavior introduced in WFLY-2029.

The problem is "access-type" relates to how an attribute is handled after the resource is added; e.g. for the write-attribute op. It does not govern whether it is set by the user as part of resource add.

OTOH, the access-control "write" setting covers both add and post-add modification.

Mixing the two leads to things like the console not allowing the Maintainer role to set non-sensitive attributes in the form used for adding resources, e.g. https://bugzilla.redhat.com/show_bug.cgi?id=1017062.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 14:54:35 2013
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Tue, 15 Oct 2013 14:54:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-133) Expression Language 3.0
	(JSR-341) APIs
In-Reply-To: <JIRA.12487467.1363659115000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12487467.1363659115000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487467.1363659115000.5263.1381863275668@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBEE-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814341#comment-12814341 ] 

Shelly McGowan commented on JBEE-133:
-------------------------------------

1.0.0.Beta1 has been released:
https://repository.jboss.org/nexus/content/groups/public/org/jboss/spec/javax/el/jboss-el-api_3.0_spec/1.0.0.Beta1/
                
> Expression Language 3.0 (JSR-341) APIs
> --------------------------------------
>
>                 Key: JBEE-133
>                 URL: https://issues.jboss.org/browse/JBEE-133
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Sub-task
>          Components: jboss-javaee-specs
>            Reporter: Shelly McGowan
>            Assignee: Remy Maucherat
>             Fix For: JavaEE 7 Spec APIs 1.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 15:00:35 2013
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Tue, 15 Oct 2013 15:00:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-141) JSR-115,
 JACC version changed from 1.4 to 1.5 in Maintenance Release 3 for
 Java EE 7 platform
In-Reply-To: <JIRA.12501330.1379963000000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501330.1379963000000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501330.1379963000000.5286.1381863635638@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBEE-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBEE-141:
--------------------------------

    Fix Version/s: JavaEE 7 Spec APIs 1.0.0.CR1
                       (was: JavaEE 7 Spec APIs 1.0.0.Beta2)

    
> JSR-115, JACC version changed from 1.4 to 1.5 in Maintenance Release 3 for Java EE 7 platform
> ---------------------------------------------------------------------------------------------
>
>                 Key: JBEE-141
>                 URL: https://issues.jboss.org/browse/JBEE-141
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Sub-task
>          Components: jboss-javaee-specs
>            Reporter: Shelly McGowan
>            Assignee: Stefan Guilhen
>             Fix For: JavaEE 7 Spec APIs 1.0.0.CR1
>
>
> http://jcp.org/en/jsr/detail?id=115

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 15:02:35 2013
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Tue, 15 Oct 2013 15:02:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-140) Java Authentication Service
 Provider Interface for Containers 1.1 (JSR-196)
In-Reply-To: <JIRA.12498523.1376434986000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498523.1376434986000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498523.1376434986000.5289.1381863755612@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBEE-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan resolved JBEE-140.
---------------------------------

    Resolution: Done


JASPIC 1.0.0.Beta1 has been included in the Java EE 7 Spec APIs BOM 1.0.0.Beta1 release.  Considering this Resolved.    Once testing has been satisfied, we can promote to .Final.
                
> Java Authentication Service Provider Interface for Containers 1.1 (JSR-196)
> ---------------------------------------------------------------------------
>
>                 Key: JBEE-140
>                 URL: https://issues.jboss.org/browse/JBEE-140
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Sub-task
>          Components: jboss-jaspi-api
>            Reporter: Shelly McGowan
>            Assignee: Stefan Guilhen
>             Fix For: JavaEE 7 Spec APIs 1.0.0.Beta2
>
>         Attachments: javadoc-warnings.txt, jboss-jaspi-api_1.1_spec-1.0.0.Beta1-SNAPSHOT-javadoc.jar
>
>
> Updates needed for JASPIC 1.1.
> See linked issue.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 15:02:36 2013
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Tue, 15 Oct 2013 15:02:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-139) Move getBootModuleLoader under
 doPrivileged block in SAAJ FactoryFinder
In-Reply-To: <JIRA.12498209.1375946901000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498209.1375946901000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498209.1375946901000.5294.1381863756083@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBEE-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan resolved JBEE-139.
---------------------------------

    Fix Version/s: JavaEE 7 Spec APIs 1.0.0.Beta2
       Resolution: Done


This has been resolved in SAAJ API 1.0.3.Beta1 release which has been promoted to 1.0.3.Final.
                
> Move getBootModuleLoader under doPrivileged block in SAAJ FactoryFinder
> -----------------------------------------------------------------------
>
>                 Key: JBEE-139
>                 URL: https://issues.jboss.org/browse/JBEE-139
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Task
>            Reporter: Jim Ma
>            Assignee: Jim Ma
>             Fix For: JavaEE 7 Spec APIs 1.0.0.Beta2
>
>
> There is getBootModuleLoader permission check error when create the soap message in container.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 15:04:35 2013
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Tue, 15 Oct 2013 15:04:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-138)
 javax.resource.spi.endpoint.MessageEndpointFactory is missing
 getEndpointClass() method
In-Reply-To: <JIRA.12497494.1375102079000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497494.1375102079000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497494.1375102079000.5301.1381863875894@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBEE-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan resolved JBEE-138.
---------------------------------

    Fix Version/s: JavaEE 7 Spec APIs 1.0.0.Beta2
       Resolution: Done

    
> javax.resource.spi.endpoint.MessageEndpointFactory is missing getEndpointClass() method
> ---------------------------------------------------------------------------------------
>
>                 Key: JBEE-138
>                 URL: https://issues.jboss.org/browse/JBEE-138
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>            Reporter: Stuart Douglas
>            Assignee: Shelly McGowan
>             Fix For: JavaEE 7 Spec APIs 1.0.0.Beta2
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 15:04:36 2013
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Tue, 15 Oct 2013 15:04:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-137) Release Final version of
 jboss-interceptors-api_1.2_spec
In-Reply-To: <JIRA.12497405.1374844018000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497405.1374844018000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497405.1374844018000.5313.1381863876961@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBEE-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan resolved JBEE-137.
---------------------------------

    Fix Version/s: JavaEE 7 Spec APIs 1.0.0.Beta2
       Resolution: Done


JBoss Interceptors 1.2 API, v1.0.0.Final has been released:
https://repository.jboss.org/nexus/content/groups/public/org/jboss/spec/javax/interceptor/jboss-interceptors-api_1.2_spec/1.0.0.Final/
                
> Release Final version of jboss-interceptors-api_1.2_spec 
> ---------------------------------------------------------
>
>                 Key: JBEE-137
>                 URL: https://issues.jboss.org/browse/JBEE-137
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>            Reporter: Shelly McGowan
>             Fix For: JavaEE 7 Spec APIs 1.0.0.Beta2
>
>
> These APIs are compliant and should be released as .Final.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 15:04:37 2013
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Tue, 15 Oct 2013 15:04:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-133) Expression Language 3.0
	(JSR-341) APIs
In-Reply-To: <JIRA.12487467.1363659115000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12487467.1363659115000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487467.1363659115000.5317.1381863877183@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBEE-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBEE-133:
--------------------------------

    Fix Version/s: JavaEE 7 Spec APIs 1.0.0.CR1
                       (was: JavaEE 7 Spec APIs 1.0.0.Beta2)

    
> Expression Language 3.0 (JSR-341) APIs
> --------------------------------------
>
>                 Key: JBEE-133
>                 URL: https://issues.jboss.org/browse/JBEE-133
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Sub-task
>          Components: jboss-javaee-specs
>            Reporter: Shelly McGowan
>            Assignee: Remy Maucherat
>             Fix For: JavaEE 7 Spec APIs 1.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 15:06:35 2013
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Tue, 15 Oct 2013 15:06:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-97) See if the jstl dependency on
 xalan can be refactored out
In-Reply-To: <JIRA.12451444.1320700577000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12451444.1320700577000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12451444.1320700577000.5322.1381863995905@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBEE-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBEE-97:
-------------------------------

    Fix Version/s: JavaEE 7 Spec APIs 1.0.0.CR1
                       (was: JavaEE 7 Spec APIs 1.0.0.Beta2)

    
> See if the jstl dependency on xalan can be refactored out
> ---------------------------------------------------------
>
>                 Key: JBEE-97
>                 URL: https://issues.jboss.org/browse/JBEE-97
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Enhancement
>          Components: jboss-jstl-api
>    Affects Versions: JavaEE 6 Spec APIs 3.0.0.Beta1
>            Reporter: Paul Gier
>            Assignee: Jason Greene
>             Fix For: JavaEE 7 Spec APIs 1.0.0.CR1
>
>
> The JSTL api has a dependency on the xalan fork which is only available in the JBoss repository.  If this can be refactored out, then the complete set of dependencies will be available in central.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 15:06:36 2013
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Tue, 15 Oct 2013 15:06:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-121) Tracker JIRA for APIs required
 by the Java EE 7 Platform Specification
In-Reply-To: <JIRA.12485867.1362012695000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485867.1362012695000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485867.1362012695000.5325.1381863996243@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBEE-121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBEE-121:
--------------------------------

    Fix Version/s: JavaEE 7 Spec APIs 1.0.0.CR1
                       (was: JavaEE 7 Spec APIs 1.0.0.Beta2)

    
> Tracker JIRA for APIs required by the Java EE 7 Platform Specification
> ----------------------------------------------------------------------
>
>                 Key: JBEE-121
>                 URL: https://issues.jboss.org/browse/JBEE-121
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: jboss-javaee-specs
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>             Fix For: JavaEE 7 Spec APIs 1.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 15:06:36 2013
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Tue, 15 Oct 2013 15:06:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-105) Create a JBoss version of the
 JavaBeans activation framework (javax.activation) API
In-Reply-To: <JIRA.12458289.1328289083000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12458289.1328289083000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12458289.1328289083000.5332.1381863996691@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBEE-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBEE-105:
--------------------------------

    Fix Version/s: JavaEE 7 Spec APIs 1.0.0.CR1
                       (was: JavaEE 7 Spec APIs 1.0.0.Beta2)

    
> Create a JBoss version of the JavaBeans activation framework (javax.activation) API
> -----------------------------------------------------------------------------------
>
>                 Key: JBEE-105
>                 URL: https://issues.jboss.org/browse/JBEE-105
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Feature Request
>          Components: general
>            Reporter: Paul Gier
>            Assignee: Shelly McGowan
>             Fix For: JavaEE 7 Spec APIs 1.0.0.CR1
>
>
> The JBoss jaxr-api jar current depends on the javax.activation package.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 15:28:35 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Tue, 15 Oct 2013 15:28:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2308) Leak of WorkManager and
	BootstrapContext
In-Reply-To: <JIRA.12502210.1380891451000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502210.1380891451000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502210.1380891451000.5402.1381865315628@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen moved JBJCA-1087 to WFLY-2308:
----------------------------------------------

              Project: WildFly  (was: IronJacamar)
                  Key: WFLY-2308  (was: JBJCA-1087)
             Workflow: GIT Pull Request workflow   (was: classic default workflow)
    Affects Version/s: 8.0.0.Beta1
                           (was: 1.1.0.Final)
          Component/s: JCA
                           (was: Core)

    
> Leak of WorkManager and BootstrapContext
> ----------------------------------------
>
>                 Key: WFLY-2308
>                 URL: https://issues.jboss.org/browse/WFLY-2308
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Bartosz Baranowski
>            Assignee: Jesper Pedersen
>
> There seems to be a leak of WorkManager and BootstrapContext clones. 
> NOTE: The clones are not standalone, for instance WorkManagerImpl.shutdown reference is shared among all clones, if one is shutdown, all of them are.
> The coordinators have an internal map of name/id -> [ BootstrapContext | WorkManager ]. They keep clones of default instance in it. In IJ code, deployers invoke coordinator.remove() method to keep it clean. However this does not happen in WFLY/AS7 ( only create is called ). 
> Here is a step by step scenario( more or less ):
> 1. WFLY boots
> 2. WorkManagerService is created( along with WorkManager instance, the default used in WMCoordinator )
> 3. RA is deployed/activated
> 4. IJ checks if there is BootstrapContext/WorkManager under "X", there is none, IJ creates clone of WM from #2 and BootstrapContext,  its stored under "X" in coordinators
> 5. Normal operations, msgs exchange, etc.
> 6. WFLY reload is called
> 7. WM from #2 shutdown() is called, this renders the clone stored under "X" as shutdown as well.
> 8. WFLY boots again
> 9. new WorkManagerService is created( along with WorkManager instance, the default used in WMCoordinator )
> 10. RA is deployed/activate
> 11. IJ checks if there is BootstrapContext/WorkManager under "X", there is, this instance is returned. 
> #11 old instance, which is shutdown since #7, is passed as WorkManager. This explodes:
> {noformat}
> ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 29) MSC000001: Failed to start service jboss.deployment.unit."mdb.jar".component.MDBLifecycleCallback.START: org.jboss.msc.service.StartException in service jboss.deployment.unit."mdb.jar".component.MDBLifecycleCallback.START: java.lang.RuntimeException: javax.resource.spi.work.WorkRejectedException: IJ000263: WorkManager is shutting down
> 	at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:57)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: java.lang.RuntimeException: javax.resource.spi.work.WorkRejectedException: IJ000263: WorkManager is shutting down
> 	at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent.activate(MessageDrivenComponent.java:218)
> 	at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent.start(MessageDrivenComponent.java:189)
> 	at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
> 	... 7 more
> Caused by: javax.resource.spi.work.WorkRejectedException: IJ000263: WorkManager is shutting down
> 	at org.jboss.jca.core.workmanager.WorkManagerImpl.doFirstChecks(WorkManagerImpl.java:776)
> 	at org.jboss.jca.core.workmanager.WorkManagerImpl.scheduleWork(WorkManagerImpl.java:617)
> 	at org.jboss.jca.core.workmanager.WorkManagerImpl.scheduleWork(WorkManagerImpl.java:602)
> 	at org.hornetq.ra.inflow.HornetQActivation.start(HornetQActivation.java:259)
> 	at org.hornetq.ra.HornetQResourceAdapter.endpointActivation(HornetQResourceAdapter.java:167)
> 	at org.jboss.jca.core.rar.EndpointImpl.activate(EndpointImpl.java:191)
> 	at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent.activate(MessageDrivenComponent.java:216)
> 	... 9 more
> {noformat}
> Steps to reproduce:
> 1. Setup an adapter deployment
> 2. reload
> 3. deploy MDB
> The reload OP has small bug, this branch (https://github.com/baranowb/wildfly/tree/WFLY-2217) has it fixed.
> Example test set: 
> {noformat}
> mvn clean install -DallTest -Dtest=CustomBootstrapContextTestCase,GetCallerPrincipalTestCase
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 15:28:35 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Tue, 15 Oct 2013 15:28:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2308) Leak of WorkManager and
	BootstrapContext
In-Reply-To: <JIRA.12502210.1380891451000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502210.1380891451000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502210.1380891451000.5405.1381865315739@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814355#comment-12814355 ] 

Jesper Pedersen commented on WFLY-2308:
---------------------------------------

I'm not seeing any IronJacamar issues here. Note, that if the JCA subsystem is restarted so must the :messaging: one, as it needs the new BC/WM pair
                
> Leak of WorkManager and BootstrapContext
> ----------------------------------------
>
>                 Key: WFLY-2308
>                 URL: https://issues.jboss.org/browse/WFLY-2308
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Bartosz Baranowski
>            Assignee: Jesper Pedersen
>
> There seems to be a leak of WorkManager and BootstrapContext clones. 
> NOTE: The clones are not standalone, for instance WorkManagerImpl.shutdown reference is shared among all clones, if one is shutdown, all of them are.
> The coordinators have an internal map of name/id -> [ BootstrapContext | WorkManager ]. They keep clones of default instance in it. In IJ code, deployers invoke coordinator.remove() method to keep it clean. However this does not happen in WFLY/AS7 ( only create is called ). 
> Here is a step by step scenario( more or less ):
> 1. WFLY boots
> 2. WorkManagerService is created( along with WorkManager instance, the default used in WMCoordinator )
> 3. RA is deployed/activated
> 4. IJ checks if there is BootstrapContext/WorkManager under "X", there is none, IJ creates clone of WM from #2 and BootstrapContext,  its stored under "X" in coordinators
> 5. Normal operations, msgs exchange, etc.
> 6. WFLY reload is called
> 7. WM from #2 shutdown() is called, this renders the clone stored under "X" as shutdown as well.
> 8. WFLY boots again
> 9. new WorkManagerService is created( along with WorkManager instance, the default used in WMCoordinator )
> 10. RA is deployed/activate
> 11. IJ checks if there is BootstrapContext/WorkManager under "X", there is, this instance is returned. 
> #11 old instance, which is shutdown since #7, is passed as WorkManager. This explodes:
> {noformat}
> ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 29) MSC000001: Failed to start service jboss.deployment.unit."mdb.jar".component.MDBLifecycleCallback.START: org.jboss.msc.service.StartException in service jboss.deployment.unit."mdb.jar".component.MDBLifecycleCallback.START: java.lang.RuntimeException: javax.resource.spi.work.WorkRejectedException: IJ000263: WorkManager is shutting down
> 	at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:57)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: java.lang.RuntimeException: javax.resource.spi.work.WorkRejectedException: IJ000263: WorkManager is shutting down
> 	at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent.activate(MessageDrivenComponent.java:218)
> 	at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent.start(MessageDrivenComponent.java:189)
> 	at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
> 	... 7 more
> Caused by: javax.resource.spi.work.WorkRejectedException: IJ000263: WorkManager is shutting down
> 	at org.jboss.jca.core.workmanager.WorkManagerImpl.doFirstChecks(WorkManagerImpl.java:776)
> 	at org.jboss.jca.core.workmanager.WorkManagerImpl.scheduleWork(WorkManagerImpl.java:617)
> 	at org.jboss.jca.core.workmanager.WorkManagerImpl.scheduleWork(WorkManagerImpl.java:602)
> 	at org.hornetq.ra.inflow.HornetQActivation.start(HornetQActivation.java:259)
> 	at org.hornetq.ra.HornetQResourceAdapter.endpointActivation(HornetQResourceAdapter.java:167)
> 	at org.jboss.jca.core.rar.EndpointImpl.activate(EndpointImpl.java:191)
> 	at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent.activate(MessageDrivenComponent.java:216)
> 	... 9 more
> {noformat}
> Steps to reproduce:
> 1. Setup an adapter deployment
> 2. reload
> 3. deploy MDB
> The reload OP has small bug, this branch (https://github.com/baranowb/wildfly/tree/WFLY-2217) has it fixed.
> Example test set: 
> {noformat}
> mvn clean install -DallTest -Dtest=CustomBootstrapContextTestCase,GetCallerPrincipalTestCase
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 15:30:36 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Tue, 15 Oct 2013 15:30:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2308) Leak of WorkManager and
	BootstrapContext
In-Reply-To: <JIRA.12502210.1380891451000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502210.1380891451000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502210.1380891451000.5417.1381865436476@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen reassigned WFLY-2308:
-------------------------------------

    Assignee: Stefano Maestri  (was: Jesper Pedersen)

    
> Leak of WorkManager and BootstrapContext
> ----------------------------------------
>
>                 Key: WFLY-2308
>                 URL: https://issues.jboss.org/browse/WFLY-2308
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Bartosz Baranowski
>            Assignee: Stefano Maestri
>
> There seems to be a leak of WorkManager and BootstrapContext clones. 
> NOTE: The clones are not standalone, for instance WorkManagerImpl.shutdown reference is shared among all clones, if one is shutdown, all of them are.
> The coordinators have an internal map of name/id -> [ BootstrapContext | WorkManager ]. They keep clones of default instance in it. In IJ code, deployers invoke coordinator.remove() method to keep it clean. However this does not happen in WFLY/AS7 ( only create is called ). 
> Here is a step by step scenario( more or less ):
> 1. WFLY boots
> 2. WorkManagerService is created( along with WorkManager instance, the default used in WMCoordinator )
> 3. RA is deployed/activated
> 4. IJ checks if there is BootstrapContext/WorkManager under "X", there is none, IJ creates clone of WM from #2 and BootstrapContext,  its stored under "X" in coordinators
> 5. Normal operations, msgs exchange, etc.
> 6. WFLY reload is called
> 7. WM from #2 shutdown() is called, this renders the clone stored under "X" as shutdown as well.
> 8. WFLY boots again
> 9. new WorkManagerService is created( along with WorkManager instance, the default used in WMCoordinator )
> 10. RA is deployed/activate
> 11. IJ checks if there is BootstrapContext/WorkManager under "X", there is, this instance is returned. 
> #11 old instance, which is shutdown since #7, is passed as WorkManager. This explodes:
> {noformat}
> ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 29) MSC000001: Failed to start service jboss.deployment.unit."mdb.jar".component.MDBLifecycleCallback.START: org.jboss.msc.service.StartException in service jboss.deployment.unit."mdb.jar".component.MDBLifecycleCallback.START: java.lang.RuntimeException: javax.resource.spi.work.WorkRejectedException: IJ000263: WorkManager is shutting down
> 	at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:57)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: java.lang.RuntimeException: javax.resource.spi.work.WorkRejectedException: IJ000263: WorkManager is shutting down
> 	at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent.activate(MessageDrivenComponent.java:218)
> 	at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent.start(MessageDrivenComponent.java:189)
> 	at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
> 	... 7 more
> Caused by: javax.resource.spi.work.WorkRejectedException: IJ000263: WorkManager is shutting down
> 	at org.jboss.jca.core.workmanager.WorkManagerImpl.doFirstChecks(WorkManagerImpl.java:776)
> 	at org.jboss.jca.core.workmanager.WorkManagerImpl.scheduleWork(WorkManagerImpl.java:617)
> 	at org.jboss.jca.core.workmanager.WorkManagerImpl.scheduleWork(WorkManagerImpl.java:602)
> 	at org.hornetq.ra.inflow.HornetQActivation.start(HornetQActivation.java:259)
> 	at org.hornetq.ra.HornetQResourceAdapter.endpointActivation(HornetQResourceAdapter.java:167)
> 	at org.jboss.jca.core.rar.EndpointImpl.activate(EndpointImpl.java:191)
> 	at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent.activate(MessageDrivenComponent.java:216)
> 	... 9 more
> {noformat}
> Steps to reproduce:
> 1. Setup an adapter deployment
> 2. reload
> 3. deploy MDB
> The reload OP has small bug, this branch (https://github.com/baranowb/wildfly/tree/WFLY-2217) has it fixed.
> Example test set: 
> {noformat}
> mvn clean install -DallTest -Dtest=CustomBootstrapContextTestCase,GetCallerPrincipalTestCase
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 15:36:37 2013
From: jira-events at lists.jboss.org (Gurinder Randhawa (JIRA))
Date: Tue, 15 Oct 2013 15:36:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-185) ClassCastException at
	ConditionEvaluator
In-Reply-To: <JIRA.12495435.1372690482000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495435.1372690482000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495435.1372690482000.5448.1381865797664@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814358#comment-12814358 ] 

Gurinder Randhawa commented on DROOLS-185:
------------------------------------------

We are seeing this issue as well, it started happening after we updated our drools libraries from 5.3.0 -> 5.5.0. 
                
> ClassCastException at ConditionEvaluator
> ----------------------------------------
>
>                 Key: DROOLS-185
>                 URL: https://issues.jboss.org/browse/DROOLS-185
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Sergey Alaev
>            Assignee: Mario Fusco
>
> Stacktrace:
> Caused by: java.lang.ClassCastException: ***** cannot be cast to ******
> 	at ConditionEvaluator443abf2927ca4f64a4ad86407ae34799.evaluate(Unknown Source)
> 	at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:200)
> 	at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:157)
> 	at org.drools.reteoo.FromNode.checkConstraintsAndPropagate(FromNode.java:318)
> 	at org.drools.reteoo.FromNode.assertLeftTuple(FromNode.java:164)
> 	at org.drools.reteoo.CompositeLeftTupleSinkAdapter.doPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:232)
> 	at org.drools.reteoo.CompositeLeftTupleSinkAdapter.createAndPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:116)
> 	at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:154)
> 	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:59)
> Reason:
> ConditionEvaluator seems to be using lazy initializing and then caches generated class to evaluate this expression with another arguments.
> Given following:
> interface A {
>    String getString();
> }
> interface B {
>    String getString();
> }
> class X implements B, A {}
> class Y implements A{}
> rule "test rule"
> when:
>      A(string != null)
> then:
> end
> When rule engine is called for the first time with instance of class X, ConditionEvaluator will bind itself to first found interface implementing method getString(), i.e. interface B.
> Thus second call with instance of class Y will cause ClassCastException of casting Y to B.
> Solution: force MVEL to bind bytecode generated methods to class/interface declared in the rule explicitly, in our case - to interface A.
> Quickfix: use following declaration of class X:
> class X implements A, B {}
> Because ConditionEvaluator binds to first available interface, it will bind now to correct interface - to interface A.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 15:46:36 2013
From: jira-events at lists.jboss.org (Gurinder Randhawa (JIRA))
Date: Tue, 15 Oct 2013 15:46:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-185) ClassCastException at
	ConditionEvaluator
In-Reply-To: <JIRA.12495435.1372690482000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495435.1372690482000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495435.1372690482000.5473.1381866396256@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814358#comment-12814358 ] 

Gurinder Randhawa edited comment on DROOLS-185 at 10/15/13 3:44 PM:
--------------------------------------------------------------------

We are seeing this issue as well, it started happening after we updated our drools libraries from 5.3.0 -> 5.5.0. 

Will there be a patch available soon? Changing out domain model objects isn't a quick fix. Please advise. Thankyou!
                
      was (Author: randhawag):
    We are seeing this issue as well, it started happening after we updated our drools libraries from 5.3.0 -> 5.5.0. 
                  
> ClassCastException at ConditionEvaluator
> ----------------------------------------
>
>                 Key: DROOLS-185
>                 URL: https://issues.jboss.org/browse/DROOLS-185
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Sergey Alaev
>            Assignee: Mario Fusco
>
> Stacktrace:
> Caused by: java.lang.ClassCastException: ***** cannot be cast to ******
> 	at ConditionEvaluator443abf2927ca4f64a4ad86407ae34799.evaluate(Unknown Source)
> 	at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:200)
> 	at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:157)
> 	at org.drools.reteoo.FromNode.checkConstraintsAndPropagate(FromNode.java:318)
> 	at org.drools.reteoo.FromNode.assertLeftTuple(FromNode.java:164)
> 	at org.drools.reteoo.CompositeLeftTupleSinkAdapter.doPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:232)
> 	at org.drools.reteoo.CompositeLeftTupleSinkAdapter.createAndPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:116)
> 	at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:154)
> 	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:59)
> Reason:
> ConditionEvaluator seems to be using lazy initializing and then caches generated class to evaluate this expression with another arguments.
> Given following:
> interface A {
>    String getString();
> }
> interface B {
>    String getString();
> }
> class X implements B, A {}
> class Y implements A{}
> rule "test rule"
> when:
>      A(string != null)
> then:
> end
> When rule engine is called for the first time with instance of class X, ConditionEvaluator will bind itself to first found interface implementing method getString(), i.e. interface B.
> Thus second call with instance of class Y will cause ClassCastException of casting Y to B.
> Solution: force MVEL to bind bytecode generated methods to class/interface declared in the rule explicitly, in our case - to interface A.
> Quickfix: use following declaration of class X:
> class X implements A, B {}
> Because ConditionEvaluator binds to first available interface, it will bind now to correct interface - to interface A.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 16:23:35 2013
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Tue, 15 Oct 2013 16:23:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2309) Fix description resolvers for
 logging extension
In-Reply-To: <JIRA.12503137.1381868599685@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503137.1381868599685@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503137.1381868599685.5681.1381868615494@jira02.app.mwc.hst.phx2.redhat.com>

James Perkins created WFLY-2309:
-----------------------------------

             Summary: Fix description resolvers for logging extension
                 Key: WFLY-2309
                 URL: https://issues.jboss.org/browse/WFLY-2309
             Project: WildFly
          Issue Type: Task
          Components: Logging
            Reporter: James Perkins
            Assignee: James Perkins
            Priority: Minor
             Fix For: 8.0.0.CR1


The logging extensions description resolver is a mess. In some cases doesn't allow the same attribute name to be used resources and get a different description.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 16:34:35 2013
From: jira-events at lists.jboss.org (Paul Alesius (JIRA))
Date: Tue, 15 Oct 2013 16:34:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2310) JDBC driver not deployed from
 exploded EAR, but works with packaged .ear
In-Reply-To: <JIRA.12503140.1381869227387@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503140.1381869227387@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503140.1381869227387.5716.1381869275633@jira02.app.mwc.hst.phx2.redhat.com>

Paul Alesius created WFLY-2310:
----------------------------------

             Summary: JDBC driver not deployed from exploded EAR, but works with packaged .ear
                 Key: WFLY-2310
                 URL: https://issues.jboss.org/browse/WFLY-2310
             Project: WildFly
          Issue Type: Bug
          Components: EE, JCA
    Affects Versions: 8.0.0.Beta1
            Reporter: Paul Alesius
            Assignee: David Lloyd


The jdbc driver in an exploded EAR isn't picked up by wildfly, it causes problems when deploying from eclipse.

It is picked up when deployed as a zipped .ear.

Example jboss-as.xml in the ear with xa driver:
<driver>testear-0.0.1-SNAPSHOT.ear_org.postgresql.Driver_9_2</driver>

You should see a message when the ear is deployed showing that the JDBC is picked up byt he server. This appears only when the .ear is zipped.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 16:38:35 2013
From: jira-events at lists.jboss.org (Paul Alesius (JIRA))
Date: Tue, 15 Oct 2013 16:38:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2310) JDBC driver not deployed from
 exploded EAR, but works with packaged .ear
In-Reply-To: <JIRA.12503140.1381869227000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503140.1381869227000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503140.1381869227000.5719.1381869515593@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Alesius updated WFLY-2310:
-------------------------------

    Attachment: testear.zip


Example empty ear project with driver that isn't picked up when deployed in eclipse, but works when packaged as .ear.
                
> JDBC driver not deployed from exploded EAR, but works with packaged .ear
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2310
>                 URL: https://issues.jboss.org/browse/WFLY-2310
>             Project: WildFly
>          Issue Type: Bug
>          Components: EE, JCA
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Paul Alesius
>            Assignee: David Lloyd
>              Labels: deployer,, exploded
>         Attachments: testear.zip
>
>
> The jdbc driver in an exploded EAR isn't picked up by wildfly, it causes problems when deploying from eclipse.
> It is picked up when deployed as a zipped .ear.
> Example jboss-as.xml in the ear with xa driver:
> <driver>testear-0.0.1-SNAPSHOT.ear_org.postgresql.Driver_9_2</driver>
> You should see a message when the ear is deployed showing that the JDBC is picked up byt he server. This appears only when the .ear is zipped.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 16:38:35 2013
From: jira-events at lists.jboss.org (Paul Alesius (JIRA))
Date: Tue, 15 Oct 2013 16:38:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2310) JDBC driver not deployed from
 exploded EAR, but works with packaged .ear
In-Reply-To: <JIRA.12503140.1381869227000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503140.1381869227000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503140.1381869227000.5721.1381869515694@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814396#comment-12814396 ] 

Paul Alesius edited comment on WFLY-2310 at 10/15/13 4:37 PM:
--------------------------------------------------------------

Added example testear project with driver that isn't picked up when deployed in eclipse, but works when packaged as .ear.
                
      was (Author: paul_alesius):
    Example empty ear project with driver that isn't picked up when deployed in eclipse, but works when packaged as .ear.
                  
> JDBC driver not deployed from exploded EAR, but works with packaged .ear
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2310
>                 URL: https://issues.jboss.org/browse/WFLY-2310
>             Project: WildFly
>          Issue Type: Bug
>          Components: EE, JCA
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Paul Alesius
>            Assignee: David Lloyd
>              Labels: deployer,, exploded
>         Attachments: testear.zip
>
>
> The jdbc driver in an exploded EAR isn't picked up by wildfly, it causes problems when deploying from eclipse.
> It is picked up when deployed as a zipped .ear.
> Example jboss-as.xml in the ear with xa driver:
> <driver>testear-0.0.1-SNAPSHOT.ear_org.postgresql.Driver_9_2</driver>
> You should see a message when the ear is deployed showing that the JDBC is picked up byt he server. This appears only when the .ear is zipped.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 17:01:37 2013
From: jira-events at lists.jboss.org (Gurinder Randhawa (JIRA))
Date: Tue, 15 Oct 2013 17:01:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-215) Corrupted Working/Production
	memory
In-Reply-To: <JIRA.12498476.1376388952000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498476.1376388952000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498476.1376388952000.5780.1381870897237@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814405#comment-12814405 ] 

Gurinder Randhawa commented on DROOLS-215:
------------------------------------------

When is Drools 5.6.x being released? Does this issue occur in 5.4.x? 

If anyone case provide any direction in how we can resolve this bug, that would be most helpful. Cheers.
                
> Corrupted Working/Production memory
> -----------------------------------
>
>                 Key: DROOLS-215
>                 URL: https://issues.jboss.org/browse/DROOLS-215
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Ales Dolecek
>            Assignee: Mark Proctor
>         Attachments: ConcurrentNodeMemories.java
>
>
> Experienced ClassCastException mixing BetaMemory and AlphaMemory. There is debate in the mailing list/forum. The problem seems to be related to dymanic updates of knowledgebase.
> Saddly there is no deterministic way how to reproduce the issue, but that should not prevent tracking it here.
> Stack trace from my project:
> java.lang.ClassCastException: org.drools.reteoo.BetaMemory cannot be cast to org.drools.reteoo.AlphaNode$AlphaMemory
>         at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:136) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:497) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:382) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:350) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:311) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:192) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:186) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at cz.nextiraone.screening.rules.screening.Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1.defaultConsequence(Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1.java:7) ~[na
> :na]
>         at cz.nextiraone.screening.rules.screening.Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1DefaultConsequenceInvokerGenerated.evaluate(Unknown Source) ~[na:na]
>         at cz.nextiraone.screening.rules.screening.Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1DefaultConsequenceInvoker.evaluate(Unknown Source) ~[na:na]
>         at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1287) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1221) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1456) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:710) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:674) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:230) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 17:41:35 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Tue, 15 Oct 2013 17:41:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-215) Corrupted Working/Production
	memory
In-Reply-To: <JIRA.12498476.1376388952000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498476.1376388952000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498476.1376388952000.5850.1381873295818@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814411#comment-12814411 ] 

Davide Sottara commented on DROOLS-215:
---------------------------------------

5.6 is ready to be built. The conditions for this particular occurrence of the CCE could never be reproduced, so we can only hope that this was fixed,
or there was a problem in the user's code. If you are experiencing this problem and have any hint about what/when it may happen, please let use know as soon as possible
Thanks
Davide
                
> Corrupted Working/Production memory
> -----------------------------------
>
>                 Key: DROOLS-215
>                 URL: https://issues.jboss.org/browse/DROOLS-215
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Ales Dolecek
>            Assignee: Mark Proctor
>         Attachments: ConcurrentNodeMemories.java
>
>
> Experienced ClassCastException mixing BetaMemory and AlphaMemory. There is debate in the mailing list/forum. The problem seems to be related to dymanic updates of knowledgebase.
> Saddly there is no deterministic way how to reproduce the issue, but that should not prevent tracking it here.
> Stack trace from my project:
> java.lang.ClassCastException: org.drools.reteoo.BetaMemory cannot be cast to org.drools.reteoo.AlphaNode$AlphaMemory
>         at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:136) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:497) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:382) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:350) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:311) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:192) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:186) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at cz.nextiraone.screening.rules.screening.Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1.defaultConsequence(Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1.java:7) ~[na
> :na]
>         at cz.nextiraone.screening.rules.screening.Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1DefaultConsequenceInvokerGenerated.evaluate(Unknown Source) ~[na:na]
>         at cz.nextiraone.screening.rules.screening.Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1DefaultConsequenceInvoker.evaluate(Unknown Source) ~[na:na]
>         at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1287) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1221) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1456) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:710) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:674) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:230) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 17:55:35 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 15 Oct 2013 17:55:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2311) Confusing password
 requirements prompt in add-user.sh
In-Reply-To: <JIRA.12503144.1381874096580@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503144.1381874096580@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503144.1381874096580.5860.1381874135946@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-2311:
--------------------------------------

             Summary: Confusing password requirements prompt in add-user.sh
                 Key: WFLY-2311
                 URL: https://issues.jboss.org/browse/WFLY-2311
             Project: WildFly
          Issue Type: Bug
          Components: Security
    Affects Versions: 8.0.0.Beta1
            Reporter: Brian Stansberry
            Assignee: Darran Lofthouse


The add-user script prompt says the requirements for a password will be listed, but nothing is listed.

What type of user do you wish to add? 
 a) Management User (mgmt-users.properties) 
 b) Application User (application-users.properties)
(a): a

Enter the details of the new user to add.
Using realm 'ManagementRealm' as discovered from the existing property files.
Username : bstansberry
Password requirements are listed below. To modify these restrictions edit the add-user.properties configuration file.
Password : 


If there are no requirements, then some placeholder requirement like <no restrictions on password format> should be output.

It seems there is at least a non-null/empty requirement, as I just created a user with 'b' as the password, but no password at all failed. So that requirement should be reported.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 18:07:35 2013
From: jira-events at lists.jboss.org (Gurinder Randhawa (JIRA))
Date: Tue, 15 Oct 2013 18:07:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-215) Corrupted Working/Production
	memory
In-Reply-To: <JIRA.12498476.1376388952000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498476.1376388952000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498476.1376388952000.5884.1381874855946@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814416#comment-12814416 ] 

Gurinder Randhawa commented on DROOLS-215:
------------------------------------------

Thanks Davide for quick reply.

I can safely say, this issue still occurs with drools-core-5.6.0-20130913.043517-15.jar and related jars, our specific stack trace is below. It does not occur with Drools 5.3.x from which we had to upgrade to fix another unrelated issue. I wish I could spend time building a test case, but it would take us quite some time to setup a unit test on this issue. We could try version 5.4.x, do you know if this issue started in v5.5?

2013-10-15 14:59:53,942 ERROR [STDERR] Exception executing consequence for rule "10_ServiceRequest_InsertRefData" in sales.rules.sys.setup: java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.Long
2013-10-15 14:59:53,944 ERROR [STDERR]  at org.drools.runtime.rule.impl.DefaultConsequenceExceptionHandler.handleException(DefaultConsequenceExceptionHandler.java:39)
2013-10-15 14:59:53,944 ERROR [STDERR]  at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1291)
2013-10-15 14:59:53,944 ERROR [STDERR]  at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1215)
2013-10-15 14:59:53,944 ERROR [STDERR]  at org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1450)
2013-10-15 14:59:53,944 ERROR [STDERR]  at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:703)
2013-10-15 14:59:53,944 ERROR [STDERR]  at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:667)
2013-10-15 14:59:53,944 ERROR [STDERR]  at tu.venture.domain.interfaces.RulesRequestProcessor.processByStatefullRules(RulesRequestProcessor.java:68)
2013-10-15 14:59:53,944 ERROR [STDERR]  at tu.venture.sales.ejb.business.SalesPriceProcessor.process(SalesPriceProcessor.java:106)
2013-10-15 14:59:53,944 ERROR [STDERR]  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
2013-10-15 14:59:53,944 ERROR [STDERR]  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
2013-10-15 14:59:53,944 ERROR [STDERR]  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
2013-10-15 14:59:53,944 ERROR [STDERR]  at java.lang.reflect.Method.invoke(Method.java:597)
                
> Corrupted Working/Production memory
> -----------------------------------
>
>                 Key: DROOLS-215
>                 URL: https://issues.jboss.org/browse/DROOLS-215
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Ales Dolecek
>            Assignee: Mark Proctor
>         Attachments: ConcurrentNodeMemories.java
>
>
> Experienced ClassCastException mixing BetaMemory and AlphaMemory. There is debate in the mailing list/forum. The problem seems to be related to dymanic updates of knowledgebase.
> Saddly there is no deterministic way how to reproduce the issue, but that should not prevent tracking it here.
> Stack trace from my project:
> java.lang.ClassCastException: org.drools.reteoo.BetaMemory cannot be cast to org.drools.reteoo.AlphaNode$AlphaMemory
>         at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:136) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:497) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:382) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:350) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:311) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:192) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:186) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at cz.nextiraone.screening.rules.screening.Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1.defaultConsequence(Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1.java:7) ~[na
> :na]
>         at cz.nextiraone.screening.rules.screening.Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1DefaultConsequenceInvokerGenerated.evaluate(Unknown Source) ~[na:na]
>         at cz.nextiraone.screening.rules.screening.Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1DefaultConsequenceInvoker.evaluate(Unknown Source) ~[na:na]
>         at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1287) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1221) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1456) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:710) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:674) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:230) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 18:11:35 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Tue, 15 Oct 2013 18:11:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-215) Corrupted Working/Production
	memory
In-Reply-To: <JIRA.12498476.1376388952000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498476.1376388952000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498476.1376388952000.5891.1381875095549@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814417#comment-12814417 ] 

Davide Sottara commented on DROOLS-215:
---------------------------------------

wait a second.. this is a different CCE... it seems an exception in the RHS of one of your rules.
It's different from the internal CCE reported in this ticket. Can you check that?

                
> Corrupted Working/Production memory
> -----------------------------------
>
>                 Key: DROOLS-215
>                 URL: https://issues.jboss.org/browse/DROOLS-215
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Ales Dolecek
>            Assignee: Mark Proctor
>         Attachments: ConcurrentNodeMemories.java
>
>
> Experienced ClassCastException mixing BetaMemory and AlphaMemory. There is debate in the mailing list/forum. The problem seems to be related to dymanic updates of knowledgebase.
> Saddly there is no deterministic way how to reproduce the issue, but that should not prevent tracking it here.
> Stack trace from my project:
> java.lang.ClassCastException: org.drools.reteoo.BetaMemory cannot be cast to org.drools.reteoo.AlphaNode$AlphaMemory
>         at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:136) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:497) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:382) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:350) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:311) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:192) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:186) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at cz.nextiraone.screening.rules.screening.Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1.defaultConsequence(Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1.java:7) ~[na
> :na]
>         at cz.nextiraone.screening.rules.screening.Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1DefaultConsequenceInvokerGenerated.evaluate(Unknown Source) ~[na:na]
>         at cz.nextiraone.screening.rules.screening.Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1DefaultConsequenceInvoker.evaluate(Unknown Source) ~[na:na]
>         at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1287) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1221) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1456) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:710) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:674) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:230) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 18:15:36 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Tue, 15 Oct 2013 18:15:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-215) Corrupted Working/Production
	memory
In-Reply-To: <JIRA.12498476.1376388952000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498476.1376388952000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498476.1376388952000.5896.1381875336610@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814417#comment-12814417 ] 

Davide Sottara edited comment on DROOLS-215 at 10/15/13 6:14 PM:
-----------------------------------------------------------------

wait a second.. this is a different CCE... it seems an exception in the RHS of one of your rules.
It's different from the internal CCE reported in this ticket. Can you check that?
Could you at least post the full stack trace, so that we can see the root exception?
Thanks

                
      was (Author: dsotty):
    wait a second.. this is a different CCE... it seems an exception in the RHS of one of your rules.
It's different from the internal CCE reported in this ticket. Can you check that?

                  
> Corrupted Working/Production memory
> -----------------------------------
>
>                 Key: DROOLS-215
>                 URL: https://issues.jboss.org/browse/DROOLS-215
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Ales Dolecek
>            Assignee: Mark Proctor
>         Attachments: ConcurrentNodeMemories.java
>
>
> Experienced ClassCastException mixing BetaMemory and AlphaMemory. There is debate in the mailing list/forum. The problem seems to be related to dymanic updates of knowledgebase.
> Saddly there is no deterministic way how to reproduce the issue, but that should not prevent tracking it here.
> Stack trace from my project:
> java.lang.ClassCastException: org.drools.reteoo.BetaMemory cannot be cast to org.drools.reteoo.AlphaNode$AlphaMemory
>         at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:136) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:497) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:382) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:350) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:311) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:192) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:186) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at cz.nextiraone.screening.rules.screening.Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1.defaultConsequence(Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1.java:7) ~[na
> :na]
>         at cz.nextiraone.screening.rules.screening.Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1DefaultConsequenceInvokerGenerated.evaluate(Unknown Source) ~[na:na]
>         at cz.nextiraone.screening.rules.screening.Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1DefaultConsequenceInvoker.evaluate(Unknown Source) ~[na:na]
>         at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1287) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1221) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1456) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:710) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:674) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:230) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 18:15:36 2013
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Tue, 15 Oct 2013 18:15:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-215) Corrupted Working/Production
	memory
In-Reply-To: <JIRA.12498476.1376388952000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498476.1376388952000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498476.1376388952000.5902.1381875336933@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814418#comment-12814418 ] 

Mark Proctor commented on DROOLS-215:
-------------------------------------

"I wish I could spend time building a test case, but it would take us quite some time to setup a unit test on this issue."
Could you paste the rules? or the offending rules? There is nothing in that stack trace that can help us, you need to unwrap it to see what he root exception is.

                
> Corrupted Working/Production memory
> -----------------------------------
>
>                 Key: DROOLS-215
>                 URL: https://issues.jboss.org/browse/DROOLS-215
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Ales Dolecek
>            Assignee: Mark Proctor
>         Attachments: ConcurrentNodeMemories.java
>
>
> Experienced ClassCastException mixing BetaMemory and AlphaMemory. There is debate in the mailing list/forum. The problem seems to be related to dymanic updates of knowledgebase.
> Saddly there is no deterministic way how to reproduce the issue, but that should not prevent tracking it here.
> Stack trace from my project:
> java.lang.ClassCastException: org.drools.reteoo.BetaMemory cannot be cast to org.drools.reteoo.AlphaNode$AlphaMemory
>         at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:136) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:497) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:382) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:350) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:311) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:192) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:186) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at cz.nextiraone.screening.rules.screening.Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1.defaultConsequence(Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1.java:7) ~[na
> :na]
>         at cz.nextiraone.screening.rules.screening.Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1DefaultConsequenceInvokerGenerated.evaluate(Unknown Source) ~[na:na]
>         at cz.nextiraone.screening.rules.screening.Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1DefaultConsequenceInvoker.evaluate(Unknown Source) ~[na:na]
>         at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1287) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1221) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1456) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:710) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:674) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:230) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 18:35:37 2013
From: jira-events at lists.jboss.org (Gurinder Randhawa (JIRA))
Date: Tue, 15 Oct 2013 18:35:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-215) Corrupted Working/Production
	memory
In-Reply-To: <JIRA.12498476.1376388952000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498476.1376388952000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498476.1376388952000.5913.1381876537056@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814420#comment-12814420 ] 

Gurinder Randhawa commented on DROOLS-215:
------------------------------------------

Yes its occurring on RHS on one of our rules which is just inserting java object into session. The first invocation of our stateless request fires OK. The second subsequent one fails. We are an insurance company, the data below is generated in our price request java service. Hope this helps!!

I am posting the specific rule and domain object its inserting.

//
// Insert reference data
//
rule "10_ServiceRequest_InsertRefData"
    auto-focus true
    no-loop
	salience 10000
when
    not(exists (RefData()))
then
    Map<String, RefData> rfMap = RefDataCacheFactory.getRefDataCache().getRefDataMap();
    for(RefData rd : rfMap.values()){
        if(rd.isActive()){
            insert(rd);
        }
    }

end


//Domain object
@Embeddable
@XmlType(propOrder={})
public class RefData implements Flagged, Referenceable, Nameable, Sortable, RefIdAdaptable {

    private static final long serialVersionUID = -2247172391015849722L;

    @Field 
    private String name;
    @Field 
    private String refId;
    @Field 
    private String code;
    private String descr;
    private String groupRefId;
    private boolean activeFlag;
    private String standardType;
    private Long standardCodeNumber;
    private Long sortOrder;

    public RefData() {
    }

    public RefData(String refId,  String code, String name, String descr, String groupRefId,  boolean activeFlag,
            String standardType, Long standardCodeNumber,  Long sortOrder) {
        super();
        this.refId = refId;
        this.code = code;
        this.name = name;
        this.descr = descr;
        this.groupRefId = groupRefId;
        this.activeFlag = activeFlag;
        this.standardType = standardType;
        this.standardCodeNumber = standardCodeNumber;
        this.sortOrder = sortOrder;
    }
    
    @org.hibernate.validator.Length(max = 100)
    @Column(name = "DESCR", length = 100)
    @Size(max = 100)
    public String getDescr() {
        return descr;
    }

    public void setDescr(String descr) {
        this.descr = descr;
    }

    @Transient
    @XmlAttribute
    public String getGroupRefId() {
        return groupRefId;
    }

    public void setGroupRefId(String groupRefId) {
        this.groupRefId = groupRefId;
    }

    @org.hibernate.validator.Length(max = 50)
    @org.hibernate.validator.NotNull
    @Column(name = "NAME", nullable = false, length = 50)
    @NotNull
    @Size(max = 50)
    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    @Column(name = "STATUS_FLAG", nullable = false, length = 1)
    @Type(type = "yes_no")
    @XmlTransient
    public boolean getActiveFlag() {
        return activeFlag;
    }

    public void setActiveFlag(boolean activeFlag) {
        this.activeFlag = activeFlag;
    }

    @Digits(integer = 2, fraction = 0)
    @Column(name = "SORT_ORDER", precision = 2, scale = 0)
    @XmlTransient
    public Long getSortOrder() {
        return this.sortOrder;
    }

    public void setSortOrder(Long sortOrder) {
        this.sortOrder = sortOrder;
    }

    @Column(name = "STANDARD_TYPE")
    @XmlTransient
    public String getStandardType() {
        return standardType;
    }

    public void setStandardType(String standardType) {
        this.standardType = standardType;
    }

    @Column(name = "STANDARD_CODE_NUMBER")
    @XmlTransient
    public Long getStandardCodeNumber() {
        return standardCodeNumber;
    }

    public void setStandardCodeNumber(Long standardCodeNumber) {
        this.standardCodeNumber = standardCodeNumber;
    }

    @org.hibernate.validator.NotNull
    @Column(name = "REF_ID", unique = true, nullable = false, length = 45)
    @NotNull
    @Size(max = 45)
    @XmlAttribute
    public String getRefId() {
        return refId;
    }

    public void setRefId(String refId) {
        if(refId != null && this.refId != null && this.refId.trim().length() > 0 && !this.refId.equals(refId)){
            throw new RuntimeException("RefId can't be updated!");
        }

        if(refId != null && refId.trim().length() > 0){
            this.refId = refId.trim().toUpperCase();
        }
    }

    
    /**
     * @see tu.venture.common.dao.util.RefIdAdaptable#generateRefId()
     */
    @Override
    public void generateRefId() {        
        if(this.refId == null || this.refId.length() == 0){
            this.setRefId(String.format("%s-%s", this.getGroupRefId(), this.getCode()));           
        }        
    }
    
    @org.hibernate.validator.NotNull
    @Column(name = "CODE", length = 45)
    @Size(max = 45)
    @NotNull
    @XmlElement(required=true)
    public String getCode(){
        return code;
    }

    public void setCode(String code) {
        this.code = code;
    }

    @Transient
    @XmlTransient
    public ActivationStatusEnum getStatus() {
        if (getActiveFlag() == true) {
            return ActivationStatusEnum.ACTIVE;
        } else {
            return ActivationStatusEnum.INACTIVE;
        }
    }

    @Transient
    public void setStatus(ActivationStatusEnum status) {
        if (status == ActivationStatusEnum.ACTIVE) {
            setActiveFlag(true);
        } else {
            setActiveFlag(false);
        }
    }

    @Transient
    public boolean isActive() {
        if (getActiveFlag() == true) {
            return true;
        } else {
            return false;
        }
    }

    @Transient
    public boolean isInactive() {
        if (getActiveFlag() == true) {
            return false;
        } else {
            return true;
        }
    }

    @Transient
    public boolean isNew() {
        return false; // activeFlag is never 'new'
    }

    @Transient
    public boolean isPending() {
        return false; // activeFlag is never 'pending'
    }

    @Override
    public <T extends Referenceable> T deepClone(boolean resetRefIds) throws IOException, ClassNotFoundException {
        return ReferenceableBase.deepClone((T)this, false); // never reset RefId for RefData
    }


    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;

        RefData refData = (RefData) o;

        if (activeFlag != refData.activeFlag) return false;
        if (groupRefId != null ? !groupRefId.equals(refData.groupRefId) : refData.groupRefId != null) return false;
        if (code != null ? !code.equals(refData.code) : refData.code != null) return false;
        if (name != null ? !name.equals(refData.name) : refData.name != null) return false;
        if (refId != null ? !refId.equals(refData.refId) : refData.refId != null) return false;
        if (standardCodeNumber != null ? !standardCodeNumber.equals(refData.standardCodeNumber) : refData.standardCodeNumber != null) return false;
        if (standardType != null ? !standardType.equals(refData.standardType) : refData.standardType != null) return false;
        if (sortOrder != null ? !sortOrder.equals(refData.sortOrder) : refData.sortOrder != null) return false;
        
        return true;
    }

    @Override
    public int hashCode() {
        int result = groupRefId != null ? groupRefId.hashCode() : 0;
        result = 31 * result + (code != null ? code.hashCode() : 0);
        result = 31 * result + (name != null ? name.hashCode() : 0);
        result = 31 * result + (activeFlag ? 1 : 0);
        result = 31 * result + (standardType != null ? standardType.hashCode() : 0);
        result = 31 * result + (standardCodeNumber != null ? standardCodeNumber.hashCode() : 0);
        result = 31 * result + (refId != null ? refId.hashCode() : 0);
        result = 31 * result + (sortOrder != null ? sortOrder.hashCode() : 0);
        return result;
    }
}



========Full stack trace=========
2013-10-15 15:20:23,516 INFO  [tu.venture.sales.drools.util.RulesHelper] 1025_PriceContext_InsertTrip: Trip [refId='null', cost=null, destination=null, reservation=null, bookingDate=null, arrivalDate=null, startDate=Tue Oct 15 00:00:00 PDT 2013, endDate=Tue Nov 05 00:00:00 PST 2013]
2013-10-15 15:20:23,516 INFO  [tu.venture.sales.drools.util.RulesHelper] 1010_PriceContext_InsertInsureds: 1
2013-10-15 15:20:23,517 INFO  [tu.venture.sales.drools.util.RulesHelper] 1000_PriceContext_InsertSelectedProductAgreement: TU-PRODUCTAGREEMENT-2000433
2013-10-15 15:20:23,517 INFO  [tu.venture.sales.drools.util.RulesHelper] 5005_InsertProductPlansBasedOnInsuredType
2013-10-15 15:20:23,752 ERROR [STDERR] Exception executing consequence for rule "10_ServiceRequest_InsertRefData" in sales.rules.sys.setup: java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.Long
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.drools.runtime.rule.impl.DefaultConsequenceExceptionHandler.handleException(DefaultConsequenceExceptionHandler.java:39)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1283)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1209)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1442)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:710)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:674)
2013-10-15 15:20:23,754 ERROR [STDERR]  at tu.venture.domain.interfaces.RulesRequestProcessor.processByStatefullRules(RulesRequestProcessor.java:68)
2013-10-15 15:20:23,754 ERROR [STDERR]  at tu.venture.sales.ejb.business.SalesPriceProcessor.process(SalesPriceProcessor.java:106)
2013-10-15 15:20:23,754 ERROR [STDERR]  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
2013-10-15 15:20:23,754 ERROR [STDERR]  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
2013-10-15 15:20:23,754 ERROR [STDERR]  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
2013-10-15 15:20:23,754 ERROR [STDERR]  at java.lang.reflect.Method.invoke(Method.java:597)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:32)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.seam.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:28)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:77)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:185)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:103)
2013-10-15 15:20:23,754 ERROR [STDERR]  at tu.venture.sales.ejb.business.SalesPriceProcessor_$$_javassist_seam_5.process(SalesPriceProcessor_$$_javassist_seam_5.java)
2013-10-15 15:20:23,754 ERROR [STDERR]  at tu.venture.sales.ejb.business.SalesRequestProcessor.dispatchToBusinessLayer(SalesRequestProcessor.java:58)
2013-10-15 15:20:23,754 ERROR [STDERR]  at tu.venture.domain.interfaces.AbstractModuleRequestProcessor.process(AbstractModuleRequestProcessor.java:46)
2013-10-15 15:20:23,754 ERROR [STDERR]  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
2013-10-15 15:20:23,754 ERROR [STDERR]  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
2013-10-15 15:20:23,754 ERROR [STDERR]  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
2013-10-15 15:20:23,754 ERROR [STDERR]  at java.lang.reflect.Method.invoke(Method.java:597)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.aop.joinpoint.MethodInvocation.invokeTarget(MethodInvocation.java:122)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.ejb3.interceptors.container.ContainerMethodInvocationWrapper.invokeNext(ContainerMethodInvocationWrapper.java:72)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor$InvocationContext.proceed(InvocationContextInterceptor.java:138)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.seam.intercept.EJBInvocationContext.proceed(EJBInvocationContext.java:44)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.seam.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:28)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:77)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.seam.persistence.EntityManagerProxyInterceptor.aroundInvoke(EntityManagerProxyInterceptor.java:29)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.seam.persistence.HibernateSessionProxyInterceptor.aroundInvoke(HibernateSessionProxyInterceptor.java:30)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:118)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.seam.intercept.SessionBeanInterceptor.aroundInvoke(SessionBeanInterceptor.java:50)
2013-10-15 15:20:23,754 ERROR [STDERR]  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
2013-10-15 15:20:23,754 ERROR [STDERR]  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
2013-10-15 15:20:23,754 ERROR [STDERR]  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
2013-10-15 15:20:23,754 ERROR [STDERR]  at java.lang.reflect.Method.invoke(Method.java:597)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.ejb3.interceptors.aop.EJB3InterceptorInterceptor.invoke(EJB3InterceptorInterceptor.java:83)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.ejb3.interceptors.aop.EJB3InterceptorInterceptor.invoke(EJB3InterceptorInterceptor.java:70)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.ejb3.interceptors.container.ContainerMethodInvocationWrapper.invokeNext(ContainerMethodInvocationWrapper.java:62)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.ejb3.interceptors.aop.InterceptorSequencer.invoke(InterceptorSequencer.java:76)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.ejb3.interceptors.aop.InterceptorSequencer.aroundInvoke(InterceptorSequencer.java:62)
2013-10-15 15:20:23,754 ERROR [STDERR]  at sun.reflect.GeneratedMethodAccessor3020.invoke(Unknown Source)
2013-10-15 15:20:23,754 ERROR [STDERR]  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
2013-10-15 15:20:23,754 ERROR [STDERR]  at java.lang.reflect.Method.invoke(Method.java:597)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.aop.advice.PerJoinpointAdvice.invoke(PerJoinpointAdvice.java:174)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.fillMethod(InvocationContextInterceptor.java:72)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_fillMethod_1798969827.invoke(InvocationContextInterceptor_z_fillMethod_1798969827.java)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.setup(InvocationContextInterceptor.java:88)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_setup_1798969827.invoke(InvocationContextInterceptor_z_setup_1798969827.java)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.ejb3.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:62)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:56)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:68)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:190)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.ejb3.security.RoleBasedAuthorizationInterceptorv2.invoke(RoleBasedAuthorizationInterceptorv2.java:201)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:182)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.ejb3.core.context.CurrentInvocationContextInterceptor.invoke(CurrentInvocationContextInterceptor.java:47)
2013-10-15 15:20:23,754 ERROR [STDERR]  at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
2013-10-15 15:20:23,755 ERROR [STDERR]  at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
2013-10-15 15:20:23,755 ERROR [STDERR]  at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
2013-10-15 15:20:23,755 ERROR [STDERR]  at org.jboss.ejb3.interceptor.EJB3TCCLInterceptor.invoke(EJB3TCCLInterceptor.java:86)
2013-10-15 15:20:23,755 ERROR [STDERR]  at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
2013-10-15 15:20:23,755 ERROR [STDERR]  at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:444)
2013-10-15 15:20:23,755 ERROR [STDERR]  at org.jboss.ejb3.remoting.IsLocalInterceptor.invokeLocal(IsLocalInterceptor.java:88)
2013-10-15 15:20:23,755 ERROR [STDERR]  at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:75)
2013-10-15 15:20:23,755 ERROR [STDERR]  at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
2013-10-15 15:20:23,755 ERROR [STDERR]  at org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:62)
2013-10-15 15:20:23,755 ERROR [STDERR]  at $Proxy1326.invoke(Unknown Source)
2013-10-15 15:20:23,755 ERROR [STDERR]  at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:188)
2013-10-15 15:20:23,755 ERROR [STDERR]  at $Proxy4059.process(Unknown Source)
2013-10-15 15:20:23,755 ERROR [STDERR]  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
2013-10-15 15:20:23,755 ERROR [STDERR]  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
2013-10-15 15:20:23,755 ERROR [STDERR]  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
2013-10-15 15:20:23,755 ERROR [STDERR]  at java.lang.reflect.Method.invoke(Method.java:597)
2013-10-15 15:20:23,755 ERROR [STDERR]  at tu.venture.ui.framework.EJBServiceProxy.invoke(EJBServiceProxy.java:58)
2013-10-15 15:20:23,755 ERROR [STDERR]  at $Proxy4060.process(Unknown Source)
2013-10-15 15:20:23,755 ERROR [STDERR]  at tu.venture.ui.framework.ClientRequestProcessor.processRequest(ClientRequestProcessor.java:24)
2013-10-15 15:20:23,755 ERROR [STDERR]  at tu.venture.ui.partner.client.AbstractPolicyQuoteClient.callService(AbstractPolicyQuoteClient.java:98)
2013-10-15 15:20:23,755 ERROR [STDERR]  at tu.venture.ui.partner.client.quote.InitialSalePriceClient.execute(InitialSalePriceClient.java:41)
2013-10-15 15:20:23,755 ERROR [STDERR]  at tu.venture.ui.partner.client.PolicyQuoteFacade.calculateQuote(PolicyQuoteFacade.java:107)
2013-10-15 15:20:23,755 ERROR [STDERR]  at tu.venture.ui.partner.controller.quote.PolicyQuoteController.calculateQuote(PolicyQuoteController.java:83)
2013-10-15 15:20:23,755 ERROR [STDERR]  at tu.venture.ui.partner.controller.quote.PolicyQuoteController$Proxy$_$$_WeldClientProxy.calculateQuote(PolicyQuoteController$Proxy$_$$_WeldClientProxy.java)
2013-10-15 15:20:23,755 ERROR [STDERR]  at tu.venture.ui.partner.bean.quote.QuotePageBean.calculateQuote(QuotePageBean.java:75)
2013-10-15 15:20:23,755 ERROR [STDERR]  at tu.venture.ui.partner.bean.planinfo.PlanInfoBean.addPlansToCart(PlanInfoBean.java:270)
2013-10-15 15:20:23,755 ERROR [STDERR]  at tu.venture.ui.partner.bean.planinfo.PlanInfoBean$Proxy$_$$_WeldClientProxy.addPlansToCart(PlanInfoBean$Proxy$_$$_WeldClientProxy.java)
2013-10-15 15:20:23,755 ERROR [STDERR]  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
2013-10-15 15:20:23,755 ERROR [STDERR]  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
2013-10-15 15:20:23,755 ERROR [STDERR]  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
2013-10-15 15:20:23,755 ERROR [STDERR]  at java.lang.reflect.Method.invoke(Method.java:597)
2013-10-15 15:20:23,755 ERROR [STDERR]  at org.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:335)
2013-10-15 15:20:23,755 ERROR [STDERR]  at org.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:280)
2013-10-15 15:20:23,755 ERROR [STDERR]  at org.jboss.el.parser.AstMethodSuffix.getValue(AstMethodSuffix.java:59)
2013-10-15 15:20:23,755 ERROR [STDERR]  at org.jboss.el.parser.AstMethodSuffix.invoke(AstMethodSuffix.java:65)
2013-10-15 15:20:23,755 ERROR [STDERR]  at org.jboss.el.parser.AstValue.invoke(AstValue.java:96)
2013-10-15 15:20:23,755 ERROR [STDERR]  at org.jboss.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276)
2013-10-15 15:20:23,755 ERROR [STDERR]  at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:39)
2013-10-15 15:20:23,755 ERROR [STDERR]  at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50)
2013-10-15 15:20:23,755 ERROR [STDERR]  at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105)
2013-10-15 15:20:23,755 ERROR [STDERR]  at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:88)
2013-10-15 15:20:23,755 ERROR [STDERR]  at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:102)
2013-10-15 15:20:23,755 ERROR [STDERR]  at javax.faces.component.UICommand.broadcast(UICommand.java:315)
2013-10-15 15:20:23,755 ERROR [STDERR]  at org.richfaces.component.RowKeyContextEventWrapper.broadcast(RowKeyContextEventWrapper.java:104)
2013-10-15 15:20:23,755 ERROR [STDERR]  at org.richfaces.component.UIDataAdaptor.broadcast(UIDataAdaptor.java:448)
2013-10-15 15:20:23,755 ERROR [STDERR]  at org.richfaces.component.RowKeyContextEventWrapper.broadcast(RowKeyContextEventWrapper.java:104)
2013-10-15 15:20:23,755 ERROR [STDERR]  at org.richfaces.component.UIDataAdaptor.broadcast(UIDataAdaptor.java:448)
2013-10-15 15:20:23,755 ERROR [STDERR]  at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:794)
2013-10-15 15:20:23,755 ERROR [STDERR]  at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1259)
2013-10-15 15:20:23,755 ERROR [STDERR]  at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81)
2013-10-15 15:20:23,755 ERROR [STDERR]  at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
2013-10-15 15:20:23,755 ERROR [STDERR]  at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
2013-10-15 15:20:23,755 ERROR [STDERR]  at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593)
2013-10-15 15:20:23,755 ERROR [STDERR]  at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
2013-10-15 15:20:23,755 ERROR [STDERR]  at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
2013-10-15 15:20:23,755 ERROR [STDERR]  at tu.venture.ui.framework.servlet.ExceptionCatchingFilter.doFilter(ExceptionCatchingFilter.java:54)
2013-10-15 15:20:23,755 ERROR [STDERR]  at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
2013-10-15 15:20:23,755 ERROR [STDERR]  at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
2013-10-15 15:20:23,755 ERROR [STDERR]  at tu.venture.ui.framework.servlet.NoCacheHeadersServlet.doFilter(NoCacheHeadersServlet.java:41)
2013-10-15 15:20:23,755 ERROR [STDERR]  at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
2013-10-15 15:20:23,755 ERROR [STDERR]  at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
2013-10-15 15:20:23,755 ERROR [STDERR]  at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
2013-10-15 15:20:23,755 ERROR [STDERR]  at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
2013-10-15 15:20:23,755 ERROR [STDERR]  at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
2013-10-15 15:20:23,755 ERROR [STDERR]  at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
2013-10-15 15:20:23,755 ERROR [STDERR]  at org.apache.catalina.core.StandardContextValve.__invoke(StandardContextValve.java:191)
2013-10-15 15:20:23,755 ERROR [STDERR]  at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java)
2013-10-15 15:20:23,755 ERROR [STDERR]  at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:183)
2013-10-15 15:20:23,755 ERROR [STDERR]  at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)
2013-10-15 15:20:23,755 ERROR [STDERR]  at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:95)
2013-10-15 15:20:23,755 ERROR [STDERR]  at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
2013-10-15 15:20:23,755 ERROR [STDERR]  at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
2013-10-15 15:20:23,755 ERROR [STDERR]  at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
2013-10-15 15:20:23,755 ERROR [STDERR]  at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
2013-10-15 15:20:23,755 ERROR [STDERR]  at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
2013-10-15 15:20:23,755 ERROR [STDERR]  at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
2013-10-15 15:20:23,755 ERROR [STDERR]  at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
2013-10-15 15:20:23,755 ERROR [STDERR]  at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
2013-10-15 15:20:23,755 ERROR [STDERR]  at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
2013-10-15 15:20:23,755 ERROR [STDERR]  at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:451)
2013-10-15 15:20:23,755 ERROR [STDERR]  at java.lang.Thread.run(Thread.java:662)
2013-10-15 15:20:23,756 ERROR [STDERR] Caused by: java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.Long
2013-10-15 15:20:23,756 ERROR [STDERR]  at ConditionEvaluatordf13704748e74e68a38cf5bb6c1630ef.evaluate(Unknown Source)
2013-10-15 15:20:23,756 ERROR [STDERR]  at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:167)
2013-10-15 15:20:23,756 ERROR [STDERR]  at org.drools.rule.constraint.MvelConstraint.isAllowedCachedLeft(MvelConstraint.java:136)
2013-10-15 15:20:23,756 ERROR [STDERR]  at org.drools.common.TripleBetaConstraints.isAllowedCachedLeft(TripleBetaConstraints.java:199)
2013-10-15 15:20:23,756 ERROR [STDERR]  at org.drools.reteoo.JoinNode.assertLeftTuple(JoinNode.java:96)
2013-10-15 15:20:23,756 ERROR [STDERR]  at org.drools.reteoo.CompositeLeftTupleSinkAdapter.doPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:232)
2013-10-15 15:20:23,756 ERROR [STDERR]  at org.drools.reteoo.CompositeLeftTupleSinkAdapter.propagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:89)
2013-10-15 15:20:23,756 ERROR [STDERR]  at org.drools.reteoo.JoinNode.assertLeftTuple(JoinNode.java:98)
2013-10-15 15:20:23,756 ERROR [STDERR]  at org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:196)
2013-10-15 15:20:23,756 ERROR [STDERR]  at org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:71)
2013-10-15 15:20:23,756 ERROR [STDERR]  at org.drools.reteoo.JoinNode.assertLeftTuple(JoinNode.java:98)
2013-10-15 15:20:23,756 ERROR [STDERR]  at org.drools.reteoo.CompositeLeftTupleSinkAdapter.doPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:232)
2013-10-15 15:20:23,756 ERROR [STDERR]  at org.drools.reteoo.CompositeLeftTupleSinkAdapter.createAndPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:116)
2013-10-15 15:20:23,756 ERROR [STDERR]  at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:154)
2013-10-15 15:20:23,756 ERROR [STDERR]  at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:59)
2013-10-15 15:20:23,756 ERROR [STDERR]  at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:364)
2013-10-15 15:20:23,756 ERROR [STDERR]  at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235)
2013-10-15 15:20:23,756 ERROR [STDERR]  at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240)
2013-10-15 15:20:23,756 ERROR [STDERR]  at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:337)
2013-10-15 15:20:23,756 ERROR [STDERR]  at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:298)
2013-10-15 15:20:23,756 ERROR [STDERR]  at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:888)
2013-10-15 15:20:23,756 ERROR [STDERR]  at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:187)
2013-10-15 15:20:23,756 ERROR [STDERR]  at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:181)
2013-10-15 15:20:23,756 ERROR [STDERR]  at sales.rules.sys.setup.Rule_10_ServiceRequest_InsertRefData_fbff25aa69474eb5a6023d156e613f1e.defaultConsequence(Rule_10_ServiceRequest_InsertRefData_fbff25aa69474eb5a6023d156e613f1e.java:10)
2013-10-15 15:20:23,756 ERROR [STDERR]  at sales.rules.sys.setup.Rule_10_ServiceRequest_InsertRefData_fbff25aa69474eb5a6023d156e613f1eDefaultConsequenceInvokerGenerated.evaluate(Unknown Source)
2013-10-15 15:20:23,756 ERROR [STDERR]  at sales.rules.sys.setup.Rule_10_ServiceRequest_InsertRefData_fbff25aa69474eb5a6023d156e613f1eDefaultConsequenceInvoker.evaluate(Unknown Source)
2013-10-15 15:20:23,756 ERROR [STDERR]  at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1273)
2013-10-15 15:20:23,756 ERROR [STDERR]  ... 175 more
2013-10-15 15:20:23,777 INFO  [STDOUT] 20000-Insert breakdown code=PL-SPCK-6, insured=, age=11, rateGroup=TU-RATESTANDARDGROUP-2001883
2013-10-15 15:20:23,777 INFO  [STDOUT] 20000-Insert breakdown code=PL-MTI-1, insured=, age=11, rateGroup=TU-RATESTANDARDGROUP-2001823
2013-10-15 15:20:23,778 INFO  [STDOUT] 20000-Insert breakdown code=PL-MMED-2, insured=, age=11, rateGroup=TU-RATESTANDARDGROUP-2001583
2013-10-15 15:20:23,778 INFO  [STDOUT] 20000-Insert breakdown code=PL-SMED-3, insured=, age=11, rateGroup=TU-RATESTANDARDGROUP-2001743
2013-10-15 15:20:23,778 INFO  [tu.venture.sales.drools.util.RulesHelper] 5510_UpdatePriceResponse_AddPriceBreakdownsToCollection: plan=PL-SMED-3 ???nsured=
2013-10-15 15:20:23,778 INFO  [tu.venture.sales.drools.util.RulesHelper] 24000_SetMinimumPremium_$20_FreedomPlansRegion1,2
2013-10-15 15:20:23,779 INFO  [STDOUT] 20000-Insert breakdown code=PL-STCAN-1, insured=, age=11, rateGroup=TU-RATESTANDARDGROUP-2001563
2013-10-15 15:20:23,779 INFO  [tu.venture.sales.drools.util.RulesHelper] 5510_UpdatePriceResponse_AddPriceBreakdownsToCollection: plan=PL-STCAN-1 ???nsured=
2013-10-15 15:20:23,779 INFO  [STDOUT] 20000-Insert breakdown code=PL-STI-1, insured=, age=11, rateGroup=TU-RATESTANDARDGROUP-2001643
2013-10-15 15:20:23,780 INFO  [STDOUT] 20000-Insert breakdown code=PL-MTCAN-1, insured=, age=11, rateGroup=TU-RATESTANDARDGROUP-2001543
2013-10-15 15:20:23,780 INFO  [STDOUT] 20000-Insert breakdown code=PL-MADD-1, insured=, age=11, rateGroup=TU-RATESTANDARDGROUP-2001723
2013-10-15 15:20:23,780 INFO  [STDOUT] 20000-Insert breakdown code=PL-SMED-2, insured=, age=11, rateGroup=TU-RATESTANDARDGROUP-2001983
2013-10-15 15:20:23,781 INFO  [STDOUT] 20000-Insert breakdown code=PL-SMED-1, insured=, age=11, rateGroup=TU-RATESTANDARDGROUP-2001903
2013-10-15 15:20:23,781 INFO  [STDOUT] 20000-Insert breakdown code=PL-SMED-4, insured=, age=11, rateGroup=TU-RATESTANDARDGROUP-2002003
2013-10-15 15:20:23,782 INFO  [STDOUT] 20000-Insert breakdown code=PL-SSRC-1, insured=, age=11, rateGroup=TU-RATESTANDARDGROUP-2001703
2013-10-15 15:20:23,782 INFO  [STDOUT] 20000-Insert breakdown code=PL-SBAG-1, insured=, age=11, rateGroup=TU-RATESTANDARDGROUP-2001513
2013-10-15 15:20:23,782 INFO  [STDOUT] 20000-Insert breakdown code=PL-SPCK-2, insured=, age=11, rateGroup=TU-RATESTANDARDGROUP-2001623
2013-10-15 15:20:23,783 INFO  [STDOUT] 20000-Insert breakdown code=PL-MMED-3, insured=, age=11, rateGroup=TU-RATESTANDARDGROUP-2002083
2013-10-15 15:20:23,783 INFO  [STDOUT] 20000-Insert breakdown code=PL-SADD-1, insured=, age=11, rateGroup=TU-RATESTANDARDGROUP-2001783
2013-10-15 15:20:23,783 INFO  [tu.venture.sales.drools.util.RulesHelper] 23000_SetBaseRateMultiplier_TRIP: PL-SSRC-1|rg=Default - Rental Car - Single Trip
2013-10-15 15:20:23,783 INFO  [tu.venture.sales.drools.util.RulesHelper] 23000_SetBaseRateMultiplier_TRIP: PL-SMED-4|rg=Freedom - Medical Worldwide xUSA - Single Trip
2013-10-15 15:20:23,784 INFO  [tu.venture.sales.drools.util.RulesHelper] 23000_SetBaseRateMultiplier_TRIP: PL-SMED-1|rg=Freedom - Medical within Canada - Single Trip
2013-10-15 15:20:23,784 INFO  [tu.venture.sales.drools.util.RulesHelper] 23000_SetBaseRateMultiplier_TRIP: PL-SMED-2|rg=Freedom - Visitors - Single Trip
2013-10-15 15:20:23,784 INFO  [tu.venture.sales.drools.util.RulesHelper] 23000_SetBaseRateMultiplier_TRIP: PL-SMED-3|rg=Freedom - Medical Worldwide - Single Trip
2013-10-15 15:20:23,794 WARN  [tu.venture.sales.ejb.business.SalesPriceProcessor] Rate not found for insured plan:PL-STCAN-1^^:Missing rate factors, unable to retrieve a rate group = Default - Trip Cancellation - Single Trip: missing factors=[RefData [activeFlag=true, code=AGE, name=Age, refId=PRD-RFACTORCAT-AGE, sortOrder=0]]
2013-10-15 15:20:23,797 WARN  [tu.venture.sales.ejb.business.SalesPriceProcessor] Rate not found for insured plan:PL-SADD-1^^:Missing rate factors, unable to retrieve a rate group = Default - AD&D - Single Trip: missing factors=[RefData [activeFlag=true, code=TRIP, name=Trip Length, refId=PRD-RFACTORCAT-TRIP, sortOrder=3], RefData [activeFlag=true, code=AGE, name=Age, refId=PRD-RFACTORCAT-AGE, sortOrder=0]]
2013-10-15 15:20:23,797 WARN  [tu.venture.sales.ejb.business.SalesPriceProcessor] Rate not found for insured plan:PL-MMED-3^^:Missing rate factors, unable to retrieve a rate group = Freedom - Medical Worldwide - Multi Trip - CDI: missing factors=[RefData [activeFlag=true, code=FAM, name=Family, refId=PRD-RFACTORCAT-FAM, sortOrder=8], RefData [activeFlag=true, code=AGE, name=Age, refId=PRD-RFACTORCAT-AGE, sortOrder=0], RefData [activeFlag=true, code=HLTH, name=Health, refId=PRD-RFACTORCAT-HLTH, sortOrder=2]]
2013-10-15 15:20:23,798 WARN  [tu.venture.sales.ejb.business.SalesPriceProcessor] Rate not found for insured plan:PL-SPCK-2^^:Missing rate factors, unable to retrieve a rate group = Freedom - All Inclusive - Single Trip: missing factors=[RefData [activeFlag=true, code=TRIP, name=Trip Length, refId=PRD-RFACTORCAT-TRIP, sortOrder=3]]
2013-10-15 15:20:23,798 WARN  [tu.venture.sales.ejb.business.SalesPriceProcessor] Rate not found for insured plan:PL-SBAG-1^^:Missing rate factors, unable to retrieve a rate group = Default - Baggage - Single Trip: missing factors=[RefData [activeFlag=true, code=TRIP, name=Trip Length, refId=PRD-RFACTORCAT-TRIP, sortOrder=3], RefData [activeFlag=true, code=AGE, name=Age, refId=PRD-RFACTORCAT-AGE, sortOrder=0], RefData [activeFlag=true, code=FAM, name=Family, refId=PRD-RFACTORCAT-FAM, sortOrder=8]]
2013-10-15 15:20:23,798 WARN  [tu.venture.sales.ejb.business.SalesPriceProcessor] Rate not found for insured plan:PL-SSRC-1^^:Missing rate factors, unable to retrieve a rate group = Default - Rental Car - Single Trip: missing factors=[RefData [activeFlag=true, code=TRIP, name=Trip Length, refId=PRD-RFACTORCAT-TRIP, sortOrder=3], RefData [activeFlag=true, code=AGE, name=Age, refId=PRD-RFACTORCAT-AGE, sortOrder=0]]
2013-10-15 15:20:23,798 WARN  [tu.venture.sales.ejb.business.SalesPriceProcessor] Rate not found for insured plan:PL-SMED-4^^:Missing rate factors, unable to retrieve a rate group = Freedom - Medical Worldwide xUSA - Single Trip: missing factors=[RefData [activeFlag=true, code=TRIP, name=Trip Length, refId=PRD-RFACTORCAT-TRIP, sortOrder=3], RefData [activeFlag=true, code=HLTH, name=Health, refId=PRD-RFACTORCAT-HLTH, sortOrder=2], RefData [activeFlag=true, code=REGI, name=Region, refId=PRD-RFACTORCAT-REGI, sortOrder=10], RefData [activeFlag=true, code=AGE, name=Age, refId=PRD-RFACTORCAT-AGE, sortOrder=0], RefData [activeFlag=true, code=FAM, name=Family, refId=PRD-RFACTORCAT-FAM, sortOrder=8]]
2013-10-15 15:20:23,798 WARN  [tu.venture.sales.ejb.business.SalesPriceProcessor] Rate not found for insured plan:PL-SMED-1^^:Missing rate factors, unable to retrieve a rate group = Freedom - Medical within Canada - Single Trip: missing factors=[RefData [activeFlag=true, code=AGE, name=Age, refId=PRD-RFACTORCAT-AGE, sortOrder=0], RefData [activeFlag=true, code=TRIP, name=Trip Length, refId=PRD-RFACTORCAT-TRIP, sortOrder=3], RefData [activeFlag=true, code=FAM, name=Family, refId=PRD-RFACTORCAT-FAM, sortOrder=8]]
2013-10-15 15:20:23,798 WARN  [tu.venture.sales.ejb.business.SalesPriceProcessor] Rate not found for insured plan:PL-SMED-2^^:Missing rate factors, unable to retrieve a rate group = Freedom - Visitors - Single Trip: missing factors=[RefData [activeFlag=true, code=AGE, name=Age, refId=PRD-RFACTORCAT-AGE, sortOrder=0], RefData [activeFlag=true, code=FAM, name=Family, refId=PRD-RFACTORCAT-FAM, sortOrder=8]]
2013-10-15 15:20:23,798 WARN  [tu.venture.sales.ejb.business.SalesPriceProcessor] Rate not found for insured plan:PL-MTCAN-1^^:Missing rate factors, unable to retrieve a rate group = Default - Trip Cancellation - Multi Trip: missing factors=[RefData [activeFlag=true, code=AGE, name=Age, refId=PRD-RFACTORCAT-AGE, sortOrder=0]]
2013-10-15 15:20:23,798 WARN  [tu.venture.sales.ejb.business.SalesPriceProcessor] Rate not found for insured plan:PL-MADD-1^^:Missing rate factors, unable to retrieve a rate group = Default - AD&D - Multi Trip: missing factors=[RefData [activeFlag=true, code=AGE, name=Age, refId=PRD-RFACTORCAT-AGE, sortOrder=0], RefData [activeFlag=true, code=TRIP, name=Trip Length, refId=PRD-RFACTORCAT-TRIP, sortOrder=3]]
2013-10-15 15:20:23,798 WARN  [tu.venture.sales.ejb.business.SalesPriceProcessor] Rate not found for insured plan:PL-STCAN-1^^:Missing rate factors, unable to retrieve a rate group = Default - Trip Cancellation - Single Trip: missing factors=[RefData [activeFlag=true, code=AGE, name=Age, refId=PRD-RFACTORCAT-AGE, sortOrder=0]]
2013-10-15 15:20:23,799 WARN  [tu.venture.sales.ejb.business.SalesPriceProcessor] Rate not found for insured plan:PL-STI-1^^:Missing rate factors, unable to retrieve a rate group = Default - Trip Interruption - Single Trip: missing factors=[RefData [activeFlag=true, code=AGE, name=Age, refId=PRD-RFACTORCAT-AGE, sortOrder=0]]
2013-10-15 15:20:23,799 WARN  [tu.venture.sales.ejb.business.SalesPriceProcessor] Rate not found for insured plan:PL-SMED-3^^:Missing rate factors, unable to retrieve a rate group = Freedom - Medical Worldwide - Single Trip: missing factors=[RefData [activeFlag=true, code=AGE, name=Age, refId=PRD-RFACTORCAT-AGE, sortOrder=0], RefData [activeFlag=true, code=REGI, name=Region, refId=PRD-RFACTORCAT-REGI, sortOrder=10], RefData [activeFlag=true, code=FAM, name=Family, refId=PRD-RFACTORCAT-FAM, sortOrder=8], RefData [activeFlag=true, code=HLTH, name=Health, refId=PRD-RFACTORCAT-HLTH, sortOrder=2], RefData [activeFlag=true, code=TRIP, name=Trip Length, refId=PRD-RFACTORCAT-TRIP, sortOrder=3]]
2013-10-15 15:20:23,799 WARN  [tu.venture.sales.ejb.business.SalesPriceProcessor] Rate not found for insured plan:PL-MMED-2^^:Missing rate factors, unable to retrieve a rate group = Freedom - Medical within Canada - Multi Trip: missing factors=[RefData [activeFlag=true, code=FAM, name=Family, refId=PRD-RFACTORCAT-FAM, sortOrder=8], RefData [activeFlag=true, code=AGE, name=Age, refId=PRD-RFACTORCAT-AGE, sortOrder=0]]
2013-10-15 15:20:23,799 WARN  [tu.venture.sales.ejb.business.SalesPriceProcessor] Rate not found for insured plan:PL-SPCK-6^^:Missing rate factors, unable to retrieve a rate group = Freedom - Non Medical Package - Single Trip: missing factors=[RefData [activeFlag=true, code=AGE, name=Age, refId=PRD-RFACTORCAT-AGE, sortOrder=0]]
2013-10-15 15:20:23,799 WARN  [tu.venture.sales.ejb.business.SalesPriceProcessor] Rate not found for insured plan:PL-MTI-1^^:Missing rate factors, unable to retrieve a rate group = Default - Trip Interruption - Multi Trip: missing factors=[RefData [activeFlag=true, code=AGE, name=Age, refId=PRD-RFACTORCAT-AGE, sortOrder=0]]
2013-10-15 15:20:23,801 INFO  [STDOUT] Set minimum applied=true on plan=PL-SMED-3 minAmount=20
2013-10-15 15:20:23,802 INFO  [STDOUT] Charged minimum premium=$20

                
> Corrupted Working/Production memory
> -----------------------------------
>
>                 Key: DROOLS-215
>                 URL: https://issues.jboss.org/browse/DROOLS-215
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Ales Dolecek
>            Assignee: Mark Proctor
>         Attachments: ConcurrentNodeMemories.java
>
>
> Experienced ClassCastException mixing BetaMemory and AlphaMemory. There is debate in the mailing list/forum. The problem seems to be related to dymanic updates of knowledgebase.
> Saddly there is no deterministic way how to reproduce the issue, but that should not prevent tracking it here.
> Stack trace from my project:
> java.lang.ClassCastException: org.drools.reteoo.BetaMemory cannot be cast to org.drools.reteoo.AlphaNode$AlphaMemory
>         at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:136) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:497) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:382) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:350) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:311) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:192) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:186) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at cz.nextiraone.screening.rules.screening.Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1.defaultConsequence(Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1.java:7) ~[na
> :na]
>         at cz.nextiraone.screening.rules.screening.Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1DefaultConsequenceInvokerGenerated.evaluate(Unknown Source) ~[na:na]
>         at cz.nextiraone.screening.rules.screening.Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1DefaultConsequenceInvoker.evaluate(Unknown Source) ~[na:na]
>         at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1287) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1221) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1456) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:710) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:674) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:230) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Tue Oct 15 18:45:37 2013
From: jira-events at lists.jboss.org (Gurinder Randhawa (JIRA))
Date: Tue, 15 Oct 2013 18:45:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-185) ClassCastException at
	ConditionEvaluator
In-Reply-To: <JIRA.12495435.1372690482000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495435.1372690482000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495435.1372690482000.5923.1381877137290@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814422#comment-12814422 ] 

Gurinder Randhawa commented on DROOLS-185:
------------------------------------------

Re-posting this here as its related to this issue more so than Drools-215 issue.


Yes its occurring on RHS on one of our rules which is just inserting java object into session. The first invocation of our stateless request fires OK. The second subsequent one fails. We are an insurance company, the data below is generated in our price request java service. Hope this helps!!
I am posting the specific rule and domain object its inserting.
//
// Insert reference data
//
rule "10_ServiceRequest_InsertRefData"
auto-focus true
no-loop
salience 10000
when
not(exists (RefData()))
then
Map<String, RefData> rfMap = RefDataCacheFactory.getRefDataCache().getRefDataMap();
for(RefData rd : rfMap.values()){
if(rd.isActive())
{ insert(rd); }
}
end
//Domain object
@Embeddable
@XmlType(propOrder={})
public class RefData implements Flagged, Referenceable, Nameable, Sortable, RefIdAdaptable {
private static final long serialVersionUID = -2247172391015849722L;
@Field 
private String name;
@Field 
private String refId;
@Field 
private String code;
private String descr;
private String groupRefId;
private boolean activeFlag;
private String standardType;
private Long standardCodeNumber;
private Long sortOrder;
public RefData() {
}
public RefData(String refId, String code, String name, String descr, String groupRefId, boolean activeFlag,
String standardType, Long standardCodeNumber, Long sortOrder)
{ super(); this.refId = refId; this.code = code; this.name = name; this.descr = descr; this.groupRefId = groupRefId; this.activeFlag = activeFlag; this.standardType = standardType; this.standardCodeNumber = standardCodeNumber; this.sortOrder = sortOrder; }
@org.hibernate.validator.Length(max = 100)
@Column(name = "DESCR", length = 100)
@Size(max = 100)
public String getDescr()
{ return descr; }
public void setDescr(String descr)
{ this.descr = descr; }
@Transient
@XmlAttribute
public String getGroupRefId()
{ return groupRefId; }
public void setGroupRefId(String groupRefId)
{ this.groupRefId = groupRefId; }
@org.hibernate.validator.Length(max = 50)
@org.hibernate.validator.NotNull
@Column(name = "NAME", nullable = false, length = 50)
@NotNull
@Size(max = 50)
public String getName()
{ return name; }
public void setName(String name)
{ this.name = name; }
@Column(name = "STATUS_FLAG", nullable = false, length = 1)
@Type(type = "yes_no")
@XmlTransient
public boolean getActiveFlag()
{ return activeFlag; }
public void setActiveFlag(boolean activeFlag)
{ this.activeFlag = activeFlag; }
@Digits(integer = 2, fraction = 0)
@Column(name = "SORT_ORDER", precision = 2, scale = 0)
@XmlTransient
public Long getSortOrder()
{ return this.sortOrder; }
public void setSortOrder(Long sortOrder)
{ this.sortOrder = sortOrder; }
@Column(name = "STANDARD_TYPE")
@XmlTransient
public String getStandardType()
{ return standardType; }
public void setStandardType(String standardType)
{ this.standardType = standardType; }
@Column(name = "STANDARD_CODE_NUMBER")
@XmlTransient
public Long getStandardCodeNumber()
{ return standardCodeNumber; }
public void setStandardCodeNumber(Long standardCodeNumber)
{ this.standardCodeNumber = standardCodeNumber; }
@org.hibernate.validator.NotNull
@Column(name = "REF_ID", unique = true, nullable = false, length = 45)
@NotNull
@Size(max = 45)
@XmlAttribute
public String getRefId()
{ return refId; }
public void setRefId(String refId) {
if(refId != null && this.refId != null && this.refId.trim().length() > 0 && !this.refId.equals(refId))
{ throw new RuntimeException("RefId can't be updated!"); }
if(refId != null && refId.trim().length() > 0)
{ this.refId = refId.trim().toUpperCase(); }
}
/**
@see tu.venture.common.dao.util.RefIdAdaptable#generateRefId()
*/
@Override
public void generateRefId()
Unknown macro: { if(this.refId == null || this.refId.length() == 0){ this.setRefId(String.format("%s-%s", this.getGroupRefId(), this.getCode())); } }
@org.hibernate.validator.NotNull
@Column(name = "CODE", length = 45)
@Size(max = 45)
@NotNull
@XmlElement(required=true)
public String getCode()
{ return code; }
public void setCode(String code)
{ this.code = code; }
@Transient
@XmlTransient
public ActivationStatusEnum getStatus() {
if (getActiveFlag() == true)
{ return ActivationStatusEnum.ACTIVE; }
else
{ return ActivationStatusEnum.INACTIVE; }
}
@Transient
public void setStatus(ActivationStatusEnum status) {
if (status == ActivationStatusEnum.ACTIVE)
{ setActiveFlag(true); }
else
{ setActiveFlag(false); }
}
@Transient
public boolean isActive() {
if (getActiveFlag() == true)
{ return true; } else { return false; }
}

@Transient
public boolean isInactive() {
if (getActiveFlag() == true) { return false; } else { return true; }
}
@Transient
public boolean isNew()
{ return false; // activeFlag is never 'new' }
@Transient
public boolean isPending()
{ return false; // activeFlag is never 'pending' }
@Override
public <T extends Referenceable> T deepClone(boolean resetRefIds) throws IOException, ClassNotFoundException
{ return ReferenceableBase.deepClone((T)this, false); // never reset RefId for RefData }
@Override
public boolean equals(Object o)
{ if (this == o) return true; if (o == null || getClass() != o.getClass()) return false; RefData refData = (RefData) o; if (activeFlag != refData.activeFlag) return false; if (groupRefId != null ? !groupRefId.equals(refData.groupRefId) : refData.groupRefId != null) return false; if (code != null ? !code.equals(refData.code) : refData.code != null) return false; if (name != null ? !name.equals(refData.name) : refData.name != null) return false; if (refId != null ? !refId.equals(refData.refId) : refData.refId != null) return false; if (standardCodeNumber != null ? !standardCodeNumber.equals(refData.standardCodeNumber) : refData.standardCodeNumber != null) return false; if (standardType != null ? !standardType.equals(refData.standardType) : refData.standardType != null) return false; if (sortOrder != null ? !sortOrder.equals(refData.sortOrder) : refData.sortOrder != null) return false; return true; }
@Override
public int hashCode()
{ int result = groupRefId != null ? groupRefId.hashCode() : 0; result = 31 * result + (code != null ? code.hashCode() : 0); result = 31 * result + (name != null ? name.hashCode() : 0); result = 31 * result + (activeFlag ? 1 : 0); result = 31 * result + (standardType != null ? standardType.hashCode() : 0); result = 31 * result + (standardCodeNumber != null ? standardCodeNumber.hashCode() : 0); result = 31 * result + (refId != null ? refId.hashCode() : 0); result = 31 * result + (sortOrder != null ? sortOrder.hashCode() : 0); return result; }
}
========Full stack trace=========
2013-10-15 15:20:23,516 INFO [tu.venture.sales.drools.util.RulesHelper] 1025_PriceContext_InsertTrip: Trip [refId='null', cost=null, destination=null, reservation=null, bookingDate=null, arrivalDate=null, startDate=Tue Oct 15 00:00:00 PDT 2013, endDate=Tue Nov 05 00:00:00 PST 2013]
2013-10-15 15:20:23,516 INFO [tu.venture.sales.drools.util.RulesHelper] 1010_PriceContext_InsertInsureds: 1
2013-10-15 15:20:23,517 INFO [tu.venture.sales.drools.util.RulesHelper] 1000_PriceContext_InsertSelectedProductAgreement: TU-PRODUCTAGREEMENT-2000433
2013-10-15 15:20:23,517 INFO [tu.venture.sales.drools.util.RulesHelper] 5005_InsertProductPlansBasedOnInsuredType
2013-10-15 15:20:23,752 ERROR [STDERR] Exception executing consequence for rule "10_ServiceRequest_InsertRefData" in sales.rules.sys.setup: java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.Long
2013-10-15 15:20:23,754 ERROR [STDERR] at org.drools.runtime.rule.impl.DefaultConsequenceExceptionHandler.handleException(DefaultConsequenceExceptionHandler.java:39)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1283)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1209)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1442)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:710)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:674)
2013-10-15 15:20:23,754 ERROR [STDERR] at tu.venture.domain.interfaces.RulesRequestProcessor.processByStatefullRules(RulesRequestProcessor.java:68)
2013-10-15 15:20:23,754 ERROR [STDERR] at tu.venture.sales.ejb.business.SalesPriceProcessor.process(SalesPriceProcessor.java:106)
2013-10-15 15:20:23,754 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
2013-10-15 15:20:23,754 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
2013-10-15 15:20:23,754 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
2013-10-15 15:20:23,754 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:597)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:32)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.seam.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:28)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:77)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:185)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:103)
2013-10-15 15:20:23,754 ERROR [STDERR] at tu.venture.sales.ejb.business.SalesPriceProcessor_$$javassist_seam_5.process(SalesPriceProcessor$$_javassist_seam_5.java)
2013-10-15 15:20:23,754 ERROR [STDERR] at tu.venture.sales.ejb.business.SalesRequestProcessor.dispatchToBusinessLayer(SalesRequestProcessor.java:58)
2013-10-15 15:20:23,754 ERROR [STDERR] at tu.venture.domain.interfaces.AbstractModuleRequestProcessor.process(AbstractModuleRequestProcessor.java:46)
2013-10-15 15:20:23,754 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
2013-10-15 15:20:23,754 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
2013-10-15 15:20:23,754 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
2013-10-15 15:20:23,754 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:597)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.aop.joinpoint.MethodInvocation.invokeTarget(MethodInvocation.java:122)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.ejb3.interceptors.container.ContainerMethodInvocationWrapper.invokeNext(ContainerMethodInvocationWrapper.java:72)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor$InvocationContext.proceed(InvocationContextInterceptor.java:138)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.seam.intercept.EJBInvocationContext.proceed(EJBInvocationContext.java:44)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.seam.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:28)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:77)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.seam.persistence.EntityManagerProxyInterceptor.aroundInvoke(EntityManagerProxyInterceptor.java:29)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.seam.persistence.HibernateSessionProxyInterceptor.aroundInvoke(HibernateSessionProxyInterceptor.java:30)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:118)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.seam.intercept.SessionBeanInterceptor.aroundInvoke(SessionBeanInterceptor.java:50)
2013-10-15 15:20:23,754 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
2013-10-15 15:20:23,754 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
2013-10-15 15:20:23,754 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
2013-10-15 15:20:23,754 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:597)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.ejb3.interceptors.aop.EJB3InterceptorInterceptor.invoke(EJB3InterceptorInterceptor.java:83)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.ejb3.interceptors.aop.EJB3InterceptorInterceptor.invoke(EJB3InterceptorInterceptor.java:70)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.ejb3.interceptors.container.ContainerMethodInvocationWrapper.invokeNext(ContainerMethodInvocationWrapper.java:62)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.ejb3.interceptors.aop.InterceptorSequencer.invoke(InterceptorSequencer.java:76)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.ejb3.interceptors.aop.InterceptorSequencer.aroundInvoke(InterceptorSequencer.java:62)
2013-10-15 15:20:23,754 ERROR [STDERR] at sun.reflect.GeneratedMethodAccessor3020.invoke(Unknown Source)
2013-10-15 15:20:23,754 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
2013-10-15 15:20:23,754 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:597)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.aop.advice.PerJoinpointAdvice.invoke(PerJoinpointAdvice.java:174)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.fillMethod(InvocationContextInterceptor.java:72)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_fillMethod_1798969827.invoke(InvocationContextInterceptor_z_fillMethod_1798969827.java)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor.setup(InvocationContextInterceptor.java:88)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.aop.advice.org.jboss.ejb3.interceptors.aop.InvocationContextInterceptor_z_setup_1798969827.invoke(InvocationContextInterceptor_z_setup_1798969827.java)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.ejb3.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:62)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:56)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:68)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:190)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.ejb3.security.RoleBasedAuthorizationInterceptorv2.invoke(RoleBasedAuthorizationInterceptorv2.java:201)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:182)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.ejb3.core.context.CurrentInvocationContextInterceptor.invoke(CurrentInvocationContextInterceptor.java:47)
2013-10-15 15:20:23,754 ERROR [STDERR] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
2013-10-15 15:20:23,755 ERROR [STDERR] at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
2013-10-15 15:20:23,755 ERROR [STDERR] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
2013-10-15 15:20:23,755 ERROR [STDERR] at org.jboss.ejb3.interceptor.EJB3TCCLInterceptor.invoke(EJB3TCCLInterceptor.java:86)
2013-10-15 15:20:23,755 ERROR [STDERR] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
2013-10-15 15:20:23,755 ERROR [STDERR] at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:444)
2013-10-15 15:20:23,755 ERROR [STDERR] at org.jboss.ejb3.remoting.IsLocalInterceptor.invokeLocal(IsLocalInterceptor.java:88)
2013-10-15 15:20:23,755 ERROR [STDERR] at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:75)
2013-10-15 15:20:23,755 ERROR [STDERR] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
2013-10-15 15:20:23,755 ERROR [STDERR] at org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:62)
2013-10-15 15:20:23,755 ERROR [STDERR] at $Proxy1326.invoke(Unknown Source)
2013-10-15 15:20:23,755 ERROR [STDERR] at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:188)
2013-10-15 15:20:23,755 ERROR [STDERR] at $Proxy4059.process(Unknown Source)
2013-10-15 15:20:23,755 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
2013-10-15 15:20:23,755 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
2013-10-15 15:20:23,755 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
2013-10-15 15:20:23,755 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:597)
2013-10-15 15:20:23,755 ERROR [STDERR] at tu.venture.ui.framework.EJBServiceProxy.invoke(EJBServiceProxy.java:58)
2013-10-15 15:20:23,755 ERROR [STDERR] at $Proxy4060.process(Unknown Source)
2013-10-15 15:20:23,755 ERROR [STDERR] at tu.venture.ui.framework.ClientRequestProcessor.processRequest(ClientRequestProcessor.java:24)
2013-10-15 15:20:23,755 ERROR [STDERR] at tu.venture.ui.partner.client.AbstractPolicyQuoteClient.callService(AbstractPolicyQuoteClient.java:98)
2013-10-15 15:20:23,755 ERROR [STDERR] at tu.venture.ui.partner.client.quote.InitialSalePriceClient.execute(InitialSalePriceClient.java:41)
2013-10-15 15:20:23,755 ERROR [STDERR] at tu.venture.ui.partner.client.PolicyQuoteFacade.calculateQuote(PolicyQuoteFacade.java:107)
2013-10-15 15:20:23,755 ERROR [STDERR] at tu.venture.ui.partner.controller.quote.PolicyQuoteController.calculateQuote(PolicyQuoteController.java:83)
2013-10-15 15:20:23,755 ERROR [STDERR] at tu.venture.ui.partner.controller.quote.PolicyQuoteController$Proxy$$$_WeldClientProxy.calculateQuote(PolicyQuoteController$Proxy$$$_WeldClientProxy.java)
2013-10-15 15:20:23,755 ERROR [STDERR] at tu.venture.ui.partner.bean.quote.QuotePageBean.calculateQuote(QuotePageBean.java:75)
2013-10-15 15:20:23,755 ERROR [STDERR] at tu.venture.ui.partner.bean.planinfo.PlanInfoBean.addPlansToCart(PlanInfoBean.java:270)
2013-10-15 15:20:23,755 ERROR [STDERR] at tu.venture.ui.partner.bean.planinfo.PlanInfoBean$Proxy$$$_WeldClientProxy.addPlansToCart(PlanInfoBean$Proxy$$$_WeldClientProxy.java)
2013-10-15 15:20:23,755 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
2013-10-15 15:20:23,755 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
2013-10-15 15:20:23,755 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
2013-10-15 15:20:23,755 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:597)
2013-10-15 15:20:23,755 ERROR [STDERR] at org.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:335)
2013-10-15 15:20:23,755 ERROR [STDERR] at org.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:280)
2013-10-15 15:20:23,755 ERROR [STDERR] at org.jboss.el.parser.AstMethodSuffix.getValue(AstMethodSuffix.java:59)
2013-10-15 15:20:23,755 ERROR [STDERR] at org.jboss.el.parser.AstMethodSuffix.invoke(AstMethodSuffix.java:65)
2013-10-15 15:20:23,755 ERROR [STDERR] at org.jboss.el.parser.AstValue.invoke(AstValue.java:96)
2013-10-15 15:20:23,755 ERROR [STDERR] at org.jboss.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276)
2013-10-15 15:20:23,755 ERROR [STDERR] at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:39)
2013-10-15 15:20:23,755 ERROR [STDERR] at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50)
2013-10-15 15:20:23,755 ERROR [STDERR] at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105)
2013-10-15 15:20:23,755 ERROR [STDERR] at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:88)
2013-10-15 15:20:23,755 ERROR [STDERR] at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:102)
2013-10-15 15:20:23,755 ERROR [STDERR] at javax.faces.component.UICommand.broadcast(UICommand.java:315)
2013-10-15 15:20:23,755 ERROR [STDERR] at org.richfaces.component.RowKeyContextEventWrapper.broadcast(RowKeyContextEventWrapper.java:104)
2013-10-15 15:20:23,755 ERROR [STDERR] at org.richfaces.component.UIDataAdaptor.broadcast(UIDataAdaptor.java:448)
2013-10-15 15:20:23,755 ERROR [STDERR] at org.richfaces.component.RowKeyContextEventWrapper.broadcast(RowKeyContextEventWrapper.java:104)
2013-10-15 15:20:23,755 ERROR [STDERR] at org.richfaces.component.UIDataAdaptor.broadcast(UIDataAdaptor.java:448)
2013-10-15 15:20:23,755 ERROR [STDERR] at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:794)
2013-10-15 15:20:23,755 ERROR [STDERR] at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1259)
2013-10-15 15:20:23,755 ERROR [STDERR] at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81)
2013-10-15 15:20:23,755 ERROR [STDERR] at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
2013-10-15 15:20:23,755 ERROR [STDERR] at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
2013-10-15 15:20:23,755 ERROR [STDERR] at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593)
2013-10-15 15:20:23,755 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
2013-10-15 15:20:23,755 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
2013-10-15 15:20:23,755 ERROR [STDERR] at tu.venture.ui.framework.servlet.ExceptionCatchingFilter.doFilter(ExceptionCatchingFilter.java:54)
2013-10-15 15:20:23,755 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
2013-10-15 15:20:23,755 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
2013-10-15 15:20:23,755 ERROR [STDERR] at tu.venture.ui.framework.servlet.NoCacheHeadersServlet.doFilter(NoCacheHeadersServlet.java:41)
2013-10-15 15:20:23,755 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
2013-10-15 15:20:23,755 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
2013-10-15 15:20:23,755 ERROR [STDERR] at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
2013-10-15 15:20:23,755 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
2013-10-15 15:20:23,755 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
2013-10-15 15:20:23,755 ERROR [STDERR] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
2013-10-15 15:20:23,755 ERROR [STDERR] at org.apache.catalina.core.StandardContextValve.__invoke(StandardContextValve.java:191)
2013-10-15 15:20:23,755 ERROR [STDERR] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java)
2013-10-15 15:20:23,755 ERROR [STDERR] at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:183)
2013-10-15 15:20:23,755 ERROR [STDERR] at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)
2013-10-15 15:20:23,755 ERROR [STDERR] at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:95)
2013-10-15 15:20:23,755 ERROR [STDERR] at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
2013-10-15 15:20:23,755 ERROR [STDERR] at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
2013-10-15 15:20:23,755 ERROR [STDERR] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
2013-10-15 15:20:23,755 ERROR [STDERR] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
2013-10-15 15:20:23,755 ERROR [STDERR] at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
2013-10-15 15:20:23,755 ERROR [STDERR] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
2013-10-15 15:20:23,755 ERROR [STDERR] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
2013-10-15 15:20:23,755 ERROR [STDERR] at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
2013-10-15 15:20:23,755 ERROR [STDERR] at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
2013-10-15 15:20:23,755 ERROR [STDERR] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:451)
2013-10-15 15:20:23,755 ERROR [STDERR] at java.lang.Thread.run(Thread.java:662)
2013-10-15 15:20:23,756 ERROR [STDERR] Caused by: java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.Long
2013-10-15 15:20:23,756 ERROR [STDERR] at ConditionEvaluatordf13704748e74e68a38cf5bb6c1630ef.evaluate(Unknown Source)
2013-10-15 15:20:23,756 ERROR [STDERR] at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:167)
2013-10-15 15:20:23,756 ERROR [STDERR] at org.drools.rule.constraint.MvelConstraint.isAllowedCachedLeft(MvelConstraint.java:136)
2013-10-15 15:20:23,756 ERROR [STDERR] at org.drools.common.TripleBetaConstraints.isAllowedCachedLeft(TripleBetaConstraints.java:199)
2013-10-15 15:20:23,756 ERROR [STDERR] at org.drools.reteoo.JoinNode.assertLeftTuple(JoinNode.java:96)
2013-10-15 15:20:23,756 ERROR [STDERR] at org.drools.reteoo.CompositeLeftTupleSinkAdapter.doPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:232)
2013-10-15 15:20:23,756 ERROR [STDERR] at org.drools.reteoo.CompositeLeftTupleSinkAdapter.propagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:89)
2013-10-15 15:20:23,756 ERROR [STDERR] at org.drools.reteoo.JoinNode.assertLeftTuple(JoinNode.java:98)
2013-10-15 15:20:23,756 ERROR [STDERR] at org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:196)
2013-10-15 15:20:23,756 ERROR [STDERR] at org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:71)
2013-10-15 15:20:23,756 ERROR [STDERR] at org.drools.reteoo.JoinNode.assertLeftTuple(JoinNode.java:98)
2013-10-15 15:20:23,756 ERROR [STDERR] at org.drools.reteoo.CompositeLeftTupleSinkAdapter.doPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:232)
2013-10-15 15:20:23,756 ERROR [STDERR] at org.drools.reteoo.CompositeLeftTupleSinkAdapter.createAndPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:116)
2013-10-15 15:20:23,756 ERROR [STDERR] at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:154)
2013-10-15 15:20:23,756 ERROR [STDERR] at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:59)
2013-10-15 15:20:23,756 ERROR [STDERR] at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:364)
2013-10-15 15:20:23,756 ERROR [STDERR] at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235)
2013-10-15 15:20:23,756 ERROR [STDERR] at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240)
2013-10-15 15:20:23,756 ERROR [STDERR] at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:337)
2013-10-15 15:20:23,756 ERROR [STDERR] at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:298)
2013-10-15 15:20:23,756 ERROR [STDERR] at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:888)
2013-10-15 15:20:23,756 ERROR [STDERR] at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:187)
2013-10-15 15:20:23,756 ERROR [STDERR] at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:181)
2013-10-15 15:20:23,756 ERROR [STDERR] at sales.rules.sys.setup.Rule_10_ServiceRequest_InsertRefData_fbff25aa69474eb5a6023d156e613f1e.defaultConsequence(Rule_10_ServiceRequest_InsertRefData_fbff25aa69474eb5a6023d156e613f1e.java:10)
2013-10-15 15:20:23,756 ERROR [STDERR] at sales.rules.sys.setup.Rule_10_ServiceRequest_InsertRefData_fbff25aa69474eb5a6023d156e613f1eDefaultConsequenceInvokerGenerated.evaluate(Unknown Source)
2013-10-15 15:20:23,756 ERROR [STDERR] at sales.rules.sys.setup.Rule_10_ServiceRequest_InsertRefData_fbff25aa69474eb5a6023d156e613f1eDefaultConsequenceInvoker.evaluate(Unknown Source)
2013-10-15 15:20:23,756 ERROR [STDERR] at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1273)
2013-10-15 15:20:23,756 ERROR [STDERR] ... 175 more
2013-10-15 15:20:23,777 INFO [STDOUT] 20000-Insert breakdown code=PL-SPCK-6, insured=, age=11, rateGroup=TU-RATESTANDARDGROUP-2001883
2013-10-15 15:20:23,777 INFO [STDOUT] 20000-Insert breakdown code=PL-MTI-1, insured=, age=11, rateGroup=TU-RATESTANDARDGROUP-2001823
2013-10-15 15:20:23,778 INFO [STDOUT] 20000-Insert breakdown code=PL-MMED-2, insured=, age=11, rateGroup=TU-RATESTANDARDGROUP-2001583
2013-10-15 15:20:23,778 INFO [STDOUT] 20000-Insert breakdown code=PL-SMED-3, insured=, age=11, rateGroup=TU-RATESTANDARDGROUP-2001743
2013-10-15 15:20:23,778 INFO [tu.venture.sales.drools.util.RulesHelper] 5510_UpdatePriceResponse_AddPriceBreakdownsToCollection: plan=PL-SMED-3 ???nsured=
2013-10-15 15:20:23,778 INFO [tu.venture.sales.drools.util.RulesHelper] 24000_SetMinimumPremium_$20_FreedomPlansRegion1,2
2013-10-15 15:20:23,779 INFO [STDOUT] 20000-Insert breakdown code=PL-STCAN-1, insured=, age=11, rateGroup=TU-RATESTANDARDGROUP-2001563
2013-10-15 15:20:23,779 INFO [tu.venture.sales.drools.util.RulesHelper] 5510_UpdatePriceResponse_AddPriceBreakdownsToCollection: plan=PL-STCAN-1 ???nsured=
2013-10-15 15:20:23,779 INFO [STDOUT] 20000-Insert breakdown code=PL-STI-1, insured=, age=11, rateGroup=TU-RATESTANDARDGROUP-2001643
2013-10-15 15:20:23,780 INFO [STDOUT] 20000-Insert breakdown code=PL-MTCAN-1, insured=, age=11, rateGroup=TU-RATESTANDARDGROUP-2001543
2013-10-15 15:20:23,780 INFO [STDOUT] 20000-Insert breakdown code=PL-MADD-1, insured=, age=11, rateGroup=TU-RATESTANDARDGROUP-2001723
2013-10-15 15:20:23,780 INFO [STDOUT] 20000-Insert breakdown code=PL-SMED-2, insured=, age=11, rateGroup=TU-RATESTANDARDGROUP-2001983
2013-10-15 15:20:23,781 INFO [STDOUT] 20000-Insert breakdown code=PL-SMED-1, insured=, age=11, rateGroup=TU-RATESTANDARDGROUP-2001903
2013-10-15 15:20:23,781 INFO [STDOUT] 20000-Insert breakdown code=PL-SMED-4, insured=, age=11, rateGroup=TU-RATESTANDARDGROUP-2002003
2013-10-15 15:20:23,782 INFO [STDOUT] 20000-Insert breakdown code=PL-SSRC-1, insured=, age=11, rateGroup=TU-RATESTANDARDGROUP-2001703
2013-10-15 15:20:23,782 INFO [STDOUT] 20000-Insert breakdown code=PL-SBAG-1, insured=, age=11, rateGroup=TU-RATESTANDARDGROUP-2001513
2013-10-15 15:20:23,782 INFO [STDOUT] 20000-Insert breakdown code=PL-SPCK-2, insured=, age=11, rateGroup=TU-RATESTANDARDGROUP-2001623
2013-10-15 15:20:23,783 INFO [STDOUT] 20000-Insert breakdown code=PL-MMED-3, insured=, age=11, rateGroup=TU-RATESTANDARDGROUP-2002083
2013-10-15 15:20:23,783 INFO [STDOUT] 20000-Insert breakdown code=PL-SADD-1, insured=, age=11, rateGroup=TU-RATESTANDARDGROUP-2001783
2013-10-15 15:20:23,783 INFO [tu.venture.sales.drools.util.RulesHelper] 23000_SetBaseRateMultiplier_TRIP: PL-SSRC-1|rg=Default - Rental Car - Single Trip
2013-10-15 15:20:23,783 INFO [tu.venture.sales.drools.util.RulesHelper] 23000_SetBaseRateMultiplier_TRIP: PL-SMED-4|rg=Freedom - Medical Worldwide xUSA - Single Trip
2013-10-15 15:20:23,784 INFO [tu.venture.sales.drools.util.RulesHelper] 23000_SetBaseRateMultiplier_TRIP: PL-SMED-1|rg=Freedom - Medical within Canada - Single Trip
2013-10-15 15:20:23,784 INFO [tu.venture.sales.drools.util.RulesHelper] 23000_SetBaseRateMultiplier_TRIP: PL-SMED-2|rg=Freedom - Visitors - Single Trip
2013-10-15 15:20:23,784 INFO [tu.venture.sales.drools.util.RulesHelper] 23000_SetBaseRateMultiplier_TRIP: PL-SMED-3|rg=Freedom - Medical Worldwide - Single Trip
2013-10-15 15:20:23,794 WARN [tu.venture.sales.ejb.business.SalesPriceProcessor] Rate not found for insured plan:PL-STCAN-1^^:Missing rate factors, unable to retrieve a rate group = Default - Trip Cancellation - Single Trip: missing factors=[RefData [activeFlag=true, code=AGE, name=Age, refId=PRD-RFACTORCAT-AGE, sortOrder=0]]
2013-10-15 15:20:23,797 WARN [tu.venture.sales.ejb.business.SalesPriceProcessor] Rate not found for insured plan:PL-SADD-1^^:Missing rate factors, unable to retrieve a rate group = Default - AD&D - Single Trip: missing factors=[RefData [activeFlag=true, code=TRIP, name=Trip Length, refId=PRD-RFACTORCAT-TRIP, sortOrder=3], RefData [activeFlag=true, code=AGE, name=Age, refId=PRD-RFACTORCAT-AGE, sortOrder=0]]
2013-10-15 15:20:23,797 WARN [tu.venture.sales.ejb.business.SalesPriceProcessor] Rate not found for insured plan:PL-MMED-3^^:Missing rate factors, unable to retrieve a rate group = Freedom - Medical Worldwide - Multi Trip - CDI: missing factors=[RefData [activeFlag=true, code=FAM, name=Family, refId=PRD-RFACTORCAT-FAM, sortOrder=8], RefData [activeFlag=true, code=AGE, name=Age, refId=PRD-RFACTORCAT-AGE, sortOrder=0], RefData [activeFlag=true, code=HLTH, name=Health, refId=PRD-RFACTORCAT-HLTH, sortOrder=2]]
2013-10-15 15:20:23,798 WARN [tu.venture.sales.ejb.business.SalesPriceProcessor] Rate not found for insured plan:PL-SPCK-2^^:Missing rate factors, unable to retrieve a rate group = Freedom - All Inclusive - Single Trip: missing factors=[RefData [activeFlag=true, code=TRIP, name=Trip Length, refId=PRD-RFACTORCAT-TRIP, sortOrder=3]]
2013-10-15 15:20:23,798 WARN [tu.venture.sales.ejb.business.SalesPriceProcessor] Rate not found for insured plan:PL-SBAG-1^^:Missing rate factors, unable to retrieve a rate group = Default - Baggage - Single Trip: missing factors=[RefData [activeFlag=true, code=TRIP, name=Trip Length, refId=PRD-RFACTORCAT-TRIP, sortOrder=3], RefData [activeFlag=true, code=AGE, name=Age, refId=PRD-RFACTORCAT-AGE, sortOrder=0], RefData [activeFlag=true, code=FAM, name=Family, refId=PRD-RFACTORCAT-FAM, sortOrder=8]]
2013-10-15 15:20:23,798 WARN [tu.venture.sales.ejb.business.SalesPriceProcessor] Rate not found for insured plan:PL-SSRC-1^^:Missing rate factors, unable to retrieve a rate group = Default - Rental Car - Single Trip: missing factors=[RefData [activeFlag=true, code=TRIP, name=Trip Length, refId=PRD-RFACTORCAT-TRIP, sortOrder=3], RefData [activeFlag=true, code=AGE, name=Age, refId=PRD-RFACTORCAT-AGE, sortOrder=0]]
2013-10-15 15:20:23,798 WARN [tu.venture.sales.ejb.business.SalesPriceProcessor] Rate not found for insured plan:PL-SMED-4^^:Missing rate factors, unable to retrieve a rate group = Freedom - Medical Worldwide xUSA - Single Trip: missing factors=[RefData [activeFlag=true, code=TRIP, name=Trip Length, refId=PRD-RFACTORCAT-TRIP, sortOrder=3], RefData [activeFlag=true, code=HLTH, name=Health, refId=PRD-RFACTORCAT-HLTH, sortOrder=2], RefData [activeFlag=true, code=REGI, name=Region, refId=PRD-RFACTORCAT-REGI, sortOrder=10], RefData [activeFlag=true, code=AGE, name=Age, refId=PRD-RFACTORCAT-AGE, sortOrder=0], RefData [activeFlag=true, code=FAM, name=Family, refId=PRD-RFACTORCAT-FAM, sortOrder=8]]
2013-10-15 15:20:23,798 WARN [tu.venture.sales.ejb.business.SalesPriceProcessor] Rate not found for insured plan:PL-SMED-1^^:Missing rate factors, unable to retrieve a rate group = Freedom - Medical within Canada - Single Trip: missing factors=[RefData [activeFlag=true, code=AGE, name=Age, refId=PRD-RFACTORCAT-AGE, sortOrder=0], RefData [activeFlag=true, code=TRIP, name=Trip Length, refId=PRD-RFACTORCAT-TRIP, sortOrder=3], RefData [activeFlag=true, code=FAM, name=Family, refId=PRD-RFACTORCAT-FAM, sortOrder=8]]
2013-10-15 15:20:23,798 WARN [tu.venture.sales.ejb.business.SalesPriceProcessor] Rate not found for insured plan:PL-SMED-2^^:Missing rate factors, unable to retrieve a rate group = Freedom - Visitors - Single Trip: missing factors=[RefData [activeFlag=true, code=AGE, name=Age, refId=PRD-RFACTORCAT-AGE, sortOrder=0], RefData [activeFlag=true, code=FAM, name=Family, refId=PRD-RFACTORCAT-FAM, sortOrder=8]]
2013-10-15 15:20:23,798 WARN [tu.venture.sales.ejb.business.SalesPriceProcessor] Rate not found for insured plan:PL-MTCAN-1^^:Missing rate factors, unable to retrieve a rate group = Default - Trip Cancellation - Multi Trip: missing factors=[RefData [activeFlag=true, code=AGE, name=Age, refId=PRD-RFACTORCAT-AGE, sortOrder=0]]
2013-10-15 15:20:23,798 WARN [tu.venture.sales.ejb.business.SalesPriceProcessor] Rate not found for insured plan:PL-MADD-1^^:Missing rate factors, unable to retrieve a rate group = Default - AD&D - Multi Trip: missing factors=[RefData [activeFlag=true, code=AGE, name=Age, refId=PRD-RFACTORCAT-AGE, sortOrder=0], RefData [activeFlag=true, code=TRIP, name=Trip Length, refId=PRD-RFACTORCAT-TRIP, sortOrder=3]]
2013-10-15 15:20:23,798 WARN [tu.venture.sales.ejb.business.SalesPriceProcessor] Rate not found for insured plan:PL-STCAN-1^^:Missing rate factors, unable to retrieve a rate group = Default - Trip Cancellation - Single Trip: missing factors=[RefData [activeFlag=true, code=AGE, name=Age, refId=PRD-RFACTORCAT-AGE, sortOrder=0]]
2013-10-15 15:20:23,799 WARN [tu.venture.sales.ejb.business.SalesPriceProcessor] Rate not found for insured plan:PL-STI-1^^:Missing rate factors, unable to retrieve a rate group = Default - Trip Interruption - Single Trip: missing factors=[RefData [activeFlag=true, code=AGE, name=Age, refId=PRD-RFACTORCAT-AGE, sortOrder=0]]
2013-10-15 15:20:23,799 WARN [tu.venture.sales.ejb.business.SalesPriceProcessor] Rate not found for insured plan:PL-SMED-3^^:Missing rate factors, unable to retrieve a rate group = Freedom - Medical Worldwide - Single Trip: missing factors=[RefData [activeFlag=true, code=AGE, name=Age, refId=PRD-RFACTORCAT-AGE, sortOrder=0], RefData [activeFlag=true, code=REGI, name=Region, refId=PRD-RFACTORCAT-REGI, sortOrder=10], RefData [activeFlag=true, code=FAM, name=Family, refId=PRD-RFACTORCAT-FAM, sortOrder=8], RefData [activeFlag=true, code=HLTH, name=Health, refId=PRD-RFACTORCAT-HLTH, sortOrder=2], RefData [activeFlag=true, code=TRIP, name=Trip Length, refId=PRD-RFACTORCAT-TRIP, sortOrder=3]]
2013-10-15 15:20:23,799 WARN [tu.venture.sales.ejb.business.SalesPriceProcessor] Rate not found for insured plan:PL-MMED-2^^:Missing rate factors, unable to retrieve a rate group = Freedom - Medical within Canada - Multi Trip: missing factors=[RefData [activeFlag=true, code=FAM, name=Family, refId=PRD-RFACTORCAT-FAM, sortOrder=8], RefData [activeFlag=true, code=AGE, name=Age, refId=PRD-RFACTORCAT-AGE, sortOrder=0]]
2013-10-15 15:20:23,799 WARN [tu.venture.sales.ejb.business.SalesPriceProcessor] Rate not found for insured plan:PL-SPCK-6^^:Missing rate factors, unable to retrieve a rate group = Freedom - Non Medical Package - Single Trip: missing factors=[RefData [activeFlag=true, code=AGE, name=Age, refId=PRD-RFACTORCAT-AGE, sortOrder=0]]
2013-10-15 15:20:23,799 WARN [tu.venture.sales.ejb.business.SalesPriceProcessor] Rate not found for insured plan:PL-MTI-1^^:Missing rate factors, unable to retrieve a rate group = Default - Trip Interruption - Multi Trip: missing factors=[RefData [activeFlag=true, code=AGE, name=Age, refId=PRD-RFACTORCAT-AGE, sortOrder=0]]
2013-10-15 15:20:23,801 INFO [STDOUT] Set minimum applied=true on plan=PL-SMED-3 minAmount=20
2013-10-15 15:20:23,802 INFO [STDOUT] Charged minimum premium=$20
                
> ClassCastException at ConditionEvaluator
> ----------------------------------------
>
>                 Key: DROOLS-185
>                 URL: https://issues.jboss.org/browse/DROOLS-185
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Sergey Alaev
>            Assignee: Mario Fusco
>
> Stacktrace:
> Caused by: java.lang.ClassCastException: ***** cannot be cast to ******
> 	at ConditionEvaluator443abf2927ca4f64a4ad86407ae34799.evaluate(Unknown Source)
> 	at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:200)
> 	at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:157)
> 	at org.drools.reteoo.FromNode.checkConstraintsAndPropagate(FromNode.java:318)
> 	at org.drools.reteoo.FromNode.assertLeftTuple(FromNode.java:164)
> 	at org.drools.reteoo.CompositeLeftTupleSinkAdapter.doPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:232)
> 	at org.drools.reteoo.CompositeLeftTupleSinkAdapter.createAndPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:116)
> 	at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:154)
> 	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:59)
> Reason:
> ConditionEvaluator seems to be using lazy initializing and then caches generated class to evaluate this expression with another arguments.
> Given following:
> interface A {
>    String getString();
> }
> interface B {
>    String getString();
> }
> class X implements B, A {}
> class Y implements A{}
> rule "test rule"
> when:
>      A(string != null)
> then:
> end
> When rule engine is called for the first time with instance of class X, ConditionEvaluator will bind itself to first found interface implementing method getString(), i.e. interface B.
> Thus second call with instance of class Y will cause ClassCastException of casting Y to B.
> Solution: force MVEL to bind bytecode generated methods to class/interface declared in the rule explicitly, in our case - to interface A.
> Quickfix: use following declaration of class X:
> class X implements A, B {}
> Because ConditionEvaluator binds to first available interface, it will bind now to correct interface - to interface A.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Tue Oct 15 20:02:35 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Tue, 15 Oct 2013 20:02:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-215) Corrupted Working/Production
	memory
In-Reply-To: <JIRA.12498476.1376388952000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498476.1376388952000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498476.1376388952000.5949.1381881755710@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814426#comment-12814426 ] 

Davide Sottara commented on DROOLS-215:
---------------------------------------

Ok, so the problem is definitely NOT related to this JIRA (CCE in ConcurrentNodeMemories), we'll have to move it to a different ticket.
The relevant part of the exception is pasted at the end of the commet : you have a pattern somewhere, in one of your rules, which 
has 3 beta constraints. One of them, when evaluated by MVEL, causes the CCE. 
- Could you try the very latest version of 5.6? Some bugs have been fixed there
- Could you try locating the rule with the constraint that causes the exception? Looking at the stacktrace, you should have at least 4 patterns,
the first should be for RefData() or one of its subclasses and the last one has exactly three beta constraints involving variables declared
on the previous objects.

RefData( /* only bindings here */ )
AAA( ... )
BBB( ... )
CCC( ..., f1 op $x, f2 op $y, f3 op $z, ... ) // exactly three constraints involving variables
....


2013-10-15 15:20:23,756 ERROR [STDERR] Caused by: java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.Long
2013-10-15 15:20:23,756 ERROR [STDERR] at ConditionEvaluatordf13704748e74e68a38cf5bb6c1630ef.evaluate(Unknown Source)
2013-10-15 15:20:23,756 ERROR [STDERR] at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:167)
2013-10-15 15:20:23,756 ERROR [STDERR] at org.drools.rule.constraint.MvelConstraint.isAllowedCachedLeft(MvelConstraint.java:136)
2013-10-15 15:20:23,756 ERROR [STDERR] at org.drools.common.TripleBetaConstraints.isAllowedCachedLeft(TripleBetaConstraints.java:199)
2013-10-15 15:20:23,756 ERROR [STDERR] at org.drools.reteoo.JoinNode.assertLeftTuple(JoinNode.java:96)
2013-10-15 15:20:23,756 ERROR [STDERR] at org.drools.reteoo.CompositeLeftTupleSinkAdapter.doPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:232)
2013-10-15 15:20:23,756 ERROR [STDERR] at org.drools.reteoo.CompositeLeftTupleSinkAdapter.propagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:89)
2013-10-15 15:20:23,756 ERROR [STDERR] at org.drools.reteoo.JoinNode.assertLeftTuple(JoinNode.java:98)
2013-10-15 15:20:23,756 ERROR [STDERR] at org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:196)
2013-10-15 15:20:23,756 ERROR [STDERR] at org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:71)
2013-10-15 15:20:23,756 ERROR [STDERR] at org.drools.reteoo.JoinNode.assertLeftTuple(JoinNode.java:98)
2013-10-15 15:20:23,756 ERROR [STDERR] at org.drools.reteoo.CompositeLeftTupleSinkAdapter.doPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:232)
2013-10-15 15:20:23,756 ERROR [STDERR] at org.drools.reteoo.CompositeLeftTupleSinkAdapter.createAndPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:116)
2013-10-15 15:20:23,756 ERROR [STDERR] at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:154)
2013-10-15 15:20:23,756 ERROR [STDERR] at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:59)
2013-10-15 15:20:23,756 ERROR [STDERR] at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:364)
2013-10-15 15:20:23,756 ERROR [STDERR] at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235)
2013-10-15 15:20:23,756 ERROR [STDERR] at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240)
2013-10-15 15:20:23,756 ERROR [STDERR] at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:337)
2013-10-15 15:20:23,756 ERROR [STDERR] at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:298)
2013-10-15 15:20:23,756 ERROR [STDERR] at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:888)
2013-10-15 15:20:23,756 ERROR [STDERR] at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:187)
2013-10-15 15:20:23,756 ERROR [STDERR] at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:181)
2013-10-15 15:20:23,756 ERROR [STDERR] at sales.rules.sys.setup.Rule_10_ServiceRequest_InsertRefData_fbff25aa69474eb5a6023d156e613f1e.defaultConsequence(Rule_10_ServiceRequest_InsertRefData_fbff25aa69474eb5a6023d156e613f1e.java:10) 
                
> Corrupted Working/Production memory
> -----------------------------------
>
>                 Key: DROOLS-215
>                 URL: https://issues.jboss.org/browse/DROOLS-215
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Ales Dolecek
>            Assignee: Mark Proctor
>         Attachments: ConcurrentNodeMemories.java
>
>
> Experienced ClassCastException mixing BetaMemory and AlphaMemory. There is debate in the mailing list/forum. The problem seems to be related to dymanic updates of knowledgebase.
> Saddly there is no deterministic way how to reproduce the issue, but that should not prevent tracking it here.
> Stack trace from my project:
> java.lang.ClassCastException: org.drools.reteoo.BetaMemory cannot be cast to org.drools.reteoo.AlphaNode$AlphaMemory
>         at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:136) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:497) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:382) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:350) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:311) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:192) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:186) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at cz.nextiraone.screening.rules.screening.Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1.defaultConsequence(Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1.java:7) ~[na
> :na]
>         at cz.nextiraone.screening.rules.screening.Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1DefaultConsequenceInvokerGenerated.evaluate(Unknown Source) ~[na:na]
>         at cz.nextiraone.screening.rules.screening.Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1DefaultConsequenceInvoker.evaluate(Unknown Source) ~[na:na]
>         at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1287) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1221) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1456) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:710) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:674) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:230) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 22:08:35 2013
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Tue, 15 Oct 2013 22:08:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-121) Tracker JIRA for APIs required
 by the Java EE 7 Platform Specification
In-Reply-To: <JIRA.12485867.1362012695000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485867.1362012695000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485867.1362012695000.5989.1381889315678@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBEE-121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814436#comment-12814436 ] 

Shelly McGowan commented on JBEE-121:
-------------------------------------

Java EE 7 Specs API Bom ,v1.0.0.Beta2 has been released for use in EE 7 application development:
Java EE 7 Full Profile:
https://repository.jboss.org/nexus/content/groups/public/org/jboss/spec/jboss-javaee-7.0/1.0.0.Beta2/
Java EE 7 Web Profile:
https://repository.jboss.org/nexus/content/groups/public/org/jboss/spec/jboss-javaee-web-7.0/1.0.0.Beta2/
Uber Jar:
https://repository.jboss.org/nexus/content/groups/public/org/jboss/spec/jboss-javaee-all-7.0/1.0.0.Beta2/

                
> Tracker JIRA for APIs required by the Java EE 7 Platform Specification
> ----------------------------------------------------------------------
>
>                 Key: JBEE-121
>                 URL: https://issues.jboss.org/browse/JBEE-121
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: jboss-javaee-specs
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>             Fix For: JavaEE 7 Spec APIs 1.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 15 22:50:35 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 15 Oct 2013 22:50:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2312) WebVirtualHostDefinition
 isn't validating enable-welcome-root vs default-web-module
In-Reply-To: <JIRA.12503148.1381891762952@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503148.1381891762952@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503148.1381891762952.6003.1381891835474@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-2312:
--------------------------------------

             Summary: WebVirtualHostDefinition isn't validating enable-welcome-root vs default-web-module
                 Key: WFLY-2312
                 URL: https://issues.jboss.org/browse/WFLY-2312
             Project: WildFly
          Issue Type: Bug
          Components: Domain Management, Web (JBoss Web)
    Affects Versions: 8.0.0.Beta1
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
            Priority: Minor
             Fix For: 8.0.0.CR1


The validation of the relationship between enable-welcome-root and default-web-module was dropped during the conversion of the legacy web module to model-only mode.

This is no big deal as any legacy slave (without which the subsystem is pointless) will reject a problem. But I want to fix it anyway as the fix will help illustrate how to do a patch for EAP.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 02:53:35 2013
From: jira-events at lists.jboss.org (Josef Cacek (JIRA))
Date: Wed, 16 Oct 2013 02:53:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2313) Move test(s) with too long
 name(s) to a better place - prevent FNFE: File name too long
In-Reply-To: <JIRA.12503149.1381906346948@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503149.1381906346948@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503149.1381906346948.6075.1381906415492@jira02.app.mwc.hst.phx2.redhat.com>

Josef Cacek created WFLY-2313:
---------------------------------

             Summary: Move test(s) with too long name(s) to a better place - prevent  FNFE: File name too long
                 Key: WFLY-2313
                 URL: https://issues.jboss.org/browse/WFLY-2313
             Project: WildFly
          Issue Type: Bug
          Components: Test Suite
    Affects Versions: 8.0.0.Beta1
            Reporter: Josef Cacek
            Assignee: Josef Cacek


I'm getting FileNotFoundException (File name too long) when running AuditJoinTableoverOnetoManyJoinColumnTest. We should refactor the too long test names.

{code}
Running org.jboss.as.test.integration.jpa.hibernate.envers.auditjointableoveronetomanyjoincolumntest.AuditJoinTableoverOnetoManyJoinColumnTest
Exception in thread "ThreadedStreamConsumer" org.apache.maven.surefire.util.NestedRuntimeException: null; nested exception is java.io.FileNotFoundException: /home/jcacek/Java/Projects/wildfly/testsuite/integration/basic/target/surefire-reports/org.jboss.as.test.integration.jpa.hibernate.envers.auditjointableoveronetomanyjoincolumntest.AuditJoinTableoverOnetoManyJoinColumnTest-output.txt (File name too long)
java.io.FileNotFoundException: /home/jcacek/Java/Projects/wildfly/testsuite/integration/basic/target/surefire-reports/org.jboss.as.test.integration.jpa.hibernate.envers.auditjointableoveronetomanyjoincolumntest.AuditJoinTableoverOnetoManyJoinColumnTest-output.txt (File name too long)
	at java.io.FileOutputStream.open(Native Method)
	at java.io.FileOutputStream.<init>(FileOutputStream.java:212)
	at java.io.FileOutputStream.<init>(FileOutputStream.java:165)
	at java.io.FileWriter.<init>(FileWriter.java:90)
	at org.apache.maven.surefire.report.ConsoleOutputFileReporter.writeMessage(ConsoleOutputFileReporter.java:89)
	at org.apache.maven.surefire.report.MulticastingReporter.writeMessage(MulticastingReporter.java:101)
	at org.apache.maven.surefire.report.TestSetRunListener.writeTestOutput(TestSetRunListener.java:105)
	at org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:132)
	at org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:67)
	at java.lang.Thread.run(Thread.java:724)
{code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 03:01:37 2013
From: jira-events at lists.jboss.org (Sergey Alaev (JIRA))
Date: Wed, 16 Oct 2013 03:01:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-185) ClassCastException at
	ConditionEvaluator
In-Reply-To: <JIRA.12495435.1372690482000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495435.1372690482000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495435.1372690482000.6093.1381906897006@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814455#comment-12814455 ] 

Sergey Alaev commented on DROOLS-185:
-------------------------------------

Gurinder Randhawa,

Here is some more information about that bug:

It appears randomly on ANY overridden field used in left half of a rule.
Thus currently there is only way to avoid potential prod issues related to this problem - you must get rid of ALL overriden getters/setters from your domain model.
                
> ClassCastException at ConditionEvaluator
> ----------------------------------------
>
>                 Key: DROOLS-185
>                 URL: https://issues.jboss.org/browse/DROOLS-185
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Sergey Alaev
>            Assignee: Mario Fusco
>
> Stacktrace:
> Caused by: java.lang.ClassCastException: ***** cannot be cast to ******
> 	at ConditionEvaluator443abf2927ca4f64a4ad86407ae34799.evaluate(Unknown Source)
> 	at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:200)
> 	at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:157)
> 	at org.drools.reteoo.FromNode.checkConstraintsAndPropagate(FromNode.java:318)
> 	at org.drools.reteoo.FromNode.assertLeftTuple(FromNode.java:164)
> 	at org.drools.reteoo.CompositeLeftTupleSinkAdapter.doPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:232)
> 	at org.drools.reteoo.CompositeLeftTupleSinkAdapter.createAndPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:116)
> 	at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:154)
> 	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:59)
> Reason:
> ConditionEvaluator seems to be using lazy initializing and then caches generated class to evaluate this expression with another arguments.
> Given following:
> interface A {
>    String getString();
> }
> interface B {
>    String getString();
> }
> class X implements B, A {}
> class Y implements A{}
> rule "test rule"
> when:
>      A(string != null)
> then:
> end
> When rule engine is called for the first time with instance of class X, ConditionEvaluator will bind itself to first found interface implementing method getString(), i.e. interface B.
> Thus second call with instance of class Y will cause ClassCastException of casting Y to B.
> Solution: force MVEL to bind bytecode generated methods to class/interface declared in the rule explicitly, in our case - to interface A.
> Quickfix: use following declaration of class X:
> class X implements A, B {}
> Because ConditionEvaluator binds to first available interface, it will bind now to correct interface - to interface A.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 04:31:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Wed, 16 Oct 2013 04:31:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-300) Add optional start and end
 arguments to timers
In-Reply-To: <JIRA.12503113.1381861876000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503113.1381861876000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503113.1381861876000.191.1381912262000@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814525#comment-12814525 ] 

Mario Fusco commented on DROOLS-300:
------------------------------------

We are adding 3 optional parameters named "start", "end" and "repeat-limit" to interval and expression timers.

When one or more of these parameters are used the first part of the timer definition must be followed by a semicolon ';' and the parameters have to be separated by a comma ',' as in the following example:

timer (int: 30s 10s; start=3-JAN-2010, end=5-JAN-2010)

The value for start and end parameters can be a Date, a String representing a Date or a long or more in general any Number that will be transformed in a date with the following conversion:

new Date( ((Number) n).longValue() )

The value for those parameters can also be any expression that can be resolved in any of the before mentioned type so for instance the following DRL will be valid:

declare Bean
    delay   : String = "30s"
    period  : long = 60000
    start   : String = "3-JAN-2010"
end

rule R 
    timer( expr: $d, $p; start=$s )
when
    Bean( $d : delay, $p : period, $s : start )
then
end
 
The date eventually defined by the end parameter represents the moment when the timer will stop triggering. In the same way the repeat-limit one defines the maximum number of repetitions allowed by the timer. If both are set the timer will stop when the first of the two will be matched.

For backward compatibility when none of these optional parameters is used the timers will behave as before. However when the start parameter is set it defines a phase for the timer, where the start of the phase is given by the start itself plus the eventual delay. In other words the timed rule will then be scheduled at times:

start + delay + n*period 

for up to max repetitions and no later than the end timestamp (whichever first). It means that the rule defined in the former DRL will be scheduled at 30th second of every minute after the midnight of the 3-JAN-2010. So if you turn the system on at midnight of the 3-FEB-2010 it won't be scheduled immediately but will preserve the phase defined by the timer and so it will be scheduled for the first time 30 seconds after the midnight. If for some reason the system is paused (e.g. the session is serialized and then deserialized after a while) the rule will be scheduled only once to recover from missing activations (regardless of how many activations we missed) and subsequently it will be scheduled again in phase with the timer.

Those parameters are not available on the cron timers because they already allow you to define a phase without them, so the start value could be potentially in contrast with it.

                
> Add optional start and end arguments to timers
> ----------------------------------------------
>
>                 Key: DROOLS-300
>                 URL: https://issues.jboss.org/browse/DROOLS-300
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 04:31:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Wed, 16 Oct 2013 04:31:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-300) Add optional start and end
 arguments to timers
In-Reply-To: <JIRA.12503113.1381861876000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503113.1381861876000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503113.1381861876000.197.1381912262443@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814525#comment-12814525 ] 

Mario Fusco edited comment on DROOLS-300 at 10/16/13 4:30 AM:
--------------------------------------------------------------

We are adding 3 optional parameters named "start", "end" and "repeat-limit" to interval and expression timers.

When one or more of these parameters are used the first part of the timer definition must be followed by a semicolon ';' and the parameters have to be separated by a comma ',' as in the following example:

timer (int: 30s 10s; start=3-JAN-2010, end=5-JAN-2010)

The value for start and end parameters can be a Date, a String representing a Date or a long or more in general any Number that will be transformed in a date with the following conversion:
{{{
new Date( ((Number) n).longValue() )
}}}

The value for those parameters can also be any expression that can be resolved in any of the before mentioned type so for instance the following DRL will be valid:

{{{
declare Bean
    delay   : String = "30s"
    period  : long = 60000
    start   : String = "3-JAN-2010"
end

rule R 
    timer( expr: $d, $p; start=$s )
when
    Bean( $d : delay, $p : period, $s : start )
then
end
}}}
 
The date eventually defined by the end parameter represents the moment when the timer will stop triggering. In the same way the repeat-limit one defines the maximum number of repetitions allowed by the timer. If both are set the timer will stop when the first of the two will be matched.

For backward compatibility when none of these optional parameters is used the timers will behave as before. However when the start parameter is set it defines a phase for the timer, where the start of the phase is given by the start itself plus the eventual delay. In other words the timed rule will then be scheduled at times:

{{{
start + delay + n*period 
}}}

for up to max repetitions and no later than the end timestamp (whichever first). It means that the rule defined in the former DRL will be scheduled at 30th second of every minute after the midnight of the 3-JAN-2010. So if you turn the system on at midnight of the 3-FEB-2010 it won't be scheduled immediately but will preserve the phase defined by the timer and so it will be scheduled for the first time 30 seconds after the midnight. If for some reason the system is paused (e.g. the session is serialized and then deserialized after a while) the rule will be scheduled only once to recover from missing activations (regardless of how many activations we missed) and subsequently it will be scheduled again in phase with the timer.

Those parameters are not available on the cron timers because they already allow you to define a phase without them, so the start value could be potentially in contrast with it.

                
      was (Author: mfusco):
    We are adding 3 optional parameters named "start", "end" and "repeat-limit" to interval and expression timers.

When one or more of these parameters are used the first part of the timer definition must be followed by a semicolon ';' and the parameters have to be separated by a comma ',' as in the following example:

timer (int: 30s 10s; start=3-JAN-2010, end=5-JAN-2010)

The value for start and end parameters can be a Date, a String representing a Date or a long or more in general any Number that will be transformed in a date with the following conversion:

new Date( ((Number) n).longValue() )

The value for those parameters can also be any expression that can be resolved in any of the before mentioned type so for instance the following DRL will be valid:

declare Bean
    delay   : String = "30s"
    period  : long = 60000
    start   : String = "3-JAN-2010"
end

rule R 
    timer( expr: $d, $p; start=$s )
when
    Bean( $d : delay, $p : period, $s : start )
then
end
 
The date eventually defined by the end parameter represents the moment when the timer will stop triggering. In the same way the repeat-limit one defines the maximum number of repetitions allowed by the timer. If both are set the timer will stop when the first of the two will be matched.

For backward compatibility when none of these optional parameters is used the timers will behave as before. However when the start parameter is set it defines a phase for the timer, where the start of the phase is given by the start itself plus the eventual delay. In other words the timed rule will then be scheduled at times:

start + delay + n*period 

for up to max repetitions and no later than the end timestamp (whichever first). It means that the rule defined in the former DRL will be scheduled at 30th second of every minute after the midnight of the 3-JAN-2010. So if you turn the system on at midnight of the 3-FEB-2010 it won't be scheduled immediately but will preserve the phase defined by the timer and so it will be scheduled for the first time 30 seconds after the midnight. If for some reason the system is paused (e.g. the session is serialized and then deserialized after a while) the rule will be scheduled only once to recover from missing activations (regardless of how many activations we missed) and subsequently it will be scheduled again in phase with the timer.

Those parameters are not available on the cron timers because they already allow you to define a phase without them, so the start value could be potentially in contrast with it.

                  
> Add optional start and end arguments to timers
> ----------------------------------------------
>
>                 Key: DROOLS-300
>                 URL: https://issues.jboss.org/browse/DROOLS-300
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 04:33:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Wed, 16 Oct 2013 04:33:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-300) Add optional start and end
 arguments to timers
In-Reply-To: <JIRA.12503113.1381861876000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503113.1381861876000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503113.1381861876000.200.1381912382101@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814525#comment-12814525 ] 

Mario Fusco edited comment on DROOLS-300 at 10/16/13 4:31 AM:
--------------------------------------------------------------

We are adding 3 optional parameters named "start", "end" and "repeat-limit" to interval and expression timers.

When one or more of these parameters are used the first part of the timer definition must be followed by a semicolon ';' and the parameters have to be separated by a comma ',' as in the following example:

timer (int: 30s 10s; start=3-JAN-2010, end=5-JAN-2010)

The value for start and end parameters can be a Date, a String representing a Date or a long or more in general any Number that will be transformed in a date with the following conversion:
{{
new Date( ((Number) n).longValue() )
}}

The value for those parameters can also be any expression that can be resolved in any of the before mentioned type so for instance the following DRL will be valid:

{{
declare Bean
    delay   : String = "30s"
    period  : long = 60000
    start   : String = "3-JAN-2010"
end

rule R 
    timer( expr: $d, $p; start=$s )
when
    Bean( $d : delay, $p : period, $s : start )
then
end
}}
 
The date eventually defined by the end parameter represents the moment when the timer will stop triggering. In the same way the repeat-limit one defines the maximum number of repetitions allowed by the timer. If both are set the timer will stop when the first of the two will be matched.

For backward compatibility when none of these optional parameters is used the timers will behave as before. However when the start parameter is set it defines a phase for the timer, where the start of the phase is given by the start itself plus the eventual delay. In other words the timed rule will then be scheduled at times:

{{
start + delay + n*period 
}}

for up to max repetitions and no later than the end timestamp (whichever first). It means that the rule defined in the former DRL will be scheduled at 30th second of every minute after the midnight of the 3-JAN-2010. So if you turn the system on at midnight of the 3-FEB-2010 it won't be scheduled immediately but will preserve the phase defined by the timer and so it will be scheduled for the first time 30 seconds after the midnight. If for some reason the system is paused (e.g. the session is serialized and then deserialized after a while) the rule will be scheduled only once to recover from missing activations (regardless of how many activations we missed) and subsequently it will be scheduled again in phase with the timer.

Those parameters are not available on the cron timers because they already allow you to define a phase without them, so the start value could be potentially in contrast with it.

                
      was (Author: mfusco):
    We are adding 3 optional parameters named "start", "end" and "repeat-limit" to interval and expression timers.

When one or more of these parameters are used the first part of the timer definition must be followed by a semicolon ';' and the parameters have to be separated by a comma ',' as in the following example:

timer (int: 30s 10s; start=3-JAN-2010, end=5-JAN-2010)

The value for start and end parameters can be a Date, a String representing a Date or a long or more in general any Number that will be transformed in a date with the following conversion:
{{{
new Date( ((Number) n).longValue() )
}}}

The value for those parameters can also be any expression that can be resolved in any of the before mentioned type so for instance the following DRL will be valid:

{{{
declare Bean
    delay   : String = "30s"
    period  : long = 60000
    start   : String = "3-JAN-2010"
end

rule R 
    timer( expr: $d, $p; start=$s )
when
    Bean( $d : delay, $p : period, $s : start )
then
end
}}}
 
The date eventually defined by the end parameter represents the moment when the timer will stop triggering. In the same way the repeat-limit one defines the maximum number of repetitions allowed by the timer. If both are set the timer will stop when the first of the two will be matched.

For backward compatibility when none of these optional parameters is used the timers will behave as before. However when the start parameter is set it defines a phase for the timer, where the start of the phase is given by the start itself plus the eventual delay. In other words the timed rule will then be scheduled at times:

{{{
start + delay + n*period 
}}}

for up to max repetitions and no later than the end timestamp (whichever first). It means that the rule defined in the former DRL will be scheduled at 30th second of every minute after the midnight of the 3-JAN-2010. So if you turn the system on at midnight of the 3-FEB-2010 it won't be scheduled immediately but will preserve the phase defined by the timer and so it will be scheduled for the first time 30 seconds after the midnight. If for some reason the system is paused (e.g. the session is serialized and then deserialized after a while) the rule will be scheduled only once to recover from missing activations (regardless of how many activations we missed) and subsequently it will be scheduled again in phase with the timer.

Those parameters are not available on the cron timers because they already allow you to define a phase without them, so the start value could be potentially in contrast with it.

                  
> Add optional start and end arguments to timers
> ----------------------------------------------
>
>                 Key: DROOLS-300
>                 URL: https://issues.jboss.org/browse/DROOLS-300
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 04:33:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Wed, 16 Oct 2013 04:33:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-300) Add optional start and end
 arguments to timers
In-Reply-To: <JIRA.12503113.1381861876000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503113.1381861876000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503113.1381861876000.201.1381912382204@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814525#comment-12814525 ] 

Mario Fusco edited comment on DROOLS-300 at 10/16/13 4:32 AM:
--------------------------------------------------------------

We are adding 3 optional parameters named "start", "end" and "repeat-limit" to interval and expression timers.

When one or more of these parameters are used the first part of the timer definition must be followed by a semicolon ';' and the parameters have to be separated by a comma ',' as in the following example:

timer (int: 30s 10s; start=3-JAN-2010, end=5-JAN-2010)

The value for start and end parameters can be a Date, a String representing a Date or a long or more in general any Number that will be transformed in a date with the following conversion:
{{new Date( ((Number) n).longValue() )}}

The value for those parameters can also be any expression that can be resolved in any of the before mentioned type so for instance the following DRL will be valid:

{{declare Bean
    delay   : String = "30s"
    period  : long = 60000
    start   : String = "3-JAN-2010"
end

rule R 
    timer( expr: $d, $p; start=$s )
when
    Bean( $d : delay, $p : period, $s : start )
then
end}}
 
The date eventually defined by the end parameter represents the moment when the timer will stop triggering. In the same way the repeat-limit one defines the maximum number of repetitions allowed by the timer. If both are set the timer will stop when the first of the two will be matched.

For backward compatibility when none of these optional parameters is used the timers will behave as before. However when the start parameter is set it defines a phase for the timer, where the start of the phase is given by the start itself plus the eventual delay. In other words the timed rule will then be scheduled at times:

{{start + delay + n*period }}

for up to max repetitions and no later than the end timestamp (whichever first). It means that the rule defined in the former DRL will be scheduled at 30th second of every minute after the midnight of the 3-JAN-2010. So if you turn the system on at midnight of the 3-FEB-2010 it won't be scheduled immediately but will preserve the phase defined by the timer and so it will be scheduled for the first time 30 seconds after the midnight. If for some reason the system is paused (e.g. the session is serialized and then deserialized after a while) the rule will be scheduled only once to recover from missing activations (regardless of how many activations we missed) and subsequently it will be scheduled again in phase with the timer.

Those parameters are not available on the cron timers because they already allow you to define a phase without them, so the start value could be potentially in contrast with it.

                
      was (Author: mfusco):
    We are adding 3 optional parameters named "start", "end" and "repeat-limit" to interval and expression timers.

When one or more of these parameters are used the first part of the timer definition must be followed by a semicolon ';' and the parameters have to be separated by a comma ',' as in the following example:

timer (int: 30s 10s; start=3-JAN-2010, end=5-JAN-2010)

The value for start and end parameters can be a Date, a String representing a Date or a long or more in general any Number that will be transformed in a date with the following conversion:
{{
new Date( ((Number) n).longValue() )
}}

The value for those parameters can also be any expression that can be resolved in any of the before mentioned type so for instance the following DRL will be valid:

{{
declare Bean
    delay   : String = "30s"
    period  : long = 60000
    start   : String = "3-JAN-2010"
end

rule R 
    timer( expr: $d, $p; start=$s )
when
    Bean( $d : delay, $p : period, $s : start )
then
end
}}
 
The date eventually defined by the end parameter represents the moment when the timer will stop triggering. In the same way the repeat-limit one defines the maximum number of repetitions allowed by the timer. If both are set the timer will stop when the first of the two will be matched.

For backward compatibility when none of these optional parameters is used the timers will behave as before. However when the start parameter is set it defines a phase for the timer, where the start of the phase is given by the start itself plus the eventual delay. In other words the timed rule will then be scheduled at times:

{{
start + delay + n*period 
}}

for up to max repetitions and no later than the end timestamp (whichever first). It means that the rule defined in the former DRL will be scheduled at 30th second of every minute after the midnight of the 3-JAN-2010. So if you turn the system on at midnight of the 3-FEB-2010 it won't be scheduled immediately but will preserve the phase defined by the timer and so it will be scheduled for the first time 30 seconds after the midnight. If for some reason the system is paused (e.g. the session is serialized and then deserialized after a while) the rule will be scheduled only once to recover from missing activations (regardless of how many activations we missed) and subsequently it will be scheduled again in phase with the timer.

Those parameters are not available on the cron timers because they already allow you to define a phase without them, so the start value could be potentially in contrast with it.

                  
> Add optional start and end arguments to timers
> ----------------------------------------------
>
>                 Key: DROOLS-300
>                 URL: https://issues.jboss.org/browse/DROOLS-300
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 04:35:01 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Wed, 16 Oct 2013 04:35:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-300) Add optional start and end
 arguments to timers
In-Reply-To: <JIRA.12503113.1381861876000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503113.1381861876000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503113.1381861876000.211.1381912501969@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814525#comment-12814525 ] 

Mario Fusco edited comment on DROOLS-300 at 10/16/13 4:33 AM:
--------------------------------------------------------------

We are adding 3 optional parameters named "start", "end" and "repeat-limit" to interval and expression timers.

When one or more of these parameters are used the first part of the timer definition must be followed by a semicolon ';' and the parameters have to be separated by a comma ',' as in the following example:

{code}
timer (int: 30s 10s; start=3-JAN-2010, end=5-JAN-2010)
{code}

The value for start and end parameters can be a Date, a String representing a Date or a long or more in general any Number that will be transformed in a date with the following conversion:

{code}
new Date( ((Number) n).longValue() )
{code}

The value for those parameters can also be any expression that can be resolved in any of the before mentioned type so for instance the following DRL will be valid:

{code}
declare Bean
    delay   : String = "30s"
    period  : long = 60000
    start   : String = "3-JAN-2010"
end

rule R 
    timer( expr: $d, $p; start=$s )
when
    Bean( $d : delay, $p : period, $s : start )
then
end
{code}
 
The date eventually defined by the end parameter represents the moment when the timer will stop triggering. In the same way the repeat-limit one defines the maximum number of repetitions allowed by the timer. If both are set the timer will stop when the first of the two will be matched.

For backward compatibility when none of these optional parameters is used the timers will behave as before. However when the start parameter is set it defines a phase for the timer, where the start of the phase is given by the start itself plus the eventual delay. In other words the timed rule will then be scheduled at times:

{code}
start + delay + n*period 
{code}

for up to max repetitions and no later than the end timestamp (whichever first). It means that the rule defined in the former DRL will be scheduled at 30th second of every minute after the midnight of the 3-JAN-2010. So if you turn the system on at midnight of the 3-FEB-2010 it won't be scheduled immediately but will preserve the phase defined by the timer and so it will be scheduled for the first time 30 seconds after the midnight. If for some reason the system is paused (e.g. the session is serialized and then deserialized after a while) the rule will be scheduled only once to recover from missing activations (regardless of how many activations we missed) and subsequently it will be scheduled again in phase with the timer.

Those parameters are not available on the cron timers because they already allow you to define a phase without them, so the start value could be potentially in contrast with it.

                
      was (Author: mfusco):
    We are adding 3 optional parameters named "start", "end" and "repeat-limit" to interval and expression timers.

When one or more of these parameters are used the first part of the timer definition must be followed by a semicolon ';' and the parameters have to be separated by a comma ',' as in the following example:

timer (int: 30s 10s; start=3-JAN-2010, end=5-JAN-2010)

The value for start and end parameters can be a Date, a String representing a Date or a long or more in general any Number that will be transformed in a date with the following conversion:
{{new Date( ((Number) n).longValue() )}}

The value for those parameters can also be any expression that can be resolved in any of the before mentioned type so for instance the following DRL will be valid:

{{declare Bean
    delay   : String = "30s"
    period  : long = 60000
    start   : String = "3-JAN-2010"
end

rule R 
    timer( expr: $d, $p; start=$s )
when
    Bean( $d : delay, $p : period, $s : start )
then
end}}
 
The date eventually defined by the end parameter represents the moment when the timer will stop triggering. In the same way the repeat-limit one defines the maximum number of repetitions allowed by the timer. If both are set the timer will stop when the first of the two will be matched.

For backward compatibility when none of these optional parameters is used the timers will behave as before. However when the start parameter is set it defines a phase for the timer, where the start of the phase is given by the start itself plus the eventual delay. In other words the timed rule will then be scheduled at times:

{{start + delay + n*period }}

for up to max repetitions and no later than the end timestamp (whichever first). It means that the rule defined in the former DRL will be scheduled at 30th second of every minute after the midnight of the 3-JAN-2010. So if you turn the system on at midnight of the 3-FEB-2010 it won't be scheduled immediately but will preserve the phase defined by the timer and so it will be scheduled for the first time 30 seconds after the midnight. If for some reason the system is paused (e.g. the session is serialized and then deserialized after a while) the rule will be scheduled only once to recover from missing activations (regardless of how many activations we missed) and subsequently it will be scheduled again in phase with the timer.

Those parameters are not available on the cron timers because they already allow you to define a phase without them, so the start value could be potentially in contrast with it.

                  
> Add optional start and end arguments to timers
> ----------------------------------------------
>
>                 Key: DROOLS-300
>                 URL: https://issues.jboss.org/browse/DROOLS-300
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 05:01:02 2013
From: jira-events at lists.jboss.org (Radim Vansa (JIRA))
Date: Wed, 16 Oct 2013 05:01:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1716) The UDP receiver thread
 parsing messages causes performance regression
In-Reply-To: <JIRA.12503100.1381850347000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503100.1381850347000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503100.1381850347000.232.1381914062307@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radim Vansa updated JGRP-1716:
------------------------------

    Attachment: benchmark-jgroups.xml
                jgroups-udp.xml


Yes, the chart is based on results obtained with RadarGun. I am attaching the benchmark and JGroups configuration (just rename it to jgroups-udp-custom.xml) used to show the difference.
RadarGun can be checked out from https://github.com/radargun/radargun (you may want to change JGroups version in jgroups34 plugin's pom.xml from Beta1 to Final).
                
> The UDP receiver thread parsing messages causes performance regression
> ----------------------------------------------------------------------
>
>                 Key: JGRP-1716
>                 URL: https://issues.jboss.org/browse/JGRP-1716
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Dan Berindei
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>         Attachments: benchmark-jgroups.xml, jgroups-udp.pdf, jgroups-udp.xml
>
>
> Comparing JGroups 3.2/3.3/3.4 performance with Radargun, the throughput went down by ~10%. (See the attached chart. "getall" means the get requests are sent to 2 nodes, "getfirst" means they are sent to only 1 node.)
> Erik Salter profiled his application and noticed that the message parsing in the UDP receiver thread seemed to slow things down. He wrote a patch that brought his throughput back to 3.2 levels: https://github.com/an1310/JGroups/compare/t_perfhack
> The UDP receiver thread may not tell the whole story, however: in the Radargun tests, performance with his patch was even lower.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 05:03:02 2013
From: jira-events at lists.jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Wed, 16 Oct 2013 05:03:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-287) Rule names with
 non-alphabetic characters may lead to name clashes
In-Reply-To: <JIRA.12502262.1380953728000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502262.1380953728000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502262.1380953728000.243.1381914182993@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-287:
------------------------------------------

    Fix Version/s: 6.0.0.Final
                       (was: 6.0.0.CR5)

    
> Rule names with non-alphabetic characters may lead to name clashes
> ------------------------------------------------------------------
>
>                 Key: DROOLS-287
>                 URL: https://issues.jboss.org/browse/DROOLS-287
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final,  6.0.0.CR4
>            Reporter: Davide Sottara
>            Assignee: Mark Proctor
>            Priority: Critical
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> A KB with the two following rules will not compile:
> {code}
> rule "Rule_>"
> when then end
> rule "Rule_<"
> when then end
> {code}
> Here's a more realistic example:
> {code}
> rule "dollar > euro"
> when then end
> rule "dollar < euro"
> when then end
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 05:03:03 2013
From: jira-events at lists.jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Wed, 16 Oct 2013 05:03:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-285)
 JtaTransactionSynchronizationAdapter contains infite loop
In-Reply-To: <JIRA.12502197.1380886759000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502197.1380886759000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502197.1380886759000.250.1381914183295@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-285:
------------------------------------------

    Fix Version/s: 6.0.0.Final
                       (was: 6.0.0.CR5)

    
> JtaTransactionSynchronizationAdapter contains infite loop
> ---------------------------------------------------------
>
>                 Key: DROOLS-285
>                 URL: https://issues.jboss.org/browse/DROOLS-285
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Nils Miehe
>            Assignee: Mark Proctor
>             Fix For: 6.0.0.Final
>
>
> I stumbled upon this while searching for a potential cause of JBPM-4132 .
> In the method afterCompletion of JtaTransactionSynchronizationAdapter a call with STATUS_ACTIVE would cause an infinite loop. As this value in itself indicates an inconsistent state the error probably wasn't noticed earlier.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 05:03:03 2013
From: jira-events at lists.jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Wed, 16 Oct 2013 05:03:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-257) Past events beyond
 expiration are not expired
In-Reply-To: <JIRA.12500351.1378778236000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500351.1378778236000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500351.1378778236000.254.1381914183485@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-257:
------------------------------------------

    Fix Version/s: 6.0.0.Final
                       (was: 6.0.0.CR5)

    
> Past events beyond expiration are not expired
> ---------------------------------------------
>
>                 Key: DROOLS-257
>                 URL: https://issues.jboss.org/browse/DROOLS-257
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final,  6.0.0.CR3
>            Reporter: Davide Sottara
>            Assignee: Mark Proctor
>            Priority: Critical
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 05:03:03 2013
From: jira-events at lists.jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Wed, 16 Oct 2013 05:03:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-254) "Exists OR" rules are
 compiled inconsistently
In-Reply-To: <JIRA.12500231.1378486146000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500231.1378486146000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500231.1378486146000.258.1381914183672@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-254:
------------------------------------------

    Fix Version/s: 6.0.0.Final
                       (was: 6.0.0.CR5)

    
> "Exists OR" rules are compiled inconsistently
> ---------------------------------------------
>
>                 Key: DROOLS-254
>                 URL: https://issues.jboss.org/browse/DROOLS-254
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final,  6.0.0.CR3
>            Reporter: Davide Sottara
>            Assignee: Mark Proctor
>            Priority: Critical
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> Exists ( A or B ) is transformed into ( Exists A ) or ( Exists B )
> In case both A and B are asserted, they result in two activations, 
> whereas one would expect only one. 
> Moreover, the equivalent not ( (not A) and (not B) ) results in only
> one activation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 05:03:03 2013
From: jira-events at lists.jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Wed, 16 Oct 2013 05:03:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-251) Classloader fails to resolve
 when annotation and declared class have the same name
In-Reply-To: <JIRA.12500015.1378364475000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500015.1378364475000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500015.1378364475000.262.1381914183835@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-251:
------------------------------------------

    Fix Version/s: 6.0.0.Final
                       (was: 6.0.0.CR5)

    
> Classloader fails to resolve when annotation and declared class have the same name
> ----------------------------------------------------------------------------------
>
>                 Key: DROOLS-251
>                 URL: https://issues.jboss.org/browse/DROOLS-251
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.CR2
>            Reporter: Davide Sottara
>            Assignee: Mark Proctor
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> package test
> declare Annot
>   fld : int @Annot
> end
> The packagebuilder type resolver will confuse the annotation with the declared class and throw exceptions (varies depending on optional import
> statements)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 05:03:03 2013
From: jira-events at lists.jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Wed, 16 Oct 2013 05:03:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-249) Handle conflicts when using
 @position in declared types
In-Reply-To: <JIRA.12500013.1378364090000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500013.1378364090000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500013.1378364090000.266.1381914183987@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-249:
------------------------------------------

    Fix Version/s: 6.0.0.Final
                       (was: 6.0.0.CR5)

    
> Handle conflicts when using @position in declared types
> -------------------------------------------------------
>
>                 Key: DROOLS-249
>                 URL: https://issues.jboss.org/browse/DROOLS-249
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.CR2
>            Reporter: Davide Sottara
>            Assignee: Mark Proctor
>            Priority: Minor
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> declare A
>  f : int @position(2)
>  g : int @position(1)
> end
> declare B extends A
>  h : int @position(3)
>  i : int @position(2)
> end
> The resulting field order may not be deterministic because of
>  - the clashes (2)
>  - the missing pos (0)
> this is dangerous when used with positional constraints
> B( $x, $y, $z, $w ; )
> Marked as minor because of the obvious workaround

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 05:03:04 2013
From: jira-events at lists.jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Wed, 16 Oct 2013 05:03:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-238) (Trait) hierarchy indexing
 and lookup is dramatically slower than needed
In-Reply-To: <JIRA.12499302.1377277962000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499302.1377277962000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499302.1377277962000.270.1381914184219@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-238:
------------------------------------------

    Fix Version/s: 6.0.0.Final
                       (was: 6.0.0.CR5)

    
> (Trait) hierarchy indexing and lookup is dramatically slower than needed
> ------------------------------------------------------------------------
>
>                 Key: DROOLS-238
>                 URL: https://issues.jboss.org/browse/DROOLS-238
>             Project: Drools
>          Issue Type: Quality Risk
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.CR1
>            Reporter: Davide Sottara
>            Assignee: Mark Proctor
>            Priority: Critical
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> The encoding is not optimized for performance, and suffers particularly in case of large, flat taxonomies

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 05:03:04 2013
From: jira-events at lists.jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Wed, 16 Oct 2013 05:03:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-201) Improve Rule Removal
In-Reply-To: <JIRA.12497212.1374649467000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497212.1374649467000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497212.1374649467000.273.1381914184326@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-201:
------------------------------------------

    Fix Version/s: 6.0.0.Final
                       (was: 6.0.0.CR5)

    
> Improve Rule Removal
> --------------------
>
>                 Key: DROOLS-201
>                 URL: https://issues.jboss.org/browse/DROOLS-201
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>            Assignee: Mark Proctor
>             Fix For: 6.0.0.Final
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 05:03:04 2013
From: jira-events at lists.jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Wed, 16 Oct 2013 05:03:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-134) Metadata inheritance is not
 resolved correctly when typeDeclarations are created implicitly
In-Reply-To: <JIRA.12491626.1368431589000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12491626.1368431589000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12491626.1368431589000.280.1381914184612@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-134:
------------------------------------------

    Fix Version/s: 6.0.0.Final
                       (was: 6.0.0.CR5)

    
> Metadata inheritance is not resolved correctly when typeDeclarations are created implicitly
> -------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-134
>                 URL: https://issues.jboss.org/browse/DROOLS-134
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.1.Final
>            Reporter: Davide Sottara
>            Assignee: Mark Proctor
>            Priority: Blocker
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> Implicit TypeDeclarations do not resolve declared metadata modifiers correctly

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 05:03:04 2013
From: jira-events at lists.jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Wed, 16 Oct 2013 05:03:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-198) Separate Rete and Phreak
In-Reply-To: <JIRA.12496969.1374456180000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496969.1374456180000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496969.1374456180000.276.1381914184449@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-198:
------------------------------------------

    Fix Version/s: 6.0.0.Final
                       (was: 6.0.0.CR5)

    
> Separate Rete and Phreak
> ------------------------
>
>                 Key: DROOLS-198
>                 URL: https://issues.jboss.org/browse/DROOLS-198
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>            Assignee: Mark Proctor
>             Fix For: 6.0.0.Final
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 05:03:05 2013
From: jira-events at lists.jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Wed, 16 Oct 2013 05:03:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-115) Add support for strong
	negation
In-Reply-To: <JIRA.12474560.1347671752000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12474560.1347671752000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12474560.1347671752000.288.1381914185014@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-115:
------------------------------------------

    Fix Version/s: 6.0.0.Final
                       (was: 6.0.0.CR5)

    
> Add support for strong negation
> -------------------------------
>
>                 Key: DROOLS-115
>                 URL: https://issues.jboss.org/browse/DROOLS-115
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Davide Sottara
>            Assignee: Davide Sottara
>            Priority: Minor
>             Fix For: 6.0.0.Final
>
>
> Drools "not" operator implements a type of "negation by failure", i.e. not X() behaves as the negation of "exists" or, in other words, translates as "it is NOT asserted that ...".
> However, another form of stronger negation is needed to express conditionals such as "it is asserted that NOT ..."
> It should be possible, then, to assert facts both in a "positive" and "negative" way, to assert THAT and THAT NOT. 
> The language should also support a "neg" CE to create "negative" patterns which will match with negative facts. I.e. it should be possible to write rules such as:
> when $p : Person() and Car( owner == $p ) then
> // a positive, matching Car is present in the WM
> when $p : Person() and neg Car( owner == $p ) then
> // a negative, matching Car is present in the WM
> when $p : Person() and not Car( owner == $p ) then
> // neither a positive nor a negative fact exists in the WM
> For a more detailed description and motivation see e.g.:
> https://oxygen.informatik.tu-cottbus.de/publications/wagner/WebRules2Neg.pdf

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 05:03:04 2013
From: jira-events at lists.jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Wed, 16 Oct 2013 05:03:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-126) Drools Verifier does not
 support Conditional Branches
In-Reply-To: <JIRA.12490994.1367522395000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12490994.1367522395000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12490994.1367522395000.284.1381914184799@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-126:
------------------------------------------

    Fix Version/s: 6.0.0.Final
                       (was: 6.0.0.CR5)

    
> Drools Verifier does not support Conditional Branches
> -----------------------------------------------------
>
>                 Key: DROOLS-126
>                 URL: https://issues.jboss.org/browse/DROOLS-126
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.Beta2
>            Reporter: Davide Sottara
>            Assignee: Toni Rikkola
>            Priority: Blocker
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> Drools Verifier has not been updated since the introduction of the Conditional Branches. 
> Any rule with a ConditionalBranchDescr would generate an exception
> when Verified.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 05:03:05 2013
From: jira-events at lists.jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Wed, 16 Oct 2013 05:03:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-88) Support generics in declared
	types' fields
In-Reply-To: <JIRA.12487865.1364200178000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12487865.1364200178000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487865.1364200178000.290.1381914185177@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer updated DROOLS-88:
-----------------------------------------

    Fix Version/s: 6.0.0.Final
                       (was: 6.0.0.CR5)

    
> Support generics in declared types' fields
> ------------------------------------------
>
>                 Key: DROOLS-88
>                 URL: https://issues.jboss.org/browse/DROOLS-88
>             Project: Drools
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Davide Sottara
>            Assignee: Davide Sottara
>            Priority: Minor
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> It should be possible to write:
> declare Foo
>   list : List<String>
> end
> While not supported in rules using the mvel dialect, it makes declared types much more readable, and adds some type-safety to java rules.
> Notice that this ticket is NOT related to the possibility of declaring generic classes, such as Foo<T>.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 05:07:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 16 Oct 2013 05:07:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2311) Confusing password
 requirements prompt in add-user.sh
In-Reply-To: <JIRA.12503144.1381874096000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503144.1381874096000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503144.1381874096000.308.1381914422364@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2311:
-----------------------------------

    Fix Version/s: 8.0.0.CR1

    
> Confusing password requirements prompt in add-user.sh
> -----------------------------------------------------
>
>                 Key: WFLY-2311
>                 URL: https://issues.jboss.org/browse/WFLY-2311
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Brian Stansberry
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> The add-user script prompt says the requirements for a password will be listed, but nothing is listed.
> What type of user do you wish to add? 
>  a) Management User (mgmt-users.properties) 
>  b) Application User (application-users.properties)
> (a): a
> Enter the details of the new user to add.
> Using realm 'ManagementRealm' as discovered from the existing property files.
> Username : bstansberry
> Password requirements are listed below. To modify these restrictions edit the add-user.properties configuration file.
> Password : 
> If there are no requirements, then some placeholder requirement like <no restrictions on password format> should be output.
> It seems there is at least a non-null/empty requirement, as I just created a user with 'b' as the password, but no password at all failed. So that requirement should be reported.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 05:07:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 16 Oct 2013 05:07:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2311) Confusing password
 requirements prompt in add-user.sh
In-Reply-To: <JIRA.12503144.1381874096000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503144.1381874096000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503144.1381874096000.312.1381914422736@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814537#comment-12814537 ] 

Darran Lofthouse commented on WFLY-2311:
----------------------------------------

That is weird - I still keep getting an ugly requirements list when I run it.
                
> Confusing password requirements prompt in add-user.sh
> -----------------------------------------------------
>
>                 Key: WFLY-2311
>                 URL: https://issues.jboss.org/browse/WFLY-2311
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Brian Stansberry
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> The add-user script prompt says the requirements for a password will be listed, but nothing is listed.
> What type of user do you wish to add? 
>  a) Management User (mgmt-users.properties) 
>  b) Application User (application-users.properties)
> (a): a
> Enter the details of the new user to add.
> Using realm 'ManagementRealm' as discovered from the existing property files.
> Username : bstansberry
> Password requirements are listed below. To modify these restrictions edit the add-user.properties configuration file.
> Password : 
> If there are no requirements, then some placeholder requirement like <no restrictions on password format> should be output.
> It seems there is at least a non-null/empty requirement, as I just created a user with 'b' as the password, but no password at all failed. So that requirement should be reported.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 05:17:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 16 Oct 2013 05:17:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1660) LockService hangs during
 concurrent access (tryLock/tryLock(timeout)/lock/unlock)
In-Reply-To: <JIRA.12496765.1374141727000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496765.1374141727000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496765.1374141727000.327.1381915022442@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1660:
---------------------------

    Fix Version/s: 3.5

    
> LockService hangs during concurrent access (tryLock/tryLock(timeout)/lock/unlock)
> ---------------------------------------------------------------------------------
>
>                 Key: JGRP-1660
>                 URL: https://issues.jboss.org/browse/JGRP-1660
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.4, 3.3.3
>         Environment: Intel(R) Core(TM) i5-2310 CPU @ 2.90GHz
> 6GB RAM
> Windows 7
> JRE 1.6.31
>            Reporter: Architect SoftWeb.ISD
>            Assignee: Bela Ban
>             Fix For: 3.3.5, 3.4, 3.5
>
>         Attachments: bla2.java, lock.xml, lock.xml, LockServiceStabilityTestCase.java, LockServiceStabilityTestCase.java, LockServiceStabilityTestCase.java, lockservice_stability_testcase.jar
>
>
> We have rather simple test that starts some amount of threads which in turn simultaneously obtain lock through LockService#getLock then perform lock and unlock.
> Each thread works during some time.
> After couple of seconds of work some threads just hang up in Locking$ClientLock(Object).wait() called indirectly from LockService$LockImpl.tryLock().
> Here is stack trace:
> Thread [Thread-ClientImitation-1] (Suspended)                
>                 Object.wait(long) line: not available [native method]      
>                 Locking$ClientLock(Object).wait() line: 485          
>                 Locking$ClientLock.acquireTryLock(long, boolean) line: 1010       
>                 Locking$ClientLock.tryLock() line: 896     
>                 CENTRAL_LOCK(Locking).down(Event) line: 152                
>                 ProtocolStack.down(Event) line: 1025    
>                 JChannel.down(Event) line: 718                
>                 LockService$LockImpl.tryLock() line: 102               
>                 LockServiceStabilityTestCase$ClientImitation.run() line: 167        
>                 Thread.run() line: 662     

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 05:59:02 2013
From: jira-events at lists.jboss.org (Matti Linnanvuori (JIRA))
Date: Wed, 16 Oct 2013 05:59:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2314)
 @Consumes(MediaType.APPLICATION_FORM_URLENCODED) MultivaluedMap<String,
 String> form did not work in RESTEasy JAX-RS 3.0.4.Final
In-Reply-To: <JIRA.12503221.1381917463775@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503221.1381917463775@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503221.1381917463775.394.1381917542141@jira02.app.mwc.hst.phx2.redhat.com>

Matti Linnanvuori created WFLY-2314:
---------------------------------------

             Summary: @Consumes(MediaType.APPLICATION_FORM_URLENCODED) MultivaluedMap<String, String> form did not work in RESTEasy JAX-RS 3.0.4.Final
                 Key: WFLY-2314
                 URL: https://issues.jboss.org/browse/WFLY-2314
             Project: WildFly
          Issue Type: Bug
          Components: REST
    Affects Versions: 8.0.0.Beta1
         Environment: Linux Debian
            Reporter: Matti Linnanvuori
            Assignee: Stuart Douglas


@Consumes(MediaType.APPLICATION_FORM_URLENCODED) did not work with RESTEasy JAX-RS 3.0.4.Final but the form variable was empty. @FormParam works.

The following interface change made it work:
 
@Consumes(MediaType.APPLICATION_FORM_URLENCODED)
public abstract StatusElement lockRunsForTrips(MultivaluedMap<String, String> form);

to 

public abstract StatusElement lockRunsForTrips(@FormParam("run_id") List<String> runIdStrings);

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 06:28:02 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Wed, 16 Oct 2013 06:28:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2315) Update to HAL 2.0.4.Final
In-Reply-To: <JIRA.12503225.1381919257720@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503225.1381919257720@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503225.1381919257720.469.1381919282324@jira02.app.mwc.hst.phx2.redhat.com>

Heiko Braun created WFLY-2315:
---------------------------------

             Summary: Update to HAL 2.0.4.Final
                 Key: WFLY-2315
                 URL: https://issues.jboss.org/browse/WFLY-2315
             Project: WildFly
          Issue Type: Bug
          Components: Web Console
            Reporter: Heiko Braun
            Assignee: Heiko Braun
             Fix For: 8.0.0.CR1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 06:30:01 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Wed, 16 Oct 2013 06:30:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2316) Make
 ResourceTransformationDescriptionBuilder.addChildRedirection(PathElement
 current, PathElement legacy) handle wildcard redirects.
In-Reply-To: <JIRA.12503226.1381919326725@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503226.1381919326725@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503226.1381919326725.471.1381919401929@jira02.app.mwc.hst.phx2.redhat.com>

Kabir Khan created WFLY-2316:
--------------------------------

             Summary: Make ResourceTransformationDescriptionBuilder.addChildRedirection(PathElement current, PathElement legacy) handle wildcard redirects.
                 Key: WFLY-2316
                 URL: https://issues.jboss.org/browse/WFLY-2316
             Project: WildFly
          Issue Type: Feature Request
            Reporter: Kabir Khan
            Assignee: Kabir Khan
             Fix For: 8.0.0.CR1


It works fine for current:child=one, legacy:new-child=two, so that child=one gets redirected to new-child=two.

However, it would be nice to make it work with wildcards. e.g. current:child=*, legacy:new-child=* so that child=test gets redirected to new-child=test, child=other to new-child=other etc.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 06:39:02 2013
From: jira-events at lists.jboss.org (Brett Lempereur (JIRA))
Date: Wed, 16 Oct 2013 06:39:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBRULES-3688) Provide detailed context
 information for NoClassDefFoundError: Could not initialize class
 org.drools.rule.constraint.MvelConstraint$ExecutorHolder at
 org.drools.rule.constraint.MvelConstraint.jitEvaluator(MvelConstraint.java:232)
In-Reply-To: <JIRA.12479408.1353131565000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479408.1353131565000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479408.1353131565000.482.1381919942095@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBRULES-3688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814565#comment-12814565 ] 

Brett Lempereur commented on JBRULES-3688:
------------------------------------------

Having encountered this issue (and landing at this page) recently in a project, a temporary workaround is to include Drools 5.5.0 within your bundle.  This can be achieved by including the jars and adding them to your classpath using your manifest file, or using the "maven-shade-plugin" to include the Drools classes (along with some subset of their dependencies) within your bundle.  Using either approach mitigated this bug in our deployment.
                
> Provide detailed context information for NoClassDefFoundError: Could not initialize class org.drools.rule.constraint.MvelConstraint$ExecutorHolder at org.drools.rule.constraint.MvelConstraint.jitEvaluator(MvelConstraint.java:232)
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-3688
>                 URL: https://issues.jboss.org/browse/JBRULES-3688
>             Project: JBRULES
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.5.0.Final
>         Environment: Karaf
>   Karaf version               2.3.0
>   Karaf home                  /home/ceefour/git/bippo-commerce5/karaf
>   Karaf base                  /home/ceefour/git/bippo-commerce5/karaf
>   OSGi Framework              org.apache.felix.framework - 4.0.3
> JVM
>   Java Virtual Machine        OpenJDK 64-Bit Server VM version 23.2-b09
>   Version                     1.7.0_07
>   Vendor                      Oracle Corporation
>   Uptime                      8 minutes
>   Total compile time          44.295 seconds
> Threads
>   Live threads                107
>   Daemon threads              92
>   Peak                        140
>   Total started               322
> Memory
>   Current heap size           203,385 kbytes
>   Maximum heap size           466,048 kbytes
>   Committed heap size         283,072 kbytes
>   Pending objects             0
>   Garbage collector           Name = 'PS Scavenge', Collections = 73, Time = 0.654 seconds
>   Garbage collector           Name = 'PS MarkSweep', Collections = 2, Time = 0.366 seconds
> Classes
>   Current classes loaded      15,546
>   Total classes loaded        15,547
>   Total classes unloaded      1
> Operating system
>   Name                        Linux version 3.2.0-32-generic
>   Architecture                amd64
>   Processors                  8
>            Reporter: Hendy Irawan
>            Assignee: Mark Proctor
>
> We're using Drools 5.5.0 in OSGi with: Karaf 2.3.0, Pax Wicket 1.1.1.
> We experience several issues and this is one of them. Even if a fix is not in sight, I'd appreciate if a check with more detailed information can be provided at the exception point, which will be helpful for us to diagnose and for future bug report to Drools team.
> The error is intermittent, together with #JBRULES-3687 during a single session it happens:
> 1. This bug: ~ 40%
> 2. #JBRULES-3687: ~ 50%
> 3. Success: ~ 10%
> Stack:
> {code}
> Root cause:
> java.lang.NoClassDefFoundError: Could not initialize class org.drools.rule.constraint.MvelConstraint$ExecutorHolder
>      at org.drools.rule.constraint.MvelConstraint.jitEvaluator(MvelConstraint.java:232)
>      at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:197)
>      at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:157)
>      at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:137)
>      at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:59)
>      at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:141)
>      at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:59)
>      at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:141)
>      at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:497)
>      at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:372)
>      at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235)
>      at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240)
>      at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:350)
>      at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:311)
>      at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903)
>      at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:847)
>      at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:269)
>      at id.co.bippo.booking.BookingCheckRulesImpl.processBookings(BookingCheckRulesImpl.java:177)
>      at id.co.bippo.booking.BookingCheckRulesImpl.processFacts(BookingCheckRulesImpl.java:195)
>      at id.co.bippo.booking.BookingCheckRulesImpl.check(BookingCheckRulesImpl.java:147)
>      at id.co.bippo.booking.web.ProductBookingPanel.<init>(ProductBookingPanel.java:47)
>      at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
>      at org.soluvas.web.site.compose.impl.LiveChildContributorImpl$1.create(LiveChildContributorImpl.java:187)
>      at org.soluvas.web.site.compose.ComposeUtils.compose(ComposeUtils.java:68)
>      at org.soluvas.web.bootstrap.BootstrapPage.onInitialize(BootstrapPage.java:302)
>      at org.apache.wicket.Component.fireInitialize(Component.java:933)
>      at org.apache.wicket.MarkupContainer.internalInitialize(MarkupContainer.java:960)
>      at org.apache.wicket.Page.internalPrepareForRender(Page.java:277)
>      at org.apache.wicket.Component.render(Component.java:2313)
>      at org.apache.wicket.Page.renderPage(Page.java:1035)
>      at org.apache.wicket.request.handler.render.WebPageRenderer.renderPage(WebPageRenderer.java:115)
>      at org.apache.wicket.request.handler.render.WebPageRenderer.respond(WebPageRenderer.java:237)
>      at org.apache.wicket.request.handler.RenderPageRequestHandler.respond(RenderPageRequestHandler.java:167)
>      at org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:784)
>      at org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
>      at org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:255)
>      at org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:212)
>      at org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:283)
>      at org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:188)
>      at org.apache.wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:137)
>      at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
>      at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
>      at org.ops4j.pax.wicket.internal.FilterDelegator$Chain.doFilter(FilterDelegator.java:79)
>      at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449)
>      at org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365)
>      at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
>      at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
>      at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383)
>      at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:362)
>      at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
>      at org.ops4j.pax.wicket.internal.FilterDelegator$Chain.doFilter(FilterDelegator.java:77)
>      at org.ops4j.pax.wicket.internal.FilterDelegator.doFilter(FilterDelegator.java:61)
>      at org.ops4j.pax.wicket.internal.ServletProxy$ServletInvocationHandler.invoke(ServletProxy.java:72)
>      at $Proxy80.service(Unknown Source)
>      at java.lang.reflect.Method.invoke(Method.java:601)
>      at org.ops4j.pax.web.service.internal.HttpServiceStarted$2.invoke(HttpServiceStarted.java:210)
>      at org.ops4j.pax.web.service.internal.$Proxy0.service(Unknown Source)
>      at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:652)
>      at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:447)
>      at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:70)
>      at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
>      at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:559)
>      at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:227)
>      at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1038)
>      at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:117)
>      at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:374)
>      at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:189)
>      at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:972)
>      at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
>      at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:74)
>      at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
>      at org.eclipse.jetty.server.Server.handle(Server.java:363)
>      at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:483)
>      at org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
>      at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:920)
>      at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:982)
>      at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:635)
>      at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
>      at org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
>      at org.eclipse.jetty.server.nio.BlockingChannelConnector$BlockingChannelEndPoint.run(BlockingChannelConnector.java:298)
>      at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
>      at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
>      at java.lang.Thread.run(Thread.java:722)
> Complete stack:
> java.lang.RuntimeException: Cannot create component id.co.bippo.booking.web.ProductBookingPanel for contributor id.co.bippo.product.web.pub.ProductView/addToCartRegion from id.co.bippo.booking.web [3478]
>      at org.soluvas.web.site.compose.impl.LiveChildContributorImpl$1.create(LiveChildContributorImpl.java:189)
>      at org.soluvas.web.site.compose.ComposeUtils.compose(ComposeUtils.java:68)
>      at org.soluvas.web.bootstrap.BootstrapPage.onInitialize(BootstrapPage.java:302)
>      at org.apache.wicket.Component.fireInitialize(Component.java:933)
>      at org.apache.wicket.MarkupContainer.internalInitialize(MarkupContainer.java:960)
>      at org.apache.wicket.Page.internalPrepareForRender(Page.java:277)
>      at org.apache.wicket.Component.render(Component.java:2313)
>      at org.apache.wicket.Page.renderPage(Page.java:1035)
>      at org.apache.wicket.request.handler.render.WebPageRenderer.renderPage(WebPageRenderer.java:115)
>      at org.apache.wicket.request.handler.render.WebPageRenderer.respond(WebPageRenderer.java:237)
>      at org.apache.wicket.request.handler.RenderPageRequestHandler.respond(RenderPageRequestHandler.java:167)
>      at org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:784)
>      at org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
>      at org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:255)
>      at org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:212)
>      at org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:283)
>      at org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:188)
> java.lang.reflect.InvocationTargetException
>      at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>      at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
>      at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
>      at org.soluvas.web.site.compose.impl.LiveChildContributorImpl$1.create(LiveChildContributorImpl.java:187)
>      at org.soluvas.web.site.compose.ComposeUtils.compose(ComposeUtils.java:68)
>      at org.soluvas.web.bootstrap.BootstrapPage.onInitialize(BootstrapPage.java:302)
>      at org.apache.wicket.Component.fireInitialize(Component.java:933)
>      at org.apache.wicket.MarkupContainer.internalInitialize(MarkupContainer.java:960)
>      at org.apache.wicket.Page.internalPrepareForRender(Page.java:277)
>      at org.apache.wicket.Component.render(Component.java:2313)
>      at org.apache.wicket.Page.renderPage(Page.java:1035)
>      at org.apache.wicket.request.handler.render.WebPageRenderer.renderPage(WebPageRenderer.java:115)
>      at org.apache.wicket.request.handler.render.WebPageRenderer.respond(WebPageRenderer.java:237)
>      at org.apache.wicket.request.handler.RenderPageRequestHandler.respond(RenderPageRequestHandler.java:167)
>      at org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:784)
>      at org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
>      at org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:255)
>      at org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:212)
>      at org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:283)
>      at org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:188)
> {code}
> Another stack trace, same root cause, different execution path:
> {code}
> Root cause:
> java.lang.NoClassDefFoundError: Could not initialize class org.drools.rule.constraint.MvelConstraint$ExecutorHolder
>      at org.drools.rule.constraint.MvelConstraint.jitEvaluator(MvelConstraint.java:232)
>      at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:197)
>      at org.drools.rule.constraint.MvelConstraint.isAllowedCachedLeft(MvelConstraint.java:169)
>      at org.drools.common.TripleBetaConstraints.isAllowedCachedLeft(TripleBetaConstraints.java:91)
>      at org.drools.reteoo.JoinNode.propagateFromLeft(JoinNode.java:105)
>      at org.drools.reteoo.JoinNode.assertLeftTuple(JoinNode.java:95)
>      at org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:196)
>      at org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:71)
>      at org.drools.reteoo.FromNode.checkConstraintsAndPropagate(FromNode.java:333)
>      at org.drools.reteoo.FromNode.assertLeftTuple(FromNode.java:164)
>      at org.drools.reteoo.CompositeLeftTupleSinkAdapter.doPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:232)
>      at org.drools.reteoo.CompositeLeftTupleSinkAdapter.createAndPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:116)
>      at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:154)
>      at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:59)
>      at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:141)
>      at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:59)
>      at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:141)
>      at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:59)
>      at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:141)
>      at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:497)
>      at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:372)
>      at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235)
>      at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240)
>      at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:350)
>      at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:311)
>      at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903)
>      at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:847)
>      at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:269)
>      at id.co.bippo.booking.BookingCheckRulesImpl.processBookings(BookingCheckRulesImpl.java:177)
>      at id.co.bippo.booking.BookingCheckRulesImpl.processFacts(BookingCheckRulesImpl.java:195)
>      at id.co.bippo.booking.BookingCheckRulesImpl.check(BookingCheckRulesImpl.java:147)
>      at id.co.bippo.booking.web.ProductBookingPanel.<init>(ProductBookingPanel.java:47)
>      at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
>      at org.soluvas.web.site.compose.impl.LiveChildContributorImpl$1.create(LiveChildContributorImpl.java:187)
>      at org.soluvas.web.site.compose.ComposeUtils.compose(ComposeUtils.java:68)
>      at org.soluvas.web.bootstrap.BootstrapPage.onInitialize(BootstrapPage.java:302)
>      at org.apache.wicket.Component.fireInitialize(Component.java:933)
>      at org.apache.wicket.MarkupContainer.internalInitialize(MarkupContainer.java:960)
>      at org.apache.wicket.Page.internalPrepareForRender(Page.java:277)
>      at org.apache.wicket.Component.render(Component.java:2313)
>      at org.apache.wicket.Page.renderPage(Page.java:1035)
>      at org.apache.wicket.request.handler.render.WebPageRenderer.renderPage(WebPageRenderer.java:115)
>      at org.apache.wicket.request.handler.render.WebPageRenderer.respond(WebPageRenderer.java:237)
>      at org.apache.wicket.request.handler.RenderPageRequestHandler.respond(RenderPageRequestHandler.java:167)
>      at org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:784)
>      at org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
>      at org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:255)
>      at org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:212)
>      at org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:283)
>      at org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:188)
>      at org.apache.wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:137)
>      at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
>      at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
>      at org.ops4j.pax.wicket.internal.FilterDelegator$Chain.doFilter(FilterDelegator.java:79)
>      at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449)
>      at org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365)
>      at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
>      at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
>      at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383)
>      at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:362)
>      at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
>      at org.ops4j.pax.wicket.internal.FilterDelegator$Chain.doFilter(FilterDelegator.java:77)
>      at org.ops4j.pax.wicket.internal.FilterDelegator.doFilter(FilterDelegator.java:61)
>      at org.ops4j.pax.wicket.internal.ServletProxy$ServletInvocationHandler.invoke(ServletProxy.java:72)
>      at $Proxy80.service(Unknown Source)
>      at java.lang.reflect.Method.invoke(Method.java:601)
>      at org.ops4j.pax.web.service.internal.HttpServiceStarted$2.invoke(HttpServiceStarted.java:210)
>      at org.ops4j.pax.web.service.internal.$Proxy0.service(Unknown Source)
>      at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:652)
>      at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:447)
>      at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:70)
>      at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
>      at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:559)
>      at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:227)
>      at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1038)
>      at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:117)
>      at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:374)
>      at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:189)
>      at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:972)
>      at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
>      at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:74)
>      at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
>      at org.eclipse.jetty.server.Server.handle(Server.java:363)
>      at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:483)
>      at org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
>      at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:920)
>      at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:982)
>      at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:635)
>      at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
>      at org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
>      at org.eclipse.jetty.server.nio.BlockingChannelConnector$BlockingChannelEndPoint.run(BlockingChannelConnector.java:298)
>      at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
>      at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
>      at java.lang.Thread.run(Thread.java:722)
> Complete stack:
> java.lang.RuntimeException: Cannot create component id.co.bippo.booking.web.ProductBookingPanel for contributor id.co.bippo.product.web.pub.ProductView/addToCartRegion from id.co.bippo.booking.web [3478]
>      at org.soluvas.web.site.compose.impl.LiveChildContributorImpl$1.create(LiveChildContributorImpl.java:189)
>      at org.soluvas.web.site.compose.ComposeUtils.compose(ComposeUtils.java:68)
>      at org.soluvas.web.bootstrap.BootstrapPage.onInitialize(BootstrapPage.java:302)
>      at org.apache.wicket.Component.fireInitialize(Component.java:933)
>      at org.apache.wicket.MarkupContainer.internalInitialize(MarkupContainer.java:960)
>      at org.apache.wicket.Page.internalPrepareForRender(Page.java:277)
>      at org.apache.wicket.Component.render(Component.java:2313)
>      at org.apache.wicket.Page.renderPage(Page.java:1035)
>      at org.apache.wicket.request.handler.render.WebPageRenderer.renderPage(WebPageRenderer.java:115)
>      at org.apache.wicket.request.handler.render.WebPageRenderer.respond(WebPageRenderer.java:237)
>      at org.apache.wicket.request.handler.RenderPageRequestHandler.respond(RenderPageRequestHandler.java:167)
>      at org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:784)
>      at org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
>      at org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:255)
>      at org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:212)
>      at org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:283)
>      at org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:188)
> java.lang.reflect.InvocationTargetException
>      at sun.reflect.GeneratedConstructorAccessor111.newInstance(Unknown Source)
>      at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>      at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
>      at org.soluvas.web.site.compose.impl.LiveChildContributorImpl$1.create(LiveChildContributorImpl.java:187)
>      at org.soluvas.web.site.compose.ComposeUtils.compose(ComposeUtils.java:68)
>      at org.soluvas.web.bootstrap.BootstrapPage.onInitialize(BootstrapPage.java:302)
>      at org.apache.wicket.Component.fireInitialize(Component.java:933)
>      at org.apache.wicket.MarkupContainer.internalInitialize(MarkupContainer.java:960)
>      at org.apache.wicket.Page.internalPrepareForRender(Page.java:277)
>      at org.apache.wicket.Component.render(Component.java:2313)
>      at org.apache.wicket.Page.renderPage(Page.java:1035)
>      at org.apache.wicket.request.handler.render.WebPageRenderer.renderPage(WebPageRenderer.java:115)
>      at org.apache.wicket.request.handler.render.WebPageRenderer.respond(WebPageRenderer.java:237)
>      at org.apache.wicket.request.handler.RenderPageRequestHandler.respond(RenderPageRequestHandler.java:167)
>      at org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:784)
>      at org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
>      at org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:255)
>      at org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:212)
>      at org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:283)
>      at org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:188)
> {code}
> Bundles:
> {code}
> [3016] [Active     ] [            ] [       ] [   80] id.co.bippo.booking.rs (5.0.0.SNAPSHOT)
> [3017] [Active     ] [            ] [       ] [   80] id.co.bippo.booking (5.0.0.SNAPSHOT)
> [3173] [Active     ] [            ] [Started] [   80] berbatik_booking.xml (0.0.0)
> [3192] [Active     ] [            ] [Started] [   80] berbatik_booking.rs.xml (0.0.0)
> [3295] [Active     ] [            ] [       ] [   50] org.drools.api (5.5.0.Final)
> [3296] [Active     ] [            ] [       ] [   50] org.drools.internalapi (5.5.0.Final)
> [3297] [Active     ] [            ] [       ] [   50] org.drools.core (5.5.0.Final)
> [3298] [Active     ] [            ] [       ] [   50] org.drools.compiler (5.5.0.Final)
> [3299] [Active     ] [            ] [       ] [   50] org.drools.templates (5.5.0.Final)
> [3478] [Active     ] [Created     ] [       ] [   80] id.co.bippo.booking.web (5.0.0.SNAPSHOT)
> {code}
> DRL:
> {code}
> package id.co.bippo.booking
> dialect "mvel"
> import org.slf4j.Logger;
> import org.joda.time.*;
> import id.co.bippo.booking.*;
> import id.co.bippo.booking.CheckProduct.Bookability;
> import id.co.bippo.booking.CheckProduct.Confirmability;
> import id.co.bippo.person.*;
> import id.co.bippo.product.util.ProductUtils;
> global Logger log;
> global BookingDao bookingDao;
> global ProductUtils productUtils;
> global PersonUtils personUtils;
> rule "Cek booking produk dengan qty 1, stock ada"
> activation-group "Check"
> 	when
> 		$action       : CheckProduct( $personId : personId, $productId : productId, $qty : qty == 1.0,
> 							bookability == Bookability.NEW,
> 							confirmability == Confirmability.NEW)
> 		$bookedQty    : Double() from bookingDao.findBookedQty($productId)
> 		$availableQty : Double(this - $bookedQty >= $qty) from productUtils.getQtyByProductId($productId)
> 		$countBook 	  : Long(this < 100) from bookingDao.getBookCountByPersonIdToday($personId)
> 	then
> 		log.info("{} boleh booking {} sebanyak {} (stok tersedia: {}, sudah dibooking: {})",
> 			{$personId, $productId, $qty, $availableQty, $bookedQty});
> 		modify($action) {
> 			setBookability(CheckProduct$Bookability.AVAILABLE),
> 			setConfirmability(CheckProduct$Confirmability.AVAILABLE),
> 			setMessage("Anda boleh melakukan booking untuk produk "+ $productId +", Terima Kasih")
> 		}
> end
> rule "Check booking yang melebihi batas yang telah ditentukan, batas booking 3 per 24 jam" 
> activation-group "Check"
> 	when
> 		$action 	   : CheckProduct( $personId : personId, $productId : productId, $qty : qty == 1.0,
> 							bookability == Bookability.NEW,
> 							confirmability == Confirmability.NEW)
> 		$countBook     : Long(this >= 100) from bookingDao.getBookCountByPersonIdToday($personId)
> 	then
> 		log.info("Person ID {} telah melakukan booking product sebanyak {}", {$personId, $countBook});
> 		modify($action) {
> 			setBookability(CheckProduct$Bookability.QUOTA_EXCEEDED), 
> 			setConfirmability(CheckProduct$Confirmability.QUOTA_EXCEEDED),
> 			setMessage("Sorry, Cannot book product currently, you have too many bookings today");
> 		}
> end
> rule "Check if product is already booked by himself (BookingDetail status: open/pending/waiting)."
> activation-group "Check"
> salience 15
>     when
>     	$action			: CheckProduct( $personId : personId, $productId: productId, $qty: qty == 1.0,
>     						bookability == Bookability.NEW,
> 							confirmability == Confirmability.NEW)
>     	$bookingDetail  : BookingDetail(booking.personId == $personId, productId == $productId, qty == $qty,
>     						/*status in (BookingDetail$Status.OPEN, BookingDetail$Status.PENDING_WAITING) )*/ 
>     						status == BookingDetail$Status.OPEN)
>     then
> 		log.info("{} sudah booking {} sebanyak {}, tinggal diorder",
> 			{$personId, $productId, $qty});
> 		modify($action) {
> 			setBookability(CheckProduct$Bookability.ALREADY_SELF),
> 			setConfirmability(CheckProduct$Confirmability.PLEASE_PAY_TO_ORDER),
> 			setBooker(personUtils.getPersonRefById($bookingDetail.booking.personId)),
> 			setMessage($personId + " sudah booking " + $productId " sebanyak " + $qty + ", tinggal diorder")
> 		}
> end
> rule "Check if product is already confimed by himself (BookingDetail status: pending_waiting)."
> activation-group "Check"
> salience 15
>     when
>     	$action			: CheckProduct( $personId : personId, $productId: productId, $qty: qty == 1.0,
>     						bookability == Bookability.NEW,
> 							confirmability == Confirmability.NEW)
>     	$bookingDetail  : BookingDetail(booking.personId == $personId, productId == $productId, qty == $qty,
>     						status == BookingDetail$Status.PENDING_WAITING)
>     then
> 		log.info("{} sudah booking {} sebanyak {}, tinggal diorder",
> 			{$personId, $productId, $qty});
> 		modify($action) {
> 			setBookability(CheckProduct$Bookability.ALREADY_SELF),
> 			setConfirmability(CheckProduct$Confirmability.PLEASE_PAY_TO_WAIT),
> 			setBooker(personUtils.getPersonRefById($bookingDetail.booking.personId)),
> 			setMessage($personId + " sudah booking " + $productId " sebanyak " + $qty + ", tinggal diorder")
> 		}
> end
> rule "Check: Product already booked by other, AND already confirmed by yet another."
> activation-group "Check"
> salience 20
>     when
>     	$action			: CheckProduct( $personId : personId, $productId: productId, $qty: qty == 1.0,
>     						bookability == Bookability.NEW,
> 							confirmability == Confirmability.NEW)
> 		$bookedQty      : Double(this >= 1.0) from bookingDao.findBookedQty($productId)
>     	$bookingDetail  : BookingDetail(booking.personId != $personId, productId == $productId, qty == $qty, 
>     						status == BookingDetail$Status.OPEN)
>     	$bookingDetail2 : BookingDetail(booking.personId != $personId, productId == $productId, qty == $qty, 
>     						status == BookingDetail$Status.PENDING_WAITING)
>     then
> 		log.info("{} ingin booking {} sebanyak {} tapi sudah dibooking dan diconfirm 2 orang",
> 			{$personId, $productId, $qty});
> 		modify($action) {
> 			setBookability(CheckProduct$Bookability.BOOKED_BY_OTHER),
> 			setConfirmability(CheckProduct$Confirmability.CONFIRMED_BY_OTHER),
> 			setBooker(personUtils.getPersonRefById($bookingDetail.booking.personId)),
> 			setMessage($productId + " sudah dibooking dan diconfirm 2 orang customer lain.")
> 		}
> end
> rule "Check the product, but the product was booked by other."
> activation-group "Check"
> salience 10
>     when
>     	$action			: CheckProduct( $personId : personId, $productId: productId, $qty: qty == 1.0,
>     						bookability == Bookability.NEW,
> 							confirmability == Confirmability.NEW)
> 		$bookedQty      : Double(this >= 1.0) from bookingDao.findBookedQty($productId)
>     	$bookingDetail  : BookingDetail(booking.personId != $personId, productId == $productId, qty == $qty, 
>     						status == BookingDetail$Status.OPEN)
>     then
> 		log.info("{} ingin booking {} sebanyak {} tapi sudah dibooking orang, mau confirm dan nunggu ngga?",
> 			{$personId, $productId, $qty});
> 		modify($action) {
> 			setBookability(CheckProduct$Bookability.BOOKED_BY_OTHER),
> 			setConfirmability(CheckProduct$Confirmability.MUST_CONFIRM_WAITING),
> 			setBooker(personUtils.getPersonRefById($bookingDetail.booking.personId)),
> 			setMessage($productId + " sudah dibooking customer lain, silahkan untuk confirm waiting list.")
> 		}
> end
> rule "Cek booking produk dengan qty 1, stock habis"
> activation-group "Check"
> 	when
> 		$action       : CheckProduct( $personId : personId, $productId : productId, $qty : qty == 1.0,
> 							bookability == Bookability.NEW,
> 							confirmability == Confirmability.NEW)
> 		$bookedQty    : Double() from bookingDao.findBookedQty($productId)
> 		$availableQty : Double(this - $bookedQty < $qty) from productUtils.getQtyByProductId($productId)
> 	then
> 		log.info("{} tidak bisa booking {} sebanyak {} karena stok tidak cukup. Stok sekarang: {}, sudah dibooking orang: {}",
> 			{$personId, $productId, $qty, $availableQty, $bookedQty});
> 		modify($action) {
> 			setBookability(CheckProduct$Bookability.OUT_OF_STOCK),
> 			setConfirmability(CheckProduct$Confirmability.OUT_OF_STOCK),
> 			setMessage("Maaf, produk "+ $productId + " tidak tersedia saat ini")
> 		}
> end
> rule "Check booking produk dengan qty bukan 1"
> activation-group "Check"
> 	when
> 		$action : CheckProduct( $personId : personId, $productId : productId, $qty : qty != 1.0,
> 							bookability == Bookability.NEW,
> 							confirmability == Confirmability.NEW)
> 	then
> 		log.info("{} booking {} sebanyak {}. Tidak boleh! Qty harus 1",
> 			{$personId, $productId, $qty});
> 		modify($action) {
> 			setBookability(CheckProduct$Bookability.INVALID),
> 			setConfirmability(CheckProduct$Confirmability.INVALID),
> 			setMessage("Booking qty harus 1") 
> 		}
> end
>  /*
> rule "Minta booking produk, tapi tidak ada ada stock"
> activation-group "Check"
> salience -10
> 	when
> 		$action 	   : CheckProduct( $personId : personId, $productId : productId, $qty : qty,
> 							bookability == Bookability.NEW,
> 							confirmability == Confirmability.NEW)
> 		Double(this == null) from stockSvc.getAvailableQtyByProductId($productId)
> 	then
> 		log.info("{} booking {} sebanyak {}. Maaf stock tidak terdaftar!",
> 			{$personId, $productId, $qty});
> 		modify($action) {
> 			setMessage("Stock produk " + $productId + " tidak terdaftar"),
> 			setBookability(Bookability.NO_STOCK_DATA),
> 			setConfirmability(Confirmability.NO_STOCK_DATA)
> 		}
> end
> */
> rule "Minta booking produk... tak ada kriteria lain yang matching (unhandled case)"
> activation-group "Check"
> salience -100
> 	when
> 		$action       : CheckProduct( $personId : personId, $productId : productId, $qty : qty,
> 							bookability == Bookability.NEW,
> 							confirmability == Confirmability.NEW)
> 	then
> 		log.warn("{} minta booking {} sebanyak {}, tapi tidak ada rule yang matching",
> 			{$personId, $productId, $qty});
> 		modify($action) {
> 			setMessage("Internal error: " + $personId + " check booking " + $productId +
> 				" sebanyak " + $qty + " namun tidak ada rule yang match. " +
> 				" Mohon laporkan ke customer support."),
> 			setBookability(CheckProduct$Bookability.ERROR),
> 			setConfirmability(CheckProduct$Confirmability.ERROR)
> 		}
> end
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 06:43:02 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Wed, 16 Oct 2013 06:43:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2316) Make
 ResourceTransformationDescriptionBuilder.addChildRedirection(PathElement
 current, PathElement legacy) handle wildcard redirects.
In-Reply-To: <JIRA.12503226.1381919326000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503226.1381919326000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503226.1381919326000.485.1381920182036@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-2316:
-----------------------------

    Description: 
It works fine for current:child=one, legacy:new-child=two, so that child=one gets redirected to new-child=two.

However, it would be nice to make it work with wildcards. e.g. {{current:child=\*}}, {{legacy:new-child=\*}} so that child=test gets redirected to new-child=test, child=other to new-child=other etc.


  was:
It works fine for current:child=one, legacy:new-child=two, so that child=one gets redirected to new-child=two.

However, it would be nice to make it work with wildcards. e.g. current:child=*, legacy:new-child=* so that child=test gets redirected to new-child=test, child=other to new-child=other etc.



    
> Make ResourceTransformationDescriptionBuilder.addChildRedirection(PathElement current, PathElement legacy) handle wildcard redirects.
> -------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2316
>                 URL: https://issues.jboss.org/browse/WFLY-2316
>             Project: WildFly
>          Issue Type: Feature Request
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.CR1
>
>
> It works fine for current:child=one, legacy:new-child=two, so that child=one gets redirected to new-child=two.
> However, it would be nice to make it work with wildcards. e.g. {{current:child=\*}}, {{legacy:new-child=\*}} so that child=test gets redirected to new-child=test, child=other to new-child=other etc.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 06:56:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 16 Oct 2013 06:56:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2270) Lack of model integrity
 checking regarding role mappings, standard role names and scoped role names.
In-Reply-To: <JIRA.12502541.1381314949000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502541.1381314949000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502541.1381314949000.526.1381920962034@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814571#comment-12814571 ] 

RH Bugzilla Integration commented on WFLY-2270:
-----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> changed the Status of [bug 1018738|https://bugzilla.redhat.com/show_bug.cgi?id=1018738] from ASSIGNED to POST
                
> Lack of model integrity checking regarding role mappings, standard role names and scoped role names.
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2270
>                 URL: https://issues.jboss.org/browse/WFLY-2270
>             Project: WildFly
>          Issue Type: Sub-task
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Take the following scoped role definition and assignment: -
> {code}
>             <host-scoped-roles>
>                 <role name="master-Monitior" base-role="MONITOR">
>                     <host name="master"/>
>                 </role>
>             </host-scoped-roles>
> {code}
> {code}
>  <role name="master-Monitior" include-all="true"/>
> {code}
> Removal results in the following: -
> {code}
> [domain at localhost:9990 /] ./core-service=management/access=authorization/host-scoped-role=master-Monitior:remove
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "JBAS014749: Operation handler failed: JBAS013470: Unknown role 'MASTER-MONITIOR'"},
>     "rolled-back" => true
> }
> {code}
> Server side this is reported as: -
> {code}
> [Host Controller] 11:24:57,780 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014612: Operation ("remove") failed - address: ([
> [Host Controller]     ("core-service" => "management"),
> [Host Controller]     ("access" => "authorization"),
> [Host Controller]     ("host-scoped-role" => "master-Monitior")
> [Host Controller] ]): java.lang.IllegalArgumentException: JBAS013470: Unknown role 'MASTER-MONITIOR'
> [Host Controller] 	at org.jboss.as.controller.access.rbac.DefaultPermissionFactory.getUserPermissions(DefaultPermissionFactory.java:134) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.access.rbac.DefaultPermissionFactory.getUserPermissions(DefaultPermissionFactory.java:107) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.access.permission.ManagementPermissionAuthorizer.authorize(ManagementPermissionAuthorizer.java:99) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.access.management.DelegatingConfigurableAuthorizer.authorize(DelegatingConfigurableAuthorizer.java:98) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.OperationContextImpl.getBasicAuthorizationResponse(OperationContextImpl.java:1157) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1059) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.OperationContextImpl.readResourceFromRoot(OperationContextImpl.java:542) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationResolver.getServerOperations(ServerOperationResolver.java:232)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.getServerOperations(ServerOperationsResolverHandler.java:149)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.access$000(ServerOperationsResolverHandler.java:58)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler$2.getServerOperations(ServerOperationsResolverHandler.java:113)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.HostControllerExecutionSupport$Factory$DomainOpExecutionSupport.getServerOps(HostControllerExecutionSupport.java:265)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.execute(ServerOperationsResolverHandler.java:124)
> [Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:609) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:487) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:258) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:143) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:205) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:110) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:157) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:153) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_17]
> [Host Controller] 	at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_17]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [wildfly-protocol-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [wildfly-protocol-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> [Host Controller] 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> [Host Controller] 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> {code}
> At this point I believe that role removal is actually successful, however a subsequent operation is failing as the role previously associated with the user no longer exists.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 07:19:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 16 Oct 2013 07:19:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2296) Patched state is missing the
 updated resulting version
In-Reply-To: <JIRA.12502946.1381752036000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502946.1381752036000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502946.1381752036000.550.1381922342033@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2296:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1018181

    
> Patched state is missing the updated resulting version
> ------------------------------------------------------
>
>                 Key: WFLY-2296
>                 URL: https://issues.jboss.org/browse/WFLY-2296
>             Project: WildFly
>          Issue Type: Bug
>          Components: Patching
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Emanuel Muckenhuber
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 07:45:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 16 Oct 2013 07:45:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2087) Administrator should be
 prevented from modifying super user and auditor roles.
In-Reply-To: <JIRA.12500788.1379348381000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500788.1379348381000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500788.1379348381000.603.1381923902623@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814579#comment-12814579 ] 

RH Bugzilla Integration commented on WFLY-2087:
-----------------------------------------------

Vladimir Dosoudil <dosoudil at redhat.com> made a comment on [bug 1012579|https://bugzilla.redhat.com/show_bug.cgi?id=1012579]

Merged in
 * https://github.com/jbossas/jboss-eap/commit/ea931ed
 * https://github.com/jbossas/jboss-eap/commit/3104bc7
Included in EAP 6.2.0 ER 4.
                
> Administrator should be prevented from modifying super user and auditor roles.
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-2087
>                 URL: https://issues.jboss.org/browse/WFLY-2087
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>
> These roles have maximum privileges in their area, i.e. super user can do everything and auditor can stop changes to the server being logged.
> The administrator role should be prevented from modifying these two roles.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 07:45:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 16 Oct 2013 07:45:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2087) Administrator should be
 prevented from modifying super user and auditor roles.
In-Reply-To: <JIRA.12500788.1379348381000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500788.1379348381000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500788.1379348381000.607.1381923902859@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814580#comment-12814580 ] 

RH Bugzilla Integration commented on WFLY-2087:
-----------------------------------------------

Vladimir Dosoudil <dosoudil at redhat.com> changed the Status of [bug 1012579|https://bugzilla.redhat.com/show_bug.cgi?id=1012579] from MODIFIED to ON_QA
                
> Administrator should be prevented from modifying super user and auditor roles.
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-2087
>                 URL: https://issues.jboss.org/browse/WFLY-2087
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>
> These roles have maximum privileges in their area, i.e. super user can do everything and auditor can stop changes to the server being logged.
> The administrator role should be prevented from modifying these two roles.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 07:49:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 16 Oct 2013 07:49:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1716) The UDP receiver thread
 parsing messages causes performance regression
In-Reply-To: <JIRA.12503100.1381850347000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503100.1381850347000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503100.1381850347000.611.1381924142055@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814581#comment-12814581 ] 

Bela Ban commented on JGRP-1716:
--------------------------------

* Between which versions did the performance go down by 10% ?
** 3.2 and 3.4 ?
** 3.3 and 3.4 ?
** I assume the latter, as you would probably have noticed a regression between 3.2 and 3.3, right ?
* Looking at the attached chart, I *don't* actually see a perf degradation !
** 3.4-udp-bundle-getall: this is the same as in 3.3 for reads and writes
** 3.4-udp-bundle-getfirst: same as in 3.3 for reads and writes
** 3.4-udp-dontbundle-getall: same as in 3.3, a bit lower than in 3.2 for writes. Ditto for reads. So the regression is only *small* (do you have absolute numbers) and between 3.2 and 3.3, not between 3.3 and 3.4
** 3.4-udp-dontbundle-getfirst: same in 3.4 and 3.3, a bit lower than 3.2 for writes, same for reads


                
> The UDP receiver thread parsing messages causes performance regression
> ----------------------------------------------------------------------
>
>                 Key: JGRP-1716
>                 URL: https://issues.jboss.org/browse/JGRP-1716
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Dan Berindei
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>         Attachments: benchmark-jgroups.xml, jgroups-udp.pdf, jgroups-udp.xml
>
>
> Comparing JGroups 3.2/3.3/3.4 performance with Radargun, the throughput went down by ~10%. (See the attached chart. "getall" means the get requests are sent to 2 nodes, "getfirst" means they are sent to only 1 node.)
> Erik Salter profiled his application and noticed that the message parsing in the UDP receiver thread seemed to slow things down. He wrote a patch that brought his throughput back to 3.2 levels: https://github.com/an1310/JGroups/compare/t_perfhack
> The UDP receiver thread may not tell the whole story, however: in the Radargun tests, performance with his patch was even lower.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 07:51:02 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Wed, 16 Oct 2013 07:51:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2317) Trying to remove a server
 group as a server-group-scoped role leaks informations
In-Reply-To: <JIRA.12503235.1381924172769@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503235.1381924172769@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503235.1381924172769.626.1381924262421@jira02.app.mwc.hst.phx2.redhat.com>

Ladislav Thon created WFLY-2317:
-----------------------------------

             Summary: Trying to remove a server group as a server-group-scoped role leaks informations
                 Key: WFLY-2317
                 URL: https://issues.jboss.org/browse/WFLY-2317
             Project: WildFly
          Issue Type: Bug
          Components: Domain Management
            Reporter: Ladislav Thon
            Assignee: Brian Stansberry


When writing a small test case for WFLY-2190, I stumbled upon a problem: trying to remove an existing server group by a server-group-scoped user that does NOT have permissions to that server group leaks information. On a freshly built WildFly with added {{admin}} user into {{domain/configuration/mgmt-users.properties}}, it can be reproduced like this:

{code}
[1] ./bin/domain.sh
[2] ./bin/jboss-cli.sh -c
    /core-service=management/access=authorization/server-group-scoped-role=NewRole:add(base-role=administrator, server-groups=[main-server-group])
    /core-service=management/access=authorization/role-mapping=NewRole:add
    /core-service=management/access=authorization/role-mapping=NewRole/include=user-admin:add(name=admin, type=user)
    /core-service=management/access=authorization:write-attribute(name=provider, value=rbac)
    exit
[1] ^C
    ./bin/domain.sh
[2] ./bin/jboss-cli.sh -c --user=admin --password=XXX
    /server-group=other-server-group:read-resource
    /server-group=other-server-group:remove
{code}

What does that mean? The {{NewRole}} is scoped to the {{main-server-group}} server group and can't see {{other-server-group}}. When doing {{/server-group=other-server-group:read-resource}}, this is correctly enforced and the output looks like this:

{code}
{
    "outcome" => "failed",
    "failure-description" => "JBAS014807: Management resource '[(\"server-group\" => \"other-server-group\")]' not found",
    "rolled-back" => true
}
{code}

However, trying to do {{/server-group=other-server-group:remove}}, which is only a different operation _on the same resource_, I get a different error message:

{code}
{
    "outcome" => "failed",
    "failure-description" => {"domain-failure-description" => "JBAS013456: Unauthorized to execute operation 'remove' for resource '[(\"server-group\" => \"other-server-group\")]' -- \"JBAS013475: Permission denied\""},
    "rolled-back" => true
}
{code}

I expect the error message to be completely the same as in previous case, not leaking any information that the {{other-server-group}} actually exists.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 07:51:02 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Wed, 16 Oct 2013 07:51:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2317) Trying to remove a server
 group as a server-group-scoped role leaks informations
In-Reply-To: <JIRA.12503235.1381924172000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503235.1381924172000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503235.1381924172000.629.1381924262671@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ladislav Thon updated WFLY-2317:
--------------------------------

        Parent: WFLY-490
    Issue Type: Sub-task  (was: Bug)

    
> Trying to remove a server group as a server-group-scoped role leaks informations
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-2317
>                 URL: https://issues.jboss.org/browse/WFLY-2317
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Brian Stansberry
>
> When writing a small test case for WFLY-2190, I stumbled upon a problem: trying to remove an existing server group by a server-group-scoped user that does NOT have permissions to that server group leaks information. On a freshly built WildFly with added {{admin}} user into {{domain/configuration/mgmt-users.properties}}, it can be reproduced like this:
> {code}
> [1] ./bin/domain.sh
> [2] ./bin/jboss-cli.sh -c
>     /core-service=management/access=authorization/server-group-scoped-role=NewRole:add(base-role=administrator, server-groups=[main-server-group])
>     /core-service=management/access=authorization/role-mapping=NewRole:add
>     /core-service=management/access=authorization/role-mapping=NewRole/include=user-admin:add(name=admin, type=user)
>     /core-service=management/access=authorization:write-attribute(name=provider, value=rbac)
>     exit
> [1] ^C
>     ./bin/domain.sh
> [2] ./bin/jboss-cli.sh -c --user=admin --password=XXX
>     /server-group=other-server-group:read-resource
>     /server-group=other-server-group:remove
> {code}
> What does that mean? The {{NewRole}} is scoped to the {{main-server-group}} server group and can't see {{other-server-group}}. When doing {{/server-group=other-server-group:read-resource}}, this is correctly enforced and the output looks like this:
> {code}
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014807: Management resource '[(\"server-group\" => \"other-server-group\")]' not found",
>     "rolled-back" => true
> }
> {code}
> However, trying to do {{/server-group=other-server-group:remove}}, which is only a different operation _on the same resource_, I get a different error message:
> {code}
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "JBAS013456: Unauthorized to execute operation 'remove' for resource '[(\"server-group\" => \"other-server-group\")]' -- \"JBAS013475: Permission denied\""},
>     "rolled-back" => true
> }
> {code}
> I expect the error message to be completely the same as in previous case, not leaking any information that the {{other-server-group}} actually exists.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 07:51:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 16 Oct 2013 07:51:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1716) The UDP receiver thread
 parsing messages causes performance regression
In-Reply-To: <JIRA.12503100.1381850347000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503100.1381850347000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503100.1381850347000.634.1381924262943@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814588#comment-12814588 ] 

Bela Ban commented on JGRP-1716:
--------------------------------

Note that DONT_BUNDLE should not be used in 3.4 anymore, and Infinispan still uses it despite my recommendations ! Could be well possible that - in combination with the new bundler - DONT_BUNDLE is actually detrimental to perf. I'll run radagun myself tohopefully find out why...
                
> The UDP receiver thread parsing messages causes performance regression
> ----------------------------------------------------------------------
>
>                 Key: JGRP-1716
>                 URL: https://issues.jboss.org/browse/JGRP-1716
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Dan Berindei
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>         Attachments: benchmark-jgroups.xml, jgroups-udp.pdf, jgroups-udp.xml
>
>
> Comparing JGroups 3.2/3.3/3.4 performance with Radargun, the throughput went down by ~10%. (See the attached chart. "getall" means the get requests are sent to 2 nodes, "getfirst" means they are sent to only 1 node.)
> Erik Salter profiled his application and noticed that the message parsing in the UDP receiver thread seemed to slow things down. He wrote a patch that brought his throughput back to 3.2 levels: https://github.com/an1310/JGroups/compare/t_perfhack
> The UDP receiver thread may not tell the whole story, however: in the Radargun tests, performance with his patch was even lower.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 07:51:03 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Wed, 16 Oct 2013 07:51:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2317) Trying to remove a server
 group as a server-group-scoped role leaks informations
In-Reply-To: <JIRA.12503235.1381924172000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503235.1381924172000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503235.1381924172000.637.1381924263121@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ladislav Thon updated WFLY-2317:
--------------------------------

    Labels: rbac-filed-by-qa  (was: )

    
> Trying to remove a server group as a server-group-scoped role leaks informations
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-2317
>                 URL: https://issues.jboss.org/browse/WFLY-2317
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Brian Stansberry
>              Labels: rbac-filed-by-qa
>
> When writing a small test case for WFLY-2190, I stumbled upon a problem: trying to remove an existing server group by a server-group-scoped user that does NOT have permissions to that server group leaks information. On a freshly built WildFly with added {{admin}} user into {{domain/configuration/mgmt-users.properties}}, it can be reproduced like this:
> {code}
> [1] ./bin/domain.sh
> [2] ./bin/jboss-cli.sh -c
>     /core-service=management/access=authorization/server-group-scoped-role=NewRole:add(base-role=administrator, server-groups=[main-server-group])
>     /core-service=management/access=authorization/role-mapping=NewRole:add
>     /core-service=management/access=authorization/role-mapping=NewRole/include=user-admin:add(name=admin, type=user)
>     /core-service=management/access=authorization:write-attribute(name=provider, value=rbac)
>     exit
> [1] ^C
>     ./bin/domain.sh
> [2] ./bin/jboss-cli.sh -c --user=admin --password=XXX
>     /server-group=other-server-group:read-resource
>     /server-group=other-server-group:remove
> {code}
> What does that mean? The {{NewRole}} is scoped to the {{main-server-group}} server group and can't see {{other-server-group}}. When doing {{/server-group=other-server-group:read-resource}}, this is correctly enforced and the output looks like this:
> {code}
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014807: Management resource '[(\"server-group\" => \"other-server-group\")]' not found",
>     "rolled-back" => true
> }
> {code}
> However, trying to do {{/server-group=other-server-group:remove}}, which is only a different operation _on the same resource_, I get a different error message:
> {code}
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "JBAS013456: Unauthorized to execute operation 'remove' for resource '[(\"server-group\" => \"other-server-group\")]' -- \"JBAS013475: Permission denied\""},
>     "rolled-back" => true
> }
> {code}
> I expect the error message to be completely the same as in previous case, not leaking any information that the {{other-server-group}} actually exists.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 07:54:01 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Wed, 16 Oct 2013 07:54:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2318) Access control exceptions
 missing for scoped roles
In-Reply-To: <JIRA.12503236.1381924408219@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503236.1381924408219@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503236.1381924408219.639.1381924441887@jira02.app.mwc.hst.phx2.redhat.com>

Heiko Braun created WFLY-2318:
---------------------------------

             Summary: Access control exceptions missing for scoped roles
                 Key: WFLY-2318
                 URL: https://issues.jboss.org/browse/WFLY-2318
             Project: WildFly
          Issue Type: Bug
          Components: Domain Management
            Reporter: Heiko Braun
            Assignee: Brian Stansberry


The following setup: user with two scoped roles assigned. maintainer for "main-servers", monitor for "other-servers". Requesting the access control meta data for the server group wildcard ]does not include "exceptions". 

Expected result: the access control meta data response contains an "exception" for each server group (main-server-group & other-server-group)

{code}

[domain at localhost:9999 /] ./server-group=*:read-resource-description(access-control=trim-descriptions, operations=true){roles=main-servers, other-servers}
{
    "outcome" => "success",
    "result" => [{
        "address" => [("server-group" => "*")],
        "outcome" => "success",
        "result" => {
            "description" => undefined,
            "attributes" => undefined,
            "operations" => undefined,
            "children" => {
                "deployment" => {"model-description" => undefined},
                "system-property" => {"model-description" => undefined},
                "jvm" => {"model-description" => undefined},
                "deployment-overlay" => {"model-description" => undefined}
            },
            "access-control" => {
                "default" => {
                    "read" => true,
                    "write" => true,
                    "attributes" => {
                        "socket-binding-port-offset" => {
                            "read" => true,
                            "write" => true
                        },
                        "management-subsystem-endpoint" => {
                            "read" => true,
                            "write" => false
                        },
                        "socket-binding-group" => {
                            "read" => true,
                            "write" => true
                        },
                        "profile" => {
                            "read" => true,
                            "write" => true
                        }
                    },
                    "operations" => {
                        "read-children-names" => {"execute" => true},
                        "read-operation-description" => {"execute" => true},
                        "remove" => {"execute" => true},
                        "read-resource-description" => {"execute" => true},
                        "stop-servers" => {"execute" => true},
                        "read-resource" => {"execute" => true},
                        "add" => {"execute" => true},
                        "read-attribute" => {"execute" => true},
                        "whoami" => {"execute" => true},
                        "read-children-types" => {"execute" => true},
                        "read-operation-names" => {"execute" => true},
                        "undefine-attribute" => {"execute" => true},
                        "start-servers" => {"execute" => true},
                        "read-children-resources" => {"execute" => true},
                        "restart-servers" => {"execute" => true},
                        "replace-deployment" => {"execute" => true},
                        "write-attribute" => {"execute" => true}
                    }
                },
                "exceptions" => {}
            }
        }
    }]
}

{code}


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 07:56:02 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Wed, 16 Oct 2013 07:56:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2317) Trying to remove a server
 group as a server-group-scoped role leaks informations
In-Reply-To: <JIRA.12503235.1381924172000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503235.1381924172000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503235.1381924172000.644.1381924562024@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814589#comment-12814589 ] 

Ladislav Thon commented on WFLY-2317:
-------------------------------------

The test case for WFLY-2190 I mentioned, that also reproduces this bug, is at https://github.com/Ladicek/wildfly/tree/rbac (the commit https://github.com/Ladicek/wildfly/commit/c4a449e8567e5781f621983080a1352fed537077)
                
> Trying to remove a server group as a server-group-scoped role leaks informations
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-2317
>                 URL: https://issues.jboss.org/browse/WFLY-2317
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Brian Stansberry
>              Labels: rbac-filed-by-qa
>
> When writing a small test case for WFLY-2190, I stumbled upon a problem: trying to remove an existing server group by a server-group-scoped user that does NOT have permissions to that server group leaks information. On a freshly built WildFly with added {{admin}} user into {{domain/configuration/mgmt-users.properties}}, it can be reproduced like this:
> {code}
> [1] ./bin/domain.sh
> [2] ./bin/jboss-cli.sh -c
>     /core-service=management/access=authorization/server-group-scoped-role=NewRole:add(base-role=administrator, server-groups=[main-server-group])
>     /core-service=management/access=authorization/role-mapping=NewRole:add
>     /core-service=management/access=authorization/role-mapping=NewRole/include=user-admin:add(name=admin, type=user)
>     /core-service=management/access=authorization:write-attribute(name=provider, value=rbac)
>     exit
> [1] ^C
>     ./bin/domain.sh
> [2] ./bin/jboss-cli.sh -c --user=admin --password=XXX
>     /server-group=other-server-group:read-resource
>     /server-group=other-server-group:remove
> {code}
> What does that mean? The {{NewRole}} is scoped to the {{main-server-group}} server group and can't see {{other-server-group}}. When doing {{/server-group=other-server-group:read-resource}}, this is correctly enforced and the output looks like this:
> {code}
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014807: Management resource '[(\"server-group\" => \"other-server-group\")]' not found",
>     "rolled-back" => true
> }
> {code}
> However, trying to do {{/server-group=other-server-group:remove}}, which is only a different operation _on the same resource_, I get a different error message:
> {code}
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "JBAS013456: Unauthorized to execute operation 'remove' for resource '[(\"server-group\" => \"other-server-group\")]' -- \"JBAS013475: Permission denied\""},
>     "rolled-back" => true
> }
> {code}
> I expect the error message to be completely the same as in previous case, not leaking any information that the {{other-server-group}} actually exists.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 07:56:02 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Wed, 16 Oct 2013 07:56:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2317) Trying to remove a server
 group as a server-group-scoped role leaks information
In-Reply-To: <JIRA.12503235.1381924172000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503235.1381924172000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503235.1381924172000.647.1381924562258@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ladislav Thon updated WFLY-2317:
--------------------------------

    Summary: Trying to remove a server group as a server-group-scoped role leaks information  (was: Trying to remove a server group as a server-group-scoped role leaks informations)

    
> Trying to remove a server group as a server-group-scoped role leaks information
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-2317
>                 URL: https://issues.jboss.org/browse/WFLY-2317
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Brian Stansberry
>              Labels: rbac-filed-by-qa
>
> When writing a small test case for WFLY-2190, I stumbled upon a problem: trying to remove an existing server group by a server-group-scoped user that does NOT have permissions to that server group leaks information. On a freshly built WildFly with added {{admin}} user into {{domain/configuration/mgmt-users.properties}}, it can be reproduced like this:
> {code}
> [1] ./bin/domain.sh
> [2] ./bin/jboss-cli.sh -c
>     /core-service=management/access=authorization/server-group-scoped-role=NewRole:add(base-role=administrator, server-groups=[main-server-group])
>     /core-service=management/access=authorization/role-mapping=NewRole:add
>     /core-service=management/access=authorization/role-mapping=NewRole/include=user-admin:add(name=admin, type=user)
>     /core-service=management/access=authorization:write-attribute(name=provider, value=rbac)
>     exit
> [1] ^C
>     ./bin/domain.sh
> [2] ./bin/jboss-cli.sh -c --user=admin --password=XXX
>     /server-group=other-server-group:read-resource
>     /server-group=other-server-group:remove
> {code}
> What does that mean? The {{NewRole}} is scoped to the {{main-server-group}} server group and can't see {{other-server-group}}. When doing {{/server-group=other-server-group:read-resource}}, this is correctly enforced and the output looks like this:
> {code}
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014807: Management resource '[(\"server-group\" => \"other-server-group\")]' not found",
>     "rolled-back" => true
> }
> {code}
> However, trying to do {{/server-group=other-server-group:remove}}, which is only a different operation _on the same resource_, I get a different error message:
> {code}
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "JBAS013456: Unauthorized to execute operation 'remove' for resource '[(\"server-group\" => \"other-server-group\")]' -- \"JBAS013475: Permission denied\""},
>     "rolled-back" => true
> }
> {code}
> I expect the error message to be completely the same as in previous case, not leaking any information that the {{other-server-group}} actually exists.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 08:05:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 16 Oct 2013 08:05:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2317) Trying to remove a server
 group as a server-group-scoped role leaks information
In-Reply-To: <JIRA.12503235.1381924172000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503235.1381924172000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503235.1381924172000.659.1381925102243@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2317:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1019784

    
> Trying to remove a server group as a server-group-scoped role leaks information
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-2317
>                 URL: https://issues.jboss.org/browse/WFLY-2317
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Brian Stansberry
>              Labels: rbac-filed-by-qa
>
> When writing a small test case for WFLY-2190, I stumbled upon a problem: trying to remove an existing server group by a server-group-scoped user that does NOT have permissions to that server group leaks information. On a freshly built WildFly with added {{admin}} user into {{domain/configuration/mgmt-users.properties}}, it can be reproduced like this:
> {code}
> [1] ./bin/domain.sh
> [2] ./bin/jboss-cli.sh -c
>     /core-service=management/access=authorization/server-group-scoped-role=NewRole:add(base-role=administrator, server-groups=[main-server-group])
>     /core-service=management/access=authorization/role-mapping=NewRole:add
>     /core-service=management/access=authorization/role-mapping=NewRole/include=user-admin:add(name=admin, type=user)
>     /core-service=management/access=authorization:write-attribute(name=provider, value=rbac)
>     exit
> [1] ^C
>     ./bin/domain.sh
> [2] ./bin/jboss-cli.sh -c --user=admin --password=XXX
>     /server-group=other-server-group:read-resource
>     /server-group=other-server-group:remove
> {code}
> What does that mean? The {{NewRole}} is scoped to the {{main-server-group}} server group and can't see {{other-server-group}}. When doing {{/server-group=other-server-group:read-resource}}, this is correctly enforced and the output looks like this:
> {code}
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014807: Management resource '[(\"server-group\" => \"other-server-group\")]' not found",
>     "rolled-back" => true
> }
> {code}
> However, trying to do {{/server-group=other-server-group:remove}}, which is only a different operation _on the same resource_, I get a different error message:
> {code}
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "JBAS013456: Unauthorized to execute operation 'remove' for resource '[(\"server-group\" => \"other-server-group\")]' -- \"JBAS013475: Permission denied\""},
>     "rolled-back" => true
> }
> {code}
> I expect the error message to be completely the same as in previous case, not leaking any information that the {{other-server-group}} actually exists.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 08:05:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 16 Oct 2013 08:05:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2317) Trying to remove a server
 group as a server-group-scoped role leaks information
In-Reply-To: <JIRA.12503235.1381924172000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503235.1381924172000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503235.1381924172000.662.1381925102668@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814592#comment-12814592 ] 

RH Bugzilla Integration commented on WFLY-2317:
-----------------------------------------------

Ladislav Thon <lthon at redhat.com> made a comment on [bug 1019784|https://bugzilla.redhat.com/show_bug.cgi?id=1019784]

This can't yet be reproduced on any EAP 6.2.0.ERx release, as it depends on a relatively new upstream commit. That's also why I'm only including a short description.

If a user in a server-group-scoped role tries to :remove a server-group that she has no permissions to, she gets a bad error message. Instead of "not found", the error message says "permission denied", effectively leaking the information that the server group exists.

Again, this can't be reproduced on any ERx release; in fact, on the last ERx release, which at this time is ER5, this works perfectly fine.
                
> Trying to remove a server group as a server-group-scoped role leaks information
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-2317
>                 URL: https://issues.jboss.org/browse/WFLY-2317
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Brian Stansberry
>              Labels: rbac-filed-by-qa
>
> When writing a small test case for WFLY-2190, I stumbled upon a problem: trying to remove an existing server group by a server-group-scoped user that does NOT have permissions to that server group leaks information. On a freshly built WildFly with added {{admin}} user into {{domain/configuration/mgmt-users.properties}}, it can be reproduced like this:
> {code}
> [1] ./bin/domain.sh
> [2] ./bin/jboss-cli.sh -c
>     /core-service=management/access=authorization/server-group-scoped-role=NewRole:add(base-role=administrator, server-groups=[main-server-group])
>     /core-service=management/access=authorization/role-mapping=NewRole:add
>     /core-service=management/access=authorization/role-mapping=NewRole/include=user-admin:add(name=admin, type=user)
>     /core-service=management/access=authorization:write-attribute(name=provider, value=rbac)
>     exit
> [1] ^C
>     ./bin/domain.sh
> [2] ./bin/jboss-cli.sh -c --user=admin --password=XXX
>     /server-group=other-server-group:read-resource
>     /server-group=other-server-group:remove
> {code}
> What does that mean? The {{NewRole}} is scoped to the {{main-server-group}} server group and can't see {{other-server-group}}. When doing {{/server-group=other-server-group:read-resource}}, this is correctly enforced and the output looks like this:
> {code}
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014807: Management resource '[(\"server-group\" => \"other-server-group\")]' not found",
>     "rolled-back" => true
> }
> {code}
> However, trying to do {{/server-group=other-server-group:remove}}, which is only a different operation _on the same resource_, I get a different error message:
> {code}
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "JBAS013456: Unauthorized to execute operation 'remove' for resource '[(\"server-group\" => \"other-server-group\")]' -- \"JBAS013475: Permission denied\""},
>     "rolled-back" => true
> }
> {code}
> I expect the error message to be completely the same as in previous case, not leaking any information that the {{other-server-group}} actually exists.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 08:11:02 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Wed, 16 Oct 2013 08:11:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2317) Trying to remove a server
 group as a server-group-scoped role leaks information
In-Reply-To: <JIRA.12503235.1381924172000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503235.1381924172000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503235.1381924172000.674.1381925462146@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814594#comment-12814594 ] 

Ladislav Thon commented on WFLY-2317:
-------------------------------------

I believe that this commit might be the cause: https://github.com/wildfly/wildfly/commit/6e35f084deeeb1df3c555bcdda121b7cd157cea2 At least it is the reason why I wrote that test case.
                
> Trying to remove a server group as a server-group-scoped role leaks information
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-2317
>                 URL: https://issues.jboss.org/browse/WFLY-2317
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Brian Stansberry
>              Labels: rbac-filed-by-qa
>
> When writing a small test case for WFLY-2190, I stumbled upon a problem: trying to remove an existing server group by a server-group-scoped user that does NOT have permissions to that server group leaks information. On a freshly built WildFly with added {{admin}} user into {{domain/configuration/mgmt-users.properties}}, it can be reproduced like this:
> {code}
> [1] ./bin/domain.sh
> [2] ./bin/jboss-cli.sh -c
>     /core-service=management/access=authorization/server-group-scoped-role=NewRole:add(base-role=administrator, server-groups=[main-server-group])
>     /core-service=management/access=authorization/role-mapping=NewRole:add
>     /core-service=management/access=authorization/role-mapping=NewRole/include=user-admin:add(name=admin, type=user)
>     /core-service=management/access=authorization:write-attribute(name=provider, value=rbac)
>     exit
> [1] ^C
>     ./bin/domain.sh
> [2] ./bin/jboss-cli.sh -c --user=admin --password=XXX
>     /server-group=other-server-group:read-resource
>     /server-group=other-server-group:remove
> {code}
> What does that mean? The {{NewRole}} is scoped to the {{main-server-group}} server group and can't see {{other-server-group}}. When doing {{/server-group=other-server-group:read-resource}}, this is correctly enforced and the output looks like this:
> {code}
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014807: Management resource '[(\"server-group\" => \"other-server-group\")]' not found",
>     "rolled-back" => true
> }
> {code}
> However, trying to do {{/server-group=other-server-group:remove}}, which is only a different operation _on the same resource_, I get a different error message:
> {code}
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "JBAS013456: Unauthorized to execute operation 'remove' for resource '[(\"server-group\" => \"other-server-group\")]' -- \"JBAS013475: Permission denied\""},
>     "rolled-back" => true
> }
> {code}
> I expect the error message to be completely the same as in previous case, not leaking any information that the {{other-server-group}} actually exists.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 08:25:02 2013
From: jira-events at lists.jboss.org (Radim Vansa (JIRA))
Date: Wed, 16 Oct 2013 08:25:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1716) Regression between 3.2.x and
 3.3.x/3.4.x in Infinispan read simulation
In-Reply-To: <JIRA.12503100.1381850347000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503100.1381850347000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503100.1381850347000.696.1381926302026@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radim Vansa updated JGRP-1716:
------------------------------

              Summary: Regression between 3.2.x and 3.3.x/3.4.x in Infinispan read simulation  (was: The UDP receiver thread parsing messages causes performance regression)
          Description: 
Comparing JGroups 3.2/3.3/3.4 performance with Radargun, the throughput of reads in scenario simulating Infinispan went down by ~10%. See the attached chart.

* getall: the get request is sent to single node (randomly picked owner)
* getfirst: the get requests are sent to 2 nodes with ResponseMode.GET_FIRST - the second response is discarded.

.h5 Suspects:
Erik Salter profiled his application and noticed that the message parsing in the UDP receiver thread seemed to slow things down. He wrote a patch that brought his throughput back to 3.2 levels: https://github.com/an1310/JGroups/compare/t_perfhack

The UDP receiver thread may not tell the whole story, however: in the Radargun tests, performance with his patch was even lower.

  was:
Comparing JGroups 3.2/3.3/3.4 performance with Radargun, the throughput went down by ~10%. (See the attached chart. "getall" means the get requests are sent to 2 nodes, "getfirst" means they are sent to only 1 node.)

Erik Salter profiled his application and noticed that the message parsing in the UDP receiver thread seemed to slow things down. He wrote a patch that brought his throughput back to 3.2 levels: https://github.com/an1310/JGroups/compare/t_perfhack

The UDP receiver thread may not tell the whole story, however: in the Radargun tests, performance with his patch was even lower.

    Affects Version/s: 3.3

    
> Regression between 3.2.x and 3.3.x/3.4.x in Infinispan read simulation
> ----------------------------------------------------------------------
>
>                 Key: JGRP-1716
>                 URL: https://issues.jboss.org/browse/JGRP-1716
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.3, 3.4
>            Reporter: Dan Berindei
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>         Attachments: benchmark-jgroups.xml, jgroups-udp.pdf, jgroups-udp.xml
>
>
> Comparing JGroups 3.2/3.3/3.4 performance with Radargun, the throughput of reads in scenario simulating Infinispan went down by ~10%. See the attached chart.
> * getall: the get request is sent to single node (randomly picked owner)
> * getfirst: the get requests are sent to 2 nodes with ResponseMode.GET_FIRST - the second response is discarded.
> .h5 Suspects:
> Erik Salter profiled his application and noticed that the message parsing in the UDP receiver thread seemed to slow things down. He wrote a patch that brought his throughput back to 3.2 levels: https://github.com/an1310/JGroups/compare/t_perfhack
> The UDP receiver thread may not tell the whole story, however: in the Radargun tests, performance with his patch was even lower.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 08:25:02 2013
From: jira-events at lists.jboss.org (Dan Berindei (JIRA))
Date: Wed, 16 Oct 2013 08:25:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1716) Regression between 3.2.x and
 3.3.x/3.4.x in Infinispan read simulation
In-Reply-To: <JIRA.12503100.1381850347000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503100.1381850347000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503100.1381850347000.698.1381926302138@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814600#comment-12814600 ] 

Dan Berindei commented on JGRP-1716:
------------------------------------

[~belaban] The performance did go down between 3.2 and 3.3, but because we didn't have a product release based on 3.3 it wend unnoticed. And DONT_BUNDLE seems to improve perf in all our tests...
                
> Regression between 3.2.x and 3.3.x/3.4.x in Infinispan read simulation
> ----------------------------------------------------------------------
>
>                 Key: JGRP-1716
>                 URL: https://issues.jboss.org/browse/JGRP-1716
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.3, 3.4
>            Reporter: Dan Berindei
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>         Attachments: benchmark-jgroups.xml, jgroups-udp.pdf, jgroups-udp.xml
>
>
> Comparing JGroups 3.2/3.3/3.4 performance with Radargun, the throughput of reads in scenario simulating Infinispan went down by ~10%. See the attached chart.
> * getall: the get request is sent to single node (randomly picked owner)
> * getfirst: the get requests are sent to 2 nodes with ResponseMode.GET_FIRST - the second response is discarded.
> .h5 Suspects:
> Erik Salter profiled his application and noticed that the message parsing in the UDP receiver thread seemed to slow things down. He wrote a patch that brought his throughput back to 3.2 levels: https://github.com/an1310/JGroups/compare/t_perfhack
> The UDP receiver thread may not tell the whole story, however: in the Radargun tests, performance with his patch was even lower.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 08:27:02 2013
From: jira-events at lists.jboss.org (Radim Vansa (JIRA))
Date: Wed, 16 Oct 2013 08:27:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1717) Bundling reduces performance
 in scenario mimicking Inifinispan
In-Reply-To: <JIRA.12503239.1381926401477@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503239.1381926401477@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503239.1381926401477.711.1381926422348@jira02.app.mwc.hst.phx2.redhat.com>

Radim Vansa created JGRP-1717:
---------------------------------

             Summary: Bundling reduces performance in scenario mimicking Inifinispan
                 Key: JGRP-1717
                 URL: https://issues.jboss.org/browse/JGRP-1717
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 3.3
            Reporter: Radim Vansa
            Assignee: Bela Ban


In Radargun benchmark of JGroups mimicking the behaviour of Infinispan we can see that performance with bundling on actually reduces the performance.

See attached configurations and results.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 08:29:02 2013
From: jira-events at lists.jboss.org (Radim Vansa (JIRA))
Date: Wed, 16 Oct 2013 08:29:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1717) Bundling reduces performance
 in scenario mimicking Inifinispan
In-Reply-To: <JIRA.12503239.1381926401000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503239.1381926401000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503239.1381926401000.719.1381926542314@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radim Vansa updated JGRP-1717:
------------------------------

    Attachment: jgroups-udp.xml
                benchmark-jgroups.xml
                jgroups-udp.pdf

    
> Bundling reduces performance in scenario mimicking Inifinispan
> --------------------------------------------------------------
>
>                 Key: JGRP-1717
>                 URL: https://issues.jboss.org/browse/JGRP-1717
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.3
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>         Attachments: benchmark-jgroups.xml, jgroups-udp.pdf, jgroups-udp.xml
>
>
> In Radargun benchmark of JGroups mimicking the behaviour of Infinispan we can see that performance with bundling on actually reduces the performance.
> See attached configurations and results.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 08:31:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 16 Oct 2013 08:31:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1717) Bundling reduces performance
 in scenario mimicking Inifinispan
In-Reply-To: <JIRA.12503239.1381926401000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503239.1381926401000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503239.1381926401000.740.1381926662596@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1717:
---------------------------

    Fix Version/s: 3.5

    
> Bundling reduces performance in scenario mimicking Inifinispan
> --------------------------------------------------------------
>
>                 Key: JGRP-1717
>                 URL: https://issues.jboss.org/browse/JGRP-1717
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.3
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>         Attachments: benchmark-jgroups.xml, jgroups-udp.pdf, jgroups-udp.xml
>
>
> In Radargun benchmark of JGroups mimicking the behaviour of Infinispan we can see that performance with bundling on actually reduces the performance.
> See attached configurations and results.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 08:47:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 16 Oct 2013 08:47:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1507) Investigate failure in
 StatefulWithXPCFailoverTestCase
In-Reply-To: <JIRA.12494123.1371055191000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494123.1371055191000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494123.1371055191000.783.1381927622105@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814611#comment-12814611 ] 

RH Bugzilla Integration commented on WFLY-1507:
-----------------------------------------------

Paul Ferraro <paul.ferraro at redhat.com> made a comment on [bug 963610|https://bugzilla.redhat.com/show_bug.cgi?id=963610]

This can no longer be addressed in the remaining time for release.
                
> Investigate failure in StatefulWithXPCFailoverTestCase
> ------------------------------------------------------
>
>                 Key: WFLY-1507
>                 URL: https://issues.jboss.org/browse/WFLY-1507
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: jaikiran pai
>            Assignee: Paul Ferraro
>            Priority: Blocker
>             Fix For: 8.0.0.Alpha2
>
>         Attachments: log2.txt
>
>
> Numerous exceptions are reported and the tests fails intermittently but often in StatefulWithXPCFailoverTestCase.
> Entire logs attached.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 09:46:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 16 Oct 2013 09:46:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2319) LDAP Search containing URL -
 InvalidNameException: ldap:: [LDAP: error code 34 - Invalid root Dn given
In-Reply-To: <JIRA.12503254.1381931058868@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503254.1381931058868@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503254.1381931058868.934.1381931162028@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-2319:
--------------------------------------

             Summary: LDAP Search containing URL - InvalidNameException: ldap:: [LDAP: error code 34 - Invalid root Dn given
                 Key: WFLY-2319
                 URL: https://issues.jboss.org/browse/WFLY-2319
             Project: WildFly
          Issue Type: Bug
          Components: Naming
    Affects Versions: 8.0.0.Beta1
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 8.0.0.CR1


The following code: -

{code}
        Hashtable env = new Hashtable();
        env.put("java.naming.factory.initial", "com.sun.jndi.ldap.LdapCtxFactory");
        env.put("java.naming.security.authentication", "simple");
        env.put("java.naming.provider.url", "ldap://localhost:10389");
        env.put(InitialDirContext.SECURITY_PRINCIPAL, "uid=admin,ou=system");
        env.put(InitialDirContext.SECURITY_CREDENTIALS, "secret");
        SearchControls ctl = null;
        String attrArr[] = new String[1];
        attrArr[0] = "sn";
        ctl = new SearchControls(2, 0L, 0, attrArr, false, false);

        String base = "ldap://localhost:10389/dc=simple,dc=wildfly,dc=org";
        String filter = "(uid=UserOne)";

        NamingEnumeration nenum = null;
        DirContext ictx = null;

            ictx = new InitialDirContext(env);
            nenum = ictx.search(base, filter, ctl);
{code}

Results in the following exception: -

{noquote}
13:03:45,598 ERROR [stderr] (default task-1) javax.naming.InvalidNameException: ldap:: [LDAP: error code 34 - Invalid root Dn given : ldap: (0x6C 0x64 0x61 0x70 0x3A ) is invalid]; remaining name 'ldap://localhost:10389/dc=simple,dc=wildfly,dc=org'
13:03:45,599 ERROR [stderr] (default task-1) 	at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3025)
13:03:45,600 ERROR [stderr] (default task-1) 	at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2840)
13:03:45,600 ERROR [stderr] (default task-1) 	at com.sun.jndi.ldap.LdapCtx.c_lookup(LdapCtx.java:1034)
{noquote}

Switching to a base that does not begin with a URL and the search works, executing this code outside of WildFly also works.

The underlying issue is that the default InitialContext implementation contains the following method: -

{code}
    protected Context getURLOrDefaultInitCtx(String name)
        throws NamingException {
        if (NamingManager.hasInitialContextFactoryBuilder()) {
            return getDefaultInitCtx();
        }
        String scheme = getURLScheme(name);
        if (scheme != null) {
            Context ctx = NamingManager.getURLContext(scheme, myProps);
            if (ctx != null) {
                return ctx;
            }
        }
        return getDefaultInitCtx();
    }
{code}

As the naming subsystem has registered a InitialContextFactoryBuilder this code will never fall down to the scheme specific section.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 09:48:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 16 Oct 2013 09:48:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2319) LDAP Search containing URL -
 InvalidNameException: ldap:: [LDAP: error code 34 - Invalid root Dn given
In-Reply-To: <JIRA.12503254.1381931058000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503254.1381931058000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503254.1381931058000.942.1381931282127@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814636#comment-12814636 ] 

Darran Lofthouse commented on WFLY-2319:
----------------------------------------

This issue is very closely related to WFLY-794 although goes beyond it for the purposes of LDAP searching.
                
> LDAP Search containing URL - InvalidNameException: ldap:: [LDAP: error code 34 - Invalid root Dn given
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2319
>                 URL: https://issues.jboss.org/browse/WFLY-2319
>             Project: WildFly
>          Issue Type: Bug
>          Components: Naming
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> The following code: -
> {code}
>         Hashtable env = new Hashtable();
>         env.put("java.naming.factory.initial", "com.sun.jndi.ldap.LdapCtxFactory");
>         env.put("java.naming.security.authentication", "simple");
>         env.put("java.naming.provider.url", "ldap://localhost:10389");
>         env.put(InitialDirContext.SECURITY_PRINCIPAL, "uid=admin,ou=system");
>         env.put(InitialDirContext.SECURITY_CREDENTIALS, "secret");
>         SearchControls ctl = null;
>         String attrArr[] = new String[1];
>         attrArr[0] = "sn";
>         ctl = new SearchControls(2, 0L, 0, attrArr, false, false);
>         String base = "ldap://localhost:10389/dc=simple,dc=wildfly,dc=org";
>         String filter = "(uid=UserOne)";
>         NamingEnumeration nenum = null;
>         DirContext ictx = null;
>             ictx = new InitialDirContext(env);
>             nenum = ictx.search(base, filter, ctl);
> {code}
> Results in the following exception: -
> {noquote}
> 13:03:45,598 ERROR [stderr] (default task-1) javax.naming.InvalidNameException: ldap:: [LDAP: error code 34 - Invalid root Dn given : ldap: (0x6C 0x64 0x61 0x70 0x3A ) is invalid]; remaining name 'ldap://localhost:10389/dc=simple,dc=wildfly,dc=org'
> 13:03:45,599 ERROR [stderr] (default task-1) 	at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3025)
> 13:03:45,600 ERROR [stderr] (default task-1) 	at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2840)
> 13:03:45,600 ERROR [stderr] (default task-1) 	at com.sun.jndi.ldap.LdapCtx.c_lookup(LdapCtx.java:1034)
> {noquote}
> Switching to a base that does not begin with a URL and the search works, executing this code outside of WildFly also works.
> The underlying issue is that the default InitialContext implementation contains the following method: -
> {code}
>     protected Context getURLOrDefaultInitCtx(String name)
>         throws NamingException {
>         if (NamingManager.hasInitialContextFactoryBuilder()) {
>             return getDefaultInitCtx();
>         }
>         String scheme = getURLScheme(name);
>         if (scheme != null) {
>             Context ctx = NamingManager.getURLContext(scheme, myProps);
>             if (ctx != null) {
>                 return ctx;
>             }
>         }
>         return getDefaultInitCtx();
>     }
> {code}
> As the naming subsystem has registered a InitialContextFactoryBuilder this code will never fall down to the scheme specific section.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 09:50:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 16 Oct 2013 09:50:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2319) LDAP Search containing URL -
 InvalidNameException: ldap:: [LDAP: error code 34 - Invalid root Dn given
In-Reply-To: <JIRA.12503254.1381931058000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503254.1381931058000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503254.1381931058000.951.1381931402312@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2319:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1014911

    
> LDAP Search containing URL - InvalidNameException: ldap:: [LDAP: error code 34 - Invalid root Dn given
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2319
>                 URL: https://issues.jboss.org/browse/WFLY-2319
>             Project: WildFly
>          Issue Type: Bug
>          Components: Naming
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> The following code: -
> {code}
>         Hashtable env = new Hashtable();
>         env.put("java.naming.factory.initial", "com.sun.jndi.ldap.LdapCtxFactory");
>         env.put("java.naming.security.authentication", "simple");
>         env.put("java.naming.provider.url", "ldap://localhost:10389");
>         env.put(InitialDirContext.SECURITY_PRINCIPAL, "uid=admin,ou=system");
>         env.put(InitialDirContext.SECURITY_CREDENTIALS, "secret");
>         SearchControls ctl = null;
>         String attrArr[] = new String[1];
>         attrArr[0] = "sn";
>         ctl = new SearchControls(2, 0L, 0, attrArr, false, false);
>         String base = "ldap://localhost:10389/dc=simple,dc=wildfly,dc=org";
>         String filter = "(uid=UserOne)";
>         NamingEnumeration nenum = null;
>         DirContext ictx = null;
>             ictx = new InitialDirContext(env);
>             nenum = ictx.search(base, filter, ctl);
> {code}
> Results in the following exception: -
> {noquote}
> 13:03:45,598 ERROR [stderr] (default task-1) javax.naming.InvalidNameException: ldap:: [LDAP: error code 34 - Invalid root Dn given : ldap: (0x6C 0x64 0x61 0x70 0x3A ) is invalid]; remaining name 'ldap://localhost:10389/dc=simple,dc=wildfly,dc=org'
> 13:03:45,599 ERROR [stderr] (default task-1) 	at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3025)
> 13:03:45,600 ERROR [stderr] (default task-1) 	at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2840)
> 13:03:45,600 ERROR [stderr] (default task-1) 	at com.sun.jndi.ldap.LdapCtx.c_lookup(LdapCtx.java:1034)
> {noquote}
> Switching to a base that does not begin with a URL and the search works, executing this code outside of WildFly also works.
> The underlying issue is that the default InitialContext implementation contains the following method: -
> {code}
>     protected Context getURLOrDefaultInitCtx(String name)
>         throws NamingException {
>         if (NamingManager.hasInitialContextFactoryBuilder()) {
>             return getDefaultInitCtx();
>         }
>         String scheme = getURLScheme(name);
>         if (scheme != null) {
>             Context ctx = NamingManager.getURLContext(scheme, myProps);
>             if (ctx != null) {
>                 return ctx;
>             }
>         }
>         return getDefaultInitCtx();
>     }
> {code}
> As the naming subsystem has registered a InitialContextFactoryBuilder this code will never fall down to the scheme specific section.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 10:15:02 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 16 Oct 2013 10:15:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1093) Track component updates
In-Reply-To: <JIRA.12503259.1381932865039@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503259.1381932865039@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503259.1381932865039.1028.1381932902813@jira02.app.mwc.hst.phx2.redhat.com>

Jesper Pedersen created JBJCA-1093:
--------------------------------------

             Summary: Track component updates
                 Key: JBJCA-1093
                 URL: https://issues.jboss.org/browse/JBJCA-1093
             Project: IronJacamar
          Issue Type: Task
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.1.1.Final




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 10:15:03 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 16 Oct 2013 10:15:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1094) JBoss Transaction SPI
	7.1.0.Final
In-Reply-To: <JIRA.12503260.1381932898841@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503260.1381932898841@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503260.1381932898841.1031.1381932903060@jira02.app.mwc.hst.phx2.redhat.com>

Jesper Pedersen created JBJCA-1094:
--------------------------------------

             Summary: JBoss Transaction SPI 7.1.0.Final
                 Key: JBJCA-1094
                 URL: https://issues.jboss.org/browse/JBJCA-1094
             Project: IronJacamar
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.1.1.Final




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 11:07:01 2013
From: jira-events at lists.jboss.org (Brad Maxwell (JIRA))
Date: Wed, 16 Oct 2013 11:07:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2320) EJB should not be remotely
 accessible until all of its dependencies have been started
In-Reply-To: <JIRA.12503266.1381935962263@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503266.1381935962263@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503266.1381935962263.1169.1381936021898@jira02.app.mwc.hst.phx2.redhat.com>

Brad Maxwell created WFLY-2320:
----------------------------------

             Summary: EJB should not be remotely accessible until all of its dependencies have been started
                 Key: WFLY-2320
                 URL: https://issues.jboss.org/browse/WFLY-2320
             Project: WildFly
          Issue Type: Bug
    Affects Versions: 8.0.0.Beta1
            Reporter: Brad Maxwell
            Assignee: Stuart Douglas


If an EJB injects or depends on a resource such as an @Singleton which has not been started, the EJB's remote interface java:jboss/exported/* is already bound and this allows remote EJB clients to try to invoke it.  This causes the EJB clients to hang because the EJB will not be started until its dependencies have been started.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 11:11:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 16 Oct 2013 11:11:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2320) EJB should not be remotely
 accessible until all of its dependencies have been started
In-Reply-To: <JIRA.12503266.1381935962000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503266.1381935962000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503266.1381935962000.1173.1381936262098@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2320:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1019894

    
> EJB should not be remotely accessible until all of its dependencies have been started
> -------------------------------------------------------------------------------------
>
>                 Key: WFLY-2320
>                 URL: https://issues.jboss.org/browse/WFLY-2320
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Brad Maxwell
>            Assignee: Stuart Douglas
>
> If an EJB injects or depends on a resource such as an @Singleton which has not been started, the EJB's remote interface java:jboss/exported/* is already bound and this allows remote EJB clients to try to invoke it.  This causes the EJB clients to hang because the EJB will not be started until its dependencies have been started.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 11:11:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 16 Oct 2013 11:11:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2320) EJB should not be remotely
 accessible until all of its dependencies have been started
In-Reply-To: <JIRA.12503266.1381935962000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503266.1381935962000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503266.1381935962000.1177.1381936262417@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814788#comment-12814788 ] 

RH Bugzilla Integration commented on WFLY-2320:
-----------------------------------------------

Brad Maxwell <bmaxwell at redhat.com> made a comment on [bug 1019894|https://bugzilla.redhat.com/show_bug.cgi?id=1019894]

If an EJB injects or depends on a resource such as an @Singleton which has not been started, the EJB's remote interface java:jboss/exported/* is already bound and this allows remote EJB clients to try to invoke it. This causes the EJB clients to hang because the EJB will not be started until its dependencies have been started.
                
> EJB should not be remotely accessible until all of its dependencies have been started
> -------------------------------------------------------------------------------------
>
>                 Key: WFLY-2320
>                 URL: https://issues.jboss.org/browse/WFLY-2320
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Brad Maxwell
>            Assignee: Stuart Douglas
>
> If an EJB injects or depends on a resource such as an @Singleton which has not been started, the EJB's remote interface java:jboss/exported/* is already bound and this allows remote EJB clients to try to invoke it.  This causes the EJB clients to hang because the EJB will not be started until its dependencies have been started.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 11:19:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 16 Oct 2013 11:19:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2206) Manualmode test suite copes
 the modules directory multiple times
In-Reply-To: <JIRA.12502031.1380731391000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502031.1380731391000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502031.1380731391000.1231.1381936742304@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814799#comment-12814799 ] 

RH Bugzilla Integration commented on WFLY-2206:
-----------------------------------------------

Tomaz Cerar <tcerar at redhat.com> changed the Status of [bug 1014742|https://bugzilla.redhat.com/show_bug.cgi?id=1014742] from NEW to POST
                
> Manualmode test suite copes the modules directory multiple times
> ----------------------------------------------------------------
>
>                 Key: WFLY-2206
>                 URL: https://issues.jboss.org/browse/WFLY-2206
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Beta1
>
>
> This uses lots of disk space for no good reason

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 11:35:02 2013
From: jira-events at lists.jboss.org (Gurinder Randhawa (JIRA))
Date: Wed, 16 Oct 2013 11:35:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-215) Corrupted Working/Production
	memory
In-Reply-To: <JIRA.12498476.1376388952000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498476.1376388952000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498476.1376388952000.1272.1381937702539@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12815441#comment-12815441 ] 

Gurinder Randhawa commented on DROOLS-215:
------------------------------------------

Davide,

Thanks for info first off. We have tried 5.6.0 snapshot from sept 13 and the bug still occurs, Only version this works with is 5.3.x We have many rules and I'm sure its not just one rule which will encounter this bug. I will investigate further into your problem description regarding beta constraints, is there any further information you can provide which would aid us in figuring out culprit rule so we can re-write them?

Also the mvel constraint evaluation you refer to, I want to confirm this has nothing to do with switching our selected dialect ? (which is java by default) but condition evaluations use dot notation (mvel) syntax.

Let me know what the new ticket reference number once its created.

                
> Corrupted Working/Production memory
> -----------------------------------
>
>                 Key: DROOLS-215
>                 URL: https://issues.jboss.org/browse/DROOLS-215
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Ales Dolecek
>            Assignee: Mark Proctor
>         Attachments: ConcurrentNodeMemories.java
>
>
> Experienced ClassCastException mixing BetaMemory and AlphaMemory. There is debate in the mailing list/forum. The problem seems to be related to dymanic updates of knowledgebase.
> Saddly there is no deterministic way how to reproduce the issue, but that should not prevent tracking it here.
> Stack trace from my project:
> java.lang.ClassCastException: org.drools.reteoo.BetaMemory cannot be cast to org.drools.reteoo.AlphaNode$AlphaMemory
>         at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:136) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:497) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:382) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:350) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:311) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:192) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:186) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at cz.nextiraone.screening.rules.screening.Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1.defaultConsequence(Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1.java:7) ~[na
> :na]
>         at cz.nextiraone.screening.rules.screening.Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1DefaultConsequenceInvokerGenerated.evaluate(Unknown Source) ~[na:na]
>         at cz.nextiraone.screening.rules.screening.Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1DefaultConsequenceInvoker.evaluate(Unknown Source) ~[na:na]
>         at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1287) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1221) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1456) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:710) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:674) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:230) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 11:53:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 16 Oct 2013 11:53:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-794)
 javax.naming.NameNotFoundException: rmi://127.0.0.1:1090/jmxrmi thrown when
 creating MBeanServerConnection
In-Reply-To: <JIRA.12488795.1365437999000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12488795.1365437999000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488795.1365437999000.1314.1381938782436@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse reassigned WFLY-794:
-------------------------------------

    Assignee: Darran Lofthouse  (was: Stuart Douglas)

    
> javax.naming.NameNotFoundException: rmi://127.0.0.1:1090/jmxrmi thrown when creating MBeanServerConnection
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-794
>                 URL: https://issues.jboss.org/browse/WFLY-794
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMX
>            Reporter: Alex Corvino
>            Assignee: Darran Lofthouse
>         Attachments: jmx-test.jar, JmxClient.java, JMXConnectionBean.java, JmxServer.java
>
>
> When trying to create a MBeanServerConnection to a NON-JBoss application from within an EJB a "javax.naming.NameNotFoundException" is thrown. 
> Steps to reproduce:
> Set up a stand-alone application that exposes an MBean. (ActiveMQ will work in this case.)
> Modify the attached JMXConnectionBean.java to connect to the ActiveMQ instance.
> Deploy the bean. A NameNotFoundException will be thrown.
> I've seen this behavior in 7.1.1.Final, 7.1.2.Final (EAP), 7.1.3.Final (EAP), EAP 6.1.0.Alpha (7.2.0.Final). 
> Note that this behavior is NOT seen when connecting to another JBoss server. 
> Full stack trace:
> {code} 
> Caused by: java.io.IOException: Failed to retrieve RMIServer stub: javax.naming.NameNotFoundException: rmi://127.0.0.1:1090/jmxrmi -- service jboss.naming.context.java.rmi:."127.0.0.1:1090".jmxrmi
> 	at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:340) [:1.6.0_26]
> 	at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:248) [:1.6.0_26]
> 	at com.example.JMXConnectionBean.init(JMXConnectionBean.java:28)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_26]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_26]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_26]
> 	at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_26]
> 	at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:70)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.ee.component.ManagedReferenceInterceptor.processInvocation(ManagedReferenceInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:44)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor$CustomSessionInvocationContext.proceed(SessionInvocationContextInterceptor.java:126)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:211)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.requiresNew(CMTTxInterceptor.java:313)
> 	at org.jboss.as.ejb3.tx.SingletonLifecycleCMTTxInterceptor.processInvocation(SingletonLifecycleCMTTxInterceptor.java:56)
> 	at org.jboss.as.ejb3.tx.SingletonLifecycleCMTTxInterceptor.processInvocation(SingletonLifecycleCMTTxInterceptor.java:42)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor.processInvocation(SessionInvocationContextInterceptor.java:71)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:152)
> 	... 9 more
> Caused by: javax.naming.NameNotFoundException: rmi://127.0.0.1:1090/jmxrmi -- service jboss.naming.context.java.rmi:."127.0.0.1:1090".jmxrmi
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:87)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:173)
> 	at org.jboss.as.naming.InitialContext.lookup(InitialContext.java:47)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:209)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:392) [:1.6.0_26]
> 	at javax.management.remote.rmi.RMIConnector.findRMIServerJNDI(RMIConnector.java:1888) [:1.6.0_26]
> 	at javax.management.remote.rmi.RMIConnector.findRMIServer(RMIConnector.java:1858) [:1.6.0_26]
> 	at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:257) [:1.6.0_26]
> 	... 37 more
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 11:55:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 16 Oct 2013 11:55:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-794)
 javax.naming.NameNotFoundException: rmi://127.0.0.1:1090/jmxrmi thrown when
 creating MBeanServerConnection
In-Reply-To: <JIRA.12488795.1365437999000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12488795.1365437999000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488795.1365437999000.1325.1381938902519@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-794:
----------------------------------

    Fix Version/s: 8.0.0.CR1

    
> javax.naming.NameNotFoundException: rmi://127.0.0.1:1090/jmxrmi thrown when creating MBeanServerConnection
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-794
>                 URL: https://issues.jboss.org/browse/WFLY-794
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMX
>            Reporter: Alex Corvino
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>         Attachments: jmx-test.jar, JmxClient.java, JMXConnectionBean.java, JmxServer.java
>
>
> When trying to create a MBeanServerConnection to a NON-JBoss application from within an EJB a "javax.naming.NameNotFoundException" is thrown. 
> Steps to reproduce:
> Set up a stand-alone application that exposes an MBean. (ActiveMQ will work in this case.)
> Modify the attached JMXConnectionBean.java to connect to the ActiveMQ instance.
> Deploy the bean. A NameNotFoundException will be thrown.
> I've seen this behavior in 7.1.1.Final, 7.1.2.Final (EAP), 7.1.3.Final (EAP), EAP 6.1.0.Alpha (7.2.0.Final). 
> Note that this behavior is NOT seen when connecting to another JBoss server. 
> Full stack trace:
> {code} 
> Caused by: java.io.IOException: Failed to retrieve RMIServer stub: javax.naming.NameNotFoundException: rmi://127.0.0.1:1090/jmxrmi -- service jboss.naming.context.java.rmi:."127.0.0.1:1090".jmxrmi
> 	at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:340) [:1.6.0_26]
> 	at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:248) [:1.6.0_26]
> 	at com.example.JMXConnectionBean.init(JMXConnectionBean.java:28)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_26]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_26]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_26]
> 	at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_26]
> 	at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:70)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.ee.component.ManagedReferenceInterceptor.processInvocation(ManagedReferenceInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:44)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor$CustomSessionInvocationContext.proceed(SessionInvocationContextInterceptor.java:126)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:211)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.requiresNew(CMTTxInterceptor.java:313)
> 	at org.jboss.as.ejb3.tx.SingletonLifecycleCMTTxInterceptor.processInvocation(SingletonLifecycleCMTTxInterceptor.java:56)
> 	at org.jboss.as.ejb3.tx.SingletonLifecycleCMTTxInterceptor.processInvocation(SingletonLifecycleCMTTxInterceptor.java:42)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor.processInvocation(SessionInvocationContextInterceptor.java:71)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:152)
> 	... 9 more
> Caused by: javax.naming.NameNotFoundException: rmi://127.0.0.1:1090/jmxrmi -- service jboss.naming.context.java.rmi:."127.0.0.1:1090".jmxrmi
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:87)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:173)
> 	at org.jboss.as.naming.InitialContext.lookup(InitialContext.java:47)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:209)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:392) [:1.6.0_26]
> 	at javax.management.remote.rmi.RMIConnector.findRMIServerJNDI(RMIConnector.java:1888) [:1.6.0_26]
> 	at javax.management.remote.rmi.RMIConnector.findRMIServer(RMIConnector.java:1858) [:1.6.0_26]
> 	at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:257) [:1.6.0_26]
> 	... 37 more
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 12:06:02 2013
From: jira-events at lists.jboss.org (Gurinder Randhawa (JIRA))
Date: Wed, 16 Oct 2013 12:06:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-215) Corrupted Working/Production
	memory
In-Reply-To: <JIRA.12498476.1376388952000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498476.1376388952000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498476.1376388952000.1351.1381939562081@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12815451#comment-12815451 ] 

Gurinder Randhawa commented on DROOLS-215:
------------------------------------------

I tried looking for rule pattern you outlined and we have alot of matches, a couple questions:

1. Is "10_ServiceRequest_InsertRefData" not the culprit rule as its shown at top of the stack trace? 

2. Narrowing down results to rules which evaluate on RefData() we have about 15 possible candidates, pasted below is one such sample, to narrow down issue can you elaborate more on your second point on constraint patterns to look for?

rule "20500_DefaultFactor_SUMM_50000"
    no-loop
    salience 7000
when
    $summRateFactorCode: RefData(code == "SUMM")
    $rateGroup: RateStandardGroup()
    $rateFactorGroup: RateFactorGroup(factorType == $summRateFactorCode, parentGroupRefId == $rateGroup.refId)
    $plan: Plan(rateGroups contains $rateGroup)
    $insuredPlan: InsuredPlan(planRefId == $plan.refId, getConfiguredParameterByGroupCode("SUMM")==null)    
    $factorValue : RateFactorValue() from $rateFactorGroup.matchInput("50000")
then
    RateFactorParameter parameter = new RateFactorParameter($factorValue);
    $insuredPlan.addConfiguredParameter(parameter);
    System.out.println("166000-Create default parameter SUMM 50000|code=" + $insuredPlan.getPlanCode() + "|value="+$factorValue.getValue()+"|min="+$factorValue.getMinValue()+"|max="+$factorValue.getMaxValue());
end
                
> Corrupted Working/Production memory
> -----------------------------------
>
>                 Key: DROOLS-215
>                 URL: https://issues.jboss.org/browse/DROOLS-215
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Ales Dolecek
>            Assignee: Mark Proctor
>         Attachments: ConcurrentNodeMemories.java
>
>
> Experienced ClassCastException mixing BetaMemory and AlphaMemory. There is debate in the mailing list/forum. The problem seems to be related to dymanic updates of knowledgebase.
> Saddly there is no deterministic way how to reproduce the issue, but that should not prevent tracking it here.
> Stack trace from my project:
> java.lang.ClassCastException: org.drools.reteoo.BetaMemory cannot be cast to org.drools.reteoo.AlphaNode$AlphaMemory
>         at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:136) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:497) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:382) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:350) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:311) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:192) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:186) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at cz.nextiraone.screening.rules.screening.Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1.defaultConsequence(Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1.java:7) ~[na
> :na]
>         at cz.nextiraone.screening.rules.screening.Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1DefaultConsequenceInvokerGenerated.evaluate(Unknown Source) ~[na:na]
>         at cz.nextiraone.screening.rules.screening.Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1DefaultConsequenceInvoker.evaluate(Unknown Source) ~[na:na]
>         at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1287) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1221) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1456) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:710) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:674) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:230) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 12:36:02 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Wed, 16 Oct 2013 12:36:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-215) Corrupted Working/Production
	memory
In-Reply-To: <JIRA.12498476.1376388952000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498476.1376388952000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498476.1376388952000.1402.1381941362220@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12815463#comment-12815463 ] 

Davide Sottara commented on DROOLS-215:
---------------------------------------

Moving the discussion to DROOLS-185, which is more appropriate
                
> Corrupted Working/Production memory
> -----------------------------------
>
>                 Key: DROOLS-215
>                 URL: https://issues.jboss.org/browse/DROOLS-215
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Ales Dolecek
>            Assignee: Mark Proctor
>         Attachments: ConcurrentNodeMemories.java
>
>
> Experienced ClassCastException mixing BetaMemory and AlphaMemory. There is debate in the mailing list/forum. The problem seems to be related to dymanic updates of knowledgebase.
> Saddly there is no deterministic way how to reproduce the issue, but that should not prevent tracking it here.
> Stack trace from my project:
> java.lang.ClassCastException: org.drools.reteoo.BetaMemory cannot be cast to org.drools.reteoo.AlphaNode$AlphaMemory
>         at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:136) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:497) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:382) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:350) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:311) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:192) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:186) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at cz.nextiraone.screening.rules.screening.Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1.defaultConsequence(Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1.java:7) ~[na
> :na]
>         at cz.nextiraone.screening.rules.screening.Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1DefaultConsequenceInvokerGenerated.evaluate(Unknown Source) ~[na:na]
>         at cz.nextiraone.screening.rules.screening.Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1DefaultConsequenceInvoker.evaluate(Unknown Source) ~[na:na]
>         at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1287) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1221) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1456) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:710) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:674) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:230) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 12:38:02 2013
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Wed, 16 Oct 2013 12:38:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (LOGTOOL-77) CodeWriter is writing one
 byte at a time potentially resulting in poor performance
In-Reply-To: <JIRA.12503721.1381941394297@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503721.1381941394297@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503721.1381941394297.1411.1381941482319@jira02.app.mwc.hst.phx2.redhat.com>

James Perkins created LOGTOOL-77:
------------------------------------

             Summary: CodeWriter is writing one byte at a time potentially resulting in poor performance
                 Key: LOGTOOL-77
                 URL: https://issues.jboss.org/browse/LOGTOOL-77
             Project: Log Tool
          Issue Type: Enhancement
      Security Level: Public (Everyone can see)
            Reporter: James Perkins
            Assignee: James Perkins
             Fix For: 1.2.0.Beta2




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 12:43:01 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 16 Oct 2013 12:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2321) Add user configuration
 loading broken if executed from any folder other than bin
In-Reply-To: <JIRA.12503723.1381941728266@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503723.1381941728266@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503723.1381941728266.1431.1381941781943@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-2321:
--------------------------------------

             Summary: Add user configuration loading broken if executed from any folder other than bin
                 Key: WFLY-2321
                 URL: https://issues.jboss.org/browse/WFLY-2321
             Project: WildFly
          Issue Type: Bug
          Components: Scripts
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse


Also should remove the system property reading and just rely on the location being bin.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 12:45:02 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Wed, 16 Oct 2013 12:45:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-185) ClassCastException at
	ConditionEvaluator
In-Reply-To: <JIRA.12495435.1372690482000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495435.1372690482000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495435.1372690482000.1440.1381941902144@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12815470#comment-12815470 ] 

Davide Sottara commented on DROOLS-185:
---------------------------------------

About the stack trace:
1) rule "10_ServiceRequest_InsertRefData" inserts RefData facts into the WM. The propagation of one of those causes the CCE, as constraints are being evaluated
2) Looking at the stack trace: 
- rule "10_ServiceRequest_InsertRefData" is inserting a RefData, and the ObjectTypeNode for RefData() is encountered
- the OTN is connected directly to a LeftInputAdapterNode --> RefData() is the first pattern. There are no alpha nodes along the way, so it must be an empty pattern, or a pattern with bindings only
3) Two JoinNodes are passed --> two more patterns
4) The last JoinNode is where the exception occurs. It's in a TripleBetaConstraint, meaning that there are exactly 3 constraints involving variables

rule "20500_DefaultFactor_SUMM_50000" does not exactly meet these criteria, but if you only have 15 rules like that is should be easy to figure out which one is causing the problem. I have seen your comment avout overriding getters/setters. That might be a good candidate to expose the problem
                
> ClassCastException at ConditionEvaluator
> ----------------------------------------
>
>                 Key: DROOLS-185
>                 URL: https://issues.jboss.org/browse/DROOLS-185
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Sergey Alaev
>            Assignee: Mario Fusco
>
> Stacktrace:
> Caused by: java.lang.ClassCastException: ***** cannot be cast to ******
> 	at ConditionEvaluator443abf2927ca4f64a4ad86407ae34799.evaluate(Unknown Source)
> 	at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:200)
> 	at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:157)
> 	at org.drools.reteoo.FromNode.checkConstraintsAndPropagate(FromNode.java:318)
> 	at org.drools.reteoo.FromNode.assertLeftTuple(FromNode.java:164)
> 	at org.drools.reteoo.CompositeLeftTupleSinkAdapter.doPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:232)
> 	at org.drools.reteoo.CompositeLeftTupleSinkAdapter.createAndPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:116)
> 	at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:154)
> 	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:59)
> Reason:
> ConditionEvaluator seems to be using lazy initializing and then caches generated class to evaluate this expression with another arguments.
> Given following:
> interface A {
>    String getString();
> }
> interface B {
>    String getString();
> }
> class X implements B, A {}
> class Y implements A{}
> rule "test rule"
> when:
>      A(string != null)
> then:
> end
> When rule engine is called for the first time with instance of class X, ConditionEvaluator will bind itself to first found interface implementing method getString(), i.e. interface B.
> Thus second call with instance of class Y will cause ClassCastException of casting Y to B.
> Solution: force MVEL to bind bytecode generated methods to class/interface declared in the rule explicitly, in our case - to interface A.
> Quickfix: use following declaration of class X:
> class X implements A, B {}
> Because ConditionEvaluator binds to first available interface, it will bind now to correct interface - to interface A.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 12:45:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 16 Oct 2013 12:45:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2321) Add user configuration
 loading broken if executed from any folder other than bin
In-Reply-To: <JIRA.12503723.1381941728000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503723.1381941728000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503723.1381941728000.1445.1381941902369@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2321:
-----------------------------------

    Affects Version/s: 8.0.0.Beta1

    
> Add user configuration loading broken if executed from any folder other than bin
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-2321
>                 URL: https://issues.jboss.org/browse/WFLY-2321
>             Project: WildFly
>          Issue Type: Bug
>          Components: Scripts
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>
> Also should remove the system property reading and just rely on the location being bin.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 12:45:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 16 Oct 2013 12:45:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2321) Add user configuration
 loading broken if executed from any folder other than bin
In-Reply-To: <JIRA.12503723.1381941728000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503723.1381941728000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503723.1381941728000.1448.1381941902453@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2321:
-----------------------------------

    Fix Version/s: 8.0.0.CR1

    
> Add user configuration loading broken if executed from any folder other than bin
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-2321
>                 URL: https://issues.jboss.org/browse/WFLY-2321
>             Project: WildFly
>          Issue Type: Bug
>          Components: Scripts
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Also should remove the system property reading and just rely on the location being bin.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 12:45:02 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Wed, 16 Oct 2013 12:45:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-185) ClassCastException at
	ConditionEvaluator
In-Reply-To: <JIRA.12495435.1372690482000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495435.1372690482000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495435.1372690482000.1455.1381941902923@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12815472#comment-12815472 ] 

Davide Sottara commented on DROOLS-185:
---------------------------------------

Can you provide more details about which getters/setters you are overriding exactly, and how?
Thanks!
Davide
                
> ClassCastException at ConditionEvaluator
> ----------------------------------------
>
>                 Key: DROOLS-185
>                 URL: https://issues.jboss.org/browse/DROOLS-185
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Sergey Alaev
>            Assignee: Mario Fusco
>
> Stacktrace:
> Caused by: java.lang.ClassCastException: ***** cannot be cast to ******
> 	at ConditionEvaluator443abf2927ca4f64a4ad86407ae34799.evaluate(Unknown Source)
> 	at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:200)
> 	at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:157)
> 	at org.drools.reteoo.FromNode.checkConstraintsAndPropagate(FromNode.java:318)
> 	at org.drools.reteoo.FromNode.assertLeftTuple(FromNode.java:164)
> 	at org.drools.reteoo.CompositeLeftTupleSinkAdapter.doPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:232)
> 	at org.drools.reteoo.CompositeLeftTupleSinkAdapter.createAndPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:116)
> 	at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:154)
> 	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:59)
> Reason:
> ConditionEvaluator seems to be using lazy initializing and then caches generated class to evaluate this expression with another arguments.
> Given following:
> interface A {
>    String getString();
> }
> interface B {
>    String getString();
> }
> class X implements B, A {}
> class Y implements A{}
> rule "test rule"
> when:
>      A(string != null)
> then:
> end
> When rule engine is called for the first time with instance of class X, ConditionEvaluator will bind itself to first found interface implementing method getString(), i.e. interface B.
> Thus second call with instance of class Y will cause ClassCastException of casting Y to B.
> Solution: force MVEL to bind bytecode generated methods to class/interface declared in the rule explicitly, in our case - to interface A.
> Quickfix: use following declaration of class X:
> class X implements A, B {}
> Because ConditionEvaluator binds to first available interface, it will bind now to correct interface - to interface A.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 13:24:02 2013
From: jira-events at lists.jboss.org (Gurinder Randhawa (JIRA))
Date: Wed, 16 Oct 2013 13:24:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-185) ClassCastException at
	ConditionEvaluator
In-Reply-To: <JIRA.12495435.1372690482000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495435.1372690482000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495435.1372690482000.1491.1381944242119@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12815482#comment-12815482 ] 

Gurinder Randhawa commented on DROOLS-185:
------------------------------------------

Davide I have resolved this issue.The rule below is run as soon as RefData(code == "TRIP") is inserted into session (as you mentioned), it has a condition with 3 constraints on RateFactorGroup. Looks like method matchInput(Long inputValue) takes in a Long but is passed an integer. I have wrapped it with a new Long(...) across rule base and seems to solve this issue.

Thanks for the help, I never would have narrowed down problem with your help! Hopefully this can be fixed in 5.6.0, I attempted to try 6.x but there are major API changes, more than we are prepared to deal with at this time. Thanks!

rule "20510_DefaultFactor_TRIP_multi_trip_medical"
    no-loop
    salience 7000
when
    $tripRateFactorCode: RefData(code == "TRIP")
    $trip: Trip(getDuration()!=null)
    $rateGroup: RateStandardGroup()
    $plan: Plan(rateGroups contains $rateGroup)
    $insuredPlan: InsuredPlan(planRefId == $plan.refId, planCode in ("PL-MMED-1","PL-MMED-2","PL-MMED-3","PL-MMED-4","PL-MMED-5"), getConfiguredParameterByGroupCode("TRIP")==null)
    $rateFactorGroup: RateFactorGroup(factorType == $tripRateFactorCode, parentGroupRefId == $rateGroup.refId, matchInput($trip.getDuration())!=null)
    $factorValue : RateFactorValue() from $rateFactorGroup.matchInput($trip.getDuration())
then
    RateFactorParameter parameter = new RateFactorParameter($factorValue, $trip.getDuration().toString());
    $insuredPlan.addConfiguredParameter(parameter);
    System.out.println("20510-Create TRIP Factor plan parameter   |code=" + $insuredPlan.getPlanCode() + "|value="+$factorValue.getValue()+"|min="+$factorValue.getMinValue()+"|max="+$factorValue.getMaxValue()+"|days="+$trip.getDuration());    
end
                
> ClassCastException at ConditionEvaluator
> ----------------------------------------
>
>                 Key: DROOLS-185
>                 URL: https://issues.jboss.org/browse/DROOLS-185
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Sergey Alaev
>            Assignee: Mario Fusco
>
> Stacktrace:
> Caused by: java.lang.ClassCastException: ***** cannot be cast to ******
> 	at ConditionEvaluator443abf2927ca4f64a4ad86407ae34799.evaluate(Unknown Source)
> 	at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:200)
> 	at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:157)
> 	at org.drools.reteoo.FromNode.checkConstraintsAndPropagate(FromNode.java:318)
> 	at org.drools.reteoo.FromNode.assertLeftTuple(FromNode.java:164)
> 	at org.drools.reteoo.CompositeLeftTupleSinkAdapter.doPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:232)
> 	at org.drools.reteoo.CompositeLeftTupleSinkAdapter.createAndPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:116)
> 	at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:154)
> 	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:59)
> Reason:
> ConditionEvaluator seems to be using lazy initializing and then caches generated class to evaluate this expression with another arguments.
> Given following:
> interface A {
>    String getString();
> }
> interface B {
>    String getString();
> }
> class X implements B, A {}
> class Y implements A{}
> rule "test rule"
> when:
>      A(string != null)
> then:
> end
> When rule engine is called for the first time with instance of class X, ConditionEvaluator will bind itself to first found interface implementing method getString(), i.e. interface B.
> Thus second call with instance of class Y will cause ClassCastException of casting Y to B.
> Solution: force MVEL to bind bytecode generated methods to class/interface declared in the rule explicitly, in our case - to interface A.
> Quickfix: use following declaration of class X:
> class X implements A, B {}
> Because ConditionEvaluator binds to first available interface, it will bind now to correct interface - to interface A.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 14:06:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 16 Oct 2013 14:06:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2322) Update add-user to REJECT bad
	passwords
In-Reply-To: <JIRA.12503730.1381946649648@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503730.1381946649648@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503730.1381946649648.1548.1381946762030@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-2322:
--------------------------------------

             Summary: Update add-user to REJECT bad passwords
                 Key: WFLY-2322
                 URL: https://issues.jboss.org/browse/WFLY-2322
             Project: WildFly
          Issue Type: Bug
          Components: Scripts
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 8.0.0.Final


Before we release .Final add-user.sh should be switched back to rejecting bad passwords rather than just warning.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 14:06:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 16 Oct 2013 14:06:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2322) Update add-user to REJECT bad
	passwords
In-Reply-To: <JIRA.12503730.1381946649000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503730.1381946649000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503730.1381946649000.1551.1381946762159@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2322:
-----------------------------------

    Priority: Blocker  (was: Major)

    
> Update add-user to REJECT bad passwords
> ---------------------------------------
>
>                 Key: WFLY-2322
>                 URL: https://issues.jboss.org/browse/WFLY-2322
>             Project: WildFly
>          Issue Type: Bug
>          Components: Scripts
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 8.0.0.Final
>
>
> Before we release .Final add-user.sh should be switched back to rejecting bad passwords rather than just warning.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 14:06:02 2013
From: jira-events at lists.jboss.org (Rich DiCroce (JIRA))
Date: Wed, 16 Oct 2013 14:06:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1718) Message corruption under
	heavy load
In-Reply-To: <JIRA.12503731.1381946713661@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503731.1381946713661@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503731.1381946713661.1561.1381946762741@jira02.app.mwc.hst.phx2.redhat.com>

Rich DiCroce created JGRP-1718:
----------------------------------

             Summary: Message corruption under heavy load
                 Key: JGRP-1718
                 URL: https://issues.jboss.org/browse/JGRP-1718
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 3.2.12
         Environment: JBoss AS 7.2.0.Final (includes JGroups 3.2.7.Final, upgrading to 3.2.12.Final had no effect)
            Reporter: Rich DiCroce
            Assignee: Bela Ban


In my project, I'm using the Kryo serialization library to serialize/deserialize objects to/from byte[]. Some of these byte arrays appear to be getting corrupted during transmission.

The problem happens very infrequently and only under load. I have to send tens of thousands of messages from hundreds of threads just to get two or three errors. The exception occurs when Kryo tries to deserialize the byte[] on the receiving node. So far, all of the errors I've seen happen when Kryo tries to find a class to deserialize an object, and the stack traces end with something like:

Caused by: java.lang.ClassNotFoundException: java.util.Date[SOH][GS]

Note that the [SOH] and [GS] are not literally those strings, they're unprintable ASCII 0x1 and 0x1D.

I'm confident that Kryo itself is not the source of the problem. I added some code to my project to deserialize the message on the sending node, immediately after serializing it, and log any exception thrown from the deserialization. The sending node did not log an exception, but the receiving node still did. My code passes the byte[] to the Message constructor without doing anything to it.

It also appears that I am not the first person to encounter this issue. See https://code.google.com/p/kryo/issues/detail?id=102

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 15:20:02 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Wed, 16 Oct 2013 15:20:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-185) ClassCastException at
	ConditionEvaluator
In-Reply-To: <JIRA.12495435.1372690482000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495435.1372690482000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495435.1372690482000.1638.1381951202174@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Davide Sottara reopened DROOLS-185:
-----------------------------------



A similar exception is raised in this scenario:

class A { public boolean match( Long value ) { .. } }
class B { public Integer getValue() { ... } }

rule R
when 
  B( $v : value )
  A( match( $v ) 
then ... end

The CCE is thrown when the mvel constraint is jitted
                
> ClassCastException at ConditionEvaluator
> ----------------------------------------
>
>                 Key: DROOLS-185
>                 URL: https://issues.jboss.org/browse/DROOLS-185
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Sergey Alaev
>            Assignee: Mario Fusco
>
> Stacktrace:
> Caused by: java.lang.ClassCastException: ***** cannot be cast to ******
> 	at ConditionEvaluator443abf2927ca4f64a4ad86407ae34799.evaluate(Unknown Source)
> 	at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:200)
> 	at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:157)
> 	at org.drools.reteoo.FromNode.checkConstraintsAndPropagate(FromNode.java:318)
> 	at org.drools.reteoo.FromNode.assertLeftTuple(FromNode.java:164)
> 	at org.drools.reteoo.CompositeLeftTupleSinkAdapter.doPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:232)
> 	at org.drools.reteoo.CompositeLeftTupleSinkAdapter.createAndPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:116)
> 	at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:154)
> 	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:59)
> Reason:
> ConditionEvaluator seems to be using lazy initializing and then caches generated class to evaluate this expression with another arguments.
> Given following:
> interface A {
>    String getString();
> }
> interface B {
>    String getString();
> }
> class X implements B, A {}
> class Y implements A{}
> rule "test rule"
> when:
>      A(string != null)
> then:
> end
> When rule engine is called for the first time with instance of class X, ConditionEvaluator will bind itself to first found interface implementing method getString(), i.e. interface B.
> Thus second call with instance of class Y will cause ClassCastException of casting Y to B.
> Solution: force MVEL to bind bytecode generated methods to class/interface declared in the rule explicitly, in our case - to interface A.
> Quickfix: use following declaration of class X:
> class X implements A, B {}
> Because ConditionEvaluator binds to first available interface, it will bind now to correct interface - to interface A.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 15:22:17 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Wed, 16 Oct 2013 15:22:17 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-185) ClassCastException at
	ConditionEvaluator
In-Reply-To: <JIRA.12495435.1372690482000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495435.1372690482000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495435.1372690482000.1646.1381951337718@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12815511#comment-12815511 ] 

Davide Sottara edited comment on DROOLS-185 at 10/16/13 3:20 PM:
-----------------------------------------------------------------

A similar exception is raised in this scenario:
<code>
class A { public boolean match( Long value ) { .. } }
class B { public Integer getValue() { ... } }

rule R
when 
  B( $v : value )
  A( match( $v ) 
then ... end
</code>
The CCE is thrown when the mvel constraint is jitted
                
      was (Author: dsotty):
    A similar exception is raised in this scenario:

class A { public boolean match( Long value ) { .. } }
class B { public Integer getValue() { ... } }

rule R
when 
  B( $v : value )
  A( match( $v ) 
then ... end

The CCE is thrown when the mvel constraint is jitted
                  
> ClassCastException at ConditionEvaluator
> ----------------------------------------
>
>                 Key: DROOLS-185
>                 URL: https://issues.jboss.org/browse/DROOLS-185
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Sergey Alaev
>            Assignee: Mario Fusco
>
> Stacktrace:
> Caused by: java.lang.ClassCastException: ***** cannot be cast to ******
> 	at ConditionEvaluator443abf2927ca4f64a4ad86407ae34799.evaluate(Unknown Source)
> 	at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:200)
> 	at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:157)
> 	at org.drools.reteoo.FromNode.checkConstraintsAndPropagate(FromNode.java:318)
> 	at org.drools.reteoo.FromNode.assertLeftTuple(FromNode.java:164)
> 	at org.drools.reteoo.CompositeLeftTupleSinkAdapter.doPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:232)
> 	at org.drools.reteoo.CompositeLeftTupleSinkAdapter.createAndPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:116)
> 	at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:154)
> 	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:59)
> Reason:
> ConditionEvaluator seems to be using lazy initializing and then caches generated class to evaluate this expression with another arguments.
> Given following:
> interface A {
>    String getString();
> }
> interface B {
>    String getString();
> }
> class X implements B, A {}
> class Y implements A{}
> rule "test rule"
> when:
>      A(string != null)
> then:
> end
> When rule engine is called for the first time with instance of class X, ConditionEvaluator will bind itself to first found interface implementing method getString(), i.e. interface B.
> Thus second call with instance of class Y will cause ClassCastException of casting Y to B.
> Solution: force MVEL to bind bytecode generated methods to class/interface declared in the rule explicitly, in our case - to interface A.
> Quickfix: use following declaration of class X:
> class X implements A, B {}
> Because ConditionEvaluator binds to first available interface, it will bind now to correct interface - to interface A.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 15:22:17 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Wed, 16 Oct 2013 15:22:17 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-185) ClassCastException at
	ConditionEvaluator
In-Reply-To: <JIRA.12495435.1372690482000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495435.1372690482000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495435.1372690482000.1651.1381951337933@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12815511#comment-12815511 ] 

Davide Sottara edited comment on DROOLS-185 at 10/16/13 3:20 PM:
-----------------------------------------------------------------

A similar exception is raised in this scenario:

class A { public boolean match( Long value ) { .. } }
class B { public Integer getValue() { ... } }

rule R
when 
  B( $v : value )
  A( match( $v ) 
then ... end

The CCE is thrown when the mvel constraint is jitted
                
      was (Author: dsotty):
    A similar exception is raised in this scenario:
<code>
class A { public boolean match( Long value ) { .. } }
class B { public Integer getValue() { ... } }

rule R
when 
  B( $v : value )
  A( match( $v ) 
then ... end
</code>
The CCE is thrown when the mvel constraint is jitted
                  
> ClassCastException at ConditionEvaluator
> ----------------------------------------
>
>                 Key: DROOLS-185
>                 URL: https://issues.jboss.org/browse/DROOLS-185
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Sergey Alaev
>            Assignee: Mario Fusco
>
> Stacktrace:
> Caused by: java.lang.ClassCastException: ***** cannot be cast to ******
> 	at ConditionEvaluator443abf2927ca4f64a4ad86407ae34799.evaluate(Unknown Source)
> 	at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:200)
> 	at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:157)
> 	at org.drools.reteoo.FromNode.checkConstraintsAndPropagate(FromNode.java:318)
> 	at org.drools.reteoo.FromNode.assertLeftTuple(FromNode.java:164)
> 	at org.drools.reteoo.CompositeLeftTupleSinkAdapter.doPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:232)
> 	at org.drools.reteoo.CompositeLeftTupleSinkAdapter.createAndPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:116)
> 	at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:154)
> 	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:59)
> Reason:
> ConditionEvaluator seems to be using lazy initializing and then caches generated class to evaluate this expression with another arguments.
> Given following:
> interface A {
>    String getString();
> }
> interface B {
>    String getString();
> }
> class X implements B, A {}
> class Y implements A{}
> rule "test rule"
> when:
>      A(string != null)
> then:
> end
> When rule engine is called for the first time with instance of class X, ConditionEvaluator will bind itself to first found interface implementing method getString(), i.e. interface B.
> Thus second call with instance of class Y will cause ClassCastException of casting Y to B.
> Solution: force MVEL to bind bytecode generated methods to class/interface declared in the rule explicitly, in our case - to interface A.
> Quickfix: use following declaration of class X:
> class X implements A, B {}
> Because ConditionEvaluator binds to first available interface, it will bind now to correct interface - to interface A.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 16:03:02 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Wed, 16 Oct 2013 16:03:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2323) Wildfly 8 EJB client can't
 talk to JBoss AS 7.x
In-Reply-To: <JIRA.12503736.1381953766793@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503736.1381953766793@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503736.1381953766793.1729.1381953781998@jira02.app.mwc.hst.phx2.redhat.com>

David Lloyd created WFLY-2323:
---------------------------------

             Summary: Wildfly 8 EJB client can't talk to JBoss AS 7.x
                 Key: WFLY-2323
                 URL: https://issues.jboss.org/browse/WFLY-2323
             Project: WildFly
          Issue Type: Bug
          Components: EJB
    Affects Versions: 8.0.0.Beta1
            Reporter: David Lloyd
            Assignee: David Lloyd
             Fix For: 8.0.0.CR1


A WildFly 8 EJB client cannot negotiate a connection to AS 7.x, though an AS 7.x client can talk to WildFly 8.x.  The protocol should be forward and backward compatible.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 16:07:02 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Wed, 16 Oct 2013 16:07:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-300) Add optional start and end
 arguments to timers
In-Reply-To: <JIRA.12503113.1381861876000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503113.1381861876000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503113.1381861876000.1742.1381954022506@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12815526#comment-12815526 ] 

Davide Sottara commented on DROOLS-300:
---------------------------------------

Issue #1
The (non-existing) documentation states just one thing: our interval/expression Timers are compatible with java Timers. 
Java actually provides two modes: fixed-delay repetitions and fixed-rate repetitions.
What we have outlined here is fixed-rate, but we could have fixed-delay too. This might require another attribute, e.g. fixedRate (=true by default).
                
> Add optional start and end arguments to timers
> ----------------------------------------------
>
>                 Key: DROOLS-300
>                 URL: https://issues.jboss.org/browse/DROOLS-300
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 16:09:01 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 16 Oct 2013 16:09:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2317) Trying to remove a server
 group as a server-group-scoped role leaks information
In-Reply-To: <JIRA.12503235.1381924172000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503235.1381924172000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503235.1381924172000.1745.1381954141987@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12815527#comment-12815527 ] 

RH Bugzilla Integration commented on WFLY-2317:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> made a comment on [bug 1019784|https://bugzilla.redhat.com/show_bug.cgi?id=1019784]

I don't believe this should be "high" severity. See https://bugzilla.redhat.com/show_bug.cgi?id=1015524#c1 for an explanation of why the other server groups are not addressable. It's really not an attempt to hide sensitive data. It's an unsuccessful attempt to provide a coherent view of the resource tree to the user. Ideally these resources would be addressable but not readable, but we can't do that for 6.2 without introducing too much risk for breaking things in the console.

No argument that if the resource is not supposed to be addressable a permission denied response is not correct.
                
> Trying to remove a server group as a server-group-scoped role leaks information
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-2317
>                 URL: https://issues.jboss.org/browse/WFLY-2317
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Brian Stansberry
>              Labels: rbac-filed-by-qa
>
> When writing a small test case for WFLY-2190, I stumbled upon a problem: trying to remove an existing server group by a server-group-scoped user that does NOT have permissions to that server group leaks information. On a freshly built WildFly with added {{admin}} user into {{domain/configuration/mgmt-users.properties}}, it can be reproduced like this:
> {code}
> [1] ./bin/domain.sh
> [2] ./bin/jboss-cli.sh -c
>     /core-service=management/access=authorization/server-group-scoped-role=NewRole:add(base-role=administrator, server-groups=[main-server-group])
>     /core-service=management/access=authorization/role-mapping=NewRole:add
>     /core-service=management/access=authorization/role-mapping=NewRole/include=user-admin:add(name=admin, type=user)
>     /core-service=management/access=authorization:write-attribute(name=provider, value=rbac)
>     exit
> [1] ^C
>     ./bin/domain.sh
> [2] ./bin/jboss-cli.sh -c --user=admin --password=XXX
>     /server-group=other-server-group:read-resource
>     /server-group=other-server-group:remove
> {code}
> What does that mean? The {{NewRole}} is scoped to the {{main-server-group}} server group and can't see {{other-server-group}}. When doing {{/server-group=other-server-group:read-resource}}, this is correctly enforced and the output looks like this:
> {code}
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014807: Management resource '[(\"server-group\" => \"other-server-group\")]' not found",
>     "rolled-back" => true
> }
> {code}
> However, trying to do {{/server-group=other-server-group:remove}}, which is only a different operation _on the same resource_, I get a different error message:
> {code}
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "JBAS013456: Unauthorized to execute operation 'remove' for resource '[(\"server-group\" => \"other-server-group\")]' -- \"JBAS013475: Permission denied\""},
>     "rolled-back" => true
> }
> {code}
> I expect the error message to be completely the same as in previous case, not leaking any information that the {{other-server-group}} actually exists.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 16:09:02 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Wed, 16 Oct 2013 16:09:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-300) Add optional start and end
 arguments to timers
In-Reply-To: <JIRA.12503113.1381861876000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503113.1381861876000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503113.1381861876000.1748.1381954142146@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12815526#comment-12815526 ] 

Davide Sottara edited comment on DROOLS-300 at 10/16/13 4:08 PM:
-----------------------------------------------------------------

Issue #1
The (non-existing) documentation states just one thing: our interval/expression Timers are compatible with java Timers. 
Java actually provides two modes: fixed-delay repetitions and fixed-rate repetitions.
What we have outlined here is fixed-rate, I suspect that what we had before is fixed-delay?
                
      was (Author: dsotty):
    Issue #1
The (non-existing) documentation states just one thing: our interval/expression Timers are compatible with java Timers. 
Java actually provides two modes: fixed-delay repetitions and fixed-rate repetitions.
What we have outlined here is fixed-rate, but we could have fixed-delay too. This might require another attribute, e.g. fixedRate (=true by default).
                  
> Add optional start and end arguments to timers
> ----------------------------------------------
>
>                 Key: DROOLS-300
>                 URL: https://issues.jboss.org/browse/DROOLS-300
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 16:11:01 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Wed, 16 Oct 2013 16:11:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-300) Add optional start and end
 arguments to timers
In-Reply-To: <JIRA.12503113.1381861876000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503113.1381861876000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503113.1381861876000.1752.1381954261961@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12815528#comment-12815528 ] 

Davide Sottara commented on DROOLS-300:
---------------------------------------

Issue #2
In our discussions, we have remarked that drools is not real-time, so the scheduled time is a lower bound for the actual activation: i.e., expect the rule to activate any time AFTER the scheduled time. Should we have an activation-specific deadline? 
E.g., activate with a period of 1 day, but cancel any activation that can't be fired within 1 hour since the activation. If you miss the 1hr-window, just skip and go for the next day
                
> Add optional start and end arguments to timers
> ----------------------------------------------
>
>                 Key: DROOLS-300
>                 URL: https://issues.jboss.org/browse/DROOLS-300
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 16:15:02 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Wed, 16 Oct 2013 16:15:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-300) Add optional start and end
 arguments to timers
In-Reply-To: <JIRA.12503113.1381861876000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503113.1381861876000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503113.1381861876000.1763.1381954502438@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12815529#comment-12815529 ] 

Davide Sottara commented on DROOLS-300:
---------------------------------------

Issue #3
Should the repetition counter be incremented even when activations can't be fired (e.g. because session is halted, serialized, rule is not in date effective range, etc...)?
I'd say no. Putting a limit to the theoretical count, given a start date, is an implicit way to define an end date, which is absolute and does not depend on halts. 
                
> Add optional start and end arguments to timers
> ----------------------------------------------
>
>                 Key: DROOLS-300
>                 URL: https://issues.jboss.org/browse/DROOLS-300
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 16:17:01 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Wed, 16 Oct 2013 16:17:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-300) Add optional start and end
 arguments to timers
In-Reply-To: <JIRA.12503113.1381861876000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503113.1381861876000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503113.1381861876000.1769.1381954621867@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12815530#comment-12815530 ] 

Davide Sottara commented on DROOLS-300:
---------------------------------------

Issue #4
Please make sure that the "old" behavior is just a special case of the "new" one. Things like 
if (newFlag) then newBehavior else oldBehavior 
will generate confusion in the future and make maintenance more difficult
                
> Add optional start and end arguments to timers
> ----------------------------------------------
>
>                 Key: DROOLS-300
>                 URL: https://issues.jboss.org/browse/DROOLS-300
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 16:21:02 2013
From: jira-events at lists.jboss.org (alexandre xypas (JIRA))
Date: Wed, 16 Oct 2013 16:21:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2276) URI ENCODING does not work in
 the beta1 version (UTF-8)
In-Reply-To: <JIRA.12502684.1381404449000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502684.1381404449000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502684.1381404449000.1779.1381954862236@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

alexandre xypas updated WFLY-2276:
----------------------------------

    Priority: Critical  (was: Major)

    
> URI ENCODING does not work in the beta1 version (UTF-8)
> -------------------------------------------------------
>
>                 Key: WFLY-2276
>                 URL: https://issues.jboss.org/browse/WFLY-2276
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (JBoss Web)
>    Affects Versions: 8.0.0.Beta1
>         Environment: Java 7, ubuntu 12.04
>            Reporter: alexandre xypas
>            Priority: Critical
>              Labels: encoding, utf-8
>
> In standalone.xml, the following is working in Alpha4, but not anymore in Beta1.
> <property name="org.apache.catalina.connector.URI_ENCODING" value="UTF-8"/>
> <property name="org.apache.catalina.connector.USE_BODY_ENCODING_FOR_QUERY_STRING" value="true"/>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 16:21:02 2013
From: jira-events at lists.jboss.org (alexandre xypas (JIRA))
Date: Wed, 16 Oct 2013 16:21:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2276) URI ENCODING does not work in
 the beta1 version (UTF-8)
In-Reply-To: <JIRA.12502684.1381404449000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502684.1381404449000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502684.1381404449000.1780.1381954862297@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

alexandre xypas updated WFLY-2276:
----------------------------------

    Priority: Major  (was: Critical)

    
> URI ENCODING does not work in the beta1 version (UTF-8)
> -------------------------------------------------------
>
>                 Key: WFLY-2276
>                 URL: https://issues.jboss.org/browse/WFLY-2276
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (JBoss Web)
>    Affects Versions: 8.0.0.Beta1
>         Environment: Java 7, ubuntu 12.04
>            Reporter: alexandre xypas
>              Labels: encoding, utf-8
>
> In standalone.xml, the following is working in Alpha4, but not anymore in Beta1.
> <property name="org.apache.catalina.connector.URI_ENCODING" value="UTF-8"/>
> <property name="org.apache.catalina.connector.USE_BODY_ENCODING_FOR_QUERY_STRING" value="true"/>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 16:23:03 2013
From: jira-events at lists.jboss.org (alexandre xypas (JIRA))
Date: Wed, 16 Oct 2013 16:23:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2276) URI ENCODING does not work in
 the beta1 version (UTF-8)
In-Reply-To: <JIRA.12502684.1381404449000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502684.1381404449000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502684.1381404449000.1785.1381954983428@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12815532#comment-12815532 ] 

alexandre xypas commented on WFLY-2276:
---------------------------------------

Most of the web server can enforce the encoding:

- Glassfish by using in glassfish-web.xml:
<glassfish-web-app>
    <parameter-encoding default-charset="UTF-8" />
</glassfish-web-app>

- Tomcat by using:
<connector .... URIEncoding="utf-8" />

- jboss 7.1
<property name="org.apache.catalina.connector.URI_ENCODING" value="UTF-8"/>
<property name="org.apache.catalina.connector.USE_BODY_ENCODING_FOR_QUERY_STRING" value="true"/>

Is there such a way in WildFly?
                
> URI ENCODING does not work in the beta1 version (UTF-8)
> -------------------------------------------------------
>
>                 Key: WFLY-2276
>                 URL: https://issues.jboss.org/browse/WFLY-2276
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (JBoss Web)
>    Affects Versions: 8.0.0.Beta1
>         Environment: Java 7, ubuntu 12.04
>            Reporter: alexandre xypas
>              Labels: encoding, utf-8
>
> In standalone.xml, the following is working in Alpha4, but not anymore in Beta1.
> <property name="org.apache.catalina.connector.URI_ENCODING" value="UTF-8"/>
> <property name="org.apache.catalina.connector.USE_BODY_ENCODING_FOR_QUERY_STRING" value="true"/>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 16:32:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 16 Oct 2013 16:32:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-179) CLONE - Adding modcluster via
 the CLI fails.
In-Reply-To: <JIRA.12472771.1345542489000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12472771.1345542489000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12472771.1345542489000.1810.1381955522804@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12815538#comment-12815538 ] 

RH Bugzilla Integration commented on WFLY-179:
----------------------------------------------

mark yarborough <myarboro at redhat.com> changed the Status of [bug 900801|https://bugzilla.redhat.com/show_bug.cgi?id=900801] from ASSIGNED to CLOSED
                
> CLONE - Adding modcluster via the CLI fails.
> --------------------------------------------
>
>                 Key: WFLY-179
>                 URL: https://issues.jboss.org/browse/WFLY-179
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI, Clustering
>            Reporter: Tom Fonteyne
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.Alpha1
>
>
> Adding modcluster via the CLI fails.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 16:32:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 16 Oct 2013 16:32:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-179) CLONE - Adding modcluster via
 the CLI fails.
In-Reply-To: <JIRA.12472771.1345542489000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12472771.1345542489000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12472771.1345542489000.1818.1381955523133@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12815539#comment-12815539 ] 

RH Bugzilla Integration commented on WFLY-179:
----------------------------------------------

mark yarborough <myarboro at redhat.com> changed the Status of [bug 900801|https://bugzilla.redhat.com/show_bug.cgi?id=900801] from ASSIGNED to CLOSED
                
> CLONE - Adding modcluster via the CLI fails.
> --------------------------------------------
>
>                 Key: WFLY-179
>                 URL: https://issues.jboss.org/browse/WFLY-179
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI, Clustering
>            Reporter: Tom Fonteyne
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.Alpha1
>
>
> Adding modcluster via the CLI fails.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 16:54:02 2013
From: jira-events at lists.jboss.org (Rich DiCroce (JIRA))
Date: Wed, 16 Oct 2013 16:54:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1718) Message corruption under
	heavy load
In-Reply-To: <JIRA.12503731.1381946713000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503731.1381946713000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503731.1381946713000.1839.1381956842047@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12815541#comment-12815541 ] 

Rich DiCroce commented on JGRP-1718:
------------------------------------

This is the protocol stack in use, from the JBoss config file:
{code:xml}
            <stack name="dispenser">
                <transport type="UDP" socket-binding="jgroups-udp-dispenser"/>
                <protocol type="PING"/>
                <protocol type="MERGE3"/>
                <protocol type="FD_SOCK" socket-binding="jgroups-udp-fd-dispenser"/>
                <protocol type="FD"/>
                <protocol type="VERIFY_SUSPECT"/>
                <protocol type="pbcast.NAKACK2"/>
                <protocol type="UNICAST2"/>
                <protocol type="SCOPE"/>
                <protocol type="pbcast.STABLE"/>
                <protocol type="pbcast.GMS"/>
                <protocol type="UFC"/>
                <protocol type="MFC"/>
                <protocol type="FRAG2"/>
                <protocol type="RSVP"/>
                <protocol type="pbcast.STATE"/>
                <protocol type="pbcast.FLUSH"/>
            </stack>
{code}

I tried disabling the top of the stack (commented out everything from UFC to FLUSH) to see if that made any difference. It did not.
                
> Message corruption under heavy load
> -----------------------------------
>
>                 Key: JGRP-1718
>                 URL: https://issues.jboss.org/browse/JGRP-1718
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.12
>         Environment: JBoss AS 7.2.0.Final (includes JGroups 3.2.7.Final, upgrading to 3.2.12.Final had no effect)
>            Reporter: Rich DiCroce
>            Assignee: Bela Ban
>
> In my project, I'm using the Kryo serialization library to serialize/deserialize objects to/from byte[]. Some of these byte arrays appear to be getting corrupted during transmission.
> The problem happens very infrequently and only under load. I have to send tens of thousands of messages from hundreds of threads just to get two or three errors. The exception occurs when Kryo tries to deserialize the byte[] on the receiving node. So far, all of the errors I've seen happen when Kryo tries to find a class to deserialize an object, and the stack traces end with something like:
> Caused by: java.lang.ClassNotFoundException: java.util.Date[SOH][GS]
> Note that the [SOH] and [GS] are not literally those strings, they're unprintable ASCII 0x1 and 0x1D.
> I'm confident that Kryo itself is not the source of the problem. I added some code to my project to deserialize the message on the sending node, immediately after serializing it, and log any exception thrown from the deserialization. The sending node did not log an exception, but the receiving node still did. My code passes the byte[] to the Message constructor without doing anything to it.
> It also appears that I am not the first person to encounter this issue. See https://code.google.com/p/kryo/issues/detail?id=102

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 18:11:01 2013
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Wed, 16 Oct 2013 18:11:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBASMP-53) Support --runtime-name for
 deployment on server groups
In-Reply-To: <JIRA.12503740.1381961447515@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503740.1381961447515@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503740.1381961447515.1860.1381961461952@jira02.app.mwc.hst.phx2.redhat.com>

James Perkins created JBASMP-53:
-----------------------------------

             Summary: Support --runtime-name for deployment on server groups
                 Key: JBASMP-53
                 URL: https://issues.jboss.org/browse/JBASMP-53
             Project: JBoss AS Maven Plugins
          Issue Type: Enhancement
            Reporter: James Perkins
            Assignee: James Perkins


The JBoss CLI provides a parameter called --runtime-name, which lets you set an additional runtime name for an deployment (complementing the already supported --name parameter).

It would be nice if the JBoss Maven plugin could add another configuration parameter for this.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 18:13:01 2013
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Wed, 16 Oct 2013 18:13:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBASMP-53) Support --runtime-name for
 deployment on server groups
In-Reply-To: <JIRA.12503740.1381961447000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503740.1381961447000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503740.1381961447000.1864.1381961581887@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBASMP-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins updated JBASMP-53:
--------------------------------

    Component/s: wildfly

    
> Support --runtime-name for deployment on server groups
> ------------------------------------------------------
>
>                 Key: JBASMP-53
>                 URL: https://issues.jboss.org/browse/JBASMP-53
>             Project: JBoss AS Maven Plugins
>          Issue Type: Enhancement
>          Components: wildfly
>            Reporter: James Perkins
>            Assignee: James Perkins
>
> The JBoss CLI provides a parameter called --runtime-name, which lets you set an additional runtime name for an deployment (complementing the already supported --name parameter).
> It would be nice if the JBoss Maven plugin could add another configuration parameter for this.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 20:13:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 16 Oct 2013 20:13:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1913) CLI 'module add' command fail
 if a drive letter is specified in its resource path
In-Reply-To: <JIRA.12499050.1377075768000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499050.1377075768000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499050.1377075768000.1917.1381968782875@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12815559#comment-12815559 ] 

RH Bugzilla Integration commented on WFLY-1913:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1014921|https://bugzilla.redhat.com/show_bug.cgi?id=1014921] from MODIFIED to ON_QA
                
> CLI 'module add' command fail if a drive letter is specified in its resource path
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-1913
>                 URL: https://issues.jboss.org/browse/WFLY-1913
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>             Fix For: 8.0.0.CR1
>
>         Attachments: install-mojarra-2.0.0.cli
>
>
> If a drive letter is specified in the resource path the module add command fails on MS Windows. It cannot locate such a resource because of doubled drive letter in the translated path.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 20:13:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 16 Oct 2013 20:13:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1569) Not possible to reload server
 when JTS transactions are activated
In-Reply-To: <JIRA.12494844.1371818256000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494844.1371818256000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494844.1371818256000.1921.1381968783152@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12815560#comment-12815560 ] 

RH Bugzilla Integration commented on WFLY-1569:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1011379|https://bugzilla.redhat.com/show_bug.cgi?id=1011379] from MODIFIED to ON_QA
                
> Not possible to reload server when JTS transactions are activated
> -----------------------------------------------------------------
>
>                 Key: WFLY-1569
>                 URL: https://issues.jboss.org/browse/WFLY-1569
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Ond?ej Chaloupka
>            Assignee: Stefano Maestri
>
> When transactions are set for JTS being used
>  - <jts/> tag under transactions subsystem
>  - transactions="on" under jacorb subsystem
> then it is not possible to reload the server.
> The reload causes the following exception being shown.
> {code}
> 14:30:56,388 WARN  [com.arjuna.ats.jts] (MSC service thread 1-5) ARJUNA022083: JacOrbRCServiceInit - Failed to start RC service: org.omg.CORBA.OBJECT_NOT_EXIST: POA destroyed
>  at org.jacorb.poa.POA.checkDestructionApparent(POA.java:1409)                           
>  at org.jacorb.poa.POA.set_servant(POA.java:1979)                          
>  at com.arjuna.ats.internal.jts.orbspecific.jacorb.recoverycoordinators.JacOrbRCServiceInit.startRCservice(JacOrbRCServiceInit.java:197) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]        
>  at com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement.startRCservice(RecoveryEnablement.java:137) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]        
>  at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:66) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]         
>  at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:104) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]              
>  at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:224) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]               
>  at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65) [narayana-jts-integration-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]            
>  at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:139) [wildfly-transactions-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]              
>  at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1942) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]                
>  at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1875) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]                  
>  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]                       
>  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]                       
>  at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]                       
> 14:30:56,396 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.txn.ArjunaRecoveryManager: org.jboss.msc.service.StartException in service jboss.txn.ArjunaRecoveryManager: JBAS010101: Recovery manager create failed                                 
>  at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:142)                      
>  at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1942) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]                
>  at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1875) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]                  
>  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]                       
>  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]                       
>  at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]                       
> Caused by: java.lang.RuntimeException: ARJUNA012364: RecoveryActivator init failed for com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement            
>  at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:67)                 
>  at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:104)                      
>  at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:224)                       
>  at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65)                  
>  at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:139)                      
>  ... 5 more 
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Wed Oct 16 20:13:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 16 Oct 2013 20:13:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2216) include-all role mappings
 don't work in domain
In-Reply-To: <JIRA.12502198.1380887272000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502198.1380887272000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502198.1380887272000.1927.1381968783556@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12815562#comment-12815562 ] 

RH Bugzilla Integration commented on WFLY-2216:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1015493|https://bugzilla.redhat.com/show_bug.cgi?id=1015493] from MODIFIED to ON_QA
                
> include-all role mappings don't work in domain
> ----------------------------------------------
>
>                 Key: WFLY-2216
>                 URL: https://issues.jboss.org/browse/WFLY-2216
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Ladislav Thon
>            Assignee: Darran Lofthouse
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.CR1
>
>
> If I understand correctly, roles that have {{include-all=true}} in their role mappings should be added to all authenticated users. In my tests, though, this only works in standalone mode.
> In domain mode, if I set a role mapping to {{include-all}}, this setting is not reflected (at least not immediately; maybe it would work after restart, but that's wrong anyway). It doesn't matter which role is set to be {{include-all}} -- in my tests, I use both standard roles and scoped roles and it consistently doesn't work. There's probably some wrong caching going on.
> The failing test case is in my pull request https://github.com/wildfly/wildfly/pull/5166 (it's the _RBAC tests for include-all role mappings in domain_ commit). If it's more convenient, the pull request is the same as my _rbac_ branch (https://github.com/Ladicek/wildfly/commits/rbac).
> Darran, I'm not sure if you are the right assignee -- please reassign if needed. Thanks.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 20:13:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 16 Oct 2013 20:13:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-78) Intermittent failures in
	RespawnTestCase
In-Reply-To: <JIRA.12483133.1358904844000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12483133.1358904844000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12483133.1358904844000.1932.1381968783961@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12815563#comment-12815563 ] 

RH Bugzilla Integration commented on WFLY-78:
---------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1012809|https://bugzilla.redhat.com/show_bug.cgi?id=1012809] from MODIFIED to ON_QA
                
> Intermittent failures in RespawnTestCase
> ----------------------------------------
>
>                 Key: WFLY-78
>                 URL: https://issues.jboss.org/browse/WFLY-78
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.Alpha1
>
>
> Problems like [1] still pop up fairly frequently. It seems the same 3 tests fail.
> Failed tests:   testReloadHcButNotServers(org.jboss.as.test.integration.respawn.RespawnTestCase)
> testReloadHcButNotServersWithFailedServer(org.jboss.as.test.integration.respawn.RespawnTestCase)  testHCReloadAbortPreservesServers(org.jboss.as.test.integration.respawn.RespawnTestCase)
> [1] http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-master-ignore/327/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 20:13:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 16 Oct 2013 20:13:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2057)
 org.jboss.as.server.deployment.RegisteredDeploymentUnitProcessor has
 unstable compareTo()
In-Reply-To: <JIRA.12500645.1379015464000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500645.1379015464000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500645.1379015464000.1940.1381968784528@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12815564#comment-12815564 ] 

RH Bugzilla Integration commented on WFLY-2057:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1013470|https://bugzilla.redhat.com/show_bug.cgi?id=1013470] from MODIFIED to ON_QA
                
> org.jboss.as.server.deployment.RegisteredDeploymentUnitProcessor has unstable compareTo()
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-2057
>                 URL: https://issues.jboss.org/browse/WFLY-2057
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>            Reporter: David Lloyd
>            Assignee: Stuart Douglas
>            Priority: Blocker
>             Fix For: 8.0.0.Beta1
>
>
> As the description says, org.jboss.as.server.deployment.RegisteredDeploymentUnitProcessor's compareTo is wrong.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 20:13:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 16 Oct 2013 20:13:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1487) Unable to read nested
 resource in WAR archive
In-Reply-To: <JIRA.12493917.1370849764000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493917.1370849764000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493917.1370849764000.1943.1381968784728@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12815565#comment-12815565 ] 

RH Bugzilla Integration commented on WFLY-1487:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1017282|https://bugzilla.redhat.com/show_bug.cgi?id=1017282] from MODIFIED to ON_QA
                
> Unable to read nested resource in WAR archive
> ---------------------------------------------
>
>                 Key: WFLY-1487
>                 URL: https://issues.jboss.org/browse/WFLY-1487
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (JBoss Web), Web (Undertow)
>            Reporter: Radim Hatlapatka
>            Assignee: David Lloyd
>             Fix For: 8.0.0.Alpha2
>
>
> Unable to retrieve resources which are nested in additional directory in META-INF. The same works for JAR, only for WAR archive it doesn't.
> Example:
> If in WAR archive I have a resource in META-INF/properties/nested.properties, I am unable to access it using
> {code}
> classLoader.getResource("META-INF/properties/nested.properties");
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 20:13:05 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 16 Oct 2013 20:13:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2173) Get subsystem test framework
 working with AS 7.2.0 legacy controller
In-Reply-To: <JIRA.12501755.1380296954000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501755.1380296954000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501755.1380296954000.1947.1381968785021@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12815566#comment-12815566 ] 

RH Bugzilla Integration commented on WFLY-2173:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1015245|https://bugzilla.redhat.com/show_bug.cgi?id=1015245] from MODIFIED to ON_QA
                
> Get subsystem test framework working with AS 7.2.0 legacy controller
> --------------------------------------------------------------------
>
>                 Key: WFLY-2173
>                 URL: https://issues.jboss.org/browse/WFLY-2173
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 20:13:05 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 16 Oct 2013 20:13:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2185) Get core model test framework
 working with 7.2.0.Final legacy controller
In-Reply-To: <JIRA.12501848.1380553676000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501848.1380553676000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501848.1380553676000.1950.1381968785260@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12815567#comment-12815567 ] 

RH Bugzilla Integration commented on WFLY-2185:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1015245|https://bugzilla.redhat.com/show_bug.cgi?id=1015245] from MODIFIED to ON_QA
                
> Get core model test framework working with 7.2.0.Final legacy controller
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2185
>                 URL: https://issues.jboss.org/browse/WFLY-2185
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 20:13:05 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 16 Oct 2013 20:13:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2220) Unable to reload server after
 adding role and executing :reload
In-Reply-To: <JIRA.12502221.1380896422000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502221.1380896422000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502221.1380896422000.1954.1381968785504@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12815568#comment-12815568 ] 

RH Bugzilla Integration commented on WFLY-2220:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1015585|https://bugzilla.redhat.com/show_bug.cgi?id=1015585] from MODIFIED to ON_QA
                
> Unable to reload server after adding role and executing :reload
> ---------------------------------------------------------------
>
>                 Key: WFLY-2220
>                 URL: https://issues.jboss.org/browse/WFLY-2220
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.CR1
>
>
> Start a clean build of WildFly 8 and execute the following commands in the CLI: -
> {code}
> [standalone at localhost:9990 /connect
> [standalone at localhost:9990 /] ./core-service=management/access=authorization/role-mapping=Operator:add
> {"outcome" => "success"}
> [standalone at localhost:9990 /] :reload
> {
>     "outcome" => "success",
>     "result" => undefined
> }
> [standalone at localhost:9990 /] 
> {code}
> Results in the following error and the server shuts down: -
> {code}
> 15:15:02,275 INFO  [org.jboss.as.server] (Controller Boot Thread) JBAS015888: Creating http management service using socket-binding (management-http)
> 15:15:02,278 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014612: Operation ("add") failed - address: ([
>     ("core-service" => "management"),
>     ("access" => "authorization"),
>     ("role-mapping" => "SuperUser")
> ]): java.lang.UnsupportedOperationException
> 	at java.util.Collections$UnmodifiableMap.put(Collections.java:1342) [rt.jar:1.7.0_17]
> 	at org.jboss.as.controller.access.management.WritableAuthorizerConfiguration.addRoleMappingImmediate(WritableAuthorizerConfiguration.java:163) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.domain.management.access.RoleMappingAdd$1.execute(RoleMappingAdd.java:76) [wildfly-domain-management-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:609) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:487) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:321) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:290) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:356) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:331) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:252) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> 15:15:02,287 INFO  [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.remoting.endpoint.management (missing) dependents: [service jboss.remoting.management.channel.registry] 
> 15:15:02,290 FATAL [org.jboss.as.server] (Controller Boot Thread) JBAS015957: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> 15:15:02,297 INFO  [org.jboss.as] (MSC service thread 1-1) JBAS015950: WildFly 8.0.0.Beta1-SNAPSHOT "WildFly" stopped in 2ms
> {code}
> What is interesting is that the server is manually startable to something has gone wrong regarding resetting the runtime state of RBAC at the time of the reload.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 20:15:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 16 Oct 2013 20:15:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2271) A problem setting include-all
 on a role mapping is failing getting rolled back.
In-Reply-To: <JIRA.12502544.1381316379000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502544.1381316379000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502544.1381316379000.1958.1381968902997@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12815570#comment-12815570 ] 

RH Bugzilla Integration commented on WFLY-2271:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1017199|https://bugzilla.redhat.com/show_bug.cgi?id=1017199] from MODIFIED to ON_QA
                
> A problem setting include-all on a role mapping is failing getting rolled back.
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-2271
>                 URL: https://issues.jboss.org/browse/WFLY-2271
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> As a side effect of another bug the following failure occurs: -
> {code}
> [domain at localhost:9990 /] ./core-service=management/access=authorization/role-mapping=test:add
> {
>     "outcome" => "success",
>     "result" => undefined,
>     "server-groups" => {"main-server-group" => {"host" => {"master" => {
>         "server-one" => {"response" => {"outcome" => "success"}},
>         "server-two" => {"response" => {"outcome" => "success"}}
>     }}}}
> }
> [domain at localhost:9990 /] ./core-service=management/access=authorization/role-mapping=test:write-attribute(name=include-all, value=true)
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "JBAS014749: Operation handler failed: JBAS013470: Unknown role 'TEST'"},
>     "rolled-back" => true
> }
> {code}
> Roll back however fails with this error: -
> {code}
> [Host Controller] 11:47:25,216 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 11) JBAS014603:  caught exception attempting to revert operation write-attribute at address [
> [Host Controller]     ("core-service" => "management"),
> [Host Controller]     ("access" => "authorization"),
> [Host Controller]     ("role-mapping" => "test")
> [Host Controller] ]: java.lang.IllegalArgumentException
> [Host Controller] 	at org.jboss.dmr.ModelValue.asBoolean(ModelValue.java:66) [jboss-dmr-1.2.0.Final.jar:1.2.0.Final]
> [Host Controller] 	at org.jboss.dmr.ModelNode.asBoolean(ModelNode.java:262) [jboss-dmr-1.2.0.Final.jar:1.2.0.Final]
> [Host Controller] 	at org.jboss.as.domain.management.access.RoleIncludeAllWriteAttributeHander.revertUpdateToRuntime(RoleIncludeAllWriteAttributeHander.java:65)
> [Host Controller] 	at org.jboss.as.domain.management.access.RoleIncludeAllWriteAttributeHander.revertUpdateToRuntime(RoleIncludeAllWriteAttributeHander.java:35)
> {code}
> Two issues here: -
> 1 - "rolled-back" should not be true as it failed.
> 2 - The failure during rollback needs to be fixed, the default for this attribute if not set is 'false'.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 20:15:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 16 Oct 2013 20:15:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2268) Add Generic JMS RA
In-Reply-To: <JIRA.12502537.1381312737000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502537.1381312737000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502537.1381312737000.1961.1381968903152@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12815571#comment-12815571 ] 

RH Bugzilla Integration commented on WFLY-2268:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1016762|https://bugzilla.redhat.com/show_bug.cgi?id=1016762] from MODIFIED to ON_QA
                
> Add Generic JMS RA
> ------------------
>
>                 Key: WFLY-2268
>                 URL: https://issues.jboss.org/browse/WFLY-2268
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JCA, JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.CR1
>
>
> WildFly could integrate the Generic JMS RA[1] to be able to use JMS brokers that does not provide a resource adapter.
> [1] https://github.com/jms-ra/generic-jms-ra

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 20:15:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 16 Oct 2013 20:15:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1756) Add access-control parameter
 to read-operation-description operation
In-Reply-To: <JIRA.12497280.1374684426000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497280.1374684426000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497280.1374684426000.1965.1381968903357@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12815572#comment-12815572 ] 

RH Bugzilla Integration commented on WFLY-1756:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1013056|https://bugzilla.redhat.com/show_bug.cgi?id=1013056] from MODIFIED to ON_QA
                
> Add access-control parameter to read-operation-description operation
> --------------------------------------------------------------------
>
>                 Key: WFLY-1756
>                 URL: https://issues.jboss.org/browse/WFLY-1756
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Beta1
>
>
> Similar to read-resource-description

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 20:15:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 16 Oct 2013 20:15:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2131) read-operation-names to
 return a filtered list of allowed operations
In-Reply-To: <JIRA.12501207.1379945777000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501207.1379945777000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501207.1379945777000.1969.1381968903608@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12815573#comment-12815573 ] 

RH Bugzilla Integration commented on WFLY-2131:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1013056|https://bugzilla.redhat.com/show_bug.cgi?id=1013056] from MODIFIED to ON_QA
                
> read-operation-names to return a filtered list of allowed operations
> --------------------------------------------------------------------
>
>                 Key: WFLY-2131
>                 URL: https://issues.jboss.org/browse/WFLY-2131
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Alexey Loubyansky
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Beta1
>
>
> As discussed on IRC with Kabir, Heiko and me, we agreed that read-operation-names should return only the operations the caller is permitted to execute.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 20:15:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 16 Oct 2013 20:15:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1341) Missing charset-related paths
	from sun.jdk
In-Reply-To: <JIRA.12491807.1368584295000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12491807.1368584295000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12491807.1368584295000.1979.1381968904414@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12815577#comment-12815577 ] 

RH Bugzilla Integration commented on WFLY-1341:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 959478|https://bugzilla.redhat.com/show_bug.cgi?id=959478] from MODIFIED to ON_QA
                
> Missing charset-related paths from sun.jdk
> ------------------------------------------
>
>                 Key: WFLY-1341
>                 URL: https://issues.jboss.org/browse/WFLY-1341
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Brad Maxwell
>            Assignee: David Lloyd
>             Fix For: 8.0.0.Alpha1
>
>
> The sun.jdk module needs the sun.nio.ext and sun.nio.cs packages to load charsets from application code properly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 20:15:05 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 16 Oct 2013 20:15:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2182) Significant slow down of
 testsuite execution
In-Reply-To: <JIRA.12501817.1380538653000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501817.1380538653000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501817.1380538653000.1987.1381968905275@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12815580#comment-12815580 ] 

RH Bugzilla Integration commented on WFLY-2182:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1013698|https://bugzilla.redhat.com/show_bug.cgi?id=1013698] from MODIFIED to ON_QA
                
> Significant slow down of testsuite execution
> --------------------------------------------
>
>                 Key: WFLY-2182
>                 URL: https://issues.jboss.org/browse/WFLY-2182
>             Project: WildFly
>          Issue Type: Bug
>          Components: Remoting
>            Reporter: Jozef Hartinger
>            Assignee: Kabir Khan
>
> I am observing a significant slow down when running the Weld integration testsuite. I tracked this down to this commit:
> https://github.com/wildfly/wildfly/commit/13f09525717a089f8a524d086fd865798410f368
> Here are the observed execution times of the Weld integration testsuite:
> Before: Total time: 4:30.357s
> After: Total time: 11:05.547s
> I also tried running the WildFly's integration testsuite (testsuite/integration/basic) with and without the 13f09525717a089f8a524d086fd865798410f368 commit:
> Before: Total time: 13:04.412s
> After: Total time: 21:33.089s
> Note that the difference is not observed when using the arquillian servlet protocol

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 16 21:46:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 16 Oct 2013 21:46:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2305) add-user utility reports "No
 java.io.Console available to interact with user." when used silently with
 su and piped to a file.
In-Reply-To: <JIRA.12503071.1381836778000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503071.1381836778000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503071.1381836778000.2055.1381974362033@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12815596#comment-12815596 ] 

RH Bugzilla Integration commented on WFLY-2305:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1019264|https://bugzilla.redhat.com/show_bug.cgi?id=1019264] from POST to MODIFIED
                
> add-user utility reports "No java.io.Console available to interact with user." when used silently with su and piped to a file.
> ------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2305
>                 URL: https://issues.jboss.org/browse/WFLY-2305
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, Security
>    Affects Versions: 8.0.0.Beta1
>         Environment: WildFly snapshot of master 15-oct-2013
>            Reporter: Tom Fonteyne
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Running add-user.sh in silent mode and redirecting the output to a file results in an exception:
> Exception in thread "main" java.lang.IllegalStateException: JBAS015232: No java.io.Console available to interact with user.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 02:22:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 17 Oct 2013 02:22:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2317) Trying to remove a server
 group as a server-group-scoped role leaks information
In-Reply-To: <JIRA.12503235.1381924172000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503235.1381924172000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503235.1381924172000.2182.1381990922109@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12815613#comment-12815613 ] 

RH Bugzilla Integration commented on WFLY-2317:
-----------------------------------------------

Ladislav Thon <lthon at redhat.com> made a comment on [bug 1019784|https://bugzilla.redhat.com/show_bug.cgi?id=1019784]

If this is not supposed to hide sensitive data (which I believed is the case), then I'm lowering the severity to medium. Still, :read-resource and :remove on a non-addressable resource should give the same answer.
                
> Trying to remove a server group as a server-group-scoped role leaks information
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-2317
>                 URL: https://issues.jboss.org/browse/WFLY-2317
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Brian Stansberry
>              Labels: rbac-filed-by-qa
>
> When writing a small test case for WFLY-2190, I stumbled upon a problem: trying to remove an existing server group by a server-group-scoped user that does NOT have permissions to that server group leaks information. On a freshly built WildFly with added {{admin}} user into {{domain/configuration/mgmt-users.properties}}, it can be reproduced like this:
> {code}
> [1] ./bin/domain.sh
> [2] ./bin/jboss-cli.sh -c
>     /core-service=management/access=authorization/server-group-scoped-role=NewRole:add(base-role=administrator, server-groups=[main-server-group])
>     /core-service=management/access=authorization/role-mapping=NewRole:add
>     /core-service=management/access=authorization/role-mapping=NewRole/include=user-admin:add(name=admin, type=user)
>     /core-service=management/access=authorization:write-attribute(name=provider, value=rbac)
>     exit
> [1] ^C
>     ./bin/domain.sh
> [2] ./bin/jboss-cli.sh -c --user=admin --password=XXX
>     /server-group=other-server-group:read-resource
>     /server-group=other-server-group:remove
> {code}
> What does that mean? The {{NewRole}} is scoped to the {{main-server-group}} server group and can't see {{other-server-group}}. When doing {{/server-group=other-server-group:read-resource}}, this is correctly enforced and the output looks like this:
> {code}
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014807: Management resource '[(\"server-group\" => \"other-server-group\")]' not found",
>     "rolled-back" => true
> }
> {code}
> However, trying to do {{/server-group=other-server-group:remove}}, which is only a different operation _on the same resource_, I get a different error message:
> {code}
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "JBAS013456: Unauthorized to execute operation 'remove' for resource '[(\"server-group\" => \"other-server-group\")]' -- \"JBAS013475: Permission denied\""},
>     "rolled-back" => true
> }
> {code}
> I expect the error message to be completely the same as in previous case, not leaking any information that the {{other-server-group}} actually exists.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 02:32:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 17 Oct 2013 02:32:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2317) Trying to remove a server
 group as a server-group-scoped role leaks information
In-Reply-To: <JIRA.12503235.1381924172000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503235.1381924172000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503235.1381924172000.2191.1381991522046@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12815616#comment-12815616 ] 

RH Bugzilla Integration commented on WFLY-2317:
-----------------------------------------------

Ladislav Thon <lthon at redhat.com> made a comment on [bug 1019784|https://bugzilla.redhat.com/show_bug.cgi?id=1019784]

One more thing -- if we have these resources non-addressable now and we'll try to make them addressable & non-readable in the future, that might be considered a regression by some customers. I'm not sure what my feelings about that would be.
                
> Trying to remove a server group as a server-group-scoped role leaks information
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-2317
>                 URL: https://issues.jboss.org/browse/WFLY-2317
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Brian Stansberry
>              Labels: rbac-filed-by-qa
>
> When writing a small test case for WFLY-2190, I stumbled upon a problem: trying to remove an existing server group by a server-group-scoped user that does NOT have permissions to that server group leaks information. On a freshly built WildFly with added {{admin}} user into {{domain/configuration/mgmt-users.properties}}, it can be reproduced like this:
> {code}
> [1] ./bin/domain.sh
> [2] ./bin/jboss-cli.sh -c
>     /core-service=management/access=authorization/server-group-scoped-role=NewRole:add(base-role=administrator, server-groups=[main-server-group])
>     /core-service=management/access=authorization/role-mapping=NewRole:add
>     /core-service=management/access=authorization/role-mapping=NewRole/include=user-admin:add(name=admin, type=user)
>     /core-service=management/access=authorization:write-attribute(name=provider, value=rbac)
>     exit
> [1] ^C
>     ./bin/domain.sh
> [2] ./bin/jboss-cli.sh -c --user=admin --password=XXX
>     /server-group=other-server-group:read-resource
>     /server-group=other-server-group:remove
> {code}
> What does that mean? The {{NewRole}} is scoped to the {{main-server-group}} server group and can't see {{other-server-group}}. When doing {{/server-group=other-server-group:read-resource}}, this is correctly enforced and the output looks like this:
> {code}
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014807: Management resource '[(\"server-group\" => \"other-server-group\")]' not found",
>     "rolled-back" => true
> }
> {code}
> However, trying to do {{/server-group=other-server-group:remove}}, which is only a different operation _on the same resource_, I get a different error message:
> {code}
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "JBAS013456: Unauthorized to execute operation 'remove' for resource '[(\"server-group\" => \"other-server-group\")]' -- \"JBAS013475: Permission denied\""},
>     "rolled-back" => true
> }
> {code}
> I expect the error message to be completely the same as in previous case, not leaking any information that the {{other-server-group}} actually exists.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 02:55:01 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Thu, 17 Oct 2013 02:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-301) NPE when a trait's soft
 field has index 32 or more
In-Reply-To: <JIRA.12503808.1381992872156@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503808.1381992872156@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503808.1381992872156.2223.1381992901952@jira02.app.mwc.hst.phx2.redhat.com>

Davide Sottara created DROOLS-301:
-------------------------------------

             Summary: NPE when a trait's soft field has index 32 or more
                 Key: DROOLS-301
                 URL: https://issues.jboss.org/browse/DROOLS-301
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 6.0.0.CR5, 5.5.0.Final
            Reporter: Davide Sottara
            Assignee: Davide Sottara
             Fix For: 5.5.1.Final, 6.0.0.Final


Create a trait with more than 32 fields
Make sure that any field beyond the 32nd is a "soft" field when donning a core object: and NPE will be thrown

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 03:08:02 2013
From: jira-events at lists.jboss.org (Ramil Israfilov (JIRA))
Date: Thu, 17 Oct 2013 03:08:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-880) jboss-cli.sh show deployment
 status is FAILED but application running well
In-Reply-To: <JIRA.12482906.1358749732000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12482906.1358749732000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12482906.1358749732000.2232.1381993682076@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12816233#comment-12816233 ] 

Ramil Israfilov commented on WFLY-880:
--------------------------------------

we have same behaviour with jboss EAP 6.1.1 (which is 7.2.1.Final I suppose)
                
> jboss-cli.sh show deployment status is FAILED but application running well
> --------------------------------------------------------------------------
>
>                 Key: WFLY-880
>                 URL: https://issues.jboss.org/browse/WFLY-880
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>         Environment: suse linux 11 sp2
>            Reporter: jing chen
>            Assignee: Alexey Loubyansky
>              Labels: jboss
>
> run jboss-cli.sh to check the deployment status and it shows FAILED.
> NDO-2120:/opt/jboss/bin # /opt/jboss/bin/jboss-cli.sh --connect command="/deployment=nsm.ear:read-attribute(name=status)"
> {
>     "outcome" => "success",
>     "result" => "FAILED"
> }
> nsm.ear is our application. But our application runs well and can be login successfully using client and executing operations are succeed. please help what is problem. what should i do to check the problem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 03:16:03 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 17 Oct 2013 03:16:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2324) Deployment overlays do not
 replace JSP files
In-Reply-To: <JIRA.12504081.1381994090316@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12504081.1381994090316@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12504081.1381994090316.2264.1381994163051@jira02.app.mwc.hst.phx2.redhat.com>

Stuart Douglas created WFLY-2324:
------------------------------------

             Summary: Deployment overlays do not replace JSP files
                 Key: WFLY-2324
                 URL: https://issues.jboss.org/browse/WFLY-2324
             Project: WildFly
          Issue Type: Bug
          Components: Server
    Affects Versions: 8.0.0.Beta1
            Reporter: Stuart Douglas
            Assignee: Stuart Douglas
             Fix For: 8.0.0.CR1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 03:18:02 2013
From: jira-events at lists.jboss.org (Ramil Israfilov (JIRA))
Date: Thu, 17 Oct 2013 03:18:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-880) jboss-cli.sh show deployment
 status is FAILED but application running well
In-Reply-To: <JIRA.12482906.1358749732000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12482906.1358749732000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12482906.1358749732000.2269.1381994282018@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12816233#comment-12816233 ] 

Ramil Israfilov edited comment on WFLY-880 at 10/17/13 3:16 AM:
----------------------------------------------------------------

we have same behaviour with jboss EAP 6.1.1 (which is 7.2.1.Final I suppose).
we use jboss-cli.sh --command=deployment-info
we deploy 3 apps on JBOSS: one ear and 2 war files.
We use that command to check status of our deployment during jboss startup (we have a wrapper python script which invokes jboss cli periodically during jboss startup).

Most time it works correctly, but if you do multiple stop/starts of jboss jboss cli can report deployment failure of one of apps (it is random, so not specific for any deployed war or ear).

but all apps are deployed correctly and we can work with them


                
      was (Author: ramazanyich2):
    we have same behaviour with jboss EAP 6.1.1 (which is 7.2.1.Final I suppose)
                  
> jboss-cli.sh show deployment status is FAILED but application running well
> --------------------------------------------------------------------------
>
>                 Key: WFLY-880
>                 URL: https://issues.jboss.org/browse/WFLY-880
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>         Environment: suse linux 11 sp2
>            Reporter: jing chen
>            Assignee: Alexey Loubyansky
>              Labels: jboss
>
> run jboss-cli.sh to check the deployment status and it shows FAILED.
> NDO-2120:/opt/jboss/bin # /opt/jboss/bin/jboss-cli.sh --connect command="/deployment=nsm.ear:read-attribute(name=status)"
> {
>     "outcome" => "success",
>     "result" => "FAILED"
> }
> nsm.ear is our application. But our application runs well and can be login successfully using client and executing operations are succeed. please help what is problem. what should i do to check the problem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 03:20:02 2013
From: jira-events at lists.jboss.org (Ramil Israfilov (JIRA))
Date: Thu, 17 Oct 2013 03:20:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-880) jboss-cli.sh show deployment
 status is FAILED but application running well
In-Reply-To: <JIRA.12482906.1358749732000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12482906.1358749732000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12482906.1358749732000.2274.1381994402158@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12816233#comment-12816233 ] 

Ramil Israfilov edited comment on WFLY-880 at 10/17/13 3:19 AM:
----------------------------------------------------------------

we have same behaviour with jboss EAP 6.1.1 (which is 7.2.1.Final I suppose).
we use jboss-cli.sh --command=deployment-info
we deploy 3 apps on JBOSS: one ear and 2 war files.
We use that command to check status of our deployment during jboss startup (we have a wrapper python script which invokes jboss cli periodically during jboss startup).

Most time it works correctly, but if you do multiple stop/starts of jboss jboss cli can report deployment failure of one of apps (it is random, so not specific for any deployed war or ear).

but all apps are deployed correctly and we can work with them

we are running on CentOS 5.5

                
      was (Author: ramazanyich2):
    we have same behaviour with jboss EAP 6.1.1 (which is 7.2.1.Final I suppose).
we use jboss-cli.sh --command=deployment-info
we deploy 3 apps on JBOSS: one ear and 2 war files.
We use that command to check status of our deployment during jboss startup (we have a wrapper python script which invokes jboss cli periodically during jboss startup).

Most time it works correctly, but if you do multiple stop/starts of jboss jboss cli can report deployment failure of one of apps (it is random, so not specific for any deployed war or ear).

but all apps are deployed correctly and we can work with them


                  
> jboss-cli.sh show deployment status is FAILED but application running well
> --------------------------------------------------------------------------
>
>                 Key: WFLY-880
>                 URL: https://issues.jboss.org/browse/WFLY-880
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>         Environment: suse linux 11 sp2
>            Reporter: jing chen
>            Assignee: Alexey Loubyansky
>              Labels: jboss
>
> run jboss-cli.sh to check the deployment status and it shows FAILED.
> NDO-2120:/opt/jboss/bin # /opt/jboss/bin/jboss-cli.sh --connect command="/deployment=nsm.ear:read-attribute(name=status)"
> {
>     "outcome" => "success",
>     "result" => "FAILED"
> }
> nsm.ear is our application. But our application runs well and can be login successfully using client and executing operations are succeed. please help what is problem. what should i do to check the problem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 03:20:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 17 Oct 2013 03:20:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2303) mod_cluster XSD is missing
 property and worker-timeout definitions
In-Reply-To: <JIRA.12503065.1381830758000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503065.1381830758000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503065.1381830758000.2276.1381994402253@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2303:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1020142

    
> mod_cluster XSD is missing property and worker-timeout definitions
> ------------------------------------------------------------------
>
>                 Key: WFLY-2303
>                 URL: https://issues.jboss.org/browse/WFLY-2303
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.CR1
>
>
> * worker-timeout
> * property
> are missing.
> Also missing in 7.x

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 03:20:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 17 Oct 2013 03:20:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2303) mod_cluster XSD is missing
 property and worker-timeout definitions
In-Reply-To: <JIRA.12503065.1381830758000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503065.1381830758000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503065.1381830758000.2280.1381994402411@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12816278#comment-12816278 ] 

RH Bugzilla Integration commented on WFLY-2303:
-----------------------------------------------

Jay SenSharma <jsenshar at redhat.com> made a comment on [bug 1020142|https://bugzilla.redhat.com/show_bug.cgi?id=1020142]

Upstream Wildfly also has issue reported:
https://issues.jboss.org/browse/WFLY-2303
                
> mod_cluster XSD is missing property and worker-timeout definitions
> ------------------------------------------------------------------
>
>                 Key: WFLY-2303
>                 URL: https://issues.jboss.org/browse/WFLY-2303
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.CR1
>
>
> * worker-timeout
> * property
> are missing.
> Also missing in 7.x

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 03:22:02 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 17 Oct 2013 03:22:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-880) jboss-cli.sh show deployment
 status is FAILED but application running well
In-Reply-To: <JIRA.12482906.1358749732000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12482906.1358749732000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12482906.1358749732000.2284.1381994522110@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12816279#comment-12816279 ] 

Tomaz Cerar commented on WFLY-880:
----------------------------------

Do you see proper result if you call bit lower level command like this
{code}
/deployment=*:read-resource
{code}

is output of this correct?
                
> jboss-cli.sh show deployment status is FAILED but application running well
> --------------------------------------------------------------------------
>
>                 Key: WFLY-880
>                 URL: https://issues.jboss.org/browse/WFLY-880
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>         Environment: suse linux 11 sp2
>            Reporter: jing chen
>            Assignee: Alexey Loubyansky
>              Labels: jboss
>
> run jboss-cli.sh to check the deployment status and it shows FAILED.
> NDO-2120:/opt/jboss/bin # /opt/jboss/bin/jboss-cli.sh --connect command="/deployment=nsm.ear:read-attribute(name=status)"
> {
>     "outcome" => "success",
>     "result" => "FAILED"
> }
> nsm.ear is our application. But our application runs well and can be login successfully using client and executing operations are succeed. please help what is problem. what should i do to check the problem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 03:26:02 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Thu, 17 Oct 2013 03:26:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-302) MVEL throws an NPE when
 evaluating dynamic salience
In-Reply-To: <JIRA.12504107.1381994724710@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12504107.1381994724710@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12504107.1381994724710.2301.1381994762177@jira02.app.mwc.hst.phx2.redhat.com>

Davide Sottara created DROOLS-302:
-------------------------------------

             Summary: MVEL throws an NPE when evaluating dynamic salience
                 Key: DROOLS-302
                 URL: https://issues.jboss.org/browse/DROOLS-302
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 6.0.0.CR5, 5.5.0.Final
            Reporter: Davide Sottara
            Assignee: Mark Proctor


Reported by Wolfgang on the user list
Reproducer : 

rule "process Token"
salience  - $prio   // by ascending x25No values
when
    $token: Token( $x25No: x25No )  //  match on int x25No
    $elem: ElemType( $prio: x25No == $x25No )
then
    retract($token);
end


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 03:31:01 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 17 Oct 2013 03:31:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2303) mod_cluster XSD is missing
 property and worker-timeout definitions
In-Reply-To: <JIRA.12503065.1381830758000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503065.1381830758000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503065.1381830758000.2305.1381995061948@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12816291#comment-12816291 ] 

RH Bugzilla Integration commented on WFLY-2303:
-----------------------------------------------

Michal Babacek <mbabacek at redhat.com> made a comment on [bug 1020142|https://bugzilla.redhat.com/show_bug.cgi?id=1020142]

No Jay, mod_cluster as such has virtually nothing to do with Clustering component.
                
> mod_cluster XSD is missing property and worker-timeout definitions
> ------------------------------------------------------------------
>
>                 Key: WFLY-2303
>                 URL: https://issues.jboss.org/browse/WFLY-2303
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.CR1
>
>
> * worker-timeout
> * property
> are missing.
> Also missing in 7.x

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 03:33:02 2013
From: jira-events at lists.jboss.org (Ramil Israfilov (JIRA))
Date: Thu, 17 Oct 2013 03:33:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-880) jboss-cli.sh show deployment
 status is FAILED but application running well
In-Reply-To: <JIRA.12482906.1358749732000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12482906.1358749732000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12482906.1358749732000.2314.1381995182471@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12816293#comment-12816293 ] 

Ramil Israfilov commented on WFLY-880:
--------------------------------------

ok, just reproduced an error and here is output from two commands:
{code}
[standalone at 127.0.0.1:10199 /] deployment-info
NAME             RUNTIME-NAME     PERSISTENT ENABLED STATUS 
hs20.war         hs20.war         false      true    OK     
mdm-ear.ear      mdm-ear.ear      false      true    FAILED 
oma-dlserver.war oma-dlserver.war false      true    OK     
[standalone at 127.0.0.1:10199 /] 
{code}

and if I execute  command suggested by yout I got:
{code}
[standalone at 127.0.0.1:10199 /] /deployment=*:read-resource
{
    "outcome" => "success",
    "result" => [
        {
            "address" => [("deployment" => "oma-dlserver.war")],
            "outcome" => "success",
            "result" => {
                "content" => [{
                    "path" => "deployments/oma-dlserver.war",
                    "relative-to" => "jboss.server.base.dir",
                    "archive" => true
                }],
                "enabled" => true,
                "name" => "oma-dlserver.war",
                "persistent" => false,
                "runtime-name" => "oma-dlserver.war",
                "subdeployment" => undefined,
                "subsystem" => {
                    "webservices" => undefined,
                    "web" => undefined
                }
            }
        },
        {
            "address" => [("deployment" => "mdm-ear.ear")],
            "outcome" => "success",
            "result" => {
                "content" => [{
                    "path" => "deployments/mdm-ear.ear",
                    "relative-to" => "jboss.server.base.dir",
                    "archive" => true
                }],
                "enabled" => true,
                "name" => "mdm-ear.ear",
                "persistent" => false,
                "runtime-name" => "mdm-ear.ear",
                "subsystem" => undefined,
                "subdeployment" => {
                    "dce-api-interface-2.1.2-MDM.jar" => undefined,
                    "wds-commons.jar" => undefined,
                    "mdm-i18n.jar" => undefined,
                    "client-provisioning-protocol.jar" => undefined,
                    "dce-server.jar" => undefined,
                    "udm-interface.jar" => undefined,
                    "dcs-plugin.jar" => undefined,
                    "hs20-plugin.jar" => undefined,
                    "dm-server.jar" => undefined,
                    "service-commons.jar" => undefined,
                    "alu-commons.jar" => undefined,
                    "device-subscriber-intf.jar" => undefined,
                    "mdm-licensing.jar" => undefined,
                    "action-services-intf.jar" => undefined,
                    "notification-services-intf.jar" => undefined,
                    "udm.jar" => undefined,
                    "tr69-connector-4.0-SNAPSHOT.war" => undefined,
                    "device-subscriber.jar" => undefined,
                    "container-api.jar" => undefined,
                    "container-jboss.jar" => undefined,
                    "selection-criteria-intf.jar" => undefined,
                    "selection-criteria.jar" => undefined,
                    "managed-services.jar" => undefined,
                    "action-services.jar" => undefined,
                    "device-jobs-intf.jar" => undefined,
                    "device-jobs.jar" => undefined,
                    "notification-services.jar" => undefined,
                    "nbi-services.jar" => undefined,
                    "system-properties.jar" => undefined,
                    "southbound-services.jar" => undefined,
                    "ios-commons.jar" => undefined,
                    "southbound-connector-4.0-SNAPSHOT.war" => undefined,
                    "tr69-protocol-4.0-SNAPSHOT.jar" => undefined,
                    "mdm-console-4.0-SNAPSHOT.war" => undefined,
                    "device-configurator-4.0-SNAPSHOT.war" => undefined,
                    "rcs-connector-4.0-SNAPSHOT.war" => undefined,
                    "rcs-protocol-4.0-SNAPSHOT.jar" => undefined,
                    "sim-ota-4.0-SNAPSHOT.war" => undefined,
                    "simota-protocol-4.0-SNAPSHOT.jar" => undefined,
                    "dce-protocol-4.0-SNAPSHOT.jar" => undefined,
                    "mdm-sce-4.0-SNAPSHOT.war" => undefined,
                    "gcm-device-registration-4.0-SNAPSHOT.war" => undefined,
                    "ios-profile-4.0-SNAPSHOT.war" => undefined
                }
            }
        },
        {
            "address" => [("deployment" => "hs20.war")],
            "outcome" => "success",
            "result" => {
                "content" => [{
                    "path" => "deployments/hs20.war",
                    "relative-to" => "jboss.server.base.dir",
                    "archive" => true
                }],
                "enabled" => true,
                "name" => "hs20.war",
                "persistent" => false,
                "runtime-name" => "hs20.war",
                "subdeployment" => undefined,
                "subsystem" => {
                    "web" => undefined,
                    "ejb3" => undefined
                }
            }
        }
    ]
}

{code}

                
> jboss-cli.sh show deployment status is FAILED but application running well
> --------------------------------------------------------------------------
>
>                 Key: WFLY-880
>                 URL: https://issues.jboss.org/browse/WFLY-880
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>         Environment: suse linux 11 sp2
>            Reporter: jing chen
>            Assignee: Alexey Loubyansky
>              Labels: jboss
>
> run jboss-cli.sh to check the deployment status and it shows FAILED.
> NDO-2120:/opt/jboss/bin # /opt/jboss/bin/jboss-cli.sh --connect command="/deployment=nsm.ear:read-attribute(name=status)"
> {
>     "outcome" => "success",
>     "result" => "FAILED"
> }
> nsm.ear is our application. But our application runs well and can be login successfully using client and executing operations are succeed. please help what is problem. what should i do to check the problem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 03:44:02 2013
From: jira-events at lists.jboss.org (gui borland (JIRA))
Date: Thu, 17 Oct 2013 03:44:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-880) jboss-cli.sh show deployment
 status is FAILED but application running well
In-Reply-To: <JIRA.12482906.1358749732000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12482906.1358749732000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12482906.1358749732000.2345.1381995842074@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12816311#comment-12816311 ] 

gui borland commented on WFLY-880:
----------------------------------

When attaching a debugger to jboss and putting a breakpoint on org.jboss.as.server.deployment.AbstractDeploymentUnitService.DeploymentServiceListener, I noticed that the servicesMissingDependencies set contains a service in case the deployment status is FAILED. 
However, this service is succesfully started (JMX msc tells me that). So it seems the DeploymentServiceListener.servicesMissingDependencies set is out of sync for some reason..
                
> jboss-cli.sh show deployment status is FAILED but application running well
> --------------------------------------------------------------------------
>
>                 Key: WFLY-880
>                 URL: https://issues.jboss.org/browse/WFLY-880
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>         Environment: suse linux 11 sp2
>            Reporter: jing chen
>            Assignee: Alexey Loubyansky
>              Labels: jboss
>
> run jboss-cli.sh to check the deployment status and it shows FAILED.
> NDO-2120:/opt/jboss/bin # /opt/jboss/bin/jboss-cli.sh --connect command="/deployment=nsm.ear:read-attribute(name=status)"
> {
>     "outcome" => "success",
>     "result" => "FAILED"
> }
> nsm.ear is our application. But our application runs well and can be login successfully using client and executing operations are succeed. please help what is problem. what should i do to check the problem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 03:54:02 2013
From: jira-events at lists.jboss.org (Radoslav Husar (JIRA))
Date: Thu, 17 Oct 2013 03:54:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2303) mod_cluster XSD is missing
 property and worker-timeout definitions
In-Reply-To: <JIRA.12503065.1381830758000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503065.1381830758000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503065.1381830758000.2375.1381996442045@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-2303:
---------------------------------

    Comment: was deleted

(was: https://github.com/wildfly/wildfly/pull/5272)

    
> mod_cluster XSD is missing property and worker-timeout definitions
> ------------------------------------------------------------------
>
>                 Key: WFLY-2303
>                 URL: https://issues.jboss.org/browse/WFLY-2303
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.CR1
>
>
> * worker-timeout
> * property
> are missing.
> Also missing in 7.x

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 03:59:02 2013
From: jira-events at lists.jboss.org (Ales Dolecek (JIRA))
Date: Thu, 17 Oct 2013 03:59:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-215) Corrupted Working/Production
	memory
In-Reply-To: <JIRA.12498476.1376388952000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498476.1376388952000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498476.1376388952000.2382.1381996742299@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12816542#comment-12816542 ] 

Ales Dolecek commented on DROOLS-215:
-------------------------------------

Hello,
  I have not seen the Exception on 5.5 from the time we rebuild knowledgebase on rule change (instead od incremental change of rules). Definitelly related to KB update. Have you looked at my last comment in the forum? I tried to analyze the code to discover where the change of nodes can occur. Seems that the lock held while copying entries during resize does not prevent concurent access.

Ale?
                
> Corrupted Working/Production memory
> -----------------------------------
>
>                 Key: DROOLS-215
>                 URL: https://issues.jboss.org/browse/DROOLS-215
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Ales Dolecek
>            Assignee: Mark Proctor
>         Attachments: ConcurrentNodeMemories.java
>
>
> Experienced ClassCastException mixing BetaMemory and AlphaMemory. There is debate in the mailing list/forum. The problem seems to be related to dymanic updates of knowledgebase.
> Saddly there is no deterministic way how to reproduce the issue, but that should not prevent tracking it here.
> Stack trace from my project:
> java.lang.ClassCastException: org.drools.reteoo.BetaMemory cannot be cast to org.drools.reteoo.AlphaNode$AlphaMemory
>         at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:136) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:497) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:382) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:350) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:311) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:192) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:186) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at cz.nextiraone.screening.rules.screening.Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1.defaultConsequence(Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1.java:7) ~[na
> :na]
>         at cz.nextiraone.screening.rules.screening.Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1DefaultConsequenceInvokerGenerated.evaluate(Unknown Source) ~[na:na]
>         at cz.nextiraone.screening.rules.screening.Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1DefaultConsequenceInvoker.evaluate(Unknown Source) ~[na:na]
>         at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1287) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1221) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1456) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:710) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:674) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:230) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Thu Oct 17 03:59:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 17 Oct 2013 03:59:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2303) mod_cluster XSD is missing
 property and worker-timeout definitions
In-Reply-To: <JIRA.12503065.1381830758000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503065.1381830758000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503065.1381830758000.2385.1381996742467@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12816557#comment-12816557 ] 

RH Bugzilla Integration commented on WFLY-2303:
-----------------------------------------------

Radoslav Husar <rhusar at redhat.com> made a comment on [bug 1020142|https://bugzilla.redhat.com/show_bug.cgi?id=1020142]

Started the process for 6.3. -- there is no 6.3, so 6.2..

The upstream is already fixed, see WFLY-2303.

@Michal: the reporter just copied the component from upstream issue where we dont differetiate between modcluster and clustering. Nevertheless, its better to use the specific component in EAP issue tracker.
                
> mod_cluster XSD is missing property and worker-timeout definitions
> ------------------------------------------------------------------
>
>                 Key: WFLY-2303
>                 URL: https://issues.jboss.org/browse/WFLY-2303
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.CR1
>
>
> * worker-timeout
> * property
> are missing.
> Also missing in 7.x

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 04:10:02 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Thu, 17 Oct 2013 04:10:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-215) Corrupted Working/Production
	memory
In-Reply-To: <JIRA.12498476.1376388952000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498476.1376388952000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498476.1376388952000.2398.1381997402942@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12816582#comment-12816582 ] 

Davide Sottara commented on DROOLS-215:
---------------------------------------

No, I haven't seen your last comment.. could you point me to the post? Thanks!!
                
> Corrupted Working/Production memory
> -----------------------------------
>
>                 Key: DROOLS-215
>                 URL: https://issues.jboss.org/browse/DROOLS-215
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Ales Dolecek
>            Assignee: Mark Proctor
>         Attachments: ConcurrentNodeMemories.java
>
>
> Experienced ClassCastException mixing BetaMemory and AlphaMemory. There is debate in the mailing list/forum. The problem seems to be related to dymanic updates of knowledgebase.
> Saddly there is no deterministic way how to reproduce the issue, but that should not prevent tracking it here.
> Stack trace from my project:
> java.lang.ClassCastException: org.drools.reteoo.BetaMemory cannot be cast to org.drools.reteoo.AlphaNode$AlphaMemory
>         at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:136) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:497) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:382) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:350) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:311) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:192) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:186) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at cz.nextiraone.screening.rules.screening.Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1.defaultConsequence(Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1.java:7) ~[na
> :na]
>         at cz.nextiraone.screening.rules.screening.Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1DefaultConsequenceInvokerGenerated.evaluate(Unknown Source) ~[na:na]
>         at cz.nextiraone.screening.rules.screening.Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1DefaultConsequenceInvoker.evaluate(Unknown Source) ~[na:na]
>         at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1287) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1221) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1456) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:710) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:674) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:230) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 04:18:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 17 Oct 2013 04:18:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2271) A problem setting include-all
 on a role mapping is failing getting rolled back.
In-Reply-To: <JIRA.12502544.1381316379000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502544.1381316379000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502544.1381316379000.2410.1381997882087@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12816583#comment-12816583 ] 

RH Bugzilla Integration commented on WFLY-2271:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> made a comment on [bug 1017199|https://bugzilla.redhat.com/show_bug.cgi?id=1017199]

Verified on EAP 6.2.0.ER6.
                
> A problem setting include-all on a role mapping is failing getting rolled back.
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-2271
>                 URL: https://issues.jboss.org/browse/WFLY-2271
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> As a side effect of another bug the following failure occurs: -
> {code}
> [domain at localhost:9990 /] ./core-service=management/access=authorization/role-mapping=test:add
> {
>     "outcome" => "success",
>     "result" => undefined,
>     "server-groups" => {"main-server-group" => {"host" => {"master" => {
>         "server-one" => {"response" => {"outcome" => "success"}},
>         "server-two" => {"response" => {"outcome" => "success"}}
>     }}}}
> }
> [domain at localhost:9990 /] ./core-service=management/access=authorization/role-mapping=test:write-attribute(name=include-all, value=true)
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "JBAS014749: Operation handler failed: JBAS013470: Unknown role 'TEST'"},
>     "rolled-back" => true
> }
> {code}
> Roll back however fails with this error: -
> {code}
> [Host Controller] 11:47:25,216 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 11) JBAS014603:  caught exception attempting to revert operation write-attribute at address [
> [Host Controller]     ("core-service" => "management"),
> [Host Controller]     ("access" => "authorization"),
> [Host Controller]     ("role-mapping" => "test")
> [Host Controller] ]: java.lang.IllegalArgumentException
> [Host Controller] 	at org.jboss.dmr.ModelValue.asBoolean(ModelValue.java:66) [jboss-dmr-1.2.0.Final.jar:1.2.0.Final]
> [Host Controller] 	at org.jboss.dmr.ModelNode.asBoolean(ModelNode.java:262) [jboss-dmr-1.2.0.Final.jar:1.2.0.Final]
> [Host Controller] 	at org.jboss.as.domain.management.access.RoleIncludeAllWriteAttributeHander.revertUpdateToRuntime(RoleIncludeAllWriteAttributeHander.java:65)
> [Host Controller] 	at org.jboss.as.domain.management.access.RoleIncludeAllWriteAttributeHander.revertUpdateToRuntime(RoleIncludeAllWriteAttributeHander.java:35)
> {code}
> Two issues here: -
> 1 - "rolled-back" should not be true as it failed.
> 2 - The failure during rollback needs to be fixed, the default for this attribute if not set is 'false'.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 04:18:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 17 Oct 2013 04:18:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2271) A problem setting include-all
 on a role mapping is failing getting rolled back.
In-Reply-To: <JIRA.12502544.1381316379000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502544.1381316379000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502544.1381316379000.2413.1381997882250@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12816584#comment-12816584 ] 

RH Bugzilla Integration commented on WFLY-2271:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> changed the Status of [bug 1017199|https://bugzilla.redhat.com/show_bug.cgi?id=1017199] from ON_QA to VERIFIED
                
> A problem setting include-all on a role mapping is failing getting rolled back.
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-2271
>                 URL: https://issues.jboss.org/browse/WFLY-2271
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> As a side effect of another bug the following failure occurs: -
> {code}
> [domain at localhost:9990 /] ./core-service=management/access=authorization/role-mapping=test:add
> {
>     "outcome" => "success",
>     "result" => undefined,
>     "server-groups" => {"main-server-group" => {"host" => {"master" => {
>         "server-one" => {"response" => {"outcome" => "success"}},
>         "server-two" => {"response" => {"outcome" => "success"}}
>     }}}}
> }
> [domain at localhost:9990 /] ./core-service=management/access=authorization/role-mapping=test:write-attribute(name=include-all, value=true)
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "JBAS014749: Operation handler failed: JBAS013470: Unknown role 'TEST'"},
>     "rolled-back" => true
> }
> {code}
> Roll back however fails with this error: -
> {code}
> [Host Controller] 11:47:25,216 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 11) JBAS014603:  caught exception attempting to revert operation write-attribute at address [
> [Host Controller]     ("core-service" => "management"),
> [Host Controller]     ("access" => "authorization"),
> [Host Controller]     ("role-mapping" => "test")
> [Host Controller] ]: java.lang.IllegalArgumentException
> [Host Controller] 	at org.jboss.dmr.ModelValue.asBoolean(ModelValue.java:66) [jboss-dmr-1.2.0.Final.jar:1.2.0.Final]
> [Host Controller] 	at org.jboss.dmr.ModelNode.asBoolean(ModelNode.java:262) [jboss-dmr-1.2.0.Final.jar:1.2.0.Final]
> [Host Controller] 	at org.jboss.as.domain.management.access.RoleIncludeAllWriteAttributeHander.revertUpdateToRuntime(RoleIncludeAllWriteAttributeHander.java:65)
> [Host Controller] 	at org.jboss.as.domain.management.access.RoleIncludeAllWriteAttributeHander.revertUpdateToRuntime(RoleIncludeAllWriteAttributeHander.java:35)
> {code}
> Two issues here: -
> 1 - "rolled-back" should not be true as it failed.
> 2 - The failure during rollback needs to be fixed, the default for this attribute if not set is 'false'.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 04:18:02 2013
From: jira-events at lists.jboss.org (Frederic Hornain (JIRA))
Date: Thu, 17 Oct 2013 04:18:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2325)
 [Wildfly][WARN][org.hibernate.dialect.H2Dialect] Unable to determine H2
 database version, certain features may not work
In-Reply-To: <JIRA.12504393.1381997843810@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12504393.1381997843810@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12504393.1381997843810.2415.1381997882406@jira02.app.mwc.hst.phx2.redhat.com>

Frederic Hornain created WFLY-2325:
--------------------------------------

             Summary: [Wildfly][WARN][org.hibernate.dialect.H2Dialect] Unable to determine H2 database version, certain features may not work
                 Key: WFLY-2325
                 URL: https://issues.jboss.org/browse/WFLY-2325
             Project: WildFly
          Issue Type: Bug
          Components: JPA / Hibernate
    Affects Versions: 8.0.0.Beta1
            Reporter: Frederic Hornain
            Assignee: Scott Marlow
            Priority: Optional


WARN  [org.hibernate.dialect.H2Dialect] (ServerService Thread Pool -- 52) HHH000431: Unable to determine H2 database version, certain features may not work

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 04:20:01 2013
From: jira-events at lists.jboss.org (Frederic Hornain (JIRA))
Date: Thu, 17 Oct 2013 04:20:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2326)
 [Wildfly][WARN][org.hibernate.dialect.H2Dialect] Defining
 hibernate.transaction.flush_before_completion=true ignored in HEM
In-Reply-To: <JIRA.12504394.1381997945075@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12504394.1381997945075@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12504394.1381997945075.2419.1381998001990@jira02.app.mwc.hst.phx2.redhat.com>

Frederic Hornain created WFLY-2326:
--------------------------------------

             Summary: [Wildfly][WARN][org.hibernate.dialect.H2Dialect] Defining hibernate.transaction.flush_before_completion=true ignored in HEM
                 Key: WFLY-2326
                 URL: https://issues.jboss.org/browse/WFLY-2326
             Project: WildFly
          Issue Type: Bug
          Components: JPA / Hibernate
    Affects Versions: 8.0.0.Beta1
            Reporter: Frederic Hornain
            Assignee: Scott Marlow
            Priority: Optional


WARN  [org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl] (ServerService Thread Pool -- 52) HHH000059: Defining hibernate.transaction.flush_before_completion=true ignored in HEM

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 04:23:02 2013
From: jira-events at lists.jboss.org (Frederic Hornain (JIRA))
Date: Thu, 17 Oct 2013 04:23:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2327) [Wildfly][RFE]
In-Reply-To: <JIRA.12504395.1381998139158@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12504395.1381998139158@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12504395.1381998139158.2437.1381998182452@jira02.app.mwc.hst.phx2.redhat.com>

Frederic Hornain created WFLY-2327:
--------------------------------------

             Summary: [Wildfly][RFE] 
                 Key: WFLY-2327
                 URL: https://issues.jboss.org/browse/WFLY-2327
             Project: WildFly
          Issue Type: Enhancement
          Components: JPA / Hibernate
    Affects Versions: 8.0.0.Beta1
            Reporter: Frederic Hornain
            Assignee: Scott Marlow
            Priority: Minor


Dear *,

Would it be possible to change the ERROR log level to something between "WARN" and "ERROR" when a non yet existing table is dropped ?

10:08:49,828 ERROR [org.hibernate.tool.hbm2ddl.SchemaExport] (ServerService Thread Pool -- 52) HHH000389: Unsuccessful: drop sequence hibernate_sequence
10:08:49,829 ERROR [org.hibernate.tool.hbm2ddl.SchemaExport] (ServerService Thread Pool -- 52) Sequence "HIBERNATE_SEQUENCE" not found; SQL statement:

    drop sequence hibernate_sequence [90036-173]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 04:27:02 2013
From: jira-events at lists.jboss.org (Ales Dolecek (JIRA))
Date: Thu, 17 Oct 2013 04:27:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-215) Corrupted Working/Production
	memory
In-Reply-To: <JIRA.12498476.1376388952000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498476.1376388952000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498476.1376388952000.2452.1381998422091@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12816588#comment-12816588 ] 

Ales Dolecek commented on DROOLS-215:
-------------------------------------

See "forum reference" in the details of this ticket. Scroll to the bottom. Permanent link should be: http://drools.46999.n3.nabble.com/java-lang-ClassCastException-org-drools-reteoo-BetaMemory-cannot-be-cast-to-org-drools-reteoo-AlphaNy-tp4023610p4025416.html
                
> Corrupted Working/Production memory
> -----------------------------------
>
>                 Key: DROOLS-215
>                 URL: https://issues.jboss.org/browse/DROOLS-215
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Ales Dolecek
>            Assignee: Mark Proctor
>         Attachments: ConcurrentNodeMemories.java
>
>
> Experienced ClassCastException mixing BetaMemory and AlphaMemory. There is debate in the mailing list/forum. The problem seems to be related to dymanic updates of knowledgebase.
> Saddly there is no deterministic way how to reproduce the issue, but that should not prevent tracking it here.
> Stack trace from my project:
> java.lang.ClassCastException: org.drools.reteoo.BetaMemory cannot be cast to org.drools.reteoo.AlphaNode$AlphaMemory
>         at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:136) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:497) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:382) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:350) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:311) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:192) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:186) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at cz.nextiraone.screening.rules.screening.Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1.defaultConsequence(Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1.java:7) ~[na
> :na]
>         at cz.nextiraone.screening.rules.screening.Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1DefaultConsequenceInvokerGenerated.evaluate(Unknown Source) ~[na:na]
>         at cz.nextiraone.screening.rules.screening.Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1DefaultConsequenceInvoker.evaluate(Unknown Source) ~[na:na]
>         at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1287) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1221) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1456) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:710) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:674) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:230) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 04:29:02 2013
From: jira-events at lists.jboss.org (Frederic Hornain (JIRA))
Date: Thu, 17 Oct 2013 04:29:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2327) [Wildfly][RFE] ERROR Level
 message when unsuccessful drop sequence hibernate_sequence occurs
In-Reply-To: <JIRA.12504395.1381998139000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12504395.1381998139000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12504395.1381998139000.2473.1381998542567@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Frederic Hornain updated WFLY-2327:
-----------------------------------

    Summary: [Wildfly][RFE] ERROR Level message when unsuccessful drop sequence hibernate_sequence occurs  (was: [Wildfly][RFE] )

    
> [Wildfly][RFE] ERROR Level message when unsuccessful drop sequence hibernate_sequence occurs
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2327
>                 URL: https://issues.jboss.org/browse/WFLY-2327
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Frederic Hornain
>            Assignee: Scott Marlow
>            Priority: Minor
>
> Dear *,
> Would it be possible to change the ERROR log level to something between "WARN" and "ERROR" when a non yet existing table is dropped ?
> 10:08:49,828 ERROR [org.hibernate.tool.hbm2ddl.SchemaExport] (ServerService Thread Pool -- 52) HHH000389: Unsuccessful: drop sequence hibernate_sequence
> 10:08:49,829 ERROR [org.hibernate.tool.hbm2ddl.SchemaExport] (ServerService Thread Pool -- 52) Sequence "HIBERNATE_SEQUENCE" not found; SQL statement:
>     drop sequence hibernate_sequence [90036-173]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 04:37:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 17 Oct 2013 04:37:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2317) Trying to remove a server
 group as a server-group-scoped role leaks information
In-Reply-To: <JIRA.12503235.1381924172000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503235.1381924172000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503235.1381924172000.2496.1381999022090@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12816594#comment-12816594 ] 

RH Bugzilla Integration commented on WFLY-2317:
-----------------------------------------------

Ladislav Thon <lthon at redhat.com> made a comment on [bug 1019784|https://bugzilla.redhat.com/show_bug.cgi?id=1019784]

This is reproducible on ER6 using the same instructions as in the upstream issue. Copying those instructions here for reference.

On a freshly unpacked EAP 6.2.0.ER6 with added "admin" user into domain/configuration/mgmt-users.properties, the problem can be reproduced like this:

[1] ./bin/domain.sh
[2] ./bin/jboss-cli.sh -c
    /core-service=management/access=authorization/server-group-scoped-role=NewRole:add(base-role=administrator, server-groups=[main-server-group])
    /core-service=management/access=authorization/role-mapping=NewRole:add
    /core-service=management/access=authorization/role-mapping=NewRole/include=user-admin:add(name=admin, type=user)
    /core-service=management/access=authorization:write-attribute(name=provider, value=rbac)
    exit
[1] ^C
    ./bin/domain.sh
[2] ./bin/jboss-cli.sh -c --user=admin --password=XXX
    /server-group=other-server-group:read-resource
    /server-group=other-server-group:remove

What does that mean? The "NewRole" role is scoped to the "main-server-group" server group and can't see the "other-server-group" group. When doing "/server-group=other-server-group:read-resource", this is correctly enforced and the output looks like this:

{
    "outcome" => "failed",
    "failure-description" => "JBAS014807: Management resource '[(\"server-group\" => \"other-server-group\")]' not found",
    "rolled-back" => true
}

However, trying to do "/server-group=other-server-group:remove", which is only a different operation _on the same resource_, I get a different error message:

{
    "outcome" => "failed",
    "failure-description" => {"domain-failure-description" => "JBAS013456: Unauthorized to execute operation 'remove' for resource '[(\"server-group\" => \"other-server-group\")]' -- \"JBAS013475: Permission denied\""},
    "rolled-back" => true
}

I expect the error message to be completely the same as in previous case, not leaking any information that the "other-server-group" group actually exists.
                
> Trying to remove a server group as a server-group-scoped role leaks information
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-2317
>                 URL: https://issues.jboss.org/browse/WFLY-2317
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Brian Stansberry
>              Labels: rbac-filed-by-qa
>
> When writing a small test case for WFLY-2190, I stumbled upon a problem: trying to remove an existing server group by a server-group-scoped user that does NOT have permissions to that server group leaks information. On a freshly built WildFly with added {{admin}} user into {{domain/configuration/mgmt-users.properties}}, it can be reproduced like this:
> {code}
> [1] ./bin/domain.sh
> [2] ./bin/jboss-cli.sh -c
>     /core-service=management/access=authorization/server-group-scoped-role=NewRole:add(base-role=administrator, server-groups=[main-server-group])
>     /core-service=management/access=authorization/role-mapping=NewRole:add
>     /core-service=management/access=authorization/role-mapping=NewRole/include=user-admin:add(name=admin, type=user)
>     /core-service=management/access=authorization:write-attribute(name=provider, value=rbac)
>     exit
> [1] ^C
>     ./bin/domain.sh
> [2] ./bin/jboss-cli.sh -c --user=admin --password=XXX
>     /server-group=other-server-group:read-resource
>     /server-group=other-server-group:remove
> {code}
> What does that mean? The {{NewRole}} is scoped to the {{main-server-group}} server group and can't see {{other-server-group}}. When doing {{/server-group=other-server-group:read-resource}}, this is correctly enforced and the output looks like this:
> {code}
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014807: Management resource '[(\"server-group\" => \"other-server-group\")]' not found",
>     "rolled-back" => true
> }
> {code}
> However, trying to do {{/server-group=other-server-group:remove}}, which is only a different operation _on the same resource_, I get a different error message:
> {code}
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "JBAS013456: Unauthorized to execute operation 'remove' for resource '[(\"server-group\" => \"other-server-group\")]' -- \"JBAS013475: Permission denied\""},
>     "rolled-back" => true
> }
> {code}
> I expect the error message to be completely the same as in previous case, not leaking any information that the {{other-server-group}} actually exists.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 04:44:02 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Thu, 17 Oct 2013 04:44:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-215) Corrupted Working/Production
	memory
In-Reply-To: <JIRA.12498476.1376388952000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498476.1376388952000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498476.1376388952000.2518.1381999442423@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12816598#comment-12816598 ] 

Davide Sottara commented on DROOLS-215:
---------------------------------------

Oh, I had seen that comment weeks ago. I tried to reproduce the bug based on that comment, but to no avail. The KB, in theory, is locked while it's being modified.
Could you make any progress in actually isolating the problem? i.e. do you have proof of concurrent access during a resize?
                
> Corrupted Working/Production memory
> -----------------------------------
>
>                 Key: DROOLS-215
>                 URL: https://issues.jboss.org/browse/DROOLS-215
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Ales Dolecek
>            Assignee: Mark Proctor
>         Attachments: ConcurrentNodeMemories.java
>
>
> Experienced ClassCastException mixing BetaMemory and AlphaMemory. There is debate in the mailing list/forum. The problem seems to be related to dymanic updates of knowledgebase.
> Saddly there is no deterministic way how to reproduce the issue, but that should not prevent tracking it here.
> Stack trace from my project:
> java.lang.ClassCastException: org.drools.reteoo.BetaMemory cannot be cast to org.drools.reteoo.AlphaNode$AlphaMemory
>         at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:136) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:497) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:382) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:350) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:311) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:192) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:186) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at cz.nextiraone.screening.rules.screening.Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1.defaultConsequence(Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1.java:7) ~[na
> :na]
>         at cz.nextiraone.screening.rules.screening.Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1DefaultConsequenceInvokerGenerated.evaluate(Unknown Source) ~[na:na]
>         at cz.nextiraone.screening.rules.screening.Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1DefaultConsequenceInvoker.evaluate(Unknown Source) ~[na:na]
>         at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1287) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1221) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1456) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:710) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:674) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]
>         at org.drools.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:230) ~[drools-core-5.5.0.Final.jar:5.5.0.Final]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 05:06:01 2013
From: jira-events at lists.jboss.org (Tom Fonteyne (JIRA))
Date: Thu, 17 Oct 2013 05:06:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-723) SPNEGO backport of
 additional Kerberos ticket decoding
In-Reply-To: <JIRA.12483911.1359631794000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12483911.1359631794000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12483911.1359631794000.2572.1382000761991@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/SECURITY-723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12816865#comment-12816865 ] 

Tom Fonteyne commented on SECURITY-723:
---------------------------------------

$ svn ci jboss-negotiation-spnego/src/main/java/org/jboss/security/negotiation/spnego/encoding/TokenParser.java -m "[SECURITY-723] SPNEGO backport of additional Kerberos ticket decoding"
Sending        jboss-negotiation-spnego/src/main/java/org/jboss/security/negotiation/spnego/encoding/TokenParser.java                                                                                                                       
Transmitting file data .                                                                                                                                                                                                                    
Committed revision 114535. 
                
> SPNEGO backport of additional Kerberos ticket decoding
> ------------------------------------------------------
>
>                 Key: SECURITY-723
>                 URL: https://issues.jboss.org/browse/SECURITY-723
>             Project: PicketBox 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>    Affects Versions: Negotiation_2_1_3
>            Reporter: Tom Fonteyne
>            Assignee: Tom Fonteyne
>
> /jboss-negotiation-spnego/src/main/java/org/jboss/security/negotiation/spnego/encoding/TokenParser.java
> is lacking additional decoding of the Kerberos ticket.
> This patch backports the missing code from trunk
> Testing: the standard unit test for remote EJB calls over SPNEGO.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 05:06:02 2013
From: jira-events at lists.jboss.org (Tom Fonteyne (JIRA))
Date: Thu, 17 Oct 2013 05:06:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-723) SPNEGO backport of
 additional Kerberos ticket decoding
In-Reply-To: <JIRA.12483911.1359631794000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12483911.1359631794000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12483911.1359631794000.2574.1382000762171@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Fonteyne updated SECURITY-723:
----------------------------------

    Steps to Reproduce: 
- Use either a combination of Windows 2003 Active Directory and a Windows XP client
- setup JBoss EAP 5.2.0 with SPNEGO pointed to the AD server.
  - "host" security domain
  - "SPNEGO" security domain
  - a simple properties based setup for spnego roles, with (for example)
     tom at JBOSSUK.REDHAT.COM=Users
- test with the SPNEGO toolkit that all 3 tests are working ok.

  was:
- Use either a combination of Windows 2003 Active Directory and a Windows XP client, or Windows 2008 and a Vista/Windows7 client
- setup JBoss EAP 5.2.0 with SPNEGO pointed to the AD server.
  - "host" security domain
  - "SPNEGO" security domain
  - a simple properties based setup for spnego roles, with (for example)
     tom at JBOSSUK.REDHAT.COM=Users
- test with the SPNEGO toolkit that all 3 tests are working ok.

MORE TO COME


    
> SPNEGO backport of additional Kerberos ticket decoding
> ------------------------------------------------------
>
>                 Key: SECURITY-723
>                 URL: https://issues.jboss.org/browse/SECURITY-723
>             Project: PicketBox 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>    Affects Versions: Negotiation_2_1_3
>            Reporter: Tom Fonteyne
>            Assignee: Tom Fonteyne
>
> /jboss-negotiation-spnego/src/main/java/org/jboss/security/negotiation/spnego/encoding/TokenParser.java
> is lacking additional decoding of the Kerberos ticket.
> This patch backports the missing code from trunk
> Testing: the standard unit test for remote EJB calls over SPNEGO.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 05:19:02 2013
From: jira-events at lists.jboss.org (Antonio Goncalves (JIRA))
Date: Thu, 17 Oct 2013 05:19:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2027) EE Default DataSource is not
	working
In-Reply-To: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500313.1378739268000.2618.1382001542783@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12816872#comment-12816872 ] 

Antonio Goncalves commented on WFLY-2027:
-----------------------------------------

I've used the Default Datasource with Beta1 and it doesn't work. Here is my persistence.xml :

{code}
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<persistence xmlns="http://xmlns.jcp.org/xml/ns/persistence"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd"
             version="2.1">
  <persistence-unit name="javaone2013PU" transaction-type="JTA">
    <description>Forge Persistence Unit</description>
    <jta-data-source>java:comp/DefaultDataSource</jta-data-source>
    <exclude-unlisted-classes>false</exclude-unlisted-classes>
    <properties>
        <property name="javax.persistence.schema-generation.database.action" value="drop-and-create"/>
        <property name="javax.persistence.schema-generation.scripts.action" value="drop-and-create"/>
        <property name="javax.persistence.schema-generation.scripts.create-target" value="createJavaOne2013.ddl"/>
        <property name="javax.persistence.schema-generation.scripts.drop-target" value="dropJavaOne2013.ddl"/>
        <property name="javax.persistence.sql-load-script-source" value="insert.sql"/>
    </properties>
  </persistence-unit>
</persistence>
{code}

When I deploy my war file I get the following in the console : 

{code}
Unexpected HTTP response: 500

Request
{
    "address" => [("deployment" => "javaone2013.war")],
    "operation" => "deploy"
}

Response

Internal Server Error
{
    "outcome" => "failed",
    "failure-description" => {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"javaone2013.war#javaone2013PU\".__FIRST_PHASE__ is missing [jboss.naming.context.java.module.javaone2013.javaone2013.DefaultDataSource]"]},
    "rolled-back" => true
}
{code}

On the server logs

{code}
[0m11:17:23,198 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-11) JBAS015876: Starting deployment of "javaone2013.war" (runtime-name: "javaone2013.war")
[0m[0m11:17:23,406 INFO  [org.jboss.as.jpa] (MSC service thread 1-7) JBAS011401: Read persistence.xml for javaone2013PU
[0m[31m11:17:23,445 ERROR [org.jboss.as.controller.management-operation] (XNIO-1 task-4) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "javaone2013.war")]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"javaone2013.war#javaone2013PU\".__FIRST_PHASE__ is missing [jboss.naming.context.java.module.javaone2013.javaone2013.DefaultDataSource]"]}
[0m[31m11:17:23,445 ERROR [org.jboss.as.server] (XNIO-1 task-4) JBAS015870: Deploy of deployment "javaone2013.war" was rolled back with the following failure message: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"javaone2013.war#javaone2013PU\".__FIRST_PHASE__ is missing [jboss.naming.context.java.module.javaone2013.javaone2013.DefaultDataSource]"]}
[0m[0m11:17:23,454 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-11) JBAS015877: Stopped deployment javaone2013.war (runtime-name: javaone2013.war) in 8ms
{code}

                
> EE Default DataSource is not working
> ------------------------------------
>
>                 Key: WFLY-2027
>                 URL: https://issues.jboss.org/browse/WFLY-2027
>             Project: WildFly
>          Issue Type: Bug
>          Components: ConfigAdmin, Domain Management, EE, JCA, JPA / Hibernate, Web Console
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Lincoln Baxter III
>            Assignee: Eduardo Martins
>             Fix For: 8.0.0.Beta1
>
>
> The EE spec states that a default datasource must be supplied under: java:comp/DefaultDataSource, and if none is specified by the @Resource or persistence.xml, it must be assumed:
>  {code}EE 5.19
> The Java EE Platform requires that a Java EE Product Provider provide a database 
> in the operational environment (see Section EE.2.6, ?Database?). The Java EE 
> Product Provider must also provide a preconfigured, default data source for use by 
> the application in accessing this database.
> The Java EE Product Provider must make the default data source accessible to 
> the application under the JNDI name java:comp/DefaultDataSource.
> The Application Component Provider or Deployer may explicitly bind a 
> DataSource resource reference to the default data source using the lookup element 
> of the Resource annotation or the lookup-name element of the resource-ref
> deployment descriptor element. For example,
> @Resource(lookup="java:comp/DefaultDataSource")
> DataSource myDS;
> In the absence of such a binding, the mapping of the reference will default to 
> the product's default data source.
> For example, the following will map to a preconfigured data source for the 
> product's default database:
> @Resource
> DataSource myDS;{code}
> This, isn't working however:
> {code}
> <persistence version="2.1" xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>    xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/persistence/persistence_2_1.xsd">
>    <persistence-unit name="default" transaction-type="JTA">
>    </persistence-unit>
> </persistence>{code}
> Results in: 
> {code}
> 10:41:31,002 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 50) MSC000001: Failed to start service jboss.persistenceunit."jpa-standard.war#default": org.jboss.msc.service.StartException in service jboss.persistenceunit."jpa-standard.war#default": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:134) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.determineDialect(DialectFactoryImpl.java:98)
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.buildDialect(DialectFactoryImpl.java:66)
> 	at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:193)
> 	at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:88)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:159)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131)
> 	at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration.java:1844)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1802)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:844)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835)
> 	at org.jboss.as.jpa.hibernate4.management.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:115) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	... 4 more
> 10:41:31,010 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"jpa-standard.war#default\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"jpa-standard.war#default\": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
>     Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set"}}
> {code}
> Additionally, actually specifying the expected JDNI name of the default DS like this:
> {code}   <persistence-unit name="default" transaction-type="JTA">
>       <jta-data-source>java:comp/DefaultDataSource</jta-data-source>
>       <exclude-unlisted-classes>false</exclude-unlisted-classes>
>    </persistence-unit>{code}
> Results in this:
> {code}
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.naming.context.java.module.jpa-standard.jpa-standard.DefaultDataSource (missing) dependents: [service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__] 
>       service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__ (missing) dependents: [service jboss.deployment.unit."jpa-standard.war".POST_MODULE] 
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Thu Oct 17 06:05:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 17 Oct 2013 06:05:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2074) Remove message IDs from
 messages used by add-user informing the user the password requirements.
In-Reply-To: <JIRA.12500730.1379264158000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500730.1379264158000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500730.1379264158000.2669.1382004302026@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2074:
-----------------------------------

        Parent: WFLY-1991
    Issue Type: Sub-task  (was: Task)

    
> Remove message IDs from messages used by add-user informing the user the password requirements.
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2074
>                 URL: https://issues.jboss.org/browse/WFLY-2074
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Scripts
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> They are only information messages not errors - they don't need message IDs.
> Also when actually validating the password all failures reasons should be identified and listed rather than just the first one encountered.
> Overall the messages would be better if they were restructured rather than the one line per requirement approach we have now.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 06:05:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 17 Oct 2013 06:05:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2311) Confusing password
 requirements prompt in add-user.sh
In-Reply-To: <JIRA.12503144.1381874096000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503144.1381874096000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503144.1381874096000.2672.1382004302170@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2311:
-----------------------------------

        Parent: WFLY-1991
    Issue Type: Sub-task  (was: Bug)

    
> Confusing password requirements prompt in add-user.sh
> -----------------------------------------------------
>
>                 Key: WFLY-2311
>                 URL: https://issues.jboss.org/browse/WFLY-2311
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Security
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Brian Stansberry
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> The add-user script prompt says the requirements for a password will be listed, but nothing is listed.
> What type of user do you wish to add? 
>  a) Management User (mgmt-users.properties) 
>  b) Application User (application-users.properties)
> (a): a
> Enter the details of the new user to add.
> Using realm 'ManagementRealm' as discovered from the existing property files.
> Username : bstansberry
> Password requirements are listed below. To modify these restrictions edit the add-user.properties configuration file.
> Password : 
> If there are no requirements, then some placeholder requirement like <no restrictions on password format> should be output.
> It seems there is at least a non-null/empty requirement, as I just created a user with 'b' as the password, but no password at all failed. So that requirement should be reported.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 06:35:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 17 Oct 2013 06:35:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1913) CLI 'module add' command fail
 if a drive letter is specified in its resource path
In-Reply-To: <JIRA.12499050.1377075768000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499050.1377075768000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499050.1377075768000.2716.1382006102082@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12817086#comment-12817086 ] 

RH Bugzilla Integration commented on WFLY-1913:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> made a comment on [bug 1014921|https://bugzilla.redhat.com/show_bug.cgi?id=1014921]


                
> CLI 'module add' command fail if a drive letter is specified in its resource path
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-1913
>                 URL: https://issues.jboss.org/browse/WFLY-1913
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>             Fix For: 8.0.0.CR1
>
>         Attachments: install-mojarra-2.0.0.cli
>
>
> If a drive letter is specified in the resource path the module add command fails on MS Windows. It cannot locate such a resource because of doubled drive letter in the translated path.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 06:35:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 17 Oct 2013 06:35:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1913) CLI 'module add' command fail
 if a drive letter is specified in its resource path
In-Reply-To: <JIRA.12499050.1377075768000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499050.1377075768000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499050.1377075768000.2724.1382006102501@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12817087#comment-12817087 ] 

RH Bugzilla Integration commented on WFLY-1913:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> changed the Status of [bug 1014921|https://bugzilla.redhat.com/show_bug.cgi?id=1014921] from ON_QA to VERIFIED
                
> CLI 'module add' command fail if a drive letter is specified in its resource path
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-1913
>                 URL: https://issues.jboss.org/browse/WFLY-1913
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>             Fix For: 8.0.0.CR1
>
>         Attachments: install-mojarra-2.0.0.cli
>
>
> If a drive letter is specified in the resource path the module add command fails on MS Windows. It cannot locate such a resource because of doubled drive letter in the translated path.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 06:35:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 17 Oct 2013 06:35:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1913) CLI 'module add' command fail
 if a drive letter is specified in its resource path
In-Reply-To: <JIRA.12499050.1377075768000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499050.1377075768000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499050.1377075768000.2728.1382006102637@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12817088#comment-12817088 ] 

RH Bugzilla Integration commented on WFLY-1913:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> made a comment on [bug 1014921|https://bugzilla.redhat.com/show_bug.cgi?id=1014921]

Hi Ivo,
How about the error message after undeploy operation?
ERROR [org.jboss.as.cli.CommandContext] Failed to execute archive script: JBAS014746: steps may not be null
Failed to execute archive script: JBAS014746: steps may not be null

All commands inside undeploy.scr are successfully executed, but after that this message will appear (same on win and linux, same message with 6.1.1). Is this a known issue or something wrong with CLI archive?

Just use attachment 813260
[standalone at localhost:9999 /] deploy --path=~/Downloads/install-mojarra-2.0.0.cli
[standalone at localhost:9999 /] undeploy --path=~/Downloads/install-mojarra-2.0.0.cli
Failed to execute archive script: JBAS014746: steps may not be null

Thanks.

Verified on EAP 6.2.0.ER6. 'module add' command inside CLI deployment archive now works on Windows as expected.
                
> CLI 'module add' command fail if a drive letter is specified in its resource path
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-1913
>                 URL: https://issues.jboss.org/browse/WFLY-1913
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>             Fix For: 8.0.0.CR1
>
>         Attachments: install-mojarra-2.0.0.cli
>
>
> If a drive letter is specified in the resource path the module add command fails on MS Windows. It cannot locate such a resource because of doubled drive letter in the translated path.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 06:39:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 17 Oct 2013 06:39:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1718) Message corruption under
	heavy load
In-Reply-To: <JIRA.12503731.1381946713000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503731.1381946713000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503731.1381946713000.2757.1382006342506@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12817090#comment-12817090 ] 

Bela Ban commented on JGRP-1718:
--------------------------------

* What makes you think this is an issue in JGroups and not in Kryo ?
* If you run your app without Kryo, does it exhibit the same problem ?
* I don't know Kryo, but does it reuse buffers, possibly overwriting unread data ? Might be worth trying out the following things:
** Copy the buffer returned from Kryo or passed to Kryo
** Use the {{Message(Address dest, Address src, byte[] buffer, int offset, int length}} constructor to pass the buffer to JGroups
** Use the {{Message.getRawBuffer(), msg.getOffset(), msg.getLength()}} method to fetch the buffer from a message

If this doesn't help and you can provide me with a JGroups standalone program that reproduces the problem, post the stack trace, and I can run it here to see what the issue is.
However, I'm not going to debug Kryo issues... :-)
                
> Message corruption under heavy load
> -----------------------------------
>
>                 Key: JGRP-1718
>                 URL: https://issues.jboss.org/browse/JGRP-1718
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.12
>         Environment: JBoss AS 7.2.0.Final (includes JGroups 3.2.7.Final, upgrading to 3.2.12.Final had no effect)
>            Reporter: Rich DiCroce
>            Assignee: Bela Ban
>
> In my project, I'm using the Kryo serialization library to serialize/deserialize objects to/from byte[]. Some of these byte arrays appear to be getting corrupted during transmission.
> The problem happens very infrequently and only under load. I have to send tens of thousands of messages from hundreds of threads just to get two or three errors. The exception occurs when Kryo tries to deserialize the byte[] on the receiving node. So far, all of the errors I've seen happen when Kryo tries to find a class to deserialize an object, and the stack traces end with something like:
> Caused by: java.lang.ClassNotFoundException: java.util.Date[SOH][GS]
> Note that the [SOH] and [GS] are not literally those strings, they're unprintable ASCII 0x1 and 0x1D.
> I'm confident that Kryo itself is not the source of the problem. I added some code to my project to deserialize the message on the sending node, immediately after serializing it, and log any exception thrown from the deserialization. The sending node did not log an exception, but the receiving node still did. My code passes the byte[] to the Message constructor without doing anything to it.
> It also appears that I am not the first person to encounter this issue. See https://code.google.com/p/kryo/issues/detail?id=102

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 06:41:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 17 Oct 2013 06:41:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1718) Message corruption under
	heavy load
In-Reply-To: <JIRA.12503731.1381946713000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503731.1381946713000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503731.1381946713000.2773.1382006462543@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12817090#comment-12817090 ] 

Bela Ban edited comment on JGRP-1718 at 10/17/13 6:39 AM:
----------------------------------------------------------

* What makes you think this is an issue in JGroups and not in Kryo ?
* If you run your app without Kryo, does it exhibit the same problem ?
* I don't know Kryo, but does it reuse buffers, possibly overwriting unread data ? Might be worth trying out the following things:
** Copy the buffer returned from Kryo or passed to Kryo
** Use the {{Message(Address dest, Address src, byte[] buffer, int offset, int length)}} constructor to pass the buffer to JGroups
** Use {{Message.getRawBuffer(), msg.getOffset(), msg.getLength()}} to fetch the buffer from a message

If this doesn't help and you can provide me with a JGroups standalone program that reproduces the problem, post the stack trace, and I can run it here to see what the issue is.
However, I'm not going to debug Kryo issues... :-)
                
      was (Author: belaban):
    * What makes you think this is an issue in JGroups and not in Kryo ?
* If you run your app without Kryo, does it exhibit the same problem ?
* I don't know Kryo, but does it reuse buffers, possibly overwriting unread data ? Might be worth trying out the following things:
** Copy the buffer returned from Kryo or passed to Kryo
** Use the {{Message(Address dest, Address src, byte[] buffer, int offset, int length}} constructor to pass the buffer to JGroups
** Use the {{Message.getRawBuffer(), msg.getOffset(), msg.getLength()}} method to fetch the buffer from a message

If this doesn't help and you can provide me with a JGroups standalone program that reproduces the problem, post the stack trace, and I can run it here to see what the issue is.
However, I'm not going to debug Kryo issues... :-)
                  
> Message corruption under heavy load
> -----------------------------------
>
>                 Key: JGRP-1718
>                 URL: https://issues.jboss.org/browse/JGRP-1718
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.12
>         Environment: JBoss AS 7.2.0.Final (includes JGroups 3.2.7.Final, upgrading to 3.2.12.Final had no effect)
>            Reporter: Rich DiCroce
>            Assignee: Bela Ban
>
> In my project, I'm using the Kryo serialization library to serialize/deserialize objects to/from byte[]. Some of these byte arrays appear to be getting corrupted during transmission.
> The problem happens very infrequently and only under load. I have to send tens of thousands of messages from hundreds of threads just to get two or three errors. The exception occurs when Kryo tries to deserialize the byte[] on the receiving node. So far, all of the errors I've seen happen when Kryo tries to find a class to deserialize an object, and the stack traces end with something like:
> Caused by: java.lang.ClassNotFoundException: java.util.Date[SOH][GS]
> Note that the [SOH] and [GS] are not literally those strings, they're unprintable ASCII 0x1 and 0x1D.
> I'm confident that Kryo itself is not the source of the problem. I added some code to my project to deserialize the message on the sending node, immediately after serializing it, and log any exception thrown from the deserialization. The sending node did not log an exception, but the receiving node still did. My code passes the byte[] to the Message constructor without doing anything to it.
> It also appears that I am not the first person to encounter this issue. See https://code.google.com/p/kryo/issues/detail?id=102

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 07:17:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 17 Oct 2013 07:17:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1489) Incorrect heap description in
 VM metrics view
In-Reply-To: <JIRA.12493929.1370859389000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493929.1370859389000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493929.1370859389000.2822.1382008622090@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12817168#comment-12817168 ] 

RH Bugzilla Integration commented on WFLY-1489:
-----------------------------------------------

Jakub Cechacek <jcechace at redhat.com> made a comment on [bug 880648|https://bugzilla.redhat.com/show_bug.cgi?id=880648]

Verified 6.2.0.ER6 - this wasn't actually fixed but runtime statistics as whole were completely reworked. New BZs will be opened for any additional issues.
                
> Incorrect heap description in VM metrics view
> ---------------------------------------------
>
>                 Key: WFLY-1489
>                 URL: https://issues.jboss.org/browse/WFLY-1489
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web Console
>            Reporter: Heiko Braun
>            Assignee: Chao Wang
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 07:17:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 17 Oct 2013 07:17:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1489) Incorrect heap description in
 VM metrics view
In-Reply-To: <JIRA.12493929.1370859389000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493929.1370859389000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493929.1370859389000.2825.1382008622212@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12817169#comment-12817169 ] 

RH Bugzilla Integration commented on WFLY-1489:
-----------------------------------------------

Jakub Cechacek <jcechace at redhat.com> changed the Status of [bug 880648|https://bugzilla.redhat.com/show_bug.cgi?id=880648] from ON_QA to VERIFIED
                
> Incorrect heap description in VM metrics view
> ---------------------------------------------
>
>                 Key: WFLY-1489
>                 URL: https://issues.jboss.org/browse/WFLY-1489
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web Console
>            Reporter: Heiko Braun
>            Assignee: Chao Wang
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 07:47:02 2013
From: jira-events at lists.jboss.org (Josef Cacek (JIRA))
Date: Thu, 17 Oct 2013 07:47:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2328) Unable to deploy WS after
 (unrelated) http-listener changes
In-Reply-To: <JIRA.12505589.1382010398299@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12505589.1382010398299@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12505589.1382010398299.2867.1382010422229@jira02.app.mwc.hst.phx2.redhat.com>

Josef Cacek created WFLY-2328:
---------------------------------

             Summary: Unable to deploy WS after (unrelated) http-listener changes
                 Key: WFLY-2328
                 URL: https://issues.jboss.org/browse/WFLY-2328
             Project: WildFly
          Issue Type: Bug
          Components: Web Services
    Affects Versions: 8.0.0.Beta1
            Reporter: Josef Cacek
            Assignee: Alessio Soldano
            Priority: Critical


WS tests fail in basic integration testsuite if they run after
{{testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/management/api/web/ListenerTestCase.java}} (which usually doesn't happen on our TeamCity, but it's the case on my machine).

The logfile contains:
{code}
13:39:14,409 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017519: Undertow HTTP listener test-listener listening on localhost/127.0.0.1:8181
13:39:14,576 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017521: Undertow HTTP listener test-listener suspending
13:39:14,577 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017520: Undertow HTTP listener test-listener stopped, was bound to localhost/127.0.0.1:8181
13:39:14,943 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015876: Starting deployment of "jaxws-basic-pojo.war" (runtime-name: "jaxws-basic-pojo.war")
13:39:15,247 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.unit."jaxws-basic-pojo.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."jaxws-basic-pojo.war".INSTALL: JBAS018733: Failed to process phase INSTALL of deployment "jaxws-basic-pojo.war"
	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
Caused by: java.lang.IllegalStateException
	at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:47) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
	at org.wildfly.extension.undertow.WebServerService.getPort(WebServerService.java:64)
	at org.jboss.as.webservices.config.WebServerInfoImpl.getPort(WebServerInfoImpl.java:36)
	at org.jboss.ws.common.management.AbstractServerConfig.getConnectorPort(AbstractServerConfig.java:207)
	at org.jboss.ws.common.management.AbstractServerConfig.getWebServicePort(AbstractServerConfig.java:170)
	at org.jboss.ws.common.deployment.EndpointAddressDeploymentAspect$PortValue.getPortValue(EndpointAddressDeploymentAspect.java:198)
	at org.jboss.ws.common.deployment.EndpointAddressDeploymentAspect$PortValue.getValue(EndpointAddressDeploymentAspect.java:191)
	at org.jboss.ws.common.deployment.EndpointAddressDeploymentAspect.start(EndpointAddressDeploymentAspect.java:77)
	at org.jboss.as.webservices.deployers.AspectDeploymentProcessor.deploy(AspectDeploymentProcessor.java:75)
	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta1.jar:8.0.0.Beta1]
	... 5 more

13:39:15,260 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014613: Operation ("deploy") failed - address: (\{"deployment" => "jaxws-basic-pojo.war"\}) - failure description: \{"JBAS014671: Failed services" => \{"jboss.deployment.unit.\"jaxws-basic-pojo.war\".INSTALL" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"jaxws-basic-pojo.war\".INSTALL: JBAS018733: Failed to process phase INSTALL of deployment \"jaxws-basic-pojo.war\"
    Caused by: java.lang.IllegalStateException"\}\}
13:39:15,263 ERROR [org.jboss.as.server] (management-handler-thread - 4) JBAS015870: Deploy of deployment "jaxws-basic-pojo.war" was rolled back with the following failure message: 
\{"JBAS014671: Failed services" => \{"jboss.deployment.unit.\"jaxws-basic-pojo.war\".INSTALL" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"jaxws-basic-pojo.war\".INSTALL: JBAS018733: Failed to process phase INSTALL of deployment \"jaxws-basic-pojo.war\"
    Caused by: java.lang.IllegalStateException"\}\}
13:39:15,274 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-7) JBAS015877: Stopped deployment jaxws-basic-pojo.war (runtime-name: jaxws-basic-pojo.war) in 11ms
13:39:15,275 INFO  [org.jboss.as.controller] (management-handler-thread - 4) JBAS014774: Service status report
JBAS014777:   Services which failed to start:      service jboss.deployment.unit."jaxws-basic-pojo.war".INSTALL
{code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 07:51:02 2013
From: jira-events at lists.jboss.org (Josef Cacek (JIRA))
Date: Thu, 17 Oct 2013 07:51:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2328) Unable to deploy WS after
 (unrelated) http-listener changes
In-Reply-To: <JIRA.12505589.1382010398000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12505589.1382010398000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12505589.1382010398000.2874.1382010662132@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Josef Cacek updated WFLY-2328:
------------------------------

    Attachment: jaxws-basic-pojo.war

    
> Unable to deploy WS after (unrelated) http-listener changes
> -----------------------------------------------------------
>
>                 Key: WFLY-2328
>                 URL: https://issues.jboss.org/browse/WFLY-2328
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web Services
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Josef Cacek
>            Assignee: Alessio Soldano
>            Priority: Critical
>         Attachments: jaxws-basic-pojo.war
>
>
> WS tests fail in basic integration testsuite if they run after
> {{testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/management/api/web/ListenerTestCase.java}} (which usually doesn't happen on our TeamCity, but it's the case on my machine).
> The logfile contains:
> {code}
> 13:39:14,409 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017519: Undertow HTTP listener test-listener listening on localhost/127.0.0.1:8181
> 13:39:14,576 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017521: Undertow HTTP listener test-listener suspending
> 13:39:14,577 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017520: Undertow HTTP listener test-listener stopped, was bound to localhost/127.0.0.1:8181
> 13:39:14,943 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015876: Starting deployment of "jaxws-basic-pojo.war" (runtime-name: "jaxws-basic-pojo.war")
> 13:39:15,247 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.unit."jaxws-basic-pojo.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."jaxws-basic-pojo.war".INSTALL: JBAS018733: Failed to process phase INSTALL of deployment "jaxws-basic-pojo.war"
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: java.lang.IllegalStateException
> 	at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:47) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at org.wildfly.extension.undertow.WebServerService.getPort(WebServerService.java:64)
> 	at org.jboss.as.webservices.config.WebServerInfoImpl.getPort(WebServerInfoImpl.java:36)
> 	at org.jboss.ws.common.management.AbstractServerConfig.getConnectorPort(AbstractServerConfig.java:207)
> 	at org.jboss.ws.common.management.AbstractServerConfig.getWebServicePort(AbstractServerConfig.java:170)
> 	at org.jboss.ws.common.deployment.EndpointAddressDeploymentAspect$PortValue.getPortValue(EndpointAddressDeploymentAspect.java:198)
> 	at org.jboss.ws.common.deployment.EndpointAddressDeploymentAspect$PortValue.getValue(EndpointAddressDeploymentAspect.java:191)
> 	at org.jboss.ws.common.deployment.EndpointAddressDeploymentAspect.start(EndpointAddressDeploymentAspect.java:77)
> 	at org.jboss.as.webservices.deployers.AspectDeploymentProcessor.deploy(AspectDeploymentProcessor.java:75)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	... 5 more
> 13:39:15,260 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014613: Operation ("deploy") failed - address: (\{"deployment" => "jaxws-basic-pojo.war"\}) - failure description: \{"JBAS014671: Failed services" => \{"jboss.deployment.unit.\"jaxws-basic-pojo.war\".INSTALL" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"jaxws-basic-pojo.war\".INSTALL: JBAS018733: Failed to process phase INSTALL of deployment \"jaxws-basic-pojo.war\"
>     Caused by: java.lang.IllegalStateException"\}\}
> 13:39:15,263 ERROR [org.jboss.as.server] (management-handler-thread - 4) JBAS015870: Deploy of deployment "jaxws-basic-pojo.war" was rolled back with the following failure message: 
> \{"JBAS014671: Failed services" => \{"jboss.deployment.unit.\"jaxws-basic-pojo.war\".INSTALL" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"jaxws-basic-pojo.war\".INSTALL: JBAS018733: Failed to process phase INSTALL of deployment \"jaxws-basic-pojo.war\"
>     Caused by: java.lang.IllegalStateException"\}\}
> 13:39:15,274 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-7) JBAS015877: Stopped deployment jaxws-basic-pojo.war (runtime-name: jaxws-basic-pojo.war) in 11ms
> 13:39:15,275 INFO  [org.jboss.as.controller] (management-handler-thread - 4) JBAS014774: Service status report
> JBAS014777:   Services which failed to start:      service jboss.deployment.unit."jaxws-basic-pojo.war".INSTALL
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 07:59:02 2013
From: jira-events at lists.jboss.org (Radoslav Husar (JIRA))
Date: Thu, 17 Oct 2013 07:59:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2303) mod_cluster XSD is missing
 property and worker-timeout definitions
In-Reply-To: <JIRA.12503065.1381830758000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503065.1381830758000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503065.1381830758000.2894.1382011142267@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-2303:
---------------------------------

    Bugzilla Update:   (was: Perform)

    
> mod_cluster XSD is missing property and worker-timeout definitions
> ------------------------------------------------------------------
>
>                 Key: WFLY-2303
>                 URL: https://issues.jboss.org/browse/WFLY-2303
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.CR1
>
>
> * worker-timeout
> * property
> are missing.
> Also missing in 7.x

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 07:59:02 2013
From: jira-events at lists.jboss.org (Radoslav Husar (JIRA))
Date: Thu, 17 Oct 2013 07:59:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2303) mod_cluster XSD is missing
 property and worker-timeout definitions
In-Reply-To: <JIRA.12503065.1381830758000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503065.1381830758000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503065.1381830758000.2897.1382011142437@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-2303:
---------------------------------

    Comment: was deleted

(was: Jay SenSharma <jsenshar at redhat.com> made a comment on [bug 1020142|https://bugzilla.redhat.com/show_bug.cgi?id=1020142]

Upstream Wildfly also has issue reported:
https://issues.jboss.org/browse/WFLY-2303)

    
> mod_cluster XSD is missing property and worker-timeout definitions
> ------------------------------------------------------------------
>
>                 Key: WFLY-2303
>                 URL: https://issues.jboss.org/browse/WFLY-2303
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.CR1
>
>
> * worker-timeout
> * property
> are missing.
> Also missing in 7.x

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 07:59:02 2013
From: jira-events at lists.jboss.org (Radoslav Husar (JIRA))
Date: Thu, 17 Oct 2013 07:59:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2303) mod_cluster XSD is missing
 property and worker-timeout definitions
In-Reply-To: <JIRA.12503065.1381830758000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503065.1381830758000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503065.1381830758000.2902.1382011142739@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-2303:
---------------------------------

    Comment: was deleted

(was: Michal Babacek <mbabacek at redhat.com> made a comment on [bug 1020142|https://bugzilla.redhat.com/show_bug.cgi?id=1020142]

No Jay, mod_cluster as such has virtually nothing to do with Clustering component.)

    
> mod_cluster XSD is missing property and worker-timeout definitions
> ------------------------------------------------------------------
>
>                 Key: WFLY-2303
>                 URL: https://issues.jboss.org/browse/WFLY-2303
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.CR1
>
>
> * worker-timeout
> * property
> are missing.
> Also missing in 7.x

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 08:01:04 2013
From: jira-events at lists.jboss.org (Radoslav Husar (JIRA))
Date: Thu, 17 Oct 2013 08:01:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2303) mod_cluster XSD is missing
 property and worker-timeout definitions
In-Reply-To: <JIRA.12503065.1381830758000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503065.1381830758000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503065.1381830758000.2906.1382011264958@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-2303:
---------------------------------

    Comment: was deleted

(was: Radoslav Husar <rhusar at redhat.com> made a comment on [bug 1020142|https://bugzilla.redhat.com/show_bug.cgi?id=1020142]

Started the process for 6.3. -- there is no 6.3, so 6.2..

The upstream is already fixed, see WFLY-2303.

@Michal: the reporter just copied the component from upstream issue where we dont differetiate between modcluster and clustering. Nevertheless, its better to use the specific component in EAP issue tracker.)

    
> mod_cluster XSD is missing property and worker-timeout definitions
> ------------------------------------------------------------------
>
>                 Key: WFLY-2303
>                 URL: https://issues.jboss.org/browse/WFLY-2303
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.CR1
>
>
> * worker-timeout
> * property
> are missing.
> Also missing in 7.x

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 09:02:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 17 Oct 2013 09:02:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1569) Not possible to reload server
 when JTS transactions are activated
In-Reply-To: <JIRA.12494844.1371818256000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494844.1371818256000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494844.1371818256000.3101.1382014922124@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12822820#comment-12822820 ] 

RH Bugzilla Integration commented on WFLY-1569:
-----------------------------------------------

Ondrej Chaloupka <ochaloup at redhat.com> changed the Status of [bug 1011379|https://bugzilla.redhat.com/show_bug.cgi?id=1011379] from ON_QA to VERIFIED
                
> Not possible to reload server when JTS transactions are activated
> -----------------------------------------------------------------
>
>                 Key: WFLY-1569
>                 URL: https://issues.jboss.org/browse/WFLY-1569
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Ond?ej Chaloupka
>            Assignee: Stefano Maestri
>
> When transactions are set for JTS being used
>  - <jts/> tag under transactions subsystem
>  - transactions="on" under jacorb subsystem
> then it is not possible to reload the server.
> The reload causes the following exception being shown.
> {code}
> 14:30:56,388 WARN  [com.arjuna.ats.jts] (MSC service thread 1-5) ARJUNA022083: JacOrbRCServiceInit - Failed to start RC service: org.omg.CORBA.OBJECT_NOT_EXIST: POA destroyed
>  at org.jacorb.poa.POA.checkDestructionApparent(POA.java:1409)                           
>  at org.jacorb.poa.POA.set_servant(POA.java:1979)                          
>  at com.arjuna.ats.internal.jts.orbspecific.jacorb.recoverycoordinators.JacOrbRCServiceInit.startRCservice(JacOrbRCServiceInit.java:197) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]        
>  at com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement.startRCservice(RecoveryEnablement.java:137) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]        
>  at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:66) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]         
>  at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:104) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]              
>  at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:224) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]               
>  at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65) [narayana-jts-integration-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]            
>  at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:139) [wildfly-transactions-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]              
>  at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1942) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]                
>  at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1875) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]                  
>  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]                       
>  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]                       
>  at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]                       
> 14:30:56,396 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.txn.ArjunaRecoveryManager: org.jboss.msc.service.StartException in service jboss.txn.ArjunaRecoveryManager: JBAS010101: Recovery manager create failed                                 
>  at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:142)                      
>  at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1942) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]                
>  at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1875) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]                  
>  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]                       
>  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]                       
>  at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]                       
> Caused by: java.lang.RuntimeException: ARJUNA012364: RecoveryActivator init failed for com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement            
>  at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:67)                 
>  at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:104)                      
>  at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:224)                       
>  at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65)                  
>  at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:139)                      
>  ... 5 more 
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Thu Oct 17 09:02:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 17 Oct 2013 09:02:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1852) Populate the Subject with the
 required prinicpals for rbac/audit logging earlier
In-Reply-To: <JIRA.12498266.1375974256000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498266.1375974256000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498266.1375974256000.3107.1382014922376@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-1852:
-----------------------------------

        Parent: WFLY-490
    Issue Type: Sub-task  (was: Feature Request)

    
> Populate the Subject with the required prinicpals for rbac/audit logging earlier
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-1852
>                 URL: https://issues.jboss.org/browse/WFLY-1852
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Security
>            Reporter: Kabir Khan
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> At the moment these are added in a number of places, see TODO comments with this JIRA id.
> I also commented your concern a few lines down for https://github.com/wildfly/wildfly/pull/4889#commitcomment-3808535: "Do we need to use the Remoting version of this Principal - not sure if a new Principal may be better that is used both for web and for Remoting."

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 09:02:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 17 Oct 2013 09:02:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1569) Not possible to reload server
 when JTS transactions are activated
In-Reply-To: <JIRA.12494844.1371818256000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494844.1371818256000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494844.1371818256000.3111.1382014922560@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12822822#comment-12822822 ] 

RH Bugzilla Integration commented on WFLY-1569:
-----------------------------------------------

Ondrej Chaloupka <ochaloup at redhat.com> made a comment on [bug 1011379|https://bugzilla.redhat.com/show_bug.cgi?id=1011379]

Verified for EAP 6.2.0.ER6
                
> Not possible to reload server when JTS transactions are activated
> -----------------------------------------------------------------
>
>                 Key: WFLY-1569
>                 URL: https://issues.jboss.org/browse/WFLY-1569
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Ond?ej Chaloupka
>            Assignee: Stefano Maestri
>
> When transactions are set for JTS being used
>  - <jts/> tag under transactions subsystem
>  - transactions="on" under jacorb subsystem
> then it is not possible to reload the server.
> The reload causes the following exception being shown.
> {code}
> 14:30:56,388 WARN  [com.arjuna.ats.jts] (MSC service thread 1-5) ARJUNA022083: JacOrbRCServiceInit - Failed to start RC service: org.omg.CORBA.OBJECT_NOT_EXIST: POA destroyed
>  at org.jacorb.poa.POA.checkDestructionApparent(POA.java:1409)                           
>  at org.jacorb.poa.POA.set_servant(POA.java:1979)                          
>  at com.arjuna.ats.internal.jts.orbspecific.jacorb.recoverycoordinators.JacOrbRCServiceInit.startRCservice(JacOrbRCServiceInit.java:197) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]        
>  at com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement.startRCservice(RecoveryEnablement.java:137) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]        
>  at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:66) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]         
>  at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:104) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]              
>  at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:224) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]               
>  at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65) [narayana-jts-integration-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]            
>  at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:139) [wildfly-transactions-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]              
>  at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1942) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]                
>  at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1875) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]                  
>  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]                       
>  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]                       
>  at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]                       
> 14:30:56,396 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.txn.ArjunaRecoveryManager: org.jboss.msc.service.StartException in service jboss.txn.ArjunaRecoveryManager: JBAS010101: Recovery manager create failed                                 
>  at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:142)                      
>  at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1942) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]                
>  at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1875) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]                  
>  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]                       
>  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]                       
>  at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]                       
> Caused by: java.lang.RuntimeException: ARJUNA012364: RecoveryActivator init failed for com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement            
>  at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:67)                 
>  at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:104)                      
>  at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:224)                       
>  at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65)                  
>  at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:139)                      
>  ... 5 more 
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Thu Oct 17 09:04:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 17 Oct 2013 09:04:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2044) Rework Subject propagation to
 avoid marshaling.
In-Reply-To: <JIRA.12500441.1378828999000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500441.1378828999000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500441.1378828999000.3118.1382015042047@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12822824#comment-12822824 ] 

Darran Lofthouse commented on WFLY-2044:
----------------------------------------

Going to get WFLY-1852 out the way first as that could have some minor alterations to the actual Principals used - the conversion from marshalling will then use this clarified set of Principals.

                
> Rework Subject propagation to avoid marshaling.
> -----------------------------------------------
>
>                 Key: WFLY-2044
>                 URL: https://issues.jboss.org/browse/WFLY-2044
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Rework Subject propagation to avoid marshalling - i.e. describe the contents of the Subject within the protocol and allow it to be reconstructed on the far side.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 09:12:01 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 17 Oct 2013 09:12:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1095) PicketBox 4.0.19.Final
In-Reply-To: <JIRA.12508065.1382015464594@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508065.1382015464594@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508065.1382015464594.3149.1382015521935@jira02.app.mwc.hst.phx2.redhat.com>

Jesper Pedersen created JBJCA-1095:
--------------------------------------

             Summary: PicketBox 4.0.19.Final
                 Key: JBJCA-1095
                 URL: https://issues.jboss.org/browse/JBJCA-1095
             Project: IronJacamar
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.1.1.Final




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 09:14:01 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 17 Oct 2013 09:14:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1096) H2 1.3.173
In-Reply-To: <JIRA.12508066.1382015610151@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508066.1382015610151@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508066.1382015610151.3152.1382015641949@jira02.app.mwc.hst.phx2.redhat.com>

Jesper Pedersen created JBJCA-1096:
--------------------------------------

             Summary: H2 1.3.173
                 Key: JBJCA-1096
                 URL: https://issues.jboss.org/browse/JBJCA-1096
             Project: IronJacamar
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.1.1.Final




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 09:22:02 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 17 Oct 2013 09:22:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1097) Jandex 1.1.0.Final
In-Reply-To: <JIRA.12508067.1382016105341@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508067.1382016105341@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508067.1382016105341.3171.1382016122315@jira02.app.mwc.hst.phx2.redhat.com>

Jesper Pedersen created JBJCA-1097:
--------------------------------------

             Summary: Jandex 1.1.0.Final
                 Key: JBJCA-1097
                 URL: https://issues.jboss.org/browse/JBJCA-1097
             Project: IronJacamar
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.1.1.Final




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 09:33:02 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 17 Oct 2013 09:33:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1098) JBoss Threads 2.1.1.Final
In-Reply-To: <JIRA.12508071.1382016727743@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508071.1382016727743@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508071.1382016727743.3232.1382016782310@jira02.app.mwc.hst.phx2.redhat.com>

Jesper Pedersen created JBJCA-1098:
--------------------------------------

             Summary: JBoss Threads 2.1.1.Final
                 Key: JBJCA-1098
                 URL: https://issues.jboss.org/browse/JBJCA-1098
             Project: IronJacamar
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.1.1.Final




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 09:51:02 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 17 Oct 2013 09:51:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1099) ShrinkWrap 1.2.0
In-Reply-To: <JIRA.12508078.1382017802329@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508078.1382017802329@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508078.1382017802329.3368.1382017862031@jira02.app.mwc.hst.phx2.redhat.com>

Jesper Pedersen created JBJCA-1099:
--------------------------------------

             Summary: ShrinkWrap 1.2.0
                 Key: JBJCA-1099
                 URL: https://issues.jboss.org/browse/JBJCA-1099
             Project: IronJacamar
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.1.1.Final




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 10:12:02 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 17 Oct 2013 10:12:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1100) JBoss Stdio 1.0.2.GA
In-Reply-To: <JIRA.12508082.1382019005843@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508082.1382019005843@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508082.1382019005843.3427.1382019122646@jira02.app.mwc.hst.phx2.redhat.com>

Jesper Pedersen created JBJCA-1100:
--------------------------------------

             Summary: JBoss Stdio 1.0.2.GA
                 Key: JBJCA-1100
                 URL: https://issues.jboss.org/browse/JBJCA-1100
             Project: IronJacamar
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.1.1.Final




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 10:57:03 2013
From: jira-events at lists.jboss.org (Kris Verlaenen (JIRA))
Date: Thu, 17 Oct 2013 10:57:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-208) Build 5.6.0-SNAPSHOT on
 jenkins and prepare for 5.6.0.Final release
In-Reply-To: <JIRA.12497703.1375285149000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497703.1375285149000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497703.1375285149000.3566.1382021823032@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12822900#comment-12822900 ] 

Kris Verlaenen commented on DROOLS-208:
---------------------------------------

Michael,  I don't think you need to do a jbpm-designer release, 2.4.0.Final should still work fine I believe, so feel free to exclude that repo
                
> Build 5.6.0-SNAPSHOT on jenkins and prepare for 5.6.0.Final release
> -------------------------------------------------------------------
>
>                 Key: DROOLS-208
>                 URL: https://issues.jboss.org/browse/DROOLS-208
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Davide Sottara
>            Assignee: Michael Biarnes Kiefer
>
> Requirements:
> 1) All repositories in the 5.6.x repository-list need to be branched from 5.5.x.
> https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/blob/5.6.x/script/repository-list.txt
> Note: the repository list is far less than master (so you can safely ignore uberfire etc).
> Warning 1: some repo's are already branched! Do not rebranch these: droolsjbpm-build-bootstrap, droolsjbpm-knowledge, drools
> Warning 2: You need to branch from 5.5.x (NOT master!) to this new branch 5.6.x
> Warning 3: jbpm uses different version numbering. You need to branch from jbpm 5.4.x to 5.5.x (NOT 5.6.x). All other repo's use the normal version.
> 2) All the 5.6.x branches (and 5.5.x for jbpm)'s versions need to change from 5.5.1-SNAPSHOT to 5.6.0-SNAPSHOT (and from 5.4.0-SNAPSHOT to 5.5.0-SNAPSHOT for jbpm).
> Note: droolsjbpm-tools's will need changes from 5.5.1.qualifier to 5.6.0.qualifier
> 3) Create a new jenkins view for "drools 5.6.x and jbpm 5.5.x"
> 4) Clone the 5.5.x jobs for all these repo's as 5.6.x jobs.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 11:01:03 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Thu, 17 Oct 2013 11:01:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-303) CCE when updating
	cron-scheduled rule
In-Reply-To: <JIRA.12508088.1382022039240@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508088.1382022039240@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508088.1382022039240.3612.1382022063883@jira02.app.mwc.hst.phx2.redhat.com>

Davide Sottara created DROOLS-303:
-------------------------------------

             Summary: CCE when updating cron-scheduled rule
                 Key: DROOLS-303
                 URL: https://issues.jboss.org/browse/DROOLS-303
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 5.5.1.Final
            Reporter: Davide Sottara
            Assignee: Mark Proctor


Regression: timer jobs are unnecessarily cast to JDKTimerJobs

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 11:19:01 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 17 Oct 2013 11:19:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1719) DefaultThreadFactory:
 newThread() names a thread twice
In-Reply-To: <JIRA.12508096.1382023094450@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508096.1382023094450@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508096.1382023094450.3726.1382023141959@jira02.app.mwc.hst.phx2.redhat.com>

Bela Ban created JGRP-1719:
------------------------------

             Summary: DefaultThreadFactory: newThread() names a thread twice
                 Key: JGRP-1719
                 URL: https://issues.jboss.org/browse/JGRP-1719
             Project: JGroups
          Issue Type: Enhancement
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 3.5


DefaultThreadFactory.newThread() creates a new thread with a name, but then calls renameThread(). 
This effectively names the thread *twice*, which is means the cost of thread creation is higher than  it should be (naming involves calling {{SecurityManager.checkAccess()}}.
SOLUTION:
Prepare the name *before* creating the thread and then pass the name to the constructor.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 11:48:02 2013
From: jira-events at lists.jboss.org (John Liptak (JIRA))
Date: Thu, 17 Oct 2013 11:48:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-838) Can't get implementing
 classname for JSR77 MBean
In-Reply-To: <JIRA.12480370.1354609982000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12480370.1354609982000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12480370.1354609982000.3841.1382024882060@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12822952#comment-12822952 ] 

John Liptak commented on WFLY-838:
----------------------------------

This bug also seems to prevent local connections from Java Mission Control (JMC).
                
> Can't get implementing classname for JSR77 MBean
> ------------------------------------------------
>
>                 Key: WFLY-838
>                 URL: https://issues.jboss.org/browse/WFLY-838
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMX
>            Reporter: Anders Welen
>            Priority: Minor
>             Fix For: Awaiting Volunteers
>
>
> The following exception are thrown when asking the MBean server for the classname implementing "jboss.jsr77:j2eeType=WebModule,name=MyWar.war,J2EEServer=default".
> It should be a legal call. Why are the code clearly states it's illegal?
>  
> java.lang.IllegalStateException: JBAS019905: Should not get called
>     at org.jboss.as.jsr77.managedobject.J2EEDeployedObjectHandlers$J2EEModuleHandler.queryObjectNames(J2EEDeployedObjectHandlers.java:245)
>     at org.jboss.as.jsr77.managedobject.BaseHandler.getMBeanInfo(BaseHandler.java:64)
>     at org.jboss.as.jsr77.managedobject.J2EEDeployedObjectHandlers.getMBeanInfo(J2EEDeployedObjectHandlers.java:147)
>     at org.jboss.as.jsr77.managedobject.ManagedObjectHandlerRegistry.getMBeanInfo(ManagedObjectHandlerRegistry.java:112)
>     at org.jboss.as.jsr77.subsystem.JSR77ManagementMBeanServer.getMBeanInfo(JSR77ManagementMBeanServer.java:179)
>     at org.jboss.as.jmx.PluggableMBeanServerImpl.getMBeanInfo(PluggableMBeanServerImpl.java:212)
>  
> The error can easily be triggered by using JConsole to browse the same MBean.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 11:50:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 17 Oct 2013 11:50:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-253) Importing a domain class
 named "Exception" raises an ambiguity exception during RHS compilation
In-Reply-To: <JIRA.12500159.1378411795000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500159.1378411795000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500159.1378411795000.3851.1382025002052@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12822954#comment-12822954 ] 

RH Bugzilla Integration commented on DROOLS-253:
------------------------------------------------

Tomas Schlosser <tschloss at redhat.com> changed the Status of [bug 1010281|https://bugzilla.redhat.com/show_bug.cgi?id=1010281] from ON_QA to VERIFIED
                
> Importing a domain class named "Exception" raises an ambiguity exception during RHS compilation
> -----------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-253
>                 URL: https://issues.jboss.org/browse/DROOLS-253
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final,  6.0.0.CR3
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Blocker
>             Fix For:  6.0.0.CR4
>
>
> If a user class named Exception is used,
> import my.own.domain.Exception
> rule "Foo"
> when then end
> the RHS compilation process resolves "Exception" to that name
> rather than to java.lang.Exception
> >> Rule compilation error [Rule name=Foo] : 
>    {if import * is used } The type Exception is ambiguous
>    {if explicit import is used } Exception is not Throwable

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 11:50:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 17 Oct 2013 11:50:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-253) Importing a domain class
 named "Exception" raises an ambiguity exception during RHS compilation
In-Reply-To: <JIRA.12500159.1378411795000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500159.1378411795000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500159.1378411795000.3855.1382025002271@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12822955#comment-12822955 ] 

RH Bugzilla Integration commented on DROOLS-253:
------------------------------------------------

Tomas Schlosser <tschloss at redhat.com> made a comment on [bug 1010281|https://bugzilla.redhat.com/show_bug.cgi?id=1010281]

Verified in BRMS 6.0.0.ER4.
                
> Importing a domain class named "Exception" raises an ambiguity exception during RHS compilation
> -----------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-253
>                 URL: https://issues.jboss.org/browse/DROOLS-253
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final,  6.0.0.CR3
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Blocker
>             Fix For:  6.0.0.CR4
>
>
> If a user class named Exception is used,
> import my.own.domain.Exception
> rule "Foo"
> when then end
> the RHS compilation process resolves "Exception" to that name
> rather than to java.lang.Exception
> >> Rule compilation error [Rule name=Foo] : 
>    {if import * is used } The type Exception is ambiguous
>    {if explicit import is used } Exception is not Throwable

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 11:50:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 17 Oct 2013 11:50:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1719) DefaultThreadFactory:
 newThread() names a thread twice
In-Reply-To: <JIRA.12508096.1382023094000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508096.1382023094000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508096.1382023094000.3858.1382025002421@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1719:
---------------------------

    Fix Version/s: 3.4.1

    
> DefaultThreadFactory: newThread() names a thread twice
> ------------------------------------------------------
>
>                 Key: JGRP-1719
>                 URL: https://issues.jboss.org/browse/JGRP-1719
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4.1, 3.5
>
>
> DefaultThreadFactory.newThread() creates a new thread with a name, but then calls renameThread(). 
> This effectively names the thread *twice*, which is means the cost of thread creation is higher than  it should be (naming involves calling {{SecurityManager.checkAccess()}}.
> SOLUTION:
> Prepare the name *before* creating the thread and then pass the name to the constructor.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 12:00:03 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 17 Oct 2013 12:00:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-836) Jboss 7.1.1 Final
 StartException on Domain Mode in Windows XP, It shows "Brontes" Starting
In-Reply-To: <JIRA.12463924.1334295236000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12463924.1334295236000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12463924.1334295236000.3912.1382025603178@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar closed WFLY-836.
----------------------------

    Resolution: Cannot Reproduce Bug


I was trying to reproduce this on multiple fully patched windows XP instances but failed to reproduce it.
Unless some more info on how to reproduce is provided there isn't anything we can do.
                
> Jboss 7.1.1 Final StartException on Domain Mode in Windows XP, It shows "Brontes" Starting
> ------------------------------------------------------------------------------------------
>
>                 Key: WFLY-836
>                 URL: https://issues.jboss.org/browse/WFLY-836
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>         Environment: Maser on Windows 7 and Slave on Windows XP SP2
>            Reporter: Paul Chan
>            Assignee: Tomaz Cerar
>
> Maser on Windows 7 and Slave on Windows XP SP2. Master has started without any error on windows 7. when i start slave on windows xp, it is registered with master but all the servers on slave are not starting. it shows "Brontes" starting. 
> CNTR+C(stopping) gives the error below
> Server:server-one] 10:00:26,859 ERROR [org.jboss.msc.service.fail] (MSC service
>  thread 1-4) MSC00001: Failed to start service jboss.as: org.jboss.msc.service.S
> tartException in service jboss.as: Failed to start service
> [Server:server-one]     at org.jboss.msc.service.ServiceControllerImpl$StartTask
> .run(ServiceControllerImpl.java:1767) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> [Server:server-one]     at java.util.concurrent.ThreadPoolExecutor$Worker.runTas
> k(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_31]
> [Server:server-one]     at java.util.concurrent.ThreadPoolExecutor$Worker.run(Th
> readPoolExecutor.java:908) [rt.jar:1.6.0_31]
> [Server:server-one]     at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_3
> 1]
> [Server:server-one] Caused by: java.lang.IllegalStateException: Container is dow
> n
> [Server:server-one]     at org.jboss.msc.service.ServiceContainerImpl.install(Se
> rviceContainerImpl.java:508) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> [Server:server-one]     at org.jboss.msc.service.ServiceTargetImpl.install(Servi
> ceTargetImpl.java:201) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> [Server:server-one]     at org.jboss.msc.service.ServiceControllerImpl$ChildServ
> iceTarget.install(ServiceControllerImpl.java:2228) [jboss-msc-1.0.2.GA.jar:1.0.2
> .GA]
> [Server:server-one]     at org.jboss.msc.service.ServiceBuilderImpl.install(Serv
> iceBuilderImpl.java:307) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> [Server:server-one]     at org.jboss.as.server.DomainServerMain.addCommunication
> Services(DomainServerMain.java:192) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final
> ]
> [Server:server-one]     at org.jboss.as.server.DomainServerMain.access$000(Domai
> nServerMain.java:73) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> [Server:server-one]     at org.jboss.as.server.DomainServerMain$HostControllerCo
> mmunicationActivator.activate(DomainServerMain.java:227) [jboss-as-server-7.1.1.
> Final.jar:7.1.1.Final]
> [Server:server-one]     at org.jboss.as.server.ApplicationServerService.start(Ap
> plicationServerService.java:155) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> [Server:server-one]     at org.jboss.msc.service.ServiceControllerImpl$StartTask
> .startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> [Server:server-two] 10:00:26,843 ERROR [org.jboss.msc.service.fail] (MSC service
>  thread 1-4) MSC00001: Failed to start service jboss.as: org.jboss.msc.service.S
> tartException in service jboss.as: Failed to start service
> [Server:server-two]     at org.jboss.msc.service.ServiceControllerImpl$StartTask
> .run(ServiceControllerImpl.java:1767) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> [Server:server-two]     at java.util.concurrent.ThreadPoolExecutor$Worker.runTas
> k(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_31]
> [Server:server-two]     at java.util.concurrent.ThreadPoolExecutor$Worker.run(Th
> readPoolExecutor.java:908) [rt.jar:1.6.0_31]
> [Server:server-two]     at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_3
> 1]
> [Server:server-two] Caused by: java.lang.IllegalStateException: Container is dow
> n
> [Server:server-one]     at org.jboss.msc.service.ServiceControllerImpl$StartTask
> .run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> [Server:server-one]     ... 3 more
> [Server:server-one]
> [Server:server-two]     at org.jboss.msc.service.ServiceContainerImpl.install(Se
> rviceContainerImpl.java:508) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> [Server:server-two]     at org.jboss.msc.service.ServiceTargetImpl.install(Servi
> ceTargetImpl.java:201) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> [Server:server-two]     at org.jboss.msc.service.ServiceControllerImpl$ChildServ
> iceTarget.install(ServiceControllerImpl.java:2228) [jboss-msc-1.0.2.GA.jar:1.0.2
> .GA]
> [Server:server-two]     at org.jboss.msc.service.ServiceBuilderImpl.install(Serv
> iceBuilderImpl.java:307) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> [Server:server-two]     at org.jboss.as.server.DomainServerMain.addCommunication
> Services(DomainServerMain.java:192) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final
> ]
> [Server:server-two]     at org.jboss.as.server.DomainServerMain.access$000(Domai
> nServerMain.java:73) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> 10:00:26,953 INFO  [org.jboss.as.process.Server:server-one.status] (reaper for S
> erver:server-one) JBAS012010: Process 'Server:server-one' finished with an exit
> status of 0
> [Server:server-two]     at org.jboss.as.server.DomainServerMain$HostControllerCo
> mmunicationActivator.activate(DomainServerMain.java:227) [jboss-as-server-7.1.1.
> Final.jar:7.1.1.Final]
> [Server:server-two]     at org.jboss.as.server.ApplicationServerService.start(Ap
> plicationServerService.java:155) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> [Server:server-two]     at org.jboss.msc.service.ServiceControllerImpl$StartTask
> .startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> [Server:server-two]     at org.jboss.msc.service.ServiceControllerImpl$StartTask
> .run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> [Server:server-two]     ... 3 more
> [Server:server-two]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 12:02:02 2013
From: jira-events at lists.jboss.org (Tom Jenkinson (JIRA))
Date: Thu, 17 Oct 2013 12:02:02 -0400 (EDT)
Subject: [jboss-jira] =?utf-8?q?=5BJBoss_JIRA=5D_=28JBJCA-1101=29_Downgrad?=
 =?utf-8?q?e_logging_of_XAException=3A=3AXA=5FRB=E2=88=97_during_XAResourc?=
 =?utf-8?b?ZTo6ZW5kKFRNRkFJTCk=?=
In-Reply-To: <JIRA.12508104.1382025703545@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508104.1382025703545@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508104.1382025703545.3918.1382025722434@jira02.app.mwc.hst.phx2.redhat.com>

Tom Jenkinson created JBJCA-1101:
------------------------------------

             Summary: Downgrade logging of XAException::XA_RB? during XAResource::end(TMFAIL)
                 Key: JBJCA-1101
                 URL: https://issues.jboss.org/browse/JBJCA-1101
             Project: IronJacamar
          Issue Type: Feature Request
            Reporter: Tom Jenkinson
            Assignee: Jesper Pedersen


In org.jboss.jca.adapters.jdbc.xa.XAManagedConnection:

{code}
try
         {
            xaResource.end(xid, flags);
         }
         catch (XAException e)
         {
            broadcastConnectionError(e);
            throw e;
         }
{code}

If we pass in TMFAIL to this method, according to XA we would expect an XAException::XA_RB* to be returned so do not log this as a warning. You can see how we handle this in JBTM over here: 

https://github.com/jbosstm/narayana/blob/540c689168fa2fd3db38d4ae1c3487c5d1ff7aff/ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/resources/arjunacore/XAResourceRecord.java#L317

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Thu Oct 17 12:10:01 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 17 Oct 2013 12:10:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1719) DefaultThreadFactory:
 newThread() names a thread twice
In-Reply-To: <JIRA.12508096.1382023094000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508096.1382023094000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508096.1382023094000.3952.1382026201972@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1719.
----------------------------

    Resolution: Done

    
> DefaultThreadFactory: newThread() names a thread twice
> ------------------------------------------------------
>
>                 Key: JGRP-1719
>                 URL: https://issues.jboss.org/browse/JGRP-1719
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4.1, 3.5
>
>
> DefaultThreadFactory.newThread() creates a new thread with a name, but then calls renameThread(). 
> This effectively names the thread *twice*, which is means the cost of thread creation is higher than  it should be (naming involves calling {{SecurityManager.checkAccess()}}.
> SOLUTION:
> Prepare the name *before* creating the thread and then pass the name to the constructor.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 12:12:02 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 17 Oct 2013 12:12:02 -0400 (EDT)
Subject: [jboss-jira] =?utf-8?q?=5BJBoss_JIRA=5D_=28JBJCA-1101=29_Downgrad?=
 =?utf-8?q?e_logging_of_XAException=3A=3AXA=5FRB=E2=88=97_during_XAResourc?=
 =?utf-8?b?ZTo6ZW5kKFRNRkFJTCk=?=
In-Reply-To: <JIRA.12508104.1382025703000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508104.1382025703000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508104.1382025703000.3961.1382026322237@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated JBJCA-1101:
-----------------------------------

           Issue Type: Bug  (was: Feature Request)
        Fix Version/s: 1.0.22.Final
                       1.1.1.Final
    Affects Version/s: 1.1.0.Final
                       1.0.21.Final
          Component/s: JDBC

    
> Downgrade logging of XAException::XA_RB? during XAResource::end(TMFAIL)
> -----------------------------------------------------------------------
>
>                 Key: JBJCA-1101
>                 URL: https://issues.jboss.org/browse/JBJCA-1101
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: JDBC
>    Affects Versions: 1.0.21.Final, 1.1.0.Final
>            Reporter: Tom Jenkinson
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.22.Final, 1.1.1.Final
>
>
> In org.jboss.jca.adapters.jdbc.xa.XAManagedConnection:
> {code}
> try
>          {
>             xaResource.end(xid, flags);
>          }
>          catch (XAException e)
>          {
>             broadcastConnectionError(e);
>             throw e;
>          }
> {code}
> If we pass in TMFAIL to this method, according to XA we would expect an XAException::XA_RB* to be returned so do not log this as a warning. You can see how we handle this in JBTM over here: 
> https://github.com/jbosstm/narayana/blob/540c689168fa2fd3db38d4ae1c3487c5d1ff7aff/ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/resources/arjunacore/XAResourceRecord.java#L317

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Thu Oct 17 12:20:02 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 17 Oct 2013 12:20:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2328) Unable to deploy WS after
 (unrelated) http-listener changes
In-Reply-To: <JIRA.12505589.1382010398000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12505589.1382010398000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12505589.1382010398000.3974.1382026802057@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar reassigned WFLY-2328:
---------------------------------

    Assignee: Tomaz Cerar  (was: Alessio Soldano)

    
> Unable to deploy WS after (unrelated) http-listener changes
> -----------------------------------------------------------
>
>                 Key: WFLY-2328
>                 URL: https://issues.jboss.org/browse/WFLY-2328
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web Services
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Josef Cacek
>            Assignee: Tomaz Cerar
>            Priority: Critical
>         Attachments: jaxws-basic-pojo.war
>
>
> WS tests fail in basic integration testsuite if they run after
> {{testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/management/api/web/ListenerTestCase.java}} (which usually doesn't happen on our TeamCity, but it's the case on my machine).
> The logfile contains:
> {code}
> 13:39:14,409 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017519: Undertow HTTP listener test-listener listening on localhost/127.0.0.1:8181
> 13:39:14,576 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017521: Undertow HTTP listener test-listener suspending
> 13:39:14,577 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017520: Undertow HTTP listener test-listener stopped, was bound to localhost/127.0.0.1:8181
> 13:39:14,943 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015876: Starting deployment of "jaxws-basic-pojo.war" (runtime-name: "jaxws-basic-pojo.war")
> 13:39:15,247 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.unit."jaxws-basic-pojo.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."jaxws-basic-pojo.war".INSTALL: JBAS018733: Failed to process phase INSTALL of deployment "jaxws-basic-pojo.war"
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: java.lang.IllegalStateException
> 	at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:47) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at org.wildfly.extension.undertow.WebServerService.getPort(WebServerService.java:64)
> 	at org.jboss.as.webservices.config.WebServerInfoImpl.getPort(WebServerInfoImpl.java:36)
> 	at org.jboss.ws.common.management.AbstractServerConfig.getConnectorPort(AbstractServerConfig.java:207)
> 	at org.jboss.ws.common.management.AbstractServerConfig.getWebServicePort(AbstractServerConfig.java:170)
> 	at org.jboss.ws.common.deployment.EndpointAddressDeploymentAspect$PortValue.getPortValue(EndpointAddressDeploymentAspect.java:198)
> 	at org.jboss.ws.common.deployment.EndpointAddressDeploymentAspect$PortValue.getValue(EndpointAddressDeploymentAspect.java:191)
> 	at org.jboss.ws.common.deployment.EndpointAddressDeploymentAspect.start(EndpointAddressDeploymentAspect.java:77)
> 	at org.jboss.as.webservices.deployers.AspectDeploymentProcessor.deploy(AspectDeploymentProcessor.java:75)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	... 5 more
> 13:39:15,260 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014613: Operation ("deploy") failed - address: (\{"deployment" => "jaxws-basic-pojo.war"\}) - failure description: \{"JBAS014671: Failed services" => \{"jboss.deployment.unit.\"jaxws-basic-pojo.war\".INSTALL" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"jaxws-basic-pojo.war\".INSTALL: JBAS018733: Failed to process phase INSTALL of deployment \"jaxws-basic-pojo.war\"
>     Caused by: java.lang.IllegalStateException"\}\}
> 13:39:15,263 ERROR [org.jboss.as.server] (management-handler-thread - 4) JBAS015870: Deploy of deployment "jaxws-basic-pojo.war" was rolled back with the following failure message: 
> \{"JBAS014671: Failed services" => \{"jboss.deployment.unit.\"jaxws-basic-pojo.war\".INSTALL" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"jaxws-basic-pojo.war\".INSTALL: JBAS018733: Failed to process phase INSTALL of deployment \"jaxws-basic-pojo.war\"
>     Caused by: java.lang.IllegalStateException"\}\}
> 13:39:15,274 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-7) JBAS015877: Stopped deployment jaxws-basic-pojo.war (runtime-name: jaxws-basic-pojo.war) in 11ms
> 13:39:15,275 INFO  [org.jboss.as.controller] (management-handler-thread - 4) JBAS014774: Service status report
> JBAS014777:   Services which failed to start:      service jboss.deployment.unit."jaxws-basic-pojo.war".INSTALL
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 12:27:02 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 17 Oct 2013 12:27:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1102) JBoss Logging 3.1.3.GA
In-Reply-To: <JIRA.12508108.1382027201335@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508108.1382027201335@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508108.1382027201335.3983.1382027222047@jira02.app.mwc.hst.phx2.redhat.com>

Jesper Pedersen created JBJCA-1102:
--------------------------------------

             Summary: JBoss Logging 3.1.3.GA
                 Key: JBJCA-1102
                 URL: https://issues.jboss.org/browse/JBJCA-1102
             Project: IronJacamar
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.1.1.Final




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 12:29:01 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 17 Oct 2013 12:29:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1103) JBoss LogManager 1.5.0.Final
In-Reply-To: <JIRA.12508109.1382027238160@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508109.1382027238160@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508109.1382027238160.3990.1382027341968@jira02.app.mwc.hst.phx2.redhat.com>

Jesper Pedersen created JBJCA-1103:
--------------------------------------

             Summary: JBoss LogManager 1.5.0.Final
                 Key: JBJCA-1103
                 URL: https://issues.jboss.org/browse/JBJCA-1103
             Project: IronJacamar
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.1.1.Final




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 12:29:02 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 17 Oct 2013 12:29:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1104) JBoss Logmanager Log4J
	1.0.2.Final
In-Reply-To: <JIRA.12508110.1382027268117@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508110.1382027268117@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508110.1382027268117.3993.1382027342109@jira02.app.mwc.hst.phx2.redhat.com>

Jesper Pedersen created JBJCA-1104:
--------------------------------------

             Summary: JBoss Logmanager Log4J 1.0.2.Final
                 Key: JBJCA-1104
                 URL: https://issues.jboss.org/browse/JBJCA-1104
             Project: IronJacamar
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.1.1.Final




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 13:06:02 2013
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Thu, 17 Oct 2013 13:06:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2298) Redesign @Stateful EJB
	clustering
In-Reply-To: <JIRA.12502968.1381765293000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502968.1381765293000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502968.1381765293000.4067.1382029562370@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12822982#comment-12822982 ] 

Paul Ferraro commented on WFLY-2298:
------------------------------------

Yes.  Infinispan's distribution mode is designed for just this purpose.  State is only replicated to a configurable number of owners (per your availability requirements), where the effective master (i.e. the node on which locks get acquired) of a given SFSB is determined at the time of SFSB creation.  Weak affinity of an SFSB is then assigned to the owning node.
                
> Redesign @Stateful EJB clustering
> ---------------------------------
>
>                 Key: WFLY-2298
>                 URL: https://issues.jboss.org/browse/WFLY-2298
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Clustering
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 9.0.0.CR1
>
>
> The current @Stateful EJB clustering design has a number of flaws:
> * The current implementation is very slow.  Each EJB invocation results in 4 Infinispan transactions!  Cache.get(...) and Cache.release(...) result in 2 transactions each, 1 for bean cache and 1 for group cache
> * An external locking mechanism is used to guard the SFSB against access from other nodes between Cache.get(...) and Cache.release(...)
> * Because the current design uses 2 separate cache instances, data is not correctly isolated and can cause integrity issues
> * The current design uses a global group cache, which results in classloader leaks when a server has multiple EJB deployments (MarshalledValues in the group cache, which survives undeployment, can still reference the classloader of an undeployed EJB)
> * The lifecycle of the global group cache does not leverage the MSC and thus is prone to race conditions by multiple SFSB deployments
> * State changes that occur to the SFSB during activation/passivation callbacks are not correctly replicated.
> * The @Clustered annotation currently has 2 orthogonal meanings:
> 	1. If applied to a @Stateful EJB, then a specific cache will be used (as defined by the EJB subsystem)
> 	2. If applied to a @Stateless or @Stateful EJB, remote EJB clients will have a dynamic view of the EJB's topology.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 13:10:02 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 17 Oct 2013 13:10:02 -0400 (EDT)
Subject: [jboss-jira] =?utf-8?q?=5BJBoss_JIRA=5D_=28JBJCA-1101=29_Downgrad?=
 =?utf-8?q?e_logging_of_XAException=3A=3AXA=5FRB=E2=88=97_during_XAResourc?=
 =?utf-8?b?ZTo6ZW5kKFRNRkFJTCk=?=
In-Reply-To: <JIRA.12508104.1382025703000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508104.1382025703000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508104.1382025703000.4082.1382029802004@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBJCA-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12822984#comment-12822984 ] 

Jesper Pedersen commented on JBJCA-1101:
----------------------------------------

PR: https://github.com/ironjacamar/ironjacamar/pull/84
                
> Downgrade logging of XAException::XA_RB? during XAResource::end(TMFAIL)
> -----------------------------------------------------------------------
>
>                 Key: JBJCA-1101
>                 URL: https://issues.jboss.org/browse/JBJCA-1101
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: JDBC
>    Affects Versions: 1.0.21.Final, 1.1.0.Final
>            Reporter: Tom Jenkinson
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.22.Final, 1.1.1.Final
>
>
> In org.jboss.jca.adapters.jdbc.xa.XAManagedConnection:
> {code}
> try
>          {
>             xaResource.end(xid, flags);
>          }
>          catch (XAException e)
>          {
>             broadcastConnectionError(e);
>             throw e;
>          }
> {code}
> If we pass in TMFAIL to this method, according to XA we would expect an XAException::XA_RB* to be returned so do not log this as a warning. You can see how we handle this in JBTM over here: 
> https://github.com/jbosstm/narayana/blob/540c689168fa2fd3db38d4ae1c3487c5d1ff7aff/ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/resources/arjunacore/XAResourceRecord.java#L317

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Thu Oct 17 13:12:02 2013
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Thu, 17 Oct 2013 13:12:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-299) Support rule configuration
 in a web archive
In-Reply-To: <JIRA.12503061.1381828954000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503061.1381828954000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503061.1381828954000.4085.1382029922000@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12822985#comment-12822985 ] 

Mark Proctor commented on DROOLS-299:
-------------------------------------

for JBoss AS you need to have the VFS jar on the classpath, or it's not VFS aware:
https://github.com/droolsjbpm/droolsjbpm-integration/tree/master/drools-jboss-integration
                
> Support rule configuration in a web archive
> -------------------------------------------
>
>                 Key: DROOLS-299
>                 URL: https://issues.jboss.org/browse/DROOLS-299
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>            Reporter: Shane Bryzak
>            Assignee: Mario Fusco
>
> I'm currently working on integration between PicketLink and Drools to provide rule-based security permissions which control access to protected application resources, similar to a feature that we had in Seam 2:
> https://github.com/seam2/jboss-seam/blob/Seam_2_3/jboss-seam/src/main/java/org/jboss/seam/security/permission/RuleBasedPermissionResolver.java
> The following quickstart (work in progress) is intended to demonstrate this integration:
> https://github.com/picketlink/picketlink-quickstarts/tree/master/picketlink-authorization-drools
> Building this quickstart first requires building the latest trunk of PicketLink locally:
> https://github.com/picketlink/picketlink
> What we would like is to allow the developer to define their security rules in the war project itself.  Currently the quickstart defines the following kmodule.xml file in the src/main/resources/META-INF directory:
> <?xml version="1.0" encoding="UTF-8"?>
> <kmodule xmlns="http://jboss.org/kie/6.0.0/kmodule">
>   <kbase name="security" default="true">
>     <ksession name="ksession1" default="true"/>
>   </kbase>
> </kmodule>
> There is also a security-rules.drl file in the src/main/resources/security directory which defines the security rules.
> Deployment of the quickstart yields the following errors and partial stacktrace:
> 18:52:56,036 INFO  [org.drools.compiler.kie.builder.impl.ClasspathKieProject] (MSC service thread 1-7) Found kmodule: vfs:/content/picketlink-authorization-drools.war/WEB-INF/classes/META-INF/kmodule.xml
> 18:52:56,036 INFO  [org.drools.compiler.kie.builder.impl.ClasspathKieProject] (MSC service thread 1-7) Virtual file physical path = /home/shane/apps/jboss/standalone/tmp/vfs/tempa9983c4071e1249/picketlink-authorization-drools.war-1c243fd87ed695cf/WEB-INF/classes
> 18:52:56,060 WARN  [org.drools.compiler.kie.builder.impl.ClasspathKieProject] (MSC service thread 1-7) Unable to load pom.properties tried recursing down from/home/shane/apps/jboss/standalone/tmp/vfs/tempa9983c4071e1249/picketlink-authorization-drools.war-1c243fd87ed695cf/WEB-INF/classes
> null
> 18:52:56,061 ERROR [org.drools.compiler.kie.builder.impl.ClasspathKieProject] (MSC service thread 1-7) Unable to build index of kmodule.xml url=vfs:/content/picketlink-authorization-drools.war/WEB-INF/classes/META-INF/kmodule.xml
> null
> 18:52:56,140 ERROR [org.drools.compiler.cdi.KieCDIExtension] (MSC service thread 1-7) Annotation @KSession(ksession1) found, but no KieSessioneModel exist.
> Either the required kproject.xml does not exist, was corrupted, or mising the KieBase entry
> 18:52:56,160 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC00001: Failed to start service jboss.deployment.unit."picketlink-authorization-drools.war".WeldService: org.jboss.msc.service.StartException in service jboss.deployment.unit."picketlink-authorization-drools.war".WeldService: org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [KieSession] with qualifiers [@KSession] at injection point [[field] @Inject @KSession org.jboss.as.quickstarts.picketlink.authorization.drools.PermissionAuthorizer.kSession]
> 	at org.jboss.as.weld.services.WeldService.start(WeldService.java:83)
> Mario indicated (during a discussion on IRC) that the rules are currently expected to be deployed within a separate jar file (which is then packaged as a library in the war), however our users are likely to view this as an extraneous requirement.  It would be far more convenient to allow them to create their rule definitions within the war project itself, and also be easier to promote this integration via tutorials and quickstarts.
> Thanks for looking into this!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 13:31:02 2013
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Thu, 17 Oct 2013 13:31:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2298) Redesign @Stateful EJB
	clustering
In-Reply-To: <JIRA.12502968.1381765293000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502968.1381765293000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502968.1381765293000.4130.1382031062023@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro updated WFLY-2298:
-------------------------------

    Description: 
The current @Stateful EJB clustering design has a number of flaws:
* The current implementation is very slow.  Each EJB invocation results in 4 Infinispan transactions!  Cache.get(...) and Cache.release(...) result in 2 transactions each, 1 for bean cache and 1 for group cache
* An external locking mechanism is used to guard the SFSB against access from other nodes between Cache.get(...) and Cache.release(...)
* Because the current design uses 2 separate cache instances, data is not correctly isolated and can cause integrity issues
* The current design uses a global group cache, which results in classloader leaks when a server has multiple EJB deployments (MarshalledValues in the group cache, which survives undeployment, can still reference the classloader of an undeployed EJB)
* The lifecycle of the global group cache does not leverage the MSC and thus is prone to race conditions by multiple SFSB deployments
* State changes that occur to the SFSB during activation/passivation callbacks are not correctly replicated.
* The @Clustered annotation currently has 2 orthogonal meanings:
	1. If applied to a @Stateful EJB, then a specific cache will be used (as defined by the EJB subsystem)
	2. If applied to a @Stateless or @Stateful EJB, remote EJB clients will have a dynamic view of the EJB's topology.
* Eager passivation is unnecessarily expensive, and makes the eventual SFSB removal slower.

  was:
The current @Stateful EJB clustering design has a number of flaws:
* The current implementation is very slow.  Each EJB invocation results in 4 Infinispan transactions!  Cache.get(...) and Cache.release(...) result in 2 transactions each, 1 for bean cache and 1 for group cache
* An external locking mechanism is used to guard the SFSB against access from other nodes between Cache.get(...) and Cache.release(...)
* Because the current design uses 2 separate cache instances, data is not correctly isolated and can cause integrity issues
* The current design uses a global group cache, which results in classloader leaks when a server has multiple EJB deployments (MarshalledValues in the group cache, which survives undeployment, can still reference the classloader of an undeployed EJB)
* The lifecycle of the global group cache does not leverage the MSC and thus is prone to race conditions by multiple SFSB deployments
* State changes that occur to the SFSB during activation/passivation callbacks are not correctly replicated.
* The @Clustered annotation currently has 2 orthogonal meanings:
	1. If applied to a @Stateful EJB, then a specific cache will be used (as defined by the EJB subsystem)
	2. If applied to a @Stateless or @Stateful EJB, remote EJB clients will have a dynamic view of the EJB's topology.


    
> Redesign @Stateful EJB clustering
> ---------------------------------
>
>                 Key: WFLY-2298
>                 URL: https://issues.jboss.org/browse/WFLY-2298
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Clustering
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 9.0.0.CR1
>
>
> The current @Stateful EJB clustering design has a number of flaws:
> * The current implementation is very slow.  Each EJB invocation results in 4 Infinispan transactions!  Cache.get(...) and Cache.release(...) result in 2 transactions each, 1 for bean cache and 1 for group cache
> * An external locking mechanism is used to guard the SFSB against access from other nodes between Cache.get(...) and Cache.release(...)
> * Because the current design uses 2 separate cache instances, data is not correctly isolated and can cause integrity issues
> * The current design uses a global group cache, which results in classloader leaks when a server has multiple EJB deployments (MarshalledValues in the group cache, which survives undeployment, can still reference the classloader of an undeployed EJB)
> * The lifecycle of the global group cache does not leverage the MSC and thus is prone to race conditions by multiple SFSB deployments
> * State changes that occur to the SFSB during activation/passivation callbacks are not correctly replicated.
> * The @Clustered annotation currently has 2 orthogonal meanings:
> 	1. If applied to a @Stateful EJB, then a specific cache will be used (as defined by the EJB subsystem)
> 	2. If applied to a @Stateless or @Stateful EJB, remote EJB clients will have a dynamic view of the EJB's topology.
> * Eager passivation is unnecessarily expensive, and makes the eventual SFSB removal slower.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 13:57:09 2013
From: jira-events at lists.jboss.org (Domen Cebulj (JIRA))
Date: Thu, 17 Oct 2013 13:57:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2329) File upload doesn't work
In-Reply-To: <JIRA.12508122.1382032527251@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508122.1382032527251@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508122.1382032527251.4176.1382032629231@jira02.app.mwc.hst.phx2.redhat.com>

Domen Cebulj created WFLY-2329:
----------------------------------

             Summary: File upload doesn't work
                 Key: WFLY-2329
                 URL: https://issues.jboss.org/browse/WFLY-2329
             Project: WildFly
          Issue Type: Bug
          Components: JSF, Web (JBoss Web)
    Affects Versions: 8.0.0.Beta1
         Environment: - Windows 7 64
- Wildfly Beta 1
- JSF Mojarra 2.2.3
- Primefaces 4.0
- Apache commons-io-2.4 & commons-fileupload-1.3
            Reporter: Domen Cebulj
            Assignee: Stan Silvert


In the previous version it worked, but in Beta 1 stopped worked file uploading with PF4 and Mojarra 2.2.3 (neither simple upload didn't work - tested on blank project, only with PF4 and Apache libs and configured web.xml file)

I get no error in IDE or JS console.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 14:04:01 2013
From: jira-events at lists.jboss.org (Frank Langelage (JIRA))
Date: Thu, 17 Oct 2013 14:04:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2330) Test set
 org.jboss.as.test.clustering.cluster.registry.RegistryTestCase fails with
 NPE
In-Reply-To: <JIRA.12508124.1382032998039@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508124.1382032998039@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508124.1382032998039.4192.1382033041904@jira02.app.mwc.hst.phx2.redhat.com>

Frank Langelage created WFLY-2330:
-------------------------------------

             Summary: Test set org.jboss.as.test.clustering.cluster.registry.RegistryTestCase fails with NPE
                 Key: WFLY-2330
                 URL: https://issues.jboss.org/browse/WFLY-2330
             Project: WildFly
          Issue Type: Bug
          Components: Clustering
    Affects Versions: 8.0.0.CR1
         Environment: Oracle JDK 1.7.0_45 on Solaris SPARC on SunBlade 2000.
            Reporter: Frank Langelage
            Assignee: Paul Ferraro


Test org.jboss.as.test.clustering.cluster.registry.RegistryTestCase fails for me because of a NPE.
See attached log files of this test.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 14:06:01 2013
From: jira-events at lists.jboss.org (Frank Langelage (JIRA))
Date: Thu, 17 Oct 2013 14:06:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2330) Test set
 org.jboss.as.test.clustering.cluster.registry.RegistryTestCase fails with
 NPE
In-Reply-To: <JIRA.12508124.1382032998000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508124.1382032998000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508124.1382032998000.4195.1382033161954@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Frank Langelage updated WFLY-2330:
----------------------------------

    Attachment: org.jboss.as.test.clustering.cluster.registry.RegistryTestCase-SYNC-tcp.txt
                org.jboss.as.test.clustering.cluster.registry.RegistryTestCase-SYNC-tcp-output.txt
                TEST-org.jboss.as.test.clustering.cluster.registry.RegistryTestCase-SYNC-tcp.xml

    
> Test set org.jboss.as.test.clustering.cluster.registry.RegistryTestCase fails with NPE
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-2330
>                 URL: https://issues.jboss.org/browse/WFLY-2330
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 8.0.0.CR1
>         Environment: Oracle JDK 1.7.0_45 on Solaris SPARC on SunBlade 2000.
>            Reporter: Frank Langelage
>            Assignee: Paul Ferraro
>         Attachments: org.jboss.as.test.clustering.cluster.registry.RegistryTestCase-SYNC-tcp-output.txt, org.jboss.as.test.clustering.cluster.registry.RegistryTestCase-SYNC-tcp.txt, TEST-org.jboss.as.test.clustering.cluster.registry.RegistryTestCase-SYNC-tcp.xml
>
>
> Test org.jboss.as.test.clustering.cluster.registry.RegistryTestCase fails for me because of a NPE.
> See attached log files of this test.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 14:21:01 2013
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Thu, 17 Oct 2013 14:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2329) File upload doesn't work
In-Reply-To: <JIRA.12508122.1382032527000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508122.1382032527000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508122.1382032527000.4218.1382034061983@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stan Silvert reassigned WFLY-2329:
----------------------------------

    Assignee: Stuart Douglas  (was: Stan Silvert)


This is a known issue that should be fixed as soon as the latest Undertow is integrated into WildFly.  Assigning to Stuart.

The workaround is to define your FacesServlet in web.xml and include the multipart-config element.
                
> File upload doesn't work
> ------------------------
>
>                 Key: WFLY-2329
>                 URL: https://issues.jboss.org/browse/WFLY-2329
>             Project: WildFly
>          Issue Type: Bug
>          Components: JSF, Web (JBoss Web)
>    Affects Versions: 8.0.0.Beta1
>         Environment: - Windows 7 64
> - Wildfly Beta 1
> - JSF Mojarra 2.2.3
> - Primefaces 4.0
> - Apache commons-io-2.4 & commons-fileupload-1.3
>            Reporter: Domen Cebulj
>            Assignee: Stuart Douglas
>              Labels: fileUpload, jsf22, primefaces, servlet
>
> In the previous version it worked, but in Beta 1 stopped worked file uploading with PF4 and Mojarra 2.2.3 (neither simple upload didn't work - tested on blank project, only with PF4 and Apache libs and configured web.xml file)
> I get no error in IDE or JS console.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 15:10:02 2013
From: jira-events at lists.jboss.org (Domen Cebulj (JIRA))
Date: Thu, 17 Oct 2013 15:10:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2329) File upload doesn't work
In-Reply-To: <JIRA.12508122.1382032527000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508122.1382032527000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508122.1382032527000.4276.1382037002015@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823014#comment-12823014 ] 

Domen Cebulj commented on WFLY-2329:
------------------------------------

OK, thanks for the note, I guess I too little look for Issue.
                
> File upload doesn't work
> ------------------------
>
>                 Key: WFLY-2329
>                 URL: https://issues.jboss.org/browse/WFLY-2329
>             Project: WildFly
>          Issue Type: Bug
>          Components: JSF, Web (JBoss Web)
>    Affects Versions: 8.0.0.Beta1
>         Environment: - Windows 7 64
> - Wildfly Beta 1
> - JSF Mojarra 2.2.3
> - Primefaces 4.0
> - Apache commons-io-2.4 & commons-fileupload-1.3
>            Reporter: Domen Cebulj
>            Assignee: Stuart Douglas
>              Labels: fileUpload, jsf22, primefaces, servlet
>
> In the previous version it worked, but in Beta 1 stopped worked file uploading with PF4 and Mojarra 2.2.3 (neither simple upload didn't work - tested on blank project, only with PF4 and Apache libs and configured web.xml file)
> I get no error in IDE or JS console.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 15:33:02 2013
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Thu, 17 Oct 2013 15:33:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2298) Redesign @Stateful EJB
	clustering
In-Reply-To: <JIRA.12502968.1381765293000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502968.1381765293000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502968.1381765293000.4306.1382038382046@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12822982#comment-12822982 ] 

Paul Ferraro edited comment on WFLY-2298 at 10/17/13 3:31 PM:
--------------------------------------------------------------

Yes.  Infinispan's distribution mode is designed for just this purpose.  State is only replicated to a configurable number of owners (per your availability requirements), where the effective master (i.e. the node on which locks get acquired) of a given SFSB is determined at the time of SFSB creation.  Weak affinity of an SFSB is then assigned to the owning node.
WFLY-2159 will make distribution mode the default cache mode in Wildfly.
                
      was (Author: pferraro):
    Yes.  Infinispan's distribution mode is designed for just this purpose.  State is only replicated to a configurable number of owners (per your availability requirements), where the effective master (i.e. the node on which locks get acquired) of a given SFSB is determined at the time of SFSB creation.  Weak affinity of an SFSB is then assigned to the owning node.
                  
> Redesign @Stateful EJB clustering
> ---------------------------------
>
>                 Key: WFLY-2298
>                 URL: https://issues.jboss.org/browse/WFLY-2298
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Clustering
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 9.0.0.CR1
>
>
> The current @Stateful EJB clustering design has a number of flaws:
> * The current implementation is very slow.  Each EJB invocation results in 4 Infinispan transactions!  Cache.get(...) and Cache.release(...) result in 2 transactions each, 1 for bean cache and 1 for group cache
> * An external locking mechanism is used to guard the SFSB against access from other nodes between Cache.get(...) and Cache.release(...)
> * Because the current design uses 2 separate cache instances, data is not correctly isolated and can cause integrity issues
> * The current design uses a global group cache, which results in classloader leaks when a server has multiple EJB deployments (MarshalledValues in the group cache, which survives undeployment, can still reference the classloader of an undeployed EJB)
> * The lifecycle of the global group cache does not leverage the MSC and thus is prone to race conditions by multiple SFSB deployments
> * State changes that occur to the SFSB during activation/passivation callbacks are not correctly replicated.
> * The @Clustered annotation currently has 2 orthogonal meanings:
> 	1. If applied to a @Stateful EJB, then a specific cache will be used (as defined by the EJB subsystem)
> 	2. If applied to a @Stateless or @Stateful EJB, remote EJB clients will have a dynamic view of the EJB's topology.
> * Eager passivation is unnecessarily expensive, and makes the eventual SFSB removal slower.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 15:59:02 2013
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Thu, 17 Oct 2013 15:59:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2331) Update JSF based on Mojarra
	2.2.4 final
In-Reply-To: <JIRA.12508130.1382039926200@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508130.1382039926200@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508130.1382039926200.4372.1382039942506@jira02.app.mwc.hst.phx2.redhat.com>

Stan Silvert created WFLY-2331:
----------------------------------

             Summary: Update JSF based on Mojarra 2.2.4 final
                 Key: WFLY-2331
                 URL: https://issues.jboss.org/browse/WFLY-2331
             Project: WildFly
          Issue Type: Component  Upgrade
          Components: JSF
    Affects Versions: 8.0.0.Beta1
            Reporter: Stan Silvert
            Assignee: Stan Silvert
             Fix For: 8.0.0.CR1


Update JSF based on Mojarra 2.2.4 final.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 16:11:02 2013
From: jira-events at lists.jboss.org (Dan Berindei (JIRA))
Date: Thu, 17 Oct 2013 16:11:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1675) Threads stuck in
 FlowControl.decrementIfEnoughCredits
In-Reply-To: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498385.1376295331000.4393.1382040662408@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823031#comment-12823031 ] 

Dan Berindei commented on JGRP-1675:
------------------------------------

I have a test that hangs reliably on my machine with 3.4.0.Final: https://github.com/danberindei/infinispan/blob/73ca65f9b629698da68916c720ec4efa0d97e2b4/core/src/test/java/org/infinispan/stress/RemoteGetStressTest.java

The test is using Infinispan, but it should be pretty easy to replicate it with JGroups only if necessary. This is what it does:
* Populate a distributed cache with huge values (100kb), making sure the coordinator doesn't own any entries.
* Launch 500 remote get operations in parallel from a single node, resulting in 1500 response messages (numOwners is 3).
* Slow down the processing of response messages by adding a {{Thread.sleep(Random.nextInt(10))}} to keep the OOB threads busy.

Interesting enough, with max_credits=1m and min_threshold=0.40, the FC logs always show at least 390k remaining credits. Yet the remote get operations still time out after 60 seconds, and the OOB threads on most nodes are stuck in {{FlowControl.decrementIfEnoughCredits()}}.
                
> Threads stuck in FlowControl.decrementIfEnoughCredits
> -----------------------------------------------------
>
>                 Key: JGRP-1675
>                 URL: https://issues.jboss.org/browse/JGRP-1675
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> I have recently observed a repeated situation where many (or all) threads have been stuck waiting for credits in FlowControl protocol.
> The credit request was not handled on the other node as this is non-oob message and some (actually many of them - cause unknown) messages before the request have been lost - therefore the request was waiting for them to be re-sent.
> However, these have not been re-sent properly as the retransmission request was not received - all OOB threads were stuck in the FlowControl protocol as these handled some other request and tried to send a response - but the response could not be sent until FlowControl gets the credits.
> The probability of such situation could be lowered by tagging the credit request to be OOB - then it would be handled immediately. If the credit replenish message would then be processed in regular OOB pool, this could get already depleted by many requests, but setting up the internal thread pool would solve the problem.
> Other consideration would be to allow releasing thread from FlowControl (let it send the message even without credits) if it waits there for too long.
> h3. Workaround
> It appears that setting MFC and UFC max_credits to 10M or removing these protocols at all is a workaround for this issue.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 16:31:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 17 Oct 2013 16:31:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1675) Threads stuck in
 FlowControl.decrementIfEnoughCredits
In-Reply-To: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498385.1376295331000.4417.1382041862403@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban reopened JGRP-1675:
----------------------------


    
> Threads stuck in FlowControl.decrementIfEnoughCredits
> -----------------------------------------------------
>
>                 Key: JGRP-1675
>                 URL: https://issues.jboss.org/browse/JGRP-1675
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> I have recently observed a repeated situation where many (or all) threads have been stuck waiting for credits in FlowControl protocol.
> The credit request was not handled on the other node as this is non-oob message and some (actually many of them - cause unknown) messages before the request have been lost - therefore the request was waiting for them to be re-sent.
> However, these have not been re-sent properly as the retransmission request was not received - all OOB threads were stuck in the FlowControl protocol as these handled some other request and tried to send a response - but the response could not be sent until FlowControl gets the credits.
> The probability of such situation could be lowered by tagging the credit request to be OOB - then it would be handled immediately. If the credit replenish message would then be processed in regular OOB pool, this could get already depleted by many requests, but setting up the internal thread pool would solve the problem.
> Other consideration would be to allow releasing thread from FlowControl (let it send the message even without credits) if it waits there for too long.
> h3. Workaround
> It appears that setting MFC and UFC max_credits to 10M or removing these protocols at all is a workaround for this issue.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 16:31:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 17 Oct 2013 16:31:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1675) Threads stuck in
 FlowControl.decrementIfEnoughCredits
In-Reply-To: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498385.1376295331000.4426.1382041862793@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1675:
---------------------------

    Fix Version/s: 3.5
                       (was: 3.4)

    
> Threads stuck in FlowControl.decrementIfEnoughCredits
> -----------------------------------------------------
>
>                 Key: JGRP-1675
>                 URL: https://issues.jboss.org/browse/JGRP-1675
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> I have recently observed a repeated situation where many (or all) threads have been stuck waiting for credits in FlowControl protocol.
> The credit request was not handled on the other node as this is non-oob message and some (actually many of them - cause unknown) messages before the request have been lost - therefore the request was waiting for them to be re-sent.
> However, these have not been re-sent properly as the retransmission request was not received - all OOB threads were stuck in the FlowControl protocol as these handled some other request and tried to send a response - but the response could not be sent until FlowControl gets the credits.
> The probability of such situation could be lowered by tagging the credit request to be OOB - then it would be handled immediately. If the credit replenish message would then be processed in regular OOB pool, this could get already depleted by many requests, but setting up the internal thread pool would solve the problem.
> Other consideration would be to allow releasing thread from FlowControl (let it send the message even without credits) if it waits there for too long.
> h3. Workaround
> It appears that setting MFC and UFC max_credits to 10M or removing these protocols at all is a workaround for this issue.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 16:51:01 2013
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Thu, 17 Oct 2013 16:51:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2332) Log manager should not be
 shaded into the client jars
In-Reply-To: <JIRA.12508132.1382043045338@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508132.1382043045338@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508132.1382043045338.4445.1382043061884@jira02.app.mwc.hst.phx2.redhat.com>

James Perkins created WFLY-2332:
-----------------------------------

             Summary: Log manager should not be shaded into the client jars
                 Key: WFLY-2332
                 URL: https://issues.jboss.org/browse/WFLY-2332
             Project: WildFly
          Issue Type: Bug
          Components: CLI
            Reporter: James Perkins
            Assignee: James Perkins
             Fix For: 8.0.0.CR1


The {{jboss-logmanager}} dependency is getting brought into the client libraries, {{jboss-cli-client.jar}} and {{jboss-client.jar}}, from {{remoting-jmx}} and {{hornetq-journal}}. There could be other places where the logmanager has the incorrect scope so those should be sorted out as well.

Pull request to fix in remote-jmx: https://github.com/jbossas/remoting-jmx/pull/15

Pull request to fix in hornetq-journal: https://github.com/hornetq/hornetq/pull/1342

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 17:10:02 2013
From: jira-events at lists.jboss.org (Shane Bryzak (JIRA))
Date: Thu, 17 Oct 2013 17:10:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-299) Support rule configuration
 in a web archive
In-Reply-To: <JIRA.12503061.1381828954000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503061.1381828954000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503061.1381828954000.4465.1382044202005@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823041#comment-12823041 ] 

Shane Bryzak commented on DROOLS-299:
-------------------------------------

Do you mean I need to add the org.drools:drools-jboss-integration dependency to the project itself?  If I do this it adds over 80mb of dependencies to the deployment.
                
> Support rule configuration in a web archive
> -------------------------------------------
>
>                 Key: DROOLS-299
>                 URL: https://issues.jboss.org/browse/DROOLS-299
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>            Reporter: Shane Bryzak
>            Assignee: Mario Fusco
>
> I'm currently working on integration between PicketLink and Drools to provide rule-based security permissions which control access to protected application resources, similar to a feature that we had in Seam 2:
> https://github.com/seam2/jboss-seam/blob/Seam_2_3/jboss-seam/src/main/java/org/jboss/seam/security/permission/RuleBasedPermissionResolver.java
> The following quickstart (work in progress) is intended to demonstrate this integration:
> https://github.com/picketlink/picketlink-quickstarts/tree/master/picketlink-authorization-drools
> Building this quickstart first requires building the latest trunk of PicketLink locally:
> https://github.com/picketlink/picketlink
> What we would like is to allow the developer to define their security rules in the war project itself.  Currently the quickstart defines the following kmodule.xml file in the src/main/resources/META-INF directory:
> <?xml version="1.0" encoding="UTF-8"?>
> <kmodule xmlns="http://jboss.org/kie/6.0.0/kmodule">
>   <kbase name="security" default="true">
>     <ksession name="ksession1" default="true"/>
>   </kbase>
> </kmodule>
> There is also a security-rules.drl file in the src/main/resources/security directory which defines the security rules.
> Deployment of the quickstart yields the following errors and partial stacktrace:
> 18:52:56,036 INFO  [org.drools.compiler.kie.builder.impl.ClasspathKieProject] (MSC service thread 1-7) Found kmodule: vfs:/content/picketlink-authorization-drools.war/WEB-INF/classes/META-INF/kmodule.xml
> 18:52:56,036 INFO  [org.drools.compiler.kie.builder.impl.ClasspathKieProject] (MSC service thread 1-7) Virtual file physical path = /home/shane/apps/jboss/standalone/tmp/vfs/tempa9983c4071e1249/picketlink-authorization-drools.war-1c243fd87ed695cf/WEB-INF/classes
> 18:52:56,060 WARN  [org.drools.compiler.kie.builder.impl.ClasspathKieProject] (MSC service thread 1-7) Unable to load pom.properties tried recursing down from/home/shane/apps/jboss/standalone/tmp/vfs/tempa9983c4071e1249/picketlink-authorization-drools.war-1c243fd87ed695cf/WEB-INF/classes
> null
> 18:52:56,061 ERROR [org.drools.compiler.kie.builder.impl.ClasspathKieProject] (MSC service thread 1-7) Unable to build index of kmodule.xml url=vfs:/content/picketlink-authorization-drools.war/WEB-INF/classes/META-INF/kmodule.xml
> null
> 18:52:56,140 ERROR [org.drools.compiler.cdi.KieCDIExtension] (MSC service thread 1-7) Annotation @KSession(ksession1) found, but no KieSessioneModel exist.
> Either the required kproject.xml does not exist, was corrupted, or mising the KieBase entry
> 18:52:56,160 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC00001: Failed to start service jboss.deployment.unit."picketlink-authorization-drools.war".WeldService: org.jboss.msc.service.StartException in service jboss.deployment.unit."picketlink-authorization-drools.war".WeldService: org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [KieSession] with qualifiers [@KSession] at injection point [[field] @Inject @KSession org.jboss.as.quickstarts.picketlink.authorization.drools.PermissionAuthorizer.kSession]
> 	at org.jboss.as.weld.services.WeldService.start(WeldService.java:83)
> Mario indicated (during a discussion on IRC) that the rules are currently expected to be deployed within a separate jar file (which is then packaged as a library in the war), however our users are likely to view this as an extraneous requirement.  It would be far more convenient to allow them to create their rule definitions within the war project itself, and also be easier to promote this integration via tutorials and quickstarts.
> Thanks for looking into this!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 17:19:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 17 Oct 2013 17:19:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-862) Shutdown process hangs using
 thread pool executor
In-Reply-To: <JIRA.12480676.1354861551000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12480676.1354861551000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12480676.1354861551000.4482.1382044742138@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823044#comment-12823044 ] 

RH Bugzilla Integration commented on WFLY-862:
----------------------------------------------

Fernando Nasser <fnasser at redhat.com> made a comment on [bug 882048|https://bugzilla.redhat.com/show_bug.cgi?id=882048]

Can someone chose the right component please?
                
> Shutdown process hangs using thread pool executor
> -------------------------------------------------
>
>                 Key: WFLY-862
>                 URL: https://issues.jboss.org/browse/WFLY-862
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Eiichi Nagai
>            Assignee: Remy Maucherat
>
> When AJP connecotr uses thread pool executor configuration[1], AJP's worker thread is waited by AjpProcessor.read()[2]. QueueExecuter recognizes it as active thread. Therefor, unless httpd server shut down, EAP server shutdown process does not finish forever. 
> [1] standalone.xml
>         <subsystem xmlns="urn:jboss:domain:threads:1.1">
>             <bounded-queue-thread-pool name="http-executor">
>                 <queue-length count="1"/>
>                 <max-threads count="1"/>
>             </bounded-queue-thread-pool>
>         </subsystem>
> --- snip ---
>         <subsystem xmlns="urn:jboss:domain:web:1.1" default-virtual-server="default-host" native="false">
>             <connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http"/>
>             <connector name="ajp" protocol="AJP/1.3" scheme="http" socket-binding="ajp" executor="http-executor"/>
>             <virtual-server name="default-host" enable-welcome-root="true">
>                 <alias name="localhost"/>
>                 <alias name="example.com"/>
>             </virtual-server>
>         </subsystem>
> [2]
> "http-executor-threads - 1" prio=6 tid=0x55515000 nid=0x20c0 runnable [0x5590f000]
>    java.lang.Thread.State: RUNNABLE
>    at java.net.SocketInputStream.socketRead0(Native Method)
>    at java.net.SocketInputStream.read(SocketInputStream.java:129)
>    at org.apache.coyote.ajp.AjpProcessor.read(AjpProcessor.java:1131)
>    at org.apache.coyote.ajp.AjpProcessor.readMessage(AjpProcessor.java:1213)
>    at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:451)
>    at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:452)
>    at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:519)
>    at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33)
>    at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:801)
>    at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45)
>    at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:821)
>    at java.lang.Thread.run(Thread.java:662)
>    at org.jboss.threads.JBossThread.run(JBossThread.java:122)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 17:34:01 2013
From: jira-events at lists.jboss.org (Rich DiCroce (JIRA))
Date: Thu, 17 Oct 2013 17:34:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1718) Message corruption under
	heavy load
In-Reply-To: <JIRA.12503731.1381946713000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503731.1381946713000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503731.1381946713000.4524.1382045641980@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823049#comment-12823049 ] 

Rich DiCroce commented on JGRP-1718:
------------------------------------

I spent the whole day today trying to nail this down, and I have some more information now. Unfortunately, this information only makes the issue more baffling.

To answer your questions:
- As part of my investigation, I added some logging of the byte arrays being processed. I have confirmed that, when an error occurs, the byte array I get in my RequestHandler does not match the byte array I passed to the Message constructor. I have also determined that when a byte array gets corrupted, I can send a second Message with the exact same byte array and request options, and the byte array in the second Message is readable. I have also made sure I can deserialize an object immediately after serializing it (before sending the Message), and I have also tried deserializing a second time after the first time failed (when receiving the Message; the second time also fails).
- I tried using normal Java serialization, and that does not seem to exhibit the problem. This does not necessarily implicate Kryo or exhonerate JGroups, however. See below.
- Kryo has input/output buffers, specifically, the Input and Output classes. I am not reusing instances of those classes. I am reusing instances of the Kryo class itself, which handles the actual serialization/deserialization. Kryo is not thread-safe, so I am obtaining the instances from a ThreadLocal to prevent concurrent use.

I have determined that the byte arrays are being corrupted in a way that's too consistent to be random chance. It seems to be triggered by a particular bit sequence, specifically:

{code}00000001{code} followed by {code}11111001{code} or {code}11100101{code}

These two bytes can be anywhere in the array. The corruption that occurs is always the same: the first bit of the second byte is flipped from 1 to 0. Unfortunately, these bit sequences only seem to be part of the cause. I believe a race condition of some sort is also at work here, because I've been unable to create a simple test that reproduces the problem.

Another twist that only makes the issue weirder: changing the loopback setting of the UDP transport affects the frequency of the corruption. With loopback = false, the problem occurs much more rarely, to the point that I initially thought it had eliminated the problem altogether. I only observed one corruption during my testing with loopback = false, and curiously, a third bit pattern that I have not observed with loopback = true got corrupted:

{code}00000001 11000100{code}

Again, the first bit of the second byte was flipped from 1 to 0. I also logged the number of nodes that were unable to read the message, and there was only one error despite the cluster having two nodes and the message being a multicast to all nodes. This implies that the corruption occurs when the message is received, not when it is sent.

Having looked at the JGroups source code, it seems like there would be less concurrency with loopback = false since a multicast message would not be immediately sent back up the stack, potentially in parallel with messages being received from other nodes. Hence the speculation about a race condition.

Does any of this make any sense to you? Because my brain feels like it's about to melt. :-)
                
> Message corruption under heavy load
> -----------------------------------
>
>                 Key: JGRP-1718
>                 URL: https://issues.jboss.org/browse/JGRP-1718
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.12
>         Environment: JBoss AS 7.2.0.Final (includes JGroups 3.2.7.Final, upgrading to 3.2.12.Final had no effect)
>            Reporter: Rich DiCroce
>            Assignee: Bela Ban
>
> In my project, I'm using the Kryo serialization library to serialize/deserialize objects to/from byte[]. Some of these byte arrays appear to be getting corrupted during transmission.
> The problem happens very infrequently and only under load. I have to send tens of thousands of messages from hundreds of threads just to get two or three errors. The exception occurs when Kryo tries to deserialize the byte[] on the receiving node. So far, all of the errors I've seen happen when Kryo tries to find a class to deserialize an object, and the stack traces end with something like:
> Caused by: java.lang.ClassNotFoundException: java.util.Date[SOH][GS]
> Note that the [SOH] and [GS] are not literally those strings, they're unprintable ASCII 0x1 and 0x1D.
> I'm confident that Kryo itself is not the source of the problem. I added some code to my project to deserialize the message on the sending node, immediately after serializing it, and log any exception thrown from the deserialization. The sending node did not log an exception, but the receiving node still did. My code passes the byte[] to the Message constructor without doing anything to it.
> It also appears that I am not the first person to encounter this issue. See https://code.google.com/p/kryo/issues/detail?id=102

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 20:37:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 17 Oct 2013 20:37:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1988) SaslException at startup in
 domain mode using JAAS for ManagementRealm
In-Reply-To: <JIRA.12499810.1378201935000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499810.1378201935000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499810.1378201935000.4582.1382056622266@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-1988:
------------------------------------------

    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1003464, https://bugzilla.redhat.com/show_bug.cgi?id=1005004, https://bugzilla.redhat.com/show_bug.cgi?id=1005670, https://bugzilla.redhat.com/show_bug.cgi?id=1020568  (was: https://bugzilla.redhat.com/show_bug.cgi?id=1003464)

    
>  SaslException at startup in domain mode using JAAS for ManagementRealm
> -----------------------------------------------------------------------
>
>                 Key: WFLY-1988
>                 URL: https://issues.jboss.org/browse/WFLY-1988
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 17 21:48:01 2013
From: jira-events at lists.jboss.org (Rich DiCroce (JIRA))
Date: Thu, 17 Oct 2013 21:48:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1718) Message corruption under
	heavy load
In-Reply-To: <JIRA.12503731.1381946713000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503731.1381946713000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503731.1381946713000.4599.1382060881966@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823066#comment-12823066 ] 

Rich DiCroce commented on JGRP-1718:
------------------------------------

I figured it out! Mostly.

After digging around in the Kryo source code, I discovered that when deserializing a byte array, Kryo flips a bit in order to read a String, then flips the bit back. I created a test where a bunch of threads all tried to deserialize a byte array at the same time, and was able to reproduce the corruption issue perfectly.

So that then leads to the question: why are multiple threads using the same byte array at the same time? I think the answer lies in Message.copy(). That method ultimately calls copy(boolean, boolean), which calls setBuffer() to copy the buffer. But setBuffer() doesn't make a copy of the byte array; instead it just copies the reference to the byte array. This explains why the corruption happened more often with loopback = true, because the byte array got passed back up the stack where Kryo mucked with it at the same time as the transport was reading the byte array to multicast it. It also explains why the corruption still happened with loopback = false, because presumably a similar situation could occur if the Message got lost and needed to be re-transmitted.

The fact that the byte array isn't being deep-copied seems like a bit of a bug to me. :-) Regardless, I don't like the fact that Kryo changes something that it's reading, so I think I'll be investigating other options for serialization.
                
> Message corruption under heavy load
> -----------------------------------
>
>                 Key: JGRP-1718
>                 URL: https://issues.jboss.org/browse/JGRP-1718
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.12
>         Environment: JBoss AS 7.2.0.Final (includes JGroups 3.2.7.Final, upgrading to 3.2.12.Final had no effect)
>            Reporter: Rich DiCroce
>            Assignee: Bela Ban
>
> In my project, I'm using the Kryo serialization library to serialize/deserialize objects to/from byte[]. Some of these byte arrays appear to be getting corrupted during transmission.
> The problem happens very infrequently and only under load. I have to send tens of thousands of messages from hundreds of threads just to get two or three errors. The exception occurs when Kryo tries to deserialize the byte[] on the receiving node. So far, all of the errors I've seen happen when Kryo tries to find a class to deserialize an object, and the stack traces end with something like:
> Caused by: java.lang.ClassNotFoundException: java.util.Date[SOH][GS]
> Note that the [SOH] and [GS] are not literally those strings, they're unprintable ASCII 0x1 and 0x1D.
> I'm confident that Kryo itself is not the source of the problem. I added some code to my project to deserialize the message on the sending node, immediately after serializing it, and log any exception thrown from the deserialization. The sending node did not log an exception, but the receiving node still did. My code passes the byte[] to the Message constructor without doing anything to it.
> It also appears that I am not the first person to encounter this issue. See https://code.google.com/p/kryo/issues/detail?id=102

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 18 01:38:02 2013
From: jira-events at lists.jboss.org (SBS JIRA Integration (JIRA))
Date: Fri, 18 Oct 2013 01:38:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-554) Operations to read content
 from the content repository
In-Reply-To: <JIRA.12469641.1340905244000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12469641.1340905244000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12469641.1340905244000.4658.1382074682352@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

SBS JIRA Integration updated WFLY-554:
--------------------------------------

    Forum Reference: https://community.jboss.org/message/841453#841453

    
> Operations to read content from the content repository
> ------------------------------------------------------
>
>                 Key: WFLY-554
>                 URL: https://issues.jboss.org/browse/WFLY-554
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Priority: Minor
>             Fix For: 9.0.0.CR1
>
>
> Ability to pull data out of the content repository. We can do that with rollout plans, but not for deployments or if we add deployment content overlays.
> Basically, if the user loses the original of the deployment, let's let them get it back via the management API and remove the temptation for them to hack into the repository.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 18 01:38:02 2013
From: jira-events at lists.jboss.org (SBS JIRA Integration (JIRA))
Date: Fri, 18 Oct 2013 01:38:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-549) Give option to make the
 content repository browsable
In-Reply-To: <JIRA.12470853.1342722472000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12470853.1342722472000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12470853.1342722472000.4661.1382074682604@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

SBS JIRA Integration updated WFLY-549:
--------------------------------------

    Forum Reference: https://community.jboss.org/message/841453#841453

    
> Give option to make the content repository browsable
> ----------------------------------------------------
>
>                 Key: WFLY-549
>                 URL: https://issues.jboss.org/browse/WFLY-549
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Ben Schofield
>             Fix For: 9.0.0.CR1
>
>
> JBoss admins regularly need to view the application content that is deployed to a server. On previous versions of JBoss this was easy to do with the deploy directory.  When using the new API to install applications the contents of applications are not easily browsable or searchable.
> Would like to have a setting that enables all content to be stored in exploded format in the content repository.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 18 04:59:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 18 Oct 2013 04:59:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1718) Message corruption under
	heavy load
In-Reply-To: <JIRA.12503731.1381946713000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503731.1381946713000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503731.1381946713000.4832.1382086743330@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823102#comment-12823102 ] 

Bela Ban commented on JGRP-1718:
--------------------------------

Hi Rich,
good investigation !
Byte buffers in a {{Message}} are never copied as they are considered *immutable*, see the javadoc in [1] for example. Actually, they are copied in some cases, but we try to minimize the amount of copying done.

{{Message.copy()}} is one case where multiple thread might access the same message at the same time, retransmission is another one: if the bit in the message was flipped and the same message happened to get retransmitted at the same time, the flipped bit would be sent, wreaking havoc at the receiver(s).

[1] https://github.com/belaban/JGroups/blob/master/src/org/jgroups/Message.java#L251

                
> Message corruption under heavy load
> -----------------------------------
>
>                 Key: JGRP-1718
>                 URL: https://issues.jboss.org/browse/JGRP-1718
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.12
>         Environment: JBoss AS 7.2.0.Final (includes JGroups 3.2.7.Final, upgrading to 3.2.12.Final had no effect)
>            Reporter: Rich DiCroce
>            Assignee: Bela Ban
>
> In my project, I'm using the Kryo serialization library to serialize/deserialize objects to/from byte[]. Some of these byte arrays appear to be getting corrupted during transmission.
> The problem happens very infrequently and only under load. I have to send tens of thousands of messages from hundreds of threads just to get two or three errors. The exception occurs when Kryo tries to deserialize the byte[] on the receiving node. So far, all of the errors I've seen happen when Kryo tries to find a class to deserialize an object, and the stack traces end with something like:
> Caused by: java.lang.ClassNotFoundException: java.util.Date[SOH][GS]
> Note that the [SOH] and [GS] are not literally those strings, they're unprintable ASCII 0x1 and 0x1D.
> I'm confident that Kryo itself is not the source of the problem. I added some code to my project to deserialize the message on the sending node, immediately after serializing it, and log any exception thrown from the deserialization. The sending node did not log an exception, but the receiving node still did. My code passes the byte[] to the Message constructor without doing anything to it.
> It also appears that I am not the first person to encounter this issue. See https://code.google.com/p/kryo/issues/detail?id=102

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 18 05:58:01 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Fri, 18 Oct 2013 05:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2333) Web deployment code assumes
 only a single ServletContainerInitializer is present in each jar
In-Reply-To: <JIRA.12508164.1382090257798@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508164.1382090257798@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508164.1382090257798.4935.1382090281951@jira02.app.mwc.hst.phx2.redhat.com>

Stuart Douglas created WFLY-2333:
------------------------------------

             Summary: Web deployment code assumes only a single ServletContainerInitializer is present in each jar
                 Key: WFLY-2333
                 URL: https://issues.jboss.org/browse/WFLY-2333
             Project: WildFly
          Issue Type: Bug
          Components: Web (Undertow)
    Affects Versions: 8.0.0.Beta1
            Reporter: Stuart Douglas
            Assignee: Stuart Douglas




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 18 06:04:01 2013
From: jira-events at lists.jboss.org (Clayton Tabone (JIRA))
Date: Fri, 18 Oct 2013 06:04:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-304) kie-ci is not able to
 resolve ranges in artifact version
In-Reply-To: <JIRA.12508165.1382090622005@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508165.1382090622005@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508165.1382090622005.4943.1382090641997@jira02.app.mwc.hst.phx2.redhat.com>

Clayton Tabone created DROOLS-304:
-------------------------------------

             Summary: kie-ci is not able to resolve ranges in artifact version
                 Key: DROOLS-304
                 URL: https://issues.jboss.org/browse/DROOLS-304
             Project: Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: 6.0.0.CR5
            Reporter: Clayton Tabone
            Assignee: Mark Proctor


When creating a new container with a given ReleaseId and a specific version, kie-ci is able to resolve the artifact from the drools-wb Maven repository. However when a range is specified, the artifact is not resolved with an error message stating that the version could not be found. The GAV with the range is a valid combination since the same works from a pom file. Kie-ci is on the classpath.

Steps to reproduce:

- Deploy drools-wb
- Build the mortgages project from the guvnorng-playground
- Run the following code:
KieServices ks = KieServices.Factory.get();
ReleaseId releaseId = ks.newReleaseId("mortgages", "mortgages", "[0.0.1-0.1.0)");
KieContainer kieContainer = ks.newKieContainer(releaseId);

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 18 06:06:02 2013
From: jira-events at lists.jboss.org (Clayton Tabone (JIRA))
Date: Fri, 18 Oct 2013 06:06:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-304) kie-ci is not able to
 resolve ranges in artifact version
In-Reply-To: <JIRA.12508165.1382090622000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508165.1382090622000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508165.1382090622000.4945.1382090762013@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clayton Tabone updated DROOLS-304:
----------------------------------

    Priority: Minor  (was: Major)

    
> kie-ci is not able to resolve ranges in artifact version
> --------------------------------------------------------
>
>                 Key: DROOLS-304
>                 URL: https://issues.jboss.org/browse/DROOLS-304
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.CR5
>            Reporter: Clayton Tabone
>            Assignee: Mark Proctor
>            Priority: Minor
>
> When creating a new container with a given ReleaseId and a specific version, kie-ci is able to resolve the artifact from the drools-wb Maven repository. However when a range is specified, the artifact is not resolved with an error message stating that the version could not be found. The GAV with the range is a valid combination since the same works from a pom file. Kie-ci is on the classpath.
> Steps to reproduce:
> - Deploy drools-wb
> - Build the mortgages project from the guvnorng-playground
> - Run the following code:
> KieServices ks = KieServices.Factory.get();
> ReleaseId releaseId = ks.newReleaseId("mortgages", "mortgages", "[0.0.1-0.1.0)");
> KieContainer kieContainer = ks.newKieContainer(releaseId);

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 18 06:26:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 18 Oct 2013 06:26:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-73) Change the logmanager sope to
	test only.
In-Reply-To: <JIRA.12508168.1382091899149@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508168.1382091899149@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508168.1382091899149.4959.1382091962032@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created REMJMX-73:
--------------------------------------

             Summary: Change the logmanager sope to test only.
                 Key: REMJMX-73
                 URL: https://issues.jboss.org/browse/REMJMX-73
             Project: Remoting JMX
          Issue Type: Task
          Components: Build
    Affects Versions: 2.0.0.CR3
            Reporter: James Perkins
            Assignee: Darran Lofthouse
             Fix For: 2.0.0.CR4




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 18 06:28:01 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 18 Oct 2013 06:28:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-73) Change the logmanager sope to
	test only.
In-Reply-To: <JIRA.12508168.1382091899000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508168.1382091899000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508168.1382091899000.4962.1382092081959@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/REMJMX-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated REMJMX-73:
-----------------------------------

    Assignee: James Perkins  (was: Darran Lofthouse)

    
> Change the logmanager sope to test only.
> ----------------------------------------
>
>                 Key: REMJMX-73
>                 URL: https://issues.jboss.org/browse/REMJMX-73
>             Project: Remoting JMX
>          Issue Type: Task
>          Components: Build
>    Affects Versions: 2.0.0.CR3
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 2.0.0.CR4
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 18 06:33:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 18 Oct 2013 06:33:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-73) Change the logmanager sope to
	test only.
In-Reply-To: <JIRA.12508168.1382091899000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508168.1382091899000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508168.1382091899000.4967.1382092382069@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/REMJMX-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved REMJMX-73.
------------------------------------

    Resolution: Done

    
> Change the logmanager sope to test only.
> ----------------------------------------
>
>                 Key: REMJMX-73
>                 URL: https://issues.jboss.org/browse/REMJMX-73
>             Project: Remoting JMX
>          Issue Type: Task
>          Components: Build
>    Affects Versions: 2.0.0.CR3
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 2.0.0.CR4
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 18 06:45:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 18 Oct 2013 06:45:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1433) Enhance add-user utility to
 allow user to select from known groups when assigning groups to a user
In-Reply-To: <JIRA.12493342.1370025633000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493342.1370025633000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493342.1370025633000.5005.1382093103232@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-1433:
-----------------------------------

    Fix Version/s: Awaiting Volunteers
                       (was: 8.0.0.CR1)

    
> Enhance add-user utility to allow user to select from known groups when assigning groups to a user
> --------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1433
>                 URL: https://issues.jboss.org/browse/WFLY-1433
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management, Scripts
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: Awaiting Volunteers
>
>
> Also ensure add-user utility is talking about groups and not roles.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 18 06:58:02 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Fri, 18 Oct 2013 06:58:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2317) Trying to remove a server
 group as a server-group-scoped role leaks information
In-Reply-To: <JIRA.12503235.1381924172000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503235.1381924172000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503235.1381924172000.5040.1382093882617@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823131#comment-12823131 ] 

Ladislav Thon commented on WFLY-2317:
-------------------------------------

I've rebased the branch and submitted a pull request (the branch/PR contains some more tests than this one). In the PR, I changed the test to pass and added a comment to explain that it shouldn't be Outcome.UNAUTHORIZED but Outcome.HIDDEN.
                
> Trying to remove a server group as a server-group-scoped role leaks information
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-2317
>                 URL: https://issues.jboss.org/browse/WFLY-2317
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Brian Stansberry
>              Labels: rbac-filed-by-qa
>
> When writing a small test case for WFLY-2190, I stumbled upon a problem: trying to remove an existing server group by a server-group-scoped user that does NOT have permissions to that server group leaks information. On a freshly built WildFly with added {{admin}} user into {{domain/configuration/mgmt-users.properties}}, it can be reproduced like this:
> {code}
> [1] ./bin/domain.sh
> [2] ./bin/jboss-cli.sh -c
>     /core-service=management/access=authorization/server-group-scoped-role=NewRole:add(base-role=administrator, server-groups=[main-server-group])
>     /core-service=management/access=authorization/role-mapping=NewRole:add
>     /core-service=management/access=authorization/role-mapping=NewRole/include=user-admin:add(name=admin, type=user)
>     /core-service=management/access=authorization:write-attribute(name=provider, value=rbac)
>     exit
> [1] ^C
>     ./bin/domain.sh
> [2] ./bin/jboss-cli.sh -c --user=admin --password=XXX
>     /server-group=other-server-group:read-resource
>     /server-group=other-server-group:remove
> {code}
> What does that mean? The {{NewRole}} is scoped to the {{main-server-group}} server group and can't see {{other-server-group}}. When doing {{/server-group=other-server-group:read-resource}}, this is correctly enforced and the output looks like this:
> {code}
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014807: Management resource '[(\"server-group\" => \"other-server-group\")]' not found",
>     "rolled-back" => true
> }
> {code}
> However, trying to do {{/server-group=other-server-group:remove}}, which is only a different operation _on the same resource_, I get a different error message:
> {code}
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "JBAS013456: Unauthorized to execute operation 'remove' for resource '[(\"server-group\" => \"other-server-group\")]' -- \"JBAS013475: Permission denied\""},
>     "rolled-back" => true
> }
> {code}
> I expect the error message to be completely the same as in previous case, not leaking any information that the {{other-server-group}} actually exists.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 18 07:51:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 18 Oct 2013 07:51:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBRULES-3666) kbase holds multiple
 KnowledgeBaseEventListenerWrapper instances when adding the same
 KnowledgeBaseEventListener multiple times
In-Reply-To: <JIRA.12477585.1350909161000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12477585.1350909161000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12477585.1350909161000.5207.1382097062022@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBRULES-3666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823156#comment-12823156 ] 

RH Bugzilla Integration commented on JBRULES-3666:
--------------------------------------------------

Tomas Schlosser <tschloss at redhat.com> made a comment on [bug 958394|https://bugzilla.redhat.com/show_bug.cgi?id=958394]

Verified in BRMS 6.0.0.ER4
                
> kbase holds multiple KnowledgeBaseEventListenerWrapper instances when adding the same KnowledgeBaseEventListener multiple times
> -------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-3666
>                 URL: https://issues.jboss.org/browse/JBRULES-3666
>             Project: JBRULES
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.5.0.Beta1
>            Reporter: Toshiya Kobayashi
>            Assignee: Mario Fusco
>             Fix For: 5.5.0.Final
>
>
> When you add the same KnowledgeBaseEventListener to kbase twice, kbase holds both KnowledgeBaseEventListenerWrapper instances. I'm not 100% sure if this is a bug but I guess KnowledgeBaseEventListenerWrapper should implement equals() method like StatefulKnowledgeSessionImpl$AgendaEventListenerWrapper.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 18 07:51:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 18 Oct 2013 07:51:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBRULES-3666) kbase holds multiple
 KnowledgeBaseEventListenerWrapper instances when adding the same
 KnowledgeBaseEventListener multiple times
In-Reply-To: <JIRA.12477585.1350909161000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12477585.1350909161000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12477585.1350909161000.5212.1382097062263@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBRULES-3666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823157#comment-12823157 ] 

RH Bugzilla Integration commented on JBRULES-3666:
--------------------------------------------------

Tomas Schlosser <tschloss at redhat.com> changed the Status of [bug 958394|https://bugzilla.redhat.com/show_bug.cgi?id=958394] from ON_QA to VERIFIED
                
> kbase holds multiple KnowledgeBaseEventListenerWrapper instances when adding the same KnowledgeBaseEventListener multiple times
> -------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-3666
>                 URL: https://issues.jboss.org/browse/JBRULES-3666
>             Project: JBRULES
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.5.0.Beta1
>            Reporter: Toshiya Kobayashi
>            Assignee: Mario Fusco
>             Fix For: 5.5.0.Final
>
>
> When you add the same KnowledgeBaseEventListener to kbase twice, kbase holds both KnowledgeBaseEventListenerWrapper instances. I'm not 100% sure if this is a bug but I guess KnowledgeBaseEventListenerWrapper should implement equals() method like StatefulKnowledgeSessionImpl$AgendaEventListenerWrapper.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 18 09:06:01 2013
From: jira-events at lists.jboss.org (Ken H (JIRA))
Date: Fri, 18 Oct 2013 09:06:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2334) EL expansion broken in
	persistence.xml
In-Reply-To: <JIRA.12508186.1382101486184@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508186.1382101486184@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508186.1382101486184.5401.1382101561982@jira02.app.mwc.hst.phx2.redhat.com>

Ken H created WFLY-2334:
---------------------------

             Summary: EL expansion broken in persistence.xml
                 Key: WFLY-2334
                 URL: https://issues.jboss.org/browse/WFLY-2334
             Project: WildFly
          Issue Type: Bug
    Affects Versions: 8.0.0.Beta1
         Environment: OSX, jdk 1.7.0_21
            Reporter: Ken H


When testing migration from Jboss AS 7.1.1, EL evaluation in persistence.xml no longer functions. I had been using this to change the jta-data-source name for specific environments using environment variables.

{code}
<jta-data-source>java:/myds/datasources/${datasource.name:myds}</jta-data-source>
{code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 18 09:26:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 18 Oct 2013 09:26:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1716) Regression between 3.2.x and
 3.3.x/3.4.x in Infinispan read simulation
In-Reply-To: <JIRA.12503100.1381850347000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503100.1381850347000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503100.1381850347000.5487.1382102762034@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823185#comment-12823185 ] 

Bela Ban commented on JGRP-1716:
--------------------------------

I'll investigate why setting DONT_BUNDLE increases performance (in JGRP-1717); this is not expected.
                
> Regression between 3.2.x and 3.3.x/3.4.x in Infinispan read simulation
> ----------------------------------------------------------------------
>
>                 Key: JGRP-1716
>                 URL: https://issues.jboss.org/browse/JGRP-1716
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.3, 3.4
>            Reporter: Dan Berindei
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>         Attachments: benchmark-jgroups.xml, jgroups-udp.pdf, jgroups-udp.xml
>
>
> Comparing JGroups 3.2/3.3/3.4 performance with Radargun, the throughput of reads in scenario simulating Infinispan went down by ~10%. See the attached chart.
> * getall: the get request is sent to single node (randomly picked owner)
> * getfirst: the get requests are sent to 2 nodes with ResponseMode.GET_FIRST - the second response is discarded.
> .h5 Suspects:
> Erik Salter profiled his application and noticed that the message parsing in the UDP receiver thread seemed to slow things down. He wrote a patch that brought his throughput back to 3.2 levels: https://github.com/an1310/JGroups/compare/t_perfhack
> The UDP receiver thread may not tell the whole story, however: in the Radargun tests, performance with his patch was even lower.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 18 09:28:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 18 Oct 2013 09:28:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1716) Regression between 3.2.x and
 3.3.x/3.4.x in Infinispan read simulation
In-Reply-To: <JIRA.12503100.1381850347000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503100.1381850347000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503100.1381850347000.5490.1382102882001@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823186#comment-12823186 ] 

Bela Ban commented on JGRP-1716:
--------------------------------

So Erik's patch in t_perfhack leaves message batching untouched, but pushes parsing of non-bundled messages back into the thread pools. I don't object to this, as message batching is not affected.

Had message batching been pushed back into the pools, I would have objected as we need to parse the batched messages into different batches (regular, oob-internal and oob) *before* passing them to the pools.
                
> Regression between 3.2.x and 3.3.x/3.4.x in Infinispan read simulation
> ----------------------------------------------------------------------
>
>                 Key: JGRP-1716
>                 URL: https://issues.jboss.org/browse/JGRP-1716
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.3, 3.4
>            Reporter: Dan Berindei
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>         Attachments: benchmark-jgroups.xml, jgroups-udp.pdf, jgroups-udp.xml
>
>
> Comparing JGroups 3.2/3.3/3.4 performance with Radargun, the throughput of reads in scenario simulating Infinispan went down by ~10%. See the attached chart.
> * getall: the get request is sent to single node (randomly picked owner)
> * getfirst: the get requests are sent to 2 nodes with ResponseMode.GET_FIRST - the second response is discarded.
> .h5 Suspects:
> Erik Salter profiled his application and noticed that the message parsing in the UDP receiver thread seemed to slow things down. He wrote a patch that brought his throughput back to 3.2 levels: https://github.com/an1310/JGroups/compare/t_perfhack
> The UDP receiver thread may not tell the whole story, however: in the Radargun tests, performance with his patch was even lower.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 18 09:48:02 2013
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 18 Oct 2013 09:48:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2334) EL expansion broken in
	persistence.xml
In-Reply-To: <JIRA.12508186.1382101486000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508186.1382101486000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508186.1382101486000.5539.1382104082348@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823191#comment-12823191 ] 

jaikiran pai commented on WFLY-2334:
------------------------------------

You mention AS 7.1.1.Final in your description whereas this bug is marked for 8.0.0.Beta1. Which exact version are you using? If you are using 7.1.1.Final, then please try a later version, since from what I remember, the system property expansion in deployment descriptors was done post 7.1.1.Final.

                
> EL expansion broken in persistence.xml
> --------------------------------------
>
>                 Key: WFLY-2334
>                 URL: https://issues.jboss.org/browse/WFLY-2334
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Beta1
>         Environment: OSX, jdk 1.7.0_21
>            Reporter: Ken H
>
> When testing migration from Jboss AS 7.1.1, EL evaluation in persistence.xml no longer functions. I had been using this to change the jta-data-source name for specific environments using environment variables.
> {code}
> <jta-data-source>java:/myds/datasources/${datasource.name:myds}</jta-data-source>
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 18 10:14:02 2013
From: jira-events at lists.jboss.org (Rich DiCroce (JIRA))
Date: Fri, 18 Oct 2013 10:14:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1718) Message corruption under
	heavy load
In-Reply-To: <JIRA.12503731.1381946713000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503731.1381946713000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503731.1381946713000.5587.1382105642094@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823201#comment-12823201 ] 

Rich DiCroce commented on JGRP-1718:
------------------------------------

Thanks for pointing that out, I had missed it. So basically, Kryo can't be used with JGroups as long as it alters the byte array during deserialization. Good to know. I guess you can close this issue as "Not Our Fault" now. :-)
                
> Message corruption under heavy load
> -----------------------------------
>
>                 Key: JGRP-1718
>                 URL: https://issues.jboss.org/browse/JGRP-1718
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.12
>         Environment: JBoss AS 7.2.0.Final (includes JGroups 3.2.7.Final, upgrading to 3.2.12.Final had no effect)
>            Reporter: Rich DiCroce
>            Assignee: Bela Ban
>
> In my project, I'm using the Kryo serialization library to serialize/deserialize objects to/from byte[]. Some of these byte arrays appear to be getting corrupted during transmission.
> The problem happens very infrequently and only under load. I have to send tens of thousands of messages from hundreds of threads just to get two or three errors. The exception occurs when Kryo tries to deserialize the byte[] on the receiving node. So far, all of the errors I've seen happen when Kryo tries to find a class to deserialize an object, and the stack traces end with something like:
> Caused by: java.lang.ClassNotFoundException: java.util.Date[SOH][GS]
> Note that the [SOH] and [GS] are not literally those strings, they're unprintable ASCII 0x1 and 0x1D.
> I'm confident that Kryo itself is not the source of the problem. I added some code to my project to deserialize the message on the sending node, immediately after serializing it, and log any exception thrown from the deserialization. The sending node did not log an exception, but the receiving node still did. My code passes the byte[] to the Message constructor without doing anything to it.
> It also appears that I am not the first person to encounter this issue. See https://code.google.com/p/kryo/issues/detail?id=102

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 18 10:28:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 18 Oct 2013 10:28:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1718) Message corruption under
	heavy load
In-Reply-To: <JIRA.12503731.1381946713000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503731.1381946713000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503731.1381946713000.5613.1382106482148@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823210#comment-12823210 ] 

Bela Ban commented on JGRP-1718:
--------------------------------

No, you could use it, but you'd have to copy the message buffer before passing it to Kryo. When done, you'd have to set the buffer in the message again. Hmm, maybe the latter step is not even needed as you said that Kryo only flips a bit and later flips it back, but doesn't alter the buffer when done... so you copying the message buffer before passing it to Kryo should suffice.
Yes, please mark the case as resolved if this works for you.
                
> Message corruption under heavy load
> -----------------------------------
>
>                 Key: JGRP-1718
>                 URL: https://issues.jboss.org/browse/JGRP-1718
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.12
>         Environment: JBoss AS 7.2.0.Final (includes JGroups 3.2.7.Final, upgrading to 3.2.12.Final had no effect)
>            Reporter: Rich DiCroce
>            Assignee: Bela Ban
>
> In my project, I'm using the Kryo serialization library to serialize/deserialize objects to/from byte[]. Some of these byte arrays appear to be getting corrupted during transmission.
> The problem happens very infrequently and only under load. I have to send tens of thousands of messages from hundreds of threads just to get two or three errors. The exception occurs when Kryo tries to deserialize the byte[] on the receiving node. So far, all of the errors I've seen happen when Kryo tries to find a class to deserialize an object, and the stack traces end with something like:
> Caused by: java.lang.ClassNotFoundException: java.util.Date[SOH][GS]
> Note that the [SOH] and [GS] are not literally those strings, they're unprintable ASCII 0x1 and 0x1D.
> I'm confident that Kryo itself is not the source of the problem. I added some code to my project to deserialize the message on the sending node, immediately after serializing it, and log any exception thrown from the deserialization. The sending node did not log an exception, but the receiving node still did. My code passes the byte[] to the Message constructor without doing anything to it.
> It also appears that I am not the first person to encounter this issue. See https://code.google.com/p/kryo/issues/detail?id=102

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 18 10:28:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 18 Oct 2013 10:28:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1718) Message corruption under
	heavy load
In-Reply-To: <JIRA.12503731.1381946713000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503731.1381946713000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503731.1381946713000.5618.1382106482424@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823102#comment-12823102 ] 

Bela Ban edited comment on JGRP-1718 at 10/18/13 10:26 AM:
-----------------------------------------------------------

Hi Rich,
good investigation !
Byte buffers in a {{Message}} are never copied as they are considered *immutable*, see the javadoc in [1] for example. Actually, they are copied in some cases, but we try to minimize the amount of copying done.

{{Message.copy()}} is one case where multiple threads might access the same message at the same time, retransmission is another one: if the bit in the message was flipped and the same message happened to get retransmitted at the same time, the flipped bit would be sent, wreaking havoc at the receiver(s).

[1] https://github.com/belaban/JGroups/blob/master/src/org/jgroups/Message.java#L251

                
      was (Author: belaban):
    Hi Rich,
good investigation !
Byte buffers in a {{Message}} are never copied as they are considered *immutable*, see the javadoc in [1] for example. Actually, they are copied in some cases, but we try to minimize the amount of copying done.

{{Message.copy()}} is one case where multiple thread might access the same message at the same time, retransmission is another one: if the bit in the message was flipped and the same message happened to get retransmitted at the same time, the flipped bit would be sent, wreaking havoc at the receiver(s).

[1] https://github.com/belaban/JGroups/blob/master/src/org/jgroups/Message.java#L251

                  
> Message corruption under heavy load
> -----------------------------------
>
>                 Key: JGRP-1718
>                 URL: https://issues.jboss.org/browse/JGRP-1718
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.12
>         Environment: JBoss AS 7.2.0.Final (includes JGroups 3.2.7.Final, upgrading to 3.2.12.Final had no effect)
>            Reporter: Rich DiCroce
>            Assignee: Bela Ban
>
> In my project, I'm using the Kryo serialization library to serialize/deserialize objects to/from byte[]. Some of these byte arrays appear to be getting corrupted during transmission.
> The problem happens very infrequently and only under load. I have to send tens of thousands of messages from hundreds of threads just to get two or three errors. The exception occurs when Kryo tries to deserialize the byte[] on the receiving node. So far, all of the errors I've seen happen when Kryo tries to find a class to deserialize an object, and the stack traces end with something like:
> Caused by: java.lang.ClassNotFoundException: java.util.Date[SOH][GS]
> Note that the [SOH] and [GS] are not literally those strings, they're unprintable ASCII 0x1 and 0x1D.
> I'm confident that Kryo itself is not the source of the problem. I added some code to my project to deserialize the message on the sending node, immediately after serializing it, and log any exception thrown from the deserialization. The sending node did not log an exception, but the receiving node still did. My code passes the byte[] to the Message constructor without doing anything to it.
> It also appears that I am not the first person to encounter this issue. See https://code.google.com/p/kryo/issues/detail?id=102

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 18 10:30:02 2013
From: jira-events at lists.jboss.org (Rich DiCroce (JIRA))
Date: Fri, 18 Oct 2013 10:30:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1718) Message corruption under
	heavy load
In-Reply-To: <JIRA.12503731.1381946713000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503731.1381946713000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503731.1381946713000.5623.1382106602127@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rich DiCroce resolved JGRP-1718.
--------------------------------

    Resolution: Rejected

    
> Message corruption under heavy load
> -----------------------------------
>
>                 Key: JGRP-1718
>                 URL: https://issues.jboss.org/browse/JGRP-1718
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.12
>         Environment: JBoss AS 7.2.0.Final (includes JGroups 3.2.7.Final, upgrading to 3.2.12.Final had no effect)
>            Reporter: Rich DiCroce
>            Assignee: Bela Ban
>
> In my project, I'm using the Kryo serialization library to serialize/deserialize objects to/from byte[]. Some of these byte arrays appear to be getting corrupted during transmission.
> The problem happens very infrequently and only under load. I have to send tens of thousands of messages from hundreds of threads just to get two or three errors. The exception occurs when Kryo tries to deserialize the byte[] on the receiving node. So far, all of the errors I've seen happen when Kryo tries to find a class to deserialize an object, and the stack traces end with something like:
> Caused by: java.lang.ClassNotFoundException: java.util.Date[SOH][GS]
> Note that the [SOH] and [GS] are not literally those strings, they're unprintable ASCII 0x1 and 0x1D.
> I'm confident that Kryo itself is not the source of the problem. I added some code to my project to deserialize the message on the sending node, immediately after serializing it, and log any exception thrown from the deserialization. The sending node did not log an exception, but the receiving node still did. My code passes the byte[] to the Message constructor without doing anything to it.
> It also appears that I am not the first person to encounter this issue. See https://code.google.com/p/kryo/issues/detail?id=102

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 18 10:49:02 2013
From: jira-events at lists.jboss.org (Brad Maxwell (JIRA))
Date: Fri, 18 Oct 2013 10:49:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1701) Race condition during server
 start-up - RA not deployed
In-Reply-To: <JIRA.12496518.1373960788000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496518.1373960788000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496518.1373960788000.5639.1382107742130@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823214#comment-12823214 ] 

Brad Maxwell commented on WFLY-1701:
------------------------------------

Issue still exists as of EAP 6.2 Beta, the issue is caused when org.jboss.as.connector.subsystems.resourceadapters.ResourceAdapterService does not start fast enough: 

RULE @1 stall ResourceAdapterService
CLASS org.jboss.as.connector.subsystems.resourceadapters.ResourceAdapterService
METHOD start
AT ENTRY
IF TRUE
DO
  System.out.println( "[BYTEMAN-1] stalling org.jboss.as.connector.subsystems.resourceadapters.ResourceAdapterService");
  Thread.sleep(2000);
ENDRULE

                
> Race condition during server start-up - RA not deployed
> -------------------------------------------------------
>
>                 Key: WFLY-1701
>                 URL: https://issues.jboss.org/browse/WFLY-1701
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 8.0.0.Alpha2
>         Environment: JBoss EAP 6.1, MS Windows server 
>            Reporter: Tom Ross
>            Assignee: Stefano Maestri
>             Fix For: 8.0.0.CR1
>
>
> A custom RA is not being deployed every during server restart even though it is linked to a MDB via @ResourceAdpater annotation. This only happens during server startup. The RA can be deployed successfully via jboss cli every time. When the deployment fails the following message appear in the log file:
> 11:30:45,303 INFO  [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.ra.cdd-ra (missing) dependents: [service jboss.deployment.unit."dmgapp.jar".component.CddListenerClientMDB.CREATE] 
> When comparing the log file from a successful startup with one from a failed one the only difference seems to be the absence of any output from RaXmlDeployer. See below:
> Successful startup:
> {noformat}
> 11:29:24,991 DEBUG [org.jboss.as.connector.logging] (MSC service thread 1-6) starting Inactive:InactiveResourceAdapterDeployment{module=Module "deployment.cdd-ra.rar:main" from Service Module Loader, connectorXmlDescriptor=org.jboss.as.connector.metadata.xmldescriptors.ConnectorXmlDescriptor at 23322e4, deployment='cdd-ra', deploymentUnitName='cdd-ra.rar', registration=org.jboss.as.controller.registry.ConcreteResourceRegistration at 6b37a7dc, serviceTarget=org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget at 12ed9382}
> 11:29:24,991 DEBUG [org.jboss.as.connector.deployment] (MSC service thread 1-6) DEPLOYMENT name = cdd-ra
> 11:29:24,994 TRACE [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-6) Connector=<?xml version="1.0" encoding="UTF-8"?><connector version="1.5"><display-name>DMG CDD Resource Adapter</display-name><vendor-name>Cassidian</vendor-name><eis-type>CDD Server</eis-type><resourceadapter-version>1.0</resourceadapter-version><resourceadapter><resourceadapter-class>com.xx-yy.dmg.jca.eis.CddResourceAdapter</resourceadapter-class><outbound-resourceadapter><connection-definition><managedconnectionfactory-class>com.xx-yy.dmg.jca.eis.CddManagedConnectionFactory</managedconnectionfactory-class><config-property><config-property-name>hostname</config-property-name><config-property-type>java.lang.String</config-property-type></config-property><config-property><config-property-name>port</config-property-name><config-property-type>java.lang.Integer</config-property-type></config-property><config-property><config-property-name>timeout</config-property-name><config-property-type>java.lang.Integer</config-property-type></config-property><config-property><config-property-name>probeTimeout</config-property-name><config-property-type>java.lang.Integer</config-property-type></config-property><connectionfactory-interface>javax.resource.cci.ConnectionFactory</connectionfactory-interface><connectionfactory-impl-class>com.xx-yy.dmg.jca.eis.CddConnectionFactory</connectionfactory-impl-class><connection-interface>javax.resource.cci.Connection</connection-interface><connection-impl-class>com.xx-yy.dmg.jca.eis.CddConnectionImpl</connection-impl-class></connection-definition><transaction-support>NoTransaction</transaction-support><reauthentication-support>false</reauthentication-support></outbound-resourceadapter><inbound-resourceadapter><messageadapter><messagelistener><messagelistener-type>javax.resource.cci.MessageListener</messagelistener-type><activationspec><activationspec-class>com.xx-yy.dmg.jca.eis.CddActivationSpec</activationspec-class><required-config-property><config-property-name>hostname</config-property-name></required-config-property><required-config-property><config-property-name>port</config-property-name></required-config-property><required-config-property><config-property-name>timeout</config-property-name></required-config-property></activationspec></messagelistener></messageadapter></inbound-resourceadapter></resourceadapter></connector>
> 11:29:24,995 TRACE [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-6) IronJacamar=null
> 11:29:24,996 TRACE [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-6) RaXML=null
> 11:29:24,996 TRACE [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-6) ActivateDeployment=false
> 11:29:24,998 DEBUG [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-6) CdMeta: <connection-definition><managedconnectionfactory-class>com.xx-yy.dmg.jca.eis.CddManagedConnectionFactory</managedconnectionfactory-class><config-property><config-property-name>hostname</config-property-name><config-property-type>java.lang.String</config-property-type></config-property><config-property><config-property-name>port</config-property-name><config-property-type>java.lang.Integer</config-property-type></config-property><config-property><config-property-name>timeout</config-property-name><config-property-type>java.lang.Integer</config-property-type></config-property><config-property><config-property-name>probeTimeout</config-property-name><config-property-type>java.lang.Integer</config-property-type></config-property><connectionfactory-interface>javax.resource.cci.ConnectionFactory</connectionfactory-interface><connectionfactory-impl-class>com.xx-yy.dmg.jca.eis.CddConnectionFactory</connectionfactory-impl-class><connection-interface>javax.resource.cci.Connection</connection-interface><connection-impl-class>com.xx-yy.dmg.jca.eis.CddConnectionImpl</connection-impl-class></connection-definition>
> 11:29:25,000 DEBUG [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-6) No activation: com.xx-yy.dmg.jca.eis.CddManagedConnectionFactory
> 11:29:25,001 DEBUG [org.jboss.as.connector.deployment] (MSC service thread 1-6) Registering ResourceAdapter cdd-ra
> 11:29:25,005 DEBUG [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-6) Activated: file:/C:/jboss-eap-6.1_test/standalone/tmp/vfs/temp7ab26b3b80d7102a/cdd-ra.rar-eb8a8dd4a3f65805/contents/
> 11:29:25,005 DEBUG [org.jboss.as.connector.deployment] (MSC service thread 1-6) Not activating: cdd-ra
> 11:29:25,009 TRACE [org.jboss.as.connector.deployers.RaXmlDeployer] (MSC service thread 1-6) Connector=<?xml version="1.0" encoding="UTF-8"?><connector version="1.5"><display-name>DMG CDD Resource Adapter</display-name><vendor-name>Cassidian</vendor-name><eis-type>CDD Server</eis-type><resourceadapter-version>1.0</resourceadapter-version><resourceadapter><resourceadapter-class>com.xx-yy.dmg.jca.eis.CddResourceAdapter</resourceadapter-class><outbound-resourceadapter><connection-definition><managedconnectionfactory-class>com.xx-yy.dmg.jca.eis.CddManagedConnectionFactory</managedconnectionfactory-class><config-property><config-property-name>hostname</config-property-name><config-property-type>java.lang.String</config-property-type></config-property><config-property><config-property-name>port</config-property-name><config-property-type>java.lang.Integer</config-property-type></config-property><config-property><config-property-name>timeout</config-property-name><config-property-type>java.lang.Integer</config-property-type></config-property><config-property><config-property-name>probeTimeout</config-property-name><config-property-type>java.lang.Integer</config-property-type></config-property><connectionfactory-interface>javax.resource.cci.ConnectionFactory</connectionfactory-interface><connectionfactory-impl-class>com.xx-yy.dmg.jca.eis.CddConnectionFactory</connectionfactory-impl-class><connection-interface>javax.resource.cci.Connection</connection-interface><connection-impl-class>com.xx-yy.dmg.jca.eis.CddConnectionImpl</connection-impl-class></connection-definition><transaction-support>NoTransaction</transaction-support><reauthentication-support>false</reauthentication-support></outbound-resourceadapter><inbound-resourceadapter><messageadapter><messagelistener><messagelistener-type>javax.resource.cci.MessageListener</messagelistener-type><activationspec><activationspec-class>com.xx-yy.dmg.jca.eis.CddActivationSpec</activationspec-class><required-config-property><config-property-name>hostname</config-property-name></required-config-property><required-config-property><config-property-name>port</config-property-name></required-config-property><required-config-property><config-property-name>timeout</config-property-name></required-config-property></activationspec></messagelistener></messageadapter></inbound-resourceadapter></resourceadapter></connector>
> 11:29:25,010 TRACE [org.jboss.as.connector.deployers.RaXmlDeployer] (MSC service thread 1-6) IronJacamar=null
> 11:29:25,010 TRACE [org.jboss.as.connector.deployers.RaXmlDeployer] (MSC service thread 1-6) RaXML=<resource-adapter><archive>cdd-ra.rar</archive><transaction-support>NoTransaction</transaction-support><connection-definitions><connection-definition class-name="com.xx-yy.dmg.jca.eis.CddManagedConnectionFactory" jndi-name="java:jboss/ra/cdd-connector" enabled="true" use-java-context="true" pool-name="ra/cdd-connector" use-ccm="false"><config-property name="port">42006</config-property><config-property name="probeTimeout">10</config-property><config-property name="timeout">45</config-property><config-property name="hostname">localhost</config-property><pool><min-pool-size>0</min-pool-size><max-pool-size>1</max-pool-size><prefill>false</prefill><use-strict-min>false</use-strict-min><flush-strategy>FailingConnectionOnly</flush-strategy></pool><timeout><blocking-timeout-millis>60000</blocking-timeout-millis></timeout><validation><background-validation>false</background-validation><use-fast-fail>false</use-fast-fail></validation></connection-definition></connection-definitions></resource-adapter>
> 11:29:25,012 TRACE [org.jboss.as.connector.deployers.RaXmlDeployer] (MSC service thread 1-6) ActivateDeployment=true
> 11:29:25,014 TRACE [org.jboss.as.connector.deployers.RaXmlDeployer] (MSC service thread 1-6) ResourceAdapter: com.xx-yy.dmg.jca.eis.CddResourceAdapter
> 11:29:25,014 TRACE [org.jboss.as.connector.deployers.RaXmlDeployer] (MSC service thread 1-6) ResourceAdapter defined in classloader: ModuleClassLoader for Module "deployment.cdd-ra.rar:main" from Service Module Loader
> 11:29:25,014 DEBUG [org.jboss.as.connector.deployers.RaXmlDeployer] (MSC service thread 1-6) CdMeta: <connection-definition><managedconnectionfactory-class>com.xx-yy.dmg.jca.eis.CddManagedConnectionFactory</managedconnectionfactory-class><config-property><config-property-name>hostname</config-property-name><config-property-type>java.lang.String</config-property-type></config-property><config-property><config-property-name>port</config-property-name><config-property-type>java.lang.Integer</config-property-type></config-property><config-property><config-property-name>timeout</config-property-name><config-property-type>java.lang.Integer</config-property-type></config-property><config-property><config-property-name>probeTimeout</config-property-name><config-property-type>java.lang.Integer</config-property-type></config-property><connectionfactory-interface>javax.resource.cci.ConnectionFactory</connectionfactory-interface><connectionfactory-impl-class>com.xx-yy.dmg.jca.eis.CddConnectionFactory</connectionfactory-impl-class><connection-interface>javax.resource.cci.Connection</connection-interface><connection-impl-class>com.xx-yy.dmg.jca.eis.CddConnectionImpl</connection-impl-class></connection-definition>
> 11:29:25,015 DEBUG [org.jboss.as.connector.deployers.RaXmlDeployer] (MSC service thread 1-6) ConnectionDefinitions: 1
> 11:29:25,017 DEBUG [org.jboss.as.connector.deployers.RaXmlDeployer] (MSC service thread 1-6) Activating: <connection-definition class-name="com.xx-yy.dmg.jca.eis.CddManagedConnectionFactory" jndi-name="java:jboss/ra/cdd-connector" enabled="true" use-java-context="true" pool-name="ra/cdd-connector" use-ccm="false"><config-property name="port">42006</config-property><config-property name="probeTimeout">10</config-property><config-property name="timeout">45</config-property><config-property name="hostname">localhost</config-property><pool><min-pool-size>0</min-pool-size><max-pool-size>1</max-pool-size><prefill>false</prefill><use-strict-min>false</use-strict-min><flush-strategy>FailingConnectionOnly</flush-strategy></pool><timeout><blocking-timeout-millis>60000</blocking-timeout-millis></timeout><validation><background-validation>false</background-validation><use-fast-fail>false</use-fast-fail></validation></connection-definition>
> 11:29:25,018 INFO  [com.xx-yy.dmg.jca.eis.CddManagedConnectionFactory] (MSC service thread 1-6) setPort() called.
> 11:29:25,019 INFO  [com.xx-yy.dmg.jca.eis.CddManagedConnectionFactory] (MSC service thread 1-6) setProbeTiemout() called.
> 11:29:25,021 INFO  [com.xx-yy.dmg.jca.eis.CddManagedConnectionFactory] (MSC service thread 1-6) setTimeout() called.
> 11:29:25,021 INFO  [com.xx-yy.dmg.jca.eis.CddManagedConnectionFactory] (MSC service thread 1-6) setHostname() called.
> {noformat}
> Failed startup:
> {noformat}
> 11:30:44,391 DEBUG [org.jboss.as.connector.deployment] (MSC service thread 1-5) DEPLOYMENT name = cdd-ra
> 11:30:44,402 TRACE [org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer] (MSC service thread 1-8) DataSource=<datasource jndi-name="java:jboss/datasources/ExampleDS" pool-name="ExampleDS" enabled="true" use-java-context="true" spy="false" use-ccm="true" jta="true"><connection-url>jdbc:h2:mem:test;DB_CLOSE_DELAY=-1</connection-url><driver>h2</driver><pool><min-pool-size>0</min-pool-size><max-pool-size>20</max-pool-size><prefill>false</prefill><use-strict-min>false</use-strict-min><flush-strategy>FailingConnectionOnly</flush-strategy></pool><security><user-name>sa</user-name><password>sa</password></security><validation><validate-on-match>false</validate-on-match><background-validation>false</background-validation><use-fast-fail>false</use-fast-fail></validation><timeout></timeout><statement><track-statements>nowarn</track-statements></statement></datasource>
> 11:30:44,408 TRACE [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-5) Connector=<?xml version="1.0" encoding="UTF-8"?><connector version="1.5"><display-name>DMG CDD Resource Adapter</display-name><vendor-name>Cassidian</vendor-name><eis-type>CDD Server</eis-type><resourceadapter-version>1.0</resourceadapter-version><resourceadapter><resourceadapter-class>com.xx-yy.dmg.jca.eis.CddResourceAdapter</resourceadapter-class><outbound-resourceadapter><connection-definition><managedconnectionfactory-class>com.xx-yy.dmg.jca.eis.CddManagedConnectionFactory</managedconnectionfactory-class><config-property><config-property-name>hostname</config-property-name><config-property-type>java.lang.String</config-property-type></config-property><config-property><config-property-name>port</config-property-name><config-property-type>java.lang.Integer</config-property-type></config-property><config-property><config-property-name>timeout</config-property-name><config-property-type>java.lang.Integer</config-property-type></config-property><config-property><config-property-name>probeTimeout</config-property-name><config-property-type>java.lang.Integer</config-property-type></config-property><connectionfactory-interface>javax.resource.cci.ConnectionFactory</connectionfactory-interface><connectionfactory-impl-class>com.xx-yy.dmg.jca.eis.CddConnectionFactory</connectionfactory-impl-class><connection-interface>javax.resource.cci.Connection</connection-interface><connection-impl-class>com.xx-yy.dmg.jca.eis.CddConnectionImpl</connection-impl-class></connection-definition><transaction-support>NoTransaction</transaction-support><reauthentication-support>false</reauthentication-support></outbound-resourceadapter><inbound-resourceadapter><messageadapter><messagelistener><messagelistener-type>javax.resource.cci.MessageListener</messagelistener-type><activationspec><activationspec-class>com.xx-yy.dmg.jca.eis.CddActivationSpec</activationspec-class><required-config-property><config-property-name>hostname</config-property-name></required-config-property><required-config-property><config-property-name>port</config-property-name></required-config-property><required-config-property><config-property-name>timeout</config-property-name></required-config-property></activationspec></messagelistener></messageadapter></inbound-resourceadapter></resourceadapter></connector>
> 11:30:44,410 TRACE [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-5) IronJacamar=null
> 11:30:44,410 TRACE [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-5) RaXML=null
> 11:30:44,410 TRACE [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-5) ActivateDeployment=false
> 11:30:44,445 DEBUG [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-5) CdMeta: <connection-definition><managedconnectionfactory-class>com.xx-yy.dmg.jca.eis.CddManagedConnectionFactory</managedconnectionfactory-class><config-property><config-property-name>hostname</config-property-name><config-property-type>java.lang.String</config-property-type></config-property><config-property><config-property-name>port</config-property-name><config-property-type>java.lang.Integer</config-property-type></config-property><config-property><config-property-name>timeout</config-property-name><config-property-type>java.lang.Integer</config-property-type></config-property><config-property><config-property-name>probeTimeout</config-property-name><config-property-type>java.lang.Integer</config-property-type></config-property><connectionfactory-interface>javax.resource.cci.ConnectionFactory</connectionfactory-interface><connectionfactory-impl-class>com.xx-yy.dmg.jca.eis.CddConnectionFactory</connectionfactory-impl-class><connection-interface>javax.resource.cci.Connection</connection-interface><connection-impl-class>com.xx-yy.dmg.jca.eis.CddConnectionImpl</connection-impl-class></connection-definition>
> 11:30:44,450 DEBUG [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-5) No activation: com.xx-yy.dmg.jca.eis.CddManagedConnectionFactory
> 11:30:44,452 DEBUG [org.jboss.as.connector.deployment] (MSC service thread 1-5) Registering ResourceAdapter cdd-ra
> 11:30:44,453 DEBUG [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-5) Activated: file:/C:/jboss-eap-6.1_test/standalone/tmp/vfs/temp3cf601edad306224/cdd-ra.rar-5ec7930ccabd45d/contents/
> 11:30:44,454 DEBUG [org.jboss.as.connector.deployment] (MSC service thread 1-5) Not activating: cdd-ra
> 11:30:44,468 DEBUG [org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer] (MSC service thread 1-8) Adding management datasource: DataSource at 1f69b08 xa=false jndiName=java:jboss/datasources/ExampleDS pool=org.jboss.jca.core.connectionmanager.pool.strategy.OnePool at 653c2b39 poolconfiguration=PoolConfiguration at 5139df1b[minSize=0 maxSize=20 blockingTimeout=30000 idleTimeoutMinutes=30 backgroundValidation=false backgroundValidationMillis=0 prefill=false strictMin=false useFastFail=false] statistics=org.jboss.jca.adapters.jdbc.statistics.JdbcStatisticsPlugin at 2e668f46]
> 11:30:44,482 DEBUG [org.jboss.as.connector.deployer.dsdeployer] (MSC service thread 1-8) Adding datasource: java:jboss/datasources/ExampleDS
> 11:30:44,485 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-3) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
> 11:30:44,578 INFO  [org.hornetq.core.server] (MSC service thread 1-1) HQ221034: Waiting to obtain live lock
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Fri Oct 18 11:25:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 18 Oct 2013 11:25:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1697) Fix JPA
 SerializableValidatorFactory memory leak
In-Reply-To: <JIRA.12496481.1373901643000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496481.1373901643000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496481.1373901643000.5714.1382109902060@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823230#comment-12823230 ] 

RH Bugzilla Integration commented on WFLY-1697:
-----------------------------------------------

Marek Schmidt <maschmid at redhat.com> made a comment on [bug 1003600|https://bugzilla.redhat.com/show_bug.cgi?id=1003600]

Verified on EAP 6.2.0.ER6. 

I have noticed the instances are still laying around in memory for quite a while after the deployment ends awaiting finalization, but I expect this to be just Java being lazy about finalization, as there are no GC roots to be found for them now...
                
> Fix JPA SerializableValidatorFactory memory leak
> ------------------------------------------------
>
>                 Key: WFLY-1697
>                 URL: https://issues.jboss.org/browse/WFLY-1697
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>
> See http://lists.jboss.org/pipermail/wildfly-dev/2013-July/000466.html for details on recreating the SerializableValidatorFactory leak and Hibernate service loader references to Integreation class/properties.  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 18 11:25:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 18 Oct 2013 11:25:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1697) Fix JPA
 SerializableValidatorFactory memory leak
In-Reply-To: <JIRA.12496481.1373901643000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496481.1373901643000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496481.1373901643000.5716.1382109902140@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823231#comment-12823231 ] 

RH Bugzilla Integration commented on WFLY-1697:
-----------------------------------------------

Marek Schmidt <maschmid at redhat.com> changed the Status of [bug 1003600|https://bugzilla.redhat.com/show_bug.cgi?id=1003600] from ON_QA to VERIFIED
                
> Fix JPA SerializableValidatorFactory memory leak
> ------------------------------------------------
>
>                 Key: WFLY-1697
>                 URL: https://issues.jboss.org/browse/WFLY-1697
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>
> See http://lists.jboss.org/pipermail/wildfly-dev/2013-July/000466.html for details on recreating the SerializableValidatorFactory leak and Hibernate service loader references to Integreation class/properties.  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 18 11:32:02 2013
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Fri, 18 Oct 2013 11:32:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2335) BroadcastGroupAdd model
 population fails on JDK8
In-Reply-To: <JIRA.12508204.1382110282078@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508204.1382110282078@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508204.1382110282078.5723.1382110322034@jira02.app.mwc.hst.phx2.redhat.com>

Jeff Mesnil created WFLY-2335:
---------------------------------

             Summary: BroadcastGroupAdd model population fails on JDK8
                 Key: WFLY-2335
                 URL: https://issues.jboss.org/browse/WFLY-2335
             Project: WildFly
          Issue Type: Bug
          Components: JMS
    Affects Versions: 8.0.0.Beta1
         Environment: JDK8
            Reporter: Jeff Mesnil
            Assignee: Jeff Mesnil
             Fix For: 8.0.0.CR1


http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=4515

All messaging subsystem tests passes on JDK7 but fails with JDK8 because BroadcastGroupAdd#populateModel falsely assumes that the connector resources have been populated *before* the current broadcast-group.

There is no such guarantee, the connector-refs validations must be done in a separate OperationStepHandler *after* all the MODEL's OSHs instead.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 18 11:48:02 2013
From: jira-events at lists.jboss.org (Aaron Ogburn (JIRA))
Date: Fri, 18 Oct 2013 11:48:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2336) Decreasing max-threads on a
 unbounded queuesless executor generates IllegalArgumentException
In-Reply-To: <JIRA.12508206.1382111218149@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508206.1382111218149@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508206.1382111218149.5765.1382111282189@jira02.app.mwc.hst.phx2.redhat.com>

Aaron Ogburn created WFLY-2336:
----------------------------------

             Summary: Decreasing max-threads on a unbounded queuesless executor generates IllegalArgumentException
                 Key: WFLY-2336
                 URL: https://issues.jboss.org/browse/WFLY-2336
             Project: WildFly
          Issue Type: Bug
    Affects Versions: 8.0.0.Beta1
            Reporter: Aaron Ogburn
            Priority: Minor


Create an unbounded queueless executor

<unbounded-queue-thread-pool name="uq-thread-pool">
<max-threads count="350"/>
<keepalive-time time="5" unit="minutes"/>
</unbounded-queue-thread-pool>

Modifying max-threads fails:

/subsystem=threads/unbounded-queue-thread-pool=uq-thread-pool:write-attribute(name=max-threads,value=300)
{
    "outcome" => "failed",
    "failure-description" => "JBAS014749: Operation handler failed: null",
    "rolled-back" => true
}

ler-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [wildfly-protocol-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [wildfly-protocol-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0]
	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0]
	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]


The core pool size needs to be adjusted in line with the max pool size to avoid that.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 18 11:56:02 2013
From: jira-events at lists.jboss.org (Aaron Ogburn (JIRA))
Date: Fri, 18 Oct 2013 11:56:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2336) Decreasing max-threads on a
 unbounded queuesless executor generates IllegalArgumentException
In-Reply-To: <JIRA.12508206.1382111218000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508206.1382111218000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508206.1382111218000.5787.1382111762145@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aaron Ogburn updated WFLY-2336:
-------------------------------

    Git Pull Request: https://github.com/wildfly/wildfly/pull/5302

    
> Decreasing max-threads on a unbounded queuesless executor generates IllegalArgumentException
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2336
>                 URL: https://issues.jboss.org/browse/WFLY-2336
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Aaron Ogburn
>            Priority: Minor
>
> Create an unbounded queueless executor
> <unbounded-queue-thread-pool name="uq-thread-pool">
> <max-threads count="350"/>
> <keepalive-time time="5" unit="minutes"/>
> </unbounded-queue-thread-pool>
> Modifying max-threads fails:
> /subsystem=threads/unbounded-queue-thread-pool=uq-thread-pool:write-attribute(name=max-threads,value=300)
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014749: Operation handler failed: null",
>     "rolled-back" => true
> }
> ler-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [wildfly-protocol-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [wildfly-protocol-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> The core pool size needs to be adjusted in line with the max pool size to avoid that.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 18 11:56:02 2013
From: jira-events at lists.jboss.org (Aaron Ogburn (JIRA))
Date: Fri, 18 Oct 2013 11:56:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2336) Decreasing max-threads on a
 unbounded queuesless executor generates IllegalArgumentException
In-Reply-To: <JIRA.12508206.1382111218000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508206.1382111218000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508206.1382111218000.5788.1382111762181@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823242#comment-12823242 ] 

Aaron Ogburn commented on WFLY-2336:
------------------------------------

This fixed it for me:

https://github.com/wildfly/wildfly/pull/5302
                
> Decreasing max-threads on a unbounded queuesless executor generates IllegalArgumentException
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2336
>                 URL: https://issues.jboss.org/browse/WFLY-2336
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Aaron Ogburn
>            Priority: Minor
>
> Create an unbounded queueless executor
> <unbounded-queue-thread-pool name="uq-thread-pool">
> <max-threads count="350"/>
> <keepalive-time time="5" unit="minutes"/>
> </unbounded-queue-thread-pool>
> Modifying max-threads fails:
> /subsystem=threads/unbounded-queue-thread-pool=uq-thread-pool:write-attribute(name=max-threads,value=300)
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014749: Operation handler failed: null",
>     "rolled-back" => true
> }
> ler-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [wildfly-protocol-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [wildfly-protocol-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> The core pool size needs to be adjusted in line with the max pool size to avoid that.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 18 12:02:02 2013
From: jira-events at lists.jboss.org (Aaron Ogburn (JIRA))
Date: Fri, 18 Oct 2013 12:02:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2336) Decreasing max-threads on a
 unbounded queuesless executor generates IllegalArgumentException
In-Reply-To: <JIRA.12508206.1382111218000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508206.1382111218000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508206.1382111218000.5806.1382112122079@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aaron Ogburn updated WFLY-2336:
-------------------------------

    Description: 
Create an unbounded queueless executor

<unbounded-queue-thread-pool name="uq-thread-pool">
<max-threads count="350"/>
<keepalive-time time="5" unit="minutes"/>
</unbounded-queue-thread-pool>

Modifying max-threads fails:

/subsystem=threads/unbounded-queue-thread-pool=uq-thread-pool:write-attribute(name=max-threads,value=300)
{
    "outcome" => "failed",
    "failure-description" => "JBAS014749: Operation handler failed: null",
    "rolled-back" => true
}

ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) JBAS014612: Operation ("write-attribute") failed - address: ([
    ("subsystem" => "threads"),
    ("unbounded-queue-thread-pool" => "uq-thread-pool")
]): java.lang.IllegalArgumentException
	at java.util.concurrent.ThreadPoolExecutor.setMaximumPoolSize(ThreadPoolExecutor.java:1620) [rt.jar:1.7.0]
	at org.jboss.threads.JBossThreadPoolExecutor.setMaxThreads(JBossThreadPoolExecutor.java:95) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
	at org.jboss.as.threads.ManagedJBossThreadPoolExecutorService.setMaxThreads(ManagedJBossThreadPoolExecutorService.java:86)
	at org.jboss.as.threads.UnboundedQueueThreadPoolService.setMaxThreads(UnboundedQueueThreadPoolService.java:91)


The core pool size needs to be adjusted in line with the max pool size to avoid that.


  was:
Create an unbounded queueless executor

<unbounded-queue-thread-pool name="uq-thread-pool">
<max-threads count="350"/>
<keepalive-time time="5" unit="minutes"/>
</unbounded-queue-thread-pool>

Modifying max-threads fails:

/subsystem=threads/unbounded-queue-thread-pool=uq-thread-pool:write-attribute(name=max-threads,value=300)
{
    "outcome" => "failed",
    "failure-description" => "JBAS014749: Operation handler failed: null",
    "rolled-back" => true
}

ler-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [wildfly-protocol-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [wildfly-protocol-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0]
	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0]
	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]


The core pool size needs to be adjusted in line with the max pool size to avoid that.



    
> Decreasing max-threads on a unbounded queuesless executor generates IllegalArgumentException
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2336
>                 URL: https://issues.jboss.org/browse/WFLY-2336
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Aaron Ogburn
>            Priority: Minor
>
> Create an unbounded queueless executor
> <unbounded-queue-thread-pool name="uq-thread-pool">
> <max-threads count="350"/>
> <keepalive-time time="5" unit="minutes"/>
> </unbounded-queue-thread-pool>
> Modifying max-threads fails:
> /subsystem=threads/unbounded-queue-thread-pool=uq-thread-pool:write-attribute(name=max-threads,value=300)
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014749: Operation handler failed: null",
>     "rolled-back" => true
> }
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) JBAS014612: Operation ("write-attribute") failed - address: ([
>     ("subsystem" => "threads"),
>     ("unbounded-queue-thread-pool" => "uq-thread-pool")
> ]): java.lang.IllegalArgumentException
> 	at java.util.concurrent.ThreadPoolExecutor.setMaximumPoolSize(ThreadPoolExecutor.java:1620) [rt.jar:1.7.0]
> 	at org.jboss.threads.JBossThreadPoolExecutor.setMaxThreads(JBossThreadPoolExecutor.java:95) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> 	at org.jboss.as.threads.ManagedJBossThreadPoolExecutorService.setMaxThreads(ManagedJBossThreadPoolExecutorService.java:86)
> 	at org.jboss.as.threads.UnboundedQueueThreadPoolService.setMaxThreads(UnboundedQueueThreadPoolService.java:91)
> The core pool size needs to be adjusted in line with the max pool size to avoid that.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 18 12:06:03 2013
From: jira-events at lists.jboss.org (Aaron Ogburn (JIRA))
Date: Fri, 18 Oct 2013 12:06:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2336) Decreasing max-threads on a
 unbounded queuesless executor generates IllegalArgumentException
In-Reply-To: <JIRA.12508206.1382111218000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508206.1382111218000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508206.1382111218000.5808.1382112363130@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aaron Ogburn updated WFLY-2336:
-------------------------------

    Description: 
Create an unbounded queueless executor

<unbounded-queue-thread-pool name="uq-thread-pool">
<max-threads count="350"/>
<keepalive-time time="5" unit="minutes"/>
</unbounded-queue-thread-pool>

Modifying max-threads fails:

/subsystem=threads/unbounded-queue-thread-pool=uq-thread-pool:write-attribute(name=max-threads,value=300)
{
    "outcome" => "failed",
    "failure-description" => "JBAS014749: Operation handler failed: null",
    "rolled-back" => true
}

ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) JBAS014612: Operation ("write-attribute") failed - address: ([
    ("subsystem" => "threads"),
    ("unbounded-queue-thread-pool" => "uq-thread-pool")
]): java.lang.IllegalArgumentException
	at java.util.concurrent.ThreadPoolExecutor.setMaximumPoolSize(ThreadPoolExecutor.java:1620) [rt.jar:1.7.0]
	at org.jboss.threads.JBossThreadPoolExecutor.setMaxThreads(JBossThreadPoolExecutor.java:95) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
	at org.jboss.as.threads.ManagedJBossThreadPoolExecutorService.setMaxThreads(ManagedJBossThreadPoolExecutorService.java:86)
	at org.jboss.as.threads.UnboundedQueueThreadPoolService.setMaxThreads(UnboundedQueueThreadPoolService.java:91)


The core pool size needs to be adjusted in line with the max pool size and in the right order to avoid that since max threads can't be less than core threads.


  was:
Create an unbounded queueless executor

<unbounded-queue-thread-pool name="uq-thread-pool">
<max-threads count="350"/>
<keepalive-time time="5" unit="minutes"/>
</unbounded-queue-thread-pool>

Modifying max-threads fails:

/subsystem=threads/unbounded-queue-thread-pool=uq-thread-pool:write-attribute(name=max-threads,value=300)
{
    "outcome" => "failed",
    "failure-description" => "JBAS014749: Operation handler failed: null",
    "rolled-back" => true
}

ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) JBAS014612: Operation ("write-attribute") failed - address: ([
    ("subsystem" => "threads"),
    ("unbounded-queue-thread-pool" => "uq-thread-pool")
]): java.lang.IllegalArgumentException
	at java.util.concurrent.ThreadPoolExecutor.setMaximumPoolSize(ThreadPoolExecutor.java:1620) [rt.jar:1.7.0]
	at org.jboss.threads.JBossThreadPoolExecutor.setMaxThreads(JBossThreadPoolExecutor.java:95) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
	at org.jboss.as.threads.ManagedJBossThreadPoolExecutorService.setMaxThreads(ManagedJBossThreadPoolExecutorService.java:86)
	at org.jboss.as.threads.UnboundedQueueThreadPoolService.setMaxThreads(UnboundedQueueThreadPoolService.java:91)


The core pool size needs to be adjusted in line with the max pool size to avoid that.



    
> Decreasing max-threads on a unbounded queuesless executor generates IllegalArgumentException
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2336
>                 URL: https://issues.jboss.org/browse/WFLY-2336
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Aaron Ogburn
>            Priority: Minor
>
> Create an unbounded queueless executor
> <unbounded-queue-thread-pool name="uq-thread-pool">
> <max-threads count="350"/>
> <keepalive-time time="5" unit="minutes"/>
> </unbounded-queue-thread-pool>
> Modifying max-threads fails:
> /subsystem=threads/unbounded-queue-thread-pool=uq-thread-pool:write-attribute(name=max-threads,value=300)
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014749: Operation handler failed: null",
>     "rolled-back" => true
> }
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) JBAS014612: Operation ("write-attribute") failed - address: ([
>     ("subsystem" => "threads"),
>     ("unbounded-queue-thread-pool" => "uq-thread-pool")
> ]): java.lang.IllegalArgumentException
> 	at java.util.concurrent.ThreadPoolExecutor.setMaximumPoolSize(ThreadPoolExecutor.java:1620) [rt.jar:1.7.0]
> 	at org.jboss.threads.JBossThreadPoolExecutor.setMaxThreads(JBossThreadPoolExecutor.java:95) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> 	at org.jboss.as.threads.ManagedJBossThreadPoolExecutorService.setMaxThreads(ManagedJBossThreadPoolExecutorService.java:86)
> 	at org.jboss.as.threads.UnboundedQueueThreadPoolService.setMaxThreads(UnboundedQueueThreadPoolService.java:91)
> The core pool size needs to be adjusted in line with the max pool size and in the right order to avoid that since max threads can't be less than core threads.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 18 12:13:01 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 18 Oct 2013 12:13:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2337) Eliminate additional round
 trip exchange of Subject from host controller to app server or slave host
 controllers.
In-Reply-To: <JIRA.12508207.1382112747215@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508207.1382112747215@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508207.1382112747215.5822.1382112781949@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-2337:
--------------------------------------

             Summary: Eliminate additional round trip exchange of Subject from host controller to app server or slave host controllers.
                 Key: WFLY-2337
                 URL: https://issues.jboss.org/browse/WFLY-2337
             Project: WildFly
          Issue Type: Sub-task
          Components: Domain Management
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 8.0.0.CR1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 18 12:17:02 2013
From: jira-events at lists.jboss.org (Tom Jenkinson (JIRA))
Date: Fri, 18 Oct 2013 12:17:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2338) When using a JDBC object
 store,
 the RecoveryManager service stop can occur after the datasource is already
 stopped
In-Reply-To: <JIRA.12508208.1382112933102@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508208.1382112933102@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508208.1382112933102.5827.1382113022124@jira02.app.mwc.hst.phx2.redhat.com>

Tom Jenkinson created WFLY-2338:
-----------------------------------

             Summary: When using a JDBC object store, the RecoveryManager service stop can occur after the datasource is already stopped
                 Key: WFLY-2338
                 URL: https://issues.jboss.org/browse/WFLY-2338
             Project: WildFly
          Issue Type: Bug
          Components: Transactions
            Reporter: Tom Jenkinson
            Assignee: Stefano Maestri


It should be the cause of https://bugzilla.redhat.com/show_bug.cgi?id=1020881

It has the effects described in the BZ, i.e. can cause warnings or can entirely block the application server from stopping

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 18 12:17:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 18 Oct 2013 12:17:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2338) When using a JDBC object
 store,
 the RecoveryManager service stop can occur after the datasource is already
 stopped
In-Reply-To: <JIRA.12508208.1382112933000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508208.1382112933000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508208.1382112933000.5831.1382113022352@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2338:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1020881

    
> When using a JDBC object store, the RecoveryManager service stop can occur after the datasource is already stopped
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2338
>                 URL: https://issues.jboss.org/browse/WFLY-2338
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>            Reporter: Tom Jenkinson
>            Assignee: Stefano Maestri
>
> It should be the cause of https://bugzilla.redhat.com/show_bug.cgi?id=1020881
> It has the effects described in the BZ, i.e. can cause warnings or can entirely block the application server from stopping

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 18 12:56:01 2013
From: jira-events at lists.jboss.org (Guillaume Grossetie (JIRA))
Date: Fri, 18 Oct 2013 12:56:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2321) Add user configuration
 loading broken if executed from any folder other than bin
In-Reply-To: <JIRA.12503723.1381941728000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503723.1381941728000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503723.1381941728000.5903.1382115361912@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823258#comment-12823258 ] 

Guillaume Grossetie commented on WFLY-2321:
-------------------------------------------

Ooops sorry my mistake!
Next time you can assign me to the issue :)
                
> Add user configuration loading broken if executed from any folder other than bin
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-2321
>                 URL: https://issues.jboss.org/browse/WFLY-2321
>             Project: WildFly
>          Issue Type: Bug
>          Components: Scripts
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Also should remove the system property reading and just rely on the location being bin.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 18 12:58:01 2013
From: jira-events at lists.jboss.org (Jeremy Whiting (JIRA))
Date: Fri, 18 Oct 2013 12:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-281) Inconsistent use of
 genStringAsCharArray in Tomcat 6.
In-Reply-To: <JIRA.12508212.1382115445128@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508212.1382115445128@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508212.1382115445128.5905.1382115481877@jira02.app.mwc.hst.phx2.redhat.com>

Jeremy Whiting created JBWEB-281:
------------------------------------

             Summary: Inconsistent use of genStringAsCharArray in Tomcat 6.
                 Key: JBWEB-281
                 URL: https://issues.jboss.org/browse/JBWEB-281
             Project: JBoss Web
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Tomcat
    Affects Versions: JBossWeb-7.2.1.GA
         Environment: All environments.
            Reporter: Jeremy Whiting
            Assignee: Remy Maucherat


 The JSP configuration property "genStringAsCharArray" is inconsistently named in Tomcat 6. This means the enabling of the feature for using char array type rather than String in generated Servlet code is not enabled.
 This issue has been fixed upstream in the 7.0 branch of Tomcat hosted at Apache.

I have created an ASF BZ https://issues.apache.org/bugzilla/show_bug.cgi?id=55671 to request the SVN revision https://issues.apache.org/bugzilla/show_bug.cgi?id=55671 be backported to Tomcat 6.0 branch.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 18 13:09:02 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 18 Oct 2013 13:09:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2027) EE Default DataSource is not
	working
In-Reply-To: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500313.1378739268000.5935.1382116142330@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar reopened WFLY-2027:
-------------------------------


    
> EE Default DataSource is not working
> ------------------------------------
>
>                 Key: WFLY-2027
>                 URL: https://issues.jboss.org/browse/WFLY-2027
>             Project: WildFly
>          Issue Type: Bug
>          Components: ConfigAdmin, Domain Management, EE, JCA, JPA / Hibernate, Web Console
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Lincoln Baxter III
>            Assignee: Eduardo Martins
>             Fix For: 8.0.0.Beta1
>
>
> The EE spec states that a default datasource must be supplied under: java:comp/DefaultDataSource, and if none is specified by the @Resource or persistence.xml, it must be assumed:
>  {code}EE 5.19
> The Java EE Platform requires that a Java EE Product Provider provide a database 
> in the operational environment (see Section EE.2.6, ?Database?). The Java EE 
> Product Provider must also provide a preconfigured, default data source for use by 
> the application in accessing this database.
> The Java EE Product Provider must make the default data source accessible to 
> the application under the JNDI name java:comp/DefaultDataSource.
> The Application Component Provider or Deployer may explicitly bind a 
> DataSource resource reference to the default data source using the lookup element 
> of the Resource annotation or the lookup-name element of the resource-ref
> deployment descriptor element. For example,
> @Resource(lookup="java:comp/DefaultDataSource")
> DataSource myDS;
> In the absence of such a binding, the mapping of the reference will default to 
> the product's default data source.
> For example, the following will map to a preconfigured data source for the 
> product's default database:
> @Resource
> DataSource myDS;{code}
> This, isn't working however:
> {code}
> <persistence version="2.1" xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>    xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/persistence/persistence_2_1.xsd">
>    <persistence-unit name="default" transaction-type="JTA">
>    </persistence-unit>
> </persistence>{code}
> Results in: 
> {code}
> 10:41:31,002 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 50) MSC000001: Failed to start service jboss.persistenceunit."jpa-standard.war#default": org.jboss.msc.service.StartException in service jboss.persistenceunit."jpa-standard.war#default": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:134) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.determineDialect(DialectFactoryImpl.java:98)
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.buildDialect(DialectFactoryImpl.java:66)
> 	at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:193)
> 	at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:88)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:159)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131)
> 	at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration.java:1844)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1802)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:844)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835)
> 	at org.jboss.as.jpa.hibernate4.management.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:115) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	... 4 more
> 10:41:31,010 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"jpa-standard.war#default\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"jpa-standard.war#default\": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
>     Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set"}}
> {code}
> Additionally, actually specifying the expected JDNI name of the default DS like this:
> {code}   <persistence-unit name="default" transaction-type="JTA">
>       <jta-data-source>java:comp/DefaultDataSource</jta-data-source>
>       <exclude-unlisted-classes>false</exclude-unlisted-classes>
>    </persistence-unit>{code}
> Results in this:
> {code}
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.naming.context.java.module.jpa-standard.jpa-standard.DefaultDataSource (missing) dependents: [service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__] 
>       service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__ (missing) dependents: [service jboss.deployment.unit."jpa-standard.war".POST_MODULE] 
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Fri Oct 18 13:18:02 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Fri, 18 Oct 2013 13:18:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2027) EE Default DataSource is not
	working
In-Reply-To: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500313.1378739268000.5944.1382116682296@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823262#comment-12823262 ] 

Scott Marlow commented on WFLY-2027:
------------------------------------

workaround: in standalone/configuration/standalone.xml, look for jpa default-datasource="" and add a default ds...
                
> EE Default DataSource is not working
> ------------------------------------
>
>                 Key: WFLY-2027
>                 URL: https://issues.jboss.org/browse/WFLY-2027
>             Project: WildFly
>          Issue Type: Bug
>          Components: ConfigAdmin, Domain Management, EE, JCA, JPA / Hibernate, Web Console
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Lincoln Baxter III
>            Assignee: Eduardo Martins
>             Fix For: 8.0.0.Beta1
>
>
> The EE spec states that a default datasource must be supplied under: java:comp/DefaultDataSource, and if none is specified by the @Resource or persistence.xml, it must be assumed:
>  {code}EE 5.19
> The Java EE Platform requires that a Java EE Product Provider provide a database 
> in the operational environment (see Section EE.2.6, ?Database?). The Java EE 
> Product Provider must also provide a preconfigured, default data source for use by 
> the application in accessing this database.
> The Java EE Product Provider must make the default data source accessible to 
> the application under the JNDI name java:comp/DefaultDataSource.
> The Application Component Provider or Deployer may explicitly bind a 
> DataSource resource reference to the default data source using the lookup element 
> of the Resource annotation or the lookup-name element of the resource-ref
> deployment descriptor element. For example,
> @Resource(lookup="java:comp/DefaultDataSource")
> DataSource myDS;
> In the absence of such a binding, the mapping of the reference will default to 
> the product's default data source.
> For example, the following will map to a preconfigured data source for the 
> product's default database:
> @Resource
> DataSource myDS;{code}
> This, isn't working however:
> {code}
> <persistence version="2.1" xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>    xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/persistence/persistence_2_1.xsd">
>    <persistence-unit name="default" transaction-type="JTA">
>    </persistence-unit>
> </persistence>{code}
> Results in: 
> {code}
> 10:41:31,002 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 50) MSC000001: Failed to start service jboss.persistenceunit."jpa-standard.war#default": org.jboss.msc.service.StartException in service jboss.persistenceunit."jpa-standard.war#default": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:134) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.determineDialect(DialectFactoryImpl.java:98)
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.buildDialect(DialectFactoryImpl.java:66)
> 	at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:193)
> 	at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:88)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:159)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131)
> 	at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration.java:1844)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1802)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:844)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835)
> 	at org.jboss.as.jpa.hibernate4.management.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:115) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	... 4 more
> 10:41:31,010 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"jpa-standard.war#default\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"jpa-standard.war#default\": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
>     Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set"}}
> {code}
> Additionally, actually specifying the expected JDNI name of the default DS like this:
> {code}   <persistence-unit name="default" transaction-type="JTA">
>       <jta-data-source>java:comp/DefaultDataSource</jta-data-source>
>       <exclude-unlisted-classes>false</exclude-unlisted-classes>
>    </persistence-unit>{code}
> Results in this:
> {code}
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.naming.context.java.module.jpa-standard.jpa-standard.DefaultDataSource (missing) dependents: [service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__] 
>       service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__ (missing) dependents: [service jboss.deployment.unit."jpa-standard.war".POST_MODULE] 
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Fri Oct 18 13:20:01 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Fri, 18 Oct 2013 13:20:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2272) component upgrade to
 Hibernate ORM 4.3.0.Beta6
In-Reply-To: <JIRA.12502612.1381348561000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502612.1381348561000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502612.1381348561000.5947.1382116801953@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow updated WFLY-2272:
-------------------------------

    Summary: component upgrade to Hibernate ORM 4.3.0.Beta6  (was: component upgrade to Hibernate ORM 4.3.0.Beta5)

    
> component upgrade to Hibernate ORM 4.3.0.Beta6
> ----------------------------------------------
>
>                 Key: WFLY-2272
>                 URL: https://issues.jboss.org/browse/WFLY-2272
>             Project: WildFly
>          Issue Type: Task
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 18 13:22:02 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Fri, 18 Oct 2013 13:22:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2027) EE Default DataSource is not
	working
In-Reply-To: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500313.1378739268000.5956.1382116922167@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823263#comment-12823263 ] 

Scott Marlow commented on WFLY-2027:
------------------------------------

Feedback is welcome on whether JPA is *required* to use the default datasource...  I read in this jira that it should be but why is it required?  WFLY-2212 is the jira for that work.
                
> EE Default DataSource is not working
> ------------------------------------
>
>                 Key: WFLY-2027
>                 URL: https://issues.jboss.org/browse/WFLY-2027
>             Project: WildFly
>          Issue Type: Bug
>          Components: ConfigAdmin, Domain Management, EE, JCA, JPA / Hibernate, Web Console
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Lincoln Baxter III
>            Assignee: Eduardo Martins
>             Fix For: 8.0.0.Beta1
>
>
> The EE spec states that a default datasource must be supplied under: java:comp/DefaultDataSource, and if none is specified by the @Resource or persistence.xml, it must be assumed:
>  {code}EE 5.19
> The Java EE Platform requires that a Java EE Product Provider provide a database 
> in the operational environment (see Section EE.2.6, ?Database?). The Java EE 
> Product Provider must also provide a preconfigured, default data source for use by 
> the application in accessing this database.
> The Java EE Product Provider must make the default data source accessible to 
> the application under the JNDI name java:comp/DefaultDataSource.
> The Application Component Provider or Deployer may explicitly bind a 
> DataSource resource reference to the default data source using the lookup element 
> of the Resource annotation or the lookup-name element of the resource-ref
> deployment descriptor element. For example,
> @Resource(lookup="java:comp/DefaultDataSource")
> DataSource myDS;
> In the absence of such a binding, the mapping of the reference will default to 
> the product's default data source.
> For example, the following will map to a preconfigured data source for the 
> product's default database:
> @Resource
> DataSource myDS;{code}
> This, isn't working however:
> {code}
> <persistence version="2.1" xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>    xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/persistence/persistence_2_1.xsd">
>    <persistence-unit name="default" transaction-type="JTA">
>    </persistence-unit>
> </persistence>{code}
> Results in: 
> {code}
> 10:41:31,002 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 50) MSC000001: Failed to start service jboss.persistenceunit."jpa-standard.war#default": org.jboss.msc.service.StartException in service jboss.persistenceunit."jpa-standard.war#default": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:134) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.determineDialect(DialectFactoryImpl.java:98)
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.buildDialect(DialectFactoryImpl.java:66)
> 	at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:193)
> 	at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:88)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:159)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131)
> 	at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration.java:1844)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1802)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:844)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835)
> 	at org.jboss.as.jpa.hibernate4.management.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:115) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	... 4 more
> 10:41:31,010 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"jpa-standard.war#default\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"jpa-standard.war#default\": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
>     Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set"}}
> {code}
> Additionally, actually specifying the expected JDNI name of the default DS like this:
> {code}   <persistence-unit name="default" transaction-type="JTA">
>       <jta-data-source>java:comp/DefaultDataSource</jta-data-source>
>       <exclude-unlisted-classes>false</exclude-unlisted-classes>
>    </persistence-unit>{code}
> Results in this:
> {code}
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.naming.context.java.module.jpa-standard.jpa-standard.DefaultDataSource (missing) dependents: [service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__] 
>       service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__ (missing) dependents: [service jboss.deployment.unit."jpa-standard.war".POST_MODULE] 
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Fri Oct 18 13:26:01 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 18 Oct 2013 13:26:01 -0400 (EDT)
Subject: [jboss-jira] =?utf-8?q?=5BJBoss_JIRA=5D_=28JBJCA-1101=29_Downgrad?=
 =?utf-8?q?e_logging_of_XAException=3A=3AXA=5FRB=E2=88=97_during_XAResourc?=
 =?utf-8?b?ZTo6ZW5kKFRNRkFJTCk=?=
In-Reply-To: <JIRA.12508104.1382025703000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508104.1382025703000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508104.1382025703000.5959.1382117161966@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated JBJCA-1101:
-----------------------------------

    Priority: Critical  (was: Major)

    
> Downgrade logging of XAException::XA_RB? during XAResource::end(TMFAIL)
> -----------------------------------------------------------------------
>
>                 Key: JBJCA-1101
>                 URL: https://issues.jboss.org/browse/JBJCA-1101
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: JDBC
>    Affects Versions: 1.0.21.Final, 1.1.0.Final
>            Reporter: Tom Jenkinson
>            Assignee: Jesper Pedersen
>            Priority: Critical
>             Fix For: 1.0.22.Final, 1.1.1.Final
>
>
> In org.jboss.jca.adapters.jdbc.xa.XAManagedConnection:
> {code}
> try
>          {
>             xaResource.end(xid, flags);
>          }
>          catch (XAException e)
>          {
>             broadcastConnectionError(e);
>             throw e;
>          }
> {code}
> If we pass in TMFAIL to this method, according to XA we would expect an XAException::XA_RB* to be returned so do not log this as a warning. You can see how we handle this in JBTM over here: 
> https://github.com/jbosstm/narayana/blob/540c689168fa2fd3db38d4ae1c3487c5d1ff7aff/ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/resources/arjunacore/XAResourceRecord.java#L317

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Fri Oct 18 13:55:02 2013
From: jira-events at lists.jboss.org (Farah Juma (JIRA))
Date: Fri, 18 Oct 2013 13:55:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2339) Error occurs when a
 deployment contains two WARs that each need a different JSF implementation
In-Reply-To: <JIRA.12508213.1382118852000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508213.1382118852000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508213.1382118852000.6052.1382118902242@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Farah Juma updated WFLY-2339:
-----------------------------

    Forum Reference: https://community.jboss.org/message/842316  (was: https://community.jboss.org/message/842316#842316)

    
> Error occurs when a deployment contains two WARs that each need a different JSF implementation
> ----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2339
>                 URL: https://issues.jboss.org/browse/WFLY-2339
>             Project: WildFly
>          Issue Type: Bug
>          Components: JSF
>            Reporter: Farah Juma
>            Assignee: Farah Juma
>            Priority: Minor
>
> A deployment that contains two WARs that each need a different JSF implementation fails to start. As described in the forum post, using jboss-deployment-structure.xml to add the correct dependencies to the two subdeployments doesn't currently work.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 18 13:55:01 2013
From: jira-events at lists.jboss.org (Farah Juma (JIRA))
Date: Fri, 18 Oct 2013 13:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2339) Error occurs when a
 deployment contains two WARs that each need a different JSF implementation
In-Reply-To: <JIRA.12508213.1382118852481@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508213.1382118852481@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508213.1382118852481.6050.1382118901938@jira02.app.mwc.hst.phx2.redhat.com>

Farah Juma created WFLY-2339:
--------------------------------

             Summary: Error occurs when a deployment contains two WARs that each need a different JSF implementation
                 Key: WFLY-2339
                 URL: https://issues.jboss.org/browse/WFLY-2339
             Project: WildFly
          Issue Type: Bug
          Components: JSF
            Reporter: Farah Juma
            Assignee: Farah Juma
            Priority: Minor


A deployment that contains two WARs that each need a different JSF implementation fails to start. As described in the forum post, using jboss-deployment-structure.xml to add the correct dependencies to the two subdeployments doesn't currently work.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 18 14:53:01 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Fri, 18 Oct 2013 14:53:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2340) Add default persistence unit
	properties
In-Reply-To: <JIRA.12508214.1382122371380@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508214.1382122371380@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508214.1382122371380.6122.1382122381943@jira02.app.mwc.hst.phx2.redhat.com>

Scott Marlow created WFLY-2340:
----------------------------------

             Summary: Add default persistence unit properties
                 Key: WFLY-2340
                 URL: https://issues.jboss.org/browse/WFLY-2340
             Project: WildFly
          Issue Type: Feature Request
          Components: JPA / Hibernate
            Reporter: Scott Marlow
            Assignee: Scott Marlow
             Fix For: 8.0.0.CR1


in a tck test, we need to set jpa.provider.implementation.specific.properties=true but don't want to make that a default.  Adding this feature will allow us to set default jpa properties (if the deployment doesn't already include those property settings).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 18 15:02:01 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Fri, 18 Oct 2013 15:02:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2340) Add default persistence unit
	properties
In-Reply-To: <JIRA.12508214.1382122371000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508214.1382122371000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508214.1382122371000.6125.1382122921950@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow updated WFLY-2340:
-------------------------------

         Assignee:     (was: Scott Marlow)
    Fix Version/s:     (was: 8.0.0.CR1)


I'm not fully convinced on this idea yet.
                
> Add default persistence unit properties
> ---------------------------------------
>
>                 Key: WFLY-2340
>                 URL: https://issues.jboss.org/browse/WFLY-2340
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>
> in a tck test, we need to set jpa.provider.implementation.specific.properties=true but don't want to make that a default.  Adding this feature will allow us to set default jpa properties (if the deployment doesn't already include those property settings).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 18 15:11:01 2013
From: jira-events at lists.jboss.org (Aaron Ogburn (JIRA))
Date: Fri, 18 Oct 2013 15:11:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2336) Decreasing max-threads on a
 unbounded queuesless executor generates IllegalArgumentException
In-Reply-To: <JIRA.12508206.1382111218000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508206.1382111218000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508206.1382111218000.6139.1382123461900@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aaron Ogburn updated WFLY-2336:
-------------------------------


    
> Decreasing max-threads on a unbounded queuesless executor generates IllegalArgumentException
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2336
>                 URL: https://issues.jboss.org/browse/WFLY-2336
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Aaron Ogburn
>            Priority: Minor
>
> Create an unbounded queueless executor
> <unbounded-queue-thread-pool name="uq-thread-pool">
> <max-threads count="350"/>
> <keepalive-time time="5" unit="minutes"/>
> </unbounded-queue-thread-pool>
> Modifying max-threads fails:
> /subsystem=threads/unbounded-queue-thread-pool=uq-thread-pool:write-attribute(name=max-threads,value=300)
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014749: Operation handler failed: null",
>     "rolled-back" => true
> }
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) JBAS014612: Operation ("write-attribute") failed - address: ([
>     ("subsystem" => "threads"),
>     ("unbounded-queue-thread-pool" => "uq-thread-pool")
> ]): java.lang.IllegalArgumentException
> 	at java.util.concurrent.ThreadPoolExecutor.setMaximumPoolSize(ThreadPoolExecutor.java:1620) [rt.jar:1.7.0]
> 	at org.jboss.threads.JBossThreadPoolExecutor.setMaxThreads(JBossThreadPoolExecutor.java:95) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> 	at org.jboss.as.threads.ManagedJBossThreadPoolExecutorService.setMaxThreads(ManagedJBossThreadPoolExecutorService.java:86)
> 	at org.jboss.as.threads.UnboundedQueueThreadPoolService.setMaxThreads(UnboundedQueueThreadPoolService.java:91)
> The core pool size needs to be adjusted in line with the max pool size and in the right order to avoid that since max threads can't be less than core threads.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 18 16:25:01 2013
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Fri, 18 Oct 2013 16:25:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1807) Logging Subsystem: Add 2.0.0
 to 1.2.0 transformers
In-Reply-To: <JIRA.12497786.1375372114000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497786.1375372114000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497786.1375372114000.6162.1382127901971@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins closed WFLY-1807.
-------------------------------

    Resolution: Duplicate Issue


Duplicate of https://issues.jboss.org/browse/WFLY-2238
                
> Logging Subsystem: Add 2.0.0 to 1.2.0 transformers
> --------------------------------------------------
>
>                 Key: WFLY-1807
>                 URL: https://issues.jboss.org/browse/WFLY-1807
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Blocker
>             Fix For: 8.0.0.CR1
>
>
> Need to add transformers for the 2.0.0 model to the logging subsystem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 18 16:42:02 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Fri, 18 Oct 2013 16:42:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2245) Transactions subsystem
 transformers for 7.2.0
In-Reply-To: <JIRA.12502331.1381146540000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502331.1381146540000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502331.1381146540000.6171.1382128922032@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan reassigned WFLY-2245:
--------------------------------

    Assignee: Kabir Khan  (was: jaikiran pai)

    
> Transactions subsystem transformers for 7.2.0
> ---------------------------------------------
>
>                 Key: WFLY-2245
>                 URL: https://issues.jboss.org/browse/WFLY-2245
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Transactions
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 18 17:53:02 2013
From: jira-events at lists.jboss.org (Lincoln Baxter III (JIRA))
Date: Fri, 18 Oct 2013 17:53:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2027) EE Default DataSource is not
	working
In-Reply-To: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500313.1378739268000.6196.1382133182192@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823296#comment-12823296 ] 

Lincoln Baxter III commented on WFLY-2027:
------------------------------------------

[~smarlow] This blog is why I believe that's the case:

https://blogs.oracle.com/arungupta/entry/default_datasource_in_java_ee
                
> EE Default DataSource is not working
> ------------------------------------
>
>                 Key: WFLY-2027
>                 URL: https://issues.jboss.org/browse/WFLY-2027
>             Project: WildFly
>          Issue Type: Bug
>          Components: ConfigAdmin, Domain Management, EE, JCA, JPA / Hibernate, Web Console
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Lincoln Baxter III
>            Assignee: Eduardo Martins
>             Fix For: 8.0.0.Beta1
>
>
> The EE spec states that a default datasource must be supplied under: java:comp/DefaultDataSource, and if none is specified by the @Resource or persistence.xml, it must be assumed:
>  {code}EE 5.19
> The Java EE Platform requires that a Java EE Product Provider provide a database 
> in the operational environment (see Section EE.2.6, ?Database?). The Java EE 
> Product Provider must also provide a preconfigured, default data source for use by 
> the application in accessing this database.
> The Java EE Product Provider must make the default data source accessible to 
> the application under the JNDI name java:comp/DefaultDataSource.
> The Application Component Provider or Deployer may explicitly bind a 
> DataSource resource reference to the default data source using the lookup element 
> of the Resource annotation or the lookup-name element of the resource-ref
> deployment descriptor element. For example,
> @Resource(lookup="java:comp/DefaultDataSource")
> DataSource myDS;
> In the absence of such a binding, the mapping of the reference will default to 
> the product's default data source.
> For example, the following will map to a preconfigured data source for the 
> product's default database:
> @Resource
> DataSource myDS;{code}
> This, isn't working however:
> {code}
> <persistence version="2.1" xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>    xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/persistence/persistence_2_1.xsd">
>    <persistence-unit name="default" transaction-type="JTA">
>    </persistence-unit>
> </persistence>{code}
> Results in: 
> {code}
> 10:41:31,002 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 50) MSC000001: Failed to start service jboss.persistenceunit."jpa-standard.war#default": org.jboss.msc.service.StartException in service jboss.persistenceunit."jpa-standard.war#default": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:134) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.determineDialect(DialectFactoryImpl.java:98)
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.buildDialect(DialectFactoryImpl.java:66)
> 	at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:193)
> 	at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:88)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:159)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131)
> 	at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration.java:1844)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1802)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:844)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835)
> 	at org.jboss.as.jpa.hibernate4.management.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:115) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	... 4 more
> 10:41:31,010 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"jpa-standard.war#default\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"jpa-standard.war#default\": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
>     Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set"}}
> {code}
> Additionally, actually specifying the expected JDNI name of the default DS like this:
> {code}   <persistence-unit name="default" transaction-type="JTA">
>       <jta-data-source>java:comp/DefaultDataSource</jta-data-source>
>       <exclude-unlisted-classes>false</exclude-unlisted-classes>
>    </persistence-unit>{code}
> Results in this:
> {code}
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.naming.context.java.module.jpa-standard.jpa-standard.DefaultDataSource (missing) dependents: [service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__] 
>       service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__ (missing) dependents: [service jboss.deployment.unit."jpa-standard.war".POST_MODULE] 
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Fri Oct 18 19:36:02 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Fri, 18 Oct 2013 19:36:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2027) EE Default DataSource is not
	working
In-Reply-To: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500313.1378739268000.6209.1382139362611@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823298#comment-12823298 ] 

Scott Marlow commented on WFLY-2027:
------------------------------------

I agree that is the spirit of what the blog conveys, however, it is ambiguous (IMO) how the blog describes what the container must do when it quotes the following part of the JPA 2.1 spec.  I shouldn't feel ambiguous but I do, since this JPA requirement is not tied to EE7 (it was also in the JPA 2.0 spec).  

It may also be that the EE 7 spec section quoted above was *intended* to also apply to JPA, however, I'm trying to separate wanting to do this change from what we are required by (EE/JPA) specification to do.  Which is why I asked the question about why. :)

I agree that changing JPA to use the EE default DataSource, would be useful.  However, others raised the concern that someone could easily forget to specify the datasource and find themselves (unexpectedly) using the wrong database.  Anyway, please vote for WFLY-2212 if you want to see it completed (more likely to be WF9 at this point).

{quote}
JPA 2.1 section 8.2.1.5 jta-data-source, non-jta-data-source

In Java EE environments, the jta-data-source and non-jta-data-source elements are used to specify the JNDI name of the JTA and/or non-JTA data source to be used by the persistence provider. If neither is specified, the deployer must specify a JTA data source at deployment or the default JTA data source must be provided by the container, and a JTA EntityManagerFactory will be created to correspond to it.

In Java SE environments, these elements may be used or the data source information may be specified
by other means?depending upon the requirements of the provider.
{quote}

Also, the WildFly configuration (e.g. wf/standalone/configuration/standalone.xml or whichever config your using) contains:
{quote}
 <subsystem xmlns="urn:jboss:domain:jpa:1.1">
     <jpa default-datasource="" default-extended-persistence-inheritance="DEEP"/>
</subsystem>
{quote}
The jpa default-datasource can be specified, which does what your asking for (with the limitation that it is blank out of the box).
                
> EE Default DataSource is not working
> ------------------------------------
>
>                 Key: WFLY-2027
>                 URL: https://issues.jboss.org/browse/WFLY-2027
>             Project: WildFly
>          Issue Type: Bug
>          Components: ConfigAdmin, Domain Management, EE, JCA, JPA / Hibernate, Web Console
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Lincoln Baxter III
>            Assignee: Eduardo Martins
>             Fix For: 8.0.0.Beta1
>
>
> The EE spec states that a default datasource must be supplied under: java:comp/DefaultDataSource, and if none is specified by the @Resource or persistence.xml, it must be assumed:
>  {code}EE 5.19
> The Java EE Platform requires that a Java EE Product Provider provide a database 
> in the operational environment (see Section EE.2.6, ?Database?). The Java EE 
> Product Provider must also provide a preconfigured, default data source for use by 
> the application in accessing this database.
> The Java EE Product Provider must make the default data source accessible to 
> the application under the JNDI name java:comp/DefaultDataSource.
> The Application Component Provider or Deployer may explicitly bind a 
> DataSource resource reference to the default data source using the lookup element 
> of the Resource annotation or the lookup-name element of the resource-ref
> deployment descriptor element. For example,
> @Resource(lookup="java:comp/DefaultDataSource")
> DataSource myDS;
> In the absence of such a binding, the mapping of the reference will default to 
> the product's default data source.
> For example, the following will map to a preconfigured data source for the 
> product's default database:
> @Resource
> DataSource myDS;{code}
> This, isn't working however:
> {code}
> <persistence version="2.1" xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>    xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/persistence/persistence_2_1.xsd">
>    <persistence-unit name="default" transaction-type="JTA">
>    </persistence-unit>
> </persistence>{code}
> Results in: 
> {code}
> 10:41:31,002 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 50) MSC000001: Failed to start service jboss.persistenceunit."jpa-standard.war#default": org.jboss.msc.service.StartException in service jboss.persistenceunit."jpa-standard.war#default": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:134) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.determineDialect(DialectFactoryImpl.java:98)
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.buildDialect(DialectFactoryImpl.java:66)
> 	at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:193)
> 	at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:88)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:159)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131)
> 	at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration.java:1844)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1802)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:844)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835)
> 	at org.jboss.as.jpa.hibernate4.management.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:115) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	... 4 more
> 10:41:31,010 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"jpa-standard.war#default\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"jpa-standard.war#default\": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
>     Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set"}}
> {code}
> Additionally, actually specifying the expected JDNI name of the default DS like this:
> {code}   <persistence-unit name="default" transaction-type="JTA">
>       <jta-data-source>java:comp/DefaultDataSource</jta-data-source>
>       <exclude-unlisted-classes>false</exclude-unlisted-classes>
>    </persistence-unit>{code}
> Results in this:
> {code}
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.naming.context.java.module.jpa-standard.jpa-standard.DefaultDataSource (missing) dependents: [service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__] 
>       service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__ (missing) dependents: [service jboss.deployment.unit."jpa-standard.war".POST_MODULE] 
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Fri Oct 18 20:39:02 2013
From: jira-events at lists.jboss.org (Eduardo Martins (JIRA))
Date: Fri, 18 Oct 2013 20:39:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2027) EE Default DataSource is not
	working
In-Reply-To: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500313.1378739268000.6232.1382143142557@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823299#comment-12823299 ] 

Eduardo Martins commented on WFLY-2027:
---------------------------------------

Is that blog post some kind of spec definition? I sincerely don't get the meaning of using a java:comp jndi name in a PU xml descriptor, which EE component namespace should it refer to, since PU doesn't have one? The spec reference above from Scott clearly defines what xml should be provided to delegate the data source choice to the container...
                
> EE Default DataSource is not working
> ------------------------------------
>
>                 Key: WFLY-2027
>                 URL: https://issues.jboss.org/browse/WFLY-2027
>             Project: WildFly
>          Issue Type: Bug
>          Components: ConfigAdmin, Domain Management, EE, JCA, JPA / Hibernate, Web Console
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Lincoln Baxter III
>            Assignee: Eduardo Martins
>             Fix For: 8.0.0.Beta1
>
>
> The EE spec states that a default datasource must be supplied under: java:comp/DefaultDataSource, and if none is specified by the @Resource or persistence.xml, it must be assumed:
>  {code}EE 5.19
> The Java EE Platform requires that a Java EE Product Provider provide a database 
> in the operational environment (see Section EE.2.6, ?Database?). The Java EE 
> Product Provider must also provide a preconfigured, default data source for use by 
> the application in accessing this database.
> The Java EE Product Provider must make the default data source accessible to 
> the application under the JNDI name java:comp/DefaultDataSource.
> The Application Component Provider or Deployer may explicitly bind a 
> DataSource resource reference to the default data source using the lookup element 
> of the Resource annotation or the lookup-name element of the resource-ref
> deployment descriptor element. For example,
> @Resource(lookup="java:comp/DefaultDataSource")
> DataSource myDS;
> In the absence of such a binding, the mapping of the reference will default to 
> the product's default data source.
> For example, the following will map to a preconfigured data source for the 
> product's default database:
> @Resource
> DataSource myDS;{code}
> This, isn't working however:
> {code}
> <persistence version="2.1" xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>    xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/persistence/persistence_2_1.xsd">
>    <persistence-unit name="default" transaction-type="JTA">
>    </persistence-unit>
> </persistence>{code}
> Results in: 
> {code}
> 10:41:31,002 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 50) MSC000001: Failed to start service jboss.persistenceunit."jpa-standard.war#default": org.jboss.msc.service.StartException in service jboss.persistenceunit."jpa-standard.war#default": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:134) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.determineDialect(DialectFactoryImpl.java:98)
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.buildDialect(DialectFactoryImpl.java:66)
> 	at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:193)
> 	at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:88)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:159)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131)
> 	at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration.java:1844)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1802)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:844)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835)
> 	at org.jboss.as.jpa.hibernate4.management.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:115) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	... 4 more
> 10:41:31,010 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"jpa-standard.war#default\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"jpa-standard.war#default\": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
>     Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set"}}
> {code}
> Additionally, actually specifying the expected JDNI name of the default DS like this:
> {code}   <persistence-unit name="default" transaction-type="JTA">
>       <jta-data-source>java:comp/DefaultDataSource</jta-data-source>
>       <exclude-unlisted-classes>false</exclude-unlisted-classes>
>    </persistence-unit>{code}
> Results in this:
> {code}
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.naming.context.java.module.jpa-standard.jpa-standard.DefaultDataSource (missing) dependents: [service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__] 
>       service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__ (missing) dependents: [service jboss.deployment.unit."jpa-standard.war".POST_MODULE] 
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Fri Oct 18 22:12:02 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Fri, 18 Oct 2013 22:12:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2027) EE Default DataSource is not
	working
In-Reply-To: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500313.1378739268000.6259.1382148722828@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823301#comment-12823301 ] 

Scott Marlow commented on WFLY-2027:
------------------------------------

I agree with [~emmartins] about java:comp/DefaultDataSource in the persistence.xml.  The persistence unit can be referenced from EE components (e.g. via an @PersistenceUnit or @PersistenceContext or JNDI lookup) but isn't part of a component.

I'm not completely sure how WFLY-2212 would need to be implemented but it might be as simple as changing the WildFly configuration to:
{quote}
<subsystem xmlns="urn:jboss:domain:jpa:1.1">
<jpa default-datasource="java:jboss/datasources/ExampleDS" default-extended-persistence-inheritance="DEEP"/>
</subsystem>
{quote}

Another WFLY-2212 implementation detail is that we would need a persistence unit hint to ignore the default datasource (OGM will not deploy with a datasource specified).  Something like "wildfly.jpa.ignoredefaultdatasource".
{code}
<?xml version="1.0" encoding="UTF-8"?>
<persistence xmlns="http://java.sun.com/xml/ns/persistence" version="1.0">
    <persistence-unit name="OGMTEST_PU">
    <provider>org.hibernate.ogm.jpa.HibernateOgmPersistence</provider>
    <properties>
         <property name="wildfly.jpa.ignoredefaultdatasource" value="true" />      
    </properties>
  </persistence-unit>
</persistence>
{code}


                
> EE Default DataSource is not working
> ------------------------------------
>
>                 Key: WFLY-2027
>                 URL: https://issues.jboss.org/browse/WFLY-2027
>             Project: WildFly
>          Issue Type: Bug
>          Components: ConfigAdmin, Domain Management, EE, JCA, JPA / Hibernate, Web Console
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Lincoln Baxter III
>            Assignee: Eduardo Martins
>             Fix For: 8.0.0.Beta1
>
>
> The EE spec states that a default datasource must be supplied under: java:comp/DefaultDataSource, and if none is specified by the @Resource or persistence.xml, it must be assumed:
>  {code}EE 5.19
> The Java EE Platform requires that a Java EE Product Provider provide a database 
> in the operational environment (see Section EE.2.6, ?Database?). The Java EE 
> Product Provider must also provide a preconfigured, default data source for use by 
> the application in accessing this database.
> The Java EE Product Provider must make the default data source accessible to 
> the application under the JNDI name java:comp/DefaultDataSource.
> The Application Component Provider or Deployer may explicitly bind a 
> DataSource resource reference to the default data source using the lookup element 
> of the Resource annotation or the lookup-name element of the resource-ref
> deployment descriptor element. For example,
> @Resource(lookup="java:comp/DefaultDataSource")
> DataSource myDS;
> In the absence of such a binding, the mapping of the reference will default to 
> the product's default data source.
> For example, the following will map to a preconfigured data source for the 
> product's default database:
> @Resource
> DataSource myDS;{code}
> This, isn't working however:
> {code}
> <persistence version="2.1" xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>    xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/persistence/persistence_2_1.xsd">
>    <persistence-unit name="default" transaction-type="JTA">
>    </persistence-unit>
> </persistence>{code}
> Results in: 
> {code}
> 10:41:31,002 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 50) MSC000001: Failed to start service jboss.persistenceunit."jpa-standard.war#default": org.jboss.msc.service.StartException in service jboss.persistenceunit."jpa-standard.war#default": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:134) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.determineDialect(DialectFactoryImpl.java:98)
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.buildDialect(DialectFactoryImpl.java:66)
> 	at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:193)
> 	at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:88)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:159)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131)
> 	at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration.java:1844)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1802)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:844)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835)
> 	at org.jboss.as.jpa.hibernate4.management.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:115) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	... 4 more
> 10:41:31,010 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"jpa-standard.war#default\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"jpa-standard.war#default\": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
>     Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set"}}
> {code}
> Additionally, actually specifying the expected JDNI name of the default DS like this:
> {code}   <persistence-unit name="default" transaction-type="JTA">
>       <jta-data-source>java:comp/DefaultDataSource</jta-data-source>
>       <exclude-unlisted-classes>false</exclude-unlisted-classes>
>    </persistence-unit>{code}
> Results in this:
> {code}
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.naming.context.java.module.jpa-standard.jpa-standard.DefaultDataSource (missing) dependents: [service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__] 
>       service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__ (missing) dependents: [service jboss.deployment.unit."jpa-standard.war".POST_MODULE] 
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Fri Oct 18 22:12:03 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Fri, 18 Oct 2013 22:12:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2027) EE Default DataSource is not
	working
In-Reply-To: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500313.1378739268000.6262.1382148723077@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823301#comment-12823301 ] 

Scott Marlow edited comment on WFLY-2027 at 10/18/13 10:11 PM:
---------------------------------------------------------------

I agree with [~emmartins] about java:comp/DefaultDataSource in the persistence.xml.  The persistence unit can be referenced from EE components (e.g. via an @PersistenceUnit or @PersistenceContext or JNDI lookup or injection) but isn't part of a component.

I'm not completely sure how WFLY-2212 would need to be implemented but it might be as simple as changing the WildFly configuration to:
{quote}
<subsystem xmlns="urn:jboss:domain:jpa:1.1">
<jpa default-datasource="java:jboss/datasources/ExampleDS" default-extended-persistence-inheritance="DEEP"/>
</subsystem>
{quote}

Another WFLY-2212 implementation detail is that we would need a persistence unit hint to ignore the default datasource (OGM will not deploy with a datasource specified).  Something like "wildfly.jpa.ignoredefaultdatasource".
{code}
<?xml version="1.0" encoding="UTF-8"?>
<persistence xmlns="http://java.sun.com/xml/ns/persistence" version="1.0">
    <persistence-unit name="OGMTEST_PU">
    <provider>org.hibernate.ogm.jpa.HibernateOgmPersistence</provider>
    <properties>
         <property name="wildfly.jpa.ignoredefaultdatasource" value="true" />      
    </properties>
  </persistence-unit>
</persistence>
{code}


                
      was (Author: smarlow):
    I agree with [~emmartins] about java:comp/DefaultDataSource in the persistence.xml.  The persistence unit can be referenced from EE components (e.g. via an @PersistenceUnit or @PersistenceContext or JNDI lookup) but isn't part of a component.

I'm not completely sure how WFLY-2212 would need to be implemented but it might be as simple as changing the WildFly configuration to:
{quote}
<subsystem xmlns="urn:jboss:domain:jpa:1.1">
<jpa default-datasource="java:jboss/datasources/ExampleDS" default-extended-persistence-inheritance="DEEP"/>
</subsystem>
{quote}

Another WFLY-2212 implementation detail is that we would need a persistence unit hint to ignore the default datasource (OGM will not deploy with a datasource specified).  Something like "wildfly.jpa.ignoredefaultdatasource".
{code}
<?xml version="1.0" encoding="UTF-8"?>
<persistence xmlns="http://java.sun.com/xml/ns/persistence" version="1.0">
    <persistence-unit name="OGMTEST_PU">
    <provider>org.hibernate.ogm.jpa.HibernateOgmPersistence</provider>
    <properties>
         <property name="wildfly.jpa.ignoredefaultdatasource" value="true" />      
    </properties>
  </persistence-unit>
</persistence>
{code}


                  
> EE Default DataSource is not working
> ------------------------------------
>
>                 Key: WFLY-2027
>                 URL: https://issues.jboss.org/browse/WFLY-2027
>             Project: WildFly
>          Issue Type: Bug
>          Components: ConfigAdmin, Domain Management, EE, JCA, JPA / Hibernate, Web Console
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Lincoln Baxter III
>            Assignee: Eduardo Martins
>             Fix For: 8.0.0.Beta1
>
>
> The EE spec states that a default datasource must be supplied under: java:comp/DefaultDataSource, and if none is specified by the @Resource or persistence.xml, it must be assumed:
>  {code}EE 5.19
> The Java EE Platform requires that a Java EE Product Provider provide a database 
> in the operational environment (see Section EE.2.6, ?Database?). The Java EE 
> Product Provider must also provide a preconfigured, default data source for use by 
> the application in accessing this database.
> The Java EE Product Provider must make the default data source accessible to 
> the application under the JNDI name java:comp/DefaultDataSource.
> The Application Component Provider or Deployer may explicitly bind a 
> DataSource resource reference to the default data source using the lookup element 
> of the Resource annotation or the lookup-name element of the resource-ref
> deployment descriptor element. For example,
> @Resource(lookup="java:comp/DefaultDataSource")
> DataSource myDS;
> In the absence of such a binding, the mapping of the reference will default to 
> the product's default data source.
> For example, the following will map to a preconfigured data source for the 
> product's default database:
> @Resource
> DataSource myDS;{code}
> This, isn't working however:
> {code}
> <persistence version="2.1" xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>    xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/persistence/persistence_2_1.xsd">
>    <persistence-unit name="default" transaction-type="JTA">
>    </persistence-unit>
> </persistence>{code}
> Results in: 
> {code}
> 10:41:31,002 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 50) MSC000001: Failed to start service jboss.persistenceunit."jpa-standard.war#default": org.jboss.msc.service.StartException in service jboss.persistenceunit."jpa-standard.war#default": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:134) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.determineDialect(DialectFactoryImpl.java:98)
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.buildDialect(DialectFactoryImpl.java:66)
> 	at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:193)
> 	at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:88)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:159)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131)
> 	at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration.java:1844)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1802)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:844)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835)
> 	at org.jboss.as.jpa.hibernate4.management.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:115) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	... 4 more
> 10:41:31,010 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"jpa-standard.war#default\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"jpa-standard.war#default\": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
>     Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set"}}
> {code}
> Additionally, actually specifying the expected JDNI name of the default DS like this:
> {code}   <persistence-unit name="default" transaction-type="JTA">
>       <jta-data-source>java:comp/DefaultDataSource</jta-data-source>
>       <exclude-unlisted-classes>false</exclude-unlisted-classes>
>    </persistence-unit>{code}
> Results in this:
> {code}
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.naming.context.java.module.jpa-standard.jpa-standard.DefaultDataSource (missing) dependents: [service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__] 
>       service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__ (missing) dependents: [service jboss.deployment.unit."jpa-standard.war".POST_MODULE] 
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Fri Oct 18 22:21:01 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Fri, 18 Oct 2013 22:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2212) Update JPA subsystem to use
 default datasource
In-Reply-To: <JIRA.12502126.1380810972000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502126.1380810972000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502126.1380810972000.6271.1382149261932@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow updated WFLY-2212:
-------------------------------

        Summary: Update JPA subsystem to use default datasource  (was: Update JPA subsystem to use default EE datasource binding)
    Description: See comments in WFLY-2027 before starting the work on this jira...  (was: JPA subsystem should check if a default EE datasource binding is available to use and default to that if a persistence unit doesn't specify a datasource.

Also add a persistence unit hint to not use a default datasource (might be helpful for OGM which fails the deployment if a datasource is specified).

)

    
> Update JPA subsystem to use default datasource
> ----------------------------------------------
>
>                 Key: WFLY-2212
>                 URL: https://issues.jboss.org/browse/WFLY-2212
>             Project: WildFly
>          Issue Type: Task
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 8.0.0.CR1
>
>
> See comments in WFLY-2027 before starting the work on this jira...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 19 01:31:01 2013
From: jira-events at lists.jboss.org (Eduardo Martins (JIRA))
Date: Sat, 19 Oct 2013 01:31:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2212) Update JPA subsystem to use
 default datasource
In-Reply-To: <JIRA.12502126.1380810972000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502126.1380810972000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502126.1380810972000.6292.1382160661959@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823305#comment-12823305 ] 

Eduardo Martins commented on WFLY-2212:
---------------------------------------

Dunno about the OGM issue, but here is a branch that uses EE default datasource if neither the PU and JPA subsystem defines one:

https://github.com/emmartins/wildfly/compare/WFLY-2212
                
> Update JPA subsystem to use default datasource
> ----------------------------------------------
>
>                 Key: WFLY-2212
>                 URL: https://issues.jboss.org/browse/WFLY-2212
>             Project: WildFly
>          Issue Type: Task
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 8.0.0.CR1
>
>
> See comments in WFLY-2027 before starting the work on this jira...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 19 01:37:01 2013
From: jira-events at lists.jboss.org (Eduardo Martins (JIRA))
Date: Sat, 19 Oct 2013 01:37:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2027) EE Default DataSource is not
	working
In-Reply-To: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500313.1378739268000.6296.1382161021919@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823306#comment-12823306 ] 

Eduardo Martins commented on WFLY-2027:
---------------------------------------

WFLY-2212 updated.

[~agoncal] [~lincolnthree] Can I close this issue again?
                
> EE Default DataSource is not working
> ------------------------------------
>
>                 Key: WFLY-2027
>                 URL: https://issues.jboss.org/browse/WFLY-2027
>             Project: WildFly
>          Issue Type: Bug
>          Components: ConfigAdmin, Domain Management, EE, JCA, JPA / Hibernate, Web Console
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Lincoln Baxter III
>            Assignee: Eduardo Martins
>             Fix For: 8.0.0.Beta1
>
>
> The EE spec states that a default datasource must be supplied under: java:comp/DefaultDataSource, and if none is specified by the @Resource or persistence.xml, it must be assumed:
>  {code}EE 5.19
> The Java EE Platform requires that a Java EE Product Provider provide a database 
> in the operational environment (see Section EE.2.6, ?Database?). The Java EE 
> Product Provider must also provide a preconfigured, default data source for use by 
> the application in accessing this database.
> The Java EE Product Provider must make the default data source accessible to 
> the application under the JNDI name java:comp/DefaultDataSource.
> The Application Component Provider or Deployer may explicitly bind a 
> DataSource resource reference to the default data source using the lookup element 
> of the Resource annotation or the lookup-name element of the resource-ref
> deployment descriptor element. For example,
> @Resource(lookup="java:comp/DefaultDataSource")
> DataSource myDS;
> In the absence of such a binding, the mapping of the reference will default to 
> the product's default data source.
> For example, the following will map to a preconfigured data source for the 
> product's default database:
> @Resource
> DataSource myDS;{code}
> This, isn't working however:
> {code}
> <persistence version="2.1" xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>    xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/persistence/persistence_2_1.xsd">
>    <persistence-unit name="default" transaction-type="JTA">
>    </persistence-unit>
> </persistence>{code}
> Results in: 
> {code}
> 10:41:31,002 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 50) MSC000001: Failed to start service jboss.persistenceunit."jpa-standard.war#default": org.jboss.msc.service.StartException in service jboss.persistenceunit."jpa-standard.war#default": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:134) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.determineDialect(DialectFactoryImpl.java:98)
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.buildDialect(DialectFactoryImpl.java:66)
> 	at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:193)
> 	at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:88)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:159)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131)
> 	at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration.java:1844)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1802)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:844)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835)
> 	at org.jboss.as.jpa.hibernate4.management.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:115) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	... 4 more
> 10:41:31,010 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"jpa-standard.war#default\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"jpa-standard.war#default\": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
>     Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set"}}
> {code}
> Additionally, actually specifying the expected JDNI name of the default DS like this:
> {code}   <persistence-unit name="default" transaction-type="JTA">
>       <jta-data-source>java:comp/DefaultDataSource</jta-data-source>
>       <exclude-unlisted-classes>false</exclude-unlisted-classes>
>    </persistence-unit>{code}
> Results in this:
> {code}
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.naming.context.java.module.jpa-standard.jpa-standard.DefaultDataSource (missing) dependents: [service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__] 
>       service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__ (missing) dependents: [service jboss.deployment.unit."jpa-standard.war".POST_MODULE] 
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Sat Oct 19 01:42:02 2013
From: jira-events at lists.jboss.org (Eduardo Martins (JIRA))
Date: Sat, 19 Oct 2013 01:42:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2319) LDAP Search containing URL -
 InvalidNameException: ldap:: [LDAP: error code 34 - Invalid root Dn given
In-Reply-To: <JIRA.12503254.1381931058000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503254.1381931058000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503254.1381931058000.6306.1382161322059@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Eduardo Martins reassigned WFLY-2319:
-------------------------------------

    Assignee: Eduardo Martins  (was: Darran Lofthouse)

    
> LDAP Search containing URL - InvalidNameException: ldap:: [LDAP: error code 34 - Invalid root Dn given
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2319
>                 URL: https://issues.jboss.org/browse/WFLY-2319
>             Project: WildFly
>          Issue Type: Bug
>          Components: Naming
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Darran Lofthouse
>            Assignee: Eduardo Martins
>             Fix For: 8.0.0.CR1
>
>
> The following code: -
> {code}
>         Hashtable env = new Hashtable();
>         env.put("java.naming.factory.initial", "com.sun.jndi.ldap.LdapCtxFactory");
>         env.put("java.naming.security.authentication", "simple");
>         env.put("java.naming.provider.url", "ldap://localhost:10389");
>         env.put(InitialDirContext.SECURITY_PRINCIPAL, "uid=admin,ou=system");
>         env.put(InitialDirContext.SECURITY_CREDENTIALS, "secret");
>         SearchControls ctl = null;
>         String attrArr[] = new String[1];
>         attrArr[0] = "sn";
>         ctl = new SearchControls(2, 0L, 0, attrArr, false, false);
>         String base = "ldap://localhost:10389/dc=simple,dc=wildfly,dc=org";
>         String filter = "(uid=UserOne)";
>         NamingEnumeration nenum = null;
>         DirContext ictx = null;
>             ictx = new InitialDirContext(env);
>             nenum = ictx.search(base, filter, ctl);
> {code}
> Results in the following exception: -
> {noquote}
> 13:03:45,598 ERROR [stderr] (default task-1) javax.naming.InvalidNameException: ldap:: [LDAP: error code 34 - Invalid root Dn given : ldap: (0x6C 0x64 0x61 0x70 0x3A ) is invalid]; remaining name 'ldap://localhost:10389/dc=simple,dc=wildfly,dc=org'
> 13:03:45,599 ERROR [stderr] (default task-1) 	at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3025)
> 13:03:45,600 ERROR [stderr] (default task-1) 	at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2840)
> 13:03:45,600 ERROR [stderr] (default task-1) 	at com.sun.jndi.ldap.LdapCtx.c_lookup(LdapCtx.java:1034)
> {noquote}
> Switching to a base that does not begin with a URL and the search works, executing this code outside of WildFly also works.
> The underlying issue is that the default InitialContext implementation contains the following method: -
> {code}
>     protected Context getURLOrDefaultInitCtx(String name)
>         throws NamingException {
>         if (NamingManager.hasInitialContextFactoryBuilder()) {
>             return getDefaultInitCtx();
>         }
>         String scheme = getURLScheme(name);
>         if (scheme != null) {
>             Context ctx = NamingManager.getURLContext(scheme, myProps);
>             if (ctx != null) {
>                 return ctx;
>             }
>         }
>         return getDefaultInitCtx();
>     }
> {code}
> As the naming subsystem has registered a InitialContextFactoryBuilder this code will never fall down to the scheme specific section.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 19 02:20:03 2013
From: jira-events at lists.jboss.org (Lincoln Baxter III (JIRA))
Date: Sat, 19 Oct 2013 02:20:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2027) EE Default DataSource is not
	working
In-Reply-To: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500313.1378739268000.6314.1382163603597@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823307#comment-12823307 ] 

Lincoln Baxter III commented on WFLY-2027:
------------------------------------------

Actually, I don't know if this was the case in JPA2.0, but notice that omitting any data-source results in a schema valid persistence.xml. If one of jta-data-source or non-jta-data-source were required, then I think the schema should show that, right?

If you still disagree, go ahead and close this :)
                
> EE Default DataSource is not working
> ------------------------------------
>
>                 Key: WFLY-2027
>                 URL: https://issues.jboss.org/browse/WFLY-2027
>             Project: WildFly
>          Issue Type: Bug
>          Components: ConfigAdmin, Domain Management, EE, JCA, JPA / Hibernate, Web Console
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Lincoln Baxter III
>            Assignee: Eduardo Martins
>             Fix For: 8.0.0.Beta1
>
>
> The EE spec states that a default datasource must be supplied under: java:comp/DefaultDataSource, and if none is specified by the @Resource or persistence.xml, it must be assumed:
>  {code}EE 5.19
> The Java EE Platform requires that a Java EE Product Provider provide a database 
> in the operational environment (see Section EE.2.6, ?Database?). The Java EE 
> Product Provider must also provide a preconfigured, default data source for use by 
> the application in accessing this database.
> The Java EE Product Provider must make the default data source accessible to 
> the application under the JNDI name java:comp/DefaultDataSource.
> The Application Component Provider or Deployer may explicitly bind a 
> DataSource resource reference to the default data source using the lookup element 
> of the Resource annotation or the lookup-name element of the resource-ref
> deployment descriptor element. For example,
> @Resource(lookup="java:comp/DefaultDataSource")
> DataSource myDS;
> In the absence of such a binding, the mapping of the reference will default to 
> the product's default data source.
> For example, the following will map to a preconfigured data source for the 
> product's default database:
> @Resource
> DataSource myDS;{code}
> This, isn't working however:
> {code}
> <persistence version="2.1" xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>    xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/persistence/persistence_2_1.xsd">
>    <persistence-unit name="default" transaction-type="JTA">
>    </persistence-unit>
> </persistence>{code}
> Results in: 
> {code}
> 10:41:31,002 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 50) MSC000001: Failed to start service jboss.persistenceunit."jpa-standard.war#default": org.jboss.msc.service.StartException in service jboss.persistenceunit."jpa-standard.war#default": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:134) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.determineDialect(DialectFactoryImpl.java:98)
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.buildDialect(DialectFactoryImpl.java:66)
> 	at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:193)
> 	at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:88)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:159)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131)
> 	at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration.java:1844)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1802)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:844)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835)
> 	at org.jboss.as.jpa.hibernate4.management.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:115) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	... 4 more
> 10:41:31,010 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"jpa-standard.war#default\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"jpa-standard.war#default\": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
>     Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set"}}
> {code}
> Additionally, actually specifying the expected JDNI name of the default DS like this:
> {code}   <persistence-unit name="default" transaction-type="JTA">
>       <jta-data-source>java:comp/DefaultDataSource</jta-data-source>
>       <exclude-unlisted-classes>false</exclude-unlisted-classes>
>    </persistence-unit>{code}
> Results in this:
> {code}
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.naming.context.java.module.jpa-standard.jpa-standard.DefaultDataSource (missing) dependents: [service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__] 
>       service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__ (missing) dependents: [service jboss.deployment.unit."jpa-standard.war".POST_MODULE] 
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Sat Oct 19 02:20:03 2013
From: jira-events at lists.jboss.org (Lincoln Baxter III (JIRA))
Date: Sat, 19 Oct 2013 02:20:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2212) Update JPA subsystem to use
 default datasource
In-Reply-To: <JIRA.12502126.1380810972000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502126.1380810972000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502126.1380810972000.6316.1382163603710@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823308#comment-12823308 ] 

Lincoln Baxter III commented on WFLY-2212:
------------------------------------------

Actually, I don't know if this was the case in JPA2.0, but notice that omitting any data-source results in a schema valid persistence.xml. If one of jta-data-source or non-jta-data-source were required, then I think the schema should show that, right?
                
> Update JPA subsystem to use default datasource
> ----------------------------------------------
>
>                 Key: WFLY-2212
>                 URL: https://issues.jboss.org/browse/WFLY-2212
>             Project: WildFly
>          Issue Type: Task
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 8.0.0.CR1
>
>
> See comments in WFLY-2027 before starting the work on this jira...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 19 03:17:01 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Sat, 19 Oct 2013 03:17:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2336) Decreasing max-threads on a
 unbounded queuesless executor generates IllegalArgumentException
In-Reply-To: <JIRA.12508206.1382111218000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508206.1382111218000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508206.1382111218000.6323.1382167021925@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2336:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1021077

    
> Decreasing max-threads on a unbounded queuesless executor generates IllegalArgumentException
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2336
>                 URL: https://issues.jboss.org/browse/WFLY-2336
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Aaron Ogburn
>            Priority: Minor
>
> Create an unbounded queueless executor
> <unbounded-queue-thread-pool name="uq-thread-pool">
> <max-threads count="350"/>
> <keepalive-time time="5" unit="minutes"/>
> </unbounded-queue-thread-pool>
> Modifying max-threads fails:
> /subsystem=threads/unbounded-queue-thread-pool=uq-thread-pool:write-attribute(name=max-threads,value=300)
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014749: Operation handler failed: null",
>     "rolled-back" => true
> }
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) JBAS014612: Operation ("write-attribute") failed - address: ([
>     ("subsystem" => "threads"),
>     ("unbounded-queue-thread-pool" => "uq-thread-pool")
> ]): java.lang.IllegalArgumentException
> 	at java.util.concurrent.ThreadPoolExecutor.setMaximumPoolSize(ThreadPoolExecutor.java:1620) [rt.jar:1.7.0]
> 	at org.jboss.threads.JBossThreadPoolExecutor.setMaxThreads(JBossThreadPoolExecutor.java:95) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> 	at org.jboss.as.threads.ManagedJBossThreadPoolExecutorService.setMaxThreads(ManagedJBossThreadPoolExecutorService.java:86)
> 	at org.jboss.as.threads.UnboundedQueueThreadPoolService.setMaxThreads(UnboundedQueueThreadPoolService.java:91)
> The core pool size needs to be adjusted in line with the max pool size and in the right order to avoid that since max threads can't be less than core threads.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 19 04:44:02 2013
From: jira-events at lists.jboss.org (Tom Jenkinson (JIRA))
Date: Sat, 19 Oct 2013 04:44:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2338) When using a JDBC object
 store,
 the RecoveryManager service stop can occur after the datasource is already
 stopped
In-Reply-To: <JIRA.12508208.1382112933000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508208.1382112933000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508208.1382112933000.6326.1382172242062@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson updated WFLY-2338:
--------------------------------

    Attachment: 0001-patching-servicename-for-ds-dependency.patch

    
> When using a JDBC object store, the RecoveryManager service stop can occur after the datasource is already stopped
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2338
>                 URL: https://issues.jboss.org/browse/WFLY-2338
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>            Reporter: Tom Jenkinson
>            Assignee: Stefano Maestri
>         Attachments: 0001-patching-servicename-for-ds-dependency.patch
>
>
> It should be the cause of https://bugzilla.redhat.com/show_bug.cgi?id=1020881
> It has the effects described in the BZ, i.e. can cause warnings or can entirely block the application server from stopping

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 19 04:52:02 2013
From: jira-events at lists.jboss.org (Antonio Goncalves (JIRA))
Date: Sat, 19 Oct 2013 04:52:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2027) EE Default DataSource is not
	working
In-Reply-To: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500313.1378739268000.6334.1382172722611@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823310#comment-12823310 ] 

Antonio Goncalves commented on WFLY-2027:
-----------------------------------------

This requirement is not in the JPA spec actually, but in the Java EE 7. It states :

{quote}
EE.5.19 - Default Data Source

The Java EE Platform requires that a Java EE Product Provider provide a database in the operational environment (see Section EE.2.6, ?Database?). The Java EE Product Provider must also provide a preconfigured, default data source for use by the application in accessing this database.

The Java EE Product Provider must make the default data source accessible to the application under the JNDI name {{java:comp/DefaultDataSource}}.

The Application Component Provider or Deployer may explicitly bind a DataSource resource reference to the default data source using the lookup element of the Resource annotation or the lookup-name element of the resource-ref deployment descriptor element. For example,
{code}
@Resource(lookup="java:comp/DefaultDataSource")
DataSource myDS;
{code}
In the absence of such a binding, the mapping of the reference will default to the product's default data source.
For example, the following will map to a preconfigured data source for the product's default database:
{code}
@Resource
DataSource myDS;
{code}
{quote}
                
> EE Default DataSource is not working
> ------------------------------------
>
>                 Key: WFLY-2027
>                 URL: https://issues.jboss.org/browse/WFLY-2027
>             Project: WildFly
>          Issue Type: Bug
>          Components: ConfigAdmin, Domain Management, EE, JCA, JPA / Hibernate, Web Console
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Lincoln Baxter III
>            Assignee: Eduardo Martins
>             Fix For: 8.0.0.Beta1
>
>
> The EE spec states that a default datasource must be supplied under: java:comp/DefaultDataSource, and if none is specified by the @Resource or persistence.xml, it must be assumed:
>  {code}EE 5.19
> The Java EE Platform requires that a Java EE Product Provider provide a database 
> in the operational environment (see Section EE.2.6, ?Database?). The Java EE 
> Product Provider must also provide a preconfigured, default data source for use by 
> the application in accessing this database.
> The Java EE Product Provider must make the default data source accessible to 
> the application under the JNDI name java:comp/DefaultDataSource.
> The Application Component Provider or Deployer may explicitly bind a 
> DataSource resource reference to the default data source using the lookup element 
> of the Resource annotation or the lookup-name element of the resource-ref
> deployment descriptor element. For example,
> @Resource(lookup="java:comp/DefaultDataSource")
> DataSource myDS;
> In the absence of such a binding, the mapping of the reference will default to 
> the product's default data source.
> For example, the following will map to a preconfigured data source for the 
> product's default database:
> @Resource
> DataSource myDS;{code}
> This, isn't working however:
> {code}
> <persistence version="2.1" xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>    xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/persistence/persistence_2_1.xsd">
>    <persistence-unit name="default" transaction-type="JTA">
>    </persistence-unit>
> </persistence>{code}
> Results in: 
> {code}
> 10:41:31,002 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 50) MSC000001: Failed to start service jboss.persistenceunit."jpa-standard.war#default": org.jboss.msc.service.StartException in service jboss.persistenceunit."jpa-standard.war#default": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:134) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.determineDialect(DialectFactoryImpl.java:98)
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.buildDialect(DialectFactoryImpl.java:66)
> 	at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:193)
> 	at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:88)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:159)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131)
> 	at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration.java:1844)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1802)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:844)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835)
> 	at org.jboss.as.jpa.hibernate4.management.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:115) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	... 4 more
> 10:41:31,010 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"jpa-standard.war#default\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"jpa-standard.war#default\": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
>     Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set"}}
> {code}
> Additionally, actually specifying the expected JDNI name of the default DS like this:
> {code}   <persistence-unit name="default" transaction-type="JTA">
>       <jta-data-source>java:comp/DefaultDataSource</jta-data-source>
>       <exclude-unlisted-classes>false</exclude-unlisted-classes>
>    </persistence-unit>{code}
> Results in this:
> {code}
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.naming.context.java.module.jpa-standard.jpa-standard.DefaultDataSource (missing) dependents: [service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__] 
>       service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__ (missing) dependents: [service jboss.deployment.unit."jpa-standard.war".POST_MODULE] 
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Sat Oct 19 05:04:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Sat, 19 Oct 2013 05:04:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1716) Regression between 3.2.x and
 3.3.x/3.4.x in Infinispan read simulation
In-Reply-To: <JIRA.12503100.1381850347000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503100.1381850347000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503100.1381850347000.6339.1382173442185@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1716:
---------------------------

    Fix Version/s: 3.4.1

    
> Regression between 3.2.x and 3.3.x/3.4.x in Infinispan read simulation
> ----------------------------------------------------------------------
>
>                 Key: JGRP-1716
>                 URL: https://issues.jboss.org/browse/JGRP-1716
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.3, 3.4
>            Reporter: Dan Berindei
>            Assignee: Bela Ban
>             Fix For: 3.4.1, 3.5
>
>         Attachments: benchmark-jgroups.xml, jgroups-udp.pdf, jgroups-udp.xml
>
>
> Comparing JGroups 3.2/3.3/3.4 performance with Radargun, the throughput of reads in scenario simulating Infinispan went down by ~10%. See the attached chart.
> * getall: the get request is sent to single node (randomly picked owner)
> * getfirst: the get requests are sent to 2 nodes with ResponseMode.GET_FIRST - the second response is discarded.
> .h5 Suspects:
> Erik Salter profiled his application and noticed that the message parsing in the UDP receiver thread seemed to slow things down. He wrote a patch that brought his throughput back to 3.2 levels: https://github.com/an1310/JGroups/compare/t_perfhack
> The UDP receiver thread may not tell the whole story, however: in the Radargun tests, performance with his patch was even lower.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 19 05:06:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Sat, 19 Oct 2013 05:06:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1718) Message corruption under
	heavy load
In-Reply-To: <JIRA.12503731.1381946713000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503731.1381946713000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503731.1381946713000.6343.1382173562141@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1718:
---------------------------

    Fix Version/s: 3.5

    
> Message corruption under heavy load
> -----------------------------------
>
>                 Key: JGRP-1718
>                 URL: https://issues.jboss.org/browse/JGRP-1718
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.12
>         Environment: JBoss AS 7.2.0.Final (includes JGroups 3.2.7.Final, upgrading to 3.2.12.Final had no effect)
>            Reporter: Rich DiCroce
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> In my project, I'm using the Kryo serialization library to serialize/deserialize objects to/from byte[]. Some of these byte arrays appear to be getting corrupted during transmission.
> The problem happens very infrequently and only under load. I have to send tens of thousands of messages from hundreds of threads just to get two or three errors. The exception occurs when Kryo tries to deserialize the byte[] on the receiving node. So far, all of the errors I've seen happen when Kryo tries to find a class to deserialize an object, and the stack traces end with something like:
> Caused by: java.lang.ClassNotFoundException: java.util.Date[SOH][GS]
> Note that the [SOH] and [GS] are not literally those strings, they're unprintable ASCII 0x1 and 0x1D.
> I'm confident that Kryo itself is not the source of the problem. I added some code to my project to deserialize the message on the sending node, immediately after serializing it, and log any exception thrown from the deserialization. The sending node did not log an exception, but the receiving node still did. My code passes the byte[] to the Message constructor without doing anything to it.
> It also appears that I am not the first person to encounter this issue. See https://code.google.com/p/kryo/issues/detail?id=102

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 19 05:23:03 2013
From: jira-events at lists.jboss.org (Eduardo Martins (JIRA))
Date: Sat, 19 Oct 2013 05:23:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2027) EE Default DataSource is not
	working
In-Reply-To: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500313.1378739268000.6351.1382174583746@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823311#comment-12823311 ] 

Eduardo Martins commented on WFLY-2027:
---------------------------------------

[~lincolnthree] See Scott reference to JPA spec, not providing a datasource is valid and is how the PU indicates that it should be the container to select a datasource. At WFLY-2212 I example how to update the container's data source selection process, to pickup the EE default datasource if the JPA subsystem config does not defines one.

[~agoncal] java:comp is a namespace that exists in the scope of a particular EE component, such as an EJB. Each EE component has its own java:comp context, except for components in a WAR, these share a single one. 
PUs are not EE components, for instance you may have one in a standalone jar or in EAR lib jar, in such cases which of the java:comp contexts in Wildfly would the PU xml refer to? 
You have two ways for using Wildfly default datasource in a PU, you either don't provide a datasource (jta and non jta), which will work in every Java EE platform implementation, or you provide the  JNDI name configured for the default datasource in the EE subsystem xml.
                
> EE Default DataSource is not working
> ------------------------------------
>
>                 Key: WFLY-2027
>                 URL: https://issues.jboss.org/browse/WFLY-2027
>             Project: WildFly
>          Issue Type: Bug
>          Components: ConfigAdmin, Domain Management, EE, JCA, JPA / Hibernate, Web Console
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Lincoln Baxter III
>            Assignee: Eduardo Martins
>             Fix For: 8.0.0.Beta1
>
>
> The EE spec states that a default datasource must be supplied under: java:comp/DefaultDataSource, and if none is specified by the @Resource or persistence.xml, it must be assumed:
>  {code}EE 5.19
> The Java EE Platform requires that a Java EE Product Provider provide a database 
> in the operational environment (see Section EE.2.6, ?Database?). The Java EE 
> Product Provider must also provide a preconfigured, default data source for use by 
> the application in accessing this database.
> The Java EE Product Provider must make the default data source accessible to 
> the application under the JNDI name java:comp/DefaultDataSource.
> The Application Component Provider or Deployer may explicitly bind a 
> DataSource resource reference to the default data source using the lookup element 
> of the Resource annotation or the lookup-name element of the resource-ref
> deployment descriptor element. For example,
> @Resource(lookup="java:comp/DefaultDataSource")
> DataSource myDS;
> In the absence of such a binding, the mapping of the reference will default to 
> the product's default data source.
> For example, the following will map to a preconfigured data source for the 
> product's default database:
> @Resource
> DataSource myDS;{code}
> This, isn't working however:
> {code}
> <persistence version="2.1" xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>    xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/persistence/persistence_2_1.xsd">
>    <persistence-unit name="default" transaction-type="JTA">
>    </persistence-unit>
> </persistence>{code}
> Results in: 
> {code}
> 10:41:31,002 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 50) MSC000001: Failed to start service jboss.persistenceunit."jpa-standard.war#default": org.jboss.msc.service.StartException in service jboss.persistenceunit."jpa-standard.war#default": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:134) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.determineDialect(DialectFactoryImpl.java:98)
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.buildDialect(DialectFactoryImpl.java:66)
> 	at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:193)
> 	at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:88)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:159)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131)
> 	at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration.java:1844)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1802)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:844)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835)
> 	at org.jboss.as.jpa.hibernate4.management.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:115) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	... 4 more
> 10:41:31,010 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"jpa-standard.war#default\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"jpa-standard.war#default\": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
>     Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set"}}
> {code}
> Additionally, actually specifying the expected JDNI name of the default DS like this:
> {code}   <persistence-unit name="default" transaction-type="JTA">
>       <jta-data-source>java:comp/DefaultDataSource</jta-data-source>
>       <exclude-unlisted-classes>false</exclude-unlisted-classes>
>    </persistence-unit>{code}
> Results in this:
> {code}
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.naming.context.java.module.jpa-standard.jpa-standard.DefaultDataSource (missing) dependents: [service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__] 
>       service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__ (missing) dependents: [service jboss.deployment.unit."jpa-standard.war".POST_MODULE] 
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Sat Oct 19 05:28:02 2013
From: jira-events at lists.jboss.org (Eduardo Martins (JIRA))
Date: Sat, 19 Oct 2013 05:28:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2027) EE Default DataSource is not
	working
In-Reply-To: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500313.1378739268000.6353.1382174882031@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823311#comment-12823311 ] 

Eduardo Martins edited comment on WFLY-2027 at 10/19/13 5:26 AM:
-----------------------------------------------------------------

[~lincolnthree] See Scott reference to JPA spec, not providing a datasource is valid and is how the PU indicates that it should be the container to select a datasource. At WFLY-2212 I example how to update the container's data source selection process, to pickup the EE default datasource if the JPA subsystem config does not defines one.

[~agoncal] java:comp is a namespace that exists in the scope of a particular EE component, such as an EJB. Each EE component has its own java:comp context, except for components in a WAR, these share a single one. 
PUs are not EE components, for instance you may have one in a standalone jar or in EAR lib jar, in such cases which of the java:comp contexts in Wildfly would the PU xml refer to? 
You have two ways for using Wildfly default datasource in a PU, you either don't provide a datasource (jta and non jta), which will work in every Java EE platform implementation, or you provide the  JNDI name configured for the default datasource in the EE subsystem xml.

PS: please note that until WFLY-2212 is solved, to use the portable way you need to configure the default datasource yourself in the JPA subsystem configuration, just copy the jndi name in the EE subsystem configuration. 
                
      was (Author: emmartins):
    [~lincolnthree] See Scott reference to JPA spec, not providing a datasource is valid and is how the PU indicates that it should be the container to select a datasource. At WFLY-2212 I example how to update the container's data source selection process, to pickup the EE default datasource if the JPA subsystem config does not defines one.

[~agoncal] java:comp is a namespace that exists in the scope of a particular EE component, such as an EJB. Each EE component has its own java:comp context, except for components in a WAR, these share a single one. 
PUs are not EE components, for instance you may have one in a standalone jar or in EAR lib jar, in such cases which of the java:comp contexts in Wildfly would the PU xml refer to? 
You have two ways for using Wildfly default datasource in a PU, you either don't provide a datasource (jta and non jta), which will work in every Java EE platform implementation, or you provide the  JNDI name configured for the default datasource in the EE subsystem xml.
                  
> EE Default DataSource is not working
> ------------------------------------
>
>                 Key: WFLY-2027
>                 URL: https://issues.jboss.org/browse/WFLY-2027
>             Project: WildFly
>          Issue Type: Bug
>          Components: ConfigAdmin, Domain Management, EE, JCA, JPA / Hibernate, Web Console
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Lincoln Baxter III
>            Assignee: Eduardo Martins
>             Fix For: 8.0.0.Beta1
>
>
> The EE spec states that a default datasource must be supplied under: java:comp/DefaultDataSource, and if none is specified by the @Resource or persistence.xml, it must be assumed:
>  {code}EE 5.19
> The Java EE Platform requires that a Java EE Product Provider provide a database 
> in the operational environment (see Section EE.2.6, ?Database?). The Java EE 
> Product Provider must also provide a preconfigured, default data source for use by 
> the application in accessing this database.
> The Java EE Product Provider must make the default data source accessible to 
> the application under the JNDI name java:comp/DefaultDataSource.
> The Application Component Provider or Deployer may explicitly bind a 
> DataSource resource reference to the default data source using the lookup element 
> of the Resource annotation or the lookup-name element of the resource-ref
> deployment descriptor element. For example,
> @Resource(lookup="java:comp/DefaultDataSource")
> DataSource myDS;
> In the absence of such a binding, the mapping of the reference will default to 
> the product's default data source.
> For example, the following will map to a preconfigured data source for the 
> product's default database:
> @Resource
> DataSource myDS;{code}
> This, isn't working however:
> {code}
> <persistence version="2.1" xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>    xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/persistence/persistence_2_1.xsd">
>    <persistence-unit name="default" transaction-type="JTA">
>    </persistence-unit>
> </persistence>{code}
> Results in: 
> {code}
> 10:41:31,002 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 50) MSC000001: Failed to start service jboss.persistenceunit."jpa-standard.war#default": org.jboss.msc.service.StartException in service jboss.persistenceunit."jpa-standard.war#default": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:134) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.determineDialect(DialectFactoryImpl.java:98)
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.buildDialect(DialectFactoryImpl.java:66)
> 	at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:193)
> 	at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:88)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:159)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131)
> 	at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration.java:1844)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1802)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:844)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835)
> 	at org.jboss.as.jpa.hibernate4.management.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:115) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	... 4 more
> 10:41:31,010 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"jpa-standard.war#default\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"jpa-standard.war#default\": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
>     Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set"}}
> {code}
> Additionally, actually specifying the expected JDNI name of the default DS like this:
> {code}   <persistence-unit name="default" transaction-type="JTA">
>       <jta-data-source>java:comp/DefaultDataSource</jta-data-source>
>       <exclude-unlisted-classes>false</exclude-unlisted-classes>
>    </persistence-unit>{code}
> Results in this:
> {code}
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.naming.context.java.module.jpa-standard.jpa-standard.DefaultDataSource (missing) dependents: [service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__] 
>       service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__ (missing) dependents: [service jboss.deployment.unit."jpa-standard.war".POST_MODULE] 
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Sat Oct 19 07:15:03 2013
From: jira-events at lists.jboss.org (Denis Kostousov (JIRA))
Date: Sat, 19 Oct 2013 07:15:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2341) WildFly-8.0.0.Beta1 throws an
 exception during persistence unit starting on java 1.8.0-ea-b111
In-Reply-To: <JIRA.12508227.1382181208321@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508227.1382181208321@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508227.1382181208321.6367.1382181303235@jira02.app.mwc.hst.phx2.redhat.com>

Denis Kostousov created WFLY-2341:
-------------------------------------

             Summary: WildFly-8.0.0.Beta1 throws an exception during persistence unit starting on java 1.8.0-ea-b111
                 Key: WFLY-2341
                 URL: https://issues.jboss.org/browse/WFLY-2341
             Project: WildFly
          Issue Type: Bug
          Components: JPA / Hibernate
    Affects Versions: 8.0.0.Beta1
         Environment: % java -version
java version "1.8.0-ea"
Java(TM) SE Runtime Environment (build 1.8.0-ea-b111)
Java HotSpot(TM) 64-Bit Server VM (build 25.0-b53, mixed mode)

% uname -a
Linux irtysh.kostousov.net 3.11.1-200.fc19.x86_64 #1 SMP Sat Sep 14 15:04:51 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

            Reporter: Denis Kostousov
            Assignee: Scott Marlow
            Priority: Critical


An exception occurs during application deploying on Wildfly 8.0.0.Beta1 after jdk was changed from 1.8.0-ea-b109 to 1.8.0-ea-b111. On 1.8.0-ea-b109 same code works fine.
{code}
2013-10-19 16:52:49,975 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 52) MSC000001: Failed to start service jboss.persistenceunit."acquiring-gate-ear-0.5-SNAPSHOT.ear/server-0.5-SNAPSHOT.war#AGDirectory": org.jboss.msc.service.StartException in service jboss.persistenceunit."acquiring-gate-ear-0.5-SNAPSHOT.ear/server-0.5-SNAPSHOT.war#AGDirectory": java.lang.IllegalAccessError: tried to access method java.lang.Object.clone()Ljava/lang/Object; from class org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator
	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:169) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0-ea]
	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:463) [wildfly-security-manager-1.0.0.Beta3.jar:1.0.0.Beta3]
	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:178) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0-ea]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0-ea]
	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.8.0-ea]
	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
Caused by: java.lang.IllegalAccessError: tried to access method java.lang.Object.clone()Ljava/lang/Object; from class org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator
	at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.cloneAndSetupRevisionInfoRelationMapping(AuditMetadataGenerator.java:140)
	at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.addRevisionInfoRelation(AuditMetadataGenerator.java:152)
	at org.hibernate.envers.configuration.internal.metadata.IdMetadataGenerator.addId(IdMetadataGenerator.java:210)
	at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.generateFirstPass(AuditMetadataGenerator.java:561)
	at org.hibernate.envers.configuration.internal.EntitiesConfigurator.configure(EntitiesConfigurator.java:110)
	at org.hibernate.envers.configuration.spi.AuditConfiguration.<init>(AuditConfiguration.java:130)
	at org.hibernate.envers.configuration.spi.AuditConfiguration.getFor(AuditConfiguration.java:180)
	at org.hibernate.envers.event.spi.EnversIntegrator.integrate(EnversIntegrator.java:76)
	at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:310)
	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1837)
	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:854)
	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:847)
	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:396)
	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:846)
	at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:151) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
	... 8 more
{code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 19 07:17:02 2013
From: jira-events at lists.jboss.org (Denis Kostousov (JIRA))
Date: Sat, 19 Oct 2013 07:17:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2294) jandex-1.1.0.Alpha1.jar
 doesn't support JDK 8
In-Reply-To: <JIRA.12502848.1381509782000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502848.1381509782000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502848.1381509782000.6369.1382181422035@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Denis Kostousov updated WFLY-2294:
----------------------------------

    Component/s: Class Loading

    
> jandex-1.1.0.Alpha1.jar doesn't support JDK 8
> ---------------------------------------------
>
>                 Key: WFLY-2294
>                 URL: https://issues.jboss.org/browse/WFLY-2294
>             Project: WildFly
>          Issue Type: Bug
>          Components: Class Loading
>    Affects Versions: 8.0.0.Alpha4, 8.0.0.Beta1
>            Reporter: Denis Kostousov
>
> Wildfly 8.0.0.Beta1 uses jandex-1.1.0.Alpha1.jar This library doesn't support JDK8. It should be replaced by jandex-1.1.0.Final

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 19 07:19:01 2013
From: jira-events at lists.jboss.org (Yves Cuillerdier (JIRA))
Date: Sat, 19 Oct 2013 07:19:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-211) "while(true)" generate
	Stack Map Error
In-Reply-To: <JIRA.12508228.1382181466718@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508228.1382181466718@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508228.1382181466718.6372.1382181541970@jira02.app.mwc.hst.phx2.redhat.com>

Yves Cuillerdier created JASSIST-211:
----------------------------------------

             Summary: "while(true)" generate Stack Map Error
                 Key: JASSIST-211
                 URL: https://issues.jboss.org/browse/JASSIST-211
             Project: Javassist
          Issue Type: Bug
    Affects Versions: 3.18.1-GA
         Environment: Windows 7, Java 1.7.0.15 64 bits
            Reporter: Yves Cuillerdier
            Assignee: Shigeru Chiba


"while(true)" generate a StackMap Error while other forms does not as for example "while(0==0)"

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 19 07:29:02 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Sat, 19 Oct 2013 07:29:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2212) Update JPA subsystem to use
 default datasource
In-Reply-To: <JIRA.12502126.1380810972000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502126.1380810972000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502126.1380810972000.6378.1382182142354@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823312#comment-12823312 ] 

Scott Marlow commented on WFLY-2212:
------------------------------------

In JPA 2.0, the container may or may not be able to supply a default datasource.  If applications want a default datasource to be used, they just configure the jpa section in standalone.xml (or whichever config they are using).  

In the OGM case, the OGM persistence provider (strictly) throws a deployment error if a data-source is supplied.  OGM doesn't use a data-source so throwing an deployment is fine as long as the JPA container doesn't supply one.

Thanks for the patch [~emmartins].  If you can also add the following method to org.jboss.as.jpa.config.Configuration (at the bottom is fine).   Also add a constant (something like) JPA_ALLOW_DEFAULT_DATA_SOURCE_USE set to "wildfly.jpa.allowdefaultdatasourceuse" (defaults to true but can be overridden to false in a persistence unit definition).  I think the focus is on tck now but we can see if your patch is accepted for WF8, if not it can be considered for WF9.  Another change that is needed is to pick one of JPA unit tests and remove the datasource from the persistence.xml (org.jboss.as.test.integration.jpa.webtxem.WebJPATestCase or pick any one).   Other changes are below.

{code}
    /**
     * Determine the default data-source should be used
     *
     * @param pu
     * @return true if the default data-source should be used
     */
    public static boolean allowDefaultDataSourceUse(PersistenceUnitMetadata pu) {
        boolean result = true;
        if (pu.getProperties().containsKey(Configuration.JPA_ALLOW_DEFAULT_DATA_SOURCE_USE)) {
            result = Boolean.parseBoolean(pu.getProperties().getProperty(Configuration.JPA_ALLOW_DEFAULT_DATA_SOURCE_USE));
        }
        return result;
    }
{code}

In PersistenceUnitServiceHandler, change to:
{code}
boolean useDefaultDataSource = Configuration.allowDefaultDataSourceUse(pu);
{code}
                
> Update JPA subsystem to use default datasource
> ----------------------------------------------
>
>                 Key: WFLY-2212
>                 URL: https://issues.jboss.org/browse/WFLY-2212
>             Project: WildFly
>          Issue Type: Task
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 8.0.0.CR1
>
>
> See comments in WFLY-2027 before starting the work on this jira...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 19 07:29:02 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Sat, 19 Oct 2013 07:29:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2212) Update JPA subsystem to use
 default datasource
In-Reply-To: <JIRA.12502126.1380810972000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502126.1380810972000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502126.1380810972000.6382.1382182142715@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823312#comment-12823312 ] 

Scott Marlow edited comment on WFLY-2212 at 10/19/13 7:28 AM:
--------------------------------------------------------------

In JPA 2.0, the container may or may not be able to supply a default datasource.  If applications want a default datasource to be used, they just configure the jpa section in standalone.xml (or whichever config they are using).  

In the OGM case, the OGM persistence provider (strictly) throws a deployment error if a data-source is supplied.  OGM doesn't use a data-source so throwing an deployment is fine as long as the JPA container doesn't supply one.

Thanks for the patch [~emmartins].  If you can also add the following method to org.jboss.as.jpa.config.Configuration (at the bottom is fine).   Also add a constant (something like) JPA_ALLOW_DEFAULT_DATA_SOURCE_USE set to "wildfly.jpa.allowdefaultdatasourceuse" (defaults to true but can be overridden to false in a persistence unit definition).  I think the focus is on tck now but we can see if your patch is accepted for WF8, if not it can be considered for WF9.  Another change that is needed is to pick one of JPA unit tests and remove the datasource from the persistence.xml (org.jboss.as.test.integration.jpa.webtxem.WebJPATestCase or pick any one).   Other changes are below.

{code}
    /**
     * Determine if the default data-source should be used
     *
     * @param pu
     * @return true if the default data-source should be used
     */
    public static boolean allowDefaultDataSourceUse(PersistenceUnitMetadata pu) {
        boolean result = true;
        if (pu.getProperties().containsKey(Configuration.JPA_ALLOW_DEFAULT_DATA_SOURCE_USE)) {
            result = Boolean.parseBoolean(pu.getProperties().getProperty(Configuration.JPA_ALLOW_DEFAULT_DATA_SOURCE_USE));
        }
        return result;
    }
{code}

In PersistenceUnitServiceHandler, change to:
{code}
boolean useDefaultDataSource = Configuration.allowDefaultDataSourceUse(pu);
{code}
                
      was (Author: smarlow):
    In JPA 2.0, the container may or may not be able to supply a default datasource.  If applications want a default datasource to be used, they just configure the jpa section in standalone.xml (or whichever config they are using).  

In the OGM case, the OGM persistence provider (strictly) throws a deployment error if a data-source is supplied.  OGM doesn't use a data-source so throwing an deployment is fine as long as the JPA container doesn't supply one.

Thanks for the patch [~emmartins].  If you can also add the following method to org.jboss.as.jpa.config.Configuration (at the bottom is fine).   Also add a constant (something like) JPA_ALLOW_DEFAULT_DATA_SOURCE_USE set to "wildfly.jpa.allowdefaultdatasourceuse" (defaults to true but can be overridden to false in a persistence unit definition).  I think the focus is on tck now but we can see if your patch is accepted for WF8, if not it can be considered for WF9.  Another change that is needed is to pick one of JPA unit tests and remove the datasource from the persistence.xml (org.jboss.as.test.integration.jpa.webtxem.WebJPATestCase or pick any one).   Other changes are below.

{code}
    /**
     * Determine the default data-source should be used
     *
     * @param pu
     * @return true if the default data-source should be used
     */
    public static boolean allowDefaultDataSourceUse(PersistenceUnitMetadata pu) {
        boolean result = true;
        if (pu.getProperties().containsKey(Configuration.JPA_ALLOW_DEFAULT_DATA_SOURCE_USE)) {
            result = Boolean.parseBoolean(pu.getProperties().getProperty(Configuration.JPA_ALLOW_DEFAULT_DATA_SOURCE_USE));
        }
        return result;
    }
{code}

In PersistenceUnitServiceHandler, change to:
{code}
boolean useDefaultDataSource = Configuration.allowDefaultDataSourceUse(pu);
{code}
                  
> Update JPA subsystem to use default datasource
> ----------------------------------------------
>
>                 Key: WFLY-2212
>                 URL: https://issues.jboss.org/browse/WFLY-2212
>             Project: WildFly
>          Issue Type: Task
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 8.0.0.CR1
>
>
> See comments in WFLY-2027 before starting the work on this jira...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 19 07:47:02 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Sat, 19 Oct 2013 07:47:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2212) Update JPA subsystem to use
 default datasource
In-Reply-To: <JIRA.12502126.1380810972000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502126.1380810972000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502126.1380810972000.6391.1382183222080@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823313#comment-12823313 ] 

Scott Marlow commented on WFLY-2212:
------------------------------------

One other comment, if eeModuleDescription.getDefaultResourceJndiNames().getDataSource() is returning  "java:comp/DefaultDataSource", this patch will not be useful.  In which case, a different change is needed.  Can you clarify?

What does eeModuleDescription.getDefaultResourceJndiNames().getDataSource() return exactly?  If it returns "java:jboss/datasources/ExampleDS", we are fine.  If not, the other patch is simpler and mostly to standalone.xml and other configuration files to default the jpa datasource to "java:jboss/datasources/ExampleDS" and the Configuration.allowDefaultDataSourceUse(pu) change would also be needed.
                
> Update JPA subsystem to use default datasource
> ----------------------------------------------
>
>                 Key: WFLY-2212
>                 URL: https://issues.jboss.org/browse/WFLY-2212
>             Project: WildFly
>          Issue Type: Task
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 8.0.0.CR1
>
>
> See comments in WFLY-2027 before starting the work on this jira...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 19 07:49:02 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Sat, 19 Oct 2013 07:49:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2027) EE Default DataSource is not
	working
In-Reply-To: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500313.1378739268000.6399.1382183342308@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823314#comment-12823314 ] 

Scott Marlow commented on WFLY-2027:
------------------------------------

Antonio, I agree with you, that JPA does not require the EE default data source to be used.  EE 7 does require one to be available but only at the EE component level which doesn't apply to persistence unit definitions for reasons that I stated above (persistence unit is not part of a EE component but is instead used by EE components).  

[~emmartins], I don't think that there is a portable way as JPA doesn't require a default datasource feature to be implemented.  Unless someone can state otherwise (with a reference to the JPA spec section that points out that I am in error), I think we should treat WFLY-2212 as an extension.  This is a minor point but others will look at this jira to help them understand more about using a default datasource with jpa.  I think we are otherwise in agreement.
                
> EE Default DataSource is not working
> ------------------------------------
>
>                 Key: WFLY-2027
>                 URL: https://issues.jboss.org/browse/WFLY-2027
>             Project: WildFly
>          Issue Type: Bug
>          Components: ConfigAdmin, Domain Management, EE, JCA, JPA / Hibernate, Web Console
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Lincoln Baxter III
>            Assignee: Eduardo Martins
>             Fix For: 8.0.0.Beta1
>
>
> The EE spec states that a default datasource must be supplied under: java:comp/DefaultDataSource, and if none is specified by the @Resource or persistence.xml, it must be assumed:
>  {code}EE 5.19
> The Java EE Platform requires that a Java EE Product Provider provide a database 
> in the operational environment (see Section EE.2.6, ?Database?). The Java EE 
> Product Provider must also provide a preconfigured, default data source for use by 
> the application in accessing this database.
> The Java EE Product Provider must make the default data source accessible to 
> the application under the JNDI name java:comp/DefaultDataSource.
> The Application Component Provider or Deployer may explicitly bind a 
> DataSource resource reference to the default data source using the lookup element 
> of the Resource annotation or the lookup-name element of the resource-ref
> deployment descriptor element. For example,
> @Resource(lookup="java:comp/DefaultDataSource")
> DataSource myDS;
> In the absence of such a binding, the mapping of the reference will default to 
> the product's default data source.
> For example, the following will map to a preconfigured data source for the 
> product's default database:
> @Resource
> DataSource myDS;{code}
> This, isn't working however:
> {code}
> <persistence version="2.1" xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>    xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/persistence/persistence_2_1.xsd">
>    <persistence-unit name="default" transaction-type="JTA">
>    </persistence-unit>
> </persistence>{code}
> Results in: 
> {code}
> 10:41:31,002 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 50) MSC000001: Failed to start service jboss.persistenceunit."jpa-standard.war#default": org.jboss.msc.service.StartException in service jboss.persistenceunit."jpa-standard.war#default": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:134) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.determineDialect(DialectFactoryImpl.java:98)
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.buildDialect(DialectFactoryImpl.java:66)
> 	at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:193)
> 	at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:88)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:159)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131)
> 	at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration.java:1844)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1802)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:844)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835)
> 	at org.jboss.as.jpa.hibernate4.management.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:115) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	... 4 more
> 10:41:31,010 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"jpa-standard.war#default\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"jpa-standard.war#default\": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
>     Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set"}}
> {code}
> Additionally, actually specifying the expected JDNI name of the default DS like this:
> {code}   <persistence-unit name="default" transaction-type="JTA">
>       <jta-data-source>java:comp/DefaultDataSource</jta-data-source>
>       <exclude-unlisted-classes>false</exclude-unlisted-classes>
>    </persistence-unit>{code}
> Results in this:
> {code}
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.naming.context.java.module.jpa-standard.jpa-standard.DefaultDataSource (missing) dependents: [service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__] 
>       service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__ (missing) dependents: [service jboss.deployment.unit."jpa-standard.war".POST_MODULE] 
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Sat Oct 19 09:09:02 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Sat, 19 Oct 2013 09:09:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2341) WildFly-8.0.0.Beta1 throws an
 exception during persistence unit starting on java 1.8.0-ea-b111
In-Reply-To: <JIRA.12508227.1382181208000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508227.1382181208000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508227.1382181208000.6405.1382188142245@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823315#comment-12823315 ] 

Scott Marlow commented on WFLY-2341:
------------------------------------

What happens if you build the Hibernate dev project under the new java8?  I'm not sure if anyone has tried that yet but you could:
{quote}
git clone git at github.com:hibernate/hibernate-orm.git hibernate
cd hibernate
./gradlew clean install test

                
> WildFly-8.0.0.Beta1 throws an exception during persistence unit starting on java 1.8.0-ea-b111
> ----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2341
>                 URL: https://issues.jboss.org/browse/WFLY-2341
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Beta1
>         Environment: % java -version
> java version "1.8.0-ea"
> Java(TM) SE Runtime Environment (build 1.8.0-ea-b111)
> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b53, mixed mode)
> % uname -a
> Linux irtysh.kostousov.net 3.11.1-200.fc19.x86_64 #1 SMP Sat Sep 14 15:04:51 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
>            Reporter: Denis Kostousov
>            Assignee: Scott Marlow
>            Priority: Critical
>
> An exception occurs during application deploying on Wildfly 8.0.0.Beta1 after jdk was changed from 1.8.0-ea-b109 to 1.8.0-ea-b111. On 1.8.0-ea-b109 same code works fine.
> {code}
> 2013-10-19 16:52:49,975 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 52) MSC000001: Failed to start service jboss.persistenceunit."acquiring-gate-ear-0.5-SNAPSHOT.ear/server-0.5-SNAPSHOT.war#AGDirectory": org.jboss.msc.service.StartException in service jboss.persistenceunit."acquiring-gate-ear-0.5-SNAPSHOT.ear/server-0.5-SNAPSHOT.war#AGDirectory": java.lang.IllegalAccessError: tried to access method java.lang.Object.clone()Ljava/lang/Object; from class org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:169) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0-ea]
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:463) [wildfly-security-manager-1.0.0.Beta3.jar:1.0.0.Beta3]
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:178) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0-ea]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0-ea]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.8.0-ea]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: java.lang.IllegalAccessError: tried to access method java.lang.Object.clone()Ljava/lang/Object; from class org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator
> 	at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.cloneAndSetupRevisionInfoRelationMapping(AuditMetadataGenerator.java:140)
> 	at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.addRevisionInfoRelation(AuditMetadataGenerator.java:152)
> 	at org.hibernate.envers.configuration.internal.metadata.IdMetadataGenerator.addId(IdMetadataGenerator.java:210)
> 	at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.generateFirstPass(AuditMetadataGenerator.java:561)
> 	at org.hibernate.envers.configuration.internal.EntitiesConfigurator.configure(EntitiesConfigurator.java:110)
> 	at org.hibernate.envers.configuration.spi.AuditConfiguration.<init>(AuditConfiguration.java:130)
> 	at org.hibernate.envers.configuration.spi.AuditConfiguration.getFor(AuditConfiguration.java:180)
> 	at org.hibernate.envers.event.spi.EnversIntegrator.integrate(EnversIntegrator.java:76)
> 	at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:310)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1837)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:854)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:847)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:396)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:846)
> 	at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:151) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	... 8 more
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 19 09:09:02 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Sat, 19 Oct 2013 09:09:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2341) WildFly-8.0.0.Beta1 throws an
 exception during persistence unit starting on java 1.8.0-ea-b111
In-Reply-To: <JIRA.12508227.1382181208000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508227.1382181208000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508227.1382181208000.6408.1382188142398@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823315#comment-12823315 ] 

Scott Marlow edited comment on WFLY-2341 at 10/19/13 9:08 AM:
--------------------------------------------------------------

What happens if you build the Hibernate dev project under the new java8?  I'm not sure if anyone has tried that yet but you could:
{quote}
git clone git at github.com:hibernate/hibernate-orm.git hibernate
cd hibernate
./gradlew clean install test
{quote}
                
      was (Author: smarlow):
    What happens if you build the Hibernate dev project under the new java8?  I'm not sure if anyone has tried that yet but you could:
{quote}
git clone git at github.com:hibernate/hibernate-orm.git hibernate
cd hibernate
./gradlew clean install test

                  
> WildFly-8.0.0.Beta1 throws an exception during persistence unit starting on java 1.8.0-ea-b111
> ----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2341
>                 URL: https://issues.jboss.org/browse/WFLY-2341
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Beta1
>         Environment: % java -version
> java version "1.8.0-ea"
> Java(TM) SE Runtime Environment (build 1.8.0-ea-b111)
> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b53, mixed mode)
> % uname -a
> Linux irtysh.kostousov.net 3.11.1-200.fc19.x86_64 #1 SMP Sat Sep 14 15:04:51 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
>            Reporter: Denis Kostousov
>            Assignee: Scott Marlow
>            Priority: Critical
>
> An exception occurs during application deploying on Wildfly 8.0.0.Beta1 after jdk was changed from 1.8.0-ea-b109 to 1.8.0-ea-b111. On 1.8.0-ea-b109 same code works fine.
> {code}
> 2013-10-19 16:52:49,975 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 52) MSC000001: Failed to start service jboss.persistenceunit."acquiring-gate-ear-0.5-SNAPSHOT.ear/server-0.5-SNAPSHOT.war#AGDirectory": org.jboss.msc.service.StartException in service jboss.persistenceunit."acquiring-gate-ear-0.5-SNAPSHOT.ear/server-0.5-SNAPSHOT.war#AGDirectory": java.lang.IllegalAccessError: tried to access method java.lang.Object.clone()Ljava/lang/Object; from class org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:169) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0-ea]
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:463) [wildfly-security-manager-1.0.0.Beta3.jar:1.0.0.Beta3]
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:178) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0-ea]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0-ea]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.8.0-ea]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: java.lang.IllegalAccessError: tried to access method java.lang.Object.clone()Ljava/lang/Object; from class org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator
> 	at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.cloneAndSetupRevisionInfoRelationMapping(AuditMetadataGenerator.java:140)
> 	at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.addRevisionInfoRelation(AuditMetadataGenerator.java:152)
> 	at org.hibernate.envers.configuration.internal.metadata.IdMetadataGenerator.addId(IdMetadataGenerator.java:210)
> 	at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.generateFirstPass(AuditMetadataGenerator.java:561)
> 	at org.hibernate.envers.configuration.internal.EntitiesConfigurator.configure(EntitiesConfigurator.java:110)
> 	at org.hibernate.envers.configuration.spi.AuditConfiguration.<init>(AuditConfiguration.java:130)
> 	at org.hibernate.envers.configuration.spi.AuditConfiguration.getFor(AuditConfiguration.java:180)
> 	at org.hibernate.envers.event.spi.EnversIntegrator.integrate(EnversIntegrator.java:76)
> 	at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:310)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1837)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:854)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:847)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:396)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:846)
> 	at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:151) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	... 8 more
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 19 10:42:02 2013
From: jira-events at lists.jboss.org (Denis Kostousov (JIRA))
Date: Sat, 19 Oct 2013 10:42:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2341) WildFly-8.0.0.Beta1 throws an
 exception during persistence unit starting on java 1.8.0-ea-b111
In-Reply-To: <JIRA.12508227.1382181208000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508227.1382181208000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508227.1382181208000.6431.1382193722294@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823317#comment-12823317 ] 

Denis Kostousov edited comment on WFLY-2341 at 10/19/13 10:41 AM:
------------------------------------------------------------------

I have attached a build output. The compilation fails. Where I can see compiler logs?
                
      was (Author: sandello):
    build hiberanate master with command
./gradlew clean install test --stacktrace
                  
> WildFly-8.0.0.Beta1 throws an exception during persistence unit starting on java 1.8.0-ea-b111
> ----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2341
>                 URL: https://issues.jboss.org/browse/WFLY-2341
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Beta1
>         Environment: % java -version
> java version "1.8.0-ea"
> Java(TM) SE Runtime Environment (build 1.8.0-ea-b111)
> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b53, mixed mode)
> % uname -a
> Linux irtysh.kostousov.net 3.11.1-200.fc19.x86_64 #1 SMP Sat Sep 14 15:04:51 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
>            Reporter: Denis Kostousov
>            Assignee: Scott Marlow
>            Priority: Critical
>         Attachments: hibernate.HEAD.build.log
>
>
> An exception occurs during application deploying on Wildfly 8.0.0.Beta1 after jdk was changed from 1.8.0-ea-b109 to 1.8.0-ea-b111. On 1.8.0-ea-b109 same code works fine.
> {code}
> 2013-10-19 16:52:49,975 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 52) MSC000001: Failed to start service jboss.persistenceunit."acquiring-gate-ear-0.5-SNAPSHOT.ear/server-0.5-SNAPSHOT.war#AGDirectory": org.jboss.msc.service.StartException in service jboss.persistenceunit."acquiring-gate-ear-0.5-SNAPSHOT.ear/server-0.5-SNAPSHOT.war#AGDirectory": java.lang.IllegalAccessError: tried to access method java.lang.Object.clone()Ljava/lang/Object; from class org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:169) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0-ea]
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:463) [wildfly-security-manager-1.0.0.Beta3.jar:1.0.0.Beta3]
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:178) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0-ea]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0-ea]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.8.0-ea]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: java.lang.IllegalAccessError: tried to access method java.lang.Object.clone()Ljava/lang/Object; from class org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator
> 	at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.cloneAndSetupRevisionInfoRelationMapping(AuditMetadataGenerator.java:140)
> 	at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.addRevisionInfoRelation(AuditMetadataGenerator.java:152)
> 	at org.hibernate.envers.configuration.internal.metadata.IdMetadataGenerator.addId(IdMetadataGenerator.java:210)
> 	at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.generateFirstPass(AuditMetadataGenerator.java:561)
> 	at org.hibernate.envers.configuration.internal.EntitiesConfigurator.configure(EntitiesConfigurator.java:110)
> 	at org.hibernate.envers.configuration.spi.AuditConfiguration.<init>(AuditConfiguration.java:130)
> 	at org.hibernate.envers.configuration.spi.AuditConfiguration.getFor(AuditConfiguration.java:180)
> 	at org.hibernate.envers.event.spi.EnversIntegrator.integrate(EnversIntegrator.java:76)
> 	at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:310)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1837)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:854)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:847)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:396)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:846)
> 	at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:151) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	... 8 more
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 19 10:42:02 2013
From: jira-events at lists.jboss.org (Denis Kostousov (JIRA))
Date: Sat, 19 Oct 2013 10:42:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2341) WildFly-8.0.0.Beta1 throws an
 exception during persistence unit starting on java 1.8.0-ea-b111
In-Reply-To: <JIRA.12508227.1382181208000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508227.1382181208000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508227.1382181208000.6428.1382193722145@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Denis Kostousov updated WFLY-2341:
----------------------------------

    Attachment: hibernate.HEAD.build.log


build hiberanate master with command
./gradlew clean install test --stacktrace
                
> WildFly-8.0.0.Beta1 throws an exception during persistence unit starting on java 1.8.0-ea-b111
> ----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2341
>                 URL: https://issues.jboss.org/browse/WFLY-2341
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Beta1
>         Environment: % java -version
> java version "1.8.0-ea"
> Java(TM) SE Runtime Environment (build 1.8.0-ea-b111)
> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b53, mixed mode)
> % uname -a
> Linux irtysh.kostousov.net 3.11.1-200.fc19.x86_64 #1 SMP Sat Sep 14 15:04:51 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
>            Reporter: Denis Kostousov
>            Assignee: Scott Marlow
>            Priority: Critical
>         Attachments: hibernate.HEAD.build.log
>
>
> An exception occurs during application deploying on Wildfly 8.0.0.Beta1 after jdk was changed from 1.8.0-ea-b109 to 1.8.0-ea-b111. On 1.8.0-ea-b109 same code works fine.
> {code}
> 2013-10-19 16:52:49,975 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 52) MSC000001: Failed to start service jboss.persistenceunit."acquiring-gate-ear-0.5-SNAPSHOT.ear/server-0.5-SNAPSHOT.war#AGDirectory": org.jboss.msc.service.StartException in service jboss.persistenceunit."acquiring-gate-ear-0.5-SNAPSHOT.ear/server-0.5-SNAPSHOT.war#AGDirectory": java.lang.IllegalAccessError: tried to access method java.lang.Object.clone()Ljava/lang/Object; from class org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:169) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0-ea]
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:463) [wildfly-security-manager-1.0.0.Beta3.jar:1.0.0.Beta3]
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:178) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0-ea]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0-ea]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.8.0-ea]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: java.lang.IllegalAccessError: tried to access method java.lang.Object.clone()Ljava/lang/Object; from class org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator
> 	at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.cloneAndSetupRevisionInfoRelationMapping(AuditMetadataGenerator.java:140)
> 	at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.addRevisionInfoRelation(AuditMetadataGenerator.java:152)
> 	at org.hibernate.envers.configuration.internal.metadata.IdMetadataGenerator.addId(IdMetadataGenerator.java:210)
> 	at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.generateFirstPass(AuditMetadataGenerator.java:561)
> 	at org.hibernate.envers.configuration.internal.EntitiesConfigurator.configure(EntitiesConfigurator.java:110)
> 	at org.hibernate.envers.configuration.spi.AuditConfiguration.<init>(AuditConfiguration.java:130)
> 	at org.hibernate.envers.configuration.spi.AuditConfiguration.getFor(AuditConfiguration.java:180)
> 	at org.hibernate.envers.event.spi.EnversIntegrator.integrate(EnversIntegrator.java:76)
> 	at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:310)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1837)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:854)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:847)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:396)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:846)
> 	at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:151) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	... 8 more
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 19 10:44:02 2013
From: jira-events at lists.jboss.org (Denis Kostousov (JIRA))
Date: Sat, 19 Oct 2013 10:44:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2341) WildFly-8.0.0.Beta1 throws an
 exception during persistence unit starting on java 1.8.0-ea-b111
In-Reply-To: <JIRA.12508227.1382181208000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508227.1382181208000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508227.1382181208000.6438.1382193842187@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823317#comment-12823317 ] 

Denis Kostousov edited comment on WFLY-2341 at 10/19/13 10:43 AM:
------------------------------------------------------------------

I have attached a build output. The compilation fails on 1.8.0-ea-b111. Where I can see compiler logs?
                
      was (Author: sandello):
    I have attached a build output. The compilation fails. Where I can see compiler logs?
                  
> WildFly-8.0.0.Beta1 throws an exception during persistence unit starting on java 1.8.0-ea-b111
> ----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2341
>                 URL: https://issues.jboss.org/browse/WFLY-2341
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Beta1
>         Environment: % java -version
> java version "1.8.0-ea"
> Java(TM) SE Runtime Environment (build 1.8.0-ea-b111)
> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b53, mixed mode)
> % uname -a
> Linux irtysh.kostousov.net 3.11.1-200.fc19.x86_64 #1 SMP Sat Sep 14 15:04:51 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
>            Reporter: Denis Kostousov
>            Assignee: Scott Marlow
>            Priority: Critical
>         Attachments: hibernate.HEAD.build.log
>
>
> An exception occurs during application deploying on Wildfly 8.0.0.Beta1 after jdk was changed from 1.8.0-ea-b109 to 1.8.0-ea-b111. On 1.8.0-ea-b109 same code works fine.
> {code}
> 2013-10-19 16:52:49,975 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 52) MSC000001: Failed to start service jboss.persistenceunit."acquiring-gate-ear-0.5-SNAPSHOT.ear/server-0.5-SNAPSHOT.war#AGDirectory": org.jboss.msc.service.StartException in service jboss.persistenceunit."acquiring-gate-ear-0.5-SNAPSHOT.ear/server-0.5-SNAPSHOT.war#AGDirectory": java.lang.IllegalAccessError: tried to access method java.lang.Object.clone()Ljava/lang/Object; from class org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:169) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0-ea]
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:463) [wildfly-security-manager-1.0.0.Beta3.jar:1.0.0.Beta3]
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:178) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0-ea]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0-ea]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.8.0-ea]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: java.lang.IllegalAccessError: tried to access method java.lang.Object.clone()Ljava/lang/Object; from class org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator
> 	at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.cloneAndSetupRevisionInfoRelationMapping(AuditMetadataGenerator.java:140)
> 	at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.addRevisionInfoRelation(AuditMetadataGenerator.java:152)
> 	at org.hibernate.envers.configuration.internal.metadata.IdMetadataGenerator.addId(IdMetadataGenerator.java:210)
> 	at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.generateFirstPass(AuditMetadataGenerator.java:561)
> 	at org.hibernate.envers.configuration.internal.EntitiesConfigurator.configure(EntitiesConfigurator.java:110)
> 	at org.hibernate.envers.configuration.spi.AuditConfiguration.<init>(AuditConfiguration.java:130)
> 	at org.hibernate.envers.configuration.spi.AuditConfiguration.getFor(AuditConfiguration.java:180)
> 	at org.hibernate.envers.event.spi.EnversIntegrator.integrate(EnversIntegrator.java:76)
> 	at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:310)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1837)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:854)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:847)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:396)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:846)
> 	at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:151) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	... 8 more
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 19 11:31:02 2013
From: jira-events at lists.jboss.org (Michael Musgrove (JIRA))
Date: Sat, 19 Oct 2013 11:31:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2342) Update jboss-transaction-spi
In-Reply-To: <JIRA.12508232.1382196555436@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508232.1382196555436@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508232.1382196555436.6443.1382196662007@jira02.app.mwc.hst.phx2.redhat.com>

Michael Musgrove created WFLY-2342:
--------------------------------------

             Summary: Update jboss-transaction-spi
                 Key: WFLY-2342
                 URL: https://issues.jboss.org/browse/WFLY-2342
             Project: WildFly
          Issue Type: Task
          Components: Transactions
    Affects Versions: 8.0.0.Beta1
            Reporter: Michael Musgrove
            Assignee: Michael Musgrove
             Fix For: 8.0.0.CR1


The latest transactions SPI contains two new marker interfaces requested by JCA that Jesper needs before he can finalise the latest IJ release

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 19 11:58:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Sat, 19 Oct 2013 11:58:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1716) Regression between 3.2.x and
 3.3.x/3.4.x in Infinispan read simulation
In-Reply-To: <JIRA.12503100.1381850347000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503100.1381850347000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503100.1381850347000.6454.1382198282198@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12814588#comment-12814588 ] 

Bela Ban edited comment on JGRP-1716 at 10/19/13 11:57 AM:
-----------------------------------------------------------

Note that DONT_BUNDLE should not be used in 3.4 anymore, and Infinispan still uses it despite my recommendations ! Could be well possible that - in combination with the new bundler - DONT_BUNDLE is actually detrimental to perf. I'll run radagun myself to hopefully find out why...
                
      was (Author: belaban):
    Note that DONT_BUNDLE should not be used in 3.4 anymore, and Infinispan still uses it despite my recommendations ! Could be well possible that - in combination with the new bundler - DONT_BUNDLE is actually detrimental to perf. I'll run radagun myself tohopefully find out why...
                  
> Regression between 3.2.x and 3.3.x/3.4.x in Infinispan read simulation
> ----------------------------------------------------------------------
>
>                 Key: JGRP-1716
>                 URL: https://issues.jboss.org/browse/JGRP-1716
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.3, 3.4
>            Reporter: Dan Berindei
>            Assignee: Bela Ban
>             Fix For: 3.4.1, 3.5
>
>         Attachments: benchmark-jgroups.xml, jgroups-udp.pdf, jgroups-udp.xml
>
>
> Comparing JGroups 3.2/3.3/3.4 performance with Radargun, the throughput of reads in scenario simulating Infinispan went down by ~10%. See the attached chart.
> * getall: the get request is sent to single node (randomly picked owner)
> * getfirst: the get requests are sent to 2 nodes with ResponseMode.GET_FIRST - the second response is discarded.
> .h5 Suspects:
> Erik Salter profiled his application and noticed that the message parsing in the UDP receiver thread seemed to slow things down. He wrote a patch that brought his throughput back to 3.2 levels: https://github.com/an1310/JGroups/compare/t_perfhack
> The UDP receiver thread may not tell the whole story, however: in the Radargun tests, performance with his patch was even lower.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 19 11:58:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Sat, 19 Oct 2013 11:58:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1716) Regression between 3.2.x and
 3.3.x/3.4.x in Infinispan read simulation
In-Reply-To: <JIRA.12503100.1381850347000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503100.1381850347000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503100.1381850347000.6459.1382198282423@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1716.
----------------------------

    Resolution: Done

    
> Regression between 3.2.x and 3.3.x/3.4.x in Infinispan read simulation
> ----------------------------------------------------------------------
>
>                 Key: JGRP-1716
>                 URL: https://issues.jboss.org/browse/JGRP-1716
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.3, 3.4
>            Reporter: Dan Berindei
>            Assignee: Bela Ban
>             Fix For: 3.4.1, 3.5
>
>         Attachments: benchmark-jgroups.xml, jgroups-udp.pdf, jgroups-udp.xml
>
>
> Comparing JGroups 3.2/3.3/3.4 performance with Radargun, the throughput of reads in scenario simulating Infinispan went down by ~10%. See the attached chart.
> * getall: the get request is sent to single node (randomly picked owner)
> * getfirst: the get requests are sent to 2 nodes with ResponseMode.GET_FIRST - the second response is discarded.
> .h5 Suspects:
> Erik Salter profiled his application and noticed that the message parsing in the UDP receiver thread seemed to slow things down. He wrote a patch that brought his throughput back to 3.2 levels: https://github.com/an1310/JGroups/compare/t_perfhack
> The UDP receiver thread may not tell the whole story, however: in the Radargun tests, performance with his patch was even lower.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 19 12:11:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Sat, 19 Oct 2013 12:11:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1716) Regression between 3.2.x and
 3.3.x/3.4.x in Infinispan read simulation
In-Reply-To: <JIRA.12503100.1381850347000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503100.1381850347000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503100.1381850347000.6467.1382199062051@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823320#comment-12823320 ] 

Bela Ban commented on JGRP-1716:
--------------------------------

I got much better perf with JGRP-1716 implemented:

|| type || reads/sec (old) || writes/sec (old) || reads/sec (new) || writes/sec (new) ||
| 32-udp-dontbundle-getall | 28'453 | 9'573 | - | - |
| 34-udp-dontbundle-getall | 25'819 | 8'457 | 26'852 | 11'960 |
| 34-udp-bundle-getall | 27'765 | 9'175 | 34'631 | 15'088 |
| 32-udp-dontbundle-getfirst | 10'764 | 6'301 | - | - |
| 34-udp-dontbundle-getfirst | 15'621 | 3'597 | 15'640 | 4'905 |
| 34-udp-bundle-getfirst | 18'434 | 4'354 | 22'980 | 6'526 |

* I didn't run the tests for 3.2 again, only for 3.4
* For the new tests I used fast.xml instead of jgroups-udp.xml
** The only diff between fast.xml and fast-local/xml shipped with JGroups is that ip_ttl=1
                
> Regression between 3.2.x and 3.3.x/3.4.x in Infinispan read simulation
> ----------------------------------------------------------------------
>
>                 Key: JGRP-1716
>                 URL: https://issues.jboss.org/browse/JGRP-1716
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.3, 3.4
>            Reporter: Dan Berindei
>            Assignee: Bela Ban
>             Fix For: 3.4.1, 3.5
>
>         Attachments: benchmark-jgroups.xml, jgroups-udp.pdf, jgroups-udp.xml
>
>
> Comparing JGroups 3.2/3.3/3.4 performance with Radargun, the throughput of reads in scenario simulating Infinispan went down by ~10%. See the attached chart.
> * getall: the get request is sent to single node (randomly picked owner)
> * getfirst: the get requests are sent to 2 nodes with ResponseMode.GET_FIRST - the second response is discarded.
> .h5 Suspects:
> Erik Salter profiled his application and noticed that the message parsing in the UDP receiver thread seemed to slow things down. He wrote a patch that brought his throughput back to 3.2 levels: https://github.com/an1310/JGroups/compare/t_perfhack
> The UDP receiver thread may not tell the whole story, however: in the Radargun tests, performance with his patch was even lower.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 19 12:13:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Sat, 19 Oct 2013 12:13:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1716) Regression between 3.2.x and
 3.3.x/3.4.x in Infinispan read simulation
In-Reply-To: <JIRA.12503100.1381850347000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503100.1381850347000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503100.1381850347000.6470.1382199182056@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823320#comment-12823320 ] 

Bela Ban edited comment on JGRP-1716 at 10/19/13 12:12 PM:
-----------------------------------------------------------

I got much better perf with JGRP-1716 implemented:

|| type || reads/sec (old) || writes/sec (old) || reads/sec (new) || writes/sec (new) ||
| 32-udp-dontbundle-getall | 28'453 | 9'573 | - | - |
| 34-udp-dontbundle-getall | 25'819 | 8'457 | 26'852 | 11'960 |
| 34-udp-bundle-getall | 27'765 | 9'175 | 34'631 | 15'088 |
| 32-udp-dontbundle-getfirst | 10'764 | 6'301 | - | - |
| 34-udp-dontbundle-getfirst | 15'621 | 3'597 | 15'640 | 4'905 |
| 34-udp-bundle-getfirst | 18'434 | 4'354 | 22'980 | 6'526 |

* I didn't run the tests for 3.2 again, only for 3.4
* For the new tests I used fast.xml instead of jgroups-udp.xml
** The only diff between fast.xml and fast-local/xml shipped with JGroups is that ip_ttl=1

The results for 3.4 are *all* better in the new run than the old run.
                
      was (Author: belaban):
    I got much better perf with JGRP-1716 implemented:

|| type || reads/sec (old) || writes/sec (old) || reads/sec (new) || writes/sec (new) ||
| 32-udp-dontbundle-getall | 28'453 | 9'573 | - | - |
| 34-udp-dontbundle-getall | 25'819 | 8'457 | 26'852 | 11'960 |
| 34-udp-bundle-getall | 27'765 | 9'175 | 34'631 | 15'088 |
| 32-udp-dontbundle-getfirst | 10'764 | 6'301 | - | - |
| 34-udp-dontbundle-getfirst | 15'621 | 3'597 | 15'640 | 4'905 |
| 34-udp-bundle-getfirst | 18'434 | 4'354 | 22'980 | 6'526 |

* I didn't run the tests for 3.2 again, only for 3.4
* For the new tests I used fast.xml instead of jgroups-udp.xml
** The only diff between fast.xml and fast-local/xml shipped with JGroups is that ip_ttl=1
                  
> Regression between 3.2.x and 3.3.x/3.4.x in Infinispan read simulation
> ----------------------------------------------------------------------
>
>                 Key: JGRP-1716
>                 URL: https://issues.jboss.org/browse/JGRP-1716
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.3, 3.4
>            Reporter: Dan Berindei
>            Assignee: Bela Ban
>             Fix For: 3.4.1, 3.5
>
>         Attachments: benchmark-jgroups.xml, jgroups-udp.pdf, jgroups-udp.xml
>
>
> Comparing JGroups 3.2/3.3/3.4 performance with Radargun, the throughput of reads in scenario simulating Infinispan went down by ~10%. See the attached chart.
> * getall: the get request is sent to single node (randomly picked owner)
> * getfirst: the get requests are sent to 2 nodes with ResponseMode.GET_FIRST - the second response is discarded.
> .h5 Suspects:
> Erik Salter profiled his application and noticed that the message parsing in the UDP receiver thread seemed to slow things down. He wrote a patch that brought his throughput back to 3.2 levels: https://github.com/an1310/JGroups/compare/t_perfhack
> The UDP receiver thread may not tell the whole story, however: in the Radargun tests, performance with his patch was even lower.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 19 12:15:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Sat, 19 Oct 2013 12:15:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1716) Regression between 3.2.x and
 3.3.x/3.4.x in Infinispan read simulation
In-Reply-To: <JIRA.12503100.1381850347000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503100.1381850347000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503100.1381850347000.6476.1382199302823@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823320#comment-12823320 ] 

Bela Ban edited comment on JGRP-1716 at 10/19/13 12:13 PM:
-----------------------------------------------------------

I got much better perf with JGRP-1716 implemented:

|| type || reads/sec (old) || writes/sec (old) || reads/sec (new) || writes/sec (new) ||
| 32-udp-dontbundle-getall | 28'453 | 9'573 | - | - |
| 34-udp-dontbundle-getall | 25'819 | 8'457 | *26'852* | *11'960* |
| 34-udp-bundle-getall | 27'765 | 9'175 | *34'631* | *15'088* |
| 32-udp-dontbundle-getfirst | 10'764 | 6'301 | - | - |
| 34-udp-dontbundle-getfirst | 15'621 | 3'597 | *15'640* | *4'905* |
| 34-udp-bundle-getfirst | 18'434 | 4'354 | *22'980* | *6'526* |

* I didn't run the tests for 3.2 again, only for 3.4
* For the new tests I used fast.xml instead of jgroups-udp.xml
** The only diff between fast.xml and fast-local/xml shipped with JGroups is that ip_ttl=1

The results for 3.4 are *all* better in the new run than the old run.
                
      was (Author: belaban):
    I got much better perf with JGRP-1716 implemented:

|| type || reads/sec (old) || writes/sec (old) || reads/sec (new) || writes/sec (new) ||
| 32-udp-dontbundle-getall | 28'453 | 9'573 | - | - |
| 34-udp-dontbundle-getall | 25'819 | 8'457 | 26'852 | 11'960 |
| 34-udp-bundle-getall | 27'765 | 9'175 | 34'631 | 15'088 |
| 32-udp-dontbundle-getfirst | 10'764 | 6'301 | - | - |
| 34-udp-dontbundle-getfirst | 15'621 | 3'597 | 15'640 | 4'905 |
| 34-udp-bundle-getfirst | 18'434 | 4'354 | 22'980 | 6'526 |

* I didn't run the tests for 3.2 again, only for 3.4
* For the new tests I used fast.xml instead of jgroups-udp.xml
** The only diff between fast.xml and fast-local/xml shipped with JGroups is that ip_ttl=1

The results for 3.4 are *all* better in the new run than the old run.
                  
> Regression between 3.2.x and 3.3.x/3.4.x in Infinispan read simulation
> ----------------------------------------------------------------------
>
>                 Key: JGRP-1716
>                 URL: https://issues.jboss.org/browse/JGRP-1716
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.3, 3.4
>            Reporter: Dan Berindei
>            Assignee: Bela Ban
>             Fix For: 3.4.1, 3.5
>
>         Attachments: benchmark-jgroups.xml, jgroups-udp.pdf, jgroups-udp.xml
>
>
> Comparing JGroups 3.2/3.3/3.4 performance with Radargun, the throughput of reads in scenario simulating Infinispan went down by ~10%. See the attached chart.
> * getall: the get request is sent to single node (randomly picked owner)
> * getfirst: the get requests are sent to 2 nodes with ResponseMode.GET_FIRST - the second response is discarded.
> .h5 Suspects:
> Erik Salter profiled his application and noticed that the message parsing in the UDP receiver thread seemed to slow things down. He wrote a patch that brought his throughput back to 3.2 levels: https://github.com/an1310/JGroups/compare/t_perfhack
> The UDP receiver thread may not tell the whole story, however: in the Radargun tests, performance with his patch was even lower.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 19 12:22:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Sat, 19 Oct 2013 12:22:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1716) Regression between 3.2.x and
 3.3.x/3.4.x in Infinispan read simulation
In-Reply-To: <JIRA.12503100.1381850347000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503100.1381850347000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503100.1381850347000.6483.1382199722136@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823320#comment-12823320 ] 

Bela Ban edited comment on JGRP-1716 at 10/19/13 12:20 PM:
-----------------------------------------------------------

I got much better perf with JGRP-1716 implemented:

|| type || reads/sec (old) || writes/sec (old) || reads/sec (new) || writes/sec (new) ||
| 32-udp-dontbundle-getall | 28'453 | 9'573 | - | - |
| 34-udp-dontbundle-getall | 25'819 | 8'457 | *26'852* | *11'960* |
| 34-udp-bundle-getall | 27'765 | 9'175 | *34'631* | *15'088* |
| 32-udp-dontbundle-getfirst | 10'764 | 6'301 | - | - |
| 34-udp-dontbundle-getfirst | 15'621 | 3'597 | *15'640* | *4'905* |
| 34-udp-bundle-getfirst | 18'434 | 4'354 | *22'980* | *6'526* |

* I didn't run the tests for 3.2 again, only for 3.4
* For the new tests I used fast.xml instead of jgroups-udp.xml
** The only diff between fast.xml and fast-local/xml shipped with JGroups is that ip_ttl=1

h5. Findings
* The results for 3.4 are *all* better in the new run than the old 3.4 run
* The non-bundled result in the new 3.4 run are 50% better than the corresponding 3.2 run and 50% worse !
* All of the bundled results in the new 3.4 run are better than the non-bundled results in either the old 3.4 or the 3.2 run !
                
      was (Author: belaban):
    I got much better perf with JGRP-1716 implemented:

|| type || reads/sec (old) || writes/sec (old) || reads/sec (new) || writes/sec (new) ||
| 32-udp-dontbundle-getall | 28'453 | 9'573 | - | - |
| 34-udp-dontbundle-getall | 25'819 | 8'457 | *26'852* | *11'960* |
| 34-udp-bundle-getall | 27'765 | 9'175 | *34'631* | *15'088* |
| 32-udp-dontbundle-getfirst | 10'764 | 6'301 | - | - |
| 34-udp-dontbundle-getfirst | 15'621 | 3'597 | *15'640* | *4'905* |
| 34-udp-bundle-getfirst | 18'434 | 4'354 | *22'980* | *6'526* |

* I didn't run the tests for 3.2 again, only for 3.4
* For the new tests I used fast.xml instead of jgroups-udp.xml
** The only diff between fast.xml and fast-local/xml shipped with JGroups is that ip_ttl=1

The results for 3.4 are *all* better in the new run than the old run.
                  
> Regression between 3.2.x and 3.3.x/3.4.x in Infinispan read simulation
> ----------------------------------------------------------------------
>
>                 Key: JGRP-1716
>                 URL: https://issues.jboss.org/browse/JGRP-1716
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.3, 3.4
>            Reporter: Dan Berindei
>            Assignee: Bela Ban
>             Fix For: 3.4.1, 3.5
>
>         Attachments: benchmark-jgroups.xml, jgroups-udp.pdf, jgroups-udp.xml
>
>
> Comparing JGroups 3.2/3.3/3.4 performance with Radargun, the throughput of reads in scenario simulating Infinispan went down by ~10%. See the attached chart.
> * getall: the get request is sent to single node (randomly picked owner)
> * getfirst: the get requests are sent to 2 nodes with ResponseMode.GET_FIRST - the second response is discarded.
> .h5 Suspects:
> Erik Salter profiled his application and noticed that the message parsing in the UDP receiver thread seemed to slow things down. He wrote a patch that brought his throughput back to 3.2 levels: https://github.com/an1310/JGroups/compare/t_perfhack
> The UDP receiver thread may not tell the whole story, however: in the Radargun tests, performance with his patch was even lower.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 19 12:28:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Sat, 19 Oct 2013 12:28:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1716) Regression between 3.2.x and
 3.3.x/3.4.x in Infinispan read simulation
In-Reply-To: <JIRA.12503100.1381850347000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503100.1381850347000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503100.1381850347000.6486.1382200082008@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823320#comment-12823320 ] 

Bela Ban edited comment on JGRP-1716 at 10/19/13 12:27 PM:
-----------------------------------------------------------

I got much better perf with JGRP-1716 implemented:

|| type || reads/sec (old) || writes/sec (old) || reads/sec (new) || writes/sec (new) ||
| 32-udp-dontbundle-getall | 28'453 | 9'573 | - | - |
| 34-udp-dontbundle-getall | 25'819 | 8'457 | *26'852* | *11'960* |
| 34-udp-bundle-getall | 27'765 | 9'175 | *34'631* | *15'088* |
| 32-udp-dontbundle-getfirst | 10'764 | 6'301 | - | - |
| 34-udp-dontbundle-getfirst | 15'621 | 3'597 | *15'640* | *4'905* |
| 34-udp-bundle-getfirst | 18'434 | 4'354 | *22'980* | *6'526* |

* I didn't run the tests for 3.2 again, only for 3.4
* For the new tests I used fast.xml instead of jgroups-udp.xml
** The only diff between fast.xml and fast-local/xml shipped with JGroups is that ip_ttl=1

h5. Findings
* The results for 3.4 are *all* better in the new run than the old 3.4 run
* The non-bundled result in the new 3.4 run are 50% better than the corresponding 3.2 run and 50% worse !
* All of the bundled results in the new 3.4 run are better than the non-bundled results in either the old 3.4 or the 3.2 run !
** --> If the latter is confirmed by Radim in his own tests, then we should look into abandoning using the DONT_BUNDLE flag. Note that JGRP-1717 is about investigating why using DONT_BUNDLE is faster than not, but the results above indicate the contrary.
                
      was (Author: belaban):
    I got much better perf with JGRP-1716 implemented:

|| type || reads/sec (old) || writes/sec (old) || reads/sec (new) || writes/sec (new) ||
| 32-udp-dontbundle-getall | 28'453 | 9'573 | - | - |
| 34-udp-dontbundle-getall | 25'819 | 8'457 | *26'852* | *11'960* |
| 34-udp-bundle-getall | 27'765 | 9'175 | *34'631* | *15'088* |
| 32-udp-dontbundle-getfirst | 10'764 | 6'301 | - | - |
| 34-udp-dontbundle-getfirst | 15'621 | 3'597 | *15'640* | *4'905* |
| 34-udp-bundle-getfirst | 18'434 | 4'354 | *22'980* | *6'526* |

* I didn't run the tests for 3.2 again, only for 3.4
* For the new tests I used fast.xml instead of jgroups-udp.xml
** The only diff between fast.xml and fast-local/xml shipped with JGroups is that ip_ttl=1

h5. Findings
* The results for 3.4 are *all* better in the new run than the old 3.4 run
* The non-bundled result in the new 3.4 run are 50% better than the corresponding 3.2 run and 50% worse !
* All of the bundled results in the new 3.4 run are better than the non-bundled results in either the old 3.4 or the 3.2 run !
                  
> Regression between 3.2.x and 3.3.x/3.4.x in Infinispan read simulation
> ----------------------------------------------------------------------
>
>                 Key: JGRP-1716
>                 URL: https://issues.jboss.org/browse/JGRP-1716
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.3, 3.4
>            Reporter: Dan Berindei
>            Assignee: Bela Ban
>             Fix For: 3.4.1, 3.5
>
>         Attachments: benchmark-jgroups.xml, jgroups-udp.pdf, jgroups-udp.xml
>
>
> Comparing JGroups 3.2/3.3/3.4 performance with Radargun, the throughput of reads in scenario simulating Infinispan went down by ~10%. See the attached chart.
> * getall: the get request is sent to single node (randomly picked owner)
> * getfirst: the get requests are sent to 2 nodes with ResponseMode.GET_FIRST - the second response is discarded.
> .h5 Suspects:
> Erik Salter profiled his application and noticed that the message parsing in the UDP receiver thread seemed to slow things down. He wrote a patch that brought his throughput back to 3.2 levels: https://github.com/an1310/JGroups/compare/t_perfhack
> The UDP receiver thread may not tell the whole story, however: in the Radargun tests, performance with his patch was even lower.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 19 14:56:02 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Sat, 19 Oct 2013 14:56:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2341) WildFly-8.0.0.Beta1 throws an
 exception during persistence unit starting on java 1.8.0-ea-b111
In-Reply-To: <JIRA.12508227.1382181208000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508227.1382181208000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508227.1382181208000.6509.1382208962024@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823324#comment-12823324 ] 

Scott Marlow commented on WFLY-2341:
------------------------------------

I'm not sure when the Hibernate project will work on compiling with Java 8 but maybe you could offer to help fix the compile errors as a first step.

The Hibernate development mailing list can be joined via https://lists.jboss.org/mailman/listinfo/hibernate-dev, if your interested in collaborating with others on getting past the build error.  The "org.gradle.api.internal.tasks.compile.CompilationFailedException" error is a gradle error, so not sure if that is a known issue or not.  There could be some gradle work involved.  

>From the JDK 8 point of view, does the runtime problem occur because of a JDK bug or a JDK design change?  This question will be good to also ask on the hibernate-dev mailing list with regard to org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator on Java 8.

Thanks for taking an early interest in Java 8 + WildFly 8!
                
> WildFly-8.0.0.Beta1 throws an exception during persistence unit starting on java 1.8.0-ea-b111
> ----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2341
>                 URL: https://issues.jboss.org/browse/WFLY-2341
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Beta1
>         Environment: % java -version
> java version "1.8.0-ea"
> Java(TM) SE Runtime Environment (build 1.8.0-ea-b111)
> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b53, mixed mode)
> % uname -a
> Linux irtysh.kostousov.net 3.11.1-200.fc19.x86_64 #1 SMP Sat Sep 14 15:04:51 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
>            Reporter: Denis Kostousov
>            Assignee: Scott Marlow
>            Priority: Critical
>         Attachments: hibernate.HEAD.build.log
>
>
> An exception occurs during application deploying on Wildfly 8.0.0.Beta1 after jdk was changed from 1.8.0-ea-b109 to 1.8.0-ea-b111. On 1.8.0-ea-b109 same code works fine.
> {code}
> 2013-10-19 16:52:49,975 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 52) MSC000001: Failed to start service jboss.persistenceunit."acquiring-gate-ear-0.5-SNAPSHOT.ear/server-0.5-SNAPSHOT.war#AGDirectory": org.jboss.msc.service.StartException in service jboss.persistenceunit."acquiring-gate-ear-0.5-SNAPSHOT.ear/server-0.5-SNAPSHOT.war#AGDirectory": java.lang.IllegalAccessError: tried to access method java.lang.Object.clone()Ljava/lang/Object; from class org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:169) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0-ea]
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:463) [wildfly-security-manager-1.0.0.Beta3.jar:1.0.0.Beta3]
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:178) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0-ea]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0-ea]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.8.0-ea]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: java.lang.IllegalAccessError: tried to access method java.lang.Object.clone()Ljava/lang/Object; from class org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator
> 	at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.cloneAndSetupRevisionInfoRelationMapping(AuditMetadataGenerator.java:140)
> 	at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.addRevisionInfoRelation(AuditMetadataGenerator.java:152)
> 	at org.hibernate.envers.configuration.internal.metadata.IdMetadataGenerator.addId(IdMetadataGenerator.java:210)
> 	at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.generateFirstPass(AuditMetadataGenerator.java:561)
> 	at org.hibernate.envers.configuration.internal.EntitiesConfigurator.configure(EntitiesConfigurator.java:110)
> 	at org.hibernate.envers.configuration.spi.AuditConfiguration.<init>(AuditConfiguration.java:130)
> 	at org.hibernate.envers.configuration.spi.AuditConfiguration.getFor(AuditConfiguration.java:180)
> 	at org.hibernate.envers.event.spi.EnversIntegrator.integrate(EnversIntegrator.java:76)
> 	at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:310)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1837)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:854)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:847)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:396)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:846)
> 	at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:151) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	... 8 more
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 19 15:58:02 2013
From: jira-events at lists.jboss.org (=?UTF-8?Q?Dojcs=C3=A1k_S=C3=A1ndor_=28JIRA=29?=)
Date: Sat, 19 Oct 2013 15:58:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBASMP-54) Maven phase executing twice
In-Reply-To: <JIRA.12508235.1382212598140@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508235.1382212598140@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508235.1382212598140.6530.1382212682117@jira02.app.mwc.hst.phx2.redhat.com>

Dojcs?k S?ndor created JBASMP-54:
------------------------------------

             Summary: Maven phase executing twice
                 Key: JBASMP-54
                 URL: https://issues.jboss.org/browse/JBASMP-54
             Project: JBoss AS Maven Plugins
          Issue Type: Bug
            Reporter: Dojcs?k S?ndor
            Assignee: James Perkins


I attached deploy goal to the package lifecycle phase.
When I run mvn package it works fine, but I noticed that all phase executes twice.
I removed @Execute(phase = LifecyclePhase.PACKAGE) line from Deploy.java. This solved the problem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Sat Oct 19 16:12:02 2013
From: jira-events at lists.jboss.org (=?UTF-8?Q?Dojcs=C3=A1k_S=C3=A1ndor_=28JIRA=29?=)
Date: Sat, 19 Oct 2013 16:12:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBASMP-55) Undeploy requires dependency
 resolution of artifacts in scope: runtime
In-Reply-To: <JIRA.12508236.1382213434703@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508236.1382213434703@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508236.1382213434703.6533.1382213522069@jira02.app.mwc.hst.phx2.redhat.com>

Dojcs?k S?ndor created JBASMP-55:
------------------------------------

             Summary: Undeploy requires dependency resolution of artifacts in scope: runtime
                 Key: JBASMP-55
                 URL: https://issues.jboss.org/browse/JBASMP-55
             Project: JBoss AS Maven Plugins
          Issue Type: Bug
            Reporter: Dojcs?k S?ndor
            Assignee: James Perkins


I attached deploy goal to the clean lifecycle phase. I changed resolution scope in Undeploy.java to ResolutionScope.NONE. After I do not require mvn install for dependency resolution before I run clean.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Sat Oct 19 17:05:02 2013
From: jira-events at lists.jboss.org (Ondrej Zizka (JIRA))
Date: Sat, 19 Oct 2013 17:05:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (AS7-6072) Automate creating EAP 6.x
 public API Javadoc
In-Reply-To: <JIRA.12477281.1350542782000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12477281.1350542782000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12477281.1350542782000.6540.1382216702218@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-6072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823326#comment-12823326 ] 

Ondrej Zizka commented on AS7-6072:
-----------------------------------

David Lloyd:

Guys, when developing an API that is going to be shipped either as part 
of WildFly as a module or for end-user consumption, I want you to 
remember something:

Every public and protected member of that module *IS* API.  That means 
you can't ever change it without considering compatibility.  "Well I 
just made it public because this other module needs access to it" is not 
a valid excuse, nor is "Well I needed access from another package". 
Both are synonyms for "I screwed up my design at an early stage and now 
I want to break the rules to fix my mistake".

The only exception is if you're developing a component specifically and 
exclusively for use in the modular environment, and you put all non-API 
public members into a specific package or package set which is then 
excluded from export in the module.xml descriptor in the shipped 
environment.

If you do not fall into this exception then you are volunteering to 
personally maintain these non-public public classes for the next 10 
years come hell or high water, because people are surely going to use 
them, and I sure don't want to be the one to maintain them.

http://lists.jboss.org/pipermail/wildfly-dev/2013-October/000949.html
                
> Automate creating EAP 6.x public API Javadoc
> --------------------------------------------
>
>                 Key: AS7-6072
>                 URL: https://issues.jboss.org/browse/AS7-6072
>             Project: Application Server 7
>          Issue Type: Enhancement
>          Components: Build System, Documentation
>    Affects Versions: 7.1.3.Final (EAP)
>            Reporter: Ondrej Zizka
>            Assignee: Ondrej Zizka
>             Fix For: EAP 6.1.0.Alpha (7.2.0.Final)
>
>
> Docspace page: https://docspace.corp.redhat.com/docs/DOC-134981
> First attempt: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/EAP6-javadoc/
> What's needed:
> * Blacklist of skipped .jar's (cause exceptions when generating)
> * XSLT to put <include>'s to pom.xml
> * XSLT to put <groups> to pom.xml
> See also https://docspace.corp.redhat.com/docs/DOC-105009 (bottom)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 19 22:56:01 2013
From: jira-events at lists.jboss.org (huanghwh (JIRA))
Date: Sat, 19 Oct 2013 22:56:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2343) IllegalStateException when
 invoking ManagedThreadFactory.newThread
In-Reply-To: <JIRA.12508243.1382237712731@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508243.1382237712731@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508243.1382237712731.6577.1382237761972@jira02.app.mwc.hst.phx2.redhat.com>

huanghwh created WFLY-2343:
------------------------------

             Summary: IllegalStateException when invoking ManagedThreadFactory.newThread
                 Key: WFLY-2343
                 URL: https://issues.jboss.org/browse/WFLY-2343
             Project: WildFly
          Issue Type: Bug
          Components: EE
    Affects Versions: 8.0.0.Beta1
         Environment: #uname -a
FreeBSD mbp.gddsn.org.cn 9.2-STABLE FreeBSD 9.2-STABLE #22 r256314: Sat Oct 12 01:53:39 CST 2013     root at mbp.gddsn.org.cn:/usr/obj/usr/src/sys/MACBOOK  amd64
# /usr/local/openjdk7/bin/java -version
openjdk version "1.7.0_25"
OpenJDK Runtime Environment (build 1.7.0_25-b15)
OpenJDK 64-Bit Server VM (build 23.21-b01, mixed mode)

            Reporter: huanghwh
            Assignee: David Lloyd


I test the simple test case under wildfly beta2, and got the stacktrace below.
@Singleton
@Startup
public class SSSManagerBean{
  static Logger logger = Logger.getLogger(SSSManagerBean.class);
  
  @Resource
  private ManagedThreadFactory mtf;

  public SSSManagerBean() {
  }

  @PostConstruct
  public void postConstruct() {
    logger.info("XXXXXXXXXXXXXXXXXXXXXXXXXX: "+mtf);
    Thread t = mtf.newThread(new Runnable(){
      @Override
      public void run(){
        logger.info("XXXXXXXXXXXXXXXX: hello");
      }
    });
    t.start();
  }
}

The stacktrace:

Caused by: java.lang.IllegalStateException: JBAS016707: No concurrent context currently set, unable to locate the context service to delegate.
	at org.jboss.as.ee.concurrent.DefaultContextSetupProviderImpl.getConcurrentContext(DefaultContextSetupProviderImpl.java:41) [wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	at org.jboss.as.ee.concurrent.DefaultContextSetupProviderImpl.saveContext(DefaultContextSetupProviderImpl.java:48) [wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	at org.glassfish.enterprise.concurrent.ManagedThreadFactoryImpl.newThread(ManagedThreadFactoryImpl.java:125)
	at cn.org.gddsn.sss.server.SSSManagerBean.postConstruct(SSSManagerBean.java:91)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_25]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_25]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_25]
	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_25]
	at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptorFactory$ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptorFactory.java:130) [wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doLifecycleInterception(Jsr299BindingsInterceptor.java:165) [wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:148) [wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:55) [weld-core-impl-2.1.0.CR1.jar:2013-09-26 16:53]
	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:56) [wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:115) [wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:115) [wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28) [wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:62) [wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) [wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:273)
	... 27 more


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 19 23:00:01 2013
From: jira-events at lists.jboss.org (huanghwh (JIRA))
Date: Sat, 19 Oct 2013 23:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2343) IllegalStateException when
 invoking ManagedThreadFactory.newThread
In-Reply-To: <JIRA.12508243.1382237712000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508243.1382237712000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508243.1382237712000.6580.1382238001894@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

huanghwh updated WFLY-2343:
---------------------------

    Description: 
I test the simple test case under wildfly beta2, and got the stacktrace below,
Remove @Startup, the test case is pass.


@Singleton
@Startup
public class SSSManagerBean{
  static Logger logger = Logger.getLogger(SSSManagerBean.class);
  
  @Resource
  private ManagedThreadFactory mtf;

  public SSSManagerBean() {
  }

  @PostConstruct
  public void postConstruct() {
    logger.info("XXXXXXXXXXXXXXXXXXXXXXXXXX: "+mtf);
    Thread t = mtf.newThread(new Runnable(){
      @Override
      public void run(){
        logger.info("XXXXXXXXXXXXXXXX: hello");
      }
    });
    t.start();
  }
}

The stacktrace:

Caused by: java.lang.IllegalStateException: JBAS016707: No concurrent context currently set, unable to locate the context service to delegate.
	at org.jboss.as.ee.concurrent.DefaultContextSetupProviderImpl.getConcurrentContext(DefaultContextSetupProviderImpl.java:41) [wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	at org.jboss.as.ee.concurrent.DefaultContextSetupProviderImpl.saveContext(DefaultContextSetupProviderImpl.java:48) [wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	at org.glassfish.enterprise.concurrent.ManagedThreadFactoryImpl.newThread(ManagedThreadFactoryImpl.java:125)
	at cn.org.gddsn.sss.server.SSSManagerBean.postConstruct(SSSManagerBean.java:91)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_25]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_25]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_25]
	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_25]
	at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptorFactory$ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptorFactory.java:130) [wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doLifecycleInterception(Jsr299BindingsInterceptor.java:165) [wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:148) [wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:55) [weld-core-impl-2.1.0.CR1.jar:2013-09-26 16:53]
	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:56) [wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:115) [wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:115) [wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28) [wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:62) [wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) [wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:273)
	... 27 more


  was:
I test the simple test case under wildfly beta2, and got the stacktrace below.
@Singleton
@Startup
public class SSSManagerBean{
  static Logger logger = Logger.getLogger(SSSManagerBean.class);
  
  @Resource
  private ManagedThreadFactory mtf;

  public SSSManagerBean() {
  }

  @PostConstruct
  public void postConstruct() {
    logger.info("XXXXXXXXXXXXXXXXXXXXXXXXXX: "+mtf);
    Thread t = mtf.newThread(new Runnable(){
      @Override
      public void run(){
        logger.info("XXXXXXXXXXXXXXXX: hello");
      }
    });
    t.start();
  }
}

The stacktrace:

Caused by: java.lang.IllegalStateException: JBAS016707: No concurrent context currently set, unable to locate the context service to delegate.
	at org.jboss.as.ee.concurrent.DefaultContextSetupProviderImpl.getConcurrentContext(DefaultContextSetupProviderImpl.java:41) [wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	at org.jboss.as.ee.concurrent.DefaultContextSetupProviderImpl.saveContext(DefaultContextSetupProviderImpl.java:48) [wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	at org.glassfish.enterprise.concurrent.ManagedThreadFactoryImpl.newThread(ManagedThreadFactoryImpl.java:125)
	at cn.org.gddsn.sss.server.SSSManagerBean.postConstruct(SSSManagerBean.java:91)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_25]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_25]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_25]
	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_25]
	at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptorFactory$ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptorFactory.java:130) [wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doLifecycleInterception(Jsr299BindingsInterceptor.java:165) [wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:148) [wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:55) [weld-core-impl-2.1.0.CR1.jar:2013-09-26 16:53]
	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:56) [wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:115) [wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:115) [wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28) [wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:62) [wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) [wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:273)
	... 27 more



    
> IllegalStateException when invoking ManagedThreadFactory.newThread
> ------------------------------------------------------------------
>
>                 Key: WFLY-2343
>                 URL: https://issues.jboss.org/browse/WFLY-2343
>             Project: WildFly
>          Issue Type: Bug
>          Components: EE
>    Affects Versions: 8.0.0.Beta1
>         Environment: #uname -a
> FreeBSD mbp.gddsn.org.cn 9.2-STABLE FreeBSD 9.2-STABLE #22 r256314: Sat Oct 12 01:53:39 CST 2013     root at mbp.gddsn.org.cn:/usr/obj/usr/src/sys/MACBOOK  amd64
> # /usr/local/openjdk7/bin/java -version
> openjdk version "1.7.0_25"
> OpenJDK Runtime Environment (build 1.7.0_25-b15)
> OpenJDK 64-Bit Server VM (build 23.21-b01, mixed mode)
>            Reporter: huanghwh
>            Assignee: David Lloyd
>
> I test the simple test case under wildfly beta2, and got the stacktrace below,
> Remove @Startup, the test case is pass.
> @Singleton
> @Startup
> public class SSSManagerBean{
>   static Logger logger = Logger.getLogger(SSSManagerBean.class);
>   
>   @Resource
>   private ManagedThreadFactory mtf;
>   public SSSManagerBean() {
>   }
>   @PostConstruct
>   public void postConstruct() {
>     logger.info("XXXXXXXXXXXXXXXXXXXXXXXXXX: "+mtf);
>     Thread t = mtf.newThread(new Runnable(){
>       @Override
>       public void run(){
>         logger.info("XXXXXXXXXXXXXXXX: hello");
>       }
>     });
>     t.start();
>   }
> }
> The stacktrace:
> Caused by: java.lang.IllegalStateException: JBAS016707: No concurrent context currently set, unable to locate the context service to delegate.
> 	at org.jboss.as.ee.concurrent.DefaultContextSetupProviderImpl.getConcurrentContext(DefaultContextSetupProviderImpl.java:41) [wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.as.ee.concurrent.DefaultContextSetupProviderImpl.saveContext(DefaultContextSetupProviderImpl.java:48) [wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.glassfish.enterprise.concurrent.ManagedThreadFactoryImpl.newThread(ManagedThreadFactoryImpl.java:125)
> 	at cn.org.gddsn.sss.server.SSSManagerBean.postConstruct(SSSManagerBean.java:91)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_25]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_25]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_25]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_25]
> 	at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptorFactory$ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptorFactory.java:130) [wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doLifecycleInterception(Jsr299BindingsInterceptor.java:165) [wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:148) [wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:55) [weld-core-impl-2.1.0.CR1.jar:2013-09-26 16:53]
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:56) [wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:115) [wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:115) [wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28) [wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:62) [wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) [wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:273)
> 	... 27 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Oct 20 01:53:01 2013
From: jira-events at lists.jboss.org (miguel deanda (JIRA))
Date: Sun, 20 Oct 2013 01:53:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2344) undertow claims already
	registered
In-Reply-To: <JIRA.12508247.1382248265295@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508247.1382248265295@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508247.1382248265295.6583.1382248381954@jira02.app.mwc.hst.phx2.redhat.com>

miguel deanda created WFLY-2344:
-----------------------------------

             Summary: undertow claims already registered
                 Key: WFLY-2344
                 URL: https://issues.jboss.org/browse/WFLY-2344
             Project: WildFly
          Issue Type: Bug
    Affects Versions: 8.0.0.Beta1
            Reporter: miguel deanda


I've downloaded wildfly beta, attempted to add a vhost using the undertow configuration (can't find documentation btw) but when it starts, it says:

org.jboss.msc.service.DuplicateServiceException: Service jboss.web.common.host./ is already registered 

I originally posted the question here:
https://community.jboss.org/message/842352

The relevant config section (standalone.xml) is the following:

<subsystem xmlns="urn:jboss:domain:undertow:1.0">
	<buffer-caches>
		<buffer-cache name="default" buffer-size="1024" buffers-per-region="1024" max-regions="10"/>
	</buffer-caches>
	<server name="default-server">
		<http-listener name="default" socket-binding="http" max-post-size="10485760"/>
		<host name="default-host" alias="localhost">
			<location name="/" handler="welcome-content"/>
		</host>
		<host name="other-host" alias="www.mysite.com" default-web-module="something.war">
			<location name="/" handler="welcome-content">
				<filter-ref name="connection-limit"/>
			</location>
		</host>
	</server>
	<servlet-container name="default" default-buffer-cache="default" stack-trace-on-error="local-only">
		<jsp-config/>
		<persistent-sessions path="persistent-web-sessions" relative-to="jboss.server.data.dir"/>
	</servlet-container>
	<handlers>
		<file name="welcome-content" path="${jboss.home.dir}/welcome-content" directory-listing="true"/>
	</handlers>
</subsystem>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Oct 20 01:53:02 2013
From: jira-events at lists.jboss.org (miguel deanda (JIRA))
Date: Sun, 20 Oct 2013 01:53:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2344) undertow claims already
	registered
In-Reply-To: <JIRA.12508247.1382248265000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508247.1382248265000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508247.1382248265000.6584.1382248382006@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823335#comment-12823335 ] 

miguel deanda commented on WFLY-2344:
-------------------------------------

the error looks like this: (lines might be missing as copying colors lines didn't work on my terminal)

11:29:36,171 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 49) JBAS014612: Operation ("add") failed - address: ([
    ("subsystem" => "undertow"),                                                                                                                                                     
    ("server" => "default-server"),                                                                                                                                                  
    ("host" => "other-host"),                                                                                                                                                        
    ("location" => "/")                                                                                                                                                              
]): org.jboss.msc.service.DuplicateServiceException: Service jboss.web.common.host./ is already registered                                                                           
        at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
        at org.jboss.as.controller.OperationContextImpl$ContextServiceBuilder.install(OperationContextImpl.java:1422) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
        at org.wildfly.extension.undertow.LocationAdd.performRuntime(LocationAdd.java:84)
        at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:75) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
        at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:609) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
        at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:487) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
        at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
        at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1.jar:8.0.0.Beta1]
                
> undertow claims already registered
> ----------------------------------
>
>                 Key: WFLY-2344
>                 URL: https://issues.jboss.org/browse/WFLY-2344
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Beta1
>            Reporter: miguel deanda
>
> I've downloaded wildfly beta, attempted to add a vhost using the undertow configuration (can't find documentation btw) but when it starts, it says:
> org.jboss.msc.service.DuplicateServiceException: Service jboss.web.common.host./ is already registered 
> I originally posted the question here:
> https://community.jboss.org/message/842352
> The relevant config section (standalone.xml) is the following:
> <subsystem xmlns="urn:jboss:domain:undertow:1.0">
> 	<buffer-caches>
> 		<buffer-cache name="default" buffer-size="1024" buffers-per-region="1024" max-regions="10"/>
> 	</buffer-caches>
> 	<server name="default-server">
> 		<http-listener name="default" socket-binding="http" max-post-size="10485760"/>
> 		<host name="default-host" alias="localhost">
> 			<location name="/" handler="welcome-content"/>
> 		</host>
> 		<host name="other-host" alias="www.mysite.com" default-web-module="something.war">
> 			<location name="/" handler="welcome-content">
> 				<filter-ref name="connection-limit"/>
> 			</location>
> 		</host>
> 	</server>
> 	<servlet-container name="default" default-buffer-cache="default" stack-trace-on-error="local-only">
> 		<jsp-config/>
> 		<persistent-sessions path="persistent-web-sessions" relative-to="jboss.server.data.dir"/>
> 	</servlet-container>
> 	<handlers>
> 		<file name="welcome-content" path="${jboss.home.dir}/welcome-content" directory-listing="true"/>
> 	</handlers>
> </subsystem>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Oct 20 02:49:01 2013
From: jira-events at lists.jboss.org (chandra shekhar joshi (JIRA))
Date: Sun, 20 Oct 2013 02:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBBUILD-732) Lock Exception
In-Reply-To: <JIRA.12508248.1382251736997@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508248.1382251736997@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508248.1382251736997.6588.1382251741945@jira02.app.mwc.hst.phx2.redhat.com>

chandra shekhar joshi created JBBUILD-732:
---------------------------------------------

             Summary: Lock Exception
                 Key: JBBUILD-732
                 URL: https://issues.jboss.org/browse/JBBUILD-732
             Project: JBoss Build System
          Issue Type: Bug
          Components: JBoss Parent POM
    Affects Versions: JBoss Parent POM - 9
         Environment: Windows
            Reporter: chandra shekhar joshi
            Assignee: Paul Gier


java.sql.SQLException: Unable to obtain lock in 60 seconds
Caused by: java.sql.SQLException: Unable to obtain lock in 60 seconds: org.jboss.resource.adapter.jdbc.xa.XAManagedConnection at 1d314d
    at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.tryLock(BaseWrapperManagedConnection.java:267)
    at org.jboss.resource.adapter.jdbc.WrappedConnection.lock(WrappedConnection.java:79)
    at org.jboss.resource.adapter.jdbc.WrappedConnection.prepareStatement(WrappedConnection.java:237)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Oct 20 06:37:02 2013
From: jira-events at lists.jboss.org (Philippe Marschall (JIRA))
Date: Sun, 20 Oct 2013 06:37:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2345) Port offset 0 does not work
In-Reply-To: <JIRA.12508250.1382265308013@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508250.1382265308013@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508250.1382265308013.6592.1382265422036@jira02.app.mwc.hst.phx2.redhat.com>

Philippe Marschall created WFLY-2345:
----------------------------------------

             Summary: Port offset 0 does not work
                 Key: WFLY-2345
                 URL: https://issues.jboss.org/browse/WFLY-2345
             Project: WildFly
          Issue Type: Bug
          Components: Server
    Affects Versions: 8.0.0.Beta1
            Reporter: Philippe Marschall
            Assignee: Jason Greene


When a port offset is specified in the socket binding group and the socket binding has a port of 0, then the port offset is not used to calculate the port instead port 0 is bound.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Oct 20 10:20:02 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Sun, 20 Oct 2013 10:20:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2343) IllegalStateException when
 invoking ManagedThreadFactory.newThread
In-Reply-To: <JIRA.12508243.1382237712000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508243.1382237712000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508243.1382237712000.6600.1382278802128@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd updated WFLY-2343:
------------------------------

                Assignee: Eduardo Martins  (was: David Lloyd)
    Estimated Difficulty: Low

    
> IllegalStateException when invoking ManagedThreadFactory.newThread
> ------------------------------------------------------------------
>
>                 Key: WFLY-2343
>                 URL: https://issues.jboss.org/browse/WFLY-2343
>             Project: WildFly
>          Issue Type: Bug
>          Components: EE
>    Affects Versions: 8.0.0.Beta1
>         Environment: #uname -a
> FreeBSD mbp.gddsn.org.cn 9.2-STABLE FreeBSD 9.2-STABLE #22 r256314: Sat Oct 12 01:53:39 CST 2013     root at mbp.gddsn.org.cn:/usr/obj/usr/src/sys/MACBOOK  amd64
> # /usr/local/openjdk7/bin/java -version
> openjdk version "1.7.0_25"
> OpenJDK Runtime Environment (build 1.7.0_25-b15)
> OpenJDK 64-Bit Server VM (build 23.21-b01, mixed mode)
>            Reporter: huanghwh
>            Assignee: Eduardo Martins
>
> I test the simple test case under wildfly beta2, and got the stacktrace below,
> Remove @Startup, the test case is pass.
> @Singleton
> @Startup
> public class SSSManagerBean{
>   static Logger logger = Logger.getLogger(SSSManagerBean.class);
>   
>   @Resource
>   private ManagedThreadFactory mtf;
>   public SSSManagerBean() {
>   }
>   @PostConstruct
>   public void postConstruct() {
>     logger.info("XXXXXXXXXXXXXXXXXXXXXXXXXX: "+mtf);
>     Thread t = mtf.newThread(new Runnable(){
>       @Override
>       public void run(){
>         logger.info("XXXXXXXXXXXXXXXX: hello");
>       }
>     });
>     t.start();
>   }
> }
> The stacktrace:
> Caused by: java.lang.IllegalStateException: JBAS016707: No concurrent context currently set, unable to locate the context service to delegate.
> 	at org.jboss.as.ee.concurrent.DefaultContextSetupProviderImpl.getConcurrentContext(DefaultContextSetupProviderImpl.java:41) [wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.as.ee.concurrent.DefaultContextSetupProviderImpl.saveContext(DefaultContextSetupProviderImpl.java:48) [wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.glassfish.enterprise.concurrent.ManagedThreadFactoryImpl.newThread(ManagedThreadFactoryImpl.java:125)
> 	at cn.org.gddsn.sss.server.SSSManagerBean.postConstruct(SSSManagerBean.java:91)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_25]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_25]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_25]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_25]
> 	at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptorFactory$ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptorFactory.java:130) [wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doLifecycleInterception(Jsr299BindingsInterceptor.java:165) [wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:148) [wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:55) [weld-core-impl-2.1.0.CR1.jar:2013-09-26 16:53]
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:56) [wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:115) [wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:115) [wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28) [wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:62) [wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) [wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:273)
> 	... 27 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Oct 20 10:22:02 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Sun, 20 Oct 2013 10:22:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2343) IllegalStateException when
 invoking ManagedThreadFactory.newThread
In-Reply-To: <JIRA.12508243.1382237712000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508243.1382237712000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508243.1382237712000.6603.1382278922021@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823338#comment-12823338 ] 

David Lloyd commented on WFLY-2343:
-----------------------------------

Looks like maybe interceptors don't have the right context set up all the time.
                
> IllegalStateException when invoking ManagedThreadFactory.newThread
> ------------------------------------------------------------------
>
>                 Key: WFLY-2343
>                 URL: https://issues.jboss.org/browse/WFLY-2343
>             Project: WildFly
>          Issue Type: Bug
>          Components: EE
>    Affects Versions: 8.0.0.Beta1
>         Environment: #uname -a
> FreeBSD mbp.gddsn.org.cn 9.2-STABLE FreeBSD 9.2-STABLE #22 r256314: Sat Oct 12 01:53:39 CST 2013     root at mbp.gddsn.org.cn:/usr/obj/usr/src/sys/MACBOOK  amd64
> # /usr/local/openjdk7/bin/java -version
> openjdk version "1.7.0_25"
> OpenJDK Runtime Environment (build 1.7.0_25-b15)
> OpenJDK 64-Bit Server VM (build 23.21-b01, mixed mode)
>            Reporter: huanghwh
>            Assignee: Eduardo Martins
>
> I test the simple test case under wildfly beta2, and got the stacktrace below,
> Remove @Startup, the test case is pass.
> @Singleton
> @Startup
> public class SSSManagerBean{
>   static Logger logger = Logger.getLogger(SSSManagerBean.class);
>   
>   @Resource
>   private ManagedThreadFactory mtf;
>   public SSSManagerBean() {
>   }
>   @PostConstruct
>   public void postConstruct() {
>     logger.info("XXXXXXXXXXXXXXXXXXXXXXXXXX: "+mtf);
>     Thread t = mtf.newThread(new Runnable(){
>       @Override
>       public void run(){
>         logger.info("XXXXXXXXXXXXXXXX: hello");
>       }
>     });
>     t.start();
>   }
> }
> The stacktrace:
> Caused by: java.lang.IllegalStateException: JBAS016707: No concurrent context currently set, unable to locate the context service to delegate.
> 	at org.jboss.as.ee.concurrent.DefaultContextSetupProviderImpl.getConcurrentContext(DefaultContextSetupProviderImpl.java:41) [wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.as.ee.concurrent.DefaultContextSetupProviderImpl.saveContext(DefaultContextSetupProviderImpl.java:48) [wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.glassfish.enterprise.concurrent.ManagedThreadFactoryImpl.newThread(ManagedThreadFactoryImpl.java:125)
> 	at cn.org.gddsn.sss.server.SSSManagerBean.postConstruct(SSSManagerBean.java:91)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_25]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_25]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_25]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_25]
> 	at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptorFactory$ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptorFactory.java:130) [wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doLifecycleInterception(Jsr299BindingsInterceptor.java:165) [wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:148) [wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:55) [weld-core-impl-2.1.0.CR1.jar:2013-09-26 16:53]
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:56) [wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:115) [wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:115) [wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28) [wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:62) [wildfly-weld-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) [wildfly-ee-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:273)
> 	... 27 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 04:33:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Mon, 21 Oct 2013 04:33:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2324) Deployment overlays do not
 replace JSP files
In-Reply-To: <JIRA.12504081.1381994090000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12504081.1381994090000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12504081.1381994090000.7152.1382344382495@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-2324.
----------------------------------

    Resolution: Done

    
> Deployment overlays do not replace JSP files
> --------------------------------------------
>
>                 Key: WFLY-2324
>                 URL: https://issues.jboss.org/browse/WFLY-2324
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 05:14:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 21 Oct 2013 05:14:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1341) Missing charset-related paths
	from sun.jdk
In-Reply-To: <JIRA.12491807.1368584295000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12491807.1368584295000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12491807.1368584295000.7501.1382346842222@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823434#comment-12823434 ] 

RH Bugzilla Integration commented on WFLY-1341:
-----------------------------------------------

Ladislav Thon <lthon at redhat.com> changed the Status of [bug 959478|https://bugzilla.redhat.com/show_bug.cgi?id=959478] from ON_QA to VERIFIED
                
> Missing charset-related paths from sun.jdk
> ------------------------------------------
>
>                 Key: WFLY-1341
>                 URL: https://issues.jboss.org/browse/WFLY-1341
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Brad Maxwell
>            Assignee: David Lloyd
>             Fix For: 8.0.0.Alpha1
>
>
> The sun.jdk module needs the sun.nio.ext and sun.nio.cs packages to load charsets from application code properly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 05:14:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 21 Oct 2013 05:14:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1341) Missing charset-related paths
	from sun.jdk
In-Reply-To: <JIRA.12491807.1368584295000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12491807.1368584295000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12491807.1368584295000.7504.1382346842390@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823435#comment-12823435 ] 

RH Bugzilla Integration commented on WFLY-1341:
-----------------------------------------------

Ladislav Thon <lthon at redhat.com> made a comment on [bug 959478|https://bugzilla.redhat.com/show_bug.cgi?id=959478]

Verified with EAP 6.2.0.ER6.
                
> Missing charset-related paths from sun.jdk
> ------------------------------------------
>
>                 Key: WFLY-1341
>                 URL: https://issues.jboss.org/browse/WFLY-1341
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Brad Maxwell
>            Assignee: David Lloyd
>             Fix For: 8.0.0.Alpha1
>
>
> The sun.jdk module needs the sun.nio.ext and sun.nio.cs packages to load charsets from application code properly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 05:34:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 21 Oct 2013 05:34:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1487) Unable to read nested
 resource in WAR archive
In-Reply-To: <JIRA.12493917.1370849764000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493917.1370849764000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493917.1370849764000.7561.1382348042216@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823442#comment-12823442 ] 

RH Bugzilla Integration commented on WFLY-1487:
-----------------------------------------------

Ladislav Thon <lthon at redhat.com> made a comment on [bug 1017282|https://bugzilla.redhat.com/show_bug.cgi?id=1017282]

Verified with EAP 6.2.0.ER6.
                
> Unable to read nested resource in WAR archive
> ---------------------------------------------
>
>                 Key: WFLY-1487
>                 URL: https://issues.jboss.org/browse/WFLY-1487
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (JBoss Web), Web (Undertow)
>            Reporter: Radim Hatlapatka
>            Assignee: David Lloyd
>             Fix For: 8.0.0.Alpha2
>
>
> Unable to retrieve resources which are nested in additional directory in META-INF. The same works for JAR, only for WAR archive it doesn't.
> Example:
> If in WAR archive I have a resource in META-INF/properties/nested.properties, I am unable to access it using
> {code}
> classLoader.getResource("META-INF/properties/nested.properties");
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 05:34:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 21 Oct 2013 05:34:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1487) Unable to read nested
 resource in WAR archive
In-Reply-To: <JIRA.12493917.1370849764000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493917.1370849764000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493917.1370849764000.7564.1382348042316@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823443#comment-12823443 ] 

RH Bugzilla Integration commented on WFLY-1487:
-----------------------------------------------

Ladislav Thon <lthon at redhat.com> changed the Status of [bug 1017282|https://bugzilla.redhat.com/show_bug.cgi?id=1017282] from ON_QA to VERIFIED
                
> Unable to read nested resource in WAR archive
> ---------------------------------------------
>
>                 Key: WFLY-1487
>                 URL: https://issues.jboss.org/browse/WFLY-1487
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (JBoss Web), Web (Undertow)
>            Reporter: Radim Hatlapatka
>            Assignee: David Lloyd
>             Fix For: 8.0.0.Alpha2
>
>
> Unable to retrieve resources which are nested in additional directory in META-INF. The same works for JAR, only for WAR archive it doesn't.
> Example:
> If in WAR archive I have a resource in META-INF/properties/nested.properties, I am unable to access it using
> {code}
> classLoader.getResource("META-INF/properties/nested.properties");
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 05:44:02 2013
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 21 Oct 2013 05:44:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2346) messaging: add 1.4 XML
	namespace
In-Reply-To: <JIRA.12508287.1382348551840@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508287.1382348551840@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508287.1382348551840.7583.1382348642098@jira02.app.mwc.hst.phx2.redhat.com>

Jeff Mesnil created WFLY-2346:
---------------------------------

             Summary: messaging: add 1.4 XML namespace
                 Key: WFLY-2346
                 URL: https://issues.jboss.org/browse/WFLY-2346
             Project: WildFly
          Issue Type: Bug
          Components: JMS
    Affects Versions: 8.0.0.Beta1
            Reporter: Jeff Mesnil
            Assignee: Jeff Mesnil
             Fix For: 8.0.0.CR1


Add support for the 1.4 XML namespace in the messaging subsystem that added the max-saved-replicated-journal-size attribute to the hornetq-server resource (compared to the 1.3 namespace)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 05:50:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 21 Oct 2013 05:50:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2087) Administrator should be
 prevented from modifying super user and auditor roles.
In-Reply-To: <JIRA.12500788.1379348381000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500788.1379348381000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500788.1379348381000.7607.1382349002471@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823447#comment-12823447 ] 

RH Bugzilla Integration commented on WFLY-2087:
-----------------------------------------------

Ladislav Thon <lthon at redhat.com> made a comment on [bug 1012579|https://bugzilla.redhat.com/show_bug.cgi?id=1012579]

Verified with EAP 6.2.0.ER6.
                
> Administrator should be prevented from modifying super user and auditor roles.
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-2087
>                 URL: https://issues.jboss.org/browse/WFLY-2087
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>
> These roles have maximum privileges in their area, i.e. super user can do everything and auditor can stop changes to the server being logged.
> The administrator role should be prevented from modifying these two roles.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 05:50:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 21 Oct 2013 05:50:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2087) Administrator should be
 prevented from modifying super user and auditor roles.
In-Reply-To: <JIRA.12500788.1379348381000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500788.1379348381000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500788.1379348381000.7611.1382349002668@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823448#comment-12823448 ] 

RH Bugzilla Integration commented on WFLY-2087:
-----------------------------------------------

Ladislav Thon <lthon at redhat.com> changed the Status of [bug 1012579|https://bugzilla.redhat.com/show_bug.cgi?id=1012579] from ON_QA to VERIFIED
                
> Administrator should be prevented from modifying super user and auditor roles.
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-2087
>                 URL: https://issues.jboss.org/browse/WFLY-2087
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>
> These roles have maximum privileges in their area, i.e. super user can do everything and auditor can stop changes to the server being logged.
> The administrator role should be prevented from modifying these two roles.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 05:54:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 21 Oct 2013 05:54:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2131) read-operation-names to
 return a filtered list of allowed operations
In-Reply-To: <JIRA.12501207.1379945777000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501207.1379945777000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501207.1379945777000.7652.1382349242696@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823453#comment-12823453 ] 

RH Bugzilla Integration commented on WFLY-2131:
-----------------------------------------------

Ladislav Thon <lthon at redhat.com> changed the Status of [bug 1013056|https://bugzilla.redhat.com/show_bug.cgi?id=1013056] from ON_QA to VERIFIED
                
> read-operation-names to return a filtered list of allowed operations
> --------------------------------------------------------------------
>
>                 Key: WFLY-2131
>                 URL: https://issues.jboss.org/browse/WFLY-2131
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Alexey Loubyansky
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Beta1
>
>
> As discussed on IRC with Kabir, Heiko and me, we agreed that read-operation-names should return only the operations the caller is permitted to execute.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 05:54:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 21 Oct 2013 05:54:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2131) read-operation-names to
 return a filtered list of allowed operations
In-Reply-To: <JIRA.12501207.1379945777000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501207.1379945777000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501207.1379945777000.7656.1382349242994@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823454#comment-12823454 ] 

RH Bugzilla Integration commented on WFLY-2131:
-----------------------------------------------

Ladislav Thon <lthon at redhat.com> made a comment on [bug 1013056|https://bugzilla.redhat.com/show_bug.cgi?id=1013056]

Verified with EAP 6.2.0.ER6.
                
> read-operation-names to return a filtered list of allowed operations
> --------------------------------------------------------------------
>
>                 Key: WFLY-2131
>                 URL: https://issues.jboss.org/browse/WFLY-2131
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Alexey Loubyansky
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Beta1
>
>
> As discussed on IRC with Kabir, Heiko and me, we agreed that read-operation-names should return only the operations the caller is permitted to execute.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 05:56:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 21 Oct 2013 05:56:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1756) Add access-control parameter
 to read-operation-description operation
In-Reply-To: <JIRA.12497280.1374684426000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497280.1374684426000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497280.1374684426000.7660.1382349362022@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823455#comment-12823455 ] 

RH Bugzilla Integration commented on WFLY-1756:
-----------------------------------------------

Ladislav Thon <lthon at redhat.com> changed the Status of [bug 1013056|https://bugzilla.redhat.com/show_bug.cgi?id=1013056] from ON_QA to VERIFIED
                
> Add access-control parameter to read-operation-description operation
> --------------------------------------------------------------------
>
>                 Key: WFLY-1756
>                 URL: https://issues.jboss.org/browse/WFLY-1756
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Beta1
>
>
> Similar to read-resource-description

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 05:56:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 21 Oct 2013 05:56:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1756) Add access-control parameter
 to read-operation-description operation
In-Reply-To: <JIRA.12497280.1374684426000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497280.1374684426000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497280.1374684426000.7662.1382349362133@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823456#comment-12823456 ] 

RH Bugzilla Integration commented on WFLY-1756:
-----------------------------------------------

Ladislav Thon <lthon at redhat.com> made a comment on [bug 1013056|https://bugzilla.redhat.com/show_bug.cgi?id=1013056]

Verified with EAP 6.2.0.ER6.
                
> Add access-control parameter to read-operation-description operation
> --------------------------------------------------------------------
>
>                 Key: WFLY-1756
>                 URL: https://issues.jboss.org/browse/WFLY-1756
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Beta1
>
>
> Similar to read-resource-description

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 06:05:02 2013
From: jira-events at lists.jboss.org (Eduardo Martins (JIRA))
Date: Mon, 21 Oct 2013 06:05:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2027) EE Default DataSource is not
	working
In-Reply-To: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500313.1378739268000.7744.1382349902808@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823459#comment-12823459 ] 

Eduardo Martins commented on WFLY-2027:
---------------------------------------

[~smarlow] I'm not a JPA expert, but in your previous quote:

{quote}
JPA 2.1 section 8.2.1.5 jta-data-source, non-jta-data-source
In Java EE environments, the jta-data-source and non-jta-data-source elements are used to specify the JNDI name of the JTA and/or non-JTA data source to be used by the persistence provider. If neither is specified, the deployer must specify a JTA data source at deployment or the default JTA data source must be provided by the container...
{quote}
                
> EE Default DataSource is not working
> ------------------------------------
>
>                 Key: WFLY-2027
>                 URL: https://issues.jboss.org/browse/WFLY-2027
>             Project: WildFly
>          Issue Type: Bug
>          Components: ConfigAdmin, Domain Management, EE, JCA, JPA / Hibernate, Web Console
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Lincoln Baxter III
>            Assignee: Eduardo Martins
>             Fix For: 8.0.0.Beta1
>
>
> The EE spec states that a default datasource must be supplied under: java:comp/DefaultDataSource, and if none is specified by the @Resource or persistence.xml, it must be assumed:
>  {code}EE 5.19
> The Java EE Platform requires that a Java EE Product Provider provide a database 
> in the operational environment (see Section EE.2.6, ?Database?). The Java EE 
> Product Provider must also provide a preconfigured, default data source for use by 
> the application in accessing this database.
> The Java EE Product Provider must make the default data source accessible to 
> the application under the JNDI name java:comp/DefaultDataSource.
> The Application Component Provider or Deployer may explicitly bind a 
> DataSource resource reference to the default data source using the lookup element 
> of the Resource annotation or the lookup-name element of the resource-ref
> deployment descriptor element. For example,
> @Resource(lookup="java:comp/DefaultDataSource")
> DataSource myDS;
> In the absence of such a binding, the mapping of the reference will default to 
> the product's default data source.
> For example, the following will map to a preconfigured data source for the 
> product's default database:
> @Resource
> DataSource myDS;{code}
> This, isn't working however:
> {code}
> <persistence version="2.1" xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>    xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/persistence/persistence_2_1.xsd">
>    <persistence-unit name="default" transaction-type="JTA">
>    </persistence-unit>
> </persistence>{code}
> Results in: 
> {code}
> 10:41:31,002 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 50) MSC000001: Failed to start service jboss.persistenceunit."jpa-standard.war#default": org.jboss.msc.service.StartException in service jboss.persistenceunit."jpa-standard.war#default": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:134) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.determineDialect(DialectFactoryImpl.java:98)
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.buildDialect(DialectFactoryImpl.java:66)
> 	at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:193)
> 	at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:88)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:159)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131)
> 	at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration.java:1844)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1802)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:844)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835)
> 	at org.jboss.as.jpa.hibernate4.management.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:115) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	... 4 more
> 10:41:31,010 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"jpa-standard.war#default\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"jpa-standard.war#default\": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
>     Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set"}}
> {code}
> Additionally, actually specifying the expected JDNI name of the default DS like this:
> {code}   <persistence-unit name="default" transaction-type="JTA">
>       <jta-data-source>java:comp/DefaultDataSource</jta-data-source>
>       <exclude-unlisted-classes>false</exclude-unlisted-classes>
>    </persistence-unit>{code}
> Results in this:
> {code}
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.naming.context.java.module.jpa-standard.jpa-standard.DefaultDataSource (missing) dependents: [service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__] 
>       service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__ (missing) dependents: [service jboss.deployment.unit."jpa-standard.war".POST_MODULE] 
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Mon Oct 21 06:13:02 2013
From: jira-events at lists.jboss.org (Eduardo Martins (JIRA))
Date: Mon, 21 Oct 2013 06:13:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2212) Update JPA subsystem to use
 default datasource
In-Reply-To: <JIRA.12502126.1380810972000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502126.1380810972000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502126.1380810972000.7777.1382350382229@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823463#comment-12823463 ] 

Eduardo Martins commented on WFLY-2212:
---------------------------------------

eeModuleDescription.getDefaultResourceJndiNames().getDataSource() has the *real* jndi name that is used for the lookup injection source when binding "java:comp/DefaultDataSource"

Please add my wildfly repo fork as a remote of yours and use that branch as a source for yours, I will not have time to go after this soon.
                
> Update JPA subsystem to use default datasource
> ----------------------------------------------
>
>                 Key: WFLY-2212
>                 URL: https://issues.jboss.org/browse/WFLY-2212
>             Project: WildFly
>          Issue Type: Task
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 8.0.0.CR1
>
>
> See comments in WFLY-2027 before starting the work on this jira...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 06:17:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Mon, 21 Oct 2013 06:17:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2344) undertow claims already
	registered
In-Reply-To: <JIRA.12508247.1382248265000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508247.1382248265000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508247.1382248265000.7790.1382350622171@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFLY-2344:
------------------------------------

    Assignee: Tomaz Cerar


Looks like the location service is not using the host name to build up the service name.
                
> undertow claims already registered
> ----------------------------------
>
>                 Key: WFLY-2344
>                 URL: https://issues.jboss.org/browse/WFLY-2344
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Beta1
>            Reporter: miguel deanda
>            Assignee: Tomaz Cerar
>
> I've downloaded wildfly beta, attempted to add a vhost using the undertow configuration (can't find documentation btw) but when it starts, it says:
> org.jboss.msc.service.DuplicateServiceException: Service jboss.web.common.host./ is already registered 
> I originally posted the question here:
> https://community.jboss.org/message/842352
> The relevant config section (standalone.xml) is the following:
> <subsystem xmlns="urn:jboss:domain:undertow:1.0">
> 	<buffer-caches>
> 		<buffer-cache name="default" buffer-size="1024" buffers-per-region="1024" max-regions="10"/>
> 	</buffer-caches>
> 	<server name="default-server">
> 		<http-listener name="default" socket-binding="http" max-post-size="10485760"/>
> 		<host name="default-host" alias="localhost">
> 			<location name="/" handler="welcome-content"/>
> 		</host>
> 		<host name="other-host" alias="www.mysite.com" default-web-module="something.war">
> 			<location name="/" handler="welcome-content">
> 				<filter-ref name="connection-limit"/>
> 			</location>
> 		</host>
> 	</server>
> 	<servlet-container name="default" default-buffer-cache="default" stack-trace-on-error="local-only">
> 		<jsp-config/>
> 		<persistent-sessions path="persistent-web-sessions" relative-to="jboss.server.data.dir"/>
> 	</servlet-container>
> 	<handlers>
> 		<file name="welcome-content" path="${jboss.home.dir}/welcome-content" directory-listing="true"/>
> 	</handlers>
> </subsystem>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 06:19:02 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 21 Oct 2013 06:19:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2344) undertow claims already
	registered
In-Reply-To: <JIRA.12508247.1382248265000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508247.1382248265000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508247.1382248265000.7807.1382350742341@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823470#comment-12823470 ] 

Tomaz Cerar commented on WFLY-2344:
-----------------------------------

Problem is registration to common web server, it should be done only for default host/server
                
> undertow claims already registered
> ----------------------------------
>
>                 Key: WFLY-2344
>                 URL: https://issues.jboss.org/browse/WFLY-2344
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Beta1
>            Reporter: miguel deanda
>            Assignee: Tomaz Cerar
>
> I've downloaded wildfly beta, attempted to add a vhost using the undertow configuration (can't find documentation btw) but when it starts, it says:
> org.jboss.msc.service.DuplicateServiceException: Service jboss.web.common.host./ is already registered 
> I originally posted the question here:
> https://community.jboss.org/message/842352
> The relevant config section (standalone.xml) is the following:
> <subsystem xmlns="urn:jboss:domain:undertow:1.0">
> 	<buffer-caches>
> 		<buffer-cache name="default" buffer-size="1024" buffers-per-region="1024" max-regions="10"/>
> 	</buffer-caches>
> 	<server name="default-server">
> 		<http-listener name="default" socket-binding="http" max-post-size="10485760"/>
> 		<host name="default-host" alias="localhost">
> 			<location name="/" handler="welcome-content"/>
> 		</host>
> 		<host name="other-host" alias="www.mysite.com" default-web-module="something.war">
> 			<location name="/" handler="welcome-content">
> 				<filter-ref name="connection-limit"/>
> 			</location>
> 		</host>
> 	</server>
> 	<servlet-container name="default" default-buffer-cache="default" stack-trace-on-error="local-only">
> 		<jsp-config/>
> 		<persistent-sessions path="persistent-web-sessions" relative-to="jboss.server.data.dir"/>
> 	</servlet-container>
> 	<handlers>
> 		<file name="welcome-content" path="${jboss.home.dir}/welcome-content" directory-listing="true"/>
> 	</handlers>
> </subsystem>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 06:25:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 21 Oct 2013 06:25:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2182) Significant slow down of
 testsuite execution
In-Reply-To: <JIRA.12501817.1380538653000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501817.1380538653000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501817.1380538653000.7816.1382351102734@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823472#comment-12823472 ] 

RH Bugzilla Integration commented on WFLY-2182:
-----------------------------------------------

Ladislav Thon <lthon at redhat.com> changed the Status of [bug 1013698|https://bugzilla.redhat.com/show_bug.cgi?id=1013698] from ON_QA to VERIFIED
                
> Significant slow down of testsuite execution
> --------------------------------------------
>
>                 Key: WFLY-2182
>                 URL: https://issues.jboss.org/browse/WFLY-2182
>             Project: WildFly
>          Issue Type: Bug
>          Components: Remoting
>            Reporter: Jozef Hartinger
>            Assignee: Kabir Khan
>
> I am observing a significant slow down when running the Weld integration testsuite. I tracked this down to this commit:
> https://github.com/wildfly/wildfly/commit/13f09525717a089f8a524d086fd865798410f368
> Here are the observed execution times of the Weld integration testsuite:
> Before: Total time: 4:30.357s
> After: Total time: 11:05.547s
> I also tried running the WildFly's integration testsuite (testsuite/integration/basic) with and without the 13f09525717a089f8a524d086fd865798410f368 commit:
> Before: Total time: 13:04.412s
> After: Total time: 21:33.089s
> Note that the difference is not observed when using the arquillian servlet protocol

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 06:25:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 21 Oct 2013 06:25:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2182) Significant slow down of
 testsuite execution
In-Reply-To: <JIRA.12501817.1380538653000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501817.1380538653000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501817.1380538653000.7822.1382351103151@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823473#comment-12823473 ] 

RH Bugzilla Integration commented on WFLY-2182:
-----------------------------------------------

Ladislav Thon <lthon at redhat.com> made a comment on [bug 1013698|https://bugzilla.redhat.com/show_bug.cgi?id=1013698]

Verified with EAP 6.2.0.ER6.
                
> Significant slow down of testsuite execution
> --------------------------------------------
>
>                 Key: WFLY-2182
>                 URL: https://issues.jboss.org/browse/WFLY-2182
>             Project: WildFly
>          Issue Type: Bug
>          Components: Remoting
>            Reporter: Jozef Hartinger
>            Assignee: Kabir Khan
>
> I am observing a significant slow down when running the Weld integration testsuite. I tracked this down to this commit:
> https://github.com/wildfly/wildfly/commit/13f09525717a089f8a524d086fd865798410f368
> Here are the observed execution times of the Weld integration testsuite:
> Before: Total time: 4:30.357s
> After: Total time: 11:05.547s
> I also tried running the WildFly's integration testsuite (testsuite/integration/basic) with and without the 13f09525717a089f8a524d086fd865798410f368 commit:
> Before: Total time: 13:04.412s
> After: Total time: 21:33.089s
> Note that the difference is not observed when using the arquillian servlet protocol

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 06:36:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 21 Oct 2013 06:36:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2220) Unable to reload server after
 adding role and executing :reload
In-Reply-To: <JIRA.12502221.1380896422000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502221.1380896422000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502221.1380896422000.7839.1382351762071@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823476#comment-12823476 ] 

RH Bugzilla Integration commented on WFLY-2220:
-----------------------------------------------

Ladislav Thon <lthon at redhat.com> made a comment on [bug 1015585|https://bugzilla.redhat.com/show_bug.cgi?id=1015585]

Verified with EAP 6.2.0.ER6.
                
> Unable to reload server after adding role and executing :reload
> ---------------------------------------------------------------
>
>                 Key: WFLY-2220
>                 URL: https://issues.jboss.org/browse/WFLY-2220
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.CR1
>
>
> Start a clean build of WildFly 8 and execute the following commands in the CLI: -
> {code}
> [standalone at localhost:9990 /connect
> [standalone at localhost:9990 /] ./core-service=management/access=authorization/role-mapping=Operator:add
> {"outcome" => "success"}
> [standalone at localhost:9990 /] :reload
> {
>     "outcome" => "success",
>     "result" => undefined
> }
> [standalone at localhost:9990 /] 
> {code}
> Results in the following error and the server shuts down: -
> {code}
> 15:15:02,275 INFO  [org.jboss.as.server] (Controller Boot Thread) JBAS015888: Creating http management service using socket-binding (management-http)
> 15:15:02,278 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014612: Operation ("add") failed - address: ([
>     ("core-service" => "management"),
>     ("access" => "authorization"),
>     ("role-mapping" => "SuperUser")
> ]): java.lang.UnsupportedOperationException
> 	at java.util.Collections$UnmodifiableMap.put(Collections.java:1342) [rt.jar:1.7.0_17]
> 	at org.jboss.as.controller.access.management.WritableAuthorizerConfiguration.addRoleMappingImmediate(WritableAuthorizerConfiguration.java:163) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.domain.management.access.RoleMappingAdd$1.execute(RoleMappingAdd.java:76) [wildfly-domain-management-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:609) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:487) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:321) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:290) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:356) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:331) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:252) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> 15:15:02,287 INFO  [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.remoting.endpoint.management (missing) dependents: [service jboss.remoting.management.channel.registry] 
> 15:15:02,290 FATAL [org.jboss.as.server] (Controller Boot Thread) JBAS015957: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> 15:15:02,297 INFO  [org.jboss.as] (MSC service thread 1-1) JBAS015950: WildFly 8.0.0.Beta1-SNAPSHOT "WildFly" stopped in 2ms
> {code}
> What is interesting is that the server is manually startable to something has gone wrong regarding resetting the runtime state of RBAC at the time of the reload.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 06:36:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 21 Oct 2013 06:36:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2220) Unable to reload server after
 adding role and executing :reload
In-Reply-To: <JIRA.12502221.1380896422000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502221.1380896422000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502221.1380896422000.7843.1382351762385@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823477#comment-12823477 ] 

RH Bugzilla Integration commented on WFLY-2220:
-----------------------------------------------

Ladislav Thon <lthon at redhat.com> changed the Status of [bug 1015585|https://bugzilla.redhat.com/show_bug.cgi?id=1015585] from ON_QA to VERIFIED
                
> Unable to reload server after adding role and executing :reload
> ---------------------------------------------------------------
>
>                 Key: WFLY-2220
>                 URL: https://issues.jboss.org/browse/WFLY-2220
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.CR1
>
>
> Start a clean build of WildFly 8 and execute the following commands in the CLI: -
> {code}
> [standalone at localhost:9990 /connect
> [standalone at localhost:9990 /] ./core-service=management/access=authorization/role-mapping=Operator:add
> {"outcome" => "success"}
> [standalone at localhost:9990 /] :reload
> {
>     "outcome" => "success",
>     "result" => undefined
> }
> [standalone at localhost:9990 /] 
> {code}
> Results in the following error and the server shuts down: -
> {code}
> 15:15:02,275 INFO  [org.jboss.as.server] (Controller Boot Thread) JBAS015888: Creating http management service using socket-binding (management-http)
> 15:15:02,278 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014612: Operation ("add") failed - address: ([
>     ("core-service" => "management"),
>     ("access" => "authorization"),
>     ("role-mapping" => "SuperUser")
> ]): java.lang.UnsupportedOperationException
> 	at java.util.Collections$UnmodifiableMap.put(Collections.java:1342) [rt.jar:1.7.0_17]
> 	at org.jboss.as.controller.access.management.WritableAuthorizerConfiguration.addRoleMappingImmediate(WritableAuthorizerConfiguration.java:163) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.domain.management.access.RoleMappingAdd$1.execute(RoleMappingAdd.java:76) [wildfly-domain-management-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:609) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:487) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:321) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:290) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:356) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:331) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:252) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> 15:15:02,287 INFO  [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.remoting.endpoint.management (missing) dependents: [service jboss.remoting.management.channel.registry] 
> 15:15:02,290 FATAL [org.jboss.as.server] (Controller Boot Thread) JBAS015957: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> 15:15:02,297 INFO  [org.jboss.as] (MSC service thread 1-1) JBAS015950: WildFly 8.0.0.Beta1-SNAPSHOT "WildFly" stopped in 2ms
> {code}
> What is interesting is that the server is manually startable to something has gone wrong regarding resetting the runtime state of RBAC at the time of the reload.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 06:40:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Mon, 21 Oct 2013 06:40:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-247) Property reactivity does not
 work with positional/unification constraints
In-Reply-To: <JIRA.12499719.1377919009000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499719.1377919009000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499719.1377919009000.7860.1382352002616@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-247.
--------------------------------

    Resolution: Done

    
> Property reactivity does not work with positional/unification constraints
> -------------------------------------------------------------------------
>
>                 Key: DROOLS-247
>                 URL: https://issues.jboss.org/browse/DROOLS-247
>             Project: Drools
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.CR2
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Minor
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> Positional and/or unification constraints are interpreted as either bindings
> or constraints, depending on the whether the variable is already bound or not. The user is expected not to have to care about the difference.
> ...
> Person( $name; $age := age )
> ...
> If the pattern type is @propertyReactive, however, the actual decision
> between binding and constraint WILL make a difference, possibly forcing
> the user to use @watch()

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 06:40:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Mon, 21 Oct 2013 06:40:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-247) Property reactivity does not
 work with positional/unification constraints
In-Reply-To: <JIRA.12499719.1377919009000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499719.1377919009000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499719.1377919009000.7858.1382352002514@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-247:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> Property reactivity does not work with positional/unification constraints
> -------------------------------------------------------------------------
>
>                 Key: DROOLS-247
>                 URL: https://issues.jboss.org/browse/DROOLS-247
>             Project: Drools
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.CR2
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Minor
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> Positional and/or unification constraints are interpreted as either bindings
> or constraints, depending on the whether the variable is already bound or not. The user is expected not to have to care about the difference.
> ...
> Person( $name; $age := age )
> ...
> If the pattern type is @propertyReactive, however, the actual decision
> between binding and constraint WILL make a difference, possibly forcing
> the user to use @watch()

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 06:42:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 21 Oct 2013 06:42:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2216) include-all role mappings
 don't work in domain
In-Reply-To: <JIRA.12502198.1380887272000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502198.1380887272000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502198.1380887272000.7865.1382352122021@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823479#comment-12823479 ] 

RH Bugzilla Integration commented on WFLY-2216:
-----------------------------------------------

Ladislav Thon <lthon at redhat.com> changed the Status of [bug 1015493|https://bugzilla.redhat.com/show_bug.cgi?id=1015493] from ON_QA to VERIFIED
                
> include-all role mappings don't work in domain
> ----------------------------------------------
>
>                 Key: WFLY-2216
>                 URL: https://issues.jboss.org/browse/WFLY-2216
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Ladislav Thon
>            Assignee: Darran Lofthouse
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.CR1
>
>
> If I understand correctly, roles that have {{include-all=true}} in their role mappings should be added to all authenticated users. In my tests, though, this only works in standalone mode.
> In domain mode, if I set a role mapping to {{include-all}}, this setting is not reflected (at least not immediately; maybe it would work after restart, but that's wrong anyway). It doesn't matter which role is set to be {{include-all}} -- in my tests, I use both standard roles and scoped roles and it consistently doesn't work. There's probably some wrong caching going on.
> The failing test case is in my pull request https://github.com/wildfly/wildfly/pull/5166 (it's the _RBAC tests for include-all role mappings in domain_ commit). If it's more convenient, the pull request is the same as my _rbac_ branch (https://github.com/Ladicek/wildfly/commits/rbac).
> Darran, I'm not sure if you are the right assignee -- please reassign if needed. Thanks.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 06:42:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 21 Oct 2013 06:42:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2216) include-all role mappings
 don't work in domain
In-Reply-To: <JIRA.12502198.1380887272000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502198.1380887272000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502198.1380887272000.7868.1382352122166@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823480#comment-12823480 ] 

RH Bugzilla Integration commented on WFLY-2216:
-----------------------------------------------

Ladislav Thon <lthon at redhat.com> made a comment on [bug 1015493|https://bugzilla.redhat.com/show_bug.cgi?id=1015493]

Verified with EAP 6.2.0.ER6.
                
> include-all role mappings don't work in domain
> ----------------------------------------------
>
>                 Key: WFLY-2216
>                 URL: https://issues.jboss.org/browse/WFLY-2216
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Ladislav Thon
>            Assignee: Darran Lofthouse
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.CR1
>
>
> If I understand correctly, roles that have {{include-all=true}} in their role mappings should be added to all authenticated users. In my tests, though, this only works in standalone mode.
> In domain mode, if I set a role mapping to {{include-all}}, this setting is not reflected (at least not immediately; maybe it would work after restart, but that's wrong anyway). It doesn't matter which role is set to be {{include-all}} -- in my tests, I use both standard roles and scoped roles and it consistently doesn't work. There's probably some wrong caching going on.
> The failing test case is in my pull request https://github.com/wildfly/wildfly/pull/5166 (it's the _RBAC tests for include-all role mappings in domain_ commit). If it's more convenient, the pull request is the same as my _rbac_ branch (https://github.com/Ladicek/wildfly/commits/rbac).
> Darran, I'm not sure if you are the right assignee -- please reassign if needed. Thanks.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 06:50:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Mon, 21 Oct 2013 06:50:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-244) Sliding windows working
 incorrectly when timestamp attribute is defined
In-Reply-To: <JIRA.12499640.1377791004000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499640.1377791004000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499640.1377791004000.7888.1382352602548@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-244:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> Sliding windows working incorrectly when timestamp attribute is defined
> -----------------------------------------------------------------------
>
>                 Key: DROOLS-244
>                 URL: https://issues.jboss.org/browse/DROOLS-244
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Vytautas Gimbutas
>            Assignee: Mario Fusco
>         Attachments: app-ss-test-case.zip, Event.java, file.drl, Transaction.java, TransactionCompletedEvent.java, TransactionCreatedEvent.java, TransactionEvent.java
>
>
> Download app-ss-test-case.zip and run TimestampAttributeTest.
> When timestamp attribute is set in the past (lets say with timestamp of 30 days ago) it falls in every sliding window over time (e.g. 1s).
> Expected output:
> 1
> 0
> Actual output:
> 1
> 1

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 06:50:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Mon, 21 Oct 2013 06:50:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-244) Sliding windows working
 incorrectly when timestamp attribute is defined
In-Reply-To: <JIRA.12499640.1377791004000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499640.1377791004000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499640.1377791004000.7892.1382352602737@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-244.
--------------------------------

    Fix Version/s: 5.5.1.Final
                   6.0.0.Final
       Resolution: Done

    
> Sliding windows working incorrectly when timestamp attribute is defined
> -----------------------------------------------------------------------
>
>                 Key: DROOLS-244
>                 URL: https://issues.jboss.org/browse/DROOLS-244
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Vytautas Gimbutas
>            Assignee: Mario Fusco
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>         Attachments: app-ss-test-case.zip, Event.java, file.drl, Transaction.java, TransactionCompletedEvent.java, TransactionCreatedEvent.java, TransactionEvent.java
>
>
> Download app-ss-test-case.zip and run TimestampAttributeTest.
> When timestamp attribute is set in the past (lets say with timestamp of 30 days ago) it falls in every sliding window over time (e.g. 1s).
> Expected output:
> 1
> 0
> Actual output:
> 1
> 1

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 07:22:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 21 Oct 2013 07:22:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1740) ManagedSocketBinding class
 Impossible cast from java.net.InetAddress to java.net.InetSocketAddress
In-Reply-To: <JIRA.12497092.1374526330000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497092.1374526330000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497092.1374526330000.7989.1382354522831@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823494#comment-12823494 ] 

RH Bugzilla Integration commented on WFLY-1740:
-----------------------------------------------

Emanuel Muckenhuber <emuckenh at redhat.com> changed the Status of [bug 1017747|https://bugzilla.redhat.com/show_bug.cgi?id=1017747] from ASSIGNED to POST
                
> ManagedSocketBinding class Impossible cast from java.net.InetAddress to java.net.InetSocketAddress
> --------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1740
>                 URL: https://issues.jboss.org/browse/WFLY-1740
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Cheng Fang
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.CR1
>
>
> Reported by FindBugs:
> Impossible cast from java.net.InetAddress to java.net.InetSocketAddress
> Class:
> ManagedSocketBinding (org.jboss.as.network) line 55
> Method:
> getBindAddress (org.jboss.as.network.ManagedSocketBinding.getBindAddress())
> Priority:
> ? ? ?High Confidence Correctness
> ?
> Problem classification:
> Correctness (Bad casts of object references)
> BC_IMPOSSIBLE_CAST (Impossible cast)
> Notes:
> Actual type java.net.InetAddress
> Expected java.net.InetSocketAddress
> Return value of Class.cast(Object)
> FindBadCast2 (BC|NP)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Mon Oct 21 07:22:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 21 Oct 2013 07:22:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1740) ManagedSocketBinding class
 Impossible cast from java.net.InetAddress to java.net.InetSocketAddress
In-Reply-To: <JIRA.12497092.1374526330000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497092.1374526330000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497092.1374526330000.7993.1382354523012@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823495#comment-12823495 ] 

RH Bugzilla Integration commented on WFLY-1740:
-----------------------------------------------

Emanuel Muckenhuber <emuckenh at redhat.com> made a comment on [bug 1017747|https://bugzilla.redhat.com/show_bug.cgi?id=1017747]

I openend a PR containing a fix for this. The related change is: https://github.com/emuckenhuber/jboss-eap/commit/e64b87dd2c7c0cf10f1e580db7080e991be59f0f
                
> ManagedSocketBinding class Impossible cast from java.net.InetAddress to java.net.InetSocketAddress
> --------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1740
>                 URL: https://issues.jboss.org/browse/WFLY-1740
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Cheng Fang
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.CR1
>
>
> Reported by FindBugs:
> Impossible cast from java.net.InetAddress to java.net.InetSocketAddress
> Class:
> ManagedSocketBinding (org.jboss.as.network) line 55
> Method:
> getBindAddress (org.jboss.as.network.ManagedSocketBinding.getBindAddress())
> Priority:
> ? ? ?High Confidence Correctness
> ?
> Problem classification:
> Correctness (Bad casts of object references)
> BC_IMPOSSIBLE_CAST (Impossible cast)
> Notes:
> Actual type java.net.InetAddress
> Expected java.net.InetSocketAddress
> Return value of Class.cast(Object)
> FindBadCast2 (BC|NP)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Mon Oct 21 08:35:02 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 21 Oct 2013 08:35:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2344) undertow claims already
	registered
In-Reply-To: <JIRA.12508247.1382248265000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508247.1382248265000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508247.1382248265000.8213.1382358902176@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-2344:
------------------------------

    Fix Version/s: 8.0.0.CR1

    
> undertow claims already registered
> ----------------------------------
>
>                 Key: WFLY-2344
>                 URL: https://issues.jboss.org/browse/WFLY-2344
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Beta1
>            Reporter: miguel deanda
>            Assignee: Tomaz Cerar
>             Fix For: 8.0.0.CR1
>
>
> I've downloaded wildfly beta, attempted to add a vhost using the undertow configuration (can't find documentation btw) but when it starts, it says:
> org.jboss.msc.service.DuplicateServiceException: Service jboss.web.common.host./ is already registered 
> I originally posted the question here:
> https://community.jboss.org/message/842352
> The relevant config section (standalone.xml) is the following:
> <subsystem xmlns="urn:jboss:domain:undertow:1.0">
> 	<buffer-caches>
> 		<buffer-cache name="default" buffer-size="1024" buffers-per-region="1024" max-regions="10"/>
> 	</buffer-caches>
> 	<server name="default-server">
> 		<http-listener name="default" socket-binding="http" max-post-size="10485760"/>
> 		<host name="default-host" alias="localhost">
> 			<location name="/" handler="welcome-content"/>
> 		</host>
> 		<host name="other-host" alias="www.mysite.com" default-web-module="something.war">
> 			<location name="/" handler="welcome-content">
> 				<filter-ref name="connection-limit"/>
> 			</location>
> 		</host>
> 	</server>
> 	<servlet-container name="default" default-buffer-cache="default" stack-trace-on-error="local-only">
> 		<jsp-config/>
> 		<persistent-sessions path="persistent-web-sessions" relative-to="jboss.server.data.dir"/>
> 	</servlet-container>
> 	<handlers>
> 		<file name="welcome-content" path="${jboss.home.dir}/welcome-content" directory-listing="true"/>
> 	</handlers>
> </subsystem>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 08:35:02 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 21 Oct 2013 08:35:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2344) undertow claims already
	registered
In-Reply-To: <JIRA.12508247.1382248265000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508247.1382248265000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508247.1382248265000.8221.1382358902470@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-2344:
------------------------------

    Component/s: Web (Undertow)

    
> undertow claims already registered
> ----------------------------------
>
>                 Key: WFLY-2344
>                 URL: https://issues.jboss.org/browse/WFLY-2344
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: miguel deanda
>            Assignee: Tomaz Cerar
>             Fix For: 8.0.0.CR1
>
>
> I've downloaded wildfly beta, attempted to add a vhost using the undertow configuration (can't find documentation btw) but when it starts, it says:
> org.jboss.msc.service.DuplicateServiceException: Service jboss.web.common.host./ is already registered 
> I originally posted the question here:
> https://community.jboss.org/message/842352
> The relevant config section (standalone.xml) is the following:
> <subsystem xmlns="urn:jboss:domain:undertow:1.0">
> 	<buffer-caches>
> 		<buffer-cache name="default" buffer-size="1024" buffers-per-region="1024" max-regions="10"/>
> 	</buffer-caches>
> 	<server name="default-server">
> 		<http-listener name="default" socket-binding="http" max-post-size="10485760"/>
> 		<host name="default-host" alias="localhost">
> 			<location name="/" handler="welcome-content"/>
> 		</host>
> 		<host name="other-host" alias="www.mysite.com" default-web-module="something.war">
> 			<location name="/" handler="welcome-content">
> 				<filter-ref name="connection-limit"/>
> 			</location>
> 		</host>
> 	</server>
> 	<servlet-container name="default" default-buffer-cache="default" stack-trace-on-error="local-only">
> 		<jsp-config/>
> 		<persistent-sessions path="persistent-web-sessions" relative-to="jboss.server.data.dir"/>
> 	</servlet-container>
> 	<handlers>
> 		<file name="welcome-content" path="${jboss.home.dir}/welcome-content" directory-listing="true"/>
> 	</handlers>
> </subsystem>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 08:41:01 2013
From: jira-events at lists.jboss.org (Alessio Soldano (JIRA))
Date: Mon, 21 Oct 2013 08:41:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2347) Upgrade to JBossWS 4.2.2.Final
In-Reply-To: <JIRA.12508338.1382359162507@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508338.1382359162507@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508338.1382359162507.8237.1382359261957@jira02.app.mwc.hst.phx2.redhat.com>

Alessio Soldano created WFLY-2347:
-------------------------------------

             Summary: Upgrade to JBossWS 4.2.2.Final
                 Key: WFLY-2347
                 URL: https://issues.jboss.org/browse/WFLY-2347
             Project: WildFly
          Issue Type: Component  Upgrade
          Components: Web Services
            Reporter: Alessio Soldano
            Assignee: Alessio Soldano
             Fix For: 8.0.0.CR1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 08:53:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 21 Oct 2013 08:53:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1720) RequestOptions: exclusion
 list should be array
In-Reply-To: <JIRA.12508339.1382359866878@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508339.1382359866878@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508339.1382359866878.8275.1382359982157@jira02.app.mwc.hst.phx2.redhat.com>

Bela Ban created JGRP-1720:
------------------------------

             Summary: RequestOptions: exclusion list should be array
                 Key: JGRP-1720
                 URL: https://issues.jboss.org/browse/JGRP-1720
             Project: JGroups
          Issue Type: Enhancement
            Reporter: Bela Ban
            Assignee: Bela Ban
            Priority: Minor
             Fix For: 3.4.1, 3.5


RequestOptions.exclusion_list should be an array, to conserve memory and CPU overhead. Possibly also just send the index of the member in the current view.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 09:26:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 21 Oct 2013 09:26:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-369) Domain mode: kill an
	unresponsive JVM
In-Reply-To: <JIRA.12480351.1354566315000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12480351.1354566315000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12480351.1354566315000.8370.1382361963094@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823559#comment-12823559 ] 

RH Bugzilla Integration commented on WFLY-369:
----------------------------------------------

Dimitris Andreadis <dandread at redhat.com> made a comment on [bug 901232|https://bugzilla.redhat.com/show_bug.cgi?id=901232]

Raising the blocker request flag to make sure it doesn't fall through the cracks.
                
> Domain mode: kill an unresponsive JVM
> -------------------------------------
>
>                 Key: WFLY-369
>                 URL: https://issues.jboss.org/browse/WFLY-369
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Dennis Reed
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.Alpha1
>
>
> If an AS instance gets into a state where it cannot be controlled normally by the host controller, local OS commands must be used to kill it.
> It would be helpful to be able to kill an unresponsive JVM through the management interface.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 10:01:03 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Mon, 21 Oct 2013 10:01:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2027) EE Default DataSource is not
	working
In-Reply-To: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500313.1378739268000.8574.1382364063288@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823590#comment-12823590 ] 

Scott Marlow commented on WFLY-2027:
------------------------------------

[~emmartins] The quoted JPA specification is not from EE7/JPA 2.1.  There was no "default JTA data source" at the EE product level in earlier EE versions.  However, JBoss AS7 did introduce a JPA level default data source (which WildFly 8.0.0 also has), that is the "default JTA data source".

                
> EE Default DataSource is not working
> ------------------------------------
>
>                 Key: WFLY-2027
>                 URL: https://issues.jboss.org/browse/WFLY-2027
>             Project: WildFly
>          Issue Type: Bug
>          Components: ConfigAdmin, Domain Management, EE, JCA, JPA / Hibernate, Web Console
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Lincoln Baxter III
>            Assignee: Eduardo Martins
>             Fix For: 8.0.0.Beta1
>
>
> The EE spec states that a default datasource must be supplied under: java:comp/DefaultDataSource, and if none is specified by the @Resource or persistence.xml, it must be assumed:
>  {code}EE 5.19
> The Java EE Platform requires that a Java EE Product Provider provide a database 
> in the operational environment (see Section EE.2.6, ?Database?). The Java EE 
> Product Provider must also provide a preconfigured, default data source for use by 
> the application in accessing this database.
> The Java EE Product Provider must make the default data source accessible to 
> the application under the JNDI name java:comp/DefaultDataSource.
> The Application Component Provider or Deployer may explicitly bind a 
> DataSource resource reference to the default data source using the lookup element 
> of the Resource annotation or the lookup-name element of the resource-ref
> deployment descriptor element. For example,
> @Resource(lookup="java:comp/DefaultDataSource")
> DataSource myDS;
> In the absence of such a binding, the mapping of the reference will default to 
> the product's default data source.
> For example, the following will map to a preconfigured data source for the 
> product's default database:
> @Resource
> DataSource myDS;{code}
> This, isn't working however:
> {code}
> <persistence version="2.1" xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>    xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/persistence/persistence_2_1.xsd">
>    <persistence-unit name="default" transaction-type="JTA">
>    </persistence-unit>
> </persistence>{code}
> Results in: 
> {code}
> 10:41:31,002 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 50) MSC000001: Failed to start service jboss.persistenceunit."jpa-standard.war#default": org.jboss.msc.service.StartException in service jboss.persistenceunit."jpa-standard.war#default": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:134) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.determineDialect(DialectFactoryImpl.java:98)
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.buildDialect(DialectFactoryImpl.java:66)
> 	at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:193)
> 	at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:88)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:159)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131)
> 	at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration.java:1844)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1802)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:844)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835)
> 	at org.jboss.as.jpa.hibernate4.management.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:115) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	... 4 more
> 10:41:31,010 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"jpa-standard.war#default\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"jpa-standard.war#default\": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
>     Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set"}}
> {code}
> Additionally, actually specifying the expected JDNI name of the default DS like this:
> {code}   <persistence-unit name="default" transaction-type="JTA">
>       <jta-data-source>java:comp/DefaultDataSource</jta-data-source>
>       <exclude-unlisted-classes>false</exclude-unlisted-classes>
>    </persistence-unit>{code}
> Results in this:
> {code}
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.naming.context.java.module.jpa-standard.jpa-standard.DefaultDataSource (missing) dependents: [service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__] 
>       service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__ (missing) dependents: [service jboss.deployment.unit."jpa-standard.war".POST_MODULE] 
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Mon Oct 21 10:14:02 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Mon, 21 Oct 2013 10:14:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2212) Update JPA subsystem to use
 default datasource
In-Reply-To: <JIRA.12502126.1380810972000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502126.1380810972000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502126.1380810972000.8628.1382364842175@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823601#comment-12823601 ] 

Scott Marlow commented on WFLY-2212:
------------------------------------

Sure, thanks for the patch [~emmartins]
                
> Update JPA subsystem to use default datasource
> ----------------------------------------------
>
>                 Key: WFLY-2212
>                 URL: https://issues.jboss.org/browse/WFLY-2212
>             Project: WildFly
>          Issue Type: Task
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 8.0.0.CR1
>
>
> See comments in WFLY-2027 before starting the work on this jira...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 10:14:02 2013
From: jira-events at lists.jboss.org (gui borland (JIRA))
Date: Mon, 21 Oct 2013 10:14:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-895) JBoss crashes when run with
 AspectJ java agent
In-Reply-To: <JIRA.12458681.1328740621000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12458681.1328740621000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12458681.1328740621000.8631.1382364842354@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823602#comment-12823602 ] 

gui borland commented on WFLY-895:
----------------------------------

An annoying side effect of using the workaround is that custom log handlers no longer work. 
Jboss insist on loading these custom handlers using jboss modules, but this fails if logmanager is on the system classpath...
                
> JBoss crashes when run with AspectJ java agent
> ----------------------------------------------
>
>                 Key: WFLY-895
>                 URL: https://issues.jboss.org/browse/WFLY-895
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>         Environment: OS X 10.7.2, Ubuntu 11.10
>            Reporter: Jack Lund
>            Assignee: David Lloyd
>              Labels: aspectj, load_time_weaving
>
> When trying to start JBoss with the AspectJ java agent (-javaagent:/path/aspectjweaver.jar) to enable load-time weaving, JBoss crashes with the following stack trace in the logs:
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /home/jack/jboss-as-7.1.0.CR1b
>   JAVA: java
>   JAVA_OPTS: -server -javaagent:/home/jack/aspectjweaver.jar -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> WARNING: Failed to load the specified logmodule org.jboss.logmanager:main
> Exception in thread "main" java.lang.ExceptionInInitializerError
> 	at org.jboss.as.server.Main.main(Main.java:92)
> 	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:616)
> 	at org.jboss.modules.Module.run(Module.java:248)
> 	at org.jboss.modules.Main.main(Main.java:313)
> Caused by: java.lang.IllegalStateException: The LogManager was not properly installed (you must set the "java.util.logging.manager" system property to "org.jboss.logmanager.LogManager")
> 	at org.jboss.logmanager.Logger.getLogger(Logger.java:60)
> 	at org.jboss.logmanager.log4j.BridgeRepositorySelector.<clinit>(BridgeRepositorySelector.java:42)
> 	... 7 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 10:22:02 2013
From: jira-events at lists.jboss.org (Philippe Marschall (JIRA))
Date: Mon, 21 Oct 2013 10:22:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2348) standalone.bat very slow on
	windows
In-Reply-To: <JIRA.12508361.1382365222612@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508361.1382365222612@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508361.1382365222612.8681.1382365322517@jira02.app.mwc.hst.phx2.redhat.com>

Philippe Marschall created WFLY-2348:
----------------------------------------

             Summary: standalone.bat very slow on windows
                 Key: WFLY-2348
                 URL: https://issues.jboss.org/browse/WFLY-2348
             Project: WildFly
          Issue Type: Enhancement
          Components: Scripts
    Affects Versions: 8.0.0.Beta1
            Reporter: Philippe Marschall
            Assignee: Brian Stansberry


With a plain WildFly AS downloaded and executing {code}standalone.bat{code} we see about two to three seconds spent in this loop:

{code}
rem Setup directories, note directories with spaces do not work
set "CONSOLIDATED_OPTS=%JAVA_OPTS% %SERVER_OPTS%"
:DIRLOOP
echo(%CONSOLIDATED_OPTS% | findstr /r /c:"^-Djboss.server.base.dir" > nul && (
  for /f "tokens=1,2* delims==" %%a IN ("%CONSOLIDATED_OPTS%") DO (
    for /f %%i IN ("%%b") DO set "JBOSS_BASE_DIR=%%~fi"
  )
)
echo(%CONSOLIDATED_OPTS% | findstr /r /c:"^-Djboss.server.config.dir" > nul && (
  for /f "tokens=1,2* delims==" %%a IN ("%CONSOLIDATED_OPTS%") DO (
    for /f %%i IN ("%%b") DO set "JBOSS_CONFIG_DIR=%%~fi"
  )
)
echo(%CONSOLIDATED_OPTS% | findstr /r /c:"^-Djboss.server.log.dir" > nul && (
  for /f "tokens=1,2* delims==" %%a IN ("%CONSOLIDATED_OPTS%") DO (
    for /f %%i IN ("%%b") DO set "JBOSS_LOG_DIR=%%~fi"
  )
)

for /f "tokens=1* delims= " %%i IN ("%CONSOLIDATED_OPTS%") DO (
  if %%i == "" (
    goto ENDDIRLOOP
  ) else (
    set CONSOLIDATED_OPTS=%%j
    GOTO DIRLOOP
  )
)

:ENDDIRLOOP
{code}

It does not seem to define any variables by default, simply removing the code noticeably reduces start up time. 

Windows 7, 64 bit, SSD

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 10:22:02 2013
From: jira-events at lists.jboss.org (Philippe Marschall (JIRA))
Date: Mon, 21 Oct 2013 10:22:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2348) standalone.bat very slow
In-Reply-To: <JIRA.12508361.1382365222000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508361.1382365222000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508361.1382365222000.8684.1382365322701@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Philippe Marschall updated WFLY-2348:
-------------------------------------

    Summary: standalone.bat very slow  (was: standalone.bat very slow on windows)

    
> standalone.bat very slow
> ------------------------
>
>                 Key: WFLY-2348
>                 URL: https://issues.jboss.org/browse/WFLY-2348
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Scripts
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Philippe Marschall
>            Assignee: Brian Stansberry
>
> With a plain WildFly AS downloaded and executing {code}standalone.bat{code} we see about two to three seconds spent in this loop:
> {code}
> rem Setup directories, note directories with spaces do not work
> set "CONSOLIDATED_OPTS=%JAVA_OPTS% %SERVER_OPTS%"
> :DIRLOOP
> echo(%CONSOLIDATED_OPTS% | findstr /r /c:"^-Djboss.server.base.dir" > nul && (
>   for /f "tokens=1,2* delims==" %%a IN ("%CONSOLIDATED_OPTS%") DO (
>     for /f %%i IN ("%%b") DO set "JBOSS_BASE_DIR=%%~fi"
>   )
> )
> echo(%CONSOLIDATED_OPTS% | findstr /r /c:"^-Djboss.server.config.dir" > nul && (
>   for /f "tokens=1,2* delims==" %%a IN ("%CONSOLIDATED_OPTS%") DO (
>     for /f %%i IN ("%%b") DO set "JBOSS_CONFIG_DIR=%%~fi"
>   )
> )
> echo(%CONSOLIDATED_OPTS% | findstr /r /c:"^-Djboss.server.log.dir" > nul && (
>   for /f "tokens=1,2* delims==" %%a IN ("%CONSOLIDATED_OPTS%") DO (
>     for /f %%i IN ("%%b") DO set "JBOSS_LOG_DIR=%%~fi"
>   )
> )
> for /f "tokens=1* delims= " %%i IN ("%CONSOLIDATED_OPTS%") DO (
>   if %%i == "" (
>     goto ENDDIRLOOP
>   ) else (
>     set CONSOLIDATED_OPTS=%%j
>     GOTO DIRLOOP
>   )
> )
> :ENDDIRLOOP
> {code}
> It does not seem to define any variables by default, simply removing the code noticeably reduces start up time. 
> Windows 7, 64 bit, SSD

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 10:32:02 2013
From: jira-events at lists.jboss.org (Eduardo Martins (JIRA))
Date: Mon, 21 Oct 2013 10:32:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2027) EE Default DataSource is not
	working
In-Reply-To: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500313.1378739268000.8727.1382365922437@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823618#comment-12823618 ] 

Eduardo Martins commented on WFLY-2027:
---------------------------------------

What do you mean with not from EE7/JPA 2.1? Java EE 7 spec includes JPA 2.1, and within JPA 2.1 spec there is that section 8.2.1.5 which you quoted, I confirmed that now. Doesn't that says in Java EE the container is responsible for providing a default data source if the persistence.xml has no "jta-data-source" and no "non-jta-data-source"?
                
> EE Default DataSource is not working
> ------------------------------------
>
>                 Key: WFLY-2027
>                 URL: https://issues.jboss.org/browse/WFLY-2027
>             Project: WildFly
>          Issue Type: Bug
>          Components: ConfigAdmin, Domain Management, EE, JCA, JPA / Hibernate, Web Console
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Lincoln Baxter III
>            Assignee: Eduardo Martins
>             Fix For: 8.0.0.Beta1
>
>
> The EE spec states that a default datasource must be supplied under: java:comp/DefaultDataSource, and if none is specified by the @Resource or persistence.xml, it must be assumed:
>  {code}EE 5.19
> The Java EE Platform requires that a Java EE Product Provider provide a database 
> in the operational environment (see Section EE.2.6, ?Database?). The Java EE 
> Product Provider must also provide a preconfigured, default data source for use by 
> the application in accessing this database.
> The Java EE Product Provider must make the default data source accessible to 
> the application under the JNDI name java:comp/DefaultDataSource.
> The Application Component Provider or Deployer may explicitly bind a 
> DataSource resource reference to the default data source using the lookup element 
> of the Resource annotation or the lookup-name element of the resource-ref
> deployment descriptor element. For example,
> @Resource(lookup="java:comp/DefaultDataSource")
> DataSource myDS;
> In the absence of such a binding, the mapping of the reference will default to 
> the product's default data source.
> For example, the following will map to a preconfigured data source for the 
> product's default database:
> @Resource
> DataSource myDS;{code}
> This, isn't working however:
> {code}
> <persistence version="2.1" xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>    xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/persistence/persistence_2_1.xsd">
>    <persistence-unit name="default" transaction-type="JTA">
>    </persistence-unit>
> </persistence>{code}
> Results in: 
> {code}
> 10:41:31,002 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 50) MSC000001: Failed to start service jboss.persistenceunit."jpa-standard.war#default": org.jboss.msc.service.StartException in service jboss.persistenceunit."jpa-standard.war#default": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:134) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.determineDialect(DialectFactoryImpl.java:98)
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.buildDialect(DialectFactoryImpl.java:66)
> 	at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:193)
> 	at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:88)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:159)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131)
> 	at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration.java:1844)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1802)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:844)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835)
> 	at org.jboss.as.jpa.hibernate4.management.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:115) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	... 4 more
> 10:41:31,010 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"jpa-standard.war#default\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"jpa-standard.war#default\": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
>     Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set"}}
> {code}
> Additionally, actually specifying the expected JDNI name of the default DS like this:
> {code}   <persistence-unit name="default" transaction-type="JTA">
>       <jta-data-source>java:comp/DefaultDataSource</jta-data-source>
>       <exclude-unlisted-classes>false</exclude-unlisted-classes>
>    </persistence-unit>{code}
> Results in this:
> {code}
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.naming.context.java.module.jpa-standard.jpa-standard.DefaultDataSource (missing) dependents: [service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__] 
>       service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__ (missing) dependents: [service jboss.deployment.unit."jpa-standard.war".POST_MODULE] 
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Mon Oct 21 10:36:03 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Mon, 21 Oct 2013 10:36:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-251) Classloader fails to resolve
 when annotation and declared class have the same name
In-Reply-To: <JIRA.12500015.1378364475000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500015.1378364475000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500015.1378364475000.8749.1382366163671@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-251:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> Classloader fails to resolve when annotation and declared class have the same name
> ----------------------------------------------------------------------------------
>
>                 Key: DROOLS-251
>                 URL: https://issues.jboss.org/browse/DROOLS-251
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.CR2
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> package test
> declare Annot
>   fld : int @Annot
> end
> The packagebuilder type resolver will confuse the annotation with the declared class and throw exceptions (varies depending on optional import
> statements)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 10:36:03 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Mon, 21 Oct 2013 10:36:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-251) Classloader fails to resolve
 when annotation and declared class have the same name
In-Reply-To: <JIRA.12500015.1378364475000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500015.1378364475000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500015.1378364475000.8751.1382366163751@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-251.
--------------------------------

    Resolution: Done

    
> Classloader fails to resolve when annotation and declared class have the same name
> ----------------------------------------------------------------------------------
>
>                 Key: DROOLS-251
>                 URL: https://issues.jboss.org/browse/DROOLS-251
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.CR2
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> package test
> declare Annot
>   fld : int @Annot
> end
> The packagebuilder type resolver will confuse the annotation with the declared class and throw exceptions (varies depending on optional import
> statements)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 10:38:02 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Mon, 21 Oct 2013 10:38:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2027) EE Default DataSource is not
	working
In-Reply-To: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500313.1378739268000.8765.1382366282436@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823619#comment-12823619 ] 

Scott Marlow commented on WFLY-2027:
------------------------------------

Excellent question, I mean that the above (JPA spec) text was added to the earlier JPA 2.0 specification, which went into EE 6 (before the default data source concept was introduced into the EE 7 spec later).

{quote}
JPA 2.0 spec (EE 6) section 8.2.1.5 jta-data-source, non-jta-data-source

In Java EE environments, the jta-data-source and non-jta-data-source elements are used to specify the global JNDI name of the JTA and/or non-JTA data source to be used by the persistence provider. If neither is specified, the deployer must specify a JTA data source at deployment or a JTA data source must be provided by the container, and a JTA EntityManagerFactory will be created to correspond to it.

These elements name the data source in the local environment; the format of these names and the ability to specify the names are product specific.

In Java SE environments, these elements may be used or the data source information may be specified by other means?depending upon the requirements of the provider.
{quote}

                
> EE Default DataSource is not working
> ------------------------------------
>
>                 Key: WFLY-2027
>                 URL: https://issues.jboss.org/browse/WFLY-2027
>             Project: WildFly
>          Issue Type: Bug
>          Components: ConfigAdmin, Domain Management, EE, JCA, JPA / Hibernate, Web Console
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Lincoln Baxter III
>            Assignee: Eduardo Martins
>             Fix For: 8.0.0.Beta1
>
>
> The EE spec states that a default datasource must be supplied under: java:comp/DefaultDataSource, and if none is specified by the @Resource or persistence.xml, it must be assumed:
>  {code}EE 5.19
> The Java EE Platform requires that a Java EE Product Provider provide a database 
> in the operational environment (see Section EE.2.6, ?Database?). The Java EE 
> Product Provider must also provide a preconfigured, default data source for use by 
> the application in accessing this database.
> The Java EE Product Provider must make the default data source accessible to 
> the application under the JNDI name java:comp/DefaultDataSource.
> The Application Component Provider or Deployer may explicitly bind a 
> DataSource resource reference to the default data source using the lookup element 
> of the Resource annotation or the lookup-name element of the resource-ref
> deployment descriptor element. For example,
> @Resource(lookup="java:comp/DefaultDataSource")
> DataSource myDS;
> In the absence of such a binding, the mapping of the reference will default to 
> the product's default data source.
> For example, the following will map to a preconfigured data source for the 
> product's default database:
> @Resource
> DataSource myDS;{code}
> This, isn't working however:
> {code}
> <persistence version="2.1" xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>    xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/persistence/persistence_2_1.xsd">
>    <persistence-unit name="default" transaction-type="JTA">
>    </persistence-unit>
> </persistence>{code}
> Results in: 
> {code}
> 10:41:31,002 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 50) MSC000001: Failed to start service jboss.persistenceunit."jpa-standard.war#default": org.jboss.msc.service.StartException in service jboss.persistenceunit."jpa-standard.war#default": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:134) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.determineDialect(DialectFactoryImpl.java:98)
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.buildDialect(DialectFactoryImpl.java:66)
> 	at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:193)
> 	at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:88)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:159)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131)
> 	at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration.java:1844)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1802)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:844)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835)
> 	at org.jboss.as.jpa.hibernate4.management.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:115) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	... 4 more
> 10:41:31,010 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"jpa-standard.war#default\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"jpa-standard.war#default\": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
>     Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set"}}
> {code}
> Additionally, actually specifying the expected JDNI name of the default DS like this:
> {code}   <persistence-unit name="default" transaction-type="JTA">
>       <jta-data-source>java:comp/DefaultDataSource</jta-data-source>
>       <exclude-unlisted-classes>false</exclude-unlisted-classes>
>    </persistence-unit>{code}
> Results in this:
> {code}
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.naming.context.java.module.jpa-standard.jpa-standard.DefaultDataSource (missing) dependents: [service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__] 
>       service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__ (missing) dependents: [service jboss.deployment.unit."jpa-standard.war".POST_MODULE] 
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Mon Oct 21 10:42:02 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 21 Oct 2013 10:42:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2348) standalone.bat very slow
In-Reply-To: <JIRA.12508361.1382365222000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508361.1382365222000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508361.1382365222000.8787.1382366522257@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823621#comment-12823621 ] 

Tomaz Cerar commented on WFLY-2348:
-----------------------------------

There are many issues related to our *.bat scripts, we have plan to move everything to powershell scripts that should resolve all this problems.
See WFLY-676 for more details, but we haven't managed to get to it yet :|
                
> standalone.bat very slow
> ------------------------
>
>                 Key: WFLY-2348
>                 URL: https://issues.jboss.org/browse/WFLY-2348
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Scripts
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Philippe Marschall
>            Assignee: Brian Stansberry
>
> With a plain WildFly AS downloaded and executing {code}standalone.bat{code} we see about two to three seconds spent in this loop:
> {code}
> rem Setup directories, note directories with spaces do not work
> set "CONSOLIDATED_OPTS=%JAVA_OPTS% %SERVER_OPTS%"
> :DIRLOOP
> echo(%CONSOLIDATED_OPTS% | findstr /r /c:"^-Djboss.server.base.dir" > nul && (
>   for /f "tokens=1,2* delims==" %%a IN ("%CONSOLIDATED_OPTS%") DO (
>     for /f %%i IN ("%%b") DO set "JBOSS_BASE_DIR=%%~fi"
>   )
> )
> echo(%CONSOLIDATED_OPTS% | findstr /r /c:"^-Djboss.server.config.dir" > nul && (
>   for /f "tokens=1,2* delims==" %%a IN ("%CONSOLIDATED_OPTS%") DO (
>     for /f %%i IN ("%%b") DO set "JBOSS_CONFIG_DIR=%%~fi"
>   )
> )
> echo(%CONSOLIDATED_OPTS% | findstr /r /c:"^-Djboss.server.log.dir" > nul && (
>   for /f "tokens=1,2* delims==" %%a IN ("%CONSOLIDATED_OPTS%") DO (
>     for /f %%i IN ("%%b") DO set "JBOSS_LOG_DIR=%%~fi"
>   )
> )
> for /f "tokens=1* delims= " %%i IN ("%CONSOLIDATED_OPTS%") DO (
>   if %%i == "" (
>     goto ENDDIRLOOP
>   ) else (
>     set CONSOLIDATED_OPTS=%%j
>     GOTO DIRLOOP
>   )
> )
> :ENDDIRLOOP
> {code}
> It does not seem to define any variables by default, simply removing the code noticeably reduces start up time. 
> Windows 7, 64 bit, SSD

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 10:50:02 2013
From: jira-events at lists.jboss.org (Eduardo Martins (JIRA))
Date: Mon, 21 Oct 2013 10:50:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2027) EE Default DataSource is not
	working
In-Reply-To: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500313.1378739268000.8816.1382367002523@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823626#comment-12823626 ] 

Eduardo Martins commented on WFLY-2027:
---------------------------------------

Forget everything prior to EE 7, there is JPA 2.1 8.2.1.5 saying the EE container provides a default datasource, and thus that's what we need to do in Wildfly 8. That truly reads to me as the real portable way for a PU to apply for a EE platform default datasource.

Now there is nothing in the specs saying it has to be the same default datasource as java:comp/DefaultDataSource for an EJB, I guess it's fine to keep the feature in JPA config to define a specific one, but I think it would be nice to have these in sync by default, which is what my patch at WFLY-2212 "starts".
                
> EE Default DataSource is not working
> ------------------------------------
>
>                 Key: WFLY-2027
>                 URL: https://issues.jboss.org/browse/WFLY-2027
>             Project: WildFly
>          Issue Type: Bug
>          Components: ConfigAdmin, Domain Management, EE, JCA, JPA / Hibernate, Web Console
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Lincoln Baxter III
>            Assignee: Eduardo Martins
>             Fix For: 8.0.0.Beta1
>
>
> The EE spec states that a default datasource must be supplied under: java:comp/DefaultDataSource, and if none is specified by the @Resource or persistence.xml, it must be assumed:
>  {code}EE 5.19
> The Java EE Platform requires that a Java EE Product Provider provide a database 
> in the operational environment (see Section EE.2.6, ?Database?). The Java EE 
> Product Provider must also provide a preconfigured, default data source for use by 
> the application in accessing this database.
> The Java EE Product Provider must make the default data source accessible to 
> the application under the JNDI name java:comp/DefaultDataSource.
> The Application Component Provider or Deployer may explicitly bind a 
> DataSource resource reference to the default data source using the lookup element 
> of the Resource annotation or the lookup-name element of the resource-ref
> deployment descriptor element. For example,
> @Resource(lookup="java:comp/DefaultDataSource")
> DataSource myDS;
> In the absence of such a binding, the mapping of the reference will default to 
> the product's default data source.
> For example, the following will map to a preconfigured data source for the 
> product's default database:
> @Resource
> DataSource myDS;{code}
> This, isn't working however:
> {code}
> <persistence version="2.1" xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>    xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/persistence/persistence_2_1.xsd">
>    <persistence-unit name="default" transaction-type="JTA">
>    </persistence-unit>
> </persistence>{code}
> Results in: 
> {code}
> 10:41:31,002 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 50) MSC000001: Failed to start service jboss.persistenceunit."jpa-standard.war#default": org.jboss.msc.service.StartException in service jboss.persistenceunit."jpa-standard.war#default": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:134) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.determineDialect(DialectFactoryImpl.java:98)
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.buildDialect(DialectFactoryImpl.java:66)
> 	at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:193)
> 	at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:88)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:159)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131)
> 	at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration.java:1844)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1802)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:844)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835)
> 	at org.jboss.as.jpa.hibernate4.management.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:115) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	... 4 more
> 10:41:31,010 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"jpa-standard.war#default\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"jpa-standard.war#default\": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
>     Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set"}}
> {code}
> Additionally, actually specifying the expected JDNI name of the default DS like this:
> {code}   <persistence-unit name="default" transaction-type="JTA">
>       <jta-data-source>java:comp/DefaultDataSource</jta-data-source>
>       <exclude-unlisted-classes>false</exclude-unlisted-classes>
>    </persistence-unit>{code}
> Results in this:
> {code}
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.naming.context.java.module.jpa-standard.jpa-standard.DefaultDataSource (missing) dependents: [service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__] 
>       service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__ (missing) dependents: [service jboss.deployment.unit."jpa-standard.war".POST_MODULE] 
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Mon Oct 21 10:56:02 2013
From: jira-events at lists.jboss.org (Eduardo Martins (JIRA))
Date: Mon, 21 Oct 2013 10:56:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2027) EE Default DataSource is not
	working
In-Reply-To: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500313.1378739268000.8842.1382367362281@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823627#comment-12823627 ] 

Eduardo Martins commented on WFLY-2027:
---------------------------------------

I still think there are no reasons for keeping this issue open, section EE 5.19 that is in the issue descriptor is about @Resource and <resource-ref/>, not persistence-unit.xml, and every java:comp context instance in Wildfly has java:comp/DefaultDataSource bound...
                
> EE Default DataSource is not working
> ------------------------------------
>
>                 Key: WFLY-2027
>                 URL: https://issues.jboss.org/browse/WFLY-2027
>             Project: WildFly
>          Issue Type: Bug
>          Components: ConfigAdmin, Domain Management, EE, JCA, JPA / Hibernate, Web Console
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Lincoln Baxter III
>            Assignee: Eduardo Martins
>             Fix For: 8.0.0.Beta1
>
>
> The EE spec states that a default datasource must be supplied under: java:comp/DefaultDataSource, and if none is specified by the @Resource or persistence.xml, it must be assumed:
>  {code}EE 5.19
> The Java EE Platform requires that a Java EE Product Provider provide a database 
> in the operational environment (see Section EE.2.6, ?Database?). The Java EE 
> Product Provider must also provide a preconfigured, default data source for use by 
> the application in accessing this database.
> The Java EE Product Provider must make the default data source accessible to 
> the application under the JNDI name java:comp/DefaultDataSource.
> The Application Component Provider or Deployer may explicitly bind a 
> DataSource resource reference to the default data source using the lookup element 
> of the Resource annotation or the lookup-name element of the resource-ref
> deployment descriptor element. For example,
> @Resource(lookup="java:comp/DefaultDataSource")
> DataSource myDS;
> In the absence of such a binding, the mapping of the reference will default to 
> the product's default data source.
> For example, the following will map to a preconfigured data source for the 
> product's default database:
> @Resource
> DataSource myDS;{code}
> This, isn't working however:
> {code}
> <persistence version="2.1" xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>    xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/persistence/persistence_2_1.xsd">
>    <persistence-unit name="default" transaction-type="JTA">
>    </persistence-unit>
> </persistence>{code}
> Results in: 
> {code}
> 10:41:31,002 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 50) MSC000001: Failed to start service jboss.persistenceunit."jpa-standard.war#default": org.jboss.msc.service.StartException in service jboss.persistenceunit."jpa-standard.war#default": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:134) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.determineDialect(DialectFactoryImpl.java:98)
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.buildDialect(DialectFactoryImpl.java:66)
> 	at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:193)
> 	at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:88)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:159)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131)
> 	at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration.java:1844)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1802)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:844)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835)
> 	at org.jboss.as.jpa.hibernate4.management.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:115) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	... 4 more
> 10:41:31,010 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"jpa-standard.war#default\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"jpa-standard.war#default\": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
>     Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set"}}
> {code}
> Additionally, actually specifying the expected JDNI name of the default DS like this:
> {code}   <persistence-unit name="default" transaction-type="JTA">
>       <jta-data-source>java:comp/DefaultDataSource</jta-data-source>
>       <exclude-unlisted-classes>false</exclude-unlisted-classes>
>    </persistence-unit>{code}
> Results in this:
> {code}
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.naming.context.java.module.jpa-standard.jpa-standard.DefaultDataSource (missing) dependents: [service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__] 
>       service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__ (missing) dependents: [service jboss.deployment.unit."jpa-standard.war".POST_MODULE] 
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Mon Oct 21 11:04:02 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Mon, 21 Oct 2013 11:04:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2241) Naming subsystem transformers
	for 7.2.0
In-Reply-To: <JIRA.12502327.1381146366000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502327.1381146366000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502327.1381146366000.8885.1382367842064@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan reassigned WFLY-2241:
--------------------------------

    Assignee: Kabir Khan  (was: Brian Stansberry)

    
> Naming subsystem transformers for 7.2.0
> ---------------------------------------
>
>                 Key: WFLY-2241
>                 URL: https://issues.jboss.org/browse/WFLY-2241
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Naming
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 11:13:02 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Mon, 21 Oct 2013 11:13:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2241) Naming subsystem transformers
	for 7.2.0
In-Reply-To: <JIRA.12502327.1381146366000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502327.1381146366000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502327.1381146366000.8906.1382368382049@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan reassigned WFLY-2241:
--------------------------------

    Assignee: Stuart Douglas  (was: Kabir Khan)


I've set up Naming120TransformersTestCase to run against AS 7.2.0 in my subsystem-and-core-model-tests-against-EAP branch. I've not looked to carefully, but have some doubts about the tests since the modeldiff from WF head to 7.2.0 is:
{code}
====== Resource root address: ["subsystem" => "naming"] - Current version: 2.0.0; legacy version: 1.2.0 =======
--- Problems for relative address to root ["binding" => "*"]:
Missing attributes in current: []; missing in legacy [cache]
Missing parameters for operation 'add' in current: []; missing in legacy [cache]
{code}

And we actually seem to be checking that we cannot add a something with a binding-type=external-context. At the least there should be something showing that a binding with a 'cache' attribute with the wrong value can not be added.
                
> Naming subsystem transformers for 7.2.0
> ---------------------------------------
>
>                 Key: WFLY-2241
>                 URL: https://issues.jboss.org/browse/WFLY-2241
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Naming
>            Reporter: Kabir Khan
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 11:23:02 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Mon, 21 Oct 2013 11:23:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2241) Naming subsystem transformers
	for 7.2.0
In-Reply-To: <JIRA.12502327.1381146366000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502327.1381146366000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502327.1381146366000.8936.1382368982206@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan reassigned WFLY-2241:
--------------------------------

    Assignee: Kabir Khan  (was: Stuart Douglas)


Actually, never mind. I think I see what I need to do
                
> Naming subsystem transformers for 7.2.0
> ---------------------------------------
>
>                 Key: WFLY-2241
>                 URL: https://issues.jboss.org/browse/WFLY-2241
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Naming
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 11:42:02 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Mon, 21 Oct 2013 11:42:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2027) EE Default DataSource is not
	working
In-Reply-To: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500313.1378739268000.8983.1382370122534@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823646#comment-12823646 ] 

Scott Marlow commented on WFLY-2027:
------------------------------------

Regarding forgetting about earlier EE releases, I disagree about that line of understanding the current EE 7 requirements.  We can't go back in time and re-invent what was intended by earlier EE/JPA spec versions (the JPA intent back in the EE 6 days was not for the container to use the EE product level default data source as there was no such thing).  To me, this part of the discussion only determines what is an EE 7 specification requirement for the (JPA) container.

I see no reason to keep this jira open either and no one has given a strong enough "EE compliance" counter argument for this jira to be open.

No one has of yet argued against WFLY-2212 being fixed, which is encouraging for those that want it.   :)
                
> EE Default DataSource is not working
> ------------------------------------
>
>                 Key: WFLY-2027
>                 URL: https://issues.jboss.org/browse/WFLY-2027
>             Project: WildFly
>          Issue Type: Bug
>          Components: ConfigAdmin, Domain Management, EE, JCA, JPA / Hibernate, Web Console
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Lincoln Baxter III
>            Assignee: Eduardo Martins
>             Fix For: 8.0.0.Beta1
>
>
> The EE spec states that a default datasource must be supplied under: java:comp/DefaultDataSource, and if none is specified by the @Resource or persistence.xml, it must be assumed:
>  {code}EE 5.19
> The Java EE Platform requires that a Java EE Product Provider provide a database 
> in the operational environment (see Section EE.2.6, ?Database?). The Java EE 
> Product Provider must also provide a preconfigured, default data source for use by 
> the application in accessing this database.
> The Java EE Product Provider must make the default data source accessible to 
> the application under the JNDI name java:comp/DefaultDataSource.
> The Application Component Provider or Deployer may explicitly bind a 
> DataSource resource reference to the default data source using the lookup element 
> of the Resource annotation or the lookup-name element of the resource-ref
> deployment descriptor element. For example,
> @Resource(lookup="java:comp/DefaultDataSource")
> DataSource myDS;
> In the absence of such a binding, the mapping of the reference will default to 
> the product's default data source.
> For example, the following will map to a preconfigured data source for the 
> product's default database:
> @Resource
> DataSource myDS;{code}
> This, isn't working however:
> {code}
> <persistence version="2.1" xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>    xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/persistence/persistence_2_1.xsd">
>    <persistence-unit name="default" transaction-type="JTA">
>    </persistence-unit>
> </persistence>{code}
> Results in: 
> {code}
> 10:41:31,002 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 50) MSC000001: Failed to start service jboss.persistenceunit."jpa-standard.war#default": org.jboss.msc.service.StartException in service jboss.persistenceunit."jpa-standard.war#default": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:134) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.determineDialect(DialectFactoryImpl.java:98)
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.buildDialect(DialectFactoryImpl.java:66)
> 	at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:193)
> 	at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:88)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:159)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131)
> 	at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration.java:1844)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1802)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:844)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835)
> 	at org.jboss.as.jpa.hibernate4.management.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:115) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	... 4 more
> 10:41:31,010 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"jpa-standard.war#default\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"jpa-standard.war#default\": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
>     Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set"}}
> {code}
> Additionally, actually specifying the expected JDNI name of the default DS like this:
> {code}   <persistence-unit name="default" transaction-type="JTA">
>       <jta-data-source>java:comp/DefaultDataSource</jta-data-source>
>       <exclude-unlisted-classes>false</exclude-unlisted-classes>
>    </persistence-unit>{code}
> Results in this:
> {code}
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.naming.context.java.module.jpa-standard.jpa-standard.DefaultDataSource (missing) dependents: [service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__] 
>       service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__ (missing) dependents: [service jboss.deployment.unit."jpa-standard.war".POST_MODULE] 
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Mon Oct 21 12:14:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Mon, 21 Oct 2013 12:14:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-178) NoSuchMethodError at runtime
 due to eval in query (BW chaining)
In-Reply-To: <JIRA.12495023.1372138865000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495023.1372138865000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495023.1372138865000.9058.1382372042151@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-178:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> NoSuchMethodError at runtime due to eval in query (BW chaining)
> ---------------------------------------------------------------
>
>                 Key: DROOLS-178
>                 URL: https://issues.jboss.org/browse/DROOLS-178
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Wolfgang Laun
>            Assignee: Mario Fusco
>            Priority: Critical
>
> An eval CW in a query used in a BW chaining rule compiles, but causes a NoSuchMethodError when executed.
> Exception in thread "main" java.lang.NoSuchMethodError:
> pythagoras.Rule_isTriple_17ac16f7237046ee9562afce35dfe174.eval0(III)Z
>         at pythagoras.Rule_isTriple_17ac16f7237046ee9562afce35dfe174Eval0InvokerGenerated.evaluate(Unknown
> Source)
>         at pythagoras.Rule_isTriple_17ac16f7237046ee9562afce35dfe174Eval0Invoker.evaluate(Unknown
> Source)
>         at org.drools.rule.EvalCondition.isAllowed(EvalCondition.java:114)
>         at org.drools.reteoo.EvalConditionNode.assertLeftTuple(EvalConditionNode.java:176)
>         at org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:196)
>         at org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:71)
>         at org.drools.reteoo.JoinNode.propagateFromRight(JoinNode.java:159)
>         at org.drools.reteoo.JoinNode.assertObject(JoinNode.java:148)
>         at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:497)
>         at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:382)
>         at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235)
>         at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240)
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:350)
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:311)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:847)
>         at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:269)
>         at pythagoras.Main.makeFacts(Main.java:94)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 12:35:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Mon, 21 Oct 2013 12:35:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-178) NoSuchMethodError at runtime
 due to eval in query (BW chaining)
In-Reply-To: <JIRA.12495023.1372138865000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495023.1372138865000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495023.1372138865000.9124.1382373302134@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-178.
--------------------------------

    Fix Version/s: 5.5.1.Final
                   6.0.0.Final
       Resolution: Done

    
> NoSuchMethodError at runtime due to eval in query (BW chaining)
> ---------------------------------------------------------------
>
>                 Key: DROOLS-178
>                 URL: https://issues.jboss.org/browse/DROOLS-178
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Wolfgang Laun
>            Assignee: Mario Fusco
>            Priority: Critical
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> An eval CW in a query used in a BW chaining rule compiles, but causes a NoSuchMethodError when executed.
> Exception in thread "main" java.lang.NoSuchMethodError:
> pythagoras.Rule_isTriple_17ac16f7237046ee9562afce35dfe174.eval0(III)Z
>         at pythagoras.Rule_isTriple_17ac16f7237046ee9562afce35dfe174Eval0InvokerGenerated.evaluate(Unknown
> Source)
>         at pythagoras.Rule_isTriple_17ac16f7237046ee9562afce35dfe174Eval0Invoker.evaluate(Unknown
> Source)
>         at org.drools.rule.EvalCondition.isAllowed(EvalCondition.java:114)
>         at org.drools.reteoo.EvalConditionNode.assertLeftTuple(EvalConditionNode.java:176)
>         at org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:196)
>         at org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:71)
>         at org.drools.reteoo.JoinNode.propagateFromRight(JoinNode.java:159)
>         at org.drools.reteoo.JoinNode.assertObject(JoinNode.java:148)
>         at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:497)
>         at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:382)
>         at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235)
>         at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240)
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:350)
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:311)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:847)
>         at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:269)
>         at pythagoras.Main.makeFacts(Main.java:94)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 12:47:02 2013
From: jira-events at lists.jboss.org (Jeremy Whiting (JIRA))
Date: Mon, 21 Oct 2013 12:47:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-281) Inconsistent use of
 genStringAsCharArray in Tomcat 6.
In-Reply-To: <JIRA.12508212.1382115445000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508212.1382115445000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508212.1382115445000.9149.1382374022151@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBWEB-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeremy Whiting updated JBWEB-281:
---------------------------------

    Description: 
 The JSP configuration property "genStringAsCharArray" is inconsistently named in jbossweb. This means the enabling of the feature for using char array type rather than String in generated Servlet code is not enabled.
 This issue has been fixed upstream in the 7.0 branch of Tomcat hosted at Apache.

 Can this patch be ported to jbossweb so that the 6.2 version of EAP includes this fix ?



  was:
 The JSP configuration property "genStringAsCharArray" is inconsistently named in Tomcat 6. This means the enabling of the feature for using char array type rather than String in generated Servlet code is not enabled.
 This issue has been fixed upstream in the 7.0 branch of Tomcat hosted at Apache.

I have created an ASF BZ https://issues.apache.org/bugzilla/show_bug.cgi?id=55671 to request the SVN revision https://issues.apache.org/bugzilla/show_bug.cgi?id=55671 be backported to Tomcat 6.0 branch.



    
> Inconsistent use of genStringAsCharArray in Tomcat 6.
> -----------------------------------------------------
>
>                 Key: JBWEB-281
>                 URL: https://issues.jboss.org/browse/JBWEB-281
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-7.2.1.GA
>         Environment: All environments.
>            Reporter: Jeremy Whiting
>            Assignee: Remy Maucherat
>
>  The JSP configuration property "genStringAsCharArray" is inconsistently named in jbossweb. This means the enabling of the feature for using char array type rather than String in generated Servlet code is not enabled.
>  This issue has been fixed upstream in the 7.0 branch of Tomcat hosted at Apache.
>  Can this patch be ported to jbossweb so that the 6.2 version of EAP includes this fix ?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 12:47:02 2013
From: jira-events at lists.jboss.org (Jeremy Whiting (JIRA))
Date: Mon, 21 Oct 2013 12:47:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-281) Inconsistent use of
	genStringAsCharArray.
In-Reply-To: <JIRA.12508212.1382115445000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508212.1382115445000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508212.1382115445000.9152.1382374022274@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBWEB-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeremy Whiting updated JBWEB-281:
---------------------------------

    Summary: Inconsistent use of genStringAsCharArray.  (was: Inconsistent use of genStringAsCharArray in Tomcat 6.)

    
> Inconsistent use of genStringAsCharArray.
> -----------------------------------------
>
>                 Key: JBWEB-281
>                 URL: https://issues.jboss.org/browse/JBWEB-281
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-7.2.1.GA
>         Environment: All environments.
>            Reporter: Jeremy Whiting
>            Assignee: Remy Maucherat
>
>  The JSP configuration property "genStringAsCharArray" is inconsistently named in jbossweb. This means the enabling of the feature for using char array type rather than String in generated Servlet code is not enabled.
>  This issue has been fixed upstream in the 7.0 branch of Tomcat hosted at Apache.
>  Can this patch be ported to jbossweb so that the 6.2 version of EAP includes this fix ?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 12:49:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 21 Oct 2013 12:49:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-74) REMJMX-65 Overzealous
 disabling local authentication
In-Reply-To: <JIRA.12508386.1382374102930@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508386.1382374102930@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508386.1382374102930.9155.1382374142075@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created REMJMX-74:
--------------------------------------

             Summary: REMJMX-65 Overzealous disabling local authentication
                 Key: REMJMX-74
                 URL: https://issues.jboss.org/browse/REMJMX-74
             Project: Remoting JMX
          Issue Type: Bug
          Components: Connection
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 1.1.2.CR1, 2.0.0.CR4


REMJMX-65 is overzealous at disabling local authentication, if a username and credential is supplied in the environment then it does make sense to disable local authentication - however the availability of a callback handler is not a sufficient flag to also disable it.

In the case of the callback handler the user may still only want to be prompted if the other mechanisms fail.

This issue will remove the disabling of local authentication based on the presence of a callback handler and will instead add a configuration option that can be set on the environment.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 12:53:01 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 21 Oct 2013 12:53:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-74) REMJMX-65 Overzealous
 disabling local authentication
In-Reply-To: <JIRA.12508386.1382374102000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508386.1382374102000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508386.1382374102000.9167.1382374381970@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/REMJMX-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated REMJMX-74:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1021630

    
> REMJMX-65 Overzealous disabling local authentication
> ----------------------------------------------------
>
>                 Key: REMJMX-74
>                 URL: https://issues.jboss.org/browse/REMJMX-74
>             Project: Remoting JMX
>          Issue Type: Bug
>          Components: Connection
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.2.CR1, 2.0.0.CR4
>
>
> REMJMX-65 is overzealous at disabling local authentication, if a username and credential is supplied in the environment then it does make sense to disable local authentication - however the availability of a callback handler is not a sufficient flag to also disable it.
> In the case of the callback handler the user may still only want to be prompted if the other mechanisms fail.
> This issue will remove the disabling of local authentication based on the presence of a callback handler and will instead add a configuration option that can be set on the environment.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 12:53:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 21 Oct 2013 12:53:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-74) REMJMX-65 Overzealous
 disabling local authentication
In-Reply-To: <JIRA.12508386.1382374102000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508386.1382374102000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508386.1382374102000.9170.1382374382120@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/REMJMX-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823678#comment-12823678 ] 

RH Bugzilla Integration commented on REMJMX-74:
-----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> made a comment on [bug 1021630|https://bugzilla.redhat.com/show_bug.cgi?id=1021630]

Description of problem:

Remoting JMX was enhanced to disable local authentication if a username and password is supplied or is a callback handler is supplied, the check involving the callback handler is too much as end users may want to supply the callback handler for use only if other authentication mechanisms fail.

Instead a configuration option will be added to cover the case where a CallbackHandler is supplied if the user wants to disable local authentication.
                
> REMJMX-65 Overzealous disabling local authentication
> ----------------------------------------------------
>
>                 Key: REMJMX-74
>                 URL: https://issues.jboss.org/browse/REMJMX-74
>             Project: Remoting JMX
>          Issue Type: Bug
>          Components: Connection
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.2.CR1, 2.0.0.CR4
>
>
> REMJMX-65 is overzealous at disabling local authentication, if a username and credential is supplied in the environment then it does make sense to disable local authentication - however the availability of a callback handler is not a sufficient flag to also disable it.
> In the case of the callback handler the user may still only want to be prompted if the other mechanisms fail.
> This issue will remove the disabling of local authentication based on the presence of a callback handler and will instead add a configuration option that can be set on the environment.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 12:53:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 21 Oct 2013 12:53:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-74) REMJMX-65 Overzealous
 disabling local authentication
In-Reply-To: <JIRA.12508386.1382374102000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508386.1382374102000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508386.1382374102000.9173.1382374382217@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/REMJMX-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823679#comment-12823679 ] 

RH Bugzilla Integration commented on REMJMX-74:
-----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> changed the Status of [bug 1021630|https://bugzilla.redhat.com/show_bug.cgi?id=1021630] from NEW to ASSIGNED
                
> REMJMX-65 Overzealous disabling local authentication
> ----------------------------------------------------
>
>                 Key: REMJMX-74
>                 URL: https://issues.jboss.org/browse/REMJMX-74
>             Project: Remoting JMX
>          Issue Type: Bug
>          Components: Connection
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.2.CR1, 2.0.0.CR4
>
>
> REMJMX-65 is overzealous at disabling local authentication, if a username and credential is supplied in the environment then it does make sense to disable local authentication - however the availability of a callback handler is not a sufficient flag to also disable it.
> In the case of the callback handler the user may still only want to be prompted if the other mechanisms fail.
> This issue will remove the disabling of local authentication based on the presence of a callback handler and will instead add a configuration option that can be set on the environment.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 13:01:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 21 Oct 2013 13:01:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2349) Upgrade to Remoting JMX
	2.0.0.CR4
In-Reply-To: <JIRA.12508389.1382374823408@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508389.1382374823408@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508389.1382374823408.9207.1382374862091@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-2349:
--------------------------------------

             Summary: Upgrade to Remoting JMX 2.0.0.CR4
                 Key: WFLY-2349
                 URL: https://issues.jboss.org/browse/WFLY-2349
             Project: WildFly
          Issue Type: Component  Upgrade
      Security Level: Public (Everyone can see)
          Components: JMX, Remoting
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 8.0.0.CR1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 14:43:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 21 Oct 2013 14:43:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-74) REMJMX-65 Overzealous
 disabling local authentication
In-Reply-To: <JIRA.12508386.1382374102000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508386.1382374102000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508386.1382374102000.9278.1382380982082@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/REMJMX-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved REMJMX-74.
------------------------------------

    Resolution: Done

    
> REMJMX-65 Overzealous disabling local authentication
> ----------------------------------------------------
>
>                 Key: REMJMX-74
>                 URL: https://issues.jboss.org/browse/REMJMX-74
>             Project: Remoting JMX
>          Issue Type: Bug
>          Components: Connection
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.2.CR1, 2.0.0.CR4
>
>
> REMJMX-65 is overzealous at disabling local authentication, if a username and credential is supplied in the environment then it does make sense to disable local authentication - however the availability of a callback handler is not a sufficient flag to also disable it.
> In the case of the callback handler the user may still only want to be prompted if the other mechanisms fail.
> This issue will remove the disabling of local authentication based on the presence of a callback handler and will instead add a configuration option that can be set on the environment.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 14:45:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Mon, 21 Oct 2013 14:45:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-249) Handle conflicts when using
 @position in declared types
In-Reply-To: <JIRA.12500013.1378364090000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500013.1378364090000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500013.1378364090000.9282.1382381102032@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-249:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> Handle conflicts when using @position in declared types
> -------------------------------------------------------
>
>                 Key: DROOLS-249
>                 URL: https://issues.jboss.org/browse/DROOLS-249
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.CR2
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Minor
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> declare A
>  f : int @position(2)
>  g : int @position(1)
> end
> declare B extends A
>  h : int @position(3)
>  i : int @position(2)
> end
> The resulting field order may not be deterministic because of
>  - the clashes (2)
>  - the missing pos (0)
> this is dangerous when used with positional constraints
> B( $x, $y, $z, $w ; )
> Marked as minor because of the obvious workaround

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 14:45:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Mon, 21 Oct 2013 14:45:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-249) Handle conflicts when using
 @position in declared types
In-Reply-To: <JIRA.12500013.1378364090000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500013.1378364090000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500013.1378364090000.9287.1382381102283@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-249.
--------------------------------

    Resolution: Done

    
> Handle conflicts when using @position in declared types
> -------------------------------------------------------
>
>                 Key: DROOLS-249
>                 URL: https://issues.jboss.org/browse/DROOLS-249
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.CR2
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Minor
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> declare A
>  f : int @position(2)
>  g : int @position(1)
> end
> declare B extends A
>  h : int @position(3)
>  i : int @position(2)
> end
> The resulting field order may not be deterministic because of
>  - the clashes (2)
>  - the missing pos (0)
> this is dangerous when used with positional constraints
> B( $x, $y, $z, $w ; )
> Marked as minor because of the obvious workaround

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 14:45:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 21 Oct 2013 14:45:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-75) Release 2.0.0.CR4
In-Reply-To: <JIRA.12508394.1382381097603@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508394.1382381097603@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508394.1382381097603.9290.1382381102379@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created REMJMX-75:
--------------------------------------

             Summary: Release 2.0.0.CR4
                 Key: REMJMX-75
                 URL: https://issues.jboss.org/browse/REMJMX-75
             Project: Remoting JMX
          Issue Type: Task
          Components: Build
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 2.0.0.CR4




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 14:55:02 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 21 Oct 2013 14:55:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2348) standalone.bat very slow
In-Reply-To: <JIRA.12508361.1382365222000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508361.1382365222000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508361.1382365222000.9305.1382381702053@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-2348:
-----------------------------------

    Assignee:     (was: Brian Stansberry)

    
> standalone.bat very slow
> ------------------------
>
>                 Key: WFLY-2348
>                 URL: https://issues.jboss.org/browse/WFLY-2348
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Scripts
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Philippe Marschall
>
> With a plain WildFly AS downloaded and executing {code}standalone.bat{code} we see about two to three seconds spent in this loop:
> {code}
> rem Setup directories, note directories with spaces do not work
> set "CONSOLIDATED_OPTS=%JAVA_OPTS% %SERVER_OPTS%"
> :DIRLOOP
> echo(%CONSOLIDATED_OPTS% | findstr /r /c:"^-Djboss.server.base.dir" > nul && (
>   for /f "tokens=1,2* delims==" %%a IN ("%CONSOLIDATED_OPTS%") DO (
>     for /f %%i IN ("%%b") DO set "JBOSS_BASE_DIR=%%~fi"
>   )
> )
> echo(%CONSOLIDATED_OPTS% | findstr /r /c:"^-Djboss.server.config.dir" > nul && (
>   for /f "tokens=1,2* delims==" %%a IN ("%CONSOLIDATED_OPTS%") DO (
>     for /f %%i IN ("%%b") DO set "JBOSS_CONFIG_DIR=%%~fi"
>   )
> )
> echo(%CONSOLIDATED_OPTS% | findstr /r /c:"^-Djboss.server.log.dir" > nul && (
>   for /f "tokens=1,2* delims==" %%a IN ("%CONSOLIDATED_OPTS%") DO (
>     for /f %%i IN ("%%b") DO set "JBOSS_LOG_DIR=%%~fi"
>   )
> )
> for /f "tokens=1* delims= " %%i IN ("%CONSOLIDATED_OPTS%") DO (
>   if %%i == "" (
>     goto ENDDIRLOOP
>   ) else (
>     set CONSOLIDATED_OPTS=%%j
>     GOTO DIRLOOP
>   )
> )
> :ENDDIRLOOP
> {code}
> It does not seem to define any variables by default, simply removing the code noticeably reduces start up time. 
> Windows 7, 64 bit, SSD

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 14:57:01 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 21 Oct 2013 14:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-75) Release 2.0.0.CR4
In-Reply-To: <JIRA.12508394.1382381097000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508394.1382381097000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508394.1382381097000.9308.1382381821939@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/REMJMX-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved REMJMX-75.
------------------------------------

    Resolution: Done

    
> Release 2.0.0.CR4
> -----------------
>
>                 Key: REMJMX-75
>                 URL: https://issues.jboss.org/browse/REMJMX-75
>             Project: Remoting JMX
>          Issue Type: Task
>          Components: Build
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 2.0.0.CR4
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 14:59:02 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 21 Oct 2013 14:59:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1954) Exceptions when operating on
	domain mode
In-Reply-To: <JIRA.12499374.1377530442000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499374.1377530442000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499374.1377530442000.9313.1382381942091@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry resolved WFLY-1954.
------------------------------------

    Resolution: Duplicate Issue


I'm going to assume this was the same thing as the issue reported/fixed in WFLY-2273.
                
> Exceptions when operating on domain mode
> ----------------------------------------
>
>                 Key: WFLY-1954
>                 URL: https://issues.jboss.org/browse/WFLY-1954
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> When refreshing the topology view form the web console, you'll see a lot of these:
> {noformat}
> [Host Controller] 17:16:58,942 ERROR [org.jboss.as.controller.client] (XNIO-1 task-9) JBAS014781: Step handler org.jboss.as.domain.controller.operations.coordination.DomainFinalResultHandler at 5601ac22 for operation composite at address [] failed handling operation rollback -- null
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 15:38:01 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 21 Oct 2013 15:38:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2350) Services calling
 XAResourceRecoveryRegistry.removeXAResourceRecovery in stop must use MSC
 async API
In-Reply-To: <JIRA.12508395.1382384213728@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508395.1382384213728@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508395.1382384213728.9345.1382384281944@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-2350:
--------------------------------------

             Summary: Services calling XAResourceRecoveryRegistry.removeXAResourceRecovery in stop must use MSC async API
                 Key: WFLY-2350
                 URL: https://issues.jboss.org/browse/WFLY-2350
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Transactions
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: 8.0.0.CR1


XAResourceRecoveryRegistry.removeXAResourceRecovery is a blocking API, so MSC services that call it in stop() must use StopContext.asynchronous().

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 16:10:02 2013
From: jira-events at lists.jboss.org (Adam Baxter (JIRA))
Date: Mon, 21 Oct 2013 16:10:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-305) ReleaseIdImpl implicitly
 required in KieBuilder implementation
In-Reply-To: <JIRA.12508397.1382386123820@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508397.1382386123820@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508397.1382386123820.9391.1382386202297@jira02.app.mwc.hst.phx2.redhat.com>

Adam Baxter created DROOLS-305:
----------------------------------

             Summary: ReleaseIdImpl implicitly required in KieBuilder implementation
                 Key: DROOLS-305
                 URL: https://issues.jboss.org/browse/DROOLS-305
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  6.0.0.CR4
         Environment: Fedora 19, JBoss EAP 6.1.1
            Reporter: Adam Baxter
            Assignee: Mark Proctor


Drools implicitly requires ReleaseIdImpl in its implementation for loading a kjar. Any classes implementing ReleaseId will cause ClassCastExceptions during load:

Caused by: java.lang.ClassCastException: org.jbpm.ee.support.KieReleaseId cannot be cast to org.drools.compiler.kproject.ReleaseIdImpl
	at org.drools.compiler.kie.builder.impl.KieBuilderImpl.getCompilationCachePath(KieBuilderImpl.java:289) [drools-compiler-6.0.0.CR4.jar:6.0.0.CR4]
	at org.drools.compiler.kie.builder.impl.AbstractKieModule.getCompilationCache(AbstractKieModule.java:300) [drools-compiler-6.0.0.CR4.jar:6.0.0.CR4]
	at org.drools.compiler.kie.builder.impl.AbstractKieModule.buildKnowledgePackages(AbstractKieModule.java:164) [drools-compiler-6.0.0.CR4.jar:6.0.0.CR4]
	at org.drools.compiler.kie.builder.impl.AbstractKieProject.verify(AbstractKieProject.java:39) [drools-compiler-6.0.0.CR4.jar:6.0.0.CR4]
	at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildKieProject(KieBuilderImpl.java:305) [drools-compiler-6.0.0.CR4.jar:6.0.0.CR4]
	at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildKieModule(KieBuilderImpl.java:300) [drools-compiler-6.0.0.CR4.jar:6.0.0.CR4]
	at org.kie.scanner.KieRepositoryScannerImpl.build(KieRepositoryScannerImpl.java:164) [kie-ci-6.0.0.CR4.jar:6.0.0.CR4]
	at org.kie.scanner.KieRepositoryScannerImpl.buildArtifact(KieRepositoryScannerImpl.java:119) [kie-ci-6.0.0.CR4.jar:6.0.0.CR4]
	at org.kie.scanner.KieRepositoryScannerImpl.loadArtifact(KieRepositoryScannerImpl.java:89) [kie-ci-6.0.0.CR4.jar:6.0.0.CR4]
	at org.kie.scanner.KieRepositoryScannerImpl.loadArtifact(KieRepositoryScannerImpl.java:82) [kie-ci-6.0.0.CR4.jar:6.0.0.CR4]
	at org.drools.compiler.kie.builder.impl.KieRepositoryImpl.loadKieModuleFromMavenRepo(KieRepositoryImpl.java:109) [drools-compiler-6.0.0.CR4.jar:6.0.0.CR4]
	at org.drools.compiler.kie.builder.impl.KieRepositoryImpl.getKieModule(KieRepositoryImpl.java:95) [drools-compiler-6.0.0.CR4.jar:6.0.0.CR4]
	at org.drools.compiler.kie.builder.impl.KieRepositoryImpl.getKieModule(KieRepositoryImpl.java:76) [drools-compiler-6.0.0.CR4.jar:6.0.0.CR4]
	at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:82) [drools-compiler-6.0.0.CR4.jar:6.0.0.CR4]
	at org.jbpm.ee.startup.KnowledgeManagerBean.getKieContainer(KnowledgeManagerBean.java:61) [test-jbpm-services.jar:]
	at org.jbpm.ee.startup.KnowledgeManagerBean.getKieBase(KnowledgeManagerBean.java:74) [test-jbpm-services.jar:]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_25]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_25]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_25]
	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_25]
	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72) [jboss-as-ee-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:58) [jboss-as-ee-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:374) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:129) [jboss-as-weld-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10]
	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:137) [jboss-as-weld-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10]
	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:58) [jboss-as-ee-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:58) [jboss-as-ee-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [jboss-as-ejb3-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:374) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
	at org.jboss.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:104) [jboss-as-ejb3-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:74) [jboss-as-weld-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53) [jboss-as-ee-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
	at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:52) [jboss-as-ejb3-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:226) [jboss-as-ejb3-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10]
	... 186 more



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 16:16:02 2013
From: jira-events at lists.jboss.org (Stefan Guilhen (JIRA))
Date: Mon, 21 Oct 2013 16:16:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-753) PicketBox Logger logging
 does not mask credentials when logging LDAP connection environment
In-Reply-To: <JIRA.12508399.1382386499674@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508399.1382386499674@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508399.1382386499674.9408.1382386562769@jira02.app.mwc.hst.phx2.redhat.com>

Stefan Guilhen created SECURITY-753:
---------------------------------------

             Summary: PicketBox Logger logging does not mask credentials when logging LDAP connection environment
                 Key: SECURITY-753
                 URL: https://issues.jboss.org/browse/SECURITY-753
             Project: PicketBox 
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JBossSX
    Affects Versions: PicketBox_4_0_20.Beta1
            Reporter: Stefan Guilhen
            Assignee: Stefan Guilhen
             Fix For: PicketBox_4_0_20.Beta2


It was reported that the PicketBoxLogger interface logs the client credentials when TRACE level is set. Although we do not consider this a security flaw in itself, we do recommend that this be considered as a candidate for a security-in-depth fix. 

At the very least, the default implementation should mask the authenticating user's credentials. The bindCredential value is already available in the configuration, however this too can be considered an issue if the configuration files use encrypted passwords.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 16:20:02 2013
From: jira-events at lists.jboss.org (Adam Baxter (JIRA))
Date: Mon, 21 Oct 2013 16:20:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-306) ReleaseIdImpl should be
	Serializable
In-Reply-To: <JIRA.12508401.1382386745778@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508401.1382386745778@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508401.1382386745778.9419.1382386802028@jira02.app.mwc.hst.phx2.redhat.com>

Adam Baxter created DROOLS-306:
----------------------------------

             Summary: ReleaseIdImpl should be Serializable 
                 Key: DROOLS-306
                 URL: https://issues.jboss.org/browse/DROOLS-306
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  6.0.0.CR4
         Environment: Fedora 19, JBoss 6.1.1
            Reporter: Adam Baxter
            Assignee: Mark Proctor


ReleaseIdImpl is not Serializable and will not work if we need to transfer it over the wire. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 17:37:02 2013
From: jira-events at lists.jboss.org (Stefan Guilhen (JIRA))
Date: Mon, 21 Oct 2013 17:37:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-753) PicketBox Logger logging
 does not mask credentials when logging LDAP connection environment
In-Reply-To: <JIRA.12508399.1382386499000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508399.1382386499000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508399.1382386499000.9587.1382391422100@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Guilhen resolved SECURITY-753.
-------------------------------------

    Resolution: Done


The code now masks the credentials before calling the Logger.
                
> PicketBox Logger logging does not mask credentials when logging LDAP connection environment
> -------------------------------------------------------------------------------------------
>
>                 Key: SECURITY-753
>                 URL: https://issues.jboss.org/browse/SECURITY-753
>             Project: PicketBox 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: PicketBox_4_0_20.Beta1
>            Reporter: Stefan Guilhen
>            Assignee: Stefan Guilhen
>             Fix For: PicketBox_4_0_20.Beta2
>
>
> It was reported that the PicketBoxLogger interface logs the client credentials when TRACE level is set. Although we do not consider this a security flaw in itself, we do recommend that this be considered as a candidate for a security-in-depth fix. 
> At the very least, the default implementation should mask the authenticating user's credentials. The bindCredential value is already available in the configuration, however this too can be considered an issue if the configuration files use encrypted passwords.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 17:37:02 2013
From: jira-events at lists.jboss.org (Stefan Guilhen (JIRA))
Date: Mon, 21 Oct 2013 17:37:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-753) PicketBox Logger logging
 does not mask credentials when logging LDAP connection environment
In-Reply-To: <JIRA.12508399.1382386499000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508399.1382386499000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508399.1382386499000.9588.1382391422167@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Guilhen closed SECURITY-753.
-----------------------------------


    
> PicketBox Logger logging does not mask credentials when logging LDAP connection environment
> -------------------------------------------------------------------------------------------
>
>                 Key: SECURITY-753
>                 URL: https://issues.jboss.org/browse/SECURITY-753
>             Project: PicketBox 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: PicketBox_4_0_20.Beta1
>            Reporter: Stefan Guilhen
>            Assignee: Stefan Guilhen
>             Fix For: PicketBox_4_0_20.Beta2
>
>
> It was reported that the PicketBoxLogger interface logs the client credentials when TRACE level is set. Although we do not consider this a security flaw in itself, we do recommend that this be considered as a candidate for a security-in-depth fix. 
> At the very least, the default implementation should mask the authenticating user's credentials. The bindCredential value is already available in the configuration, however this too can be considered an issue if the configuration files use encrypted passwords.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 17:44:01 2013
From: jira-events at lists.jboss.org (Aaron Ogburn (JIRA))
Date: Mon, 21 Oct 2013 17:44:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-282) Lack of synchronization in
 org.apache.catalina.security.SecurityUtil
In-Reply-To: <JIRA.12508407.1382391772987@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508407.1382391772987@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508407.1382391772987.9593.1382391841907@jira02.app.mwc.hst.phx2.redhat.com>

Aaron Ogburn created JBWEB-282:
----------------------------------

             Summary: Lack of synchronization in org.apache.catalina.security.SecurityUtil
                 Key: JBWEB-282
                 URL: https://issues.jboss.org/browse/JBWEB-282
             Project: JBoss Web
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Tomcat
    Affects Versions: JBossWeb-7.2.1.GA, JBossWeb-7.0.16.GA
         Environment: -JBoss EAP 6.1.1
            Reporter: Aaron Ogburn
            Assignee: Remy Maucherat


The unsynchronized objectCache in org.apache.catalina.security.SecurityUtil can cause jboss start up and application deployments to spin on concurrent hash map access. Fixed already upstream in tomcat:

https://issues.apache.org/bugzilla/show_bug.cgi?id=50138

objectCache now needs to be a ConcurrentHashMap given our multithreaded starts.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 22:42:01 2013
From: jira-events at lists.jboss.org (Osamu Nagano (JIRA))
Date: Mon, 21 Oct 2013 22:42:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2352) Domain controller fails to
 restart due to an inconsistent rollback of a redeploy
In-Reply-To: <JIRA.12508413.1382409608174@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508413.1382409608174@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508413.1382409608174.9755.1382409721969@jira02.app.mwc.hst.phx2.redhat.com>

Osamu Nagano created WFLY-2352:
----------------------------------

             Summary: Domain controller fails to restart due to an inconsistent rollback of a redeploy
                 Key: WFLY-2352
                 URL: https://issues.jboss.org/browse/WFLY-2352
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Domain Management
    Affects Versions: 8.0.0.Alpha4
            Reporter: Osamu Nagano
            Assignee: Brian Stansberry


When you try to redeploy (or deploy with --force option) the same application which has the same contents hash, and a necessary dependency like a datasource beeing injected in the application is lost by some reason, the redeploy operation will delete the contents under $JBOSS_HOME/domain/data/content directory but won't delete entries in domain.xml. Then the domain controller fails to start up because no contents found in the directory. This likely happens when you frequently changes settings during other servers shutting down.

The domain controller fails to restart with the following log messages.
{code}
12:04:10,623 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("add") failed - address: ([("deployment" => "exampleapp.war")]) - failure description: "JBAS010876: No deployment content with hash c1306bc4855f4ed9914c9616f2b999c5c62a79d3 is available in the deployment content repository for deployment 'exampleapp.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuraiton file and restart."
12:04:10,628 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010933: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details.
{code}

The domain controller should be independent from such a server specific issue and there should be a way to fix this via CLI or Console, not by a manual editing of domain.xml.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 23:26:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 21 Oct 2013 23:26:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2352) Domain controller fails to
 restart due to an inconsistent rollback of a redeploy
In-Reply-To: <JIRA.12508413.1382409608000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508413.1382409608000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508413.1382409608000.9771.1382412362011@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2352:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1021763

    
> Domain controller fails to restart due to an inconsistent rollback of a redeploy
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-2352
>                 URL: https://issues.jboss.org/browse/WFLY-2352
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Osamu Nagano
>            Assignee: Brian Stansberry
>
> When you try to redeploy (or deploy with --force option) the same application which has the same contents hash, and a necessary dependency like a datasource beeing injected in the application is lost by some reason, the redeploy operation will delete the contents under $JBOSS_HOME/domain/data/content directory but won't delete entries in domain.xml. Then the domain controller fails to start up because no contents found in the directory. This likely happens when you frequently changes settings during other servers shutting down.
> The domain controller fails to restart with the following log messages.
> {code}
> 12:04:10,623 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("add") failed - address: ([("deployment" => "exampleapp.war")]) - failure description: "JBAS010876: No deployment content with hash c1306bc4855f4ed9914c9616f2b999c5c62a79d3 is available in the deployment content repository for deployment 'exampleapp.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuraiton file and restart."
> 12:04:10,628 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010933: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> {code}
> The domain controller should be independent from such a server specific issue and there should be a way to fix this via CLI or Console, not by a manual editing of domain.xml.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 23:28:03 2013
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Mon, 21 Oct 2013 23:28:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-307) Queries should be order
 independent within the same namespace
In-Reply-To: <JIRA.12508415.1382412390715@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508415.1382412390715@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508415.1382412390715.9774.1382412483265@jira02.app.mwc.hst.phx2.redhat.com>

Mark Proctor created DROOLS-307:
-----------------------------------

             Summary: Queries should be order independent within the same namespace
                 Key: DROOLS-307
                 URL: https://issues.jboss.org/browse/DROOLS-307
             Project: Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Mark Proctor
            Assignee: Mark Proctor




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 23:28:03 2013
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Mon, 21 Oct 2013 23:28:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-307) Queries should be order
 independent within the same namespace
In-Reply-To: <JIRA.12508415.1382412390000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508415.1382412390000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508415.1382412390000.9777.1382412483376@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mark Proctor updated DROOLS-307:
--------------------------------

    Issue Type: Bug  (was: Feature Request)

    
> Queries should be order independent within the same namespace
> -------------------------------------------------------------
>
>                 Key: DROOLS-307
>                 URL: https://issues.jboss.org/browse/DROOLS-307
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>            Assignee: Mark Proctor
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 23:28:03 2013
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Mon, 21 Oct 2013 23:28:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-307) Queries should be order
 independent within the same namespace
In-Reply-To: <JIRA.12508415.1382412390000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508415.1382412390000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508415.1382412390000.9779.1382412483478@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823783#comment-12823783 ] 

Mark Proctor commented on DROOLS-307:
-------------------------------------

Queries fail to compile, if they are not in the correct order. Compilation should be independent of order.
                
> Queries should be order independent within the same namespace
> -------------------------------------------------------------
>
>                 Key: DROOLS-307
>                 URL: https://issues.jboss.org/browse/DROOLS-307
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>            Assignee: Mark Proctor
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 23:56:02 2013
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Mon, 21 Oct 2013 23:56:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-307) Queries should be order
 independent within the same namespace
In-Reply-To: <JIRA.12508415.1382412390000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508415.1382412390000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508415.1382412390000.9783.1382414162007@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mark Proctor resolved DROOLS-307.
---------------------------------

    Fix Version/s: 6.0.0.Final
       Resolution: Done

    
> Queries should be order independent within the same namespace
> -------------------------------------------------------------
>
>                 Key: DROOLS-307
>                 URL: https://issues.jboss.org/browse/DROOLS-307
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>            Assignee: Mark Proctor
>             Fix For: 6.0.0.Final
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 23:56:02 2013
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Mon, 21 Oct 2013 23:56:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-307) Queries should be order
 independent within the same namespace
In-Reply-To: <JIRA.12508415.1382412390000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508415.1382412390000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508415.1382412390000.9786.1382414162219@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mark Proctor closed DROOLS-307.
-------------------------------


    
> Queries should be order independent within the same namespace
> -------------------------------------------------------------
>
>                 Key: DROOLS-307
>                 URL: https://issues.jboss.org/browse/DROOLS-307
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>            Assignee: Mark Proctor
>             Fix For: 6.0.0.Final
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 21 23:56:02 2013
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Mon, 21 Oct 2013 23:56:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-308) Variance Tabling for Queries
In-Reply-To: <JIRA.12508416.1382414160880@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508416.1382414160880@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508416.1382414160880.9787.1382414162308@jira02.app.mwc.hst.phx2.redhat.com>

Mark Proctor created DROOLS-308:
-----------------------------------

             Summary: Variance Tabling for Queries
                 Key: DROOLS-308
                 URL: https://issues.jboss.org/browse/DROOLS-308
             Project: Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Mark Proctor
            Assignee: Mark Proctor




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 02:18:01 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Oct 2013 02:18:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-140) KIE module injection through
 CDI does not work in container
In-Reply-To: <JIRA.12491833.1368620305000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12491833.1368620305000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12491833.1368620305000.9883.1382422681993@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823802#comment-12823802 ] 

RH Bugzilla Integration commented on DROOLS-140:
------------------------------------------------

Kanchan Desai <kadesai at redhat.com> made a comment on [bug 955193|https://bugzilla.redhat.com/show_bug.cgi?id=955193]

Hi Marek,

Can you please share some more info on this bug, probably the fix and the result.
                
> KIE module injection through CDI does not work in container
> -----------------------------------------------------------
>
>                 Key: DROOLS-140
>                 URL: https://issues.jboss.org/browse/DROOLS-140
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>             Fix For: 6.0.0.CR1
>
>
> Description of problem:
> Injection of KIE module through CDI fails on JBoss EAP 6.0/6.1 due to wrong processing of resource URI when loading pom.properties in ClasspathKieProject.
> Version-Release number of selected component (if applicable):
> BRMS 6.0.0.Beta1
> EAP 6.0, 6.1.ER4
> How reproducible:
> Deploy the attached reproducer WAR. Deployment fails, server.log contains the following error (see attachment for all errors in log):
> 15:40:29,923 INFO  [stdout] (MSC service thread 1-2) kmodules: vfs:/content/kie-cdi-war-web-app-1.0.0-SNAPSHOT.war/WEB-INF/lib/kie-cdi-war-kie-module-1.0.0-SNAPSHOT.jar/META-INF/kmodule.xml
> 15:40:29,939 ERROR [org.drools.compiler.kie.builder.impl.ClasspathKieProject] (MSC service thread 1-2) Unable to load pom.properties from/content/kie-cdi-war-web-app-1.0.0-SNAPSHOT.war/WEB-INF/lib/kie-cdi-war-kie-module-1.0.0-SNAPSHOT.jar as jarPath cannot be found
> /content/kie-cdi-war-web-app-1.0.0-SNAPSHOT.war/WEB-INF/lib/kie-cdi-war-kie-module-1.0.0-SNAPSHOT.jar
> The first log line shows that ClasspathKieProject located kmodule.xml at URL starting with protocol 'vfs:'. Later, in method fixURLFromKProjectPath, the protocol prefix is removed, leading to URL /content/kie-cdi-war-web-app-1.0.0-SNAPSHOT.war/WEB-INF/lib/kie-cdi-war-kie-module-1.0.0-SNAPSHOT.jar which now references absolute path which is wrong.
> Steps to Reproduce:
> 1. Deploy attached reproducer WAR on EAP 6.
> 2. Watch server.log for deployment errors.
>   
> Actual results:
> Deployment fails due to failed injection.
> Expected results:
> Application deploys successfully and writes INFO message into server.log.
> Additional info:
> This issue blocks further testing if KIE module injection through CDI. It also renders the CDI feature unusable in real environment (e.g. some web or EJB container with CDI).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 03:08:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Oct 2013 03:08:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-247) Property reactivity does not
 work with positional/unification constraints
In-Reply-To: <JIRA.12499719.1377919009000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499719.1377919009000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499719.1377919009000.9983.1382425682062@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823815#comment-12823815 ] 

RH Bugzilla Integration commented on DROOLS-247:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> made a comment on [bug 1021803|https://bugzilla.redhat.com/show_bug.cgi?id=1021803]

Positional and/or unification constraints are interpreted as either bindings
or constraints, depending on the whether the variable is already bound or not. The user is expected not to have to care about the difference.

...
Person( $name; $age := age )
...

If the pattern type is @propertyReactive, however, the actual decision
between binding and constraint WILL make a difference, possibly forcing
the user to use @watch()
                
> Property reactivity does not work with positional/unification constraints
> -------------------------------------------------------------------------
>
>                 Key: DROOLS-247
>                 URL: https://issues.jboss.org/browse/DROOLS-247
>             Project: Drools
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.CR2
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Minor
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> Positional and/or unification constraints are interpreted as either bindings
> or constraints, depending on the whether the variable is already bound or not. The user is expected not to have to care about the difference.
> ...
> Person( $name; $age := age )
> ...
> If the pattern type is @propertyReactive, however, the actual decision
> between binding and constraint WILL make a difference, possibly forcing
> the user to use @watch()

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 03:08:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Oct 2013 03:08:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-247) Property reactivity does not
 work with positional/unification constraints
In-Reply-To: <JIRA.12499719.1377919009000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499719.1377919009000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499719.1377919009000.9986.1382425682190@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated DROOLS-247:
-------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1021803

    
> Property reactivity does not work with positional/unification constraints
> -------------------------------------------------------------------------
>
>                 Key: DROOLS-247
>                 URL: https://issues.jboss.org/browse/DROOLS-247
>             Project: Drools
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.CR2
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Minor
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> Positional and/or unification constraints are interpreted as either bindings
> or constraints, depending on the whether the variable is already bound or not. The user is expected not to have to care about the difference.
> ...
> Person( $name; $age := age )
> ...
> If the pattern type is @propertyReactive, however, the actual decision
> between binding and constraint WILL make a difference, possibly forcing
> the user to use @watch()

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 03:08:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Oct 2013 03:08:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-247) Property reactivity does not
 work with positional/unification constraints
In-Reply-To: <JIRA.12499719.1377919009000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499719.1377919009000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499719.1377919009000.9991.1382425682403@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823816#comment-12823816 ] 

RH Bugzilla Integration commented on DROOLS-247:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> made a comment on [bug 1021803|https://bugzilla.redhat.com/show_bug.cgi?id=1021803]

Fixed by https://github.com/droolsjbpm/drools/commit/3361ff876ca3bdd9d28cad3997c576d7211bd748
                
> Property reactivity does not work with positional/unification constraints
> -------------------------------------------------------------------------
>
>                 Key: DROOLS-247
>                 URL: https://issues.jboss.org/browse/DROOLS-247
>             Project: Drools
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.CR2
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Minor
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> Positional and/or unification constraints are interpreted as either bindings
> or constraints, depending on the whether the variable is already bound or not. The user is expected not to have to care about the difference.
> ...
> Person( $name; $age := age )
> ...
> If the pattern type is @propertyReactive, however, the actual decision
> between binding and constraint WILL make a difference, possibly forcing
> the user to use @watch()

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 03:08:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Oct 2013 03:08:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-247) Property reactivity does not
 work with positional/unification constraints
In-Reply-To: <JIRA.12499719.1377919009000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499719.1377919009000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499719.1377919009000.9994.1382425682523@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823817#comment-12823817 ] 

RH Bugzilla Integration commented on DROOLS-247:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> changed the Status of [bug 1021803|https://bugzilla.redhat.com/show_bug.cgi?id=1021803] from NEW to MODIFIED
                
> Property reactivity does not work with positional/unification constraints
> -------------------------------------------------------------------------
>
>                 Key: DROOLS-247
>                 URL: https://issues.jboss.org/browse/DROOLS-247
>             Project: Drools
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.CR2
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Minor
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> Positional and/or unification constraints are interpreted as either bindings
> or constraints, depending on the whether the variable is already bound or not. The user is expected not to have to care about the difference.
> ...
> Person( $name; $age := age )
> ...
> If the pattern type is @propertyReactive, however, the actual decision
> between binding and constraint WILL make a difference, possibly forcing
> the user to use @watch()

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 03:11:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Oct 2013 03:11:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-251) Classloader fails to resolve
 when annotation and declared class have the same name
In-Reply-To: <JIRA.12500015.1378364475000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500015.1378364475000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500015.1378364475000.9999.1382425862093@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823818#comment-12823818 ] 

RH Bugzilla Integration commented on DROOLS-251:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> made a comment on [bug 1021806|https://bugzilla.redhat.com/show_bug.cgi?id=1021806]

package test

declare Annot
fld : int @Annot
end

The packagebuilder type resolver will confuse the annotation with the declared class and throw exceptions (varies depending on optional import
statements)
                
> Classloader fails to resolve when annotation and declared class have the same name
> ----------------------------------------------------------------------------------
>
>                 Key: DROOLS-251
>                 URL: https://issues.jboss.org/browse/DROOLS-251
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.CR2
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> package test
> declare Annot
>   fld : int @Annot
> end
> The packagebuilder type resolver will confuse the annotation with the declared class and throw exceptions (varies depending on optional import
> statements)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 03:11:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Oct 2013 03:11:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-251) Classloader fails to resolve
 when annotation and declared class have the same name
In-Reply-To: <JIRA.12500015.1378364475000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500015.1378364475000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500015.1378364475000.10002.1382425862223@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated DROOLS-251:
-------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1021806

    
> Classloader fails to resolve when annotation and declared class have the same name
> ----------------------------------------------------------------------------------
>
>                 Key: DROOLS-251
>                 URL: https://issues.jboss.org/browse/DROOLS-251
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.CR2
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> package test
> declare Annot
>   fld : int @Annot
> end
> The packagebuilder type resolver will confuse the annotation with the declared class and throw exceptions (varies depending on optional import
> statements)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 03:13:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Oct 2013 03:13:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-251) Classloader fails to resolve
 when annotation and declared class have the same name
In-Reply-To: <JIRA.12500015.1378364475000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500015.1378364475000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500015.1378364475000.10007.1382425982027@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823821#comment-12823821 ] 

RH Bugzilla Integration commented on DROOLS-251:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> changed the Status of [bug 1021806|https://bugzilla.redhat.com/show_bug.cgi?id=1021806] from NEW to MODIFIED
                
> Classloader fails to resolve when annotation and declared class have the same name
> ----------------------------------------------------------------------------------
>
>                 Key: DROOLS-251
>                 URL: https://issues.jboss.org/browse/DROOLS-251
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.CR2
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> package test
> declare Annot
>   fld : int @Annot
> end
> The packagebuilder type resolver will confuse the annotation with the declared class and throw exceptions (varies depending on optional import
> statements)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 03:13:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Oct 2013 03:13:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-251) Classloader fails to resolve
 when annotation and declared class have the same name
In-Reply-To: <JIRA.12500015.1378364475000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500015.1378364475000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500015.1378364475000.10011.1382425982268@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823822#comment-12823822 ] 

RH Bugzilla Integration commented on DROOLS-251:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> made a comment on [bug 1021806|https://bugzilla.redhat.com/show_bug.cgi?id=1021806]

Fixed by https://github.com/droolsjbpm/drools/commit/c20957b873f5c03bbb5b90cbc571ce420704f052
                
> Classloader fails to resolve when annotation and declared class have the same name
> ----------------------------------------------------------------------------------
>
>                 Key: DROOLS-251
>                 URL: https://issues.jboss.org/browse/DROOLS-251
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.CR2
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> package test
> declare Annot
>   fld : int @Annot
> end
> The packagebuilder type resolver will confuse the annotation with the declared class and throw exceptions (varies depending on optional import
> statements)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 03:15:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Oct 2013 03:15:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-178) NoSuchMethodError at runtime
 due to eval in query (BW chaining)
In-Reply-To: <JIRA.12495023.1372138865000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495023.1372138865000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495023.1372138865000.10015.1382426102668@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated DROOLS-178:
-------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1021810

    
> NoSuchMethodError at runtime due to eval in query (BW chaining)
> ---------------------------------------------------------------
>
>                 Key: DROOLS-178
>                 URL: https://issues.jboss.org/browse/DROOLS-178
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Wolfgang Laun
>            Assignee: Mario Fusco
>            Priority: Critical
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> An eval CW in a query used in a BW chaining rule compiles, but causes a NoSuchMethodError when executed.
> Exception in thread "main" java.lang.NoSuchMethodError:
> pythagoras.Rule_isTriple_17ac16f7237046ee9562afce35dfe174.eval0(III)Z
>         at pythagoras.Rule_isTriple_17ac16f7237046ee9562afce35dfe174Eval0InvokerGenerated.evaluate(Unknown
> Source)
>         at pythagoras.Rule_isTriple_17ac16f7237046ee9562afce35dfe174Eval0Invoker.evaluate(Unknown
> Source)
>         at org.drools.rule.EvalCondition.isAllowed(EvalCondition.java:114)
>         at org.drools.reteoo.EvalConditionNode.assertLeftTuple(EvalConditionNode.java:176)
>         at org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:196)
>         at org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:71)
>         at org.drools.reteoo.JoinNode.propagateFromRight(JoinNode.java:159)
>         at org.drools.reteoo.JoinNode.assertObject(JoinNode.java:148)
>         at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:497)
>         at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:382)
>         at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235)
>         at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240)
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:350)
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:311)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:847)
>         at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:269)
>         at pythagoras.Main.makeFacts(Main.java:94)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 03:15:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Oct 2013 03:15:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-178) NoSuchMethodError at runtime
 due to eval in query (BW chaining)
In-Reply-To: <JIRA.12495023.1372138865000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495023.1372138865000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495023.1372138865000.10021.1382426102901@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823823#comment-12823823 ] 

RH Bugzilla Integration commented on DROOLS-178:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> made a comment on [bug 1021810|https://bugzilla.redhat.com/show_bug.cgi?id=1021810]

- Workaround Description:

The types of the query arguments has to be coherent with the declarations so either rewrite the query signature like:

query isTriple( int $a, int $b, int $c )

or change the patterns in the query itself like:

Integer( this == $a )

- Steps to Reproduce:

Compile and start session from KB.

rule "kickoff"
salience 100
when
then
for( Integer i: new Integer[]
{3,4,5,12,13 }

)
{ insert( i ); }

end

rule "find triple forward"
when
Integer( $a: intValue )
Integer( $b: intValue > $a )
Integer( $c: intValue > $b )
eval( $a*$a + $b*$b == $c*$c )
then
System.out.println( "fwd: " + $a + " " + $b + " " + $c );
end

query isTriple( Integer $a, Integer $b, Integer $c )
Integer( intValue == $a )
Integer( intValue == $b && > $a )
Integer( intValue == $c && > $b )
eval( $a*$a + $b*$b == $c*$c )
end

rule "find triple backward"
when
isTriple( $a, $b, $c; )
then
System.out.println( "bwd: " + $a + " " + $b + " " + $c );
end
                
> NoSuchMethodError at runtime due to eval in query (BW chaining)
> ---------------------------------------------------------------
>
>                 Key: DROOLS-178
>                 URL: https://issues.jboss.org/browse/DROOLS-178
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Wolfgang Laun
>            Assignee: Mario Fusco
>            Priority: Critical
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> An eval CW in a query used in a BW chaining rule compiles, but causes a NoSuchMethodError when executed.
> Exception in thread "main" java.lang.NoSuchMethodError:
> pythagoras.Rule_isTriple_17ac16f7237046ee9562afce35dfe174.eval0(III)Z
>         at pythagoras.Rule_isTriple_17ac16f7237046ee9562afce35dfe174Eval0InvokerGenerated.evaluate(Unknown
> Source)
>         at pythagoras.Rule_isTriple_17ac16f7237046ee9562afce35dfe174Eval0Invoker.evaluate(Unknown
> Source)
>         at org.drools.rule.EvalCondition.isAllowed(EvalCondition.java:114)
>         at org.drools.reteoo.EvalConditionNode.assertLeftTuple(EvalConditionNode.java:176)
>         at org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:196)
>         at org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:71)
>         at org.drools.reteoo.JoinNode.propagateFromRight(JoinNode.java:159)
>         at org.drools.reteoo.JoinNode.assertObject(JoinNode.java:148)
>         at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:497)
>         at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:382)
>         at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235)
>         at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240)
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:350)
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:311)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:847)
>         at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:269)
>         at pythagoras.Main.makeFacts(Main.java:94)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 03:15:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Oct 2013 03:15:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-178) NoSuchMethodError at runtime
 due to eval in query (BW chaining)
In-Reply-To: <JIRA.12495023.1372138865000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495023.1372138865000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495023.1372138865000.10026.1382426103120@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823824#comment-12823824 ] 

RH Bugzilla Integration commented on DROOLS-178:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> made a comment on [bug 1021810|https://bugzilla.redhat.com/show_bug.cgi?id=1021810]

Fixed by https://github.com/droolsjbpm/drools/commit/51b3d7794fd1f50bea2a6888db6aeafefdc8da74
                
> NoSuchMethodError at runtime due to eval in query (BW chaining)
> ---------------------------------------------------------------
>
>                 Key: DROOLS-178
>                 URL: https://issues.jboss.org/browse/DROOLS-178
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Wolfgang Laun
>            Assignee: Mario Fusco
>            Priority: Critical
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> An eval CW in a query used in a BW chaining rule compiles, but causes a NoSuchMethodError when executed.
> Exception in thread "main" java.lang.NoSuchMethodError:
> pythagoras.Rule_isTriple_17ac16f7237046ee9562afce35dfe174.eval0(III)Z
>         at pythagoras.Rule_isTriple_17ac16f7237046ee9562afce35dfe174Eval0InvokerGenerated.evaluate(Unknown
> Source)
>         at pythagoras.Rule_isTriple_17ac16f7237046ee9562afce35dfe174Eval0Invoker.evaluate(Unknown
> Source)
>         at org.drools.rule.EvalCondition.isAllowed(EvalCondition.java:114)
>         at org.drools.reteoo.EvalConditionNode.assertLeftTuple(EvalConditionNode.java:176)
>         at org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:196)
>         at org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:71)
>         at org.drools.reteoo.JoinNode.propagateFromRight(JoinNode.java:159)
>         at org.drools.reteoo.JoinNode.assertObject(JoinNode.java:148)
>         at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:497)
>         at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:382)
>         at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235)
>         at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240)
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:350)
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:311)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:847)
>         at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:269)
>         at pythagoras.Main.makeFacts(Main.java:94)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 03:15:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Oct 2013 03:15:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-178) NoSuchMethodError at runtime
 due to eval in query (BW chaining)
In-Reply-To: <JIRA.12495023.1372138865000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495023.1372138865000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495023.1372138865000.10031.1382426103299@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823825#comment-12823825 ] 

RH Bugzilla Integration commented on DROOLS-178:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> changed the Status of [bug 1021810|https://bugzilla.redhat.com/show_bug.cgi?id=1021810] from NEW to MODIFIED
                
> NoSuchMethodError at runtime due to eval in query (BW chaining)
> ---------------------------------------------------------------
>
>                 Key: DROOLS-178
>                 URL: https://issues.jboss.org/browse/DROOLS-178
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Wolfgang Laun
>            Assignee: Mario Fusco
>            Priority: Critical
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> An eval CW in a query used in a BW chaining rule compiles, but causes a NoSuchMethodError when executed.
> Exception in thread "main" java.lang.NoSuchMethodError:
> pythagoras.Rule_isTriple_17ac16f7237046ee9562afce35dfe174.eval0(III)Z
>         at pythagoras.Rule_isTriple_17ac16f7237046ee9562afce35dfe174Eval0InvokerGenerated.evaluate(Unknown
> Source)
>         at pythagoras.Rule_isTriple_17ac16f7237046ee9562afce35dfe174Eval0Invoker.evaluate(Unknown
> Source)
>         at org.drools.rule.EvalCondition.isAllowed(EvalCondition.java:114)
>         at org.drools.reteoo.EvalConditionNode.assertLeftTuple(EvalConditionNode.java:176)
>         at org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:196)
>         at org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:71)
>         at org.drools.reteoo.JoinNode.propagateFromRight(JoinNode.java:159)
>         at org.drools.reteoo.JoinNode.assertObject(JoinNode.java:148)
>         at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:497)
>         at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:382)
>         at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235)
>         at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240)
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:350)
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:311)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:847)
>         at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:269)
>         at pythagoras.Main.makeFacts(Main.java:94)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 03:17:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Oct 2013 03:17:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-249) Handle conflicts when using
 @position in declared types
In-Reply-To: <JIRA.12500013.1378364090000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500013.1378364090000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500013.1378364090000.10036.1382426222069@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823826#comment-12823826 ] 

RH Bugzilla Integration commented on DROOLS-249:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> made a comment on [bug 1021812|https://bugzilla.redhat.com/show_bug.cgi?id=1021812]

declare A
f : int @position(2)
g : int @position(1)
end

declare B extends A
h : int @position(3)
i : int @position(2)
end

The resulting field order may not be deterministic because of

    the clashes (2)
    the missing pos (0)

this is dangerous when used with positional constraints

B( $x, $y, $z, $w ; )
                
> Handle conflicts when using @position in declared types
> -------------------------------------------------------
>
>                 Key: DROOLS-249
>                 URL: https://issues.jboss.org/browse/DROOLS-249
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.CR2
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Minor
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> declare A
>  f : int @position(2)
>  g : int @position(1)
> end
> declare B extends A
>  h : int @position(3)
>  i : int @position(2)
> end
> The resulting field order may not be deterministic because of
>  - the clashes (2)
>  - the missing pos (0)
> this is dangerous when used with positional constraints
> B( $x, $y, $z, $w ; )
> Marked as minor because of the obvious workaround

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 03:17:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Oct 2013 03:17:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-249) Handle conflicts when using
 @position in declared types
In-Reply-To: <JIRA.12500013.1378364090000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500013.1378364090000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500013.1378364090000.10039.1382426222167@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated DROOLS-249:
-------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1021812

    
> Handle conflicts when using @position in declared types
> -------------------------------------------------------
>
>                 Key: DROOLS-249
>                 URL: https://issues.jboss.org/browse/DROOLS-249
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.CR2
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Minor
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> declare A
>  f : int @position(2)
>  g : int @position(1)
> end
> declare B extends A
>  h : int @position(3)
>  i : int @position(2)
> end
> The resulting field order may not be deterministic because of
>  - the clashes (2)
>  - the missing pos (0)
> this is dangerous when used with positional constraints
> B( $x, $y, $z, $w ; )
> Marked as minor because of the obvious workaround

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 03:19:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Oct 2013 03:19:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-249) Handle conflicts when using
 @position in declared types
In-Reply-To: <JIRA.12500013.1378364090000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500013.1378364090000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500013.1378364090000.10043.1382426342024@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823827#comment-12823827 ] 

RH Bugzilla Integration commented on DROOLS-249:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> changed the Status of [bug 1021812|https://bugzilla.redhat.com/show_bug.cgi?id=1021812] from NEW to MODIFIED
                
> Handle conflicts when using @position in declared types
> -------------------------------------------------------
>
>                 Key: DROOLS-249
>                 URL: https://issues.jboss.org/browse/DROOLS-249
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.CR2
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Minor
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> declare A
>  f : int @position(2)
>  g : int @position(1)
> end
> declare B extends A
>  h : int @position(3)
>  i : int @position(2)
> end
> The resulting field order may not be deterministic because of
>  - the clashes (2)
>  - the missing pos (0)
> this is dangerous when used with positional constraints
> B( $x, $y, $z, $w ; )
> Marked as minor because of the obvious workaround

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 03:19:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Oct 2013 03:19:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-249) Handle conflicts when using
 @position in declared types
In-Reply-To: <JIRA.12500013.1378364090000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500013.1378364090000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500013.1378364090000.10048.1382426342420@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823828#comment-12823828 ] 

RH Bugzilla Integration commented on DROOLS-249:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> made a comment on [bug 1021812|https://bugzilla.redhat.com/show_bug.cgi?id=1021812]

Fixed by https://github.com/droolsjbpm/drools/commit/0876a1f6ad9327d42dd1c9a213d6eb7f677f8fe9
                
> Handle conflicts when using @position in declared types
> -------------------------------------------------------
>
>                 Key: DROOLS-249
>                 URL: https://issues.jboss.org/browse/DROOLS-249
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.CR2
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Minor
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> declare A
>  f : int @position(2)
>  g : int @position(1)
> end
> declare B extends A
>  h : int @position(3)
>  i : int @position(2)
> end
> The resulting field order may not be deterministic because of
>  - the clashes (2)
>  - the missing pos (0)
> this is dangerous when used with positional constraints
> B( $x, $y, $z, $w ; )
> Marked as minor because of the obvious workaround

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 03:19:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Oct 2013 03:19:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-140) KIE module injection through
 CDI does not work in container
In-Reply-To: <JIRA.12491833.1368620305000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12491833.1368620305000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12491833.1368620305000.10051.1382426342611@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823829#comment-12823829 ] 

RH Bugzilla Integration commented on DROOLS-140:
------------------------------------------------

Marek Winkler <mwinkler at redhat.com> made a comment on [bug 955193|https://bugzilla.redhat.com/show_bug.cgi?id=955193]

(In reply to Kanchan Desai from comment #15)
> Hi Marek,
> 
> Can you please share some more info on this bug, probably the fix and the
> result.

Hi Kanchan,

in general, this issue has been caused by Drools resource loading which was not suitable for the JBoss EAP application server environment. EAP uses JBoss VFS and Drools resource loading mechanism had problems with that.

The reason was that Drools attempts to locate every KieModule on the classpath by looking for all resources called 'META-INF/kmodule.xml'. For every such resource found, it needs also to locate pom.properties (or pom.xml) file. 

The problem was that path of pom.properties is not known in advance (it is located in a relative path to kmodule.xml, such as 'maven/<groupId>/<artifactId>/pom.properties'), where <groupId> and <artifactId> are directories named according to the maven artifact they are part of, therefore you cannot use standard java resource loading mechanism to locate it. Drools accessed the filesystem (either a jar, or physical filesystem) hosting the kmodule.xml resource to determine the location of pom.properties, which did not work in case of JBoss VFS.

Mario has fixed that, in case you needed more technical details about the fix, he would give you the most accurate information.

The result is working CDI injection of Drools KieBase and KieSession with EAP. The attached reproducer web app works now when deployed to EAP (it defines a CDI bean which is able to inject a KieSession defined in kmodule.xml).
                
> KIE module injection through CDI does not work in container
> -----------------------------------------------------------
>
>                 Key: DROOLS-140
>                 URL: https://issues.jboss.org/browse/DROOLS-140
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>             Fix For: 6.0.0.CR1
>
>
> Description of problem:
> Injection of KIE module through CDI fails on JBoss EAP 6.0/6.1 due to wrong processing of resource URI when loading pom.properties in ClasspathKieProject.
> Version-Release number of selected component (if applicable):
> BRMS 6.0.0.Beta1
> EAP 6.0, 6.1.ER4
> How reproducible:
> Deploy the attached reproducer WAR. Deployment fails, server.log contains the following error (see attachment for all errors in log):
> 15:40:29,923 INFO  [stdout] (MSC service thread 1-2) kmodules: vfs:/content/kie-cdi-war-web-app-1.0.0-SNAPSHOT.war/WEB-INF/lib/kie-cdi-war-kie-module-1.0.0-SNAPSHOT.jar/META-INF/kmodule.xml
> 15:40:29,939 ERROR [org.drools.compiler.kie.builder.impl.ClasspathKieProject] (MSC service thread 1-2) Unable to load pom.properties from/content/kie-cdi-war-web-app-1.0.0-SNAPSHOT.war/WEB-INF/lib/kie-cdi-war-kie-module-1.0.0-SNAPSHOT.jar as jarPath cannot be found
> /content/kie-cdi-war-web-app-1.0.0-SNAPSHOT.war/WEB-INF/lib/kie-cdi-war-kie-module-1.0.0-SNAPSHOT.jar
> The first log line shows that ClasspathKieProject located kmodule.xml at URL starting with protocol 'vfs:'. Later, in method fixURLFromKProjectPath, the protocol prefix is removed, leading to URL /content/kie-cdi-war-web-app-1.0.0-SNAPSHOT.war/WEB-INF/lib/kie-cdi-war-kie-module-1.0.0-SNAPSHOT.jar which now references absolute path which is wrong.
> Steps to Reproduce:
> 1. Deploy attached reproducer WAR on EAP 6.
> 2. Watch server.log for deployment errors.
>   
> Actual results:
> Deployment fails due to failed injection.
> Expected results:
> Application deploys successfully and writes INFO message into server.log.
> Additional info:
> This issue blocks further testing if KIE module injection through CDI. It also renders the CDI feature unusable in real environment (e.g. some web or EJB container with CDI).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 03:21:02 2013
From: jira-events at lists.jboss.org (Martin Gencur (JIRA))
Date: Tue, 22 Oct 2013 03:21:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1721) AUTH and ENCRYPT protocols
 configured with plain text passwords
In-Reply-To: <JIRA.12508425.1382426440552@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508425.1382426440552@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508425.1382426440552.10070.1382426462587@jira02.app.mwc.hst.phx2.redhat.com>

Martin Gencur created JGRP-1721:
-----------------------------------

             Summary: AUTH and ENCRYPT protocols configured with plain text passwords
                 Key: JGRP-1721
                 URL: https://issues.jboss.org/browse/JGRP-1721
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 3.4
            Reporter: Martin Gencur
            Assignee: Bela Ban


The following parameters of AUTH protocol are stored as plain text:
* keystore_password

The following parameters of ENCRYPT protocol are stored as plain text:
* store_password
* key_password

Example:
{code}
<ENCRYPT key_store_name="defaultStore.keystore" store_password="changeit" alias="myKey"/>
{code}

Requirements for storing passwords: https://docspace.corp.redhat.com/docs/DOC-131628

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 03:25:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Oct 2013 03:25:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1721) AUTH and ENCRYPT protocols
 configured with plain text passwords
In-Reply-To: <JIRA.12508425.1382426440000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508425.1382426440000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508425.1382426440000.10075.1382426702030@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823837#comment-12823837 ] 

RH Bugzilla Integration commented on JGRP-1721:
-----------------------------------------------

Martin Gencur <mgencur at redhat.com> made a comment on [bug 1021819|https://bugzilla.redhat.com/show_bug.cgi?id=1021819]

See description in the JIRA bug.
                
> AUTH and ENCRYPT protocols configured with plain text passwords
> ---------------------------------------------------------------
>
>                 Key: JGRP-1721
>                 URL: https://issues.jboss.org/browse/JGRP-1721
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Martin Gencur
>            Assignee: Bela Ban
>
> The following parameters of AUTH protocol are stored as plain text:
> * keystore_password
> The following parameters of ENCRYPT protocol are stored as plain text:
> * store_password
> * key_password
> Example:
> {code}
> <ENCRYPT key_store_name="defaultStore.keystore" store_password="changeit" alias="myKey"/>
> {code}
> Requirements for storing passwords: https://docspace.corp.redhat.com/docs/DOC-131628

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 03:25:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Oct 2013 03:25:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1721) AUTH and ENCRYPT protocols
 configured with plain text passwords
In-Reply-To: <JIRA.12508425.1382426440000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508425.1382426440000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508425.1382426440000.10079.1382426702287@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated JGRP-1721:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1021819

    
> AUTH and ENCRYPT protocols configured with plain text passwords
> ---------------------------------------------------------------
>
>                 Key: JGRP-1721
>                 URL: https://issues.jboss.org/browse/JGRP-1721
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Martin Gencur
>            Assignee: Bela Ban
>
> The following parameters of AUTH protocol are stored as plain text:
> * keystore_password
> The following parameters of ENCRYPT protocol are stored as plain text:
> * store_password
> * key_password
> Example:
> {code}
> <ENCRYPT key_store_name="defaultStore.keystore" store_password="changeit" alias="myKey"/>
> {code}
> Requirements for storing passwords: https://docspace.corp.redhat.com/docs/DOC-131628

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 03:31:01 2013
From: jira-events at lists.jboss.org (Martin Gencur (JIRA))
Date: Tue, 22 Oct 2013 03:31:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1722) Improve performance of
	ENCRYPT protocol
In-Reply-To: <JIRA.12508426.1382426974364@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508426.1382426974364@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508426.1382426974364.10091.1382427061961@jira02.app.mwc.hst.phx2.redhat.com>

Martin Gencur created JGRP-1722:
-----------------------------------

             Summary: Improve performance of ENCRYPT protocol
                 Key: JGRP-1722
                 URL: https://issues.jboss.org/browse/JGRP-1722
             Project: JGroups
          Issue Type: Enhancement
    Affects Versions: 3.4
            Reporter: Martin Gencur
            Assignee: Bela Ban


A stress tests with the following setup showed that performance (reads and writes/sec) is halved when ENCRYPT protocol is enabled:
Infinispan had distributed sync cache with 2 owners on 4 nodes, no transactions. The stress test used 10 threads on each node accessing 1024 byte entries, no conflicts on keys, 20 % writes, 80 % reads. 

It would be great if we could improve the performance of ENCRYPT protocol.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 03:33:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Oct 2013 03:33:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1722) Improve performance of
	ENCRYPT protocol
In-Reply-To: <JIRA.12508426.1382426974000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508426.1382426974000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508426.1382426974000.10099.1382427182021@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated JGRP-1722:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1021822

    
> Improve performance of ENCRYPT protocol
> ---------------------------------------
>
>                 Key: JGRP-1722
>                 URL: https://issues.jboss.org/browse/JGRP-1722
>             Project: JGroups
>          Issue Type: Enhancement
>    Affects Versions: 3.4
>            Reporter: Martin Gencur
>            Assignee: Bela Ban
>
> A stress tests with the following setup showed that performance (reads and writes/sec) is halved when ENCRYPT protocol is enabled:
> Infinispan had distributed sync cache with 2 owners on 4 nodes, no transactions. The stress test used 10 threads on each node accessing 1024 byte entries, no conflicts on keys, 20 % writes, 80 % reads. 
> It would be great if we could improve the performance of ENCRYPT protocol.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 03:33:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Oct 2013 03:33:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1722) Improve performance of
	ENCRYPT protocol
In-Reply-To: <JIRA.12508426.1382426974000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508426.1382426974000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508426.1382426974000.10103.1382427182197@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823839#comment-12823839 ] 

RH Bugzilla Integration commented on JGRP-1722:
-----------------------------------------------

Martin Gencur <mgencur at redhat.com> made a comment on [bug 1021822|https://bugzilla.redhat.com/show_bug.cgi?id=1021822]

See description in the JIRA issue.
                
> Improve performance of ENCRYPT protocol
> ---------------------------------------
>
>                 Key: JGRP-1722
>                 URL: https://issues.jboss.org/browse/JGRP-1722
>             Project: JGroups
>          Issue Type: Enhancement
>    Affects Versions: 3.4
>            Reporter: Martin Gencur
>            Assignee: Bela Ban
>
> A stress tests with the following setup showed that performance (reads and writes/sec) is halved when ENCRYPT protocol is enabled:
> Infinispan had distributed sync cache with 2 owners on 4 nodes, no transactions. The stress test used 10 threads on each node accessing 1024 byte entries, no conflicts on keys, 20 % writes, 80 % reads. 
> It would be great if we could improve the performance of ENCRYPT protocol.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 04:07:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Tue, 22 Oct 2013 04:07:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2284)
 HttpServletRequest.getQueryString() returns null for forwarded requests
In-Reply-To: <JIRA.12502751.1381475769000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502751.1381475769000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502751.1381475769000.10192.1382429222117@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-2284.
----------------------------------

    Fix Version/s: 8.0.0.CR1
       Resolution: Done

    
> HttpServletRequest.getQueryString() returns null for forwarded requests
> -----------------------------------------------------------------------
>
>                 Key: WFLY-2284
>                 URL: https://issues.jboss.org/browse/WFLY-2284
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Christian Kaltepoth
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.CR1
>
>         Attachments: forward-query.zip
>
>
> When a request gets forwarded to another Servlet, {{HttpServletRequest.getQueryString()}} returns null, even if the original request contains query parameters.
> From Servlet 3.1 spec 9.4.1:
> {quote}
> The request dispatching mechanism is responsible for aggregating query string parameters when forwarding or including requests.
> {quote}
> The attached sample project demonstrates the problem:
> If you request {{/first?foo=bar}}, the corresponding servlet will forward the request to {{/second}}. The second servlet will get these values:
> {code}
> request.getRequestURI():      /forward-query/second
> request.getParameter("foo"):  bar
> request.getQueryString():     null
> {code}
> In JBoss AS 7.1.1  and Tomcat the result looks like this:
> {code}
> request.getRequestURI():      /forward-query/second
> request.getParameter("foo"):  bar
> request.getQueryString():     foo=bar
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 04:07:03 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Tue, 22 Oct 2013 04:07:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2251) ;
	jsessionid=... in URL not supported
In-Reply-To: <JIRA.12502353.1381155859000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502353.1381155859000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502353.1381155859000.10209.1382429223079@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-2251.
----------------------------------

    Fix Version/s: 8.0.0.CR1
       Resolution: Done

    
> ;jsessionid=... in URL not supported
> ------------------------------------
>
>                 Key: WFLY-2251
>                 URL: https://issues.jboss.org/browse/WFLY-2251
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Frank Cornelis
>            Assignee: Stuart Douglas
>            Priority: Blocker
>             Fix For: 8.0.0.CR1
>
>
> When configuring a servlet within your Java EE application, you can reach it via:
> https://localhost/your_app_context/your_servlet_mapping
> but not via:
> https://localhost/your_app_context/your_servlet_mapping;jsessionid=whatever
> You get a "Not Found" error message instead. This used to work under JBoss EAP 6.1.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 04:24:01 2013
From: jira-events at lists.jboss.org (Harald Pehl (JIRA))
Date: Tue, 22 Oct 2013 04:24:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2353) Update to HAL 2.0.5.Final
In-Reply-To: <JIRA.12508429.1382430225554@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508429.1382430225554@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508429.1382430225554.10234.1382430241947@jira02.app.mwc.hst.phx2.redhat.com>

Harald Pehl created WFLY-2353:
---------------------------------

             Summary: Update to HAL 2.0.5.Final
                 Key: WFLY-2353
                 URL: https://issues.jboss.org/browse/WFLY-2353
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Web Console
            Reporter: Harald Pehl
            Assignee: Heiko Braun




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 04:26:02 2013
From: jira-events at lists.jboss.org (Harald Pehl (JIRA))
Date: Tue, 22 Oct 2013 04:26:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2353) Update to HAL 2.0.5.Final
In-Reply-To: <JIRA.12508429.1382430225000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508429.1382430225000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508429.1382430225000.10239.1382430362075@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Harald Pehl reassigned WFLY-2353:
---------------------------------

    Assignee: Harald Pehl  (was: Heiko Braun)

    
> Update to HAL 2.0.5.Final
> -------------------------
>
>                 Key: WFLY-2353
>                 URL: https://issues.jboss.org/browse/WFLY-2353
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Console
>            Reporter: Harald Pehl
>            Assignee: Harald Pehl
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 04:28:01 2013
From: jira-events at lists.jboss.org (Harald Pehl (JIRA))
Date: Tue, 22 Oct 2013 04:28:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2353) Update to HAL 2.0.5.Final
In-Reply-To: <JIRA.12508429.1382430225000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508429.1382430225000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508429.1382430225000.10242.1382430481900@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Harald Pehl updated WFLY-2353:
------------------------------

    Fix Version/s: 8.0.0.CR1

    
> Update to HAL 2.0.5.Final
> -------------------------
>
>                 Key: WFLY-2353
>                 URL: https://issues.jboss.org/browse/WFLY-2353
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Console
>            Reporter: Harald Pehl
>            Assignee: Harald Pehl
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 04:39:02 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 22 Oct 2013 04:39:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2265)
 WebUtils#getRealPath("config-data/TESTDEV") cannot be resolved to absolute
 file path
In-Reply-To: <JIRA.12502507.1381287850000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502507.1381287850000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502507.1381287850000.10255.1382431142239@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar reassigned WFLY-2265:
---------------------------------

    Assignee: Tomaz Cerar  (was: Remy Maucherat)

    
> WebUtils#getRealPath("config-data/TESTDEV") cannot be resolved to absolute file path
> ------------------------------------------------------------------------------------
>
>                 Key: WFLY-2265
>                 URL: https://issues.jboss.org/browse/WFLY-2265
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (JBoss Web)
>    Affects Versions: 8.0.0.Beta1
>         Environment: Windows 7
>            Reporter: zhihong liu
>            Assignee: Tomaz Cerar
>              Labels: jboss
>             Fix For: 8.0.0.Beta1
>
>   Original Estimate: 3 weeks
>  Remaining Estimate: 3 weeks
>
> In windows , when use the WebUtils.getRealPath("config-data/TESTDEV") , it returns error message : ServletContext resource [/config-data/TESTDEV] cannot be resolved to absolute file path.
>  but WebUtils.getRealPath("/") can return the true path . that is to say , this method can't parse the backslash followed by a string . but it works good in linux/unix .

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 04:39:02 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 22 Oct 2013 04:39:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2265)
 WebUtils#getRealPath("config-data/TESTDEV") cannot be resolved to absolute
 file path
In-Reply-To: <JIRA.12502507.1381287850000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502507.1381287850000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502507.1381287850000.10258.1382431142422@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-2265:
------------------------------

    Component/s: Web (Undertow)
                     (was: Web (JBoss Web))

    
> WebUtils#getRealPath("config-data/TESTDEV") cannot be resolved to absolute file path
> ------------------------------------------------------------------------------------
>
>                 Key: WFLY-2265
>                 URL: https://issues.jboss.org/browse/WFLY-2265
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>         Environment: Windows 7
>            Reporter: zhihong liu
>            Assignee: Tomaz Cerar
>              Labels: jboss
>             Fix For: 8.0.0.Beta1
>
>   Original Estimate: 3 weeks
>  Remaining Estimate: 3 weeks
>
> In windows , when use the WebUtils.getRealPath("config-data/TESTDEV") , it returns error message : ServletContext resource [/config-data/TESTDEV] cannot be resolved to absolute file path.
>  but WebUtils.getRealPath("/") can return the true path . that is to say , this method can't parse the backslash followed by a string . but it works good in linux/unix .

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 04:39:02 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 22 Oct 2013 04:39:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2265)
 WebUtils#getRealPath("config-data/TESTDEV") cannot be resolved to absolute
 file path
In-Reply-To: <JIRA.12502507.1381287850000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502507.1381287850000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502507.1381287850000.10263.1382431142686@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-2265:
------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> WebUtils#getRealPath("config-data/TESTDEV") cannot be resolved to absolute file path
> ------------------------------------------------------------------------------------
>
>                 Key: WFLY-2265
>                 URL: https://issues.jboss.org/browse/WFLY-2265
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>         Environment: Windows 7
>            Reporter: zhihong liu
>            Assignee: Tomaz Cerar
>              Labels: jboss
>             Fix For: 8.0.0.CR1
>
>   Original Estimate: 3 weeks
>  Remaining Estimate: 3 weeks
>
> In windows , when use the WebUtils.getRealPath("config-data/TESTDEV") , it returns error message : ServletContext resource [/config-data/TESTDEV] cannot be resolved to absolute file path.
>  but WebUtils.getRealPath("/") can return the true path . that is to say , this method can't parse the backslash followed by a string . but it works good in linux/unix .

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 04:41:02 2013
From: jira-events at lists.jboss.org (Rob Stryker (JIRA))
Date: Tue, 22 Oct 2013 04:41:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-74) REMJMX-65 Overzealous
 disabling local authentication
In-Reply-To: <JIRA.12508386.1382374102000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508386.1382374102000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508386.1382374102000.10281.1382431262087@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/REMJMX-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823865#comment-12823865 ] 

Rob Stryker commented on REMJMX-74:
-----------------------------------

Hi Darren:

In JBossTools usecase, we do not have the callback handler classes on our classpath, and so we can't provide a classpath. We're also pulling credentials from some data that may not have been initialized by the user yet, so for us, we'd really prefer a flag or environment property such as PREFER_LOCAL_AUTHENTICATION which works for all cases, even if some credentials have been set. 

Is this possible? 

I admit I did just find a way to work around my issue (by not setting the credentials if they're null) but I still think a flag to always prefer local auth is a valid choice... 
                
> REMJMX-65 Overzealous disabling local authentication
> ----------------------------------------------------
>
>                 Key: REMJMX-74
>                 URL: https://issues.jboss.org/browse/REMJMX-74
>             Project: Remoting JMX
>          Issue Type: Bug
>          Components: Connection
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.2.CR1, 2.0.0.CR4
>
>
> REMJMX-65 is overzealous at disabling local authentication, if a username and credential is supplied in the environment then it does make sense to disable local authentication - however the availability of a callback handler is not a sufficient flag to also disable it.
> In the case of the callback handler the user may still only want to be prompted if the other mechanisms fail.
> This issue will remove the disabling of local authentication based on the presence of a callback handler and will instead add a configuration option that can be set on the environment.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 04:49:02 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 22 Oct 2013 04:49:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2276) URI ENCODING does not work in
 the beta1 version (UTF-8)
In-Reply-To: <JIRA.12502684.1381404449000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502684.1381404449000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502684.1381404449000.10298.1382431742176@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar reassigned WFLY-2276:
---------------------------------

    Assignee: Tomaz Cerar

    
> URI ENCODING does not work in the beta1 version (UTF-8)
> -------------------------------------------------------
>
>                 Key: WFLY-2276
>                 URL: https://issues.jboss.org/browse/WFLY-2276
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (JBoss Web)
>    Affects Versions: 8.0.0.Beta1
>         Environment: Java 7, ubuntu 12.04
>            Reporter: alexandre xypas
>            Assignee: Tomaz Cerar
>              Labels: encoding, utf-8
>
> In standalone.xml, the following is working in Alpha4, but not anymore in Beta1.
> <property name="org.apache.catalina.connector.URI_ENCODING" value="UTF-8"/>
> <property name="org.apache.catalina.connector.USE_BODY_ENCODING_FOR_QUERY_STRING" value="true"/>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 04:49:03 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 22 Oct 2013 04:49:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2276) URI ENCODING does not work in
 the beta1 version (UTF-8)
In-Reply-To: <JIRA.12502684.1381404449000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502684.1381404449000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502684.1381404449000.10313.1382431743003@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-2276:
------------------------------

    Component/s: Web (Undertow)
                     (was: Web (JBoss Web))

    
> URI ENCODING does not work in the beta1 version (UTF-8)
> -------------------------------------------------------
>
>                 Key: WFLY-2276
>                 URL: https://issues.jboss.org/browse/WFLY-2276
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>         Environment: Java 7, ubuntu 12.04
>            Reporter: alexandre xypas
>            Assignee: Tomaz Cerar
>              Labels: encoding, utf-8
>
> In standalone.xml, the following is working in Alpha4, but not anymore in Beta1.
> <property name="org.apache.catalina.connector.URI_ENCODING" value="UTF-8"/>
> <property name="org.apache.catalina.connector.USE_BODY_ENCODING_FOR_QUERY_STRING" value="true"/>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 05:07:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Tue, 22 Oct 2013 05:07:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2259) JSESSIONID in URL should be
	lowercase
In-Reply-To: <JIRA.12502478.1381247959000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502478.1381247959000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502478.1381247959000.10400.1382432822559@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-2259.
----------------------------------

    Fix Version/s: 8.0.0.CR1
       Resolution: Done

    
> JSESSIONID in URL should be lowercase
> -------------------------------------
>
>                 Key: WFLY-2259
>                 URL: https://issues.jboss.org/browse/WFLY-2259
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Christian Kaltepoth
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.CR1
>
>
> I know this looks like a very minor thing, but this was causing trouble for me in some integration tests, so I think I should bring it up here.
> Wildfly appends *{{JSESSIONID}}* instead of *{{jsessionid}}* to the URL when encoding the session id (uppercase instead of lowercase). IMHO the spec requires it to be lowercase.
> From Servlet 3.1 spec:
> {quote}
> *7.1.3 URL Rewriting*
> The session ID must be encoded as a path parameter in the URL string. The name of the parameter must be jsessionid. Here is an example of a URL containing encoded path information:
> {code}http://www.myserver.com/catalog/index.html;jsessionid=1234{code}
> {quote}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 05:09:02 2013
From: jira-events at lists.jboss.org (Emmanuel Hugonnet (JIRA))
Date: Tue, 22 Oct 2013 05:09:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-981) @RunAs/@RunAsPrincipal are
 ignored for @Startup/@Singleton bean
In-Reply-To: <JIRA.12487263.1363286356000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12487263.1363286356000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487263.1363286356000.10405.1382432942250@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emmanuel Hugonnet reassigned WFLY-981:
--------------------------------------

    Assignee: Emmanuel Hugonnet  (was: Derek Horton)

    
> @RunAs/@RunAsPrincipal are ignored for @Startup/@Singleton bean
> ---------------------------------------------------------------
>
>                 Key: WFLY-981
>                 URL: https://issues.jboss.org/browse/WFLY-981
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>            Reporter: Derek Horton
>            Assignee: Emmanuel Hugonnet
>             Fix For: 8.0.0.CR1
>
>
> The @RunAs/@RunAsPrincipal annotations get ignored when used on a singleton
> bean that is annotated with @Startup.  This means the the singleton bean
> is not able to call protected EJBs.
> If the protected EJB is annotated with @PermitAll, then the
> singleton is able to invoke the method because the
> AuthorizationInterceptor create an "anonymous" user that is treated as
> authenticated.  However, the @RunAsPrincipal is ignored as the
> getCallerPrincipal() returns anonymous instead of the @RunAsPrincipal.
> I dug around in the code and it looks like the @RunAs/@RunAsPrincipal
> annotations are getting handled correctly during deployment:
> Step completed: "thread=MSC service thread 1-3", org.jboss.as.ejb3.deployment.processors.merging.RunAsMergingProcessor.handleDeploymentDescriptor(), line=126 bci=249
> MSC service thread 1-3[1] print componentConfiguration.getRunAs()
>  componentConfiguration.getRunAs() = "JBossAdmin"
> MSC service thread 1-3[1] print componentConfiguration.getRunAsPrincipal()
>  componentConfiguration.getRunAsPrincipal() = "fred"
> However, by the time the SecurityContextInterceptor is called, the
> runAs/runAsPrincipal settings are null.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 05:09:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 22 Oct 2013 05:09:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-74) REMJMX-65 Overzealous
 disabling local authentication
In-Reply-To: <JIRA.12508386.1382374102000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508386.1382374102000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508386.1382374102000.10408.1382432942386@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/REMJMX-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823883#comment-12823883 ] 

Darran Lofthouse commented on REMJMX-74:
----------------------------------------

Hello Rob unfortunately your comment is a little late due to time constraints we need this fixed and tagged yesterday ;-)  

The change you have made is correct, you do not have any credentials to use so you should not be setting them - I would recommend however you do revisit looking at supplying a callback handler at some point as that gives you an opportunity to prompt for a username and password if and only if it is actually required.

One final point you may want to consider, the main reason we made this change was so that once access control was enabled and users had an option in the client to force authentication to disable local authentication - I have now added an option 'org.jboss.remoting-jmx.excluded-sasl-mechanisms' which if set on the environment with the value 'JBOSS-LOCAL-USER' will disable local authentication.

                
> REMJMX-65 Overzealous disabling local authentication
> ----------------------------------------------------
>
>                 Key: REMJMX-74
>                 URL: https://issues.jboss.org/browse/REMJMX-74
>             Project: Remoting JMX
>          Issue Type: Bug
>          Components: Connection
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.2.CR1, 2.0.0.CR4
>
>
> REMJMX-65 is overzealous at disabling local authentication, if a username and credential is supplied in the environment then it does make sense to disable local authentication - however the availability of a callback handler is not a sufficient flag to also disable it.
> In the case of the callback handler the user may still only want to be prompted if the other mechanisms fail.
> This issue will remove the disabling of local authentication based on the presence of a callback handler and will instead add a configuration option that can be set on the environment.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 05:11:01 2013
From: jira-events at lists.jboss.org (Emmanuel Hugonnet (JIRA))
Date: Tue, 22 Oct 2013 05:11:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2354) Webservice13 tck failures
 introduced by ejb3 and security change
In-Reply-To: <JIRA.12508431.1382433027031@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508431.1382433027031@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508431.1382433027031.10416.1382433061980@jira02.app.mwc.hst.phx2.redhat.com>

Emmanuel Hugonnet created WFLY-2354:
---------------------------------------

             Summary: Webservice13 tck failures introduced by ejb3 and security change 
                 Key: WFLY-2354
                 URL: https://issues.jboss.org/browse/WFLY-2354
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: EJB
    Affects Versions: 8.0.0.Beta1
            Reporter: Emmanuel Hugonnet
            Assignee: Emmanuel Hugonnet


There 2 tck regression failures under webserivice13 directory in EAP 6.2.0.ER6. 
IT turns out the change[2] introduced this two failures:

[1]https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP6/view/TCK6-EAP6/job/tck6-eap6-webservices13/lastCompletedBuild/testReport/unknownTestSuite.0/
[2][2]https://github.com/jbossas/jboss-eap/commit/72d5cd3f96540519a9747579dd3b85f0f564b64c


EAP 6.2.0.ER6 sever error message:
------------------------------------------------------------------------------

18:32:00,338 ERROR [org.jboss.as.ejb3.invocation] (http-myserver.com/127.0.0.1:8080-1) JBAS014134: EJB Invocation failed on component WSEjbSingletonTest for method public java.lang.String com.sun.ts.tests.webservices13.ejb.annotations.WSEjbSingletonTest.HelloBean.bye(java.lang.String): javax.ejb.EJBException: java.lang.IllegalStateException: JBAS014485: EJB WSEjbSingletonTest is enabled for security but doesn't have a security domain set
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:189) [jboss-as-ejb3-7.3.0.Final-redhat-SNAPSHOT.jar:7.3.0.Final-redhat-SNAPSHOT]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 05:13:01 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Oct 2013 05:13:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2354) Webservice13 tck failures
 introduced by ejb3 and security change
In-Reply-To: <JIRA.12508431.1382433027000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508431.1382433027000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508431.1382433027000.10423.1382433181990@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2354:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1021543

    
> Webservice13 tck failures introduced by ejb3 and security change 
> -----------------------------------------------------------------
>
>                 Key: WFLY-2354
>                 URL: https://issues.jboss.org/browse/WFLY-2354
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>
> There 2 tck regression failures under webserivice13 directory in EAP 6.2.0.ER6. 
> IT turns out the change[2] introduced this two failures:
> [1]https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP6/view/TCK6-EAP6/job/tck6-eap6-webservices13/lastCompletedBuild/testReport/unknownTestSuite.0/
> [2][2]https://github.com/jbossas/jboss-eap/commit/72d5cd3f96540519a9747579dd3b85f0f564b64c
> EAP 6.2.0.ER6 sever error message:
> ------------------------------------------------------------------------------
> 18:32:00,338 ERROR [org.jboss.as.ejb3.invocation] (http-myserver.com/127.0.0.1:8080-1) JBAS014134: EJB Invocation failed on component WSEjbSingletonTest for method public java.lang.String com.sun.ts.tests.webservices13.ejb.annotations.WSEjbSingletonTest.HelloBean.bye(java.lang.String): javax.ejb.EJBException: java.lang.IllegalStateException: JBAS014485: EJB WSEjbSingletonTest is enabled for security but doesn't have a security domain set
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:189) [jboss-as-ejb3-7.3.0.Final-redhat-SNAPSHOT.jar:7.3.0.Final-redhat-SNAPSHOT]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 05:32:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Oct 2013 05:32:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2338) When using a JDBC object
 store,
 the RecoveryManager service stop can occur after the datasource is already
 stopped
In-Reply-To: <JIRA.12508208.1382112933000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508208.1382112933000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508208.1382112933000.10448.1382434322027@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823889#comment-12823889 ] 

RH Bugzilla Integration commented on WFLY-2338:
-----------------------------------------------

Ondrej Chaloupka <ochaloup at redhat.com> made a comment on [bug 1020881|https://bugzilla.redhat.com/show_bug.cgi?id=1020881]

I found out that this happens not only with reload but as well when server is stopping. Which means that when the JDBC object store is configured and you stopped the server the server stucks and it has to be killed by 'kill -9' or similar way.

This problem seems to me quite urgent. I can see that the issue is already solved for Wildfly then please check the process of the stopping the server as well.
                
> When using a JDBC object store, the RecoveryManager service stop can occur after the datasource is already stopped
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2338
>                 URL: https://issues.jboss.org/browse/WFLY-2338
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Transactions
>            Reporter: Tom Jenkinson
>            Assignee: Stefano Maestri
>         Attachments: 0001-patching-servicename-for-ds-dependency.patch
>
>
> It should be the cause of https://bugzilla.redhat.com/show_bug.cgi?id=1020881
> It has the effects described in the BZ, i.e. can cause warnings or can entirely block the application server from stopping

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 05:46:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 22 Oct 2013 05:46:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-76) Release Remoting JMX
	1.1.2.Final
In-Reply-To: <JIRA.12508433.1382435066134@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508433.1382435066134@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508433.1382435066134.10504.1382435162408@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created REMJMX-76:
--------------------------------------

             Summary: Release Remoting JMX 1.1.2.Final
                 Key: REMJMX-76
                 URL: https://issues.jboss.org/browse/REMJMX-76
             Project: Remoting JMX
          Issue Type: Task
          Components: Build
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 1.1.2.CR1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 06:01:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Oct 2013 06:01:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2354) Webservice13 tck failures
 introduced by ejb3 and security change
In-Reply-To: <JIRA.12508431.1382433027000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508431.1382433027000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508431.1382433027000.10522.1382436063579@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823904#comment-12823904 ] 

RH Bugzilla Integration commented on WFLY-2354:
-----------------------------------------------

Emmanuel Hugonnet (ehsavoie) <ehugonne at redhat.com> made a comment on [bug 1021543|https://bugzilla.redhat.com/show_bug.cgi?id=1021543]

PR : https://github.com/jbossas/jboss-eap/pull/583
                
> Webservice13 tck failures introduced by ejb3 and security change 
> -----------------------------------------------------------------
>
>                 Key: WFLY-2354
>                 URL: https://issues.jboss.org/browse/WFLY-2354
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>
> There 2 tck regression failures under webserivice13 directory in EAP 6.2.0.ER6. 
> IT turns out the change[2] introduced this two failures:
> [1]https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP6/view/TCK6-EAP6/job/tck6-eap6-webservices13/lastCompletedBuild/testReport/unknownTestSuite.0/
> [2][2]https://github.com/jbossas/jboss-eap/commit/72d5cd3f96540519a9747579dd3b85f0f564b64c
> EAP 6.2.0.ER6 sever error message:
> ------------------------------------------------------------------------------
> 18:32:00,338 ERROR [org.jboss.as.ejb3.invocation] (http-myserver.com/127.0.0.1:8080-1) JBAS014134: EJB Invocation failed on component WSEjbSingletonTest for method public java.lang.String com.sun.ts.tests.webservices13.ejb.annotations.WSEjbSingletonTest.HelloBean.bye(java.lang.String): javax.ejb.EJBException: java.lang.IllegalStateException: JBAS014485: EJB WSEjbSingletonTest is enabled for security but doesn't have a security domain set
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:189) [jboss-as-ejb3-7.3.0.Final-redhat-SNAPSHOT.jar:7.3.0.Final-redhat-SNAPSHOT]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 06:01:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Oct 2013 06:01:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2354) Webservice13 tck failures
 introduced by ejb3 and security change
In-Reply-To: <JIRA.12508431.1382433027000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508431.1382433027000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508431.1382433027000.10525.1382436063704@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823905#comment-12823905 ] 

RH Bugzilla Integration commented on WFLY-2354:
-----------------------------------------------

Emmanuel Hugonnet (ehsavoie) <ehugonne at redhat.com> changed the Status of [bug 1021543|https://bugzilla.redhat.com/show_bug.cgi?id=1021543] from NEW to ASSIGNED
                
> Webservice13 tck failures introduced by ejb3 and security change 
> -----------------------------------------------------------------
>
>                 Key: WFLY-2354
>                 URL: https://issues.jboss.org/browse/WFLY-2354
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>
> There 2 tck regression failures under webserivice13 directory in EAP 6.2.0.ER6. 
> IT turns out the change[2] introduced this two failures:
> [1]https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP6/view/TCK6-EAP6/job/tck6-eap6-webservices13/lastCompletedBuild/testReport/unknownTestSuite.0/
> [2][2]https://github.com/jbossas/jboss-eap/commit/72d5cd3f96540519a9747579dd3b85f0f564b64c
> EAP 6.2.0.ER6 sever error message:
> ------------------------------------------------------------------------------
> 18:32:00,338 ERROR [org.jboss.as.ejb3.invocation] (http-myserver.com/127.0.0.1:8080-1) JBAS014134: EJB Invocation failed on component WSEjbSingletonTest for method public java.lang.String com.sun.ts.tests.webservices13.ejb.annotations.WSEjbSingletonTest.HelloBean.bye(java.lang.String): javax.ejb.EJBException: java.lang.IllegalStateException: JBAS014485: EJB WSEjbSingletonTest is enabled for security but doesn't have a security domain set
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:189) [jboss-as-ejb3-7.3.0.Final-redhat-SNAPSHOT.jar:7.3.0.Final-redhat-SNAPSHOT]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 06:15:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Oct 2013 06:15:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2338) When using a JDBC object
 store,
 the RecoveryManager service stop can occur after the datasource is already
 stopped
In-Reply-To: <JIRA.12508208.1382112933000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508208.1382112933000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508208.1382112933000.10543.1382436902540@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823909#comment-12823909 ] 

RH Bugzilla Integration commented on WFLY-2338:
-----------------------------------------------

Ondrej Chaloupka <ochaloup at redhat.com> made a comment on [bug 1020881|https://bugzilla.redhat.com/show_bug.cgi?id=1020881]

I'm blocked by this issue in my testing I'm adding TestBlocker keyword.

As server stucks for reload and shutdown in most of the cases this issue blocks my testing of the JDBC object store.
                
> When using a JDBC object store, the RecoveryManager service stop can occur after the datasource is already stopped
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2338
>                 URL: https://issues.jboss.org/browse/WFLY-2338
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Transactions
>            Reporter: Tom Jenkinson
>            Assignee: Stefano Maestri
>         Attachments: 0001-patching-servicename-for-ds-dependency.patch
>
>
> It should be the cause of https://bugzilla.redhat.com/show_bug.cgi?id=1020881
> It has the effects described in the BZ, i.e. can cause warnings or can entirely block the application server from stopping

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 06:31:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 22 Oct 2013 06:31:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1721) AUTH and ENCRYPT protocols
 configured with plain text passwords
In-Reply-To: <JIRA.12508425.1382426440000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508425.1382426440000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508425.1382426440000.10624.1382437862180@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1721:
---------------------------

    Fix Version/s: 3.5

    
> AUTH and ENCRYPT protocols configured with plain text passwords
> ---------------------------------------------------------------
>
>                 Key: JGRP-1721
>                 URL: https://issues.jboss.org/browse/JGRP-1721
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Martin Gencur
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> The following parameters of AUTH protocol are stored as plain text:
> * keystore_password
> The following parameters of ENCRYPT protocol are stored as plain text:
> * store_password
> * key_password
> Example:
> {code}
> <ENCRYPT key_store_name="defaultStore.keystore" store_password="changeit" alias="myKey"/>
> {code}
> Requirements for storing passwords: https://docspace.corp.redhat.com/docs/DOC-131628

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 06:31:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 22 Oct 2013 06:31:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1722) Improve performance of
	ENCRYPT protocol
In-Reply-To: <JIRA.12508426.1382426974000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508426.1382426974000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508426.1382426974000.10627.1382437862290@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1722:
---------------------------

    Fix Version/s: 3.5

    
> Improve performance of ENCRYPT protocol
> ---------------------------------------
>
>                 Key: JGRP-1722
>                 URL: https://issues.jboss.org/browse/JGRP-1722
>             Project: JGroups
>          Issue Type: Enhancement
>    Affects Versions: 3.4
>            Reporter: Martin Gencur
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> A stress tests with the following setup showed that performance (reads and writes/sec) is halved when ENCRYPT protocol is enabled:
> Infinispan had distributed sync cache with 2 owners on 4 nodes, no transactions. The stress test used 10 threads on each node accessing 1024 byte entries, no conflicts on keys, 20 % writes, 80 % reads. 
> It would be great if we could improve the performance of ENCRYPT protocol.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 06:35:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 22 Oct 2013 06:35:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2079) Update security realm
 <authorization /> to support multiple definitions.
In-Reply-To: <JIRA.12500754.1379329977000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500754.1379329977000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500754.1379329977000.10634.1382438103518@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2079:
-----------------------------------

    Fix Version/s: 9.0.0.CR1
                       (was: 8.0.0.CR1)

    
> Update security realm <authorization /> to support multiple definitions.
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2079
>                 URL: https://issues.jboss.org/browse/WFLY-2079
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 9.0.0.CR1
>
>
> Complex configuration could result in different methods being used for authentication, as a result we may also need to support multiple sources for loading group membership information.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 06:51:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 22 Oct 2013 06:51:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-76) Release Remoting JMX
	1.1.2.Final
In-Reply-To: <JIRA.12508433.1382435066000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508433.1382435066000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508433.1382435066000.10664.1382439062188@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/REMJMX-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved REMJMX-76.
------------------------------------

    Resolution: Done

    
> Release Remoting JMX 1.1.2.Final
> --------------------------------
>
>                 Key: REMJMX-76
>                 URL: https://issues.jboss.org/browse/REMJMX-76
>             Project: Remoting JMX
>          Issue Type: Task
>          Components: Build
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.2.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 06:53:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 22 Oct 2013 06:53:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-19) Optimise server side
 notifications to eliminate serialization issue re different instances of
 same filter and hand back server side.
In-Reply-To: <JIRA.12456336.1326305121000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12456336.1326305121000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12456336.1326305121000.10677.1382439182130@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/REMJMX-19?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated REMJMX-19:
-----------------------------------

    Fix Version/s: 2.0.0.CR5
                       (was: 1.1.2.Final)

    
> Optimise server side notifications to eliminate serialization issue re different instances of same filter and hand back server side.
> ------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: REMJMX-19
>                 URL: https://issues.jboss.org/browse/REMJMX-19
>             Project: Remoting JMX
>          Issue Type: Task
>          Components: Notifications
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 2.0.0.CR5
>
>
> The NotificationMBeanSupport class compares these items by identity so when different copies are received server side it breaks these comparisons.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 06:53:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 22 Oct 2013 06:53:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-10) Internationalisation of log
	messages
In-Reply-To: <JIRA.12455938.1325851646000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12455938.1325851646000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12455938.1325851646000.10680.1382439182182@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/REMJMX-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated REMJMX-10:
-----------------------------------

    Fix Version/s: 2.0.0.CR5
                       (was: 1.1.2.Final)

    
> Internationalisation of log messages
> ------------------------------------
>
>                 Key: REMJMX-10
>                 URL: https://issues.jboss.org/browse/REMJMX-10
>             Project: Remoting JMX
>          Issue Type: Task
>            Reporter: Darran Lofthouse
>             Fix For: 2.0.0.CR5
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 06:53:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 22 Oct 2013 06:53:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-8) Connection state notification
	suppport
In-Reply-To: <JIRA.12455935.1325851513000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12455935.1325851513000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12455935.1325851513000.10682.1382439182213@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/REMJMX-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated REMJMX-8:
----------------------------------

    Fix Version/s: 2.0.0.CR5
                       (was: 1.1.2.Final)

    
> Connection state notification suppport
> --------------------------------------
>
>                 Key: REMJMX-8
>                 URL: https://issues.jboss.org/browse/REMJMX-8
>             Project: Remoting JMX
>          Issue Type: Task
>          Components: Connection, Notifications
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 2.0.0.CR5
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 06:53:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 22 Oct 2013 06:53:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-4) Allow for long method calls
 within the protocol.
In-Reply-To: <JIRA.12455930.1325850649000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12455930.1325850649000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12455930.1325850649000.10686.1382439182293@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/REMJMX-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated REMJMX-4:
----------------------------------

    Fix Version/s: 2.0.0.CR5
                       (was: 1.1.2.Final)

    
> Allow for long method calls within the protocol.
> ------------------------------------------------
>
>                 Key: REMJMX-4
>                 URL: https://issues.jboss.org/browse/REMJMX-4
>             Project: Remoting JMX
>          Issue Type: Task
>          Components: Connection, RPC
>            Reporter: Darran Lofthouse
>             Fix For: 2.0.0.CR5
>
>
> Methods such as invoke could take a long time to return depending on what the MBean is actually doing.
> This task is to build support for this into the protocol, 2 initial ideas are: -
>  1 - Allow the client to 'ping' the server after a request has timed out and ask the server is this request still running, server side the we can track the correlation IDs of current requests an check it is still in-progress.
>  2 - The server could periodically send a message to the client to say the message is still in progress, the client could cache these and on timing out check if one has been received recently and wait again if one has.
>  3 - Any other suggestions?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 06:55:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Oct 2013 06:55:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-74) REMJMX-65 Overzealous
 disabling local authentication
In-Reply-To: <JIRA.12508386.1382374102000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508386.1382374102000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508386.1382374102000.10692.1382439302417@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/REMJMX-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823920#comment-12823920 ] 

RH Bugzilla Integration commented on REMJMX-74:
-----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> changed the Status of [bug 1021630|https://bugzilla.redhat.com/show_bug.cgi?id=1021630] from ASSIGNED to POST
                
> REMJMX-65 Overzealous disabling local authentication
> ----------------------------------------------------
>
>                 Key: REMJMX-74
>                 URL: https://issues.jboss.org/browse/REMJMX-74
>             Project: Remoting JMX
>          Issue Type: Bug
>          Components: Connection
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.2.Final, 2.0.0.CR4
>
>
> REMJMX-65 is overzealous at disabling local authentication, if a username and credential is supplied in the environment then it does make sense to disable local authentication - however the availability of a callback handler is not a sufficient flag to also disable it.
> In the case of the callback handler the user may still only want to be prompted if the other mechanisms fail.
> This issue will remove the disabling of local authentication based on the presence of a callback handler and will instead add a configuration option that can be set on the environment.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 07:39:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Tue, 22 Oct 2013 07:39:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2329) File upload doesn't work
In-Reply-To: <JIRA.12508122.1382032527000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508122.1382032527000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508122.1382032527000.10861.1382441942104@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-2329.
----------------------------------

    Fix Version/s: 8.0.0.CR1
       Resolution: Done

    
> File upload doesn't work
> ------------------------
>
>                 Key: WFLY-2329
>                 URL: https://issues.jboss.org/browse/WFLY-2329
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JSF, Web (JBoss Web)
>    Affects Versions: 8.0.0.Beta1
>         Environment: - Windows 7 64
> - Wildfly Beta 1
> - JSF Mojarra 2.2.3
> - Primefaces 4.0
> - Apache commons-io-2.4 & commons-fileupload-1.3
>            Reporter: Domen Cebulj
>            Assignee: Stuart Douglas
>              Labels: fileUpload, jsf22, primefaces, servlet
>             Fix For: 8.0.0.CR1
>
>
> In the previous version it worked, but in Beta 1 stopped worked file uploading with PF4 and Mojarra 2.2.3 (neither simple upload didn't work - tested on blank project, only with PF4 and Apache libs and configured web.xml file)
> I get no error in IDE or JS console.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 07:39:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Tue, 22 Oct 2013 07:39:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2333) Web deployment code assumes
 only a single ServletContainerInitializer is present in each jar
In-Reply-To: <JIRA.12508164.1382090257000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508164.1382090257000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508164.1382090257000.10857.1382441942013@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-2333.
----------------------------------

    Fix Version/s: 8.0.0.CR1
       Resolution: Done

    
> Web deployment code assumes only a single ServletContainerInitializer is present in each jar
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2333
>                 URL: https://issues.jboss.org/browse/WFLY-2333
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 07:52:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Oct 2013 07:52:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1487) X509Token Authentication is
 vulnerable to replay attacks
In-Reply-To: <JIRA.12469666.1340962910000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12469666.1340962910000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12469666.1340962910000.10894.1382442722090@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated JGRP-1487:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1021952

    
> X509Token Authentication is vulnerable to replay attacks
> --------------------------------------------------------
>
>                 Key: JGRP-1487
>                 URL: https://issues.jboss.org/browse/JGRP-1487
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.0.9
>            Reporter: sreenivas chinimilli
>            Assignee: Bela Ban
>             Fix For: Future
>
>
> In the implementation of X509Token Authentication
> The auth_value is enrypted with the certificate within the keystore and
> during verification encrypted auth value is decrypted with the private key
> compared against the orignial auth value.
> This implementation is prone to replay attacks, that is
> any user with out having any knowledge of the auth value can join the group
> by replaying the enrypted auth value captured in earlier sessions.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 07:52:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Oct 2013 07:52:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1487) X509Token Authentication is
 vulnerable to replay attacks
In-Reply-To: <JIRA.12469666.1340962910000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12469666.1340962910000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12469666.1340962910000.10900.1382442722248@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823942#comment-12823942 ] 

RH Bugzilla Integration commented on JGRP-1487:
-----------------------------------------------

Martin Gencur <mgencur at redhat.com> made a comment on [bug 1021952|https://bugzilla.redhat.com/show_bug.cgi?id=1021952]

See description of the bug in linked JIRA.
                
> X509Token Authentication is vulnerable to replay attacks
> --------------------------------------------------------
>
>                 Key: JGRP-1487
>                 URL: https://issues.jboss.org/browse/JGRP-1487
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.0.9
>            Reporter: sreenivas chinimilli
>            Assignee: Bela Ban
>             Fix For: Future
>
>
> In the implementation of X509Token Authentication
> The auth_value is enrypted with the certificate within the keystore and
> during verification encrypted auth value is decrypted with the private key
> compared against the orignial auth value.
> This implementation is prone to replay attacks, that is
> any user with out having any knowledge of the auth value can join the group
> by replaying the enrypted auth value captured in earlier sessions.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 08:04:01 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 22 Oct 2013 08:04:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2328) Unable to deploy WS after
 (unrelated) http-listener changes
In-Reply-To: <JIRA.12505589.1382010398000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12505589.1382010398000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12505589.1382010398000.10952.1382443441882@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-2328:
------------------------------

    Component/s: Web (Undertow)

    
> Unable to deploy WS after (unrelated) http-listener changes
> -----------------------------------------------------------
>
>                 Key: WFLY-2328
>                 URL: https://issues.jboss.org/browse/WFLY-2328
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow), Web Services
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Josef Cacek
>            Assignee: Tomaz Cerar
>            Priority: Critical
>             Fix For: 8.0.0.CR1
>
>         Attachments: jaxws-basic-pojo.war
>
>
> WS tests fail in basic integration testsuite if they run after
> {{testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/management/api/web/ListenerTestCase.java}} (which usually doesn't happen on our TeamCity, but it's the case on my machine).
> The logfile contains:
> {code}
> 13:39:14,409 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017519: Undertow HTTP listener test-listener listening on localhost/127.0.0.1:8181
> 13:39:14,576 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017521: Undertow HTTP listener test-listener suspending
> 13:39:14,577 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017520: Undertow HTTP listener test-listener stopped, was bound to localhost/127.0.0.1:8181
> 13:39:14,943 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015876: Starting deployment of "jaxws-basic-pojo.war" (runtime-name: "jaxws-basic-pojo.war")
> 13:39:15,247 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.unit."jaxws-basic-pojo.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."jaxws-basic-pojo.war".INSTALL: JBAS018733: Failed to process phase INSTALL of deployment "jaxws-basic-pojo.war"
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: java.lang.IllegalStateException
> 	at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:47) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at org.wildfly.extension.undertow.WebServerService.getPort(WebServerService.java:64)
> 	at org.jboss.as.webservices.config.WebServerInfoImpl.getPort(WebServerInfoImpl.java:36)
> 	at org.jboss.ws.common.management.AbstractServerConfig.getConnectorPort(AbstractServerConfig.java:207)
> 	at org.jboss.ws.common.management.AbstractServerConfig.getWebServicePort(AbstractServerConfig.java:170)
> 	at org.jboss.ws.common.deployment.EndpointAddressDeploymentAspect$PortValue.getPortValue(EndpointAddressDeploymentAspect.java:198)
> 	at org.jboss.ws.common.deployment.EndpointAddressDeploymentAspect$PortValue.getValue(EndpointAddressDeploymentAspect.java:191)
> 	at org.jboss.ws.common.deployment.EndpointAddressDeploymentAspect.start(EndpointAddressDeploymentAspect.java:77)
> 	at org.jboss.as.webservices.deployers.AspectDeploymentProcessor.deploy(AspectDeploymentProcessor.java:75)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	... 5 more
> 13:39:15,260 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014613: Operation ("deploy") failed - address: (\{"deployment" => "jaxws-basic-pojo.war"\}) - failure description: \{"JBAS014671: Failed services" => \{"jboss.deployment.unit.\"jaxws-basic-pojo.war\".INSTALL" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"jaxws-basic-pojo.war\".INSTALL: JBAS018733: Failed to process phase INSTALL of deployment \"jaxws-basic-pojo.war\"
>     Caused by: java.lang.IllegalStateException"\}\}
> 13:39:15,263 ERROR [org.jboss.as.server] (management-handler-thread - 4) JBAS015870: Deploy of deployment "jaxws-basic-pojo.war" was rolled back with the following failure message: 
> \{"JBAS014671: Failed services" => \{"jboss.deployment.unit.\"jaxws-basic-pojo.war\".INSTALL" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"jaxws-basic-pojo.war\".INSTALL: JBAS018733: Failed to process phase INSTALL of deployment \"jaxws-basic-pojo.war\"
>     Caused by: java.lang.IllegalStateException"\}\}
> 13:39:15,274 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-7) JBAS015877: Stopped deployment jaxws-basic-pojo.war (runtime-name: jaxws-basic-pojo.war) in 11ms
> 13:39:15,275 INFO  [org.jboss.as.controller] (management-handler-thread - 4) JBAS014774: Service status report
> JBAS014777:   Services which failed to start:      service jboss.deployment.unit."jaxws-basic-pojo.war".INSTALL
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 08:11:01 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Oct 2013 08:11:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBRULES-3666) kbase holds multiple
 KnowledgeBaseEventListenerWrapper instances when adding the same
 KnowledgeBaseEventListener multiple times
In-Reply-To: <JIRA.12477585.1350909161000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12477585.1350909161000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12477585.1350909161000.10957.1382443861928@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBRULES-3666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823950#comment-12823950 ] 

RH Bugzilla Integration commented on JBRULES-3666:
--------------------------------------------------

Kanchan Desai <kadesai at redhat.com> made a comment on [bug 958394|https://bugzilla.redhat.com/show_bug.cgi?id=958394]

Hi Tomas,

Can you please share some more info on this bug.
                
> kbase holds multiple KnowledgeBaseEventListenerWrapper instances when adding the same KnowledgeBaseEventListener multiple times
> -------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-3666
>                 URL: https://issues.jboss.org/browse/JBRULES-3666
>             Project: JBRULES
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.5.0.Beta1
>            Reporter: Toshiya Kobayashi
>            Assignee: Mario Fusco
>             Fix For: 5.5.0.Final
>
>
> When you add the same KnowledgeBaseEventListener to kbase twice, kbase holds both KnowledgeBaseEventListenerWrapper instances. I'm not 100% sure if this is a bug but I guess KnowledgeBaseEventListenerWrapper should implement equals() method like StatefulKnowledgeSessionImpl$AgendaEventListenerWrapper.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 08:17:02 2013
From: jira-events at lists.jboss.org (R Searls (JIRA))
Date: Tue, 22 Oct 2013 08:17:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-703) HttpHandlers configuration for
 EJB3 Webservice Endpoints
In-Reply-To: <JIRA.12469749.1341217769000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12469749.1341217769000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12469749.1341217769000.10974.1382444222210@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823953#comment-12823953 ] 

R Searls commented on WFLY-703:
-------------------------------

-- capture of an email discussion on this issue

from Tomaz Cercar  .... 	October 21, 2013 6:46 PM
Yes,

HttpHandler is undertow equivalent of Tomcat's Valve

And this task is just to add features we now have for web deployments (jboss-web.xml) also to non-web deployments that can result in web "endpoints" for example JAX-RS and JAX-WS.

Probably best place to add this would be with jboss-all.xml which is meant for cases like this.

To be fair it feels that work required to implement this properly is not an easy task.

> From: Alessio Soldano [mailto:asoldano at redhat.com]
> Sent: Thursday, October 17, 2013 5:33 PM

> my understanding is that with "HttpHandlers" Tomaz here is referring to a
> lower level abstraction then the JAXWS handlers. The Undertow handlers
> would basically replace the valve stuff in tomcat / jbossweb.
> My understanding (but I might be missing something) is that the goal here is
> to provide users with a mechanism for setting this low level http server thing
> for a ws application regardless of it being based on a POJO or  on a EJB3
> bean.
>

> On 16/10/13 20:21, Rebecca Searls wrote:
> >    This is sounding to me like what you want is generic JAX-WS
> > Handler-Chain support for EJB WS endpoints and to be able to define
> handler-chains from the EJB subsystem.  Does this sound right?
> >

> >> From: "Tomaz Cerar" <tcerar at redhat.com>
> >>
> >> I discussed this with few guys a bit, if anything we need to expand
> >> support for http handlers to also expand beyond just web deployment.
> >> Valves ware thing of jbossweb, HttpHandlers are thing of undertow.
> >>
> >> Valve support will be added to undertow but only to help migration
> >> from previous versions basically it will be limited support for legacy
> valves.
> >>
> >> I have updated related jira to be more in line with current state of
> >> the project.
                
> HttpHandlers configuration for EJB3 Webservice Endpoints
> --------------------------------------------------------
>
>                 Key: WFLY-703
>                 URL: https://issues.jboss.org/browse/WFLY-703
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>            Reporter: Sebastian Maurer
>            Assignee: R Searls
>             Fix For: Awaiting Volunteers
>
>
> Please add a way to configure handlers for EJB3 endpoints packaged in an ejb-jar.
> At the moment there is no option in any of the ejb deployment descriptors and of course it isn't possible to configure valves globally.
> The only way to configure handlers is by handlers.conf of ServletExcention at the moment, but this is currently limited to web deployments only.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 08:37:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 22 Oct 2013 08:37:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2319) LDAP Search containing URL -
 InvalidNameException: ldap:: [LDAP: error code 34 - Invalid root Dn given
In-Reply-To: <JIRA.12503254.1381931058000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503254.1381931058000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503254.1381931058000.11049.1382445423720@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2319:
-----------------------------------

    Attachment: LdapSearching.tgz


Adding the test project used to reproduce this.
                
> LDAP Search containing URL - InvalidNameException: ldap:: [LDAP: error code 34 - Invalid root Dn given
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2319
>                 URL: https://issues.jboss.org/browse/WFLY-2319
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Darran Lofthouse
>            Assignee: Eduardo Martins
>             Fix For: 8.0.0.CR1
>
>         Attachments: LdapSearching.tgz
>
>
> The following code: -
> {code}
>         Hashtable env = new Hashtable();
>         env.put("java.naming.factory.initial", "com.sun.jndi.ldap.LdapCtxFactory");
>         env.put("java.naming.security.authentication", "simple");
>         env.put("java.naming.provider.url", "ldap://localhost:10389");
>         env.put(InitialDirContext.SECURITY_PRINCIPAL, "uid=admin,ou=system");
>         env.put(InitialDirContext.SECURITY_CREDENTIALS, "secret");
>         SearchControls ctl = null;
>         String attrArr[] = new String[1];
>         attrArr[0] = "sn";
>         ctl = new SearchControls(2, 0L, 0, attrArr, false, false);
>         String base = "ldap://localhost:10389/dc=simple,dc=wildfly,dc=org";
>         String filter = "(uid=UserOne)";
>         NamingEnumeration nenum = null;
>         DirContext ictx = null;
>             ictx = new InitialDirContext(env);
>             nenum = ictx.search(base, filter, ctl);
> {code}
> Results in the following exception: -
> {noquote}
> 13:03:45,598 ERROR [stderr] (default task-1) javax.naming.InvalidNameException: ldap:: [LDAP: error code 34 - Invalid root Dn given : ldap: (0x6C 0x64 0x61 0x70 0x3A ) is invalid]; remaining name 'ldap://localhost:10389/dc=simple,dc=wildfly,dc=org'
> 13:03:45,599 ERROR [stderr] (default task-1) 	at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3025)
> 13:03:45,600 ERROR [stderr] (default task-1) 	at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2840)
> 13:03:45,600 ERROR [stderr] (default task-1) 	at com.sun.jndi.ldap.LdapCtx.c_lookup(LdapCtx.java:1034)
> {noquote}
> Switching to a base that does not begin with a URL and the search works, executing this code outside of WildFly also works.
> The underlying issue is that the default InitialContext implementation contains the following method: -
> {code}
>     protected Context getURLOrDefaultInitCtx(String name)
>         throws NamingException {
>         if (NamingManager.hasInitialContextFactoryBuilder()) {
>             return getDefaultInitCtx();
>         }
>         String scheme = getURLScheme(name);
>         if (scheme != null) {
>             Context ctx = NamingManager.getURLContext(scheme, myProps);
>             if (ctx != null) {
>                 return ctx;
>             }
>         }
>         return getDefaultInitCtx();
>     }
> {code}
> As the naming subsystem has registered a InitialContextFactoryBuilder this code will never fall down to the scheme specific section.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 09:17:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Oct 2013 09:17:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2338) When using a JDBC object
 store,
 the RecoveryManager service stop can occur after the datasource is already
 stopped
In-Reply-To: <JIRA.12508208.1382112933000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508208.1382112933000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508208.1382112933000.11163.1382447822257@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823973#comment-12823973 ] 

RH Bugzilla Integration commented on WFLY-2338:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1020881|https://bugzilla.redhat.com/show_bug.cgi?id=1020881] from NEW to POST
                
> When using a JDBC object store, the RecoveryManager service stop can occur after the datasource is already stopped
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2338
>                 URL: https://issues.jboss.org/browse/WFLY-2338
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Transactions
>            Reporter: Tom Jenkinson
>            Assignee: Stefano Maestri
>         Attachments: 0001-patching-servicename-for-ds-dependency.patch
>
>
> It should be the cause of https://bugzilla.redhat.com/show_bug.cgi?id=1020881
> It has the effects described in the BZ, i.e. can cause warnings or can entirely block the application server from stopping

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 09:32:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Oct 2013 09:32:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1094) Use own JSSE Provider for
	http Connector
In-Reply-To: <JIRA.12480379.1354616410000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12480379.1354616410000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12480379.1354616410000.11271.1382448722681@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12823984#comment-12823984 ] 

RH Bugzilla Integration commented on WFLY-1094:
-----------------------------------------------

Tomaz Cerar <tcerar at redhat.com> changed the Status of [bug 956391|https://bugzilla.redhat.com/show_bug.cgi?id=956391] from NEW to POST
                
> Use own JSSE Provider for http Connector
> ----------------------------------------
>
>                 Key: WFLY-1094
>                 URL: https://issues.jboss.org/browse/WFLY-1094
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Web (JBoss Web)
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Hauke Mehrtens
>            Assignee: Tomaz Cerar
>              Labels: https, jsse, ssl
>             Fix For: 8.0.0.Alpha1
>
>         Attachments: ssl-protocol.patch
>
>
> We are using our own JSSE Provider implementation for TLS to add support for HTTPS with preshared key to one http connector, while the others still use the default JSSE provider.
> In JBoss 5 we added sslProtocol="RFC4279", while RFC4279 is the name of our provider, to one Connector entry in the file server/default/deploy/jbossweb.sar/server.xml. This option is not available in JBoss 7.1 any more and we could not find a way to make one connector use our provider while the others are using the default one.
> To fix this issue for use we used the attached patch. We would like to get this patch into the next version of JBoss, so we do not have to modify the source code by our self any more. This patch was tested with JBoss 7.1.2, but it still applies against the master branch. If we should do any changed to the patch or if you want to get it in an other form please inform us.
> With this patch we are able to specify our JSSE provider like this:
> {code:xml}
> <connector name="httpspsk" protocol="HTTP/1.1" scheme="https" socket-binding="httpspsk" secure="true">
>   <ssl name="ssl" key-alias="intended purpose ssl test from bremen online services" password="123456" certificate-key-file="${jboss.server.config.dir}/governikus_ssl.jks" protocol="ALL" keystore-type="JKS" ssl_protocol="RFC4279"/>
> </connector>
> {code}
> This is related to Red Hat Customer Portal support case 00721624 "Additional JSSE Provider on socket bindings and connectors"

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 11:03:02 2013
From: jira-events at lists.jboss.org (Daniele Pizzagalli (JIRA))
Date: Tue, 22 Oct 2013 11:03:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-29) An ear file with modules in
 subfolders can not deploy under AS 7.0
In-Reply-To: <JIRA.12449097.1318316227000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12449097.1318316227000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12449097.1318316227000.11585.1382454182465@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824031#comment-12824031 ] 

Daniele Pizzagalli commented on WFLY-29:
----------------------------------------

Hello, how can I fix this problem if I have no write permissions inside the root, but only over the sub-directory? I've still not being able to migrate to 7.0 because of this bug.
                
> An ear file with modules in subfolders can not deploy under AS 7.0
> ------------------------------------------------------------------
>
>                 Key: WFLY-29
>                 URL: https://issues.jboss.org/browse/WFLY-29
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EE
>            Reporter: Adrian Zuo
>            Assignee: David Lloyd
>             Fix For: 8.0.0.CR1
>
>         Attachments: migrate.ear, migrate.ear
>
>
> I have an ear file names migrate.ear which contains one ejb jar (ejb.jar) and one war file (war.war), if I put the ejb jar to a ejb folder and war file to war folder, the ear can not be depoyed.
> If I move the ejb jar and war file out, it can be deployed. 
> Below  structuer can be deployed:
> ejb.jar
> lib/
> lib/util-1.0-SNAPSHOT.jar
> lib/version.jar
> META-INF/
> META-INF/application.xml
> META-INF/MANIFEST.MF
> war.war
>  
> Below structure can not be deployed:
> ejb/
> ejb/ejb.jar
> lib/
> lib/util-1.0-SNAPSHOT.jar
> lib/version.jar
> META-INF/
> META-INF/application.xml
> META-INF/MANIFEST.MF
> war/
> war/war.war
> Below is the error:
> http://community.jboss.org/message/630869#630869

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 11:32:02 2013
From: jira-events at lists.jboss.org (James Myers (JIRA))
Date: Tue, 22 Oct 2013 11:32:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-309) Multiple threads working
 with traits against same knowledge base hangs
In-Reply-To: <JIRA.12508490.1382455844484@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508490.1382455844484@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508490.1382455844484.11624.1382455922097@jira02.app.mwc.hst.phx2.redhat.com>

James Myers created DROOLS-309:
----------------------------------

             Summary: Multiple threads working with traits against same knowledge base hangs
                 Key: DROOLS-309
                 URL: https://issues.jboss.org/browse/DROOLS-309
             Project: Drools
          Issue Type: Quality Risk
      Security Level: Public (Everyone can see)
    Affects Versions: 5.5.0.Final
            Reporter: James Myers
            Assignee: Mark Proctor


In our web system, we are creating new StatefulKnowledgeSession per user session and executing a set of rules containing trait donning.  This starts to hang (seemingly indefinitely) with following type of stack trace (usually initiated from insert/update):

{quote}
   java.lang.Thread.State: RUNNABLE
	at org.drools.core.util.TripleStore.getAll(TripleStore.java:188)
	at org.drools.factmodel.traits.TripleBasedStruct.getTriplesForSubject(TripleBasedStruct.java:165)
	at org.drools.factmodel.traits.ThingorgdroolsfactmodeltraitsTraitSession$ItemWrapperProxyWrapper.hashCode(Unknown Source)
	at org.drools.factmodel.traits.TraitProxy.hashCode(TraitProxy.java:110)
	at org.drools.factmodel.traits.ThingorgdroolsfactmodeltraitsTraitSession$ItemWrapperProxy.hashCode(Unknown Source)
	at org.drools.common.DefaultFactHandle.<init>(DefaultFactHandle.java:110)
	at org.drools.common.DefaultFactHandle.<init>(DefaultFactHandle.java:98)
	at org.drools.common.TraitFactHandle.<init>(TraitFactHandle.java:26)
	at org.drools.reteoo.ReteooFactHandleFactory.newFactHandle(ReteooFactHandleFactory.java:80)
	at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:68)
	at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:53)
	at org.drools.common.NamedEntryPoint.createHandle(NamedEntryPoint.java:765)
	at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:301)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903)
{quote}

Here is a unit test for org.drools.factmodel.traits.TraitTest.  It's not perfect because it will spawn thread that might never die and may need thread/iteration count increased to fail consistently, but capturing a stack trace a few seconds in should show all threads in "getAll()":

{code}
    @Traitable
    public static class Item {
    	private String id;

    	public String getId() {
    		return id;
    	}

    	public void setId(String id) {
    		this.id = id;
    	}
    }

    public static class TraitRulesThread implements Runnable {
    	int threadIndex;
    	int numRepetitions;
    	StatefulKnowledgeSession ksession;

    	public TraitRulesThread(int threadIndex, int numRepetitions, final StatefulKnowledgeSession ksession) {
    		this.threadIndex = threadIndex;
    		this.numRepetitions = numRepetitions;
    		this.ksession = ksession;
    	}
    	public void run() {
    		for (int repetitionIndex = 0; repetitionIndex < numRepetitions; repetitionIndex++) {
    			final Item i = new Item();
    			i.setId(String.format("testId_%d%d", threadIndex, repetitionIndex));
    			ksession.insert(i);
    			ksession.fireAllRules();
    		}
    	}
    }

    @Test
    public void testMultithreadingTraits() throws InterruptedException {
    	final String s1 = "package test;\n" +
    	"import org.drools.factmodel.traits.TraitTest.Item;\n" +
    	"declare Item end\n" +
    	"declare trait ItemStyle\n" +
    	"	id: String\n" +
    	"	adjustable: boolean\n" +
    	"end\n" +
    	"rule \"Don ItemStyle\"\n" +
    	"	no-loop true\n" +
    	"	when\n" +
    	"		$p : Item ()\n" +
    	"		not ItemStyle ( id == $p.id )\n" +
    	"	then\n" +
    	"		don($p, ItemStyle.class);\n" +
    	"end\n" +
    	"rule \"Item Style - Adjustable\"" +
    	"	no-loop true" +
    	"	when" +
    	"		$style : ItemStyle ( !adjustable )" +
    	"		Item (" +
    	"			id == $style.id " +
    	"		)" +
    	"	then" +
    	"		modify($style) {" +
    	"			setAdjustable(true)" +
    	"		};" +
    	"end";
    	final KnowledgeBase kbase = getKnowledgeBaseFromString(s1);

    	// might need to tweak these numbers.  often works with 7-10,100,60, but often fails 15-20,100,60
    	int MAX_THREADS = 20;
    	int MAX_REPETITIONS = 100;
    	int MAX_WAIT_SECONDS = 60;

    	final ExecutorService executorService = Executors.newFixedThreadPool(MAX_THREADS);
    	for (int threadIndex = 0; threadIndex < MAX_THREADS; threadIndex++) {
    		executorService.execute(new TraitRulesThread(threadIndex, MAX_REPETITIONS, kbase.newStatefulKnowledgeSession()));
    	}

    	executorService.shutdown();
    	executorService.awaitTermination(MAX_WAIT_SECONDS, TimeUnit.SECONDS);
    	final List<Runnable> queuedTasks = executorService.shutdownNow();

    	assertEquals(0, queuedTasks.size());
    	assertEquals(true, executorService.isTerminated());
    }
{code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 11:36:02 2013
From: jira-events at lists.jboss.org (Radoslav Husar (JIRA))
Date: Tue, 22 Oct 2013 11:36:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-216) Include Infinispan CDI as a
	JBoss module
In-Reply-To: <JIRA.12486042.1362141249000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12486042.1362141249000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12486042.1362141249000.11657.1382456162603@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-216:
--------------------------------

       Issue Type: Feature Request  (was: Enhancement)
    Fix Version/s: 9.0.0.CR1
                       (was: 8.0.0.CR1)


This will have to wait till WildFly 9. Until then you can include it yourself.
                
> Include Infinispan CDI as a JBoss module
> ----------------------------------------
>
>                 Key: WFLY-216
>                 URL: https://issues.jboss.org/browse/WFLY-216
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Avelino Martins
>            Assignee: Radoslav Husar
>             Fix For: 9.0.0.CR1
>
>
> CDI has become an invaluable technology on any JavaEE project. I find hard to justify having to include infinispan-cdi as a compile dependency on every project that uses ISPN.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 11:42:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Oct 2013 11:42:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2270) Lack of model integrity
 checking regarding role mappings, standard role names and scoped role names.
In-Reply-To: <JIRA.12502541.1381314949000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502541.1381314949000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502541.1381314949000.11675.1382456522009@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824046#comment-12824046 ] 

RH Bugzilla Integration commented on WFLY-2270:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1018738|https://bugzilla.redhat.com/show_bug.cgi?id=1018738] from POST to MODIFIED
                
> Lack of model integrity checking regarding role mappings, standard role names and scoped role names.
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2270
>                 URL: https://issues.jboss.org/browse/WFLY-2270
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Take the following scoped role definition and assignment: -
> {code}
>             <host-scoped-roles>
>                 <role name="master-Monitior" base-role="MONITOR">
>                     <host name="master"/>
>                 </role>
>             </host-scoped-roles>
> {code}
> {code}
>  <role name="master-Monitior" include-all="true"/>
> {code}
> Removal results in the following: -
> {code}
> [domain at localhost:9990 /] ./core-service=management/access=authorization/host-scoped-role=master-Monitior:remove
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "JBAS014749: Operation handler failed: JBAS013470: Unknown role 'MASTER-MONITIOR'"},
>     "rolled-back" => true
> }
> {code}
> Server side this is reported as: -
> {code}
> [Host Controller] 11:24:57,780 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014612: Operation ("remove") failed - address: ([
> [Host Controller]     ("core-service" => "management"),
> [Host Controller]     ("access" => "authorization"),
> [Host Controller]     ("host-scoped-role" => "master-Monitior")
> [Host Controller] ]): java.lang.IllegalArgumentException: JBAS013470: Unknown role 'MASTER-MONITIOR'
> [Host Controller] 	at org.jboss.as.controller.access.rbac.DefaultPermissionFactory.getUserPermissions(DefaultPermissionFactory.java:134) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.access.rbac.DefaultPermissionFactory.getUserPermissions(DefaultPermissionFactory.java:107) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.access.permission.ManagementPermissionAuthorizer.authorize(ManagementPermissionAuthorizer.java:99) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.access.management.DelegatingConfigurableAuthorizer.authorize(DelegatingConfigurableAuthorizer.java:98) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.OperationContextImpl.getBasicAuthorizationResponse(OperationContextImpl.java:1157) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1059) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.OperationContextImpl.readResourceFromRoot(OperationContextImpl.java:542) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationResolver.getServerOperations(ServerOperationResolver.java:232)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.getServerOperations(ServerOperationsResolverHandler.java:149)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.access$000(ServerOperationsResolverHandler.java:58)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler$2.getServerOperations(ServerOperationsResolverHandler.java:113)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.HostControllerExecutionSupport$Factory$DomainOpExecutionSupport.getServerOps(HostControllerExecutionSupport.java:265)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.execute(ServerOperationsResolverHandler.java:124)
> [Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:609) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:487) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:258) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:143) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:205) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:110) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:157) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:153) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_17]
> [Host Controller] 	at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_17]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [wildfly-protocol-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [wildfly-protocol-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> [Host Controller] 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> [Host Controller] 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> {code}
> At this point I believe that role removal is actually successful, however a subsequent operation is failing as the role previously associated with the user no longer exists.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 11:48:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 22 Oct 2013 11:48:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2355) LdapExtLoginModule fails with
 follow referral
In-Reply-To: <JIRA.12508493.1382456846614@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508493.1382456846614@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508493.1382456846614.11682.1382456882036@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-2355:
--------------------------------------

             Summary:  LdapExtLoginModule fails with follow referral
                 Key: WFLY-2355
                 URL: https://issues.jboss.org/browse/WFLY-2355
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Security
         Environment: Probably not relevant, but Win 7 64, tried on jdk 6 and 7 64-bit.
            Reporter: Darran Lofthouse
            Assignee: Peter Skopek
         Attachments: ldap-referral-test.zip, secured-webapp.war

We connect to AD with LdapExtLoginModule. It so happens that AD keeps  references to some external trees (such as "DomainDnsZones" and "ForestDnsZones") in the root of the LDAP tree. So when you configure LdapExtLoginModule to search any root, it will hit these referrals.

This normally fails with a standard 
{code}
javax.security.auth.login.FailedLoginException: Password Incorrect/Password Required
{code}

. This is not the whole story, though. If you enable the module option
{code}<module-option name="throwValidateError" value="true"/>{code}
, you get a more complete stack trace:

{code}
09:18:14,724 ERROR [org.jboss.security.authentication.JBossCachedAuthenticationManager] (http--127.0.0.1-8080-2) Login failure: javax.security.auth.login.FailedLoginException: Password Incorrect/Password Required
	at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:270) [picketbox-4.0.7.Final.jar:4.0.7.Final]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0]
	at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0]
	at javax.security.auth.login.LoginContext.invoke(LoginContext.java:784) [rt.jar:1.7.0]
	at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203) [rt.jar:1.7.0]
	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698) [rt.jar:1.7.0]
	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696) [rt.jar:1.7.0]
	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0]
	at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695) [rt.jar:1.7.0]
	at javax.security.auth.login.LoginContext.login(LoginContext.java:594) [rt.jar:1.7.0]
	at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:449) [picketbox-infinispan-4.0.7.Final.jar:4.0.7.Final]
	at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:383) [picketbox-infinispan-4.0.7.Final.jar:4.0.7.Final]
	at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:371) [picketbox-infinispan-4.0.7.Final.jar:4.0.7.Final]
	at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:160) [picketbox-infinispan-4.0.7.Final.jar:4.0.7.Final]
	at org.jboss.as.web.security.JBossWebRealm.authenticate(JBossWebRealm.java:214) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
	at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:280) [jbossweb-7.0.13.Final.jar:]
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:381) [jbossweb-7.0.13.Final.jar:]
	at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.1.1.Final.jar:7.1.1.Final]
	at com.company.product.web.fix.ContextClassLoaderValve.invoke(ContextClassLoaderValve.java:19) [classes:]
	at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.13.Final.jar:]
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.13.Final.jar:]
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.13.Final.jar:]
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.13.Final.jar:]
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.13.Final.jar:]
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671) [jbossweb-7.0.13.Final.jar:]
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930) [jbossweb-7.0.13.Final.jar:]
	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0]
Caused by: javax.naming.PartialResultException [Root exception is javax.naming.NotContextException: Cannot create context for: ldap://DomainDnsZones.global.scd.company.com/DC=DomainDnsZones,DC=global,DC=scd,DC=company,DC=com; remaining name 'dc=global,dc=scd,dc=company,dc=com']
	at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreImpl(LdapNamingEnumeration.java:242) [rt.jar:1.7.0]
	at com.sun.jndi.ldap.LdapNamingEnumeration.hasMore(LdapNamingEnumeration.java:189) [rt.jar:1.7.0]
	at org.jboss.security.auth.spi.LdapExtLoginModule.rolesSearch(LdapExtLoginModule.java:534) [picketbox-4.0.7.Final.jar:4.0.7.Final]
	at org.jboss.security.auth.spi.LdapExtLoginModule.createLdapInitContext(LdapExtLoginModule.java:445) [picketbox-4.0.7.Final.jar:4.0.7.Final]
	at org.jboss.security.auth.spi.LdapExtLoginModule.validatePassword(LdapExtLoginModule.java:312) [picketbox-4.0.7.Final.jar:4.0.7.Final]
	at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:267) [picketbox-4.0.7.Final.jar:4.0.7.Final]
	... 29 more
Caused by: javax.naming.NotContextException: Cannot create context for: ldap://DomainDnsZones.global.scd.company.com/DC=DomainDnsZones,DC=global,DC=scd,DC=company,DC=com; remaining name 'dc=global,dc=scd,dc=company,dc=com'
	at com.sun.jndi.ldap.LdapReferralContext.<init>(LdapReferralContext.java:141) [rt.jar:1.7.0]
	at com.sun.jndi.ldap.LdapReferralException.getReferralContext(LdapReferralException.java:150) [rt.jar:1.7.0]
	at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreReferrals(LdapNamingEnumeration.java:357) [rt.jar:1.7.0]
	at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreImpl(LdapNamingEnumeration.java:226) [rt.jar:1.7.0]
	... 34 more
{code}

When debugging this error, I concluded that the culprit is that ObjectFactoryBuilder doesn't resolve the reference correctly. getObjectInstance returns the reference instead of resolving it at the following location:

{code}
at org.jboss.as.naming.context.ObjectFactoryBuilder.getObjectInstance(ObjectFactoryBuilder.java:87)
	  at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:300)
	  at com.sun.jndi.ldap.LdapReferralContext.<init>(LdapReferralContext.java:111)
	  at com.sun.jndi.ldap.LdapReferralException.getReferralContext(LdapReferralException.java:150)
	  at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreReferrals(LdapNamingEnumeration.java:357)
	  at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreImpl(LdapNamingEnumeration.java:226)
	  at com.sun.jndi.ldap.LdapNamingEnumeration.hasMore(LdapNamingEnumeration.java:189)
	  at org.jboss.security.auth.spi.LdapExtLoginModule.rolesSearch(LdapExtLoginModule.java:534)
	  at org.jboss.security.auth.spi.LdapExtLoginModule.createLdapInitContext(LdapExtLoginModule.java:445)
	  at org.jboss.security.auth.spi.LdapExtLoginModule.validatePassword(LdapExtLoginModule.java:312)
	  at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:267)
	  at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
	  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	  at java.lang.reflect.Method.invoke(Method.java:601)
	  at javax.security.auth.login.LoginContext.invoke(LoginContext.java:784)
	  at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203)
	  at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698)
	  at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696)
	  at java.security.AccessController.doPrivileged(AccessController.java:-1)
	  at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695)
	  at javax.security.auth.login.LoginContext.login(LoginContext.java:594)
	  at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:449)
	  at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:383)
	  at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:371)
	  at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:160)
	  at org.jboss.as.web.security.JBossWebRealm.authenticate(JBossWebRealm.java:214)
	  at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:280)
	  at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:381)
	  at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50)
	  at com.company.product.web.fix.ContextClassLoaderValve.invoke(ContextClassLoaderValve.java:19)
	  at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153)
	  at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)
	  at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
	  at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
	  at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368)
	  at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
	  at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671)
	  at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930)
	  at java.lang.Thread.run(Thread.java:722)
{code}

The relevant bit of code is:
{code}
 public Object getObjectInstance(final Object ref, final Name name, final Context nameCtx, final Hashtable<?, ?> environment) throws Exception {
        final ClassLoader classLoader = SecurityActions.getContextClassLoader();
        if(classLoader == null) {
            return ref;
        }
{code}

So this bit of code doesn't resolve the ref it the context classloader is null. Instead of aborting, it returns the ref unresolved. LdapReferralContext gets very confused when NamingManager doesn't resolve the reference, and throws the aforementioned NotContextException.

When debugging where the context classloader is set to null I found the following location:
{code}
http--127.0.0.1-8080-2 at 12911 daemon, prio=5, in group 'main', status: 'RUNNING'
	  at java.lang.Thread.setContextClassLoader(Thread.java:1480)
	  at org.jboss.security.auth.spi.SecurityActions$2.run(SecurityActions.java:59)
	  at org.jboss.security.auth.spi.SecurityActions$2.run(SecurityActions.java:56)
	  at java.security.AccessController.doPrivileged(AccessController.java:-1)
	  at org.jboss.security.auth.spi.SecurityActions.setContextClassLoader(SecurityActions.java:55)
	  at org.jboss.security.auth.spi.LdapExtLoginModule.createLdapInitContext(LdapExtLoginModule.java:435)
	  at org.jboss.security.auth.spi.LdapExtLoginModule.validatePassword(LdapExtLoginModule.java:312)
	  at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:267)
	  at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
	  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	  at java.lang.reflect.Method.invoke(Method.java:601)
	  at javax.security.auth.login.LoginContext.invoke(LoginContext.java:784)
	  at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203)
	  at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698)
	  at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696)
	  at java.security.AccessController.doPrivileged(AccessController.java:-1)
	  at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695)
	  at javax.security.auth.login.LoginContext.login(LoginContext.java:594)
	  at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:449)
	  at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:383)
	  at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:371)
	  at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:160)
	  at org.jboss.as.web.security.JBossWebRealm.authenticate(JBossWebRealm.java:214)
	  at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:280)
	  at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:381)
	  at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50)
	  at com.company.product.web.fix.ContextClassLoaderValve.invoke(ContextClassLoaderValve.java:19)
	  at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153)
	  at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)
	  at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
	  at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
	  at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368)
	  at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
	  at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671)
	  at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930)
	  at java.lang.Thread.run(Thread.java:722)
{code}

Unfortunately I haven't been able to find the source code for this location. But it is clear that LdapExtLoginModule does set the context classloader to null in validatePassword. I haven't come up with any way of avoiding this.

While trying to circumvent this bug I tried to avoid following the AD referral. This doesn't seem to be possible, though. When setting "java.naming.referral" to "ignore", you would expect that the login would succeed. But as documented at http://docs.oracle.com/javase/jndi/tutorial/ldap/referral/jndi.html , some LDAP implementations might still throw a PartialResultException. This is indeed what I get:

{code}
Caused by: javax.naming.PartialResultException: Unprocessed Continuation Reference(s); remaining name 'dc=global,dc=scd,dc=company,dc=com'
{code} 

Spring points this out at http://static.springsource.org/spring-ldap/site/apidocs/org/springframework/ldap/core/LdapTemplate.html and has a way of supressing these exceptions:  "ignorePartialResultException".

With JBoss lacking this, I am stuck between a rock and a hard place. I cannot enable referrals due to the null context class loader bug, and I cannot disable them due to the PartialResultException bug.

So I would call this one a blocker. Any suggestions are greatly appreciated, as we are stuck upgrading to AS 7. This is a regression, by the way, since "follow" used to work on AS 5.1.0.GA which we are upgrading from. 

The only way of avoiding this problem that I've found is to narrow the tree which you search through in AD in such a way that you avoid hitting the referrals at all. There are a couple of related bugs and forum posts (see for instance https://issues.jboss.org/browse/AS7-2085), but I don't think any of them really nailed the problem down. It's pretty tricky since you don't even get a relevant stacktrace unless you enable "throwValidateError".

Thanks

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 11:57:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 22 Oct 2013 11:57:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-754) LdapExtLoginModule fails
 with follow referral
In-Reply-To: <JIRA.12508493.1382456846000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508493.1382456846000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508493.1382456846000.11704.1382457422518@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse moved WFLY-2355 to SECURITY-754:
-------------------------------------------------

        Project: PicketBox   (was: WildFly)
            Key: SECURITY-754  (was: WFLY-2355)
       Workflow: classic default workflow  (was: GIT Pull Request workflow )
    Component/s: Negotiation
                     (was: Security)

    
>  LdapExtLoginModule fails with follow referral
> ----------------------------------------------
>
>                 Key: SECURITY-754
>                 URL: https://issues.jboss.org/browse/SECURITY-754
>             Project: PicketBox 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>         Environment: Probably not relevant, but Win 7 64, tried on jdk 6 and 7 64-bit.
>            Reporter: Darran Lofthouse
>            Assignee: Peter Skopek
>              Labels: activedirectory, authentication, authorization, ldap, objectfactory, references
>         Attachments: ldap-referral-test.zip, secured-webapp.war
>
>
> We connect to AD with LdapExtLoginModule. It so happens that AD keeps  references to some external trees (such as "DomainDnsZones" and "ForestDnsZones") in the root of the LDAP tree. So when you configure LdapExtLoginModule to search any root, it will hit these referrals.
> This normally fails with a standard 
> {code}
> javax.security.auth.login.FailedLoginException: Password Incorrect/Password Required
> {code}
> . This is not the whole story, though. If you enable the module option
> {code}<module-option name="throwValidateError" value="true"/>{code}
> , you get a more complete stack trace:
> {code}
> 09:18:14,724 ERROR [org.jboss.security.authentication.JBossCachedAuthenticationManager] (http--127.0.0.1-8080-2) Login failure: javax.security.auth.login.FailedLoginException: Password Incorrect/Password Required
> 	at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:270) [picketbox-4.0.7.Final.jar:4.0.7.Final]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0]
> 	at javax.security.auth.login.LoginContext.invoke(LoginContext.java:784) [rt.jar:1.7.0]
> 	at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203) [rt.jar:1.7.0]
> 	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698) [rt.jar:1.7.0]
> 	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696) [rt.jar:1.7.0]
> 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0]
> 	at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695) [rt.jar:1.7.0]
> 	at javax.security.auth.login.LoginContext.login(LoginContext.java:594) [rt.jar:1.7.0]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:449) [picketbox-infinispan-4.0.7.Final.jar:4.0.7.Final]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:383) [picketbox-infinispan-4.0.7.Final.jar:4.0.7.Final]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:371) [picketbox-infinispan-4.0.7.Final.jar:4.0.7.Final]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:160) [picketbox-infinispan-4.0.7.Final.jar:4.0.7.Final]
> 	at org.jboss.as.web.security.JBossWebRealm.authenticate(JBossWebRealm.java:214) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
> 	at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:280) [jbossweb-7.0.13.Final.jar:]
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:381) [jbossweb-7.0.13.Final.jar:]
> 	at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.1.1.Final.jar:7.1.1.Final]
> 	at com.company.product.web.fix.ContextClassLoaderValve.invoke(ContextClassLoaderValve.java:19) [classes:]
> 	at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.13.Final.jar:]
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.13.Final.jar:]
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.13.Final.jar:]
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.13.Final.jar:]
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.13.Final.jar:]
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671) [jbossweb-7.0.13.Final.jar:]
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930) [jbossweb-7.0.13.Final.jar:]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0]
> Caused by: javax.naming.PartialResultException [Root exception is javax.naming.NotContextException: Cannot create context for: ldap://DomainDnsZones.global.scd.company.com/DC=DomainDnsZones,DC=global,DC=scd,DC=company,DC=com; remaining name 'dc=global,dc=scd,dc=company,dc=com']
> 	at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreImpl(LdapNamingEnumeration.java:242) [rt.jar:1.7.0]
> 	at com.sun.jndi.ldap.LdapNamingEnumeration.hasMore(LdapNamingEnumeration.java:189) [rt.jar:1.7.0]
> 	at org.jboss.security.auth.spi.LdapExtLoginModule.rolesSearch(LdapExtLoginModule.java:534) [picketbox-4.0.7.Final.jar:4.0.7.Final]
> 	at org.jboss.security.auth.spi.LdapExtLoginModule.createLdapInitContext(LdapExtLoginModule.java:445) [picketbox-4.0.7.Final.jar:4.0.7.Final]
> 	at org.jboss.security.auth.spi.LdapExtLoginModule.validatePassword(LdapExtLoginModule.java:312) [picketbox-4.0.7.Final.jar:4.0.7.Final]
> 	at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:267) [picketbox-4.0.7.Final.jar:4.0.7.Final]
> 	... 29 more
> Caused by: javax.naming.NotContextException: Cannot create context for: ldap://DomainDnsZones.global.scd.company.com/DC=DomainDnsZones,DC=global,DC=scd,DC=company,DC=com; remaining name 'dc=global,dc=scd,dc=company,dc=com'
> 	at com.sun.jndi.ldap.LdapReferralContext.<init>(LdapReferralContext.java:141) [rt.jar:1.7.0]
> 	at com.sun.jndi.ldap.LdapReferralException.getReferralContext(LdapReferralException.java:150) [rt.jar:1.7.0]
> 	at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreReferrals(LdapNamingEnumeration.java:357) [rt.jar:1.7.0]
> 	at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreImpl(LdapNamingEnumeration.java:226) [rt.jar:1.7.0]
> 	... 34 more
> {code}
> When debugging this error, I concluded that the culprit is that ObjectFactoryBuilder doesn't resolve the reference correctly. getObjectInstance returns the reference instead of resolving it at the following location:
> {code}
> at org.jboss.as.naming.context.ObjectFactoryBuilder.getObjectInstance(ObjectFactoryBuilder.java:87)
> 	  at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:300)
> 	  at com.sun.jndi.ldap.LdapReferralContext.<init>(LdapReferralContext.java:111)
> 	  at com.sun.jndi.ldap.LdapReferralException.getReferralContext(LdapReferralException.java:150)
> 	  at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreReferrals(LdapNamingEnumeration.java:357)
> 	  at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreImpl(LdapNamingEnumeration.java:226)
> 	  at com.sun.jndi.ldap.LdapNamingEnumeration.hasMore(LdapNamingEnumeration.java:189)
> 	  at org.jboss.security.auth.spi.LdapExtLoginModule.rolesSearch(LdapExtLoginModule.java:534)
> 	  at org.jboss.security.auth.spi.LdapExtLoginModule.createLdapInitContext(LdapExtLoginModule.java:445)
> 	  at org.jboss.security.auth.spi.LdapExtLoginModule.validatePassword(LdapExtLoginModule.java:312)
> 	  at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:267)
> 	  at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
> 	  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	  at java.lang.reflect.Method.invoke(Method.java:601)
> 	  at javax.security.auth.login.LoginContext.invoke(LoginContext.java:784)
> 	  at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203)
> 	  at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698)
> 	  at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696)
> 	  at java.security.AccessController.doPrivileged(AccessController.java:-1)
> 	  at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695)
> 	  at javax.security.auth.login.LoginContext.login(LoginContext.java:594)
> 	  at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:449)
> 	  at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:383)
> 	  at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:371)
> 	  at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:160)
> 	  at org.jboss.as.web.security.JBossWebRealm.authenticate(JBossWebRealm.java:214)
> 	  at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:280)
> 	  at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:381)
> 	  at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50)
> 	  at com.company.product.web.fix.ContextClassLoaderValve.invoke(ContextClassLoaderValve.java:19)
> 	  at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153)
> 	  at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)
> 	  at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	  at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	  at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368)
> 	  at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
> 	  at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671)
> 	  at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930)
> 	  at java.lang.Thread.run(Thread.java:722)
> {code}
> The relevant bit of code is:
> {code}
>  public Object getObjectInstance(final Object ref, final Name name, final Context nameCtx, final Hashtable<?, ?> environment) throws Exception {
>         final ClassLoader classLoader = SecurityActions.getContextClassLoader();
>         if(classLoader == null) {
>             return ref;
>         }
> {code}
> So this bit of code doesn't resolve the ref it the context classloader is null. Instead of aborting, it returns the ref unresolved. LdapReferralContext gets very confused when NamingManager doesn't resolve the reference, and throws the aforementioned NotContextException.
> When debugging where the context classloader is set to null I found the following location:
> {code}
> http--127.0.0.1-8080-2 at 12911 daemon, prio=5, in group 'main', status: 'RUNNING'
> 	  at java.lang.Thread.setContextClassLoader(Thread.java:1480)
> 	  at org.jboss.security.auth.spi.SecurityActions$2.run(SecurityActions.java:59)
> 	  at org.jboss.security.auth.spi.SecurityActions$2.run(SecurityActions.java:56)
> 	  at java.security.AccessController.doPrivileged(AccessController.java:-1)
> 	  at org.jboss.security.auth.spi.SecurityActions.setContextClassLoader(SecurityActions.java:55)
> 	  at org.jboss.security.auth.spi.LdapExtLoginModule.createLdapInitContext(LdapExtLoginModule.java:435)
> 	  at org.jboss.security.auth.spi.LdapExtLoginModule.validatePassword(LdapExtLoginModule.java:312)
> 	  at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:267)
> 	  at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
> 	  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	  at java.lang.reflect.Method.invoke(Method.java:601)
> 	  at javax.security.auth.login.LoginContext.invoke(LoginContext.java:784)
> 	  at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203)
> 	  at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698)
> 	  at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696)
> 	  at java.security.AccessController.doPrivileged(AccessController.java:-1)
> 	  at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695)
> 	  at javax.security.auth.login.LoginContext.login(LoginContext.java:594)
> 	  at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:449)
> 	  at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:383)
> 	  at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:371)
> 	  at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:160)
> 	  at org.jboss.as.web.security.JBossWebRealm.authenticate(JBossWebRealm.java:214)
> 	  at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:280)
> 	  at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:381)
> 	  at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50)
> 	  at com.company.product.web.fix.ContextClassLoaderValve.invoke(ContextClassLoaderValve.java:19)
> 	  at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153)
> 	  at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)
> 	  at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	  at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	  at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368)
> 	  at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
> 	  at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671)
> 	  at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930)
> 	  at java.lang.Thread.run(Thread.java:722)
> {code}
> Unfortunately I haven't been able to find the source code for this location. But it is clear that LdapExtLoginModule does set the context classloader to null in validatePassword. I haven't come up with any way of avoiding this.
> While trying to circumvent this bug I tried to avoid following the AD referral. This doesn't seem to be possible, though. When setting "java.naming.referral" to "ignore", you would expect that the login would succeed. But as documented at http://docs.oracle.com/javase/jndi/tutorial/ldap/referral/jndi.html , some LDAP implementations might still throw a PartialResultException. This is indeed what I get:
> {code}
> Caused by: javax.naming.PartialResultException: Unprocessed Continuation Reference(s); remaining name 'dc=global,dc=scd,dc=company,dc=com'
> {code} 
> Spring points this out at http://static.springsource.org/spring-ldap/site/apidocs/org/springframework/ldap/core/LdapTemplate.html and has a way of supressing these exceptions:  "ignorePartialResultException".
> With JBoss lacking this, I am stuck between a rock and a hard place. I cannot enable referrals due to the null context class loader bug, and I cannot disable them due to the PartialResultException bug.
> So I would call this one a blocker. Any suggestions are greatly appreciated, as we are stuck upgrading to AS 7. This is a regression, by the way, since "follow" used to work on AS 5.1.0.GA which we are upgrading from. 
> The only way of avoiding this problem that I've found is to narrow the tree which you search through in AD in such a way that you avoid hitting the referrals at all. There are a couple of related bugs and forum posts (see for instance https://issues.jboss.org/browse/AS7-2085), but I don't think any of them really nailed the problem down. It's pretty tricky since you don't even get a relevant stacktrace unless you enable "throwValidateError".
> Thanks

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 11:57:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 22 Oct 2013 11:57:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-754) LdapExtLoginModule fails
 with follow referral
In-Reply-To: <JIRA.12508493.1382456846000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508493.1382456846000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508493.1382456846000.11708.1382457422718@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated SECURITY-754:
--------------------------------------

    Reporter: Peter Skopek  (was: Darran Lofthouse)

    
>  LdapExtLoginModule fails with follow referral
> ----------------------------------------------
>
>                 Key: SECURITY-754
>                 URL: https://issues.jboss.org/browse/SECURITY-754
>             Project: PicketBox 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>         Environment: Probably not relevant, but Win 7 64, tried on jdk 6 and 7 64-bit.
>            Reporter: Peter Skopek
>            Assignee: Peter Skopek
>              Labels: activedirectory, authentication, authorization, ldap, objectfactory, references
>         Attachments: ldap-referral-test.zip, secured-webapp.war
>
>
> We connect to AD with LdapExtLoginModule. It so happens that AD keeps  references to some external trees (such as "DomainDnsZones" and "ForestDnsZones") in the root of the LDAP tree. So when you configure LdapExtLoginModule to search any root, it will hit these referrals.
> This normally fails with a standard 
> {code}
> javax.security.auth.login.FailedLoginException: Password Incorrect/Password Required
> {code}
> . This is not the whole story, though. If you enable the module option
> {code}<module-option name="throwValidateError" value="true"/>{code}
> , you get a more complete stack trace:
> {code}
> 09:18:14,724 ERROR [org.jboss.security.authentication.JBossCachedAuthenticationManager] (http--127.0.0.1-8080-2) Login failure: javax.security.auth.login.FailedLoginException: Password Incorrect/Password Required
> 	at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:270) [picketbox-4.0.7.Final.jar:4.0.7.Final]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0]
> 	at javax.security.auth.login.LoginContext.invoke(LoginContext.java:784) [rt.jar:1.7.0]
> 	at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203) [rt.jar:1.7.0]
> 	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698) [rt.jar:1.7.0]
> 	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696) [rt.jar:1.7.0]
> 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0]
> 	at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695) [rt.jar:1.7.0]
> 	at javax.security.auth.login.LoginContext.login(LoginContext.java:594) [rt.jar:1.7.0]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:449) [picketbox-infinispan-4.0.7.Final.jar:4.0.7.Final]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:383) [picketbox-infinispan-4.0.7.Final.jar:4.0.7.Final]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:371) [picketbox-infinispan-4.0.7.Final.jar:4.0.7.Final]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:160) [picketbox-infinispan-4.0.7.Final.jar:4.0.7.Final]
> 	at org.jboss.as.web.security.JBossWebRealm.authenticate(JBossWebRealm.java:214) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
> 	at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:280) [jbossweb-7.0.13.Final.jar:]
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:381) [jbossweb-7.0.13.Final.jar:]
> 	at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.1.1.Final.jar:7.1.1.Final]
> 	at com.company.product.web.fix.ContextClassLoaderValve.invoke(ContextClassLoaderValve.java:19) [classes:]
> 	at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.13.Final.jar:]
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.13.Final.jar:]
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.13.Final.jar:]
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.13.Final.jar:]
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.13.Final.jar:]
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671) [jbossweb-7.0.13.Final.jar:]
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930) [jbossweb-7.0.13.Final.jar:]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0]
> Caused by: javax.naming.PartialResultException [Root exception is javax.naming.NotContextException: Cannot create context for: ldap://DomainDnsZones.global.scd.company.com/DC=DomainDnsZones,DC=global,DC=scd,DC=company,DC=com; remaining name 'dc=global,dc=scd,dc=company,dc=com']
> 	at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreImpl(LdapNamingEnumeration.java:242) [rt.jar:1.7.0]
> 	at com.sun.jndi.ldap.LdapNamingEnumeration.hasMore(LdapNamingEnumeration.java:189) [rt.jar:1.7.0]
> 	at org.jboss.security.auth.spi.LdapExtLoginModule.rolesSearch(LdapExtLoginModule.java:534) [picketbox-4.0.7.Final.jar:4.0.7.Final]
> 	at org.jboss.security.auth.spi.LdapExtLoginModule.createLdapInitContext(LdapExtLoginModule.java:445) [picketbox-4.0.7.Final.jar:4.0.7.Final]
> 	at org.jboss.security.auth.spi.LdapExtLoginModule.validatePassword(LdapExtLoginModule.java:312) [picketbox-4.0.7.Final.jar:4.0.7.Final]
> 	at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:267) [picketbox-4.0.7.Final.jar:4.0.7.Final]
> 	... 29 more
> Caused by: javax.naming.NotContextException: Cannot create context for: ldap://DomainDnsZones.global.scd.company.com/DC=DomainDnsZones,DC=global,DC=scd,DC=company,DC=com; remaining name 'dc=global,dc=scd,dc=company,dc=com'
> 	at com.sun.jndi.ldap.LdapReferralContext.<init>(LdapReferralContext.java:141) [rt.jar:1.7.0]
> 	at com.sun.jndi.ldap.LdapReferralException.getReferralContext(LdapReferralException.java:150) [rt.jar:1.7.0]
> 	at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreReferrals(LdapNamingEnumeration.java:357) [rt.jar:1.7.0]
> 	at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreImpl(LdapNamingEnumeration.java:226) [rt.jar:1.7.0]
> 	... 34 more
> {code}
> When debugging this error, I concluded that the culprit is that ObjectFactoryBuilder doesn't resolve the reference correctly. getObjectInstance returns the reference instead of resolving it at the following location:
> {code}
> at org.jboss.as.naming.context.ObjectFactoryBuilder.getObjectInstance(ObjectFactoryBuilder.java:87)
> 	  at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:300)
> 	  at com.sun.jndi.ldap.LdapReferralContext.<init>(LdapReferralContext.java:111)
> 	  at com.sun.jndi.ldap.LdapReferralException.getReferralContext(LdapReferralException.java:150)
> 	  at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreReferrals(LdapNamingEnumeration.java:357)
> 	  at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreImpl(LdapNamingEnumeration.java:226)
> 	  at com.sun.jndi.ldap.LdapNamingEnumeration.hasMore(LdapNamingEnumeration.java:189)
> 	  at org.jboss.security.auth.spi.LdapExtLoginModule.rolesSearch(LdapExtLoginModule.java:534)
> 	  at org.jboss.security.auth.spi.LdapExtLoginModule.createLdapInitContext(LdapExtLoginModule.java:445)
> 	  at org.jboss.security.auth.spi.LdapExtLoginModule.validatePassword(LdapExtLoginModule.java:312)
> 	  at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:267)
> 	  at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
> 	  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	  at java.lang.reflect.Method.invoke(Method.java:601)
> 	  at javax.security.auth.login.LoginContext.invoke(LoginContext.java:784)
> 	  at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203)
> 	  at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698)
> 	  at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696)
> 	  at java.security.AccessController.doPrivileged(AccessController.java:-1)
> 	  at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695)
> 	  at javax.security.auth.login.LoginContext.login(LoginContext.java:594)
> 	  at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:449)
> 	  at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:383)
> 	  at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:371)
> 	  at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:160)
> 	  at org.jboss.as.web.security.JBossWebRealm.authenticate(JBossWebRealm.java:214)
> 	  at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:280)
> 	  at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:381)
> 	  at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50)
> 	  at com.company.product.web.fix.ContextClassLoaderValve.invoke(ContextClassLoaderValve.java:19)
> 	  at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153)
> 	  at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)
> 	  at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	  at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	  at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368)
> 	  at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
> 	  at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671)
> 	  at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930)
> 	  at java.lang.Thread.run(Thread.java:722)
> {code}
> The relevant bit of code is:
> {code}
>  public Object getObjectInstance(final Object ref, final Name name, final Context nameCtx, final Hashtable<?, ?> environment) throws Exception {
>         final ClassLoader classLoader = SecurityActions.getContextClassLoader();
>         if(classLoader == null) {
>             return ref;
>         }
> {code}
> So this bit of code doesn't resolve the ref it the context classloader is null. Instead of aborting, it returns the ref unresolved. LdapReferralContext gets very confused when NamingManager doesn't resolve the reference, and throws the aforementioned NotContextException.
> When debugging where the context classloader is set to null I found the following location:
> {code}
> http--127.0.0.1-8080-2 at 12911 daemon, prio=5, in group 'main', status: 'RUNNING'
> 	  at java.lang.Thread.setContextClassLoader(Thread.java:1480)
> 	  at org.jboss.security.auth.spi.SecurityActions$2.run(SecurityActions.java:59)
> 	  at org.jboss.security.auth.spi.SecurityActions$2.run(SecurityActions.java:56)
> 	  at java.security.AccessController.doPrivileged(AccessController.java:-1)
> 	  at org.jboss.security.auth.spi.SecurityActions.setContextClassLoader(SecurityActions.java:55)
> 	  at org.jboss.security.auth.spi.LdapExtLoginModule.createLdapInitContext(LdapExtLoginModule.java:435)
> 	  at org.jboss.security.auth.spi.LdapExtLoginModule.validatePassword(LdapExtLoginModule.java:312)
> 	  at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:267)
> 	  at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
> 	  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	  at java.lang.reflect.Method.invoke(Method.java:601)
> 	  at javax.security.auth.login.LoginContext.invoke(LoginContext.java:784)
> 	  at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203)
> 	  at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698)
> 	  at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696)
> 	  at java.security.AccessController.doPrivileged(AccessController.java:-1)
> 	  at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695)
> 	  at javax.security.auth.login.LoginContext.login(LoginContext.java:594)
> 	  at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:449)
> 	  at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:383)
> 	  at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:371)
> 	  at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:160)
> 	  at org.jboss.as.web.security.JBossWebRealm.authenticate(JBossWebRealm.java:214)
> 	  at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:280)
> 	  at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:381)
> 	  at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50)
> 	  at com.company.product.web.fix.ContextClassLoaderValve.invoke(ContextClassLoaderValve.java:19)
> 	  at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153)
> 	  at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)
> 	  at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	  at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	  at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368)
> 	  at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
> 	  at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671)
> 	  at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930)
> 	  at java.lang.Thread.run(Thread.java:722)
> {code}
> Unfortunately I haven't been able to find the source code for this location. But it is clear that LdapExtLoginModule does set the context classloader to null in validatePassword. I haven't come up with any way of avoiding this.
> While trying to circumvent this bug I tried to avoid following the AD referral. This doesn't seem to be possible, though. When setting "java.naming.referral" to "ignore", you would expect that the login would succeed. But as documented at http://docs.oracle.com/javase/jndi/tutorial/ldap/referral/jndi.html , some LDAP implementations might still throw a PartialResultException. This is indeed what I get:
> {code}
> Caused by: javax.naming.PartialResultException: Unprocessed Continuation Reference(s); remaining name 'dc=global,dc=scd,dc=company,dc=com'
> {code} 
> Spring points this out at http://static.springsource.org/spring-ldap/site/apidocs/org/springframework/ldap/core/LdapTemplate.html and has a way of supressing these exceptions:  "ignorePartialResultException".
> With JBoss lacking this, I am stuck between a rock and a hard place. I cannot enable referrals due to the null context class loader bug, and I cannot disable them due to the PartialResultException bug.
> So I would call this one a blocker. Any suggestions are greatly appreciated, as we are stuck upgrading to AS 7. This is a regression, by the way, since "follow" used to work on AS 5.1.0.GA which we are upgrading from. 
> The only way of avoiding this problem that I've found is to narrow the tree which you search through in AD in such a way that you avoid hitting the referrals at all. There are a couple of related bugs and forum posts (see for instance https://issues.jboss.org/browse/AS7-2085), but I don't think any of them really nailed the problem down. It's pretty tricky since you don't even get a relevant stacktrace unless you enable "throwValidateError".
> Thanks

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 11:57:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 22 Oct 2013 11:57:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-754) LdapExtLoginModule fails
 with follow referral
In-Reply-To: <JIRA.12508493.1382456846000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508493.1382456846000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508493.1382456846000.11711.1382457422928@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated SECURITY-754:
--------------------------------------

    Fix Version/s: Negotiation_2_2_4

    
>  LdapExtLoginModule fails with follow referral
> ----------------------------------------------
>
>                 Key: SECURITY-754
>                 URL: https://issues.jboss.org/browse/SECURITY-754
>             Project: PicketBox 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>         Environment: Probably not relevant, but Win 7 64, tried on jdk 6 and 7 64-bit.
>            Reporter: Peter Skopek
>            Assignee: Peter Skopek
>              Labels: activedirectory, authentication, authorization, ldap, objectfactory, references
>             Fix For: Negotiation_2_2_4
>
>         Attachments: ldap-referral-test.zip, secured-webapp.war
>
>
> We connect to AD with LdapExtLoginModule. It so happens that AD keeps  references to some external trees (such as "DomainDnsZones" and "ForestDnsZones") in the root of the LDAP tree. So when you configure LdapExtLoginModule to search any root, it will hit these referrals.
> This normally fails with a standard 
> {code}
> javax.security.auth.login.FailedLoginException: Password Incorrect/Password Required
> {code}
> . This is not the whole story, though. If you enable the module option
> {code}<module-option name="throwValidateError" value="true"/>{code}
> , you get a more complete stack trace:
> {code}
> 09:18:14,724 ERROR [org.jboss.security.authentication.JBossCachedAuthenticationManager] (http--127.0.0.1-8080-2) Login failure: javax.security.auth.login.FailedLoginException: Password Incorrect/Password Required
> 	at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:270) [picketbox-4.0.7.Final.jar:4.0.7.Final]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0]
> 	at javax.security.auth.login.LoginContext.invoke(LoginContext.java:784) [rt.jar:1.7.0]
> 	at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203) [rt.jar:1.7.0]
> 	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698) [rt.jar:1.7.0]
> 	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696) [rt.jar:1.7.0]
> 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0]
> 	at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695) [rt.jar:1.7.0]
> 	at javax.security.auth.login.LoginContext.login(LoginContext.java:594) [rt.jar:1.7.0]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:449) [picketbox-infinispan-4.0.7.Final.jar:4.0.7.Final]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:383) [picketbox-infinispan-4.0.7.Final.jar:4.0.7.Final]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:371) [picketbox-infinispan-4.0.7.Final.jar:4.0.7.Final]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:160) [picketbox-infinispan-4.0.7.Final.jar:4.0.7.Final]
> 	at org.jboss.as.web.security.JBossWebRealm.authenticate(JBossWebRealm.java:214) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
> 	at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:280) [jbossweb-7.0.13.Final.jar:]
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:381) [jbossweb-7.0.13.Final.jar:]
> 	at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.1.1.Final.jar:7.1.1.Final]
> 	at com.company.product.web.fix.ContextClassLoaderValve.invoke(ContextClassLoaderValve.java:19) [classes:]
> 	at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.13.Final.jar:]
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.13.Final.jar:]
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.13.Final.jar:]
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.13.Final.jar:]
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.13.Final.jar:]
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671) [jbossweb-7.0.13.Final.jar:]
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930) [jbossweb-7.0.13.Final.jar:]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0]
> Caused by: javax.naming.PartialResultException [Root exception is javax.naming.NotContextException: Cannot create context for: ldap://DomainDnsZones.global.scd.company.com/DC=DomainDnsZones,DC=global,DC=scd,DC=company,DC=com; remaining name 'dc=global,dc=scd,dc=company,dc=com']
> 	at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreImpl(LdapNamingEnumeration.java:242) [rt.jar:1.7.0]
> 	at com.sun.jndi.ldap.LdapNamingEnumeration.hasMore(LdapNamingEnumeration.java:189) [rt.jar:1.7.0]
> 	at org.jboss.security.auth.spi.LdapExtLoginModule.rolesSearch(LdapExtLoginModule.java:534) [picketbox-4.0.7.Final.jar:4.0.7.Final]
> 	at org.jboss.security.auth.spi.LdapExtLoginModule.createLdapInitContext(LdapExtLoginModule.java:445) [picketbox-4.0.7.Final.jar:4.0.7.Final]
> 	at org.jboss.security.auth.spi.LdapExtLoginModule.validatePassword(LdapExtLoginModule.java:312) [picketbox-4.0.7.Final.jar:4.0.7.Final]
> 	at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:267) [picketbox-4.0.7.Final.jar:4.0.7.Final]
> 	... 29 more
> Caused by: javax.naming.NotContextException: Cannot create context for: ldap://DomainDnsZones.global.scd.company.com/DC=DomainDnsZones,DC=global,DC=scd,DC=company,DC=com; remaining name 'dc=global,dc=scd,dc=company,dc=com'
> 	at com.sun.jndi.ldap.LdapReferralContext.<init>(LdapReferralContext.java:141) [rt.jar:1.7.0]
> 	at com.sun.jndi.ldap.LdapReferralException.getReferralContext(LdapReferralException.java:150) [rt.jar:1.7.0]
> 	at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreReferrals(LdapNamingEnumeration.java:357) [rt.jar:1.7.0]
> 	at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreImpl(LdapNamingEnumeration.java:226) [rt.jar:1.7.0]
> 	... 34 more
> {code}
> When debugging this error, I concluded that the culprit is that ObjectFactoryBuilder doesn't resolve the reference correctly. getObjectInstance returns the reference instead of resolving it at the following location:
> {code}
> at org.jboss.as.naming.context.ObjectFactoryBuilder.getObjectInstance(ObjectFactoryBuilder.java:87)
> 	  at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:300)
> 	  at com.sun.jndi.ldap.LdapReferralContext.<init>(LdapReferralContext.java:111)
> 	  at com.sun.jndi.ldap.LdapReferralException.getReferralContext(LdapReferralException.java:150)
> 	  at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreReferrals(LdapNamingEnumeration.java:357)
> 	  at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreImpl(LdapNamingEnumeration.java:226)
> 	  at com.sun.jndi.ldap.LdapNamingEnumeration.hasMore(LdapNamingEnumeration.java:189)
> 	  at org.jboss.security.auth.spi.LdapExtLoginModule.rolesSearch(LdapExtLoginModule.java:534)
> 	  at org.jboss.security.auth.spi.LdapExtLoginModule.createLdapInitContext(LdapExtLoginModule.java:445)
> 	  at org.jboss.security.auth.spi.LdapExtLoginModule.validatePassword(LdapExtLoginModule.java:312)
> 	  at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:267)
> 	  at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
> 	  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	  at java.lang.reflect.Method.invoke(Method.java:601)
> 	  at javax.security.auth.login.LoginContext.invoke(LoginContext.java:784)
> 	  at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203)
> 	  at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698)
> 	  at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696)
> 	  at java.security.AccessController.doPrivileged(AccessController.java:-1)
> 	  at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695)
> 	  at javax.security.auth.login.LoginContext.login(LoginContext.java:594)
> 	  at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:449)
> 	  at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:383)
> 	  at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:371)
> 	  at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:160)
> 	  at org.jboss.as.web.security.JBossWebRealm.authenticate(JBossWebRealm.java:214)
> 	  at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:280)
> 	  at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:381)
> 	  at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50)
> 	  at com.company.product.web.fix.ContextClassLoaderValve.invoke(ContextClassLoaderValve.java:19)
> 	  at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153)
> 	  at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)
> 	  at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	  at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	  at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368)
> 	  at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
> 	  at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671)
> 	  at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930)
> 	  at java.lang.Thread.run(Thread.java:722)
> {code}
> The relevant bit of code is:
> {code}
>  public Object getObjectInstance(final Object ref, final Name name, final Context nameCtx, final Hashtable<?, ?> environment) throws Exception {
>         final ClassLoader classLoader = SecurityActions.getContextClassLoader();
>         if(classLoader == null) {
>             return ref;
>         }
> {code}
> So this bit of code doesn't resolve the ref it the context classloader is null. Instead of aborting, it returns the ref unresolved. LdapReferralContext gets very confused when NamingManager doesn't resolve the reference, and throws the aforementioned NotContextException.
> When debugging where the context classloader is set to null I found the following location:
> {code}
> http--127.0.0.1-8080-2 at 12911 daemon, prio=5, in group 'main', status: 'RUNNING'
> 	  at java.lang.Thread.setContextClassLoader(Thread.java:1480)
> 	  at org.jboss.security.auth.spi.SecurityActions$2.run(SecurityActions.java:59)
> 	  at org.jboss.security.auth.spi.SecurityActions$2.run(SecurityActions.java:56)
> 	  at java.security.AccessController.doPrivileged(AccessController.java:-1)
> 	  at org.jboss.security.auth.spi.SecurityActions.setContextClassLoader(SecurityActions.java:55)
> 	  at org.jboss.security.auth.spi.LdapExtLoginModule.createLdapInitContext(LdapExtLoginModule.java:435)
> 	  at org.jboss.security.auth.spi.LdapExtLoginModule.validatePassword(LdapExtLoginModule.java:312)
> 	  at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:267)
> 	  at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
> 	  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	  at java.lang.reflect.Method.invoke(Method.java:601)
> 	  at javax.security.auth.login.LoginContext.invoke(LoginContext.java:784)
> 	  at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203)
> 	  at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698)
> 	  at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696)
> 	  at java.security.AccessController.doPrivileged(AccessController.java:-1)
> 	  at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695)
> 	  at javax.security.auth.login.LoginContext.login(LoginContext.java:594)
> 	  at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:449)
> 	  at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:383)
> 	  at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:371)
> 	  at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:160)
> 	  at org.jboss.as.web.security.JBossWebRealm.authenticate(JBossWebRealm.java:214)
> 	  at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:280)
> 	  at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:381)
> 	  at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50)
> 	  at com.company.product.web.fix.ContextClassLoaderValve.invoke(ContextClassLoaderValve.java:19)
> 	  at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153)
> 	  at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)
> 	  at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	  at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	  at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368)
> 	  at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
> 	  at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671)
> 	  at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930)
> 	  at java.lang.Thread.run(Thread.java:722)
> {code}
> Unfortunately I haven't been able to find the source code for this location. But it is clear that LdapExtLoginModule does set the context classloader to null in validatePassword. I haven't come up with any way of avoiding this.
> While trying to circumvent this bug I tried to avoid following the AD referral. This doesn't seem to be possible, though. When setting "java.naming.referral" to "ignore", you would expect that the login would succeed. But as documented at http://docs.oracle.com/javase/jndi/tutorial/ldap/referral/jndi.html , some LDAP implementations might still throw a PartialResultException. This is indeed what I get:
> {code}
> Caused by: javax.naming.PartialResultException: Unprocessed Continuation Reference(s); remaining name 'dc=global,dc=scd,dc=company,dc=com'
> {code} 
> Spring points this out at http://static.springsource.org/spring-ldap/site/apidocs/org/springframework/ldap/core/LdapTemplate.html and has a way of supressing these exceptions:  "ignorePartialResultException".
> With JBoss lacking this, I am stuck between a rock and a hard place. I cannot enable referrals due to the null context class loader bug, and I cannot disable them due to the PartialResultException bug.
> So I would call this one a blocker. Any suggestions are greatly appreciated, as we are stuck upgrading to AS 7. This is a regression, by the way, since "follow" used to work on AS 5.1.0.GA which we are upgrading from. 
> The only way of avoiding this problem that I've found is to narrow the tree which you search through in AD in such a way that you avoid hitting the referrals at all. There are a couple of related bugs and forum posts (see for instance https://issues.jboss.org/browse/AS7-2085), but I don't think any of them really nailed the problem down. It's pretty tricky since you don't even get a relevant stacktrace unless you enable "throwValidateError".
> Thanks

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 11:57:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 22 Oct 2013 11:57:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-754) LdapExtLoginModule fails
 with follow referral
In-Reply-To: <JIRA.12508493.1382456846000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508493.1382456846000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508493.1382456846000.11714.1382457423097@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved SECURITY-754.
---------------------------------------

    Resolution: Done

    
>  LdapExtLoginModule fails with follow referral
> ----------------------------------------------
>
>                 Key: SECURITY-754
>                 URL: https://issues.jboss.org/browse/SECURITY-754
>             Project: PicketBox 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>         Environment: Probably not relevant, but Win 7 64, tried on jdk 6 and 7 64-bit.
>            Reporter: Peter Skopek
>            Assignee: Peter Skopek
>              Labels: activedirectory, authentication, authorization, ldap, objectfactory, references
>             Fix For: Negotiation_2_2_4
>
>         Attachments: ldap-referral-test.zip, secured-webapp.war
>
>
> We connect to AD with LdapExtLoginModule. It so happens that AD keeps  references to some external trees (such as "DomainDnsZones" and "ForestDnsZones") in the root of the LDAP tree. So when you configure LdapExtLoginModule to search any root, it will hit these referrals.
> This normally fails with a standard 
> {code}
> javax.security.auth.login.FailedLoginException: Password Incorrect/Password Required
> {code}
> . This is not the whole story, though. If you enable the module option
> {code}<module-option name="throwValidateError" value="true"/>{code}
> , you get a more complete stack trace:
> {code}
> 09:18:14,724 ERROR [org.jboss.security.authentication.JBossCachedAuthenticationManager] (http--127.0.0.1-8080-2) Login failure: javax.security.auth.login.FailedLoginException: Password Incorrect/Password Required
> 	at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:270) [picketbox-4.0.7.Final.jar:4.0.7.Final]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0]
> 	at javax.security.auth.login.LoginContext.invoke(LoginContext.java:784) [rt.jar:1.7.0]
> 	at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203) [rt.jar:1.7.0]
> 	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698) [rt.jar:1.7.0]
> 	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696) [rt.jar:1.7.0]
> 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0]
> 	at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695) [rt.jar:1.7.0]
> 	at javax.security.auth.login.LoginContext.login(LoginContext.java:594) [rt.jar:1.7.0]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:449) [picketbox-infinispan-4.0.7.Final.jar:4.0.7.Final]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:383) [picketbox-infinispan-4.0.7.Final.jar:4.0.7.Final]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:371) [picketbox-infinispan-4.0.7.Final.jar:4.0.7.Final]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:160) [picketbox-infinispan-4.0.7.Final.jar:4.0.7.Final]
> 	at org.jboss.as.web.security.JBossWebRealm.authenticate(JBossWebRealm.java:214) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
> 	at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:280) [jbossweb-7.0.13.Final.jar:]
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:381) [jbossweb-7.0.13.Final.jar:]
> 	at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.1.1.Final.jar:7.1.1.Final]
> 	at com.company.product.web.fix.ContextClassLoaderValve.invoke(ContextClassLoaderValve.java:19) [classes:]
> 	at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.13.Final.jar:]
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.13.Final.jar:]
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.13.Final.jar:]
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.13.Final.jar:]
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.13.Final.jar:]
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671) [jbossweb-7.0.13.Final.jar:]
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930) [jbossweb-7.0.13.Final.jar:]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0]
> Caused by: javax.naming.PartialResultException [Root exception is javax.naming.NotContextException: Cannot create context for: ldap://DomainDnsZones.global.scd.company.com/DC=DomainDnsZones,DC=global,DC=scd,DC=company,DC=com; remaining name 'dc=global,dc=scd,dc=company,dc=com']
> 	at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreImpl(LdapNamingEnumeration.java:242) [rt.jar:1.7.0]
> 	at com.sun.jndi.ldap.LdapNamingEnumeration.hasMore(LdapNamingEnumeration.java:189) [rt.jar:1.7.0]
> 	at org.jboss.security.auth.spi.LdapExtLoginModule.rolesSearch(LdapExtLoginModule.java:534) [picketbox-4.0.7.Final.jar:4.0.7.Final]
> 	at org.jboss.security.auth.spi.LdapExtLoginModule.createLdapInitContext(LdapExtLoginModule.java:445) [picketbox-4.0.7.Final.jar:4.0.7.Final]
> 	at org.jboss.security.auth.spi.LdapExtLoginModule.validatePassword(LdapExtLoginModule.java:312) [picketbox-4.0.7.Final.jar:4.0.7.Final]
> 	at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:267) [picketbox-4.0.7.Final.jar:4.0.7.Final]
> 	... 29 more
> Caused by: javax.naming.NotContextException: Cannot create context for: ldap://DomainDnsZones.global.scd.company.com/DC=DomainDnsZones,DC=global,DC=scd,DC=company,DC=com; remaining name 'dc=global,dc=scd,dc=company,dc=com'
> 	at com.sun.jndi.ldap.LdapReferralContext.<init>(LdapReferralContext.java:141) [rt.jar:1.7.0]
> 	at com.sun.jndi.ldap.LdapReferralException.getReferralContext(LdapReferralException.java:150) [rt.jar:1.7.0]
> 	at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreReferrals(LdapNamingEnumeration.java:357) [rt.jar:1.7.0]
> 	at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreImpl(LdapNamingEnumeration.java:226) [rt.jar:1.7.0]
> 	... 34 more
> {code}
> When debugging this error, I concluded that the culprit is that ObjectFactoryBuilder doesn't resolve the reference correctly. getObjectInstance returns the reference instead of resolving it at the following location:
> {code}
> at org.jboss.as.naming.context.ObjectFactoryBuilder.getObjectInstance(ObjectFactoryBuilder.java:87)
> 	  at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:300)
> 	  at com.sun.jndi.ldap.LdapReferralContext.<init>(LdapReferralContext.java:111)
> 	  at com.sun.jndi.ldap.LdapReferralException.getReferralContext(LdapReferralException.java:150)
> 	  at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreReferrals(LdapNamingEnumeration.java:357)
> 	  at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreImpl(LdapNamingEnumeration.java:226)
> 	  at com.sun.jndi.ldap.LdapNamingEnumeration.hasMore(LdapNamingEnumeration.java:189)
> 	  at org.jboss.security.auth.spi.LdapExtLoginModule.rolesSearch(LdapExtLoginModule.java:534)
> 	  at org.jboss.security.auth.spi.LdapExtLoginModule.createLdapInitContext(LdapExtLoginModule.java:445)
> 	  at org.jboss.security.auth.spi.LdapExtLoginModule.validatePassword(LdapExtLoginModule.java:312)
> 	  at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:267)
> 	  at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
> 	  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	  at java.lang.reflect.Method.invoke(Method.java:601)
> 	  at javax.security.auth.login.LoginContext.invoke(LoginContext.java:784)
> 	  at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203)
> 	  at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698)
> 	  at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696)
> 	  at java.security.AccessController.doPrivileged(AccessController.java:-1)
> 	  at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695)
> 	  at javax.security.auth.login.LoginContext.login(LoginContext.java:594)
> 	  at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:449)
> 	  at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:383)
> 	  at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:371)
> 	  at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:160)
> 	  at org.jboss.as.web.security.JBossWebRealm.authenticate(JBossWebRealm.java:214)
> 	  at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:280)
> 	  at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:381)
> 	  at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50)
> 	  at com.company.product.web.fix.ContextClassLoaderValve.invoke(ContextClassLoaderValve.java:19)
> 	  at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153)
> 	  at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)
> 	  at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	  at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	  at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368)
> 	  at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
> 	  at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671)
> 	  at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930)
> 	  at java.lang.Thread.run(Thread.java:722)
> {code}
> The relevant bit of code is:
> {code}
>  public Object getObjectInstance(final Object ref, final Name name, final Context nameCtx, final Hashtable<?, ?> environment) throws Exception {
>         final ClassLoader classLoader = SecurityActions.getContextClassLoader();
>         if(classLoader == null) {
>             return ref;
>         }
> {code}
> So this bit of code doesn't resolve the ref it the context classloader is null. Instead of aborting, it returns the ref unresolved. LdapReferralContext gets very confused when NamingManager doesn't resolve the reference, and throws the aforementioned NotContextException.
> When debugging where the context classloader is set to null I found the following location:
> {code}
> http--127.0.0.1-8080-2 at 12911 daemon, prio=5, in group 'main', status: 'RUNNING'
> 	  at java.lang.Thread.setContextClassLoader(Thread.java:1480)
> 	  at org.jboss.security.auth.spi.SecurityActions$2.run(SecurityActions.java:59)
> 	  at org.jboss.security.auth.spi.SecurityActions$2.run(SecurityActions.java:56)
> 	  at java.security.AccessController.doPrivileged(AccessController.java:-1)
> 	  at org.jboss.security.auth.spi.SecurityActions.setContextClassLoader(SecurityActions.java:55)
> 	  at org.jboss.security.auth.spi.LdapExtLoginModule.createLdapInitContext(LdapExtLoginModule.java:435)
> 	  at org.jboss.security.auth.spi.LdapExtLoginModule.validatePassword(LdapExtLoginModule.java:312)
> 	  at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:267)
> 	  at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
> 	  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	  at java.lang.reflect.Method.invoke(Method.java:601)
> 	  at javax.security.auth.login.LoginContext.invoke(LoginContext.java:784)
> 	  at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203)
> 	  at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698)
> 	  at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696)
> 	  at java.security.AccessController.doPrivileged(AccessController.java:-1)
> 	  at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695)
> 	  at javax.security.auth.login.LoginContext.login(LoginContext.java:594)
> 	  at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:449)
> 	  at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:383)
> 	  at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:371)
> 	  at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:160)
> 	  at org.jboss.as.web.security.JBossWebRealm.authenticate(JBossWebRealm.java:214)
> 	  at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:280)
> 	  at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:381)
> 	  at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50)
> 	  at com.company.product.web.fix.ContextClassLoaderValve.invoke(ContextClassLoaderValve.java:19)
> 	  at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153)
> 	  at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)
> 	  at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	  at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	  at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368)
> 	  at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
> 	  at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671)
> 	  at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930)
> 	  at java.lang.Thread.run(Thread.java:722)
> {code}
> Unfortunately I haven't been able to find the source code for this location. But it is clear that LdapExtLoginModule does set the context classloader to null in validatePassword. I haven't come up with any way of avoiding this.
> While trying to circumvent this bug I tried to avoid following the AD referral. This doesn't seem to be possible, though. When setting "java.naming.referral" to "ignore", you would expect that the login would succeed. But as documented at http://docs.oracle.com/javase/jndi/tutorial/ldap/referral/jndi.html , some LDAP implementations might still throw a PartialResultException. This is indeed what I get:
> {code}
> Caused by: javax.naming.PartialResultException: Unprocessed Continuation Reference(s); remaining name 'dc=global,dc=scd,dc=company,dc=com'
> {code} 
> Spring points this out at http://static.springsource.org/spring-ldap/site/apidocs/org/springframework/ldap/core/LdapTemplate.html and has a way of supressing these exceptions:  "ignorePartialResultException".
> With JBoss lacking this, I am stuck between a rock and a hard place. I cannot enable referrals due to the null context class loader bug, and I cannot disable them due to the PartialResultException bug.
> So I would call this one a blocker. Any suggestions are greatly appreciated, as we are stuck upgrading to AS 7. This is a regression, by the way, since "follow" used to work on AS 5.1.0.GA which we are upgrading from. 
> The only way of avoiding this problem that I've found is to narrow the tree which you search through in AD in such a way that you avoid hitting the referrals at all. There are a couple of related bugs and forum posts (see for instance https://issues.jboss.org/browse/AS7-2085), but I don't think any of them really nailed the problem down. It's pretty tricky since you don't even get a relevant stacktrace unless you enable "throwValidateError".
> Thanks

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 11:59:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 22 Oct 2013 11:59:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-755) Release JBoss Negotiation
	2.2.4
In-Reply-To: <JIRA.12508495.1382457463868@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508495.1382457463868@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508495.1382457463868.11719.1382457542014@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created SECURITY-755:
-----------------------------------------

             Summary: Release JBoss Negotiation 2.2.4
                 Key: SECURITY-755
                 URL: https://issues.jboss.org/browse/SECURITY-755
             Project: PicketBox 
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Negotiation
            Reporter: Peter Skopek
            Assignee: Peter Skopek
             Fix For: Negotiation_2_2_4




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 11:59:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 22 Oct 2013 11:59:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-755) Release JBoss Negotiation
	2.2.4
In-Reply-To: <JIRA.12508495.1382457463000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508495.1382457463000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508495.1382457463000.11723.1382457542221@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved SECURITY-755.
---------------------------------------

    Resolution: Done

    
> Release JBoss Negotiation 2.2.4
> -------------------------------
>
>                 Key: SECURITY-755
>                 URL: https://issues.jboss.org/browse/SECURITY-755
>             Project: PicketBox 
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>            Reporter: Peter Skopek
>            Assignee: Peter Skopek
>             Fix For: Negotiation_2_2_4
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 11:59:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 22 Oct 2013 11:59:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-717) Get JBoss Negotiation into
 Maven Central
In-Reply-To: <JIRA.12482052.1357571396000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12482052.1357571396000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12482052.1357571396000.11726.1382457542349@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated SECURITY-717:
--------------------------------------

    Fix Version/s: Negotiation_2_2_5
                       (was: Negotiation_2_2_4)

    
> Get JBoss Negotiation into Maven Central
> ----------------------------------------
>
>                 Key: SECURITY-717
>                 URL: https://issues.jboss.org/browse/SECURITY-717
>             Project: PicketBox 
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: Negotiation_2_2_5
>
>
> This will allow the JBoss Negotiation Toolkit to be removed from the project and instead moved to the quick starts making it much easier for end users to deploy and test.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 11:59:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 22 Oct 2013 11:59:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-677) Remove JBoss Negotiation
	Toolkit
In-Reply-To: <JIRA.12471347.1343413297000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12471347.1343413297000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12471347.1343413297000.11728.1382457542427@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated SECURITY-677:
--------------------------------------

    Fix Version/s: Negotiation_2_2_5
                       (was: Negotiation_2_2_4)

    
> Remove JBoss Negotiation Toolkit
> --------------------------------
>
>                 Key: SECURITY-677
>                 URL: https://issues.jboss.org/browse/SECURITY-677
>             Project: PicketBox 
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: Negotiation_2_2_5
>
>
> JBoss Negotiation Toolkit is being moved to the quickstarts, so it does not need to be maintained in two different locations delete it from the Negotiation source tree.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 12:01:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 22 Oct 2013 12:01:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-756) NPE introduced by
	SECURITY-754
In-Reply-To: <JIRA.12508496.1382457587695@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508496.1382457587695@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508496.1382457587695.11733.1382457662957@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created SECURITY-756:
-----------------------------------------

             Summary: NPE introduced by SECURITY-754
                 Key: SECURITY-756
                 URL: https://issues.jboss.org/browse/SECURITY-756
             Project: PicketBox 
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Negotiation
            Reporter: Peter Skopek
            Assignee: Peter Skopek




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 12:01:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 22 Oct 2013 12:01:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-757) Release JBoss Negotiation
	2.2.5
In-Reply-To: <JIRA.12508497.1382457652619@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508497.1382457652619@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508497.1382457652619.11743.1382457663502@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created SECURITY-757:
-----------------------------------------

             Summary: Release JBoss Negotiation 2.2.5
                 Key: SECURITY-757
                 URL: https://issues.jboss.org/browse/SECURITY-757
             Project: PicketBox 
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Negotiation
            Reporter: Peter Skopek
            Assignee: Peter Skopek




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 12:01:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 22 Oct 2013 12:01:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-756) NPE introduced by
	SECURITY-754
In-Reply-To: <JIRA.12508496.1382457587000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508496.1382457587000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508496.1382457587000.11737.1382457663193@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated SECURITY-756:
--------------------------------------

    Fix Version/s: Negotiation_2_2_5

    
> NPE introduced by SECURITY-754
> ------------------------------
>
>                 Key: SECURITY-756
>                 URL: https://issues.jboss.org/browse/SECURITY-756
>             Project: PicketBox 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>            Reporter: Peter Skopek
>            Assignee: Peter Skopek
>             Fix For: Negotiation_2_2_5
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 12:01:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 22 Oct 2013 12:01:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-756) NPE introduced by
	SECURITY-754
In-Reply-To: <JIRA.12508496.1382457587000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508496.1382457587000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508496.1382457587000.11741.1382457663403@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved SECURITY-756.
---------------------------------------

    Resolution: Done

    
> NPE introduced by SECURITY-754
> ------------------------------
>
>                 Key: SECURITY-756
>                 URL: https://issues.jboss.org/browse/SECURITY-756
>             Project: PicketBox 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>            Reporter: Peter Skopek
>            Assignee: Peter Skopek
>             Fix For: Negotiation_2_2_5
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 12:03:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 22 Oct 2013 12:03:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-757) Release JBoss Negotiation
	2.2.5
In-Reply-To: <JIRA.12508497.1382457652000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508497.1382457652000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508497.1382457652000.11747.1382457782076@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated SECURITY-757:
--------------------------------------

    Fix Version/s: Negotiation_2_2_5

    
> Release JBoss Negotiation 2.2.5
> -------------------------------
>
>                 Key: SECURITY-757
>                 URL: https://issues.jboss.org/browse/SECURITY-757
>             Project: PicketBox 
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>            Reporter: Peter Skopek
>            Assignee: Peter Skopek
>             Fix For: Negotiation_2_2_5
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 12:03:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 22 Oct 2013 12:03:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-757) Release JBoss Negotiation
	2.2.5
In-Reply-To: <JIRA.12508497.1382457652000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508497.1382457652000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508497.1382457652000.11750.1382457782186@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved SECURITY-757.
---------------------------------------

    Resolution: Done

    
> Release JBoss Negotiation 2.2.5
> -------------------------------
>
>                 Key: SECURITY-757
>                 URL: https://issues.jboss.org/browse/SECURITY-757
>             Project: PicketBox 
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>            Reporter: Peter Skopek
>            Assignee: Peter Skopek
>             Fix For: Negotiation_2_2_5
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 12:03:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 22 Oct 2013 12:03:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-717) Get JBoss Negotiation into
 Maven Central
In-Reply-To: <JIRA.12482052.1357571396000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12482052.1357571396000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12482052.1357571396000.11759.1382457782610@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated SECURITY-717:
--------------------------------------

    Fix Version/s: Negotiation_2_2_6
                       (was: Negotiation_2_2_5)

    
> Get JBoss Negotiation into Maven Central
> ----------------------------------------
>
>                 Key: SECURITY-717
>                 URL: https://issues.jboss.org/browse/SECURITY-717
>             Project: PicketBox 
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: Negotiation_2_2_6
>
>
> This will allow the JBoss Negotiation Toolkit to be removed from the project and instead moved to the quick starts making it much easier for end users to deploy and test.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 12:03:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 22 Oct 2013 12:03:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-677) Remove JBoss Negotiation
	Toolkit
In-Reply-To: <JIRA.12471347.1343413297000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12471347.1343413297000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12471347.1343413297000.11761.1382457782680@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated SECURITY-677:
--------------------------------------

    Fix Version/s: Negotiation_2_2_6
                       (was: Negotiation_2_2_5)

    
> Remove JBoss Negotiation Toolkit
> --------------------------------
>
>                 Key: SECURITY-677
>                 URL: https://issues.jboss.org/browse/SECURITY-677
>             Project: PicketBox 
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: Negotiation_2_2_6
>
>
> JBoss Negotiation Toolkit is being moved to the quickstarts, so it does not need to be maintained in two different locations delete it from the Negotiation source tree.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 12:15:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 22 Oct 2013 12:15:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2356) Upgrade to JBoss Negotiation
	2.2.6.Final
In-Reply-To: <JIRA.12508499.1382458494797@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508499.1382458494797@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508499.1382458494797.11801.1382458502799@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-2356:
--------------------------------------

             Summary: Upgrade to JBoss Negotiation 2.2.6.Final
                 Key: WFLY-2356
                 URL: https://issues.jboss.org/browse/WFLY-2356
             Project: WildFly
          Issue Type: Component  Upgrade
      Security Level: Public (Everyone can see)
          Components: Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 8.0.0.CR1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 12:23:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 22 Oct 2013 12:23:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-758) AdvancedLdapLoginModule
 doesn't isn't mapping nested roles
In-Reply-To: <JIRA.12508503.1382458902506@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508503.1382458902506@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508503.1382458902506.11837.1382458982259@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created SECURITY-758:
-----------------------------------------

             Summary: AdvancedLdapLoginModule doesn't isn't mapping nested roles
                 Key: SECURITY-758
                 URL: https://issues.jboss.org/browse/SECURITY-758
             Project: PicketBox 
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Negotiation
    Affects Versions: Negotiation_2_2_5
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: Negotiation_2_2_6


The recursive role searching is currently broken, believed to be caused by the introduction of quotes for a previous role searching fix.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 12:25:01 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 22 Oct 2013 12:25:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-305) ReleaseIdImpl implicitly
 required in KieBuilder implementation
In-Reply-To: <JIRA.12508397.1382386123000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508397.1382386123000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508397.1382386123000.11841.1382459101934@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-305:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> ReleaseIdImpl implicitly required in KieBuilder implementation
> --------------------------------------------------------------
>
>                 Key: DROOLS-305
>                 URL: https://issues.jboss.org/browse/DROOLS-305
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>         Environment: Fedora 19, JBoss EAP 6.1.1
>            Reporter: Adam Baxter
>            Assignee: Mario Fusco
>              Labels: classcastexception, jboss, kjar, releaseid, releaseidimpl
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> Drools implicitly requires ReleaseIdImpl in its implementation for loading a kjar. Any classes implementing ReleaseId will cause ClassCastExceptions during load:
> Caused by: java.lang.ClassCastException: org.jbpm.ee.support.KieReleaseId cannot be cast to org.drools.compiler.kproject.ReleaseIdImpl
> 	at org.drools.compiler.kie.builder.impl.KieBuilderImpl.getCompilationCachePath(KieBuilderImpl.java:289) [drools-compiler-6.0.0.CR4.jar:6.0.0.CR4]
> 	at org.drools.compiler.kie.builder.impl.AbstractKieModule.getCompilationCache(AbstractKieModule.java:300) [drools-compiler-6.0.0.CR4.jar:6.0.0.CR4]
> 	at org.drools.compiler.kie.builder.impl.AbstractKieModule.buildKnowledgePackages(AbstractKieModule.java:164) [drools-compiler-6.0.0.CR4.jar:6.0.0.CR4]
> 	at org.drools.compiler.kie.builder.impl.AbstractKieProject.verify(AbstractKieProject.java:39) [drools-compiler-6.0.0.CR4.jar:6.0.0.CR4]
> 	at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildKieProject(KieBuilderImpl.java:305) [drools-compiler-6.0.0.CR4.jar:6.0.0.CR4]
> 	at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildKieModule(KieBuilderImpl.java:300) [drools-compiler-6.0.0.CR4.jar:6.0.0.CR4]
> 	at org.kie.scanner.KieRepositoryScannerImpl.build(KieRepositoryScannerImpl.java:164) [kie-ci-6.0.0.CR4.jar:6.0.0.CR4]
> 	at org.kie.scanner.KieRepositoryScannerImpl.buildArtifact(KieRepositoryScannerImpl.java:119) [kie-ci-6.0.0.CR4.jar:6.0.0.CR4]
> 	at org.kie.scanner.KieRepositoryScannerImpl.loadArtifact(KieRepositoryScannerImpl.java:89) [kie-ci-6.0.0.CR4.jar:6.0.0.CR4]
> 	at org.kie.scanner.KieRepositoryScannerImpl.loadArtifact(KieRepositoryScannerImpl.java:82) [kie-ci-6.0.0.CR4.jar:6.0.0.CR4]
> 	at org.drools.compiler.kie.builder.impl.KieRepositoryImpl.loadKieModuleFromMavenRepo(KieRepositoryImpl.java:109) [drools-compiler-6.0.0.CR4.jar:6.0.0.CR4]
> 	at org.drools.compiler.kie.builder.impl.KieRepositoryImpl.getKieModule(KieRepositoryImpl.java:95) [drools-compiler-6.0.0.CR4.jar:6.0.0.CR4]
> 	at org.drools.compiler.kie.builder.impl.KieRepositoryImpl.getKieModule(KieRepositoryImpl.java:76) [drools-compiler-6.0.0.CR4.jar:6.0.0.CR4]
> 	at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:82) [drools-compiler-6.0.0.CR4.jar:6.0.0.CR4]
> 	at org.jbpm.ee.startup.KnowledgeManagerBean.getKieContainer(KnowledgeManagerBean.java:61) [test-jbpm-services.jar:]
> 	at org.jbpm.ee.startup.KnowledgeManagerBean.getKieBase(KnowledgeManagerBean.java:74) [test-jbpm-services.jar:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_25]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_25]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_25]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_25]
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72) [jboss-as-ee-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:58) [jboss-as-ee-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:374) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:129) [jboss-as-weld-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10]
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:137) [jboss-as-weld-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10]
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:58) [jboss-as-ee-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:58) [jboss-as-ee-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [jboss-as-ejb3-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:374) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
> 	at org.jboss.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:104) [jboss-as-ejb3-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:74) [jboss-as-weld-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53) [jboss-as-ee-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
> 	at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:52) [jboss-as-ejb3-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:226) [jboss-as-ejb3-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10]
> 	... 186 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 12:31:01 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 22 Oct 2013 12:31:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-305) ReleaseIdImpl implicitly
 required in KieBuilder implementation
In-Reply-To: <JIRA.12508397.1382386123000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508397.1382386123000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508397.1382386123000.11844.1382459461868@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-305.
--------------------------------

    Fix Version/s: 6.0.0.Final
       Resolution: Done


The ReleaseId interface is not intended to be reimplemented outside drools. I made the drools implementation (ReleaseIdImpl) Externalizable so it is no longer necessary to reimplement it.
                
> ReleaseIdImpl implicitly required in KieBuilder implementation
> --------------------------------------------------------------
>
>                 Key: DROOLS-305
>                 URL: https://issues.jboss.org/browse/DROOLS-305
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>         Environment: Fedora 19, JBoss EAP 6.1.1
>            Reporter: Adam Baxter
>            Assignee: Mario Fusco
>              Labels: classcastexception, jboss, kjar, releaseid, releaseidimpl
>             Fix For: 6.0.0.Final
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> Drools implicitly requires ReleaseIdImpl in its implementation for loading a kjar. Any classes implementing ReleaseId will cause ClassCastExceptions during load:
> Caused by: java.lang.ClassCastException: org.jbpm.ee.support.KieReleaseId cannot be cast to org.drools.compiler.kproject.ReleaseIdImpl
> 	at org.drools.compiler.kie.builder.impl.KieBuilderImpl.getCompilationCachePath(KieBuilderImpl.java:289) [drools-compiler-6.0.0.CR4.jar:6.0.0.CR4]
> 	at org.drools.compiler.kie.builder.impl.AbstractKieModule.getCompilationCache(AbstractKieModule.java:300) [drools-compiler-6.0.0.CR4.jar:6.0.0.CR4]
> 	at org.drools.compiler.kie.builder.impl.AbstractKieModule.buildKnowledgePackages(AbstractKieModule.java:164) [drools-compiler-6.0.0.CR4.jar:6.0.0.CR4]
> 	at org.drools.compiler.kie.builder.impl.AbstractKieProject.verify(AbstractKieProject.java:39) [drools-compiler-6.0.0.CR4.jar:6.0.0.CR4]
> 	at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildKieProject(KieBuilderImpl.java:305) [drools-compiler-6.0.0.CR4.jar:6.0.0.CR4]
> 	at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildKieModule(KieBuilderImpl.java:300) [drools-compiler-6.0.0.CR4.jar:6.0.0.CR4]
> 	at org.kie.scanner.KieRepositoryScannerImpl.build(KieRepositoryScannerImpl.java:164) [kie-ci-6.0.0.CR4.jar:6.0.0.CR4]
> 	at org.kie.scanner.KieRepositoryScannerImpl.buildArtifact(KieRepositoryScannerImpl.java:119) [kie-ci-6.0.0.CR4.jar:6.0.0.CR4]
> 	at org.kie.scanner.KieRepositoryScannerImpl.loadArtifact(KieRepositoryScannerImpl.java:89) [kie-ci-6.0.0.CR4.jar:6.0.0.CR4]
> 	at org.kie.scanner.KieRepositoryScannerImpl.loadArtifact(KieRepositoryScannerImpl.java:82) [kie-ci-6.0.0.CR4.jar:6.0.0.CR4]
> 	at org.drools.compiler.kie.builder.impl.KieRepositoryImpl.loadKieModuleFromMavenRepo(KieRepositoryImpl.java:109) [drools-compiler-6.0.0.CR4.jar:6.0.0.CR4]
> 	at org.drools.compiler.kie.builder.impl.KieRepositoryImpl.getKieModule(KieRepositoryImpl.java:95) [drools-compiler-6.0.0.CR4.jar:6.0.0.CR4]
> 	at org.drools.compiler.kie.builder.impl.KieRepositoryImpl.getKieModule(KieRepositoryImpl.java:76) [drools-compiler-6.0.0.CR4.jar:6.0.0.CR4]
> 	at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:82) [drools-compiler-6.0.0.CR4.jar:6.0.0.CR4]
> 	at org.jbpm.ee.startup.KnowledgeManagerBean.getKieContainer(KnowledgeManagerBean.java:61) [test-jbpm-services.jar:]
> 	at org.jbpm.ee.startup.KnowledgeManagerBean.getKieBase(KnowledgeManagerBean.java:74) [test-jbpm-services.jar:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_25]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_25]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_25]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_25]
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72) [jboss-as-ee-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:58) [jboss-as-ee-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:374) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:129) [jboss-as-weld-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10]
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:137) [jboss-as-weld-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10]
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:58) [jboss-as-ee-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:58) [jboss-as-ee-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [jboss-as-ejb3-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:374) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
> 	at org.jboss.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:104) [jboss-as-ejb3-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:74) [jboss-as-weld-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53) [jboss-as-ee-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
> 	at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:52) [jboss-as-ejb3-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:226) [jboss-as-ejb3-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10]
> 	... 186 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 12:39:01 2013
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Tue, 22 Oct 2013 12:39:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2357) OperationStepHandlers do not
 properly check if runtime steps should be added
In-Reply-To: <JIRA.12508504.1382459867214@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508504.1382459867214@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508504.1382459867214.11860.1382459941846@jira02.app.mwc.hst.phx2.redhat.com>

James Perkins created WFLY-2357:
-----------------------------------

             Summary: OperationStepHandlers do not properly check if runtime steps should be added
                 Key: WFLY-2357
                 URL: https://issues.jboss.org/browse/WFLY-2357
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Logging
            Reporter: James Perkins
            Assignee: James Perkins
            Priority: Minor
             Fix For: 8.0.0.CR1


Currently only checks if the process type is a server which would add runtime steps if booted in admin only mode. This should use the {{OperationContext.isNormalServer()}} instead.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 13:12:01 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Oct 2013 13:12:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2357) OperationStepHandlers do not
 properly check if runtime steps should be added
In-Reply-To: <JIRA.12508504.1382459867000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508504.1382459867000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508504.1382459867000.11900.1382461921950@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2357:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1021633

    
> OperationStepHandlers do not properly check if runtime steps should be added
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-2357
>                 URL: https://issues.jboss.org/browse/WFLY-2357
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Minor
>             Fix For: 8.0.0.CR1
>
>
> Currently only checks if the process type is a server which would add runtime steps if booted in admin only mode. This should use the {{OperationContext.isNormalServer()}} instead.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 13:25:01 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Oct 2013 13:25:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2357) OperationStepHandlers do not
 properly check if runtime steps should be added
In-Reply-To: <JIRA.12508504.1382459867000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508504.1382459867000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508504.1382459867000.11929.1382462701978@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824080#comment-12824080 ] 

RH Bugzilla Integration commented on WFLY-2357:
-----------------------------------------------

James Perkins <jperkins at redhat.com> changed the Status of [bug 1021633|https://bugzilla.redhat.com/show_bug.cgi?id=1021633] from NEW to POST
                
> OperationStepHandlers do not properly check if runtime steps should be added
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-2357
>                 URL: https://issues.jboss.org/browse/WFLY-2357
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Minor
>             Fix For: 8.0.0.CR1
>
>
> Currently only checks if the process type is a server which would add runtime steps if booted in admin only mode. This should use the {{OperationContext.isNormalServer()}} instead.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 13:38:01 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Oct 2013 13:38:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1470) Usage of finalize() needs
 extra guards on IBM JDK
In-Reply-To: <JIRA.12493807.1370596070000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493807.1370596070000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493807.1370596070000.11933.1382463481952@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824083#comment-12824083 ] 

RH Bugzilla Integration commented on WFLY-1470:
-----------------------------------------------

John Doyle <jdoyle at redhat.com> made a comment on [bug 901231|https://bugzilla.redhat.com/show_bug.cgi?id=901231]

We need a plan to close this BZ.

We have lists of the the occurrences of the finalize in methods in the EAP 6, can we make that list more accessible and enable people to work on the occurrences as time permits, and reduce the list that way?
                
> Usage of finalize() needs extra guards on IBM JDK
> -------------------------------------------------
>
>                 Key: WFLY-1470
>                 URL: https://issues.jboss.org/browse/WFLY-1470
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Carlo de Wolf
>            Priority: Critical
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 14:37:01 2013
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Tue, 22 Oct 2013 14:37:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-142) JACC permissions with HTTP
 method exception list are not correctly implemented
In-Reply-To: <JIRA.12501668.1380225289000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501668.1380225289000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501668.1380225289000.12060.1382467021970@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBEE-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824089#comment-12824089 ] 

Shelly McGowan commented on JBEE-142:
-------------------------------------

Fix committed to the jboss-jacc-api_spec_EE6_branch maintenance branch created for EE 6:
https://github.com/jboss/jboss-jacc-api_spec/commit/e3189a4869019f4940f2064f302b606779274aa3

JACC was reved to 1.5 with different dependencies for EE7, see:  JBEE-141.
                
>  JACC permissions with HTTP method exception list are not correctly implemented
> -------------------------------------------------------------------------------
>
>                 Key: JBEE-142
>                 URL: https://issues.jboss.org/browse/JBEE-142
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: jboss-jacc-api
>    Affects Versions: JavaEE 6 Spec APIs 3.0.2.Final
>            Reporter: Stefan Guilhen
>            Assignee: Stefan Guilhen
>             Fix For: JavaEE Spec APIs 3.0.3.Final
>
>
> As reported by Josef Cacek: JACC 1.1 permissions WebResourcePermission and WebUserDataPermission with an HTTP method exception list as actions should provide the correct list instead of null when calling getActions() method on them. Look at section "3.1.3.4 - Example" of the JACC 1.1 specification.
> There is also a second problem related - WebUserDataPermission.parseActions(String) method should remove the exclamation mark from the actions local variable before calling
> {code} 
> Object[] methodInfo = WebResourcePermission.canonicalMethods(actions);
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 14:50:01 2013
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Tue, 22 Oct 2013 14:50:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-142) JACC permissions with HTTP
 method exception list are not correctly implemented
In-Reply-To: <JIRA.12501668.1380225289000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501668.1380225289000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501668.1380225289000.12065.1382467801989@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBEE-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824091#comment-12824091 ] 

Shelly McGowan commented on JBEE-142:
-------------------------------------

https://repository.jboss.org/nexus/content/groups/public/org/jboss/spec/javax/security/jacc/jboss-jacc-api_1.4_spec/1.0.3.Final/
has been released inclusive of the above changes.
                
>  JACC permissions with HTTP method exception list are not correctly implemented
> -------------------------------------------------------------------------------
>
>                 Key: JBEE-142
>                 URL: https://issues.jboss.org/browse/JBEE-142
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: jboss-jacc-api
>    Affects Versions: JavaEE 6 Spec APIs 3.0.2.Final
>            Reporter: Stefan Guilhen
>            Assignee: Stefan Guilhen
>             Fix For: JavaEE Spec APIs 3.0.3.Final
>
>
> As reported by Josef Cacek: JACC 1.1 permissions WebResourcePermission and WebUserDataPermission with an HTTP method exception list as actions should provide the correct list instead of null when calling getActions() method on them. Look at section "3.1.3.4 - Example" of the JACC 1.1 specification.
> There is also a second problem related - WebUserDataPermission.parseActions(String) method should remove the exclamation mark from the actions local variable before calling
> {code} 
> Object[] methodInfo = WebResourcePermission.canonicalMethods(actions);
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 14:53:01 2013
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Tue, 22 Oct 2013 14:53:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-142) JACC permissions with HTTP
 method exception list are not correctly implemented
In-Reply-To: <JIRA.12501668.1380225289000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501668.1380225289000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501668.1380225289000.12068.1382467981945@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBEE-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBEE-142:
--------------------------------

    Fix Version/s: jboss-jacc-api_1.4_spec-1.0.3.Final

    
>  JACC permissions with HTTP method exception list are not correctly implemented
> -------------------------------------------------------------------------------
>
>                 Key: JBEE-142
>                 URL: https://issues.jboss.org/browse/JBEE-142
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: jboss-jacc-api
>    Affects Versions: JavaEE 6 Spec APIs 3.0.2.Final
>            Reporter: Stefan Guilhen
>            Assignee: Stefan Guilhen
>             Fix For: JavaEE Spec APIs 3.0.3.Final, jboss-jacc-api_1.4_spec-1.0.3.Final
>
>
> As reported by Josef Cacek: JACC 1.1 permissions WebResourcePermission and WebUserDataPermission with an HTTP method exception list as actions should provide the correct list instead of null when calling getActions() method on them. Look at section "3.1.3.4 - Example" of the JACC 1.1 specification.
> There is also a second problem related - WebUserDataPermission.parseActions(String) method should remove the exclamation mark from the actions local variable before calling
> {code} 
> Object[] methodInfo = WebResourcePermission.canonicalMethods(actions);
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 15:54:01 2013
From: jira-events at lists.jboss.org (Derek Horton (JIRA))
Date: Tue, 22 Oct 2013 15:54:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2358) setting
 <jacc-star-role-allow> in jboss-web.xml does not set allRolesMode to
 "authOnly"
In-Reply-To: <JIRA.12508518.1382471609436@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508518.1382471609436@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508518.1382471609436.12102.1382471641977@jira02.app.mwc.hst.phx2.redhat.com>

Derek Horton created WFLY-2358:
----------------------------------

             Summary:  setting <jacc-star-role-allow> in jboss-web.xml does not set allRolesMode to "authOnly"
                 Key: WFLY-2358
                 URL: https://issues.jboss.org/browse/WFLY-2358
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Web (JBoss Web)
    Affects Versions: 8.0.0.Beta1
            Reporter: Derek Horton
            Assignee: Remy Maucherat


I am trying to get only authentication (no authorization) to work for web application.

In EAP 5, all that was required was to set the <role-name> to a '*' in
the <security-constraint> of the web.xml.  I tried this in EAP 6,
however, it did not work.

I then found the <jacc-star-role-allow> setting that goes in the
jboss-web.xml.  Unfortunately, adding this option did not cause the
wildcard ('*') role-name to work for allowing any authenticated user 
to access the web application.

Using the following system property does appear to work:
org.apache.catalina.realm.RealmBase.ALL_ROLES_MODE=authOnly

How reproducible:
Everytime.


Steps to Reproduce:
1.  Set <role-name>*</role-name> in the security-contraint
2.  Set <jacc-star-role-allow>true</jacc-star-role-allow> in jboss-web.xml
3.  Set the security-domain so that no roles are assigned to a user
4.  Attempt to access the web app

Actual results:
403 - access denied

Expected results:
200 - access allowed

Additional info:

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 15:56:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Oct 2013 15:56:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2358) setting
 <jacc-star-role-allow> in jboss-web.xml does not set allRolesMode to
 "authOnly"
In-Reply-To: <JIRA.12508518.1382471609000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508518.1382471609000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508518.1382471609000.12109.1382471762193@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2358:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1022240

    
>  setting <jacc-star-role-allow> in jboss-web.xml does not set allRolesMode to "authOnly"
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-2358
>                 URL: https://issues.jboss.org/browse/WFLY-2358
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (JBoss Web)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Derek Horton
>            Assignee: Remy Maucherat
>
> I am trying to get only authentication (no authorization) to work for web application.
> In EAP 5, all that was required was to set the <role-name> to a '*' in
> the <security-constraint> of the web.xml.  I tried this in EAP 6,
> however, it did not work.
> I then found the <jacc-star-role-allow> setting that goes in the
> jboss-web.xml.  Unfortunately, adding this option did not cause the
> wildcard ('*') role-name to work for allowing any authenticated user 
> to access the web application.
> Using the following system property does appear to work:
> org.apache.catalina.realm.RealmBase.ALL_ROLES_MODE=authOnly
> How reproducible:
> Everytime.
> Steps to Reproduce:
> 1.  Set <role-name>*</role-name> in the security-contraint
> 2.  Set <jacc-star-role-allow>true</jacc-star-role-allow> in jboss-web.xml
> 3.  Set the security-domain so that no roles are assigned to a user
> 4.  Attempt to access the web app
> Actual results:
> 403 - access denied
> Expected results:
> 200 - access allowed
> Additional info:

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 16:20:02 2013
From: jira-events at lists.jboss.org (Stefan Guilhen (JIRA))
Date: Tue, 22 Oct 2013 16:20:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-142) JACC permissions with HTTP
 method exception list are not correctly implemented
In-Reply-To: <JIRA.12501668.1380225289000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501668.1380225289000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501668.1380225289000.12128.1382473202048@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBEE-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Guilhen closed JBEE-142.
-------------------------------

    Resolution: Done

    
>  JACC permissions with HTTP method exception list are not correctly implemented
> -------------------------------------------------------------------------------
>
>                 Key: JBEE-142
>                 URL: https://issues.jboss.org/browse/JBEE-142
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: jboss-jacc-api
>    Affects Versions: JavaEE 6 Spec APIs 3.0.2.Final
>            Reporter: Stefan Guilhen
>            Assignee: Stefan Guilhen
>             Fix For: JavaEE Spec APIs 3.0.3.Final, jboss-jacc-api_1.4_spec-1.0.3.Final
>
>
> As reported by Josef Cacek: JACC 1.1 permissions WebResourcePermission and WebUserDataPermission with an HTTP method exception list as actions should provide the correct list instead of null when calling getActions() method on them. Look at section "3.1.3.4 - Example" of the JACC 1.1 specification.
> There is also a second problem related - WebUserDataPermission.parseActions(String) method should remove the exclamation mark from the actions local variable before calling
> {code} 
> Object[] methodInfo = WebResourcePermission.canonicalMethods(actions);
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 17:03:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Oct 2013 17:03:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2021) EE Component interceptor
 chains should be stateless
In-Reply-To: <JIRA.12500214.1378475131000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500214.1378475131000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500214.1378475131000.12150.1382475782872@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2021:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1022265

    
> EE Component interceptor chains should be stateless
> ---------------------------------------------------
>
>                 Key: WFLY-2021
>                 URL: https://issues.jboss.org/browse/WFLY-2021
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: EE, EJB
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>
> This will allow them to be shared by all instances, rather than having a new chain allocated for each method.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 17:03:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Oct 2013 17:03:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2021) EE Component interceptor
 chains should be stateless
In-Reply-To: <JIRA.12500214.1378475131000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500214.1378475131000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500214.1378475131000.12153.1382475783003@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824104#comment-12824104 ] 

RH Bugzilla Integration commented on WFLY-2021:
-----------------------------------------------

Andrig T Miller <anmiller at redhat.com> made a comment on [bug 1022265|https://bugzilla.redhat.com/show_bug.cgi?id=1022265]

Description of problem:

https://issues.jboss.org/browse/WFLY-2021

Version-Release number of selected component (if applicable):

EAP 6.2

How reproducible:

N/A

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

This is a performance enhancement which shrinks the memory footprint for EJB applications, and should provide benefits in CPU consumption too, but mostly reduces the memory footprint.

The link in the description is the issue upstream, and this has already been merged.

We would like to put this into EAP 6.3.

Also, EJB is no longer a separate component, so this just needs to be back ported and merged into the core AS code base.
                
> EE Component interceptor chains should be stateless
> ---------------------------------------------------
>
>                 Key: WFLY-2021
>                 URL: https://issues.jboss.org/browse/WFLY-2021
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: EE, EJB
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>
> This will allow them to be shared by all instances, rather than having a new chain allocated for each method.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 17:03:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Oct 2013 17:03:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2021) EE Component interceptor
 chains should be stateless
In-Reply-To: <JIRA.12500214.1378475131000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500214.1378475131000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500214.1378475131000.12156.1382475783186@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824105#comment-12824105 ] 

RH Bugzilla Integration commented on WFLY-2021:
-----------------------------------------------

Andrig T Miller <anmiller at redhat.com> made a comment on [bug 1022265|https://bugzilla.redhat.com/show_bug.cgi?id=1022265]

Changed the type to enhancement, as this is a performance improvement, not a functional bug.
                
> EE Component interceptor chains should be stateless
> ---------------------------------------------------
>
>                 Key: WFLY-2021
>                 URL: https://issues.jboss.org/browse/WFLY-2021
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: EE, EJB
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>
> This will allow them to be shared by all instances, rather than having a new chain allocated for each method.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 19:04:02 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Tue, 22 Oct 2013 19:04:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-309) Multiple threads working
 with traits against same knowledge base hangs
In-Reply-To: <JIRA.12508490.1382455844000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508490.1382455844000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508490.1382455844000.12207.1382483042033@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Davide Sottara reassigned DROOLS-309:
-------------------------------------

    Assignee: Davide Sottara  (was: Mark Proctor)

    
> Multiple threads working with traits against same knowledge base hangs
> ----------------------------------------------------------------------
>
>                 Key: DROOLS-309
>                 URL: https://issues.jboss.org/browse/DROOLS-309
>             Project: Drools
>          Issue Type: Quality Risk
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: James Myers
>            Assignee: Davide Sottara
>
> In our web system, we are creating new StatefulKnowledgeSession per user session and executing a set of rules containing trait donning.  This starts to hang (seemingly indefinitely) with following type of stack trace (usually initiated from insert/update):
> {quote}
>    java.lang.Thread.State: RUNNABLE
> 	at org.drools.core.util.TripleStore.getAll(TripleStore.java:188)
> 	at org.drools.factmodel.traits.TripleBasedStruct.getTriplesForSubject(TripleBasedStruct.java:165)
> 	at org.drools.factmodel.traits.ThingorgdroolsfactmodeltraitsTraitSession$ItemWrapperProxyWrapper.hashCode(Unknown Source)
> 	at org.drools.factmodel.traits.TraitProxy.hashCode(TraitProxy.java:110)
> 	at org.drools.factmodel.traits.ThingorgdroolsfactmodeltraitsTraitSession$ItemWrapperProxy.hashCode(Unknown Source)
> 	at org.drools.common.DefaultFactHandle.<init>(DefaultFactHandle.java:110)
> 	at org.drools.common.DefaultFactHandle.<init>(DefaultFactHandle.java:98)
> 	at org.drools.common.TraitFactHandle.<init>(TraitFactHandle.java:26)
> 	at org.drools.reteoo.ReteooFactHandleFactory.newFactHandle(ReteooFactHandleFactory.java:80)
> 	at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:68)
> 	at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:53)
> 	at org.drools.common.NamedEntryPoint.createHandle(NamedEntryPoint.java:765)
> 	at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:301)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903)
> {quote}
> Here is a unit test for org.drools.factmodel.traits.TraitTest.  It's not perfect because it will spawn thread that might never die and may need thread/iteration count increased to fail consistently, but capturing a stack trace a few seconds in should show all threads in "getAll()":
> {code}
>     @Traitable
>     public static class Item {
>     	private String id;
>     	public String getId() {
>     		return id;
>     	}
>     	public void setId(String id) {
>     		this.id = id;
>     	}
>     }
>     public static class TraitRulesThread implements Runnable {
>     	int threadIndex;
>     	int numRepetitions;
>     	StatefulKnowledgeSession ksession;
>     	public TraitRulesThread(int threadIndex, int numRepetitions, final StatefulKnowledgeSession ksession) {
>     		this.threadIndex = threadIndex;
>     		this.numRepetitions = numRepetitions;
>     		this.ksession = ksession;
>     	}
>     	public void run() {
>     		for (int repetitionIndex = 0; repetitionIndex < numRepetitions; repetitionIndex++) {
>     			final Item i = new Item();
>     			i.setId(String.format("testId_%d%d", threadIndex, repetitionIndex));
>     			ksession.insert(i);
>     			ksession.fireAllRules();
>     		}
>     	}
>     }
>     @Test
>     public void testMultithreadingTraits() throws InterruptedException {
>     	final String s1 = "package test;\n" +
>     	"import org.drools.factmodel.traits.TraitTest.Item;\n" +
>     	"declare Item end\n" +
>     	"declare trait ItemStyle\n" +
>     	"	id: String\n" +
>     	"	adjustable: boolean\n" +
>     	"end\n" +
>     	"rule \"Don ItemStyle\"\n" +
>     	"	no-loop true\n" +
>     	"	when\n" +
>     	"		$p : Item ()\n" +
>     	"		not ItemStyle ( id == $p.id )\n" +
>     	"	then\n" +
>     	"		don($p, ItemStyle.class);\n" +
>     	"end\n" +
>     	"rule \"Item Style - Adjustable\"" +
>     	"	no-loop true" +
>     	"	when" +
>     	"		$style : ItemStyle ( !adjustable )" +
>     	"		Item (" +
>     	"			id == $style.id " +
>     	"		)" +
>     	"	then" +
>     	"		modify($style) {" +
>     	"			setAdjustable(true)" +
>     	"		};" +
>     	"end";
>     	final KnowledgeBase kbase = getKnowledgeBaseFromString(s1);
>     	// might need to tweak these numbers.  often works with 7-10,100,60, but often fails 15-20,100,60
>     	int MAX_THREADS = 20;
>     	int MAX_REPETITIONS = 100;
>     	int MAX_WAIT_SECONDS = 60;
>     	final ExecutorService executorService = Executors.newFixedThreadPool(MAX_THREADS);
>     	for (int threadIndex = 0; threadIndex < MAX_THREADS; threadIndex++) {
>     		executorService.execute(new TraitRulesThread(threadIndex, MAX_REPETITIONS, kbase.newStatefulKnowledgeSession()));
>     	}
>     	executorService.shutdown();
>     	executorService.awaitTermination(MAX_WAIT_SECONDS, TimeUnit.SECONDS);
>     	final List<Runnable> queuedTasks = executorService.shutdownNow();
>     	assertEquals(0, queuedTasks.size());
>     	assertEquals(true, executorService.isTerminated());
>     }
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 19:04:02 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Tue, 22 Oct 2013 19:04:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-309) Multiple threads working
 with traits against same knowledge base hangs
In-Reply-To: <JIRA.12508490.1382455844000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508490.1382455844000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508490.1382455844000.12209.1382483042183@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824112#comment-12824112 ] 

Davide Sottara commented on DROOLS-309:
---------------------------------------

Thanks for reporting this, I'll check it out.
                
> Multiple threads working with traits against same knowledge base hangs
> ----------------------------------------------------------------------
>
>                 Key: DROOLS-309
>                 URL: https://issues.jboss.org/browse/DROOLS-309
>             Project: Drools
>          Issue Type: Quality Risk
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: James Myers
>            Assignee: Davide Sottara
>
> In our web system, we are creating new StatefulKnowledgeSession per user session and executing a set of rules containing trait donning.  This starts to hang (seemingly indefinitely) with following type of stack trace (usually initiated from insert/update):
> {quote}
>    java.lang.Thread.State: RUNNABLE
> 	at org.drools.core.util.TripleStore.getAll(TripleStore.java:188)
> 	at org.drools.factmodel.traits.TripleBasedStruct.getTriplesForSubject(TripleBasedStruct.java:165)
> 	at org.drools.factmodel.traits.ThingorgdroolsfactmodeltraitsTraitSession$ItemWrapperProxyWrapper.hashCode(Unknown Source)
> 	at org.drools.factmodel.traits.TraitProxy.hashCode(TraitProxy.java:110)
> 	at org.drools.factmodel.traits.ThingorgdroolsfactmodeltraitsTraitSession$ItemWrapperProxy.hashCode(Unknown Source)
> 	at org.drools.common.DefaultFactHandle.<init>(DefaultFactHandle.java:110)
> 	at org.drools.common.DefaultFactHandle.<init>(DefaultFactHandle.java:98)
> 	at org.drools.common.TraitFactHandle.<init>(TraitFactHandle.java:26)
> 	at org.drools.reteoo.ReteooFactHandleFactory.newFactHandle(ReteooFactHandleFactory.java:80)
> 	at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:68)
> 	at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:53)
> 	at org.drools.common.NamedEntryPoint.createHandle(NamedEntryPoint.java:765)
> 	at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:301)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903)
> {quote}
> Here is a unit test for org.drools.factmodel.traits.TraitTest.  It's not perfect because it will spawn thread that might never die and may need thread/iteration count increased to fail consistently, but capturing a stack trace a few seconds in should show all threads in "getAll()":
> {code}
>     @Traitable
>     public static class Item {
>     	private String id;
>     	public String getId() {
>     		return id;
>     	}
>     	public void setId(String id) {
>     		this.id = id;
>     	}
>     }
>     public static class TraitRulesThread implements Runnable {
>     	int threadIndex;
>     	int numRepetitions;
>     	StatefulKnowledgeSession ksession;
>     	public TraitRulesThread(int threadIndex, int numRepetitions, final StatefulKnowledgeSession ksession) {
>     		this.threadIndex = threadIndex;
>     		this.numRepetitions = numRepetitions;
>     		this.ksession = ksession;
>     	}
>     	public void run() {
>     		for (int repetitionIndex = 0; repetitionIndex < numRepetitions; repetitionIndex++) {
>     			final Item i = new Item();
>     			i.setId(String.format("testId_%d%d", threadIndex, repetitionIndex));
>     			ksession.insert(i);
>     			ksession.fireAllRules();
>     		}
>     	}
>     }
>     @Test
>     public void testMultithreadingTraits() throws InterruptedException {
>     	final String s1 = "package test;\n" +
>     	"import org.drools.factmodel.traits.TraitTest.Item;\n" +
>     	"declare Item end\n" +
>     	"declare trait ItemStyle\n" +
>     	"	id: String\n" +
>     	"	adjustable: boolean\n" +
>     	"end\n" +
>     	"rule \"Don ItemStyle\"\n" +
>     	"	no-loop true\n" +
>     	"	when\n" +
>     	"		$p : Item ()\n" +
>     	"		not ItemStyle ( id == $p.id )\n" +
>     	"	then\n" +
>     	"		don($p, ItemStyle.class);\n" +
>     	"end\n" +
>     	"rule \"Item Style - Adjustable\"" +
>     	"	no-loop true" +
>     	"	when" +
>     	"		$style : ItemStyle ( !adjustable )" +
>     	"		Item (" +
>     	"			id == $style.id " +
>     	"		)" +
>     	"	then" +
>     	"		modify($style) {" +
>     	"			setAdjustable(true)" +
>     	"		};" +
>     	"end";
>     	final KnowledgeBase kbase = getKnowledgeBaseFromString(s1);
>     	// might need to tweak these numbers.  often works with 7-10,100,60, but often fails 15-20,100,60
>     	int MAX_THREADS = 20;
>     	int MAX_REPETITIONS = 100;
>     	int MAX_WAIT_SECONDS = 60;
>     	final ExecutorService executorService = Executors.newFixedThreadPool(MAX_THREADS);
>     	for (int threadIndex = 0; threadIndex < MAX_THREADS; threadIndex++) {
>     		executorService.execute(new TraitRulesThread(threadIndex, MAX_REPETITIONS, kbase.newStatefulKnowledgeSession()));
>     	}
>     	executorService.shutdown();
>     	executorService.awaitTermination(MAX_WAIT_SECONDS, TimeUnit.SECONDS);
>     	final List<Runnable> queuedTasks = executorService.shutdownNow();
>     	assertEquals(0, queuedTasks.size());
>     	assertEquals(true, executorService.isTerminated());
>     }
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 19:32:01 2013
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Tue, 22 Oct 2013 19:32:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2359) Clustering
 AsynchronousService should stop asynchronously by default
In-Reply-To: <JIRA.12508527.1382484614143@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508527.1382484614143@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508527.1382484614143.12232.1382484721974@jira02.app.mwc.hst.phx2.redhat.com>

Paul Ferraro created WFLY-2359:
----------------------------------

             Summary: Clustering AsynchronousService should stop asynchronously by default
                 Key: WFLY-2359
                 URL: https://issues.jboss.org/browse/WFLY-2359
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Clustering
    Affects Versions: 8.0.0.Beta1
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro
             Fix For: 8.0.0.CR1


By default, org.jboss.as.clustering.msc.AsynchronousService stops its service synchronously.  This was done to workaround MSC ordering issues with stopping of dependent services.  This no longer appears to be an issue.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 21:06:01 2013
From: jira-events at lists.jboss.org (Stefan Guilhen (JIRA))
Date: Tue, 22 Oct 2013 21:06:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-759)
 JASPIServerAuthenticationManager.isValid method should log configuration
 problems at WARN or ERROR level
In-Reply-To: <JIRA.12508529.1382490341484@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508529.1382490341484@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508529.1382490341484.12283.1382490361923@jira02.app.mwc.hst.phx2.redhat.com>

Stefan Guilhen created SECURITY-759:
---------------------------------------

             Summary: JASPIServerAuthenticationManager.isValid method should log configuration problems at WARN or ERROR level
                 Key: SECURITY-759
                 URL: https://issues.jboss.org/browse/SECURITY-759
             Project: PicketBox 
          Issue Type: Enhancement
      Security Level: Public (Everyone can see)
          Components: JBossSX
    Affects Versions: PicketBox_4_0_20.Beta1
            Reporter: Stefan Guilhen
            Assignee: Stefan Guilhen
             Fix For: 2.0.3.Beta2


As reported by Josef Cacek:

All fatal exception are swallowed in JASPIServerAuthenticationManager.isValid() method.
{code}
// PicketBox 4.0.9 used in EAP 6.0.0 - TRACE level
      catch(AuthException ae)
      {
         if(trace)
            log.trace("AuthException:",ae);
      }
// PicketBox 4.0.14 - DEBUG level
      catch(AuthException ae)
      {
          PicketBoxLogger.LOGGER.debugIgnoredException(ae);
      }
{code}
It includes configuration errors, which should absolutely be visible on ERROR log level or another relevant level.

We need to make sure to use ERROR log if the user-defined module cannot be found for instance.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 21:27:01 2013
From: jira-events at lists.jboss.org (Stefan Guilhen (JIRA))
Date: Tue, 22 Oct 2013 21:27:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-759)
 JASPIServerAuthenticationManager.isValid method should log configuration
 problems at WARN or ERROR level
In-Reply-To: <JIRA.12508529.1382490341000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508529.1382490341000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508529.1382490341000.12288.1382491621897@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Guilhen closed SECURITY-759.
-----------------------------------

    Resolution: Done


JASPIServerAuthenticationManager now uses ERROR level to log configuration problems that can happen when getting a ServerAuthConfig or a ServerAuthContext.
                
> JASPIServerAuthenticationManager.isValid method should log configuration problems at WARN or ERROR level
> --------------------------------------------------------------------------------------------------------
>
>                 Key: SECURITY-759
>                 URL: https://issues.jboss.org/browse/SECURITY-759
>             Project: PicketBox 
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: PicketBox_4_0_20.Beta1
>            Reporter: Stefan Guilhen
>            Assignee: Stefan Guilhen
>             Fix For: 2.0.3.Beta2
>
>
> As reported by Josef Cacek:
> All fatal exception are swallowed in JASPIServerAuthenticationManager.isValid() method.
> {code}
> // PicketBox 4.0.9 used in EAP 6.0.0 - TRACE level
>       catch(AuthException ae)
>       {
>          if(trace)
>             log.trace("AuthException:",ae);
>       }
> // PicketBox 4.0.14 - DEBUG level
>       catch(AuthException ae)
>       {
>           PicketBoxLogger.LOGGER.debugIgnoredException(ae);
>       }
> {code}
> It includes configuration errors, which should absolutely be visible on ERROR log level or another relevant level.
> We need to make sure to use ERROR log if the user-defined module cannot be found for instance.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 21:53:01 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Tue, 22 Oct 2013 21:53:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-309) Multiple threads working
 with traits against same knowledge base hangs
In-Reply-To: <JIRA.12508490.1382455844000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508490.1382455844000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508490.1382455844000.12314.1382493181991@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824134#comment-12824134 ] 

Davide Sottara commented on DROOLS-309:
---------------------------------------

The "TripleStore" is actually a mock implementation rather than a real interface to a global storage subsystem, which we haven't had time to implement yet.
Among other things, it is not thread-safe  (Drools 5 in general is not, so one has to pay attention when using multiple threads).

The best workaround is to use a local store for each traited object, which you can configure as you create the KnowledgeBase:
TraitFactory.setMode( TraitFactory.VirtualPropertyMode.MAP,  kbase );

I did fix another bug related to races in the definition of proxy classes, however, which will be in 5.6 and 6.x.
By the way, the trait subsystem in 5.6 is largely redesigned and improved. I will probably blog about it in a few days.

Best,
Davide
                
> Multiple threads working with traits against same knowledge base hangs
> ----------------------------------------------------------------------
>
>                 Key: DROOLS-309
>                 URL: https://issues.jboss.org/browse/DROOLS-309
>             Project: Drools
>          Issue Type: Quality Risk
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: James Myers
>            Assignee: Davide Sottara
>
> In our web system, we are creating new StatefulKnowledgeSession per user session and executing a set of rules containing trait donning.  This starts to hang (seemingly indefinitely) with following type of stack trace (usually initiated from insert/update):
> {quote}
>    java.lang.Thread.State: RUNNABLE
> 	at org.drools.core.util.TripleStore.getAll(TripleStore.java:188)
> 	at org.drools.factmodel.traits.TripleBasedStruct.getTriplesForSubject(TripleBasedStruct.java:165)
> 	at org.drools.factmodel.traits.ThingorgdroolsfactmodeltraitsTraitSession$ItemWrapperProxyWrapper.hashCode(Unknown Source)
> 	at org.drools.factmodel.traits.TraitProxy.hashCode(TraitProxy.java:110)
> 	at org.drools.factmodel.traits.ThingorgdroolsfactmodeltraitsTraitSession$ItemWrapperProxy.hashCode(Unknown Source)
> 	at org.drools.common.DefaultFactHandle.<init>(DefaultFactHandle.java:110)
> 	at org.drools.common.DefaultFactHandle.<init>(DefaultFactHandle.java:98)
> 	at org.drools.common.TraitFactHandle.<init>(TraitFactHandle.java:26)
> 	at org.drools.reteoo.ReteooFactHandleFactory.newFactHandle(ReteooFactHandleFactory.java:80)
> 	at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:68)
> 	at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:53)
> 	at org.drools.common.NamedEntryPoint.createHandle(NamedEntryPoint.java:765)
> 	at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:301)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903)
> {quote}
> Here is a unit test for org.drools.factmodel.traits.TraitTest.  It's not perfect because it will spawn thread that might never die and may need thread/iteration count increased to fail consistently, but capturing a stack trace a few seconds in should show all threads in "getAll()":
> {code}
>     @Traitable
>     public static class Item {
>     	private String id;
>     	public String getId() {
>     		return id;
>     	}
>     	public void setId(String id) {
>     		this.id = id;
>     	}
>     }
>     public static class TraitRulesThread implements Runnable {
>     	int threadIndex;
>     	int numRepetitions;
>     	StatefulKnowledgeSession ksession;
>     	public TraitRulesThread(int threadIndex, int numRepetitions, final StatefulKnowledgeSession ksession) {
>     		this.threadIndex = threadIndex;
>     		this.numRepetitions = numRepetitions;
>     		this.ksession = ksession;
>     	}
>     	public void run() {
>     		for (int repetitionIndex = 0; repetitionIndex < numRepetitions; repetitionIndex++) {
>     			final Item i = new Item();
>     			i.setId(String.format("testId_%d%d", threadIndex, repetitionIndex));
>     			ksession.insert(i);
>     			ksession.fireAllRules();
>     		}
>     	}
>     }
>     @Test
>     public void testMultithreadingTraits() throws InterruptedException {
>     	final String s1 = "package test;\n" +
>     	"import org.drools.factmodel.traits.TraitTest.Item;\n" +
>     	"declare Item end\n" +
>     	"declare trait ItemStyle\n" +
>     	"	id: String\n" +
>     	"	adjustable: boolean\n" +
>     	"end\n" +
>     	"rule \"Don ItemStyle\"\n" +
>     	"	no-loop true\n" +
>     	"	when\n" +
>     	"		$p : Item ()\n" +
>     	"		not ItemStyle ( id == $p.id )\n" +
>     	"	then\n" +
>     	"		don($p, ItemStyle.class);\n" +
>     	"end\n" +
>     	"rule \"Item Style - Adjustable\"" +
>     	"	no-loop true" +
>     	"	when" +
>     	"		$style : ItemStyle ( !adjustable )" +
>     	"		Item (" +
>     	"			id == $style.id " +
>     	"		)" +
>     	"	then" +
>     	"		modify($style) {" +
>     	"			setAdjustable(true)" +
>     	"		};" +
>     	"end";
>     	final KnowledgeBase kbase = getKnowledgeBaseFromString(s1);
>     	// might need to tweak these numbers.  often works with 7-10,100,60, but often fails 15-20,100,60
>     	int MAX_THREADS = 20;
>     	int MAX_REPETITIONS = 100;
>     	int MAX_WAIT_SECONDS = 60;
>     	final ExecutorService executorService = Executors.newFixedThreadPool(MAX_THREADS);
>     	for (int threadIndex = 0; threadIndex < MAX_THREADS; threadIndex++) {
>     		executorService.execute(new TraitRulesThread(threadIndex, MAX_REPETITIONS, kbase.newStatefulKnowledgeSession()));
>     	}
>     	executorService.shutdown();
>     	executorService.awaitTermination(MAX_WAIT_SECONDS, TimeUnit.SECONDS);
>     	final List<Runnable> queuedTasks = executorService.shutdownNow();
>     	assertEquals(0, queuedTasks.size());
>     	assertEquals(true, executorService.isTerminated());
>     }
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 22:33:01 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Oct 2013 22:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2206) Manualmode test suite copes
 the modules directory multiple times
In-Reply-To: <JIRA.12502031.1380731391000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502031.1380731391000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502031.1380731391000.12365.1382495581995@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824140#comment-12824140 ] 

RH Bugzilla Integration commented on WFLY-2206:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1014742|https://bugzilla.redhat.com/show_bug.cgi?id=1014742] from POST to MODIFIED
                
> Manualmode test suite copes the modules directory multiple times
> ----------------------------------------------------------------
>
>                 Key: WFLY-2206
>                 URL: https://issues.jboss.org/browse/WFLY-2206
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Beta1
>
>
> This uses lots of disk space for no good reason

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 22:41:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Oct 2013 22:41:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2338) When using a JDBC object
 store,
 the RecoveryManager service stop can occur after the datasource is already
 stopped
In-Reply-To: <JIRA.12508208.1382112933000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508208.1382112933000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508208.1382112933000.12394.1382496062148@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824148#comment-12824148 ] 

RH Bugzilla Integration commented on WFLY-2338:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1020881|https://bugzilla.redhat.com/show_bug.cgi?id=1020881] from POST to MODIFIED
                
> When using a JDBC object store, the RecoveryManager service stop can occur after the datasource is already stopped
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2338
>                 URL: https://issues.jboss.org/browse/WFLY-2338
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Transactions
>            Reporter: Tom Jenkinson
>            Assignee: Stefano Maestri
>         Attachments: 0001-patching-servicename-for-ds-dependency.patch
>
>
> It should be the cause of https://bugzilla.redhat.com/show_bug.cgi?id=1020881
> It has the effects described in the BZ, i.e. can cause warnings or can entirely block the application server from stopping

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 22 23:28:02 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Tue, 22 Oct 2013 23:28:02 -0400 (EDT)
Subject: [jboss-jira] =?utf-8?q?=5BJBoss_JIRA=5D_=28JBJCA-1101=29_XAExcept?=
 =?utf-8?b?aW9uOjpYQV9SQuKIlyBpc24ndCBmYXRhbA==?=
In-Reply-To: <JIRA.12508104.1382025703000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508104.1382025703000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508104.1382025703000.12404.1382498882079@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated JBJCA-1101:
-----------------------------------

        Summary: XAException::XA_RB? isn't fatal  (was: Downgrade logging of XAException::XA_RB? during XAResource::end(TMFAIL))
    Description: 
In org.jboss.jca.adapters.jdbc.xa.XAManagedConnection:

{code}
try
{
     xaResource.end(xid, flags);
}
catch (XAException e)
{
     broadcastConnectionError(e);
     throw e;
}
{code}

should not consider XA_RB* error codes as fatal. Same goes for .start().

  was:
In org.jboss.jca.adapters.jdbc.xa.XAManagedConnection:

{code}
try
         {
            xaResource.end(xid, flags);
         }
         catch (XAException e)
         {
            broadcastConnectionError(e);
            throw e;
         }
{code}

If we pass in TMFAIL to this method, according to XA we would expect an XAException::XA_RB* to be returned so do not log this as a warning. You can see how we handle this in JBTM over here: 

https://github.com/jbosstm/narayana/blob/540c689168fa2fd3db38d4ae1c3487c5d1ff7aff/ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/resources/arjunacore/XAResourceRecord.java#L317


    
> XAException::XA_RB? isn't fatal
> -------------------------------
>
>                 Key: JBJCA-1101
>                 URL: https://issues.jboss.org/browse/JBJCA-1101
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: JDBC
>    Affects Versions: 1.0.21.Final, 1.1.0.Final
>            Reporter: Tom Jenkinson
>            Assignee: Jesper Pedersen
>            Priority: Critical
>             Fix For: 1.0.22.Final, 1.1.1.Final
>
>
> In org.jboss.jca.adapters.jdbc.xa.XAManagedConnection:
> {code}
> try
> {
>      xaResource.end(xid, flags);
> }
> catch (XAException e)
> {
>      broadcastConnectionError(e);
>      throw e;
> }
> {code}
> should not consider XA_RB* error codes as fatal. Same goes for .start().

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Tue Oct 22 23:28:02 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Tue, 22 Oct 2013 23:28:02 -0400 (EDT)
Subject: [jboss-jira] =?utf-8?q?=5BJBoss_JIRA=5D_=28JBJCA-1101=29_XAExcept?=
 =?utf-8?b?aW9uOjpYQV9SQuKIlyBpc24ndCBmYXRhbA==?=
In-Reply-To: <JIRA.12508104.1382025703000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508104.1382025703000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508104.1382025703000.12408.1382498882236@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-1101.
------------------------------------

    Resolution: Done

    
> XAException::XA_RB? isn't fatal
> -------------------------------
>
>                 Key: JBJCA-1101
>                 URL: https://issues.jboss.org/browse/JBJCA-1101
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: JDBC
>    Affects Versions: 1.0.21.Final, 1.1.0.Final
>            Reporter: Tom Jenkinson
>            Assignee: Jesper Pedersen
>            Priority: Critical
>             Fix For: 1.0.22.Final, 1.1.1.Final
>
>
> In org.jboss.jca.adapters.jdbc.xa.XAManagedConnection:
> {code}
> try
> {
>      xaResource.end(xid, flags);
> }
> catch (XAException e)
> {
>      broadcastConnectionError(e);
>      throw e;
> }
> {code}
> should not consider XA_RB* error codes as fatal. Same goes for .start().

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Tue Oct 22 23:28:02 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Tue, 22 Oct 2013 23:28:02 -0400 (EDT)
Subject: [jboss-jira] =?utf-8?q?=5BJBoss_JIRA=5D_=28JBJCA-1101=29_XAExcept?=
 =?utf-8?b?aW9uOjpYQV9SQuKIlyBpc24ndCBmYXRhbA==?=
In-Reply-To: <JIRA.12508104.1382025703000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508104.1382025703000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508104.1382025703000.12411.1382498882405@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated JBJCA-1101:
-----------------------------------

    Comment: was deleted

(was: PR: https://github.com/ironjacamar/ironjacamar/pull/84)

    
> XAException::XA_RB? isn't fatal
> -------------------------------
>
>                 Key: JBJCA-1101
>                 URL: https://issues.jboss.org/browse/JBJCA-1101
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: JDBC
>    Affects Versions: 1.0.21.Final, 1.1.0.Final
>            Reporter: Tom Jenkinson
>            Assignee: Jesper Pedersen
>            Priority: Critical
>             Fix For: 1.0.22.Final, 1.1.1.Final
>
>
> In org.jboss.jca.adapters.jdbc.xa.XAManagedConnection:
> {code}
> try
> {
>      xaResource.end(xid, flags);
> }
> catch (XAException e)
> {
>      broadcastConnectionError(e);
>      throw e;
> }
> {code}
> should not consider XA_RB* error codes as fatal. Same goes for .start().

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Wed Oct 23 02:38:02 2013
From: jira-events at lists.jboss.org (Fred Hauschel (JIRA))
Date: Wed, 23 Oct 2013 02:38:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBASMP-32) Overriding the deployment
 name overrides the web-context
In-Reply-To: <JIRA.12482393.1357857594000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12482393.1357857594000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12482393.1357857594000.12475.1382510282083@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBASMP-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824161#comment-12824161 ] 

Fred Hauschel commented on JBASMP-32:
-------------------------------------

in my dev/test server i will test more than one instance of the same app! So define the context name in the jboss-web.xml is not so nice! It's possible to change the file with maven profiles at build time, but that is really not funny! Please add the possibility to set the context in the configuration of the plugin.
                
> Overriding the deployment name overrides the web-context
> --------------------------------------------------------
>
>                 Key: JBASMP-32
>                 URL: https://issues.jboss.org/browse/JBASMP-32
>             Project: JBoss AS Maven Plugins
>          Issue Type: Bug
>            Reporter: James Perkins
>            Assignee: James Perkins
>
> http://stackoverflow.com/questions/14241493/jboss-7-deployment-issues-with-war

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 02:52:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 23 Oct 2013 02:52:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1374) Unable to start JBoss server
 after issuing kill -9
In-Reply-To: <JIRA.12492408.1369213708000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12492408.1369213708000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12492408.1369213708000.12490.1382511122436@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-1374:
------------------------------------------

    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=965374, https://bugzilla.redhat.com/show_bug.cgi?id=1017563, https://bugzilla.redhat.com/show_bug.cgi?id=1022354  (was: https://bugzilla.redhat.com/show_bug.cgi?id=965374, https://bugzilla.redhat.com/show_bug.cgi?id=1017563)

    
> Unable to start JBoss server after issuing kill -9
> --------------------------------------------------
>
>                 Key: WFLY-1374
>                 URL: https://issues.jboss.org/browse/WFLY-1374
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Emanuel Muckenhuber
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.Beta1
>
>
> After manually killing a server it fails on subsequent start attempt using the management console or CLI.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 03:36:01 2013
From: jira-events at lists.jboss.org (Fred Hauschel (JIRA))
Date: Wed, 23 Oct 2013 03:36:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBASMP-32) Overriding the deployment
 name overrides the web-context
In-Reply-To: <JIRA.12482393.1357857594000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12482393.1357857594000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12482393.1357857594000.12549.1382513761910@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBASMP-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824177#comment-12824177 ] 

Fred Hauschel commented on JBASMP-32:
-------------------------------------

Another problem:
We are using maven as build system. And we are also using the maven-release-plugin.
So if anybody build a release of our artifact, the version increments and the artifactname also changes.
if we do not change the name / context (in the JBoss AS Maven Plugins config), so the deploy/redeploy goal will fail, because the name was changed!

This can only be handled by make an abstraction?!
                
> Overriding the deployment name overrides the web-context
> --------------------------------------------------------
>
>                 Key: JBASMP-32
>                 URL: https://issues.jboss.org/browse/JBASMP-32
>             Project: JBoss AS Maven Plugins
>          Issue Type: Bug
>            Reporter: James Perkins
>            Assignee: James Perkins
>
> http://stackoverflow.com/questions/14241493/jboss-7-deployment-issues-with-war

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 03:38:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 23 Oct 2013 03:38:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1487) X509Token Authentication is
 vulnerable to replay attacks
In-Reply-To: <JIRA.12469666.1340962910000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12469666.1340962910000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12469666.1340962910000.12554.1382513882588@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1487:
---------------------------

    Fix Version/s: 3.5
                       (was: Future)


Tristan's looking into this now
                
> X509Token Authentication is vulnerable to replay attacks
> --------------------------------------------------------
>
>                 Key: JGRP-1487
>                 URL: https://issues.jboss.org/browse/JGRP-1487
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.0.9
>            Reporter: sreenivas chinimilli
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> In the implementation of X509Token Authentication
> The auth_value is enrypted with the certificate within the keystore and
> during verification encrypted auth value is decrypted with the private key
> compared against the orignial auth value.
> This implementation is prone to replay attacks, that is
> any user with out having any knowledge of the auth value can join the group
> by replaying the enrypted auth value captured in earlier sessions.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 03:40:01 2013
From: jira-events at lists.jboss.org (Fred Hauschel (JIRA))
Date: Wed, 23 Oct 2013 03:40:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBASMP-32) Overriding the deployment
 name overrides the web-context
In-Reply-To: <JIRA.12482393.1357857594000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12482393.1357857594000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12482393.1357857594000.12562.1382514001887@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBASMP-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824180#comment-12824180 ] 

Fred Hauschel commented on JBASMP-32:
-------------------------------------

Feature Request ;-)
Enable also a deployment by maven GAV (groupid, artifactid, version). so that the JBoss AS Maven Plugin are able to undeploy previous versions of an artifact by switch.
                
> Overriding the deployment name overrides the web-context
> --------------------------------------------------------
>
>                 Key: JBASMP-32
>                 URL: https://issues.jboss.org/browse/JBASMP-32
>             Project: JBoss AS Maven Plugins
>          Issue Type: Bug
>            Reporter: James Perkins
>            Assignee: James Perkins
>
> http://stackoverflow.com/questions/14241493/jboss-7-deployment-issues-with-war

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 04:02:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 23 Oct 2013 04:02:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2358) setting
 <jacc-star-role-allow> in jboss-web.xml does not set allRolesMode to
 "authOnly"
In-Reply-To: <JIRA.12508518.1382471609000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508518.1382471609000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508518.1382471609000.12612.1382515322217@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824189#comment-12824189 ] 

RH Bugzilla Integration commented on WFLY-2358:
-----------------------------------------------

R?my Maucherat <rmaucher at redhat.com> made a comment on [bug 1022240|https://bugzilla.redhat.com/show_bug.cgi?id=1022240]

I don't know precisely what to do with the jacc-star-role-allow flag, its use was never very clear. Can you pass this to the security folks ?

For the new * behavior, the specification was clarified, it no longer means "anything", but any role in web.xml.
                
>  setting <jacc-star-role-allow> in jboss-web.xml does not set allRolesMode to "authOnly"
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-2358
>                 URL: https://issues.jboss.org/browse/WFLY-2358
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (JBoss Web)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Derek Horton
>            Assignee: Remy Maucherat
>
> I am trying to get only authentication (no authorization) to work for web application.
> In EAP 5, all that was required was to set the <role-name> to a '*' in
> the <security-constraint> of the web.xml.  I tried this in EAP 6,
> however, it did not work.
> I then found the <jacc-star-role-allow> setting that goes in the
> jboss-web.xml.  Unfortunately, adding this option did not cause the
> wildcard ('*') role-name to work for allowing any authenticated user 
> to access the web application.
> Using the following system property does appear to work:
> org.apache.catalina.realm.RealmBase.ALL_ROLES_MODE=authOnly
> How reproducible:
> Everytime.
> Steps to Reproduce:
> 1.  Set <role-name>*</role-name> in the security-contraint
> 2.  Set <jacc-star-role-allow>true</jacc-star-role-allow> in jboss-web.xml
> 3.  Set the security-domain so that no roles are assigned to a user
> 4.  Attempt to access the web app
> Actual results:
> 403 - access denied
> Expected results:
> 200 - access allowed
> Additional info:

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Wed Oct 23 04:16:03 2013
From: jira-events at lists.jboss.org (Remy Maucherat (JIRA))
Date: Wed, 23 Oct 2013 04:16:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-282) Lack of synchronization in
 org.apache.catalina.security.SecurityUtil
In-Reply-To: <JIRA.12508407.1382391772000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508407.1382391772000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508407.1382391772000.12622.1382516163339@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBWEB-282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Remy Maucherat resolved JBWEB-282.
----------------------------------

    Fix Version/s: JBossWeb-7.3.0.GA
       Resolution: Done


Ok.
                
> Lack of synchronization in org.apache.catalina.security.SecurityUtil
> --------------------------------------------------------------------
>
>                 Key: JBWEB-282
>                 URL: https://issues.jboss.org/browse/JBWEB-282
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-7.0.16.GA, JBossWeb-7.2.1.GA
>         Environment: -JBoss EAP 6.1.1
>            Reporter: Aaron Ogburn
>            Assignee: Remy Maucherat
>             Fix For: JBossWeb-7.3.0.GA
>
>
> The unsynchronized objectCache in org.apache.catalina.security.SecurityUtil can cause jboss start up and application deployments to spin on concurrent hash map access. Fixed already upstream in tomcat:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=50138
> objectCache now needs to be a ConcurrentHashMap given our multithreaded starts.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 04:33:02 2013
From: jira-events at lists.jboss.org (Remy Maucherat (JIRA))
Date: Wed, 23 Oct 2013 04:33:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-281) Inconsistent use of
	genStringAsCharArray.
In-Reply-To: <JIRA.12508212.1382115445000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508212.1382115445000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508212.1382115445000.12647.1382517182322@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBWEB-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Remy Maucherat resolved JBWEB-281.
----------------------------------

    Fix Version/s: JBossWeb-7.3.0.GA
       Resolution: Done

    
> Inconsistent use of genStringAsCharArray.
> -----------------------------------------
>
>                 Key: JBWEB-281
>                 URL: https://issues.jboss.org/browse/JBWEB-281
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-7.2.1.GA
>         Environment: All environments.
>            Reporter: Jeremy Whiting
>            Assignee: Remy Maucherat
>             Fix For: JBossWeb-7.3.0.GA
>
>
>  The JSP configuration property "genStringAsCharArray" is inconsistently named in jbossweb. This means the enabling of the feature for using char array type rather than String in generated Servlet code is not enabled.
>  This issue has been fixed upstream in the 7.0 branch of Tomcat hosted at Apache.
>  Can this patch be ported to jbossweb so that the 6.2 version of EAP includes this fix ?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 05:12:02 2013
From: jira-events at lists.jboss.org (Jeremy Whiting (JIRA))
Date: Wed, 23 Oct 2013 05:12:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2360) Upgrade to Jboss Web 7.3.0.GA
In-Reply-To: <JIRA.12508545.1382519479224@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508545.1382519479224@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508545.1382519479224.12688.1382519522039@jira02.app.mwc.hst.phx2.redhat.com>

Jeremy Whiting created WFLY-2360:
------------------------------------

             Summary: Upgrade to Jboss Web 7.3.0.GA
                 Key: WFLY-2360
                 URL: https://issues.jboss.org/browse/WFLY-2360
             Project: WildFly
          Issue Type: Component  Upgrade
      Security Level: Public (Everyone can see)
          Components: Web (JBoss Web)
    Affects Versions: 8.0.0.Beta1
            Reporter: Jeremy Whiting
            Assignee: Remy Maucherat


 The new version of jbossweb includes a fix to jsp compiler configuration.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 05:14:01 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 23 Oct 2013 05:14:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2360) Upgrade to Jboss Web 7.3.0.GA
In-Reply-To: <JIRA.12508545.1382519479000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508545.1382519479000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508545.1382519479000.12693.1382519641965@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar closed WFLY-2360.
-----------------------------

    Resolution: Rejected


Jboss web is not used in WildFly anymore.
                
> Upgrade to Jboss Web 7.3.0.GA
> -----------------------------
>
>                 Key: WFLY-2360
>                 URL: https://issues.jboss.org/browse/WFLY-2360
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Web (JBoss Web)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Jeremy Whiting
>            Assignee: Remy Maucherat
>
>  The new version of jbossweb includes a fix to jsp compiler configuration.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 05:30:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 23 Oct 2013 05:30:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2097) The vault wants write access
 to the keystore even when not needed
In-Reply-To: <JIRA.12500848.1379425358000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500848.1379425358000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500848.1379425358000.12711.1382520602135@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2097:
-----------------------------------

    Assignee: Anil Saldhana  (was: Darran Lofthouse)

    
> The vault wants write access to the keystore even when not needed
> -----------------------------------------------------------------
>
>                 Key: WFLY-2097
>                 URL: https://issues.jboss.org/browse/WFLY-2097
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Tom Fonteyne
>            Assignee: Anil Saldhana
>
> security/src/main/java/org/jboss/as/security/vault/VaultSession.java
> want constant "write" access to the keystore. This is considered to be a security risk.
> We understand this was a requirement to allow upgrades to be done automatically but don't see why the write-access has to be permanent

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 07:00:03 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Wed, 23 Oct 2013 07:00:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-254) "Exists OR" rules are
 compiled inconsistently
In-Reply-To: <JIRA.12500231.1378486146000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500231.1378486146000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500231.1378486146000.12810.1382526003070@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-254:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> "Exists OR" rules are compiled inconsistently
> ---------------------------------------------
>
>                 Key: DROOLS-254
>                 URL: https://issues.jboss.org/browse/DROOLS-254
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final,  6.0.0.CR3
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Critical
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> Exists ( A or B ) is transformed into ( Exists A ) or ( Exists B )
> In case both A and B are asserted, they result in two activations, 
> whereas one would expect only one. 
> Moreover, the equivalent not ( (not A) and (not B) ) results in only
> one activation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 07:00:03 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Wed, 23 Oct 2013 07:00:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-254) "Exists OR" rules are
 compiled inconsistently
In-Reply-To: <JIRA.12500231.1378486146000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500231.1378486146000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500231.1378486146000.12813.1382526003540@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-254.
--------------------------------

    Resolution: Done

    
> "Exists OR" rules are compiled inconsistently
> ---------------------------------------------
>
>                 Key: DROOLS-254
>                 URL: https://issues.jboss.org/browse/DROOLS-254
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final,  6.0.0.CR3
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Critical
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> Exists ( A or B ) is transformed into ( Exists A ) or ( Exists B )
> In case both A and B are asserted, they result in two activations, 
> whereas one would expect only one. 
> Moreover, the equivalent not ( (not A) and (not B) ) results in only
> one activation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 07:02:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 23 Oct 2013 07:02:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-254) "Exists OR" rules are
 compiled inconsistently
In-Reply-To: <JIRA.12500231.1378486146000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500231.1378486146000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500231.1378486146000.12816.1382526122147@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824224#comment-12824224 ] 

RH Bugzilla Integration commented on DROOLS-254:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> made a comment on [bug 1022469|https://bugzilla.redhat.com/show_bug.cgi?id=1022469]

Exists ( A or B ) is transformed into ( Exists A ) or ( Exists B )
In case both A and B are asserted, they result in two activations,
whereas one would expect only one.
Moreover, the equivalent not ( (not A) and (not B) ) results in only
one activation.
                
> "Exists OR" rules are compiled inconsistently
> ---------------------------------------------
>
>                 Key: DROOLS-254
>                 URL: https://issues.jboss.org/browse/DROOLS-254
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final,  6.0.0.CR3
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Critical
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> Exists ( A or B ) is transformed into ( Exists A ) or ( Exists B )
> In case both A and B are asserted, they result in two activations, 
> whereas one would expect only one. 
> Moreover, the equivalent not ( (not A) and (not B) ) results in only
> one activation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 07:02:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 23 Oct 2013 07:02:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-254) "Exists OR" rules are
 compiled inconsistently
In-Reply-To: <JIRA.12500231.1378486146000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500231.1378486146000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500231.1378486146000.12820.1382526122429@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated DROOLS-254:
-------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1022469

    
> "Exists OR" rules are compiled inconsistently
> ---------------------------------------------
>
>                 Key: DROOLS-254
>                 URL: https://issues.jboss.org/browse/DROOLS-254
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final,  6.0.0.CR3
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Critical
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> Exists ( A or B ) is transformed into ( Exists A ) or ( Exists B )
> In case both A and B are asserted, they result in two activations, 
> whereas one would expect only one. 
> Moreover, the equivalent not ( (not A) and (not B) ) results in only
> one activation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 07:04:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 23 Oct 2013 07:04:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-254) "Exists OR" rules are
 compiled inconsistently
In-Reply-To: <JIRA.12500231.1378486146000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500231.1378486146000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500231.1378486146000.12824.1382526242348@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824225#comment-12824225 ] 

RH Bugzilla Integration commented on DROOLS-254:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> made a comment on [bug 1022469|https://bugzilla.redhat.com/show_bug.cgi?id=1022469]

Fixed by https://github.com/droolsjbpm/drools/commit/66dabe8b1
                
> "Exists OR" rules are compiled inconsistently
> ---------------------------------------------
>
>                 Key: DROOLS-254
>                 URL: https://issues.jboss.org/browse/DROOLS-254
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final,  6.0.0.CR3
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Critical
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> Exists ( A or B ) is transformed into ( Exists A ) or ( Exists B )
> In case both A and B are asserted, they result in two activations, 
> whereas one would expect only one. 
> Moreover, the equivalent not ( (not A) and (not B) ) results in only
> one activation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 07:04:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 23 Oct 2013 07:04:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-254) "Exists OR" rules are
 compiled inconsistently
In-Reply-To: <JIRA.12500231.1378486146000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500231.1378486146000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500231.1378486146000.12828.1382526242648@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824226#comment-12824226 ] 

RH Bugzilla Integration commented on DROOLS-254:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> changed the Status of [bug 1022469|https://bugzilla.redhat.com/show_bug.cgi?id=1022469] from NEW to MODIFIED
                
> "Exists OR" rules are compiled inconsistently
> ---------------------------------------------
>
>                 Key: DROOLS-254
>                 URL: https://issues.jboss.org/browse/DROOLS-254
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final,  6.0.0.CR3
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Critical
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> Exists ( A or B ) is transformed into ( Exists A ) or ( Exists B )
> In case both A and B are asserted, they result in two activations, 
> whereas one would expect only one. 
> Moreover, the equivalent not ( (not A) and (not B) ) results in only
> one activation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 07:09:01 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 23 Oct 2013 07:09:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2361) WorkManager callback security
	never set
In-Reply-To: <JIRA.12508556.1382526535979@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508556.1382526535979@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508556.1382526535979.12831.1382526541993@jira02.app.mwc.hst.phx2.redhat.com>

Jesper Pedersen created WFLY-2361:
-------------------------------------

             Summary: WorkManager callback security never set
                 Key: WFLY-2361
                 URL: https://issues.jboss.org/browse/WFLY-2361
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JCA
    Affects Versions: 8.0.0.Beta1
            Reporter: Jesper Pedersen
            Assignee: Stefano Maestri
            Priority: Blocker
             Fix For: 8.0.0.CR1


The

{noformat}
org.jboss.as.connector.services.workmanager.WorkManagerService
{noformat}

never calls "setCallbackSecurity" with the specified policy.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 07:14:01 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 23 Oct 2013 07:14:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2361) WorkManager callback security
	never set
In-Reply-To: <JIRA.12508556.1382526535000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508556.1382526535000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508556.1382526535000.12836.1382526841955@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824228#comment-12824228 ] 

Jesper Pedersen commented on WFLY-2361:
---------------------------------------

org.jboss.jca.core.security.CallbackImpl can be used for a backing implementation
                
> WorkManager callback security never set
> ---------------------------------------
>
>                 Key: WFLY-2361
>                 URL: https://issues.jboss.org/browse/WFLY-2361
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Jesper Pedersen
>            Assignee: Stefano Maestri
>            Priority: Blocker
>             Fix For: 8.0.0.CR1
>
>
> The
> {noformat}
> org.jboss.as.connector.services.workmanager.WorkManagerService
> {noformat}
> never calls "setCallbackSecurity" with the specified policy.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 07:18:02 2013
From: jira-events at lists.jboss.org (Philippe Marschall (JIRA))
Date: Wed, 23 Oct 2013 07:18:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2345) Port offset 0 does not work
In-Reply-To: <JIRA.12508250.1382265308000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508250.1382265308000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508250.1382265308000.12841.1382527082100@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824229#comment-12824229 ] 

Philippe Marschall commented on WFLY-2345:
------------------------------------------

Pull request has been merged, should probably be closed.
                
> Port offset 0 does not work
> ---------------------------
>
>                 Key: WFLY-2345
>                 URL: https://issues.jboss.org/browse/WFLY-2345
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Philippe Marschall
>            Assignee: Jason Greene
>
> When a port offset is specified in the socket binding group and the socket binding has a port of 0, then the port offset is not used to calculate the port instead port 0 is bound.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 07:47:02 2013
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Wed, 23 Oct 2013 07:47:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2333) Web deployment code assumes
 only a single ServletContainerInitializer is present in each jar
In-Reply-To: <JIRA.12508164.1382090257000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508164.1382090257000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508164.1382090257000.12920.1382528822586@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stan Silvert reopened WFLY-2333:
--------------------------------



The fix for this causes some deployments to hang.  I narrowed down the problem to this commit:  https://github.com/wildfly/wildfly/commit/b8a222ec24f2cb58c832aa5b2f6a14dbc8d53899

I'll attach a couple of JSF projects whose WARs demonstrate the issue.
                
> Web deployment code assumes only a single ServletContainerInitializer is present in each jar
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2333
>                 URL: https://issues.jboss.org/browse/WFLY-2333
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 08:28:02 2013
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Wed, 23 Oct 2013 08:28:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2333) Web deployment code assumes
 only a single ServletContainerInitializer is present in each jar
In-Reply-To: <JIRA.12508164.1382090257000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508164.1382090257000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508164.1382090257000.13000.1382531282044@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stan Silvert updated WFLY-2333:
-------------------------------

    Attachment: diycdemo.zip
                hellomyfaces.zip


The one commonality I see between these two applications is that they are both JSF apps that have nothing in the WEB-INF/classes directory.
                
> Web deployment code assumes only a single ServletContainerInitializer is present in each jar
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2333
>                 URL: https://issues.jboss.org/browse/WFLY-2333
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.CR1
>
>         Attachments: diycdemo.zip, hellomyfaces.zip
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 08:30:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 23 Oct 2013 08:30:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-758) AdvancedLdapLoginModule
 doesn't isn't mapping nested roles
In-Reply-To: <JIRA.12508503.1382458902000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508503.1382458902000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508503.1382458902000.13004.1382531402108@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated SECURITY-758:
---------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1017974

    
> AdvancedLdapLoginModule doesn't isn't mapping nested roles
> ----------------------------------------------------------
>
>                 Key: SECURITY-758
>                 URL: https://issues.jboss.org/browse/SECURITY-758
>             Project: PicketBox 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>    Affects Versions: Negotiation_2_2_5
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: Negotiation_2_2_6
>
>
> The recursive role searching is currently broken, believed to be caused by the introduction of quotes for a previous role searching fix.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 08:41:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Wed, 23 Oct 2013 08:41:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2333) Web deployment code assumes
 only a single ServletContainerInitializer is present in each jar
In-Reply-To: <JIRA.12508164.1382090257000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508164.1382090257000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508164.1382090257000.13018.1382532062030@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824264#comment-12824264 ] 

Stuart Douglas commented on WFLY-2333:
--------------------------------------

Oops: https://github.com/wildfly/wildfly/pull/5333
                
> Web deployment code assumes only a single ServletContainerInitializer is present in each jar
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2333
>                 URL: https://issues.jboss.org/browse/WFLY-2333
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.CR1
>
>         Attachments: diycdemo.zip, hellomyfaces.zip
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 09:02:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 23 Oct 2013 09:02:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1720) RequestOptions: exclusion
 list should be array
In-Reply-To: <JIRA.12508339.1382359866000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508339.1382359866000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508339.1382359866000.13073.1382533322009@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824270#comment-12824270 ] 

Bela Ban commented on JGRP-1720:
--------------------------------

Also changed MultiDestinationHeader to use an address array instead of a list
                
> RequestOptions: exclusion list should be array
> ----------------------------------------------
>
>                 Key: JGRP-1720
>                 URL: https://issues.jboss.org/browse/JGRP-1720
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.4.1, 3.5
>
>
> RequestOptions.exclusion_list should be an array, to conserve memory and CPU overhead. Possibly also just send the index of the member in the current view.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 09:02:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 23 Oct 2013 09:02:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1720) RequestOptions: exclusion
 list should be array
In-Reply-To: <JIRA.12508339.1382359866000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508339.1382359866000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508339.1382359866000.13076.1382533322129@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1720:
---------------------------

    Fix Version/s:     (was: 3.4.1)

    
> RequestOptions: exclusion list should be array
> ----------------------------------------------
>
>                 Key: JGRP-1720
>                 URL: https://issues.jboss.org/browse/JGRP-1720
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.5
>
>
> RequestOptions.exclusion_list should be an array, to conserve memory and CPU overhead. Possibly also just send the index of the member in the current view.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 09:20:02 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Wed, 23 Oct 2013 09:20:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1458) Allow specifying timeout for
 org.jboss.as.arquillian.container.ManagementClient.isServerInRunningState()
In-Reply-To: <JIRA.12493672.1370454383000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493672.1370454383000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493672.1370454383000.13112.1382534402567@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824274#comment-12824274 ] 

Ladislav Thon commented on WFLY-1458:
-------------------------------------

I believe I have reproduces the same issue. In fact, the connection won't hang indefinitely -- it will only hang for cca 50 minutes (in default settings). That's because the loop in {{ManagedDeployableContainer.startInternal}} assumes that {{ManagementClient.isServerInRunningState()}} is cheap, which it doesn't have to be. It can fall into a trap and the IO will have to time out. By default, that timeout is 5 seconds, which means that the container startup timeout is prolonged cca 50x (which gives the 50 minutes -- the default container startup timeout is 1 minute).

I have a proposed fix in this pull request: https://github.com/wildfly/wildfly/pull/5334
                
> Allow specifying timeout for org.jboss.as.arquillian.container.ManagementClient.isServerInRunningState()
> --------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1458
>                 URL: https://issues.jboss.org/browse/WFLY-1458
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Richard Achmatowicz
>            Assignee: Aslak Knutsen
>         Attachments: thread.dump.txt
>
>
> When deploying a container, Arquillian will use a management client to connect to the deployed container to see if it is in a running state. If the management address and management port are incorrect, the connection to the container hangs indefinitely.
> Please allow configuration of a timeout so that if the connection paramaters are not correct, at least the container deployment will fail with a meaningful error.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 09:20:03 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Wed, 23 Oct 2013 09:20:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1458) Allow specifying timeout for
 org.jboss.as.arquillian.container.ManagementClient.isServerInRunningState()
In-Reply-To: <JIRA.12493672.1370454383000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493672.1370454383000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493672.1370454383000.13115.1382534403618@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824274#comment-12824274 ] 

Ladislav Thon edited comment on WFLY-1458 at 10/23/13 9:18 AM:
---------------------------------------------------------------

I believe I have reproduced the same issue. In fact, the connection won't hang indefinitely -- it will only hang for cca 50 minutes (in default settings). That's because the loop in {{ManagedDeployableContainer.startInternal}} assumes that {{ManagementClient.isServerInRunningState()}} is cheap, which it doesn't have to be. It can fall into a trap and the IO will have to time out. By default, that timeout is 5 seconds, which means that the container startup timeout is prolonged cca 50x (which gives the 50 minutes -- the default container startup timeout is 1 minute).

I have a proposed fix in this pull request: https://github.com/wildfly/wildfly/pull/5334
                
      was (Author: lthon):
    I believe I have reproduces the same issue. In fact, the connection won't hang indefinitely -- it will only hang for cca 50 minutes (in default settings). That's because the loop in {{ManagedDeployableContainer.startInternal}} assumes that {{ManagementClient.isServerInRunningState()}} is cheap, which it doesn't have to be. It can fall into a trap and the IO will have to time out. By default, that timeout is 5 seconds, which means that the container startup timeout is prolonged cca 50x (which gives the 50 minutes -- the default container startup timeout is 1 minute).

I have a proposed fix in this pull request: https://github.com/wildfly/wildfly/pull/5334
                  
> Allow specifying timeout for org.jboss.as.arquillian.container.ManagementClient.isServerInRunningState()
> --------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1458
>                 URL: https://issues.jboss.org/browse/WFLY-1458
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Richard Achmatowicz
>            Assignee: Aslak Knutsen
>         Attachments: thread.dump.txt
>
>
> When deploying a container, Arquillian will use a management client to connect to the deployed container to see if it is in a running state. If the management address and management port are incorrect, the connection to the container hangs indefinitely.
> Please allow configuration of a timeout so that if the connection paramaters are not correct, at least the container deployment will fail with a meaningful error.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 09:22:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 23 Oct 2013 09:22:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1458) Allow specifying timeout for
 org.jboss.as.arquillian.container.ManagementClient.isServerInRunningState()
In-Reply-To: <JIRA.12493672.1370454383000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493672.1370454383000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493672.1370454383000.13127.1382534522336@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-1458:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1021487

    
> Allow specifying timeout for org.jboss.as.arquillian.container.ManagementClient.isServerInRunningState()
> --------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1458
>                 URL: https://issues.jboss.org/browse/WFLY-1458
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Richard Achmatowicz
>            Assignee: Aslak Knutsen
>         Attachments: thread.dump.txt
>
>
> When deploying a container, Arquillian will use a management client to connect to the deployed container to see if it is in a running state. If the management address and management port are incorrect, the connection to the container hangs indefinitely.
> Please allow configuration of a timeout so that if the connection paramaters are not correct, at least the container deployment will fail with a meaningful error.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 09:22:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 23 Oct 2013 09:22:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1458) Allow specifying timeout for
 org.jboss.as.arquillian.container.ManagementClient.isServerInRunningState()
In-Reply-To: <JIRA.12493672.1370454383000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493672.1370454383000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493672.1370454383000.13133.1382534522528@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824275#comment-12824275 ] 

RH Bugzilla Integration commented on WFLY-1458:
-----------------------------------------------

Ladislav Thon <lthon at redhat.com> made a comment on [bug 1021487|https://bugzilla.redhat.com/show_bug.cgi?id=1021487]

Linking an upstream JIRA that I believe is essentially the same problem: https://issues.jboss.org/browse/WFLY-1458
                
> Allow specifying timeout for org.jboss.as.arquillian.container.ManagementClient.isServerInRunningState()
> --------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1458
>                 URL: https://issues.jboss.org/browse/WFLY-1458
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Richard Achmatowicz
>            Assignee: Aslak Knutsen
>         Attachments: thread.dump.txt
>
>
> When deploying a container, Arquillian will use a management client to connect to the deployed container to see if it is in a running state. If the management address and management port are incorrect, the connection to the container hangs indefinitely.
> Please allow configuration of a timeout so that if the connection paramaters are not correct, at least the container deployment will fail with a meaningful error.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 09:30:01 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 23 Oct 2013 09:30:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1720) RequestOptions: exclusion
 list should be array
In-Reply-To: <JIRA.12508339.1382359866000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508339.1382359866000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508339.1382359866000.13163.1382535001979@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1720.
----------------------------

    Resolution: Done

    
> RequestOptions: exclusion list should be array
> ----------------------------------------------
>
>                 Key: JGRP-1720
>                 URL: https://issues.jboss.org/browse/JGRP-1720
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.5
>
>
> RequestOptions.exclusion_list should be an array, to conserve memory and CPU overhead. Possibly also just send the index of the member in the current view.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 09:37:02 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 23 Oct 2013 09:37:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1458) Allow specifying timeout for
 org.jboss.as.arquillian.container.ManagementClient.isServerInRunningState()
In-Reply-To: <JIRA.12493672.1370454383000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493672.1370454383000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493672.1370454383000.13177.1382535422348@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-1458:
------------------------------

    Bugzilla Update:   (was: Perform)
        Component/s: Domain Management

    
> Allow specifying timeout for org.jboss.as.arquillian.container.ManagementClient.isServerInRunningState()
> --------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1458
>                 URL: https://issues.jboss.org/browse/WFLY-1458
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Test Suite
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Richard Achmatowicz
>            Assignee: Aslak Knutsen
>         Attachments: thread.dump.txt
>
>
> When deploying a container, Arquillian will use a management client to connect to the deployed container to see if it is in a running state. If the management address and management port are incorrect, the connection to the container hangs indefinitely.
> Please allow configuration of a timeout so that if the connection paramaters are not correct, at least the container deployment will fail with a meaningful error.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 09:39:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 23 Oct 2013 09:39:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1721) AUTH and ENCRYPT protocols
 configured with plain text passwords
In-Reply-To: <JIRA.12508425.1382426440000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508425.1382426440000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508425.1382426440000.13194.1382535542242@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824281#comment-12824281 ] 

Bela Ban commented on JGRP-1721:
--------------------------------

All passwords can be set *programmatically* instead of via XML config files. When JGroups {{AUTH}} and {{ENCRYPT}} are run within EAP, I envisage that credentials, passwords, usernames etc are injected into the JGroups subsystem by EAP.

Is this still an issue ?
                
> AUTH and ENCRYPT protocols configured with plain text passwords
> ---------------------------------------------------------------
>
>                 Key: JGRP-1721
>                 URL: https://issues.jboss.org/browse/JGRP-1721
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Martin Gencur
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> The following parameters of AUTH protocol are stored as plain text:
> * keystore_password
> The following parameters of ENCRYPT protocol are stored as plain text:
> * store_password
> * key_password
> Example:
> {code}
> <ENCRYPT key_store_name="defaultStore.keystore" store_password="changeit" alias="myKey"/>
> {code}
> Requirements for storing passwords: https://docspace.corp.redhat.com/docs/DOC-131628

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 09:41:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 23 Oct 2013 09:41:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1487) AUTH: X509Token
 Authentication is vulnerable to replay attacks
In-Reply-To: <JIRA.12469666.1340962910000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12469666.1340962910000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12469666.1340962910000.13205.1382535662255@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1487:
---------------------------

    Summary: AUTH: X509Token Authentication is vulnerable to replay attacks  (was: X509Token Authentication is vulnerable to replay attacks)

    
> AUTH: X509Token Authentication is vulnerable to replay attacks
> --------------------------------------------------------------
>
>                 Key: JGRP-1487
>                 URL: https://issues.jboss.org/browse/JGRP-1487
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.0.9
>            Reporter: sreenivas chinimilli
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> In the implementation of X509Token Authentication
> The auth_value is enrypted with the certificate within the keystore and
> during verification encrypted auth value is decrypted with the private key
> compared against the orignial auth value.
> This implementation is prone to replay attacks, that is
> any user with out having any knowledge of the auth value can join the group
> by replaying the enrypted auth value captured in earlier sessions.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 09:57:02 2013
From: jira-events at lists.jboss.org (Jozef Hartinger (JIRA))
Date: Wed, 23 Oct 2013 09:57:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2362) Support CDI interception of
 all EE components
In-Reply-To: <JIRA.12508575.1382536533244@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508575.1382536533244@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508575.1382536533244.13245.1382536622195@jira02.app.mwc.hst.phx2.redhat.com>

Jozef Hartinger created WFLY-2362:
-------------------------------------

             Summary: Support CDI interception of all EE components
                 Key: WFLY-2362
                 URL: https://issues.jboss.org/browse/WFLY-2362
             Project: WildFly
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Jozef Hartinger
            Assignee: Jozef Hartinger
            Priority: Blocker
             Fix For: 8.0.0.CR1


As required by EE 7 Table EE.5-1.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 10:21:01 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 23 Oct 2013 10:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2296) Patched state is missing the
 updated resulting version
In-Reply-To: <JIRA.12502946.1381752036000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502946.1381752036000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502946.1381752036000.13290.1382538061995@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824296#comment-12824296 ] 

RH Bugzilla Integration commented on WFLY-2296:
-----------------------------------------------

Emanuel Muckenhuber <emuckenh at redhat.com> changed the Status of [bug 1018181|https://bugzilla.redhat.com/show_bug.cgi?id=1018181] from ASSIGNED to POST
                
> Patched state is missing the updated resulting version
> ------------------------------------------------------
>
>                 Key: WFLY-2296
>                 URL: https://issues.jboss.org/browse/WFLY-2296
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Patching
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Emanuel Muckenhuber
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 10:49:01 2013
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 23 Oct 2013 10:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1941) can not undefine
 connection-factory's connector attribute
In-Reply-To: <JIRA.12499291.1377270757000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499291.1377270757000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499291.1377270757000.13372.1382539741879@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil resolved WFLY-1941.
-------------------------------

    Fix Version/s: 8.0.0.Beta1
       Resolution: Done


fixed in WFLY-2069
                
> can not undefine connection-factory's connector attribute
> ---------------------------------------------------------
>
>                 Key: WFLY-1941
>                 URL: https://issues.jboss.org/browse/WFLY-1941
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JMS
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.Beta1
>
>
> use case:
> {noformat}
> [standalone at localhost:9990 /] /subsystem=messaging/hornetq-server=default/connection-factory=RemoteConnectionFactory:undefine-attribute(name=connector)
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014749: Operation handler failed: JBAS011664: Runtime handling for connector is not implemented",
>     "rolled-back" => true
> }
> {noformat}
> and the server outputs the error:
> {noformat}
> 17:05:08,295 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) JBAS014612: Operation ("undefine-attribute") failed - address: ([
>     ("subsystem" => "messaging"),
>     ("hornetq-server" => "default"),
>     ("connection-factory" => "RemoteConnectionFactory")
> ]): java.lang.UnsupportedOperationException: JBAS011664: Runtime handling for connector is not implemented
>         at org.jboss.as.messaging.jms.ConnectionFactoryWriteAttributeHandler.applyOperationToHornetQService(ConnectionFactoryWriteAttributeHandler.java:184)
>         at org.jboss.as.messaging.jms.ConnectionFactoryWriteAttributeHandler.applyUpdateToRuntime(ConnectionFactoryWriteAttributeHandler.java:96)
>         at org.jboss.as.controller.AbstractWriteAttributeHandler$1.execute(AbstractWriteAttributeHandler.java:101) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
>         at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:608) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
>         ...
> {noformat}
> The operation should fail but for another reason: we must check whether the discovery-group-name attribute (which is an alternative to the connector) is defined on the model. If it is not, it's an error to undefine the connector.
> However, the code in ConnectionFactoryWriteAttributeHandler must also be updated to prevent updating an attribute that has *no* corresponding field in the ConnectionFactoryControl interface.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 10:55:02 2013
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Wed, 23 Oct 2013 10:55:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2363) Deprecate @Clustered EJB
	annotation
In-Reply-To: <JIRA.12508589.1382540077548@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508589.1382540077548@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508589.1382540077548.13409.1382540102282@jira02.app.mwc.hst.phx2.redhat.com>

Paul Ferraro created WFLY-2363:
----------------------------------

             Summary: Deprecate @Clustered EJB annotation
                 Key: WFLY-2363
                 URL: https://issues.jboss.org/browse/WFLY-2363
             Project: WildFly
          Issue Type: Enhancement
      Security Level: Public (Everyone can see)
          Components: Clustering
    Affects Versions: 8.0.0.Beta1
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro
             Fix For: 9.0.0.CR1


As discussed in WFLY-2298, the @Clustered annotation of AS7 has 2 orthogonal meanings: 1. If applied to a @Stateful EJB, then a specific cache will be used (as defined by the ejb subsystem) 2. If applied to a @Stateless or @Stateful EJB, remote EJB clients will have a dynamic view of the EJB deployment topology (i.e. the nodes on which a given bean is deployed). WFLY-2298 already aims to make the clusterability of a SFSB a property of the environment. This is effectively the case already, since @Clustered is ignored if the environment does not support HA. The omission of @Clustered means that the state should not replicate, whatever the environment - however, EJB 3.2 already provides a mechanism to disable replication/passivation via @Stateful(passivationCapable=false). Thus, reason #1 is no longer relevant. Reason #2 isn't really necessary either. @Clustered is ignored if, as mentioned above, the server profile does not support it, but also if the ejb client is not configured with a specific cluster name. Therefore, this behavior too can be made the default for HA profiles - and the client can dictate whether or not it is interested in deployment topology updates.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Wed Oct 23 11:03:03 2013
From: jira-events at lists.jboss.org (Denis Borovikov (JIRA))
Date: Wed, 23 Oct 2013 11:03:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2364) Uninformative NPE in
 PoolAnnotationInformationFactory
In-Reply-To: <JIRA.12508592.1382540493788@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508592.1382540493788@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508592.1382540493788.13420.1382540583222@jira02.app.mwc.hst.phx2.redhat.com>

Denis Borovikov created WFLY-2364:
-------------------------------------

             Summary: Uninformative NPE in PoolAnnotationInformationFactory 
                 Key: WFLY-2364
                 URL: https://issues.jboss.org/browse/WFLY-2364
             Project: WildFly
          Issue Type: Enhancement
      Security Level: Public (Everyone can see)
            Reporter: Denis Borovikov


I got NPE on jboss startup:

	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:119) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) [rt.jar:1.6.0_45]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) [rt.jar:1.6.0_45]
	at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_45]
Caused by: java.lang.NullPointerException
	at org.jboss.as.ejb3.deployment.processors.annotation.PoolAnnotationInformationFactory.fromAnnotation(PoolAnnotationInformationFactory.java:43)
	at org.jboss.as.ejb3.deployment.processors.annotation.PoolAnnotationInformationFactory.fromAnnotation(PoolAnnotationInformationFactory.java:35)
	at org.jboss.as.ee.metadata.ClassAnnotationInformationFactory.createAnnotationInformation(ClassAnnotationInformationFactory.java:127)
	at org.jboss.as.ee.metadata.AbstractEEAnnotationProcessor.deploy(AbstractEEAnnotationProcessor.java:54)
	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:113) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
	... 5 more

Root cause is empty value for Pool annotation in my code. I think it would be better to generate more informative exception message in this place.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 11:44:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 23 Oct 2013 11:44:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-355) JBoss Negotiation - User
 Guide Enhancements
In-Reply-To: <JIRA.12378926.1233684364000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12378926.1233684364000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12378926.1233684364000.13547.1382543042276@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved SECURITY-355.
---------------------------------------

    Resolution: Out of Date

    
> JBoss Negotiation - User Guide Enhancements
> -------------------------------------------
>
>                 Key: SECURITY-355
>                 URL: https://issues.jboss.org/browse/SECURITY-355
>             Project: PicketBox 
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>    Affects Versions: Negotiation_2.0.3.GA
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For:  Negotiation_2.0.3.SP4 
>
>
> Add additional clarification to the critical points within the user guide.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 11:44:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 23 Oct 2013 11:44:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-448) Fallback to BASIC
 authenticator if authentication fails
In-Reply-To: <JIRA.12400756.1261171651000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12400756.1261171651000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12400756.1261171651000.13568.1382543043367@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved SECURITY-448.
---------------------------------------

    Resolution: Out of Date


WildFly is making use of Undertow which is built with support for pairing SPNEGO with other authentication mechanisms.
                
> Fallback to BASIC authenticator if authentication fails
> -------------------------------------------------------
>
>                 Key: SECURITY-448
>                 URL: https://issues.jboss.org/browse/SECURITY-448
>             Project: PicketBox 
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>            Reporter: Jacob Orshalick
>            Assignee: Darran Lofthouse
>             Fix For: Negotiation_2_1_3
>
>         Attachments: jboss-negotiation-common-v1.patch, jboss-negotiation-common-v1.patch, jboss-negotiation-common-v2.patch, jboss-negotiation-spnego-v1.patch, NegotiationAuthenticator.java
>
>
> This issue is related to SECURITY-141, but is a request to allow fallback to BASIC authentication where SPNEGO is not supported.  As a side effect this should also allow username/password authentication where SPNEGO did not take place.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 11:44:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 23 Oct 2013 11:44:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2296) Patched state is missing the
 updated resulting version
In-Reply-To: <JIRA.12502946.1381752036000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502946.1381752036000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502946.1381752036000.13571.1382543043513@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824348#comment-12824348 ] 

RH Bugzilla Integration commented on WFLY-2296:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1018181|https://bugzilla.redhat.com/show_bug.cgi?id=1018181] from POST to MODIFIED
                
> Patched state is missing the updated resulting version
> ------------------------------------------------------
>
>                 Key: WFLY-2296
>                 URL: https://issues.jboss.org/browse/WFLY-2296
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Patching
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Emanuel Muckenhuber
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 11:46:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 23 Oct 2013 11:46:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-74) REMJMX-65 Overzealous
 disabling local authentication
In-Reply-To: <JIRA.12508386.1382374102000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508386.1382374102000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508386.1382374102000.13586.1382543163017@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/REMJMX-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824350#comment-12824350 ] 

RH Bugzilla Integration commented on REMJMX-74:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1021630|https://bugzilla.redhat.com/show_bug.cgi?id=1021630] from POST to MODIFIED
                
> REMJMX-65 Overzealous disabling local authentication
> ----------------------------------------------------
>
>                 Key: REMJMX-74
>                 URL: https://issues.jboss.org/browse/REMJMX-74
>             Project: Remoting JMX
>          Issue Type: Bug
>          Components: Connection
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.2.Final, 2.0.0.CR4
>
>
> REMJMX-65 is overzealous at disabling local authentication, if a username and credential is supplied in the environment then it does make sense to disable local authentication - however the availability of a callback handler is not a sufficient flag to also disable it.
> In the case of the callback handler the user may still only want to be prompted if the other mechanisms fail.
> This issue will remove the disabling of local authentication based on the presence of a callback handler and will instead add a configuration option that can be set on the environment.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 11:48:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 23 Oct 2013 11:48:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2357) OperationStepHandlers do not
 properly check if runtime steps should be added
In-Reply-To: <JIRA.12508504.1382459867000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508504.1382459867000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508504.1382459867000.13593.1382543282130@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824352#comment-12824352 ] 

RH Bugzilla Integration commented on WFLY-2357:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1021633|https://bugzilla.redhat.com/show_bug.cgi?id=1021633] from POST to MODIFIED
                
> OperationStepHandlers do not properly check if runtime steps should be added
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-2357
>                 URL: https://issues.jboss.org/browse/WFLY-2357
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Minor
>             Fix For: 8.0.0.CR1
>
>
> Currently only checks if the process type is a server which would add runtime steps if booted in admin only mode. This should use the {{OperationContext.isNormalServer()}} instead.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 11:54:02 2013
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Wed, 23 Oct 2013 11:54:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2330) Test set
 org.jboss.as.test.clustering.cluster.registry.RegistryTestCase fails with
 NPE
In-Reply-To: <JIRA.12508124.1382032998000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508124.1382032998000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508124.1382032998000.13604.1382543642116@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824355#comment-12824355 ] 

Paul Ferraro commented on WFLY-2330:
------------------------------------

That is weird.  It appears that a thread is attempting to connect the jgroups channel before it is completely built.  The former is triggered by the GlobalComponentRegistryService, the latter is triggered via the ChannelService.  The MSC dependency chain is supposed to ensure that this does not happen.
Suspiciously, the ChannelService dependency of an EmbeddedCacheManagerService (on which the GlobalComponentRegistryService depends) is optional.  Perhaps this allows the GlobalComponentRegistryService to start before the ChannelService is fully started?
                
> Test set org.jboss.as.test.clustering.cluster.registry.RegistryTestCase fails with NPE
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-2330
>                 URL: https://issues.jboss.org/browse/WFLY-2330
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.CR1
>         Environment: Oracle JDK 1.7.0_45 on Solaris SPARC on SunBlade 2000.
>            Reporter: Frank Langelage
>            Assignee: Paul Ferraro
>         Attachments: org.jboss.as.test.clustering.cluster.registry.RegistryTestCase-SYNC-tcp-output.txt, org.jboss.as.test.clustering.cluster.registry.RegistryTestCase-SYNC-tcp.txt, TEST-org.jboss.as.test.clustering.cluster.registry.RegistryTestCase-SYNC-tcp.xml
>
>
> Test org.jboss.as.test.clustering.cluster.registry.RegistryTestCase fails for me because of a NPE.
> See attached log files of this test.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 11:54:02 2013
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Wed, 23 Oct 2013 11:54:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2283) NPE in
 StatefulWithXPCFailoverTestCase(SYNC-tcp)
In-Reply-To: <JIRA.12502740.1381443705000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502740.1381443705000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502740.1381443705000.13607.1382543642279@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824356#comment-12824356 ] 

Paul Ferraro commented on WFLY-2283:
------------------------------------

See https://issues.jboss.org/browse/WFLY-2330
                
> NPE in StatefulWithXPCFailoverTestCase(SYNC-tcp)
> ------------------------------------------------
>
>                 Key: WFLY-2283
>                 URL: https://issues.jboss.org/browse/WFLY-2283
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.CR1
>         Environment: Solaris SPARC 10, Oracle JDK 1.7.0_40
>            Reporter: Frank Langelage
>            Assignee: Paul Ferraro
>         Attachments: org.jboss.as.test.clustering.cluster.ejb3.xpc.StatefulWithXPCFailoverTestCase-SYNC-tcp-output.txt, org.jboss.as.test.clustering.cluster.ejb3.xpc.StatefulWithXPCFailoverTestCase-SYNC-tcp.txt, TEST-org.jboss.as.test.clustering.cluster.ejb3.xpc.StatefulWithXPCFailoverTestCase-SYNC-tcp.xml
>
>
> Running the build of current master with complete testsuite fails with a NPE in clustering testsuite.
> See attached files.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 11:56:02 2013
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Wed, 23 Oct 2013 11:56:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2283) NPE in
 StatefulWithXPCFailoverTestCase(SYNC-tcp)
In-Reply-To: <JIRA.12502740.1381443705000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502740.1381443705000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502740.1381443705000.13613.1382543762286@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824356#comment-12824356 ] 

Paul Ferraro edited comment on WFLY-2283 at 10/23/13 11:54 AM:
---------------------------------------------------------------

See WFLY-2330
                
      was (Author: pferraro):
    See https://issues.jboss.org/browse/WFLY-2330
                  
> NPE in StatefulWithXPCFailoverTestCase(SYNC-tcp)
> ------------------------------------------------
>
>                 Key: WFLY-2283
>                 URL: https://issues.jboss.org/browse/WFLY-2283
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.CR1
>         Environment: Solaris SPARC 10, Oracle JDK 1.7.0_40
>            Reporter: Frank Langelage
>            Assignee: Paul Ferraro
>         Attachments: org.jboss.as.test.clustering.cluster.ejb3.xpc.StatefulWithXPCFailoverTestCase-SYNC-tcp-output.txt, org.jboss.as.test.clustering.cluster.ejb3.xpc.StatefulWithXPCFailoverTestCase-SYNC-tcp.txt, TEST-org.jboss.as.test.clustering.cluster.ejb3.xpc.StatefulWithXPCFailoverTestCase-SYNC-tcp.xml
>
>
> Running the build of current master with complete testsuite fails with a NPE in clustering testsuite.
> See attached files.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 12:00:03 2013
From: jira-events at lists.jboss.org (Alessio Soldano (JIRA))
Date: Wed, 23 Oct 2013 12:00:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2365) DuplicateServiceException
 when deploying ear containing jar and war with same name
In-Reply-To: <JIRA.12508602.1382543911942@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508602.1382543911942@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508602.1382543911942.13658.1382544003039@jira02.app.mwc.hst.phx2.redhat.com>

Alessio Soldano created WFLY-2365:
-------------------------------------

             Summary: DuplicateServiceException when deploying ear containing jar and war with same name
                 Key: WFLY-2365
                 URL: https://issues.jboss.org/browse/WFLY-2365
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: EE
            Reporter: Alessio Soldano
            Assignee: David Lloyd
             Fix For: 8.0.0.CR1


The following exception is thrown when deploying a EAR archive containing a war and jar with the same name (except for the file extension, of course).
See https://community.jboss.org/thread/233648

    2013-10-17 10:32:59,266 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.subunit."specj.ear"."specj.jar".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."specj.ear"."specj.jar".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of subdeployment "specj.jar" of deployment "specj.ear"  
      at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]  
      at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]  
      at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]  
      at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]  
      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]  
      at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]  
    Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.concurrent.ee.context.config.specj.specj is already registered  
      at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]  
      at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]  
      at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:767) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]  
      at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]  
      at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2384) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]  
      at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]  
      at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2384) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]  
      at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]  
      at org.jboss.as.ee.concurrent.deployers.EEConcurrentContextProcessor.setupConcurrentContext(EEConcurrentContextProcessor.java:110)  
      at org.jboss.as.ee.concurrent.deployers.EEConcurrentContextProcessor.processModuleDescription(EEConcurrentContextProcessor.java:71)  
      at org.jboss.as.ee.concurrent.deployers.EEConcurrentContextProcessor.deploy(EEConcurrentContextProcessor.java:54)  
      at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]  
      ... 5 more  
      
      
    2013-10-17 10:32:59,283 ERROR [org.jboss.as.controller.management-operation] (XNIO-1 task-3) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "specj.ear")]) - failure description: {  
        "JBAS014671: Failed services" => {"jboss.deployment.subunit.\"specj.ear\".\"specj.jar\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.subunit.\"specj.ear\".\"specj.jar\".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of subdeployment \"specj.jar\" of deployment \"specj.ear\"  
        Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.concurrent.ee.context.config.specj.specj is already registered"},  
        "JBAS014771: Services with missing/unavailable dependencies" => ["jboss.deployment.unit.\"specj.ear\".weld.weldClassIntrospector is missing [jboss.deployment.unit.\"specj.ear\".beanmanager]"]  
    }  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 12:02:02 2013
From: jira-events at lists.jboss.org (Alessio Soldano (JIRA))
Date: Wed, 23 Oct 2013 12:02:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2365) DuplicateServiceException
 when deploying ear containing jar and war with same name
In-Reply-To: <JIRA.12508602.1382543911000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508602.1382543911000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508602.1382543911000.13672.1382544122431@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824360#comment-12824360 ] 

Alessio Soldano commented on WFLY-2365:
---------------------------------------

Proposed fix: https://github.com/asoldano/wildfly/commit/8c2e7f368e877e7cea302b04c70a21a176cf0d84
                
> DuplicateServiceException when deploying ear containing jar and war with same name
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-2365
>                 URL: https://issues.jboss.org/browse/WFLY-2365
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EE
>            Reporter: Alessio Soldano
>            Assignee: David Lloyd
>             Fix For: 8.0.0.CR1
>
>
> The following exception is thrown when deploying a EAR archive containing a war and jar with the same name (except for the file extension, of course).
> See https://community.jboss.org/thread/233648
>     2013-10-17 10:32:59,266 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.subunit."specj.ear"."specj.jar".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."specj.ear"."specj.jar".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of subdeployment "specj.jar" of deployment "specj.ear"  
>       at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]  
>       at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]  
>       at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]  
>       at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]  
>       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]  
>       at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]  
>     Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.concurrent.ee.context.config.specj.specj is already registered  
>       at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]  
>       at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]  
>       at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:767) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]  
>       at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]  
>       at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2384) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]  
>       at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]  
>       at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2384) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]  
>       at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]  
>       at org.jboss.as.ee.concurrent.deployers.EEConcurrentContextProcessor.setupConcurrentContext(EEConcurrentContextProcessor.java:110)  
>       at org.jboss.as.ee.concurrent.deployers.EEConcurrentContextProcessor.processModuleDescription(EEConcurrentContextProcessor.java:71)  
>       at org.jboss.as.ee.concurrent.deployers.EEConcurrentContextProcessor.deploy(EEConcurrentContextProcessor.java:54)  
>       at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]  
>       ... 5 more  
>       
>       
>     2013-10-17 10:32:59,283 ERROR [org.jboss.as.controller.management-operation] (XNIO-1 task-3) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "specj.ear")]) - failure description: {  
>         "JBAS014671: Failed services" => {"jboss.deployment.subunit.\"specj.ear\".\"specj.jar\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.subunit.\"specj.ear\".\"specj.jar\".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of subdeployment \"specj.jar\" of deployment \"specj.ear\"  
>         Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.concurrent.ee.context.config.specj.specj is already registered"},  
>         "JBAS014771: Services with missing/unavailable dependencies" => ["jboss.deployment.unit.\"specj.ear\".weld.weldClassIntrospector is missing [jboss.deployment.unit.\"specj.ear\".beanmanager]"]  
>     }  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 12:08:01 2013
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Wed, 23 Oct 2013 12:08:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2213) UnsupportedOperationException
 in wildfly clustering web disrupts appliction access permanently
In-Reply-To: <JIRA.12502154.1380831891000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502154.1380831891000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502154.1380831891000.13695.1382544481989@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824364#comment-12824364 ] 

Paul Ferraro commented on WFLY-2213:
------------------------------------

Looking at the com.sun.faces.application.view.ViewScopeContextManager source, I see that it is attempting to remove session attributes in the sessionDestroyed callback.  While I don't see the point to removing session attributes on a session that is about to be destroyed, there is nothing in the spec that prohibits this, so perhaps these can become a no-op instead of throwing an UnsupportedOperationException.
                
> UnsupportedOperationException in wildfly clustering web disrupts appliction access permanently
> ----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2213
>                 URL: https://issues.jboss.org/browse/WFLY-2213
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering, Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Thomas Fr?hbeck
>            Assignee: Paul Ferraro
>              Labels: cluster, session, timeout, web
>
> a <distributable> struts application is working correctly, after session timeout an UnsupportedOperationException permanently prohibits access to the application.
> I cannot find any possibility to access the app again else than redeploy the application.
> 2013-10-03 14:55:48,311 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-10) ISPN000136: Execution error: org.infinispan.commons.CacheException: Caught exception [java.lang.Unsuppor
> tedOperationException] while invoking method [public void org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.removed(org.infinispan.notifications.cachelistener.event.CacheEntryRemovedEvent)] 
> on listener instance: org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager at 56af236c
>         at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation$1.run(AbstractListenerImpl.java:209)
>         at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:22)
>         at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation.invoke(AbstractListenerImpl.java:228)
>         at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation.invoke(AbstractListenerImpl.java:191)
>         at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyCacheEntryRemoved(CacheNotifierImpl.java:181)
>         at org.infinispan.commands.write.RemoveCommand.notify(RemoveCommand.java:98)
>         at org.infinispan.commands.write.RemoveCommand.performRemove(RemoveCommand.java:207)
>         at org.infinispan.commands.write.RemoveCommand.perform(RemoveCommand.java:90)
>         at org.infinispan.interceptors.CallInterceptor.handleDefault(CallInterceptor.java:91)
>         at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:37)
>         at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:51)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
>         at org.infinispan.interceptors.distribution.TxDistributionInterceptor.handleTxWriteCommand(TxDistributionInterceptor.java:268)
>         at org.infinispan.interceptors.distribution.TxDistributionInterceptor.visitRemoveCommand(TxDistributionInterceptor.java:77)
>         at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:51)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
>         at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
>         at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:37)
>         at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:51)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
>         at org.infinispan.interceptors.CacheLoaderInterceptor.visitRemoveCommand(CacheLoaderInterceptor.java:133)
>         at org.infinispan.interceptors.ActivationInterceptor.visitRemoveCommand(ActivationInterceptor.java:60)
>         at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:51)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
>         at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:292)
>         at org.infinispan.interceptors.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:372)
>         at org.infinispan.interceptors.EntryWrappingInterceptor.visitRemoveCommand(EntryWrappingInterceptor.java:205)
>         at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:51)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
>         at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitRemoveCommand(PessimisticLockingInterceptor.java:142)
>         at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:51)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
>         at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
>         at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:37)
>         at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:51)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
>         at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:247)
>         at org.infinispan.interceptors.TxInterceptor.visitRemoveCommand(TxInterceptor.java:188)
>         at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:51)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
>         at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
>         at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:37)
>         at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:51)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
>         at org.infinispan.statetransfer.StateTransferInterceptor.handleNonTxWriteCommand(StateTransferInterceptor.java:193)
>         at org.infinispan.statetransfer.StateTransferInterceptor.visitRemoveCommand(StateTransferInterceptor.java:143)
>         at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:51)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
>         at org.infinispan.interceptors.CacheMgmtInterceptor.visitRemoveCommand(CacheMgmtInterceptor.java:166)
>         at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:51)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
>         at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:106)
>         at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:70)
>         at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:37)
>         at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:51)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
>         at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:64)
>         at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:37)
>         at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:51)
>         at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:321)
>         at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1298)
>         at org.infinispan.CacheImpl.removeInternal(CacheImpl.java:400)
>         at org.infinispan.CacheImpl.remove(CacheImpl.java:393)
>         at org.infinispan.DecoratedCache.remove(DecoratedCache.java:406)
>         at org.infinispan.AbstractDelegatingCache.remove(AbstractDelegatingCache.java:281)
>         at org.wildfly.clustering.web.infinispan.Remover$RemoveOperation.invoke(Remover.java:50)
>         at org.jboss.as.clustering.infinispan.invoker.SimpleCacheInvoker.invoke(SimpleCacheInvoker.java:34)
>         at org.jboss.as.clustering.infinispan.invoker.RetryingCacheInvoker.invoke(RetryingCacheInvoker.java:82)
>         at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.remove(CoarseSessionFactory.java:116)
>         at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.remove(CoarseSessionFactory.java:54)
>         at org.wildfly.clustering.web.infinispan.session.InfinispanSession.invalidate(InfinispanSession.java:74)
>         at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:218)
>         at org.wildfly.clustering.web.undertow.session.SessionManagerAdapter.getSession(SessionManagerAdapter.java:124)
>         at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:674) [undertow-servlet-1.0.0.Beta15-SNAPSHOT.jar:1.0.0.Beta17-SNAPSHOT]
>         at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:688) [undertow-servlet-1.0.0.Beta15-SNAPSHOT.jar:1.0.0.Beta17-SNAPSHOT]
>         at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:505) [undertow-servlet-1.0.0.Beta15-SNAPSHOT.jar:1.0.0.Beta17-SNAPSHOT]
>         at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:255) [undertow-servlet-1.0.0.Beta15-SNAPSHOT.jar:1.0.0.Beta17-SNAPSHOT]
>         at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:202) [undertow-servlet-1.0.0.Beta15-SNAPSHOT.jar:1.0.0.Beta17-SNAPSHOT]
>         at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta15-SNAPSHOT.jar:1.0.0.Beta17-SNAPSHOT]
>         at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:136) [undertow-servlet-1.0.0.Beta15-SNAPSHOT.jar:1.0.0.Beta17-SNAPSHOT]
>         at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta15-SNAPSHOT.jar:1.0.0.Beta15-SNAPSHOT]
>         at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:614) [undertow-core-1.0.0.Beta15-SNAPSHOT.jar:1.0.0.Beta15-SNAPSHOT]
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
>         at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: java.lang.UnsupportedOperationException
>         at org.wildfly.clustering.web.session.ImmutableHttpSessionAdapter.removeAttribute(ImmutableHttpSessionAdapter.java:90)
>         at com.sun.faces.application.view.ViewScopeContextManager.sessionDestroyed(ViewScopeContextManager.java:298) [jsf-impl-2.2.3-jbossorg-1.jar:]
>         at com.sun.faces.application.view.ViewScopeManager.sessionDestroyed(ViewScopeManager.java:348) [jsf-impl-2.2.3-jbossorg-1.jar:]
>         at com.sun.faces.application.WebappLifecycleListener.sessionDestroyed(WebappLifecycleListener.java:176) [jsf-impl-2.2.3-jbossorg-1.jar:]
>         at com.sun.faces.config.ConfigureListener.sessionDestroyed(ConfigureListener.java:368) [jsf-impl-2.2.3-jbossorg-1.jar:]
>         at io.undertow.servlet.core.ApplicationListeners.sessionDestroyed(ApplicationListeners.java:264) [undertow-servlet-1.0.0.Beta15-SNAPSHOT.jar:1.0.0.Beta17-SNAPSHOT]
>         at org.wildfly.clustering.web.undertow.session.SessionContextAdapter$1.sessionDestroyed(SessionContextAdapter.java:60)
>         at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.removed(InfinispanSessionManager.java:297)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_25]
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_25]
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_25]
>         at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_25]
>         at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation$1.run(AbstractListenerImpl.java:205)
>         ... 84 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Wed Oct 23 12:10:02 2013
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Wed, 23 Oct 2013 12:10:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2213) UnsupportedOperationException
 in wildfly clustering web disrupts appliction access permanently
In-Reply-To: <JIRA.12502154.1380831891000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502154.1380831891000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502154.1380831891000.13706.1382544602218@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824364#comment-12824364 ] 

Paul Ferraro edited comment on WFLY-2213 at 10/23/13 12:10 PM:
---------------------------------------------------------------

Looking at the com.sun.faces.application.view.ViewScopeContextManager source, I see that it is attempting to remove session attributes in the sessionDestroyed callback.  While I don't quite see the point to removing session attributes on a session that is about to be destroyed, there is nothing in the spec that prohibits this, so perhaps these can become a no-op instead of throwing an UnsupportedOperationException.
                
      was (Author: pferraro):
    Looking at the com.sun.faces.application.view.ViewScopeContextManager source, I see that it is attempting to remove session attributes in the sessionDestroyed callback.  While I don't see the point to removing session attributes on a session that is about to be destroyed, there is nothing in the spec that prohibits this, so perhaps these can become a no-op instead of throwing an UnsupportedOperationException.
                  
> UnsupportedOperationException in wildfly clustering web disrupts appliction access permanently
> ----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2213
>                 URL: https://issues.jboss.org/browse/WFLY-2213
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering, Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Thomas Fr?hbeck
>            Assignee: Paul Ferraro
>              Labels: cluster, session, timeout, web
>
> a <distributable> struts application is working correctly, after session timeout an UnsupportedOperationException permanently prohibits access to the application.
> I cannot find any possibility to access the app again else than redeploy the application.
> 2013-10-03 14:55:48,311 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-10) ISPN000136: Execution error: org.infinispan.commons.CacheException: Caught exception [java.lang.Unsuppor
> tedOperationException] while invoking method [public void org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.removed(org.infinispan.notifications.cachelistener.event.CacheEntryRemovedEvent)] 
> on listener instance: org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager at 56af236c
>         at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation$1.run(AbstractListenerImpl.java:209)
>         at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:22)
>         at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation.invoke(AbstractListenerImpl.java:228)
>         at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation.invoke(AbstractListenerImpl.java:191)
>         at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyCacheEntryRemoved(CacheNotifierImpl.java:181)
>         at org.infinispan.commands.write.RemoveCommand.notify(RemoveCommand.java:98)
>         at org.infinispan.commands.write.RemoveCommand.performRemove(RemoveCommand.java:207)
>         at org.infinispan.commands.write.RemoveCommand.perform(RemoveCommand.java:90)
>         at org.infinispan.interceptors.CallInterceptor.handleDefault(CallInterceptor.java:91)
>         at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:37)
>         at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:51)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
>         at org.infinispan.interceptors.distribution.TxDistributionInterceptor.handleTxWriteCommand(TxDistributionInterceptor.java:268)
>         at org.infinispan.interceptors.distribution.TxDistributionInterceptor.visitRemoveCommand(TxDistributionInterceptor.java:77)
>         at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:51)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
>         at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
>         at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:37)
>         at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:51)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
>         at org.infinispan.interceptors.CacheLoaderInterceptor.visitRemoveCommand(CacheLoaderInterceptor.java:133)
>         at org.infinispan.interceptors.ActivationInterceptor.visitRemoveCommand(ActivationInterceptor.java:60)
>         at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:51)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
>         at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:292)
>         at org.infinispan.interceptors.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:372)
>         at org.infinispan.interceptors.EntryWrappingInterceptor.visitRemoveCommand(EntryWrappingInterceptor.java:205)
>         at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:51)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
>         at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitRemoveCommand(PessimisticLockingInterceptor.java:142)
>         at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:51)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
>         at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
>         at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:37)
>         at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:51)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
>         at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:247)
>         at org.infinispan.interceptors.TxInterceptor.visitRemoveCommand(TxInterceptor.java:188)
>         at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:51)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
>         at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
>         at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:37)
>         at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:51)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
>         at org.infinispan.statetransfer.StateTransferInterceptor.handleNonTxWriteCommand(StateTransferInterceptor.java:193)
>         at org.infinispan.statetransfer.StateTransferInterceptor.visitRemoveCommand(StateTransferInterceptor.java:143)
>         at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:51)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
>         at org.infinispan.interceptors.CacheMgmtInterceptor.visitRemoveCommand(CacheMgmtInterceptor.java:166)
>         at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:51)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
>         at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:106)
>         at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:70)
>         at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:37)
>         at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:51)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
>         at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:64)
>         at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:37)
>         at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:51)
>         at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:321)
>         at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1298)
>         at org.infinispan.CacheImpl.removeInternal(CacheImpl.java:400)
>         at org.infinispan.CacheImpl.remove(CacheImpl.java:393)
>         at org.infinispan.DecoratedCache.remove(DecoratedCache.java:406)
>         at org.infinispan.AbstractDelegatingCache.remove(AbstractDelegatingCache.java:281)
>         at org.wildfly.clustering.web.infinispan.Remover$RemoveOperation.invoke(Remover.java:50)
>         at org.jboss.as.clustering.infinispan.invoker.SimpleCacheInvoker.invoke(SimpleCacheInvoker.java:34)
>         at org.jboss.as.clustering.infinispan.invoker.RetryingCacheInvoker.invoke(RetryingCacheInvoker.java:82)
>         at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.remove(CoarseSessionFactory.java:116)
>         at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.remove(CoarseSessionFactory.java:54)
>         at org.wildfly.clustering.web.infinispan.session.InfinispanSession.invalidate(InfinispanSession.java:74)
>         at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:218)
>         at org.wildfly.clustering.web.undertow.session.SessionManagerAdapter.getSession(SessionManagerAdapter.java:124)
>         at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:674) [undertow-servlet-1.0.0.Beta15-SNAPSHOT.jar:1.0.0.Beta17-SNAPSHOT]
>         at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:688) [undertow-servlet-1.0.0.Beta15-SNAPSHOT.jar:1.0.0.Beta17-SNAPSHOT]
>         at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:505) [undertow-servlet-1.0.0.Beta15-SNAPSHOT.jar:1.0.0.Beta17-SNAPSHOT]
>         at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:255) [undertow-servlet-1.0.0.Beta15-SNAPSHOT.jar:1.0.0.Beta17-SNAPSHOT]
>         at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:202) [undertow-servlet-1.0.0.Beta15-SNAPSHOT.jar:1.0.0.Beta17-SNAPSHOT]
>         at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta15-SNAPSHOT.jar:1.0.0.Beta17-SNAPSHOT]
>         at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:136) [undertow-servlet-1.0.0.Beta15-SNAPSHOT.jar:1.0.0.Beta17-SNAPSHOT]
>         at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta15-SNAPSHOT.jar:1.0.0.Beta15-SNAPSHOT]
>         at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:614) [undertow-core-1.0.0.Beta15-SNAPSHOT.jar:1.0.0.Beta15-SNAPSHOT]
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
>         at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: java.lang.UnsupportedOperationException
>         at org.wildfly.clustering.web.session.ImmutableHttpSessionAdapter.removeAttribute(ImmutableHttpSessionAdapter.java:90)
>         at com.sun.faces.application.view.ViewScopeContextManager.sessionDestroyed(ViewScopeContextManager.java:298) [jsf-impl-2.2.3-jbossorg-1.jar:]
>         at com.sun.faces.application.view.ViewScopeManager.sessionDestroyed(ViewScopeManager.java:348) [jsf-impl-2.2.3-jbossorg-1.jar:]
>         at com.sun.faces.application.WebappLifecycleListener.sessionDestroyed(WebappLifecycleListener.java:176) [jsf-impl-2.2.3-jbossorg-1.jar:]
>         at com.sun.faces.config.ConfigureListener.sessionDestroyed(ConfigureListener.java:368) [jsf-impl-2.2.3-jbossorg-1.jar:]
>         at io.undertow.servlet.core.ApplicationListeners.sessionDestroyed(ApplicationListeners.java:264) [undertow-servlet-1.0.0.Beta15-SNAPSHOT.jar:1.0.0.Beta17-SNAPSHOT]
>         at org.wildfly.clustering.web.undertow.session.SessionContextAdapter$1.sessionDestroyed(SessionContextAdapter.java:60)
>         at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.removed(InfinispanSessionManager.java:297)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_25]
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_25]
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_25]
>         at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_25]
>         at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation$1.run(AbstractListenerImpl.java:205)
>         ... 84 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Wed Oct 23 12:38:02 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Wed, 23 Oct 2013 12:38:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-310) MVEL does not resolve
	class/memer aliases
In-Reply-To: <JIRA.12508608.1382546213143@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508608.1382546213143@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508608.1382546213143.13752.1382546282161@jira02.app.mwc.hst.phx2.redhat.com>

Davide Sottara created DROOLS-310:
-------------------------------------

             Summary: MVEL does not resolve class/memer aliases
                 Key: DROOLS-310
                 URL: https://issues.jboss.org/browse/DROOLS-310
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 5.5.0.Final
            Reporter: Davide Sottara
            Assignee: Mark Proctor


In the (unlikely) case a class should have the same name as one of its members:
myClass( myClass != null )
MyClass( MyClass != null )
constraints will not be resolved correctly by MVEL

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 12:38:02 2013
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Wed, 23 Oct 2013 12:38:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBASMP-54) Maven phase executing twice
In-Reply-To: <JIRA.12508235.1382212598000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508235.1382212598000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508235.1382212598000.13754.1382546282284@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBASMP-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins closed JBASMP-54.
-------------------------------

    Resolution: Rejected


This is the expected behavior. The {{@Execute}} is needed if the goal is run from without binding to a lifecycle phase. There was a {{deploy-only}} goal just recently added that does allow for this. It's merged upstream and the PR was https://github.com/jbossas/jboss-as-maven-plugin/pull/56. A release will hopefully be coming out soon with it.
                
> Maven phase executing twice
> ---------------------------
>
>                 Key: JBASMP-54
>                 URL: https://issues.jboss.org/browse/JBASMP-54
>             Project: JBoss AS Maven Plugins
>          Issue Type: Bug
>            Reporter: Dojcs?k S?ndor
>            Assignee: James Perkins
>
> I attached deploy goal to the package lifecycle phase.
> When I run mvn package it works fine, but I noticed that all phase executes twice.
> I removed @Execute(phase = LifecyclePhase.PACKAGE) line from Deploy.java. This solved the problem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Wed Oct 23 12:41:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 23 Oct 2013 12:41:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-281) Inconsistent use of
	genStringAsCharArray.
In-Reply-To: <JIRA.12508212.1382115445000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508212.1382115445000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508212.1382115445000.13759.1382546462119@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBWEB-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated JBWEB-281:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1022634

    
> Inconsistent use of genStringAsCharArray.
> -----------------------------------------
>
>                 Key: JBWEB-281
>                 URL: https://issues.jboss.org/browse/JBWEB-281
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-7.2.1.GA
>         Environment: All environments.
>            Reporter: Jeremy Whiting
>            Assignee: Remy Maucherat
>             Fix For: JBossWeb-7.3.0.GA
>
>
>  The JSP configuration property "genStringAsCharArray" is inconsistently named in jbossweb. This means the enabling of the feature for using char array type rather than String in generated Servlet code is not enabled.
>  This issue has been fixed upstream in the 7.0 branch of Tomcat hosted at Apache.
>  Can this patch be ported to jbossweb so that the 6.2 version of EAP includes this fix ?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 12:41:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 23 Oct 2013 12:41:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-281) Inconsistent use of
	genStringAsCharArray.
In-Reply-To: <JIRA.12508212.1382115445000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508212.1382115445000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508212.1382115445000.13762.1382546462397@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBWEB-281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824374#comment-12824374 ] 

RH Bugzilla Integration commented on JBWEB-281:
-----------------------------------------------

Jeremy Whiting <jwhiting at redhat.com> made a comment on [bug 1022634|https://bugzilla.redhat.com/show_bug.cgi?id=1022634]

Description of problem:
 The version of jbossweb 7.2.0.GA includes an inconsistent name for enabling char array type rather than using String.

Version-Release number of selected component (if applicable):
7.2.0.GA

How reproducible:
Always.

Steps to Reproduce:
1. Deploy a web application with a really simple Hello World JSP. Use a browser to request the JSP. Add server configuration to enable the use of char array.

<configuration>
   <jsp-configuration generate-strings-as-char-arrays="true"/>
</configuration>

2. Inspect generated source code for the Servlet (generated from the JSP).
Hint: see the code starting with out.write(

Actual results:
String type is used to hold the jsp character data used to generate a response.

Expected results:
char array is used to hold jsp character data used to generate a response.

Additional info:
                
> Inconsistent use of genStringAsCharArray.
> -----------------------------------------
>
>                 Key: JBWEB-281
>                 URL: https://issues.jboss.org/browse/JBWEB-281
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-7.2.1.GA
>         Environment: All environments.
>            Reporter: Jeremy Whiting
>            Assignee: Remy Maucherat
>             Fix For: JBossWeb-7.3.0.GA
>
>
>  The JSP configuration property "genStringAsCharArray" is inconsistently named in jbossweb. This means the enabling of the feature for using char array type rather than String in generated Servlet code is not enabled.
>  This issue has been fixed upstream in the 7.0 branch of Tomcat hosted at Apache.
>  Can this patch be ported to jbossweb so that the 6.2 version of EAP includes this fix ?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 12:54:02 2013
From: jira-events at lists.jboss.org (Stefan Guilhen (JIRA))
Date: Wed, 23 Oct 2013 12:54:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2366) Upgrade JacORB to
	2.3.2-jbossorg-5
In-Reply-To: <JIRA.12508609.1382547214167@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508609.1382547214167@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508609.1382547214167.13783.1382547242265@jira02.app.mwc.hst.phx2.redhat.com>

Stefan Guilhen created WFLY-2366:
------------------------------------

             Summary: Upgrade JacORB to 2.3.2-jbossorg-5
                 Key: WFLY-2366
                 URL: https://issues.jboss.org/browse/WFLY-2366
             Project: WildFly
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: IIOP
    Affects Versions: 8.0.0.Beta1
            Reporter: Stefan Guilhen
            Assignee: Stefan Guilhen
             Fix For: 8.0.0.CR1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 13:20:01 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Wed, 23 Oct 2013 13:20:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-311) Odd rules execution for
	expired events
In-Reply-To: <JIRA.12469400.1340610279000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12469400.1340610279000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12469400.1340610279000.13864.1382548801985@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Davide Sottara moved JBRULES-3558 to DROOLS-311:
------------------------------------------------

              Project: Drools  (was: JBRULES)
                  Key: DROOLS-311  (was: JBRULES-3558)
             Workflow: GIT Pull Request workflow   (was: classic default workflow)
    Affects Version/s: 6.0.0.CR5
                       5.5.0.Final
                           (was: 5.4.0.Final)
          Component/s:     (was: drools-core (fusion))

    
> Odd rules execution for expired events
> --------------------------------------
>
>                 Key: DROOLS-311
>                 URL: https://issues.jboss.org/browse/DROOLS-311
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.CR5, 5.5.0.Final
>         Environment: Windows Vista 64, JRE6 (x86)
>            Reporter: Karol Sobczak
>            Assignee: Mark Proctor
>            Priority: Blocker
>         Attachments: expiredrules.zip
>
>
> I have declared two types:
> declare Motion
>   @role( event )
>   @expires( 5s )
>   @timestamp( eventTime )
>   eventTime : long
> end
> declare Recording
> end
> and following rules:
> rule "StartRecording"
>   when
>     Motion()
>     not Recording()
>   then
>     insert(new Recording())
> end
> the problem is that when I put a lot of "Motions", sleep (so "Motions" become expired) and then do fireAllRules(), I got "StartRecording" executed multiple times (and not only once), event though "Recording" is inserted every time. 
> Another issue would be when instead of "StartRecording" rule I would have "StopRecording" rule:
> rule "StopRecording"
>   when
>     $m : Motion()
>     $r : Recording()
>   then
>     System.err.println("Recording: " + $r);
>     retract($r);
> end 
> then when there is a "Recording" fact inserted and multiple expired "Motions", the rule would be executed multiple times (when "Motions" expire) and $r would be null after the first "StopRecording" rule execution.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 13:26:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 23 Oct 2013 13:26:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-758) AdvancedLdapLoginModule
 doesn't isn't mapping nested roles
In-Reply-To: <JIRA.12508503.1382458902000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508503.1382458902000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508503.1382458902000.13886.1382549162034@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/SECURITY-758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824383#comment-12824383 ] 

RH Bugzilla Integration commented on SECURITY-758:
--------------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> made a comment on [bug 1017974|https://bugzilla.redhat.com/show_bug.cgi?id=1017974]

I now have a fix both for the issue reported in this Jira and for the previous issue that caused this regression.

I will proceed to tagging a release in the morning.
                
> AdvancedLdapLoginModule doesn't isn't mapping nested roles
> ----------------------------------------------------------
>
>                 Key: SECURITY-758
>                 URL: https://issues.jboss.org/browse/SECURITY-758
>             Project: PicketBox 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>    Affects Versions: Negotiation_2_2_5
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: Negotiation_2_2_6
>
>
> The recursive role searching is currently broken, believed to be caused by the introduction of quotes for a previous role searching fix.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 13:28:01 2013
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Wed, 23 Oct 2013 13:28:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBASMP-49) Give the ability to specify
 the jboss-as dist artifact coordinates to use
In-Reply-To: <JIRA.12496257.1373619778000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496257.1373619778000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496257.1373619778000.13890.1382549281880@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBASMP-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins updated JBASMP-49:
--------------------------------

    Fix Version/s: 7.5.Final

    
> Give the ability to specify the jboss-as dist artifact coordinates to use
> -------------------------------------------------------------------------
>
>                 Key: JBASMP-49
>                 URL: https://issues.jboss.org/browse/JBASMP-49
>             Project: JBoss AS Maven Plugins
>          Issue Type: Feature Request
>          Components: common, deploy
>            Reporter: Akram Ben Aissi
>            Assignee: James Perkins
>             Fix For: 7.5.Final
>
>
> For some reason, we want to be able to define a specific build to be used as the distribution of the AS Server.
> It would be nice if you can specify it, and not only the version but also the groupId and artifactId.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 13:40:02 2013
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Wed, 23 Oct 2013 13:40:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBASMP-55) Undeploy requires dependency
 resolution of artifacts in scope: runtime
In-Reply-To: <JIRA.12508236.1382213434000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508236.1382213434000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508236.1382213434000.13916.1382550002005@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBASMP-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins closed JBASMP-55.
-------------------------------

    Resolution: Duplicate Issue


This was already fixed in https://issues.jboss.org/browse/JBASMP-33
                
> Undeploy requires dependency resolution of artifacts in scope: runtime
> ----------------------------------------------------------------------
>
>                 Key: JBASMP-55
>                 URL: https://issues.jboss.org/browse/JBASMP-55
>             Project: JBoss AS Maven Plugins
>          Issue Type: Bug
>            Reporter: Dojcs?k S?ndor
>            Assignee: James Perkins
>
> I attached deploy goal to the clean lifecycle phase. I changed resolution scope in Undeploy.java to ResolutionScope.NONE. After I do not require mvn install for dependency resolution before I run clean.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Wed Oct 23 13:45:01 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Wed, 23 Oct 2013 13:45:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-311) Odd rules execution for
	expired events
In-Reply-To: <JIRA.12469400.1340610279000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12469400.1340610279000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12469400.1340610279000.13920.1382550301955@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Davide Sottara updated DROOLS-311:
----------------------------------

    Priority: Critical  (was: Blocker)

    
> Odd rules execution for expired events
> --------------------------------------
>
>                 Key: DROOLS-311
>                 URL: https://issues.jboss.org/browse/DROOLS-311
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.CR5
>         Environment: Windows Vista 64, JRE6 (x86)
>            Reporter: Karol Sobczak
>            Assignee: Mark Proctor
>            Priority: Critical
>         Attachments: expiredrules.zip
>
>
> I have declared two types:
> declare Motion
>   @role( event )
>   @expires( 5s )
>   @timestamp( eventTime )
>   eventTime : long
> end
> declare Recording
> end
> and following rules:
> rule "StartRecording"
>   when
>     Motion()
>     not Recording()
>   then
>     insert(new Recording())
> end
> the problem is that when I put a lot of "Motions", sleep (so "Motions" become expired) and then do fireAllRules(), I got "StartRecording" executed multiple times (and not only once), event though "Recording" is inserted every time. 
> Another issue would be when instead of "StartRecording" rule I would have "StopRecording" rule:
> rule "StopRecording"
>   when
>     $m : Motion()
>     $r : Recording()
>   then
>     System.err.println("Recording: " + $r);
>     retract($r);
> end 
> then when there is a "Recording" fact inserted and multiple expired "Motions", the rule would be executed multiple times (when "Motions" expire) and $r would be null after the first "StopRecording" rule execution.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 13:51:01 2013
From: jira-events at lists.jboss.org (Van Halbert (JIRA))
Date: Wed, 23 Oct 2013 13:51:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2367) Enable full property
 substitution in .cli file when using CLI to configure resource adapter
In-Reply-To: <JIRA.12508611.1382550569708@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508611.1382550569708@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508611.1382550569708.13930.1382550661960@jira02.app.mwc.hst.phx2.redhat.com>

Van Halbert created WFLY-2367:
---------------------------------

             Summary: Enable full property substitution in .cli file when using CLI to configure resource adapter
                 Key: WFLY-2367
                 URL: https://issues.jboss.org/browse/WFLY-2367
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: CLI
    Affects Versions: No Release
         Environment: EAP 6.1
            Reporter: Van Halbert
            Assignee: Alexey Loubyansky


Not sure if this has be rectified, but in EAP 6.1, when using the --properties option when calling jboss-cli.sh, not all properties defined in the .cli script are substituted for.  In this case, its the name of the resource adapter.  Example:

/subsystem=resource-adapters/resource-adapter=${ra.name}:add(module=org.jboss.teiid.resource-adapter.ldap)


The ${ra.name} is what is found in the standalone.xml after running the script.




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 14:26:02 2013
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 23 Oct 2013 14:26:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-311) Odd rules execution for
	expired events
In-Reply-To: <JIRA.12469400.1340610279000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12469400.1340610279000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12469400.1340610279000.14023.1382552761999@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824401#comment-12824401 ] 

Mark Proctor commented on DROOLS-311:
-------------------------------------

Any chance of a pull request?
http://docs.jboss.org/drools/release/5.5.0.Final/droolsjbpm-introduction-docs/html/gettingstarted.html

                
> Odd rules execution for expired events
> --------------------------------------
>
>                 Key: DROOLS-311
>                 URL: https://issues.jboss.org/browse/DROOLS-311
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.CR5
>         Environment: Windows Vista 64, JRE6 (x86)
>            Reporter: Karol Sobczak
>            Assignee: Mark Proctor
>            Priority: Critical
>         Attachments: expiredrules.zip
>
>
> I have declared two types:
> declare Motion
>   @role( event )
>   @expires( 5s )
>   @timestamp( eventTime )
>   eventTime : long
> end
> declare Recording
> end
> and following rules:
> rule "StartRecording"
>   when
>     Motion()
>     not Recording()
>   then
>     insert(new Recording())
> end
> the problem is that when I put a lot of "Motions", sleep (so "Motions" become expired) and then do fireAllRules(), I got "StartRecording" executed multiple times (and not only once), event though "Recording" is inserted every time. 
> Another issue would be when instead of "StartRecording" rule I would have "StopRecording" rule:
> rule "StopRecording"
>   when
>     $m : Motion()
>     $r : Recording()
>   then
>     System.err.println("Recording: " + $r);
>     retract($r);
> end 
> then when there is a "Recording" fact inserted and multiple expired "Motions", the rule would be executed multiple times (when "Motions" expire) and $r would be null after the first "StopRecording" rule execution.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 18:12:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 23 Oct 2013 18:12:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1740) ManagedSocketBinding class
 Impossible cast from java.net.InetAddress to java.net.InetSocketAddress
In-Reply-To: <JIRA.12497092.1374526330000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497092.1374526330000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497092.1374526330000.14524.1382566322284@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824463#comment-12824463 ] 

RH Bugzilla Integration commented on WFLY-1740:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1017747|https://bugzilla.redhat.com/show_bug.cgi?id=1017747] from POST to MODIFIED
                
> ManagedSocketBinding class Impossible cast from java.net.InetAddress to java.net.InetSocketAddress
> --------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1740
>                 URL: https://issues.jboss.org/browse/WFLY-1740
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Cheng Fang
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.CR1
>
>
> Reported by FindBugs:
> Impossible cast from java.net.InetAddress to java.net.InetSocketAddress
> Class:
> ManagedSocketBinding (org.jboss.as.network) line 55
> Method:
> getBindAddress (org.jboss.as.network.ManagedSocketBinding.getBindAddress())
> Priority:
> ? ? ?High Confidence Correctness
> ?
> Problem classification:
> Correctness (Bad casts of object references)
> BC_IMPOSSIBLE_CAST (Impossible cast)
> Notes:
> Actual type java.net.InetAddress
> Expected java.net.InetSocketAddress
> Return value of Class.cast(Object)
> FindBadCast2 (BC|NP)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Wed Oct 23 18:18:01 2013
From: jira-events at lists.jboss.org (Dmytro Zemnytskiy (JIRA))
Date: Wed, 23 Oct 2013 18:18:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2368) env-entry is not injected
 with @Resource annotation into CDI beans and JAX-RS resources
In-Reply-To: <JIRA.12508628.1382566566608@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508628.1382566566608@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508628.1382566566608.14546.1382566681908@jira02.app.mwc.hst.phx2.redhat.com>

Dmytro Zemnytskiy created WFLY-2368:
---------------------------------------

             Summary: env-entry is not injected with @Resource annotation into CDI beans and JAX-RS resources
                 Key: WFLY-2368
                 URL: https://issues.jboss.org/browse/WFLY-2368
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: CDI / Weld, REST
    Affects Versions: 8.0.0.Beta1
            Reporter: Dmytro Zemnytskiy
            Assignee: Stuart Douglas


I built simple web application to narrow down problem, consisting of war packaged in ear. It attempts to inject env-entry declared in web.xml using @Resource annotation into servlet, jax-rs resource and cdi managed bean.

For now only servlet is injected with env-entry properly. JAX-RS resource requires @ManagedBean annotation in order to work, but still does not work if it is listed explicitly in its Application, rather than autoscanned. CDI bean does not work yet. Same app without modifications work properly in Jboss AS 7.1

Below is example of CDI bean :

@Named
public class EnvEntryProducer {

	@Resource(name="demo") String env;
	
	@PostConstruct void logMe() {
		System.out.print("Env: " + env);
	}
	
	@Produces @Named("enventry") String getEnv() {
		return env;
	}

}

PostConstruct is not called yet as well

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 18:47:02 2013
From: jira-events at lists.jboss.org (Jonathan Fuerth (JIRA))
Date: Wed, 23 Oct 2013 18:47:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2369) request.getSession() throws
 IllegalStateException in distributable webapp
In-Reply-To: <JIRA.12508629.1382568353207@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508629.1382568353207@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508629.1382568353207.14567.1382568422401@jira02.app.mwc.hst.phx2.redhat.com>

Jonathan Fuerth created WFLY-2369:
-------------------------------------

             Summary: request.getSession() throws IllegalStateException in distributable webapp
                 Key: WFLY-2369
                 URL: https://issues.jboss.org/browse/WFLY-2369
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Web (Undertow)
    Affects Versions: 8.0.0.Beta1
            Reporter: Jonathan Fuerth
            Assignee: Stuart Douglas


A webapp I'm working is experiencing an IllegalStateException from calling the no-args request.getSession() method. The app has the <distributable/> marker in its web.xml. Taking <distributable/> out makes this issue go away.

Here is the stack trace:

{code}
17:29:05,728 DEBUG [org.uberfire.security.server.UberFireSecurityFilter] (default task-1) Authentication failure. Sending HTTP 401 response.: org.uberfire.security.auth.AuthenticationException: Validation fails.
	at org.uberfire.security.server.HttpSecurityManagerImpl.authenticate(HttpSecurityManagerImpl.java:220) [uberfire-security-server-0.4.0-SNAPSHOT.jar:0.4.0-SNAPSHOT]
	at org.uberfire.security.server.UberFireSecurityFilter.authenticate(UberFireSecurityFilter.java:333) [uberfire-security-server-0.4.0-SNAPSHOT.jar:0.4.0-SNAPSHOT]
	at org.uberfire.security.server.UberFireSecurityFilter.doFilter(UberFireSecurityFilter.java:277) [uberfire-security-server-0.4.0-SNAPSHOT.jar:0.4.0-SNAPSHOT]
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:59) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:218) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:619) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
Caused by: java.lang.IllegalStateException: UT000028: Session Q2FoOHf4ij6rcxT6v_9WsBOG already exists
	at org.wildfly.clustering.web.undertow.session.SessionManagerAdapter.createSession(SessionManagerAdapter.java:98)
	at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:680) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:340) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:345) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
	at org.uberfire.security.server.auth.HttpSessionStorage.load(HttpSessionStorage.java:36) [uberfire-security-server-0.4.0-SNAPSHOT.jar:0.4.0-SNAPSHOT]
	at org.uberfire.security.server.auth.HttpAuthenticationManager.authenticate(HttpAuthenticationManager.java:87) [uberfire-security-server-0.4.0-SNAPSHOT.jar:0.4.0-SNAPSHOT]
	at org.uberfire.security.server.HttpSecurityManagerImpl.authenticate(HttpSecurityManagerImpl.java:216) [uberfire-security-server-0.4.0-SNAPSHOT.jar:0.4.0-SNAPSHOT]
	... 25 more
{code}

In case you need to see it, the source code for the app that generated this trace is at https://github.com/jfuerth/errai-cdi-workbench/tree/11794888a873ae7182524d7978215a8e36002fa1

For completeness, the snapshot versions of its dependencies come from these git commits in the respective projects.

* Errai: bd130e238ed39a90d513e366336b0e20b8761146
* UberFire: 3756076ce8005ba1b0cbab6745b5d274c97d56d8

If you need to dig this deep, please ping me. I'm happy to help :)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 19:27:02 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Wed, 23 Oct 2013 19:27:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2212) Update JPA subsystem to use
 EE default datasource
In-Reply-To: <JIRA.12502126.1380810972000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502126.1380810972000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502126.1380810972000.14618.1382570822152@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow updated WFLY-2212:
-------------------------------

    Summary: Update JPA subsystem to use EE default datasource  (was: Update JPA subsystem to use default datasource)

    
> Update JPA subsystem to use EE default datasource
> -------------------------------------------------
>
>                 Key: WFLY-2212
>                 URL: https://issues.jboss.org/browse/WFLY-2212
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 8.0.0.CR1
>
>
> See comments in WFLY-2027 before starting the work on this jira...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 21:51:01 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 23 Oct 2013 21:51:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2370) NPE in
	DelegatingServerInventory
In-Reply-To: <JIRA.12508635.1382579451297@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508635.1382579451297@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508635.1382579451297.14657.1382579461965@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-2370:
--------------------------------------

             Summary: NPE in DelegatingServerInventory
                 Key: WFLY-2370
                 URL: https://issues.jboss.org/browse/WFLY-2370
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Domain Management
    Affects Versions: 8.0.0.Beta1
            Reporter: Brian Stansberry
            Assignee: Emanuel Muckenhuber
             Fix For: 8.0.0.CR1


http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=4738&tab=buildResultsDiv&buildTypeId=WF_MasterIgnoreWindowsDomainOnly

Test failure:

java.lang.AssertionError
    at org.junit.Assert.fail(Assert.java:86)
    at org.junit.Assert.assertTrue(Assert.java:41)
    at org.junit.Assert.assertTrue(Assert.java:52)
    at org.jboss.as.test.integration.domain.DomainControllerMigrationTestCase.testDCFailover(DomainControllerMigrationTestCase.java:223)

This appears in the log:

[Host Controller] 03:26:38,028 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014612: Operation ("read-attribute") failed - address: ([
[Host Controller]     ("host" => "failover-h1"),
[Host Controller]     ("server-config" => "failover-one")
[Host Controller] ]): java.lang.NullPointerException
[Host Controller]     at org.jboss.as.host.controller.DomainModelControllerService$DelegatingServerInventory.determineServerStatus(DomainModelControllerService.java:788)
[Host Controller]     at org.jboss.as.host.controller.operations.ServerStatusHandler.execute(ServerStatusHandler.java:66)
[Host Controller]     at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecuteInternal(ReadAttributeHandler.java:177) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
[Host Controller]     at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecute(ReadAttributeHandler.java:97) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
[Host Controller]     at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractMultiTargetHandler.execute(GlobalOperationHandlers.java:151) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 21:57:01 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 23 Oct 2013 21:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1105) Transaction 1.2 API -
	1.0.0.Final
In-Reply-To: <JIRA.12508636.1382579709381@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508636.1382579709381@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508636.1382579709381.14663.1382579821989@jira02.app.mwc.hst.phx2.redhat.com>

Jesper Pedersen created JBJCA-1105:
--------------------------------------

             Summary: Transaction 1.2 API - 1.0.0.Final
                 Key: JBJCA-1105
                 URL: https://issues.jboss.org/browse/JBJCA-1105
             Project: IronJacamar
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.1.1.Final




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 21:57:02 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 23 Oct 2013 21:57:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1106) Narayana 5.0.0.M8
In-Reply-To: <JIRA.12508637.1382579766322@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508637.1382579766322@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508637.1382579766322.14666.1382579822185@jira02.app.mwc.hst.phx2.redhat.com>

Jesper Pedersen created JBJCA-1106:
--------------------------------------

             Summary: Narayana 5.0.0.M8
                 Key: JBJCA-1106
                 URL: https://issues.jboss.org/browse/JBJCA-1106
             Project: IronJacamar
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.1.1.Final




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 22:54:01 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 23 Oct 2013 22:54:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-282) Lack of synchronization in
 org.apache.catalina.security.SecurityUtil
In-Reply-To: <JIRA.12508407.1382391772000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508407.1382391772000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508407.1382391772000.14705.1382583241949@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBWEB-282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated JBWEB-282:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1022634

    
> Lack of synchronization in org.apache.catalina.security.SecurityUtil
> --------------------------------------------------------------------
>
>                 Key: JBWEB-282
>                 URL: https://issues.jboss.org/browse/JBWEB-282
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-7.0.16.GA, JBossWeb-7.2.1.GA
>         Environment: -JBoss EAP 6.1.1
>            Reporter: Aaron Ogburn
>            Assignee: Remy Maucherat
>             Fix For: JBossWeb-7.3.0.GA
>
>
> The unsynchronized objectCache in org.apache.catalina.security.SecurityUtil can cause jboss start up and application deployments to spin on concurrent hash map access. Fixed already upstream in tomcat:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=50138
> objectCache now needs to be a ConcurrentHashMap given our multithreaded starts.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 22:59:01 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 23 Oct 2013 22:59:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-281) Inconsistent use of
	genStringAsCharArray.
In-Reply-To: <JIRA.12508212.1382115445000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508212.1382115445000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508212.1382115445000.14709.1382583541919@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBWEB-281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824506#comment-12824506 ] 

RH Bugzilla Integration commented on JBWEB-281:
-----------------------------------------------

Aaron Ogburn <aogburn at redhat.com> made a comment on [bug 1022634|https://bugzilla.redhat.com/show_bug.cgi?id=1022634]

This is needed to acquire the fix to JBWEB-282 as well to avoid potential hangs in concurrent deployments.
                
> Inconsistent use of genStringAsCharArray.
> -----------------------------------------
>
>                 Key: JBWEB-281
>                 URL: https://issues.jboss.org/browse/JBWEB-281
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-7.2.1.GA
>         Environment: All environments.
>            Reporter: Jeremy Whiting
>            Assignee: Remy Maucherat
>             Fix For: JBossWeb-7.3.0.GA
>
>
>  The JSP configuration property "genStringAsCharArray" is inconsistently named in jbossweb. This means the enabling of the feature for using char array type rather than String in generated Servlet code is not enabled.
>  This issue has been fixed upstream in the 7.0 branch of Tomcat hosted at Apache.
>  Can this patch be ported to jbossweb so that the 6.2 version of EAP includes this fix ?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 22:59:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 23 Oct 2013 22:59:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-282) Lack of synchronization in
 org.apache.catalina.security.SecurityUtil
In-Reply-To: <JIRA.12508407.1382391772000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508407.1382391772000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508407.1382391772000.14714.1382583542005@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBWEB-282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824507#comment-12824507 ] 

RH Bugzilla Integration commented on JBWEB-282:
-----------------------------------------------

Aaron Ogburn <aogburn at redhat.com> made a comment on [bug 1022634|https://bugzilla.redhat.com/show_bug.cgi?id=1022634]

This is needed to acquire the fix to JBWEB-282 as well to avoid potential hangs in concurrent deployments.
                
> Lack of synchronization in org.apache.catalina.security.SecurityUtil
> --------------------------------------------------------------------
>
>                 Key: JBWEB-282
>                 URL: https://issues.jboss.org/browse/JBWEB-282
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-7.0.16.GA, JBossWeb-7.2.1.GA
>         Environment: -JBoss EAP 6.1.1
>            Reporter: Aaron Ogburn
>            Assignee: Remy Maucherat
>             Fix For: JBossWeb-7.3.0.GA
>
>
> The unsynchronized objectCache in org.apache.catalina.security.SecurityUtil can cause jboss start up and application deployments to spin on concurrent hash map access. Fixed already upstream in tomcat:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=50138
> objectCache now needs to be a ConcurrentHashMap given our multithreaded starts.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 23 23:13:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 23 Oct 2013 23:13:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-282) Lack of synchronization in
 org.apache.catalina.security.SecurityUtil
In-Reply-To: <JIRA.12508407.1382391772000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508407.1382391772000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508407.1382391772000.14727.1382584382007@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBWEB-282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated JBWEB-282:
------------------------------------------

    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1022634, https://bugzilla.redhat.com/show_bug.cgi?id=1022777  (was: https://bugzilla.redhat.com/show_bug.cgi?id=1022634)

    
> Lack of synchronization in org.apache.catalina.security.SecurityUtil
> --------------------------------------------------------------------
>
>                 Key: JBWEB-282
>                 URL: https://issues.jboss.org/browse/JBWEB-282
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-7.0.16.GA, JBossWeb-7.2.1.GA
>         Environment: -JBoss EAP 6.1.1
>            Reporter: Aaron Ogburn
>            Assignee: Remy Maucherat
>             Fix For: JBossWeb-7.3.0.GA
>
>
> The unsynchronized objectCache in org.apache.catalina.security.SecurityUtil can cause jboss start up and application deployments to spin on concurrent hash map access. Fixed already upstream in tomcat:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=50138
> objectCache now needs to be a ConcurrentHashMap given our multithreaded starts.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 00:23:02 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 24 Oct 2013 00:23:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1107) Allow obtaining a connection
 during MARKED_FOR_ROLLBACK
In-Reply-To: <JIRA.12508643.1382588475670@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508643.1382588475670@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508643.1382588475670.14766.1382588582011@jira02.app.mwc.hst.phx2.redhat.com>

Jesper Pedersen created JBJCA-1107:
--------------------------------------

             Summary: Allow obtaining a connection during MARKED_FOR_ROLLBACK
                 Key: JBJCA-1107
                 URL: https://issues.jboss.org/browse/JBJCA-1107
             Project: IronJacamar
          Issue Type: Feature Request
          Components: Core
            Reporter: Scott Marlow
            Assignee: Jesper Pedersen
             Fix For: 1.1.1.Final


Provide a system property (ironjacamar.allow_marked_for_rollback) which allows the application to obtain a connection even when the transaction is in MARKED_FOR_ROLLBACK mode.

Keep the default as is, e.g. fail eagerly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 01:15:04 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 24 Oct 2013 01:15:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1949) SimpleScheduleSecondTestCase
	fails
In-Reply-To: <JIRA.12499327.1377447675000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499327.1377447675000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499327.1377447675000.14778.1382591704775@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFLY-1949:
------------------------------------

    Assignee: Stuart Douglas  (was: Ondrej Zizka)

    
> SimpleScheduleSecondTestCase fails
> ----------------------------------
>
>                 Key: WFLY-1949
>                 URL: https://issues.jboss.org/browse/WFLY-1949
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.Beta1
>         Environment: Solaris SPARC 10 6/06, Oracle JDK 1.7.0
>            Reporter: Frank Langelage
>            Assignee: Stuart Douglas
>         Attachments: org.jboss.as.test.integration.ejb.timerservice.schedule.SimpleScheduleSecondTestCase-output.txt, org.jboss.as.test.integration.ejb.timerservice.schedule.SimpleScheduleSecondTestCase.txt, TEST-org.jboss.as.test.integration.ejb.timerservice.schedule.SimpleScheduleSecondTestCase.xml
>
>
> org.jboss.as.test.integration.ejb.timerservice.schedule.SimpleScheduleSecondTestCase fails.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 01:15:04 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 24 Oct 2013 01:15:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1949) SimpleScheduleSecondTestCase
	fails
In-Reply-To: <JIRA.12499327.1377447675000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499327.1377447675000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499327.1377447675000.14781.1382591704914@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-1949.
----------------------------------

    Fix Version/s: 8.0.0.CR1
       Resolution: Done

    
> SimpleScheduleSecondTestCase fails
> ----------------------------------
>
>                 Key: WFLY-1949
>                 URL: https://issues.jboss.org/browse/WFLY-1949
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.Beta1
>         Environment: Solaris SPARC 10 6/06, Oracle JDK 1.7.0
>            Reporter: Frank Langelage
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.CR1
>
>         Attachments: org.jboss.as.test.integration.ejb.timerservice.schedule.SimpleScheduleSecondTestCase-output.txt, org.jboss.as.test.integration.ejb.timerservice.schedule.SimpleScheduleSecondTestCase.txt, TEST-org.jboss.as.test.integration.ejb.timerservice.schedule.SimpleScheduleSecondTestCase.xml
>
>
> org.jboss.as.test.integration.ejb.timerservice.schedule.SimpleScheduleSecondTestCase fails.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 01:37:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 24 Oct 2013 01:37:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1722) Improve performance of
	ENCRYPT protocol
In-Reply-To: <JIRA.12508426.1382426974000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508426.1382426974000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508426.1382426974000.14789.1382593022263@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824517#comment-12824517 ] 

Bela Ban edited comment on JGRP-1722 at 10/24/13 1:36 AM:
----------------------------------------------------------

See if ENCRYPT could be moved *down* the stack, e.g. just below the reliable retransmission protocols (NAKACK, UNICAST). I seem to recall though that ENCRYPT has a dep on GMS.
                
      was (Author: belaban):
    See if ENCRYPT could be moved *down* the stack, e.g. just below the reliable retransmission protocols ({{NAKACK}, {{UNICAST}}). I seem to recall though that ENCRYPT has a dep on GMS.
                  
> Improve performance of ENCRYPT protocol
> ---------------------------------------
>
>                 Key: JGRP-1722
>                 URL: https://issues.jboss.org/browse/JGRP-1722
>             Project: JGroups
>          Issue Type: Enhancement
>    Affects Versions: 3.4
>            Reporter: Martin Gencur
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> A stress tests with the following setup showed that performance (reads and writes/sec) is halved when ENCRYPT protocol is enabled:
> Infinispan had distributed sync cache with 2 owners on 4 nodes, no transactions. The stress test used 10 threads on each node accessing 1024 byte entries, no conflicts on keys, 20 % writes, 80 % reads. 
> It would be great if we could improve the performance of ENCRYPT protocol.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 01:37:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 24 Oct 2013 01:37:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1722) Improve performance of
	ENCRYPT protocol
In-Reply-To: <JIRA.12508426.1382426974000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508426.1382426974000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508426.1382426974000.14786.1382593022102@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824517#comment-12824517 ] 

Bela Ban commented on JGRP-1722:
--------------------------------

See if ENCRYPT could be moved *down* the stack, e.g. just below the reliable retransmission protocols ({{NAKACK}, {{UNICAST}}). I seem to recall though that ENCRYPT has a dep on GMS.
                
> Improve performance of ENCRYPT protocol
> ---------------------------------------
>
>                 Key: JGRP-1722
>                 URL: https://issues.jboss.org/browse/JGRP-1722
>             Project: JGroups
>          Issue Type: Enhancement
>    Affects Versions: 3.4
>            Reporter: Martin Gencur
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> A stress tests with the following setup showed that performance (reads and writes/sec) is halved when ENCRYPT protocol is enabled:
> Infinispan had distributed sync cache with 2 owners on 4 nodes, no transactions. The stress test used 10 threads on each node accessing 1024 byte entries, no conflicts on keys, 20 % writes, 80 % reads. 
> It would be great if we could improve the performance of ENCRYPT protocol.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 02:23:02 2013
From: jira-events at lists.jboss.org (Martin Gencur (JIRA))
Date: Thu, 24 Oct 2013 02:23:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1722) Improve performance of
	ENCRYPT protocol
In-Reply-To: <JIRA.12508426.1382426974000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508426.1382426974000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508426.1382426974000.14800.1382595782044@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824521#comment-12824521 ] 

Martin Gencur commented on JGRP-1722:
-------------------------------------

The replication works also with ENCRYPT placed under NAKACK while AUTH is placed under GMS. My functional test for the ISPN server passes with this configuration. Data is successfully replicated.
                
> Improve performance of ENCRYPT protocol
> ---------------------------------------
>
>                 Key: JGRP-1722
>                 URL: https://issues.jboss.org/browse/JGRP-1722
>             Project: JGroups
>          Issue Type: Enhancement
>    Affects Versions: 3.4
>            Reporter: Martin Gencur
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> A stress tests with the following setup showed that performance (reads and writes/sec) is halved when ENCRYPT protocol is enabled:
> Infinispan had distributed sync cache with 2 owners on 4 nodes, no transactions. The stress test used 10 threads on each node accessing 1024 byte entries, no conflicts on keys, 20 % writes, 80 % reads. 
> It would be great if we could improve the performance of ENCRYPT protocol.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 02:27:01 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 24 Oct 2013 02:27:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-140) KIE module injection through
 CDI does not work in container
In-Reply-To: <JIRA.12491833.1368620305000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12491833.1368620305000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12491833.1368620305000.14806.1382596021910@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824523#comment-12824523 ] 

RH Bugzilla Integration commented on DROOLS-140:
------------------------------------------------

Kanchan Desai <kadesai at redhat.com> made a comment on [bug 955193|https://bugzilla.redhat.com/show_bug.cgi?id=955193]

Hi Marek,

Doc Text has been added. Can you please review the CCFR.
                
> KIE module injection through CDI does not work in container
> -----------------------------------------------------------
>
>                 Key: DROOLS-140
>                 URL: https://issues.jboss.org/browse/DROOLS-140
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>             Fix For: 6.0.0.CR1
>
>
> Description of problem:
> Injection of KIE module through CDI fails on JBoss EAP 6.0/6.1 due to wrong processing of resource URI when loading pom.properties in ClasspathKieProject.
> Version-Release number of selected component (if applicable):
> BRMS 6.0.0.Beta1
> EAP 6.0, 6.1.ER4
> How reproducible:
> Deploy the attached reproducer WAR. Deployment fails, server.log contains the following error (see attachment for all errors in log):
> 15:40:29,923 INFO  [stdout] (MSC service thread 1-2) kmodules: vfs:/content/kie-cdi-war-web-app-1.0.0-SNAPSHOT.war/WEB-INF/lib/kie-cdi-war-kie-module-1.0.0-SNAPSHOT.jar/META-INF/kmodule.xml
> 15:40:29,939 ERROR [org.drools.compiler.kie.builder.impl.ClasspathKieProject] (MSC service thread 1-2) Unable to load pom.properties from/content/kie-cdi-war-web-app-1.0.0-SNAPSHOT.war/WEB-INF/lib/kie-cdi-war-kie-module-1.0.0-SNAPSHOT.jar as jarPath cannot be found
> /content/kie-cdi-war-web-app-1.0.0-SNAPSHOT.war/WEB-INF/lib/kie-cdi-war-kie-module-1.0.0-SNAPSHOT.jar
> The first log line shows that ClasspathKieProject located kmodule.xml at URL starting with protocol 'vfs:'. Later, in method fixURLFromKProjectPath, the protocol prefix is removed, leading to URL /content/kie-cdi-war-web-app-1.0.0-SNAPSHOT.war/WEB-INF/lib/kie-cdi-war-kie-module-1.0.0-SNAPSHOT.jar which now references absolute path which is wrong.
> Steps to Reproduce:
> 1. Deploy attached reproducer WAR on EAP 6.
> 2. Watch server.log for deployment errors.
>   
> Actual results:
> Deployment fails due to failed injection.
> Expected results:
> Application deploys successfully and writes INFO message into server.log.
> Additional info:
> This issue blocks further testing if KIE module injection through CDI. It also renders the CDI feature unusable in real environment (e.g. some web or EJB container with CDI).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 02:44:01 2013
From: jira-events at lists.jboss.org (Petr Kremensky (JIRA))
Date: Thu, 24 Oct 2013 02:44:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2371)
 SizeRotatingHandlerTestCase.rotationTest fails with "the file is bigger
 than allowed size"
In-Reply-To: <JIRA.12508645.1382597019572@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508645.1382597019572@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508645.1382597019572.14820.1382597041939@jira02.app.mwc.hst.phx2.redhat.com>

Petr Kremensky created WFLY-2371:
------------------------------------

             Summary: SizeRotatingHandlerTestCase.rotationTest fails with "the file is bigger than allowed size"
                 Key: WFLY-2371
                 URL: https://issues.jboss.org/browse/WFLY-2371
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Test Suite
    Affects Versions: 8.0.0.Beta1
            Reporter: Petr Kremensky
            Assignee: Petr Kremensky


The test org.jboss.as.test.integration.logging.operations.SizeRotatingHandlerTestCase.rotationTest consistently fails with:

java.lang.AssertionError: This file is bigger than allowed rotate-size: size-rotating-reload-rotationTest.log.1

Link to job:
https://jenkins.mw.lab.eng.bos.redhat.com/job/eap-6x-manu-acceptance-as-ts-RHEL6_x86-oracleJDK6-srczip/25/testReport/junit/org.jboss.as.test.integration.logging.operations/SizeRotatingHandlerTestCase/rotationTest/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 02:46:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 24 Oct 2013 02:46:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2371)
 SizeRotatingHandlerTestCase.rotationTest fails with "the file is bigger
 than allowed size"
In-Reply-To: <JIRA.12508645.1382597019000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508645.1382597019000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508645.1382597019000.14823.1382597162387@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2371:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1020339

    
> SizeRotatingHandlerTestCase.rotationTest fails with "the file is bigger than allowed size"
> ------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2371
>                 URL: https://issues.jboss.org/browse/WFLY-2371
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Petr Kremensky
>            Assignee: Petr Kremensky
>
> The test org.jboss.as.test.integration.logging.operations.SizeRotatingHandlerTestCase.rotationTest consistently fails with:
> java.lang.AssertionError: This file is bigger than allowed rotate-size: size-rotating-reload-rotationTest.log.1
> Link to job:
> https://jenkins.mw.lab.eng.bos.redhat.com/job/eap-6x-manu-acceptance-as-ts-RHEL6_x86-oracleJDK6-srczip/25/testReport/junit/org.jboss.as.test.integration.logging.operations/SizeRotatingHandlerTestCase/rotationTest/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 02:52:02 2013
From: jira-events at lists.jboss.org (Vladimir Rastseluev (JIRA))
Date: Thu, 24 Oct 2013 02:52:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-988) Core test suite
In-Reply-To: <JIRA.12485341.1361438822000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485341.1361438822000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485341.1361438822000.14841.1382597522178@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vladimir Rastseluev resolved JBJCA-988.
---------------------------------------

    Resolution: Done

    
> Core test suite
> ---------------
>
>                 Key: JBJCA-988
>                 URL: https://issues.jboss.org/browse/JBJCA-988
>             Project: IronJacamar
>          Issue Type: Task
>          Components: Core
>    Affects Versions: 1.1.0.Beta3
>            Reporter: Vladimir Rastseluev
>            Assignee: Vladimir Rastseluev
>
> Improve the subject

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 03:26:01 2013
From: jira-events at lists.jboss.org (Petr Kremensky (JIRA))
Date: Thu, 24 Oct 2013 03:26:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2371)
 SizeRotatingHandlerTestCase.rotationTest fails with "the file is bigger
 than allowed size"
In-Reply-To: <JIRA.12508645.1382597019000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508645.1382597019000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508645.1382597019000.14856.1382599561918@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824526#comment-12824526 ] 

Petr Kremensky commented on WFLY-2371:
--------------------------------------

PR sent: https://github.com/wildfly/wildfly/pull/5340
                
> SizeRotatingHandlerTestCase.rotationTest fails with "the file is bigger than allowed size"
> ------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2371
>                 URL: https://issues.jboss.org/browse/WFLY-2371
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Petr Kremensky
>            Assignee: Petr Kremensky
>
> The test org.jboss.as.test.integration.logging.operations.SizeRotatingHandlerTestCase.rotationTest consistently fails with:
> java.lang.AssertionError: This file is bigger than allowed rotate-size: size-rotating-reload-rotationTest.log.1
> Link to job:
> https://jenkins.mw.lab.eng.bos.redhat.com/job/eap-6x-manu-acceptance-as-ts-RHEL6_x86-oracleJDK6-srczip/25/testReport/junit/org.jboss.as.test.integration.logging.operations/SizeRotatingHandlerTestCase/rotationTest/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 04:06:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 24 Oct 2013 04:06:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2371)
 SizeRotatingHandlerTestCase.rotationTest fails with "the file is bigger
 than allowed size"
In-Reply-To: <JIRA.12508645.1382597019000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508645.1382597019000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508645.1382597019000.14920.1382601962215@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824533#comment-12824533 ] 

RH Bugzilla Integration commented on WFLY-2371:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> made a comment on [bug 1020339|https://bugzilla.redhat.com/show_bug.cgi?id=1020339]

PR sent: https://github.com/jbossas/jboss-eap/pull/605
                
> SizeRotatingHandlerTestCase.rotationTest fails with "the file is bigger than allowed size"
> ------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2371
>                 URL: https://issues.jboss.org/browse/WFLY-2371
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Petr Kremensky
>            Assignee: Petr Kremensky
>
> The test org.jboss.as.test.integration.logging.operations.SizeRotatingHandlerTestCase.rotationTest consistently fails with:
> java.lang.AssertionError: This file is bigger than allowed rotate-size: size-rotating-reload-rotationTest.log.1
> Link to job:
> https://jenkins.mw.lab.eng.bos.redhat.com/job/eap-6x-manu-acceptance-as-ts-RHEL6_x86-oracleJDK6-srczip/25/testReport/junit/org.jboss.as.test.integration.logging.operations/SizeRotatingHandlerTestCase/rotationTest/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 04:12:02 2013
From: jira-events at lists.jboss.org (hui gao (JIRA))
Date: Thu, 24 Oct 2013 04:12:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2125) wildfly8 can't identify
	port-offset
In-Reply-To: <JIRA.12501168.1379906107000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501168.1379906107000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501168.1379906107000.14942.1382602322273@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

hui gao reopened WFLY-2125:
---------------------------



I'm sorry,the problem is not been resolved.
I tried the new version,but it didn't work.
                
> wildfly8 can't identify port-offset
> -----------------------------------
>
>                 Key: WFLY-2125
>                 URL: https://issues.jboss.org/browse/WFLY-2125
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Alpha4
>         Environment: wildfly-8.0.0.Alpha4.tar.gz
> jdk-7u25-linux-i586.rpm
> mod_cluster-1.2.0.Final-linux2-x64-ssl.tar.gz
>            Reporter: hui gao
>            Assignee: Tomaz Cerar
>             Fix For: 8.0.0.Beta1
>
>
> I installed wildfly8 and mod_cluster  reference steps of https://docs.jboss.org/author/display/AS72/AS7+Cluster+Howto
> The cluster contains four servers,start up with domain mode:
> 10.19.222.52:server1/server2
> 10.19.222.53:server3/server4
> 10.19.222.50:apache
> But it only detects server1 and server3 which the port is 8009.
> The port-offset is 100,it can't identify the other port(8109) for server2 and server4.
> Search errorlog of Apache ,the proxy:AJP always acquired connection through initial AJP port(8009) defined in domain.xml.
> [Fri Sep 13 21:07:40 2013] [debug] mod_proxy_cluster.c(773): ajp_cping_cpong: Done
> [Fri Sep 13 21:07:40 2013] [debug] proxy_util.c(2029): proxy: ajp: has released connection for (10.19.222.52)
> [Fri Sep 13 21:07:43 2013] [debug] proxy_util.c(2011): proxy: ajp: has acquired connection for (10.19.222.53)
> [Fri Sep 13 21:07:43 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://10.19.222.53:8009/ to 10.19.222.53:8009
> [Fri Sep 13 21:07:43 2013] [debug] proxy_util.c(2193): proxy: connected ajp://10.19.222.53:8009/ to 10.19.222.53:8009
> [Fri Sep 13 21:07:43 2013] [debug] mod_proxy_cluster.c(773): ajp_cping_cpong: Done
> [Fri Sep 13 21:07:43 2013] [debug] proxy_util.c(2029): proxy: ajp: has released connection for (10.19.222.53)
> [Fri Sep 13 21:07:45 2013] [debug] proxy_util.c(2011): proxy: ajp: has acquired connection for (10.19.222.52)
> [Fri Sep 13 21:07:45 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://10.19.222.52:8009/ to 10.19.222.52:8009
> [Fri Sep 13 21:07:45 2013] [debug] proxy_util.c(2193): proxy: connected ajp://10.19.222.52:8009/ to 10.19.222.52:8009
> [Fri Sep 13 21:07:45 2013] [debug] mod_proxy_cluster.c(773): ajp_cping_cpong: Done
> [Fri Sep 13 21:07:45 2013] [debug] proxy_util.c(2029): proxy: ajp: has released connection for (10.19.222.52)
> [Fri Sep 13 21:07:46 2013] [debug] mod_manager.c(1667): manager_trans STATUS (/)
> [Fri Sep 13 21:07:46 2013] [debug] mod_manager.c(2323): manager_handler STATUS (/) processing: "JVMRoute=2644d861-0ead-352c-ba1e-619f1e1f25e8&Load=100"
> [Fri Sep 13 21:07:46 2013] [debug] mod_manager.c(1404): Processing STATUS
> [Fri Sep 13 21:07:46 2013] [debug] proxy_util.c(2011): proxy: ajp: has acquired connection for (10.19.222.53)
> [Fri Sep 13 21:07:46 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://10.19.222.53:8009/ to 10.19.222.53:8009
> [Fri Sep 13 21:07:46 2013] [debug] proxy_util.c(2193): proxy: connected ajp://10.19.222.53:8009/ to 10.19.222.53:8009
> [Fri Sep 13 21:07:46 2013] [debug] mod_proxy_cluster.c(773): ajp_cping_cpong: Done
> [Fri Sep 13 21:07:46 2013] [debug] proxy_util.c(2029): proxy: ajp: has released connection for (10.19.222.53)
> [Fri Sep 13 21:07:46 2013] [debug] mod_manager.c(2366): manager_handler STATUS  OK
> [Fri Sep 13 21:07:47 2013] [debug] mod_manager.c(1667): manager_trans STATUS (/)
> [Fri Sep 13 21:07:47 2013] [debug] mod_manager.c(2323): manager_handler STATUS (/) processing: "JVMRoute=ea81701b-f847-34a8-9534-0ac5c489af90&Load=100"
> [Fri Sep 13 21:07:47 2013] [debug] mod_manager.c(1404): Processing STATUS
> [Fri Sep 13 21:07:47 2013] [debug] proxy_util.c(2011): proxy: ajp: has acquired connection for (10.19.222.52)
> [Fri Sep 13 21:07:47 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://10.19.222.52:8009/ to 10.19.222.52:8009
> [Fri Sep 13 21:07:47 2013] [debug] proxy_util.c(2193): proxy: connected ajp://10.19.222.52:8009/ to 10.19.222.52:8009

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 04:16:02 2013
From: jira-events at lists.jboss.org (hui gao (JIRA))
Date: Thu, 24 Oct 2013 04:16:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2125) wildfly8 can't identify
	port-offset
In-Reply-To: <JIRA.12501168.1379906107000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501168.1379906107000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501168.1379906107000.14956.1382602562990@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824543#comment-12824543 ] 

hui gao commented on WFLY-2125:
-------------------------------

I have attached logs https://community.jboss.org/message/837494#837494.
                
> wildfly8 can't identify port-offset
> -----------------------------------
>
>                 Key: WFLY-2125
>                 URL: https://issues.jboss.org/browse/WFLY-2125
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Alpha4
>         Environment: wildfly-8.0.0.Alpha4.tar.gz
> jdk-7u25-linux-i586.rpm
> mod_cluster-1.2.0.Final-linux2-x64-ssl.tar.gz
>            Reporter: hui gao
>            Assignee: Tomaz Cerar
>             Fix For: 8.0.0.Beta1
>
>
> I installed wildfly8 and mod_cluster  reference steps of https://docs.jboss.org/author/display/AS72/AS7+Cluster+Howto
> The cluster contains four servers,start up with domain mode:
> 10.19.222.52:server1/server2
> 10.19.222.53:server3/server4
> 10.19.222.50:apache
> But it only detects server1 and server3 which the port is 8009.
> The port-offset is 100,it can't identify the other port(8109) for server2 and server4.
> Search errorlog of Apache ,the proxy:AJP always acquired connection through initial AJP port(8009) defined in domain.xml.
> [Fri Sep 13 21:07:40 2013] [debug] mod_proxy_cluster.c(773): ajp_cping_cpong: Done
> [Fri Sep 13 21:07:40 2013] [debug] proxy_util.c(2029): proxy: ajp: has released connection for (10.19.222.52)
> [Fri Sep 13 21:07:43 2013] [debug] proxy_util.c(2011): proxy: ajp: has acquired connection for (10.19.222.53)
> [Fri Sep 13 21:07:43 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://10.19.222.53:8009/ to 10.19.222.53:8009
> [Fri Sep 13 21:07:43 2013] [debug] proxy_util.c(2193): proxy: connected ajp://10.19.222.53:8009/ to 10.19.222.53:8009
> [Fri Sep 13 21:07:43 2013] [debug] mod_proxy_cluster.c(773): ajp_cping_cpong: Done
> [Fri Sep 13 21:07:43 2013] [debug] proxy_util.c(2029): proxy: ajp: has released connection for (10.19.222.53)
> [Fri Sep 13 21:07:45 2013] [debug] proxy_util.c(2011): proxy: ajp: has acquired connection for (10.19.222.52)
> [Fri Sep 13 21:07:45 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://10.19.222.52:8009/ to 10.19.222.52:8009
> [Fri Sep 13 21:07:45 2013] [debug] proxy_util.c(2193): proxy: connected ajp://10.19.222.52:8009/ to 10.19.222.52:8009
> [Fri Sep 13 21:07:45 2013] [debug] mod_proxy_cluster.c(773): ajp_cping_cpong: Done
> [Fri Sep 13 21:07:45 2013] [debug] proxy_util.c(2029): proxy: ajp: has released connection for (10.19.222.52)
> [Fri Sep 13 21:07:46 2013] [debug] mod_manager.c(1667): manager_trans STATUS (/)
> [Fri Sep 13 21:07:46 2013] [debug] mod_manager.c(2323): manager_handler STATUS (/) processing: "JVMRoute=2644d861-0ead-352c-ba1e-619f1e1f25e8&Load=100"
> [Fri Sep 13 21:07:46 2013] [debug] mod_manager.c(1404): Processing STATUS
> [Fri Sep 13 21:07:46 2013] [debug] proxy_util.c(2011): proxy: ajp: has acquired connection for (10.19.222.53)
> [Fri Sep 13 21:07:46 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://10.19.222.53:8009/ to 10.19.222.53:8009
> [Fri Sep 13 21:07:46 2013] [debug] proxy_util.c(2193): proxy: connected ajp://10.19.222.53:8009/ to 10.19.222.53:8009
> [Fri Sep 13 21:07:46 2013] [debug] mod_proxy_cluster.c(773): ajp_cping_cpong: Done
> [Fri Sep 13 21:07:46 2013] [debug] proxy_util.c(2029): proxy: ajp: has released connection for (10.19.222.53)
> [Fri Sep 13 21:07:46 2013] [debug] mod_manager.c(2366): manager_handler STATUS  OK
> [Fri Sep 13 21:07:47 2013] [debug] mod_manager.c(1667): manager_trans STATUS (/)
> [Fri Sep 13 21:07:47 2013] [debug] mod_manager.c(2323): manager_handler STATUS (/) processing: "JVMRoute=ea81701b-f847-34a8-9534-0ac5c489af90&Load=100"
> [Fri Sep 13 21:07:47 2013] [debug] mod_manager.c(1404): Processing STATUS
> [Fri Sep 13 21:07:47 2013] [debug] proxy_util.c(2011): proxy: ajp: has acquired connection for (10.19.222.52)
> [Fri Sep 13 21:07:47 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://10.19.222.52:8009/ to 10.19.222.52:8009
> [Fri Sep 13 21:07:47 2013] [debug] proxy_util.c(2193): proxy: connected ajp://10.19.222.52:8009/ to 10.19.222.52:8009

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 04:18:02 2013
From: jira-events at lists.jboss.org (Tomas Remes (JIRA))
Date: Thu, 24 Oct 2013 04:18:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-131) Seam2Processor will not have
 permissions to its added resource loader
In-Reply-To: <JIRA.12486803.1362759602000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12486803.1362759602000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12486803.1362759602000.14962.1382602682032@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824544#comment-12824544 ] 

Tomas Remes commented on WFLY-131:
----------------------------------

I've tried this https://github.com/tremes/wildfly/compare/attempts?expand=1 and deployment seems to work fine, however there's need to release some new version of jboss-seam-int (current revision looks ok) artifact. I asked Ales, because I don't have permissions to do it. So will see...
                
> Seam2Processor will not have permissions to its added resource loader
> ---------------------------------------------------------------------
>
>                 Key: WFLY-131
>                 URL: https://issues.jboss.org/browse/WFLY-131
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server
>            Reporter: David Lloyd
>            Assignee: Ales Justin
>              Labels: security
>             Fix For: 8.0.0.CR1
>
>
> The {{Seam2Processor}} class adds a {{VFSResourceLoader}} to the deployment in order to copy certain Seam classes into it.  The problem is that the {{VFSResourceLoader}} will fail at runtime with a permission exception because there is no corresponding {{VirtualFilePermission}}.
> For this type of resource loader, it is better just to add the JAR using {{JarFileResourceLoader}}, which does not require permissions at load time and is much faster anyway.
> If you must use {{VFSResourceLoader}}, then instead of creating and adding the resource loader yourself, add a {{ResourceRoot}} to the deployment context.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 04:26:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 24 Oct 2013 04:26:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1722) Improve performance of
	ENCRYPT protocol
In-Reply-To: <JIRA.12508426.1382426974000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508426.1382426974000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508426.1382426974000.14981.1382603162682@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824547#comment-12824547 ] 

Bela Ban commented on JGRP-1722:
--------------------------------

I think this is only true if (a) there is no communication between joiner and coordinator needed or (b) the transport is reliable.
* (a) If we have a shared keystore or username/password encryption, then this works
* (b) If we need to send a key request to the coord, and the coord sends a response, then either the transport needs to be reliable or UNICAST needs to be below ENCRYPT, or else these requests are sent *unreliably* and might get lost. A possible solution for (b) could be to assume that the message sending is unreliable and send the key request to the coordinator until a valid key is received. In this case, ENCRYPT could be moved under NAKACK/UNICAST.

[~mgencur] Either you used TCP as transport, or you were just lucky that the message wasn't dropped. Under real stress, there are no guarantees that a message isn't dropped.
                
> Improve performance of ENCRYPT protocol
> ---------------------------------------
>
>                 Key: JGRP-1722
>                 URL: https://issues.jboss.org/browse/JGRP-1722
>             Project: JGroups
>          Issue Type: Enhancement
>    Affects Versions: 3.4
>            Reporter: Martin Gencur
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> A stress tests with the following setup showed that performance (reads and writes/sec) is halved when ENCRYPT protocol is enabled:
> Infinispan had distributed sync cache with 2 owners on 4 nodes, no transactions. The stress test used 10 threads on each node accessing 1024 byte entries, no conflicts on keys, 20 % writes, 80 % reads. 
> It would be great if we could improve the performance of ENCRYPT protocol.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 05:25:02 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Thu, 24 Oct 2013 05:25:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1458) Allow specifying timeout for
 org.jboss.as.arquillian.container.ManagementClient.isServerInRunningState()
In-Reply-To: <JIRA.12493672.1370454383000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493672.1370454383000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493672.1370454383000.15197.1382606702202@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ladislav Thon updated WFLY-1458:
--------------------------------

    Fix Version/s: 8.0.0.CR1

    
> Allow specifying timeout for org.jboss.as.arquillian.container.ManagementClient.isServerInRunningState()
> --------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1458
>                 URL: https://issues.jboss.org/browse/WFLY-1458
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Test Suite
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Richard Achmatowicz
>            Assignee: Aslak Knutsen
>             Fix For: 8.0.0.CR1
>
>         Attachments: thread.dump.txt
>
>
> When deploying a container, Arquillian will use a management client to connect to the deployed container to see if it is in a running state. If the management address and management port are incorrect, the connection to the container hangs indefinitely.
> Please allow configuration of a timeout so that if the connection paramaters are not correct, at least the container deployment will fail with a meaningful error.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 05:29:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 24 Oct 2013 05:29:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-760) Make the JBoss Negotiation
 dependency on JBoss Web - Provided
In-Reply-To: <JIRA.12508666.1382606869692@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508666.1382606869692@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508666.1382606869692.15203.1382606942146@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created SECURITY-760:
-----------------------------------------

             Summary: Make the JBoss Negotiation dependency on JBoss Web - Provided
                 Key: SECURITY-760
                 URL: https://issues.jboss.org/browse/SECURITY-760
             Project: PicketBox 
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Negotiation
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: Negotiation_2_2_6




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 05:31:02 2013
From: jira-events at lists.jboss.org (Juergen Zimmermann (JIRA))
Date: Thu, 24 Oct 2013 05:31:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2372) @Model stops working with
 bean-discovery-mode="annotated"
In-Reply-To: <JIRA.12508667.1382607038973@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508667.1382607038973@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508667.1382607038973.15209.1382607062113@jira02.app.mwc.hst.phx2.redhat.com>

Juergen Zimmermann created WFLY-2372:
----------------------------------------

             Summary: @Model stops working with bean-discovery-mode="annotated"
                 Key: WFLY-2372
                 URL: https://issues.jboss.org/browse/WFLY-2372
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Web (Undertow)
    Affects Versions: 8.0.0.Beta1
            Reporter: Juergen Zimmermann
            Assignee: Stuart Douglas


First of all: I'm not sure whether this is a bug of Undertow or a bug of Weld or a limitation of Mojarra 2.1.

I changed WEB-INF/beans.xml so that the root element looks as follows, i.e. "annotated" instead of "all":
{code}
<beans ... bean-discovery-mode="annotated" ...>
{code}
When I access this CDI-enabled bean in a JSF page via EL using #{artikelModel.load}, I'm getting the stacktrace below:
{code}
@Model
public class ArtikelModel implements Serializable {
{code}
If I replace @Model with @RequestScoped @Named, then the issue is gone. Also if I go back from "annotated" to "all".

Stacktrace:
{code}
11:26:49,340 ERROR [io.undertow.request] (default task-3) Servlet request failed HttpServerExchange{ GET /shop/index.jsf}: javax.servlet.ServletException: /indexDesktop.xhtml @15,79 listener="#{artikelModel.load}": Target Unreachable, identifier 'artikelModel' resolved to null
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:606) [jsf-api-2.1.26.jar:2.1]
	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta19.jar:1.0.0.Beta19]
	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:93) [undertow-servlet-1.0.0.Beta19.jar:1.0.0.Beta19]
	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta19.jar:1.0.0.Beta19]
	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta19.jar:1.0.0.Beta19]
	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta19.jar:1.0.0.Beta19]
	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta19.jar:1.0.0.Beta19]
	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.0.Beta19.jar:1.0.0.Beta19]
	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta19.jar:1.0.0.Beta19]
	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:55) [undertow-servlet-1.0.0.Beta19.jar:1.0.0.Beta19]
	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.0.Beta19.jar:1.0.0.Beta19]
	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta19.jar:1.0.0.Beta19]
	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta19.jar:1.0.0.Beta19]
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta19.jar:1.0.0.Beta19]
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta19.jar:1.0.0.Beta19]
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:218) [undertow-servlet-1.0.0.Beta19.jar:1.0.0.Beta19]
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta19.jar:1.0.0.Beta19]
	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta19.jar:1.0.0.Beta19]
	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta19.jar:1.0.0.Beta19]
	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:138) [undertow-core-1.0.0.Beta19.jar:1.0.0.Beta19]
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:622) [undertow-core-1.0.0.Beta19.jar:1.0.0.Beta19]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
Caused by: javax.el.PropertyNotFoundException: /indexDesktop.xhtml @15,79 listener="#{artikelModel.load}": Target Unreachable, identifier 'artikelModel' resolved to null
	at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:107) [jsf-impl-2.1.26.jar:2.1.26]
	at com.sun.faces.facelets.tag.jsf.core.DeclarativeSystemEventListener.processEvent(EventHandler.java:128) [jsf-impl-2.1.26.jar:2.1.26]
	at javax.faces.component.UIComponent$ComponentSystemEventListenerAdapter.processEvent(UIComponent.java:2526) [jsf-api-2.1.26.jar:2.1]
	at javax.faces.event.SystemEvent.processListener(SystemEvent.java:106) [jsf-api-2.1.26.jar:2.1]
	at com.sun.faces.application.ApplicationImpl.processListeners(ApplicationImpl.java:2163) [jsf-impl-2.1.26.jar:2.1.26]
	at com.sun.faces.application.ApplicationImpl.invokeComponentListenersFor(ApplicationImpl.java:2111) [jsf-impl-2.1.26.jar:2.1.26]
	at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:289) [jsf-impl-2.1.26.jar:2.1.26]
	at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:247) [jsf-impl-2.1.26.jar:2.1.26]
	at org.jboss.as.jsf.injection.weld.ForwardingApplication.publishEvent(ForwardingApplication.java:299) [wildfly-jsf-injection-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
	at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:107) [jsf-impl-2.1.26.jar:2.1.26]
	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.1.26.jar:2.1.26]
	at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139) [jsf-impl-2.1.26.jar:2.1.26]
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594) [jsf-api-2.1.26.jar:2.1]
	... 24 more
{code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 05:47:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 24 Oct 2013 05:47:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1458) Allow specifying timeout for
 org.jboss.as.arquillian.container.ManagementClient.isServerInRunningState()
In-Reply-To: <JIRA.12493672.1370454383000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493672.1370454383000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493672.1370454383000.15257.1382608022070@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824582#comment-12824582 ] 

RH Bugzilla Integration commented on WFLY-1458:
-----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> changed the Status of [bug 1021487|https://bugzilla.redhat.com/show_bug.cgi?id=1021487] from NEW to ASSIGNED
                
> Allow specifying timeout for org.jboss.as.arquillian.container.ManagementClient.isServerInRunningState()
> --------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1458
>                 URL: https://issues.jboss.org/browse/WFLY-1458
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Test Suite
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Richard Achmatowicz
>            Assignee: Ladislav Thon
>             Fix For: 8.0.0.CR1
>
>         Attachments: thread.dump.txt
>
>
> When deploying a container, Arquillian will use a management client to connect to the deployed container to see if it is in a running state. If the management address and management port are incorrect, the connection to the container hangs indefinitely.
> Please allow configuration of a timeout so that if the connection paramaters are not correct, at least the container deployment will fail with a meaningful error.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 05:55:01 2013
From: jira-events at lists.jboss.org (Siamak Sadeghianfar (JIRA))
Date: Thu, 24 Oct 2013 05:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-283) Large header error is logged
 with DEBUG level
In-Reply-To: <JIRA.12508670.1382608431157@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508670.1382608431157@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508670.1382608431157.15274.1382608501927@jira02.app.mwc.hst.phx2.redhat.com>

Siamak Sadeghianfar created JBWEB-283:
-----------------------------------------

             Summary: Large header error is logged with DEBUG level
                 Key: JBWEB-283
                 URL: https://issues.jboss.org/browse/JBWEB-283
             Project: JBoss Web
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Core
    Affects Versions: JBossWeb-7.2.2.GA
            Reporter: Siamak Sadeghianfar
            Assignee: Remy Maucherat
            Priority: Minor


When the size of the request header exceeds the max size configured, the error message is logged with DEBUG level [1]. Therefore there are no records of this happening in the production environments since log level is often set to INFO. 

This needs to get logged at a higher level, preferably as a WARN.

[1] http://anonsvn.jboss.org/repos/jbossweb/tags/JBOSSWEB_7_2_2_FINAL/src/main/java/org/jboss/web/CoyoteLogger.java  line 363

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 06:01:04 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 24 Oct 2013 06:01:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-761) Release JBoss Negotiation
	2.2.6
In-Reply-To: <JIRA.12508671.1382608770236@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508671.1382608770236@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508671.1382608770236.15292.1382608864271@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created SECURITY-761:
-----------------------------------------

             Summary: Release JBoss Negotiation 2.2.6
                 Key: SECURITY-761
                 URL: https://issues.jboss.org/browse/SECURITY-761
             Project: PicketBox 
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Negotiation
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: Negotiation_2_2_6




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 06:01:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 24 Oct 2013 06:01:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-760) Make the JBoss Negotiation
 dependency on JBoss Web - Provided
In-Reply-To: <JIRA.12508666.1382606869000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508666.1382606869000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508666.1382606869000.15297.1382608864635@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated SECURITY-760:
---------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1022679

    
> Make the JBoss Negotiation dependency on JBoss Web - Provided
> -------------------------------------------------------------
>
>                 Key: SECURITY-760
>                 URL: https://issues.jboss.org/browse/SECURITY-760
>             Project: PicketBox 
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: Negotiation_2_2_6
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 06:03:02 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 24 Oct 2013 06:03:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1107) Allow obtaining a connection
 during MARKED_FOR_ROLLBACK
In-Reply-To: <JIRA.12508643.1382588475000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508643.1382588475000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508643.1382588475000.15302.1382608982005@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-1107.
------------------------------------

    Resolution: Done

    
> Allow obtaining a connection during MARKED_FOR_ROLLBACK
> -------------------------------------------------------
>
>                 Key: JBJCA-1107
>                 URL: https://issues.jboss.org/browse/JBJCA-1107
>             Project: IronJacamar
>          Issue Type: Feature Request
>          Components: Core
>            Reporter: Scott Marlow
>            Assignee: Jesper Pedersen
>             Fix For: 1.1.1.Final
>
>
> Provide a system property (ironjacamar.allow_marked_for_rollback) which allows the application to obtain a connection even when the transaction is in MARKED_FOR_ROLLBACK mode.
> Keep the default as is, e.g. fail eagerly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 06:03:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 24 Oct 2013 06:03:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-761) Release JBoss Negotiation
	2.2.6
In-Reply-To: <JIRA.12508671.1382608770000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508671.1382608770000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508671.1382608770000.15305.1382608982150@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated SECURITY-761:
---------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1017974

    
> Release JBoss Negotiation 2.2.6
> -------------------------------
>
>                 Key: SECURITY-761
>                 URL: https://issues.jboss.org/browse/SECURITY-761
>             Project: PicketBox 
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: Negotiation_2_2_6
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 06:41:01 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 24 Oct 2013 06:41:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-760) Make the JBoss Negotiation
 dependency on JBoss Web - Provided
In-Reply-To: <JIRA.12508666.1382606869000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508666.1382606869000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508666.1382606869000.15368.1382611261950@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved SECURITY-760.
---------------------------------------

    Resolution: Done

    
> Make the JBoss Negotiation dependency on JBoss Web - Provided
> -------------------------------------------------------------
>
>                 Key: SECURITY-760
>                 URL: https://issues.jboss.org/browse/SECURITY-760
>             Project: PicketBox 
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: Negotiation_2_2_6
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 07:04:02 2013
From: jira-events at lists.jboss.org (Pierre Colangelo (JIRA))
Date: Thu, 24 Oct 2013 07:04:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-324) xinclude support in the
	management model
In-Reply-To: <JIRA.12446086.1314912041000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12446086.1314912041000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12446086.1314912041000.15404.1382612642400@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824599#comment-12824599 ] 

Pierre Colangelo commented on WFLY-324:
---------------------------------------

This would be a great plus for the configuration. Especially for the profiles.
                
> xinclude support in the management model
> ----------------------------------------
>
>                 Key: WFLY-324
>                 URL: https://issues.jboss.org/browse/WFLY-324
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Jason Greene
>             Fix For: 8.0.0.CR1
>
>
> Ability to use xinclude in the domain/xml/host.xml/standalone.xml documents. Not necessarily anywhere, but where the model supports storing the information. Upon changes to the model, persistence of the relevant elements would be to the specified file.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 07:12:01 2013
From: jira-events at lists.jboss.org (Stefan Reuter (JIRA))
Date: Thu, 24 Oct 2013 07:12:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBRULES-3678) Drools 5.4 evaluates wrong
 on repeated execution
In-Reply-To: <JIRA.12478535.1351894694000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12478535.1351894694000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12478535.1351894694000.15417.1382613121966@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBRULES-3678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824600#comment-12824600 ] 

Stefan Reuter commented on JBRULES-3678:
----------------------------------------

Issue is still present in 5.5.0.Final
                
> Drools 5.4 evaluates wrong on repeated execution
> ------------------------------------------------
>
>                 Key: JBRULES-3678
>                 URL: https://issues.jboss.org/browse/JBRULES-3678
>             Project: JBRULES
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler (expert)
>    Affects Versions: 5.4.0.Final
>            Reporter: Thomas Kruse
>            Assignee: Mark Proctor
>            Priority: Critical
>         Attachments: Drools.tar.gz
>
>
> Regression in Drools 5.4: On repeated evaluation Drools starts to (not) fire rules.
> It seems like a knowledge session is getting corrupted over time. Perhaps related to the JIT?
> Disabling JIT in mvel did not mitigate the problem, change to Drools 5.3.0 does.
> I will add a test project.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 07:26:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 24 Oct 2013 07:26:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-758) AdvancedLdapLoginModule
 doesn't isn't mapping nested roles
In-Reply-To: <JIRA.12508503.1382458902000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508503.1382458902000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508503.1382458902000.15432.1382613962086@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/SECURITY-758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824604#comment-12824604 ] 

Darran Lofthouse commented on SECURITY-758:
-------------------------------------------

This can be reproduced with configuration similar to the following: -

{code}
                      <login-module code="AdvancedLdap" module="org.jboss.security.negotiation" flag="required">

                        <module-option name="bindDN" value="CN=as7" />
                        <module-option name="bindCredential" value="xxx" />

                        <module-option name="java.naming.provider.url" value="ldap://ec2-xx-xx-xx-xx.compute-1.amazonaws.com"/>
        
                        <module-option name="baseCtxDN" value="CN=Users,DC=darranl,DC=jboss,DC=org"/>
                        <module-option name="baseFilter" value="(sAMAccountName={0})"/>

                        <module-option name="rolesCtxDN" value="CN=Users,DC=darranl,DC=jboss,DC=org"/>

                        <module-option name="roleFilter" value="(distinguishedName={1})"/>
                        
                        <module-option name="roleAttributeID" value="memberOf"/>
                        <module-option name="roleAttributeIsDN" value="true"/>
                        <module-option name="roleNameAttributeID" value="name"/>
        
                        <module-option name="recurseRoles" value="true"/>

                    </login-module>
{code}

Note: One possible workaround could be if a definition is possible without the rolesFilter.
                
> AdvancedLdapLoginModule doesn't isn't mapping nested roles
> ----------------------------------------------------------
>
>                 Key: SECURITY-758
>                 URL: https://issues.jboss.org/browse/SECURITY-758
>             Project: PicketBox 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>    Affects Versions: Negotiation_2_2_5
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: Negotiation_2_2_6
>
>
> The recursive role searching is currently broken, believed to be caused by the introduction of quotes for a previous role searching fix.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 07:28:01 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 24 Oct 2013 07:28:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-735) spnego
 AdvancedLdapLoginModule cannot cope with roles contains a slash
In-Reply-To: <JIRA.12490042.1366636461000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12490042.1366636461000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12490042.1366636461000.15434.1382614081891@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/SECURITY-735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824605#comment-12824605 ] 

Darran Lofthouse commented on SECURITY-735:
-------------------------------------------

This issue is reproducible with configuration similar to the following: -

{code}
                      <login-module code="AdvancedLdap" module="org.jboss.security.negotiation" flag="required">

                        <module-option name="bindDN" value="CN=as7" />
                        <module-option name="bindCredential" value="xxx" />

                        <module-option name="java.naming.provider.url" value="ldap://ec2-xx-xx-xx-xx.compute-1.amazonaws.com"/>
        
                        <module-option name="baseCtxDN" value="CN=Users,DC=darranl,DC=jboss,DC=org"/>
                        <module-option name="baseFilter" value="(sAMAccountName={0})"/>

                        <module-option name="rolesCtxDN" value="CN=Users,DC=darranl,DC=jboss,DC=org"/>
                        
                        <module-option name="roleAttributeID" value="memberOf"/>
                        <module-option name="roleAttributeIsDN" value="true"/>
                        <module-option name="roleNameAttributeID" value="name"/>
        
                        <module-option name="recurseRoles" value="true"/>

                    </login-module>
{code}

The absence of a roleFilter is why the distinguished name is not being correctly quoted, adding the roleFilter would not be normally required as it does result in additional searches being performed by the LDAP server but in this case it is a possible workaround for the distinguished name to be quoted where required.

                
> spnego AdvancedLdapLoginModule cannot cope with roles contains a slash
> ----------------------------------------------------------------------
>
>                 Key: SECURITY-735
>                 URL: https://issues.jboss.org/browse/SECURITY-735
>             Project: PicketBox 
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>    Affects Versions: Negotiation_2_2_2
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: Negotiation_2_2_3
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 07:30:01 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 24 Oct 2013 07:30:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-761) Release JBoss Negotiation
	2.2.6
In-Reply-To: <JIRA.12508671.1382608770000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508671.1382608770000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508671.1382608770000.15439.1382614201969@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved SECURITY-761.
---------------------------------------

    Resolution: Done

    
> Release JBoss Negotiation 2.2.6
> -------------------------------
>
>                 Key: SECURITY-761
>                 URL: https://issues.jboss.org/browse/SECURITY-761
>             Project: PicketBox 
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: Negotiation_2_2_6
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 07:30:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 24 Oct 2013 07:30:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2371)
 SizeRotatingHandlerTestCase.rotationTest fails with "the file is bigger
 than allowed size"
In-Reply-To: <JIRA.12508645.1382597019000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508645.1382597019000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508645.1382597019000.15442.1382614202071@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824606#comment-12824606 ] 

RH Bugzilla Integration commented on WFLY-2371:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> changed the Status of [bug 1020339|https://bugzilla.redhat.com/show_bug.cgi?id=1020339] from NEW to POST
                
> SizeRotatingHandlerTestCase.rotationTest fails with "the file is bigger than allowed size"
> ------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2371
>                 URL: https://issues.jboss.org/browse/WFLY-2371
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Petr Kremensky
>            Assignee: Petr Kremensky
>
> The test org.jboss.as.test.integration.logging.operations.SizeRotatingHandlerTestCase.rotationTest consistently fails with:
> java.lang.AssertionError: This file is bigger than allowed rotate-size: size-rotating-reload-rotationTest.log.1
> Link to job:
> https://jenkins.mw.lab.eng.bos.redhat.com/job/eap-6x-manu-acceptance-as-ts-RHEL6_x86-oracleJDK6-srczip/25/testReport/junit/org.jboss.as.test.integration.logging.operations/SizeRotatingHandlerTestCase/rotationTest/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 07:49:01 2013
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Thu, 24 Oct 2013 07:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2373) patching resource does not
 get registered on slave hosts
In-Reply-To: <JIRA.12508684.1382615298661@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508684.1382615298661@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508684.1382615298661.15458.1382615341906@jira02.app.mwc.hst.phx2.redhat.com>

Emanuel Muckenhuber created WFLY-2373:
-----------------------------------------

             Summary: patching resource does not get registered on slave hosts
                 Key: WFLY-2373
                 URL: https://issues.jboss.org/browse/WFLY-2373
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Patching
    Affects Versions: 8.0.0.Beta1
            Reporter: Emanuel Muckenhuber
            Assignee: Emanuel Muckenhuber
             Fix For: 8.0.0.CR1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 07:51:01 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 24 Oct 2013 07:51:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2373) patching resource does not
 get registered on slave hosts
In-Reply-To: <JIRA.12508684.1382615298000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508684.1382615298000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508684.1382615298000.15461.1382615461980@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2373:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1022973

    
> patching resource does not get registered on slave hosts
> --------------------------------------------------------
>
>                 Key: WFLY-2373
>                 URL: https://issues.jboss.org/browse/WFLY-2373
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Patching
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Emanuel Muckenhuber
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 07:59:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 24 Oct 2013 07:59:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-758) AdvancedLdapLoginModule
 doesn't isn't mapping nested roles
In-Reply-To: <JIRA.12508503.1382458902000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508503.1382458902000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508503.1382458902000.15472.1382615942151@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated SECURITY-758:
--------------------------------------

    Fix Version/s: Negotiation_2_2_7
                       (was: Negotiation_2_2_6)

    
> AdvancedLdapLoginModule doesn't isn't mapping nested roles
> ----------------------------------------------------------
>
>                 Key: SECURITY-758
>                 URL: https://issues.jboss.org/browse/SECURITY-758
>             Project: PicketBox 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>    Affects Versions: Negotiation_2_2_5
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: Negotiation_2_2_7
>
>
> The recursive role searching is currently broken, believed to be caused by the introduction of quotes for a previous role searching fix.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 07:59:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 24 Oct 2013 07:59:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-717) Get JBoss Negotiation into
 Maven Central
In-Reply-To: <JIRA.12482052.1357571396000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12482052.1357571396000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12482052.1357571396000.15475.1382615942288@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated SECURITY-717:
--------------------------------------

    Fix Version/s: Negotiation_2_2_7
                       (was: Negotiation_2_2_6)

    
> Get JBoss Negotiation into Maven Central
> ----------------------------------------
>
>                 Key: SECURITY-717
>                 URL: https://issues.jboss.org/browse/SECURITY-717
>             Project: PicketBox 
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: Negotiation_2_2_7
>
>
> This will allow the JBoss Negotiation Toolkit to be removed from the project and instead moved to the quick starts making it much easier for end users to deploy and test.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 07:59:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 24 Oct 2013 07:59:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-677) Remove JBoss Negotiation
	Toolkit
In-Reply-To: <JIRA.12471347.1343413297000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12471347.1343413297000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12471347.1343413297000.15478.1382615942393@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated SECURITY-677:
--------------------------------------

    Fix Version/s: Negotiation_2_2_7
                       (was: Negotiation_2_2_6)

    
> Remove JBoss Negotiation Toolkit
> --------------------------------
>
>                 Key: SECURITY-677
>                 URL: https://issues.jboss.org/browse/SECURITY-677
>             Project: PicketBox 
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: Negotiation_2_2_7
>
>
> JBoss Negotiation Toolkit is being moved to the quickstarts, so it does not need to be maintained in two different locations delete it from the Negotiation source tree.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 08:01:04 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 24 Oct 2013 08:01:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-758) AdvancedLdapLoginModule
 doesn't isn't mapping nested roles
In-Reply-To: <JIRA.12508503.1382458902000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508503.1382458902000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508503.1382458902000.15487.1382616064029@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved SECURITY-758.
---------------------------------------

    Fix Version/s: Negotiation_2_2_6
                       (was: Negotiation_2_2_7)
       Resolution: Done

    
> AdvancedLdapLoginModule doesn't isn't mapping nested roles
> ----------------------------------------------------------
>
>                 Key: SECURITY-758
>                 URL: https://issues.jboss.org/browse/SECURITY-758
>             Project: PicketBox 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>    Affects Versions: Negotiation_2_2_5
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: Negotiation_2_2_6
>
>
> The recursive role searching is currently broken, believed to be caused by the introduction of quotes for a previous role searching fix.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 08:20:01 2013
From: jira-events at lists.jboss.org (Martin Kouba (JIRA))
Date: Thu, 24 Oct 2013 08:20:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2374) Add tests for component
 classes supporting injection
In-Reply-To: <JIRA.12508687.1382617154497@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508687.1382617154497@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508687.1382617154497.15510.1382617201996@jira02.app.mwc.hst.phx2.redhat.com>

Martin Kouba created WFLY-2374:
----------------------------------

             Summary: Add tests for component classes supporting injection
                 Key: WFLY-2374
                 URL: https://issues.jboss.org/browse/WFLY-2374
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Test Suite
            Reporter: Martin Kouba
            Assignee: Ondrej Zizka


Right now the test suite does not contain tests for component classes with "Standard" injection support level (see Table EE.5-1 and EE.5.24 Support for Dependency Injection). The problem is such tests are missing in Java EE CTS as well. Actually CDI TCK tests some basic injection scenarios (servlet, filter, etc.) but it does not cover everything. And the division of responsibilities for testing is work in progress (see also http://lists.jboss.org/pipermail/cdi-dev/2013-October/004345.html). 

Note that in Java EE 7 component classes must support the use of interceptors as well.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 08:24:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 24 Oct 2013 08:24:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2337) Eliminate additional round
 trip exchange of Subject from host controller to app server or slave host
 controllers.
In-Reply-To: <JIRA.12508207.1382112747000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508207.1382112747000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508207.1382112747000.15515.1382617443005@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2337:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1022993

    
> Eliminate additional round trip exchange of Subject from host controller to app server or slave host controllers.
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2337
>                 URL: https://issues.jboss.org/browse/WFLY-2337
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 08:26:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 24 Oct 2013 08:26:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1852) Populate the Subject with the
 required prinicpals for rbac/audit logging earlier
In-Reply-To: <JIRA.12498266.1375974256000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498266.1375974256000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498266.1375974256000.15520.1382617562176@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-1852:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1022993

    
> Populate the Subject with the required prinicpals for rbac/audit logging earlier
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-1852
>                 URL: https://issues.jboss.org/browse/WFLY-1852
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: Kabir Khan
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> At the moment these are added in a number of places, see TODO comments with this JIRA id.
> I also commented your concern a few lines down for https://github.com/wildfly/wildfly/pull/4889#commitcomment-3808535: "Do we need to use the Remoting version of this Principal - not sure if a new Principal may be better that is used both for web and for Remoting."

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 08:26:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 24 Oct 2013 08:26:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2044) Rework Subject propagation to
 avoid marshaling.
In-Reply-To: <JIRA.12500441.1378828999000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500441.1378828999000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500441.1378828999000.15523.1382617562306@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2044:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1022993

    
> Rework Subject propagation to avoid marshaling.
> -----------------------------------------------
>
>                 Key: WFLY-2044
>                 URL: https://issues.jboss.org/browse/WFLY-2044
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Rework Subject propagation to avoid marshalling - i.e. describe the contents of the Subject within the protocol and allow it to be reconstructed on the far side.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 08:36:02 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 24 Oct 2013 08:36:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2125) wildfly8 can't identify
	port-offset
In-Reply-To: <JIRA.12501168.1379906107000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501168.1379906107000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501168.1379906107000.15540.1382618162230@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar resolved WFLY-2125.
-------------------------------

    Resolution: Done


What you are seeing is different issue as we already explained in forums.
You are welcome to open new jira issue to address this new problem.
As main subject of issue was resolved, i am resolving this.
                
> wildfly8 can't identify port-offset
> -----------------------------------
>
>                 Key: WFLY-2125
>                 URL: https://issues.jboss.org/browse/WFLY-2125
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Alpha4
>         Environment: wildfly-8.0.0.Alpha4.tar.gz
> jdk-7u25-linux-i586.rpm
> mod_cluster-1.2.0.Final-linux2-x64-ssl.tar.gz
>            Reporter: hui gao
>            Assignee: Tomaz Cerar
>             Fix For: 8.0.0.Beta1
>
>
> I installed wildfly8 and mod_cluster  reference steps of https://docs.jboss.org/author/display/AS72/AS7+Cluster+Howto
> The cluster contains four servers,start up with domain mode:
> 10.19.222.52:server1/server2
> 10.19.222.53:server3/server4
> 10.19.222.50:apache
> But it only detects server1 and server3 which the port is 8009.
> The port-offset is 100,it can't identify the other port(8109) for server2 and server4.
> Search errorlog of Apache ,the proxy:AJP always acquired connection through initial AJP port(8009) defined in domain.xml.
> [Fri Sep 13 21:07:40 2013] [debug] mod_proxy_cluster.c(773): ajp_cping_cpong: Done
> [Fri Sep 13 21:07:40 2013] [debug] proxy_util.c(2029): proxy: ajp: has released connection for (10.19.222.52)
> [Fri Sep 13 21:07:43 2013] [debug] proxy_util.c(2011): proxy: ajp: has acquired connection for (10.19.222.53)
> [Fri Sep 13 21:07:43 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://10.19.222.53:8009/ to 10.19.222.53:8009
> [Fri Sep 13 21:07:43 2013] [debug] proxy_util.c(2193): proxy: connected ajp://10.19.222.53:8009/ to 10.19.222.53:8009
> [Fri Sep 13 21:07:43 2013] [debug] mod_proxy_cluster.c(773): ajp_cping_cpong: Done
> [Fri Sep 13 21:07:43 2013] [debug] proxy_util.c(2029): proxy: ajp: has released connection for (10.19.222.53)
> [Fri Sep 13 21:07:45 2013] [debug] proxy_util.c(2011): proxy: ajp: has acquired connection for (10.19.222.52)
> [Fri Sep 13 21:07:45 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://10.19.222.52:8009/ to 10.19.222.52:8009
> [Fri Sep 13 21:07:45 2013] [debug] proxy_util.c(2193): proxy: connected ajp://10.19.222.52:8009/ to 10.19.222.52:8009
> [Fri Sep 13 21:07:45 2013] [debug] mod_proxy_cluster.c(773): ajp_cping_cpong: Done
> [Fri Sep 13 21:07:45 2013] [debug] proxy_util.c(2029): proxy: ajp: has released connection for (10.19.222.52)
> [Fri Sep 13 21:07:46 2013] [debug] mod_manager.c(1667): manager_trans STATUS (/)
> [Fri Sep 13 21:07:46 2013] [debug] mod_manager.c(2323): manager_handler STATUS (/) processing: "JVMRoute=2644d861-0ead-352c-ba1e-619f1e1f25e8&Load=100"
> [Fri Sep 13 21:07:46 2013] [debug] mod_manager.c(1404): Processing STATUS
> [Fri Sep 13 21:07:46 2013] [debug] proxy_util.c(2011): proxy: ajp: has acquired connection for (10.19.222.53)
> [Fri Sep 13 21:07:46 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://10.19.222.53:8009/ to 10.19.222.53:8009
> [Fri Sep 13 21:07:46 2013] [debug] proxy_util.c(2193): proxy: connected ajp://10.19.222.53:8009/ to 10.19.222.53:8009
> [Fri Sep 13 21:07:46 2013] [debug] mod_proxy_cluster.c(773): ajp_cping_cpong: Done
> [Fri Sep 13 21:07:46 2013] [debug] proxy_util.c(2029): proxy: ajp: has released connection for (10.19.222.53)
> [Fri Sep 13 21:07:46 2013] [debug] mod_manager.c(2366): manager_handler STATUS  OK
> [Fri Sep 13 21:07:47 2013] [debug] mod_manager.c(1667): manager_trans STATUS (/)
> [Fri Sep 13 21:07:47 2013] [debug] mod_manager.c(2323): manager_handler STATUS (/) processing: "JVMRoute=ea81701b-f847-34a8-9534-0ac5c489af90&Load=100"
> [Fri Sep 13 21:07:47 2013] [debug] mod_manager.c(1404): Processing STATUS
> [Fri Sep 13 21:07:47 2013] [debug] proxy_util.c(2011): proxy: ajp: has acquired connection for (10.19.222.52)
> [Fri Sep 13 21:07:47 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://10.19.222.52:8009/ to 10.19.222.52:8009
> [Fri Sep 13 21:07:47 2013] [debug] proxy_util.c(2193): proxy: connected ajp://10.19.222.52:8009/ to 10.19.222.52:8009

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 08:40:02 2013
From: jira-events at lists.jboss.org (Martin Kouba (JIRA))
Date: Thu, 24 Oct 2013 08:40:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2374) Add tests for component
 classes supporting injection
In-Reply-To: <JIRA.12508687.1382617154000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508687.1382617154000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508687.1382617154000.15547.1382618402079@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Kouba reassigned WFLY-2374:
----------------------------------

    Assignee: Martin Kouba  (was: Ondrej Zizka)

    
> Add tests for component classes supporting injection
> ----------------------------------------------------
>
>                 Key: WFLY-2374
>                 URL: https://issues.jboss.org/browse/WFLY-2374
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Martin Kouba
>            Assignee: Martin Kouba
>
> Right now the test suite does not contain tests for component classes with "Standard" injection support level (see Table EE.5-1 and EE.5.24 Support for Dependency Injection). The problem is such tests are missing in Java EE CTS as well. Actually CDI TCK tests some basic injection scenarios (servlet, filter, etc.) but it does not cover everything. And the division of responsibilities for testing is work in progress (see also http://lists.jboss.org/pipermail/cdi-dev/2013-October/004345.html). 
> Note that in Java EE 7 component classes must support the use of interceptors as well.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 09:00:04 2013
From: jira-events at lists.jboss.org (=?UTF-8?Q?Dojcs=C3=A1k_S=C3=A1ndor_=28JIRA=29?=)
Date: Thu, 24 Oct 2013 09:00:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBASMP-55) Undeploy requires dependency
 resolution of artifacts in scope: runtime
In-Reply-To: <JIRA.12508236.1382213434000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508236.1382213434000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508236.1382213434000.15637.1382619604608@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBASMP-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824633#comment-12824633 ] 

Dojcs?k S?ndor commented on JBASMP-55:
--------------------------------------

Thank you for your answer but I think it is another problem.
For example I have a maven multi module project (my-app) with 2 module: module-a, module-b. Module-a depends on module-b.
{code:xml|title=my-app pom.xml}
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
	<modelVersion>4.0.0</modelVersion>
	<groupId>com.mycompany.app</groupId>
	<artifactId>my-app</artifactId>
	<packaging>pom</packaging>
	<version>1.0-SNAPSHOT</version>
	<name>my-app</name>
	<url>http://maven.apache.org</url>

	<modules>
		<module>module-a</module>
		<module>module-b</module>
	</modules>

</project>

{code}

{code:xml|title=module-a pom.xml}
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
	<modelVersion>4.0.0</modelVersion>

	<parent>
		<groupId>com.mycompany.app</groupId>
		<artifactId>my-app</artifactId>
		<version>1.0-SNAPSHOT</version>
		<relativePath>..</relativePath>
	</parent>

	<artifactId>module-a</artifactId>
	<packaging>jar</packaging>
	<version>1.0-SNAPSHOT</version>
	<name>module-a</name>
	<dependencies>
		<dependency>
			<groupId>junit</groupId>
			<artifactId>junit</artifactId>
			<version>3.8.1</version>
			<scope>test</scope>
		</dependency>
		<dependency>
			<groupId>${project.groupId}</groupId>
			<artifactId>module-b</artifactId>
			<version>${project.version}</version>
		</dependency>
	</dependencies>

	<build>
		<plugins>
			<plugin>
				<groupId>org.jboss.as.plugins</groupId>
				<artifactId>jboss-as-maven-plugin</artifactId>
				<version>7.4.Final</version>
				<executions>
					<execution>
						<id>undeploy</id>
						<phase>clean</phase>
						<goals>
							<goal>undeploy</goal>
						</goals>
					</execution>
				</executions>
			</plugin>
		</plugins>
	</build>
</project>
{code}

{code:xml|title=module-b pom.xml}
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
	<modelVersion>4.0.0</modelVersion>

	<parent>
		<groupId>com.mycompany.app</groupId>
		<artifactId>my-app</artifactId>
		<version>1.0-SNAPSHOT</version>
		<relativePath>..</relativePath>
	</parent>

	<artifactId>module-b</artifactId>
	<version>1.0-SNAPSHOT</version>
	<name>module-b</name>
	<dependencies>
		<dependency>
			<groupId>junit</groupId>
			<artifactId>junit</artifactId>
			<version>3.8.1</version>
			<scope>test</scope>
		</dependency>
	</dependencies>
</project>
{code}

Please run mvn clean and you will see the problem: ?[ERROR] Failed to execute goal on project module-a: Could not resolve dependencies for project??
If you change resolution scope in Undeploy.java to ResolutionScope.NONE, you can run mvn clean.

                
> Undeploy requires dependency resolution of artifacts in scope: runtime
> ----------------------------------------------------------------------
>
>                 Key: JBASMP-55
>                 URL: https://issues.jboss.org/browse/JBASMP-55
>             Project: JBoss AS Maven Plugins
>          Issue Type: Bug
>            Reporter: Dojcs?k S?ndor
>            Assignee: James Perkins
>
> I attached deploy goal to the clean lifecycle phase. I changed resolution scope in Undeploy.java to ResolutionScope.NONE. After I do not require mvn install for dependency resolution before I run clean.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Thu Oct 24 09:43:02 2013
From: jira-events at lists.jboss.org (Indranil Majumder (JIRA))
Date: Thu, 24 Oct 2013 09:43:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-324) xinclude support in the
	management model
In-Reply-To: <JIRA.12446086.1314912041000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12446086.1314912041000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12446086.1314912041000.15871.1382622182157@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824655#comment-12824655 ] 

Indranil Majumder commented on WFLY-324:
----------------------------------------

Is it possible for HAL to have a module to provide upload facility of customized profile xml(s) and restart/dynamically load it.
                
> xinclude support in the management model
> ----------------------------------------
>
>                 Key: WFLY-324
>                 URL: https://issues.jboss.org/browse/WFLY-324
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Jason Greene
>             Fix For: 8.0.0.CR1
>
>
> Ability to use xinclude in the domain/xml/host.xml/standalone.xml documents. Not necessarily anywhere, but where the model supports storing the information. Upon changes to the model, persistence of the relevant elements would be to the specified file.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 10:01:02 2013
From: jira-events at lists.jboss.org (Martin Kouba (JIRA))
Date: Thu, 24 Oct 2013 10:01:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2375) Servlet component classes do
 not support interceptors
In-Reply-To: <JIRA.12508703.1382623256117@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508703.1382623256117@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508703.1382623256117.15945.1382623262424@jira02.app.mwc.hst.phx2.redhat.com>

Martin Kouba created WFLY-2375:
----------------------------------

             Summary: Servlet component classes do not support interceptors
                 Key: WFLY-2375
                 URL: https://issues.jboss.org/browse/WFLY-2375
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Web (Undertow)
            Reporter: Martin Kouba
            Assignee: Stuart Douglas


In Java EE 7 component classes with "Standard" injection support level must support the use of interceptors (see Table EE.5-1 and EE.5.24 Support for Dependency Injection). Servlets, servlet filters and event listeners do not support interceptors at the moment.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 10:05:01 2013
From: jira-events at lists.jboss.org (Martin Kouba (JIRA))
Date: Thu, 24 Oct 2013 10:05:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2375) Servlet component classes do
 not support interceptors
In-Reply-To: <JIRA.12508703.1382623256000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508703.1382623256000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508703.1382623256000.15958.1382623501941@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824666#comment-12824666 ] 

Martin Kouba commented on WFLY-2375:
------------------------------------

There are no tests/reproducers in WF8 testsuite yet. The initial work on WFLY-2374 may be found here: https://github.com/mkouba/wildfly/tree/WFLY-2374/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/ee/injection/support/servlet
                
> Servlet component classes do not support interceptors
> -----------------------------------------------------
>
>                 Key: WFLY-2375
>                 URL: https://issues.jboss.org/browse/WFLY-2375
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>            Reporter: Martin Kouba
>            Assignee: Stuart Douglas
>
> In Java EE 7 component classes with "Standard" injection support level must support the use of interceptors (see Table EE.5-1 and EE.5.24 Support for Dependency Injection). Servlets, servlet filters and event listeners do not support interceptors at the moment.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 10:17:01 2013
From: jira-events at lists.jboss.org (Jay Kumar SenSharma (JIRA))
Date: Thu, 24 Oct 2013 10:17:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2376) DataSource properties are not
 persisting via CLI
In-Reply-To: <JIRA.12508706.1382624115225@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508706.1382624115225@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508706.1382624115225.16014.1382624221945@jira02.app.mwc.hst.phx2.redhat.com>

Jay Kumar SenSharma created WFLY-2376:
-----------------------------------------

             Summary: DataSource properties are not persisting via CLI
                 Key: WFLY-2376
                 URL: https://issues.jboss.org/browse/WFLY-2376
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JCA
            Reporter: Jay Kumar SenSharma
            Assignee: Jesper Pedersen


- The CLI command show that there are some valid configuration properties available like following while configuring DataSources, However those properties never get persisted in the DataSource configuration:

{quote}
 ./jboss-cli.sh  --user=admin --password=admin at 123 -c --controller=remote://localhost:9999  command="/subsystem=datasources/data-source=testpool:read-resource-description(recursive=true)" 


            "stale-connection-checker-properties" => {
                "type" => OBJECT,
                "description" => "The stale connection checker properties",
                "expressions-allowed" => true,
                "nillable" => true,
                "value-type" => STRING,
                "access-type" => "read-write",
                "storage" => "configuration",
                "restart-required" => "no-services"
            },
            "reauth-plugin-properties" => {
                "type" => OBJECT,
                "description" => "The properties for the reauthentication plugin",
                "expressions-allowed" => true,
                "nillable" => true,
                "value-type" => STRING,
                "access-type" => "read-write",
                "storage" => "configuration",
                "restart-required" => "no-services"
            },
            "exception-sorter-properties" => {
                "type" => OBJECT,
                "description" => "The exception sorter properties",
                "expressions-allowed" => true,
                "nillable" => true,
                "value-type" => STRING,
                "access-type" => "read-write",
                "storage" => "configuration",
                "restart-required" => "no-services"
            },
{quote}

- Following command never complains about any issue and the following command executed without any issue but the above properties are not persisted in the DataSource.

{quote}
 ./jboss-cli.sh --user=admin --password=admin at 123 -c --controller=remote://localhost:9999 command="/subsystem=datasources/data-source=testpool:add(jndi-name=\"java:jboss/TestDS\",driver-name=\"ojdbc6.jar\",connection-url=\"jdbc:oracle:thin:@DBHostName:1521:DBName\",user-name=\"user\",password=\"pass\",new-connection-sql=\"select 1 from dual\", check-valid-connection-sql=\"select 2 from dual\",valid-connection-checker-class-name=\"org.jboss.resource.adapter.jdbc.vendor.OracleValidConnectionChecker\",exception-sorter-properties={\"prop1\"=>\"value1\"},reauth-plugin-properties={\"reauthProp1\"=>\"reauthValue1\"},exception-sorter-properties={\"exceptionSorterProp1\"=>\"exceptionSorterValue1\"})"
{quote}


- The Generated DataSource looks like following:

${quote}
                <datasource jndi-name="java:jboss/TestDS" pool-name="testpool" enabled="true">
                    <connection-url>jdbc:oracle:thin:@DBHostName:1521:DBName</connection-url>
                    <driver>ojdbc6.jar</driver>
                    <new-connection-sql>select 1 from dual</new-connection-sql>
                    <security>
                        <user-name>user</user-name>
                        <password>pass</password>
                    </security>
                    <validation>
                        <valid-connection-checker class-name="org.jboss.resource.adapter.jdbc.vendor.OracleValidConnectionChecker"/>
                        <check-valid-connection-sql>select 2 from dual</check-valid-connection-sql>
                    </validation>
                </datasource>
${quote}


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 10:17:02 2013
From: jira-events at lists.jboss.org (Jay Kumar SenSharma (JIRA))
Date: Thu, 24 Oct 2013 10:17:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2376) DataSource properties are not
 persisting via CLI
In-Reply-To: <JIRA.12508706.1382624115000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508706.1382624115000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508706.1382624115000.16018.1382624222021@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jay Kumar SenSharma updated WFLY-2376:
--------------------------------------

    Description: 
- The CLI command show that there are some valid configuration properties available like following while configuring DataSources, However those properties never get persisted in the DataSource configuration:

{quote}
 ./jboss-cli.sh  --user=admin --password=admin at 123 -c --controller=remote://localhost:9999  command="/subsystem=datasources/data-source=testpool:read-resource-description(recursive=true)" 


            "stale-connection-checker-properties" => {
                "type" => OBJECT,
                "description" => "The stale connection checker properties",
                "expressions-allowed" => true,
                "nillable" => true,
                "value-type" => STRING,
                "access-type" => "read-write",
                "storage" => "configuration",
                "restart-required" => "no-services"
            },
            "reauth-plugin-properties" => {
                "type" => OBJECT,
                "description" => "The properties for the reauthentication plugin",
                "expressions-allowed" => true,
                "nillable" => true,
                "value-type" => STRING,
                "access-type" => "read-write",
                "storage" => "configuration",
                "restart-required" => "no-services"
            },
            "exception-sorter-properties" => {
                "type" => OBJECT,
                "description" => "The exception sorter properties",
                "expressions-allowed" => true,
                "nillable" => true,
                "value-type" => STRING,
                "access-type" => "read-write",
                "storage" => "configuration",
                "restart-required" => "no-services"
            },
{quote}

- Following command never complains about any issue and the following command executed without any issue but the above properties are not persisted in the DataSource.

 ./jboss-cli.sh --user=admin --password=admin at 123 -c --controller=remote://localhost:9999 command="/subsystem=datasources/data-source=testpool:add(jndi-name=\"java:jboss/TestDS\",driver-name=\"ojdbc6.jar\",connection-url=\"jdbc:oracle:thin:@DBHostName:1521:DBName\",user-name=\"user\",password=\"pass\",new-connection-sql=\"select 1 from dual\", check-valid-connection-sql=\"select 2 from dual\",valid-connection-checker-class-name=\"org.jboss.resource.adapter.jdbc.vendor.OracleValidConnectionChecker\",exception-sorter-properties={\"prop1\"=>\"value1\"},reauth-plugin-properties={\"reauthProp1\"=>\"reauthValue1\"},exception-sorter-properties={\"exceptionSorterProp1\"=>\"exceptionSorterValue1\"})"



- The Generated DataSource looks like following:

${quote}
                <datasource jndi-name="java:jboss/TestDS" pool-name="testpool" enabled="true">
                    <connection-url>jdbc:oracle:thin:@DBHostName:1521:DBName</connection-url>
                    <driver>ojdbc6.jar</driver>
                    <new-connection-sql>select 1 from dual</new-connection-sql>
                    <security>
                        <user-name>user</user-name>
                        <password>pass</password>
                    </security>
                    <validation>
                        <valid-connection-checker class-name="org.jboss.resource.adapter.jdbc.vendor.OracleValidConnectionChecker"/>
                        <check-valid-connection-sql>select 2 from dual</check-valid-connection-sql>
                    </validation>
                </datasource>
${quote}


  was:
- The CLI command show that there are some valid configuration properties available like following while configuring DataSources, However those properties never get persisted in the DataSource configuration:

{quote}
 ./jboss-cli.sh  --user=admin --password=admin at 123 -c --controller=remote://localhost:9999  command="/subsystem=datasources/data-source=testpool:read-resource-description(recursive=true)" 


            "stale-connection-checker-properties" => {
                "type" => OBJECT,
                "description" => "The stale connection checker properties",
                "expressions-allowed" => true,
                "nillable" => true,
                "value-type" => STRING,
                "access-type" => "read-write",
                "storage" => "configuration",
                "restart-required" => "no-services"
            },
            "reauth-plugin-properties" => {
                "type" => OBJECT,
                "description" => "The properties for the reauthentication plugin",
                "expressions-allowed" => true,
                "nillable" => true,
                "value-type" => STRING,
                "access-type" => "read-write",
                "storage" => "configuration",
                "restart-required" => "no-services"
            },
            "exception-sorter-properties" => {
                "type" => OBJECT,
                "description" => "The exception sorter properties",
                "expressions-allowed" => true,
                "nillable" => true,
                "value-type" => STRING,
                "access-type" => "read-write",
                "storage" => "configuration",
                "restart-required" => "no-services"
            },
{quote}

- Following command never complains about any issue and the following command executed without any issue but the above properties are not persisted in the DataSource.

{quote}
 ./jboss-cli.sh --user=admin --password=admin at 123 -c --controller=remote://localhost:9999 command="/subsystem=datasources/data-source=testpool:add(jndi-name=\"java:jboss/TestDS\",driver-name=\"ojdbc6.jar\",connection-url=\"jdbc:oracle:thin:@DBHostName:1521:DBName\",user-name=\"user\",password=\"pass\",new-connection-sql=\"select 1 from dual\", check-valid-connection-sql=\"select 2 from dual\",valid-connection-checker-class-name=\"org.jboss.resource.adapter.jdbc.vendor.OracleValidConnectionChecker\",exception-sorter-properties={\"prop1\"=>\"value1\"},reauth-plugin-properties={\"reauthProp1\"=>\"reauthValue1\"},exception-sorter-properties={\"exceptionSorterProp1\"=>\"exceptionSorterValue1\"})"
{quote}


- The Generated DataSource looks like following:

${quote}
                <datasource jndi-name="java:jboss/TestDS" pool-name="testpool" enabled="true">
                    <connection-url>jdbc:oracle:thin:@DBHostName:1521:DBName</connection-url>
                    <driver>ojdbc6.jar</driver>
                    <new-connection-sql>select 1 from dual</new-connection-sql>
                    <security>
                        <user-name>user</user-name>
                        <password>pass</password>
                    </security>
                    <validation>
                        <valid-connection-checker class-name="org.jboss.resource.adapter.jdbc.vendor.OracleValidConnectionChecker"/>
                        <check-valid-connection-sql>select 2 from dual</check-valid-connection-sql>
                    </validation>
                </datasource>
${quote}



    
> DataSource properties are not persisting via CLI
> ------------------------------------------------
>
>                 Key: WFLY-2376
>                 URL: https://issues.jboss.org/browse/WFLY-2376
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA
>            Reporter: Jay Kumar SenSharma
>            Assignee: Jesper Pedersen
>
> - The CLI command show that there are some valid configuration properties available like following while configuring DataSources, However those properties never get persisted in the DataSource configuration:
> {quote}
>  ./jboss-cli.sh  --user=admin --password=admin at 123 -c --controller=remote://localhost:9999  command="/subsystem=datasources/data-source=testpool:read-resource-description(recursive=true)" 
>             "stale-connection-checker-properties" => {
>                 "type" => OBJECT,
>                 "description" => "The stale connection checker properties",
>                 "expressions-allowed" => true,
>                 "nillable" => true,
>                 "value-type" => STRING,
>                 "access-type" => "read-write",
>                 "storage" => "configuration",
>                 "restart-required" => "no-services"
>             },
>             "reauth-plugin-properties" => {
>                 "type" => OBJECT,
>                 "description" => "The properties for the reauthentication plugin",
>                 "expressions-allowed" => true,
>                 "nillable" => true,
>                 "value-type" => STRING,
>                 "access-type" => "read-write",
>                 "storage" => "configuration",
>                 "restart-required" => "no-services"
>             },
>             "exception-sorter-properties" => {
>                 "type" => OBJECT,
>                 "description" => "The exception sorter properties",
>                 "expressions-allowed" => true,
>                 "nillable" => true,
>                 "value-type" => STRING,
>                 "access-type" => "read-write",
>                 "storage" => "configuration",
>                 "restart-required" => "no-services"
>             },
> {quote}
> - Following command never complains about any issue and the following command executed without any issue but the above properties are not persisted in the DataSource.
>  ./jboss-cli.sh --user=admin --password=admin at 123 -c --controller=remote://localhost:9999 command="/subsystem=datasources/data-source=testpool:add(jndi-name=\"java:jboss/TestDS\",driver-name=\"ojdbc6.jar\",connection-url=\"jdbc:oracle:thin:@DBHostName:1521:DBName\",user-name=\"user\",password=\"pass\",new-connection-sql=\"select 1 from dual\", check-valid-connection-sql=\"select 2 from dual\",valid-connection-checker-class-name=\"org.jboss.resource.adapter.jdbc.vendor.OracleValidConnectionChecker\",exception-sorter-properties={\"prop1\"=>\"value1\"},reauth-plugin-properties={\"reauthProp1\"=>\"reauthValue1\"},exception-sorter-properties={\"exceptionSorterProp1\"=>\"exceptionSorterValue1\"})"
> - The Generated DataSource looks like following:
> ${quote}
>                 <datasource jndi-name="java:jboss/TestDS" pool-name="testpool" enabled="true">
>                     <connection-url>jdbc:oracle:thin:@DBHostName:1521:DBName</connection-url>
>                     <driver>ojdbc6.jar</driver>
>                     <new-connection-sql>select 1 from dual</new-connection-sql>
>                     <security>
>                         <user-name>user</user-name>
>                         <password>pass</password>
>                     </security>
>                     <validation>
>                         <valid-connection-checker class-name="org.jboss.resource.adapter.jdbc.vendor.OracleValidConnectionChecker"/>
>                         <check-valid-connection-sql>select 2 from dual</check-valid-connection-sql>
>                     </validation>
>                 </datasource>
> ${quote}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 10:19:01 2013
From: jira-events at lists.jboss.org (Jay Kumar SenSharma (JIRA))
Date: Thu, 24 Oct 2013 10:19:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2376) DataSource properties are not
 persisting via CLI
In-Reply-To: <JIRA.12508706.1382624115000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508706.1382624115000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508706.1382624115000.16022.1382624341911@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jay Kumar SenSharma updated WFLY-2376:
--------------------------------------

    Affects Version/s: 8.0.0.Beta1

    
> DataSource properties are not persisting via CLI
> ------------------------------------------------
>
>                 Key: WFLY-2376
>                 URL: https://issues.jboss.org/browse/WFLY-2376
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Jay Kumar SenSharma
>            Assignee: Jesper Pedersen
>
> - The CLI command show that there are some valid configuration properties available like following while configuring DataSources, However those properties never get persisted in the DataSource configuration:
> {quote}
>  ./jboss-cli.sh  --user=admin --password=admin at 123 -c --controller=remote://localhost:9999  command="/subsystem=datasources/data-source=testpool:read-resource-description(recursive=true)" 
>             "stale-connection-checker-properties" => {
>                 "type" => OBJECT,
>                 "description" => "The stale connection checker properties",
>                 "expressions-allowed" => true,
>                 "nillable" => true,
>                 "value-type" => STRING,
>                 "access-type" => "read-write",
>                 "storage" => "configuration",
>                 "restart-required" => "no-services"
>             },
>             "reauth-plugin-properties" => {
>                 "type" => OBJECT,
>                 "description" => "The properties for the reauthentication plugin",
>                 "expressions-allowed" => true,
>                 "nillable" => true,
>                 "value-type" => STRING,
>                 "access-type" => "read-write",
>                 "storage" => "configuration",
>                 "restart-required" => "no-services"
>             },
>             "exception-sorter-properties" => {
>                 "type" => OBJECT,
>                 "description" => "The exception sorter properties",
>                 "expressions-allowed" => true,
>                 "nillable" => true,
>                 "value-type" => STRING,
>                 "access-type" => "read-write",
>                 "storage" => "configuration",
>                 "restart-required" => "no-services"
>             },
> {quote}
> - Following command never complains about any issue and the following command executed without any issue but the above properties are not persisted in the DataSource.
>  ./jboss-cli.sh --user=admin --password=admin at 123 -c --controller=remote://localhost:9999 command="/subsystem=datasources/data-source=testpool:add(jndi-name=\"java:jboss/TestDS\",driver-name=\"ojdbc6.jar\",connection-url=\"jdbc:oracle:thin:@DBHostName:1521:DBName\",user-name=\"user\",password=\"pass\",new-connection-sql=\"select 1 from dual\", check-valid-connection-sql=\"select 2 from dual\",valid-connection-checker-class-name=\"org.jboss.resource.adapter.jdbc.vendor.OracleValidConnectionChecker\",exception-sorter-properties={\"prop1\"=>\"value1\"},reauth-plugin-properties={\"reauthProp1\"=>\"reauthValue1\"},exception-sorter-properties={\"exceptionSorterProp1\"=>\"exceptionSorterValue1\"})"
> - The Generated DataSource looks like following:
> ${quote}
>                 <datasource jndi-name="java:jboss/TestDS" pool-name="testpool" enabled="true">
>                     <connection-url>jdbc:oracle:thin:@DBHostName:1521:DBName</connection-url>
>                     <driver>ojdbc6.jar</driver>
>                     <new-connection-sql>select 1 from dual</new-connection-sql>
>                     <security>
>                         <user-name>user</user-name>
>                         <password>pass</password>
>                     </security>
>                     <validation>
>                         <valid-connection-checker class-name="org.jboss.resource.adapter.jdbc.vendor.OracleValidConnectionChecker"/>
>                         <check-valid-connection-sql>select 2 from dual</check-valid-connection-sql>
>                     </validation>
>                 </datasource>
> ${quote}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 10:41:01 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Thu, 24 Oct 2013 10:41:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2230) Web subsystem transformers
	for 7.2.0
In-Reply-To: <JIRA.12502316.1381145821000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502316.1381145821000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502316.1381145821000.16037.1382625661949@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan reassigned WFLY-2230:
--------------------------------

    Assignee: Kabir Khan  (was: Tomaz Cerar)

    
> Web subsystem transformers for 7.2.0
> ------------------------------------
>
>                 Key: WFLY-2230
>                 URL: https://issues.jboss.org/browse/WFLY-2230
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Web (JBoss Web)
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 11:12:01 2013
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Thu, 24 Oct 2013 11:12:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2377) Upgrade Infinispan to
	6.0.0.CR2
In-Reply-To: <JIRA.12508713.1382627508567@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508713.1382627508567@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508713.1382627508567.16124.1382627521932@jira02.app.mwc.hst.phx2.redhat.com>

Paul Ferraro created WFLY-2377:
----------------------------------

             Summary: Upgrade Infinispan to 6.0.0.CR2
                 Key: WFLY-2377
                 URL: https://issues.jboss.org/browse/WFLY-2377
             Project: WildFly
          Issue Type: Component  Upgrade
      Security Level: Public (Everyone can see)
          Components: Clustering
    Affects Versions: 8.0.0.Beta1
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro
             Fix For: 8.0.0.CR1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 11:14:01 2013
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Thu, 24 Oct 2013 11:14:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2378) Re-enable
	StatefulWithXPCFailoverTestCase
In-Reply-To: <JIRA.12508714.1382627574719@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508714.1382627574719@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508714.1382627574719.16127.1382627641916@jira02.app.mwc.hst.phx2.redhat.com>

Paul Ferraro created WFLY-2378:
----------------------------------

             Summary: Re-enable StatefulWithXPCFailoverTestCase
                 Key: WFLY-2378
                 URL: https://issues.jboss.org/browse/WFLY-2378
             Project: WildFly
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Clustering
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro


So I don't forget...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 11:14:01 2013
From: jira-events at lists.jboss.org (Derek Horton (JIRA))
Date: Thu, 24 Oct 2013 11:14:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-762) Bug in
 JBossJSSESecurityDomain.java - attempting to use wrong provider
In-Reply-To: <JIRA.12508715.1382627586103@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508715.1382627586103@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508715.1382627586103.16130.1382627641964@jira02.app.mwc.hst.phx2.redhat.com>

Derek Horton created SECURITY-762:
-------------------------------------

             Summary: Bug in JBossJSSESecurityDomain.java - attempting to use wrong provider
                 Key: SECURITY-762
                 URL: https://issues.jboss.org/browse/SECURITY-762
             Project: PicketBox 
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JBossSX
    Affects Versions: PicketBox_4_0_19.Final
            Reporter: Derek Horton
            Assignee: Anil Saldhana


There is a bug in JBossJSSESecurityDomain.java where it attempts to use the keystore/truststore provider to get instances of the trust manager.

The code reads:
         if (trustManagerFactoryProvider != null)
            trustManagerFactory = TrustManagerFactory.getInstance(algorithm, trustStoreProvider);
         else
            trustManagerFactory = TrustManagerFactory.getInstance(algorithm);


I think it should read:
         if (trustManagerFactoryProvider != null)
            trustManagerFactory = TrustManagerFactory.getInstance(algorithm, trustManagerFactoryProvider);
         else
            trustManagerFactory = TrustManagerFactory.getInstance(algorithm);


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 11:16:02 2013
From: jira-events at lists.jboss.org (Derek Horton (JIRA))
Date: Thu, 24 Oct 2013 11:16:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-762) Bug in
 JBossJSSESecurityDomain.java - attempting to use wrong provider
In-Reply-To: <JIRA.12508715.1382627586000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508715.1382627586000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508715.1382627586000.16141.1382627762930@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Derek Horton updated SECURITY-762:
----------------------------------

    Steps to Reproduce: 
Steps to Reproduce:
Setup a security-domain that defines a JSSE keystore/truststore:

   <!-- keystore works
                    <jsse keystore-url="/home/dehort/dev/java/jboss-eap-6.1.1/standalone/configuration/server.keystore"
                      keystore-password="123456" 
                      key-manager-factory-algorithm="SunX509" 
                      key-manager-factory-provider="SunJSSE"/>
   -->
  
   <!-- truststore configured the same way fails -->
                    <jsse truststore-url="/home/dehort/dev/java/jboss-eap-6.1.1/standalone/configuration/server.keystore"
                      truststore-password="123456" 
                      trust-manager-factory-algorithm="SunX509" 
                      trust-manager-factory-provider="SunJSSE"/>


  was:


Steps to Reproduce:
Setup a security-domain that defines a JSSE keystore/truststore:
+                    <!--
+                    <jsse keystore-url="/home/dehort/dev/java/jboss-eap-6.1.1/standalone/configuration/server.keystore"
+                      keystore-password="123456" 
+                      key-manager-factory-algorithm="SunX509" 
+                      key-manager-factory-provider="SunJSSE"/>
+                    -->
+                    <jsse truststore-url="/home/dehort/dev/java/jboss-eap-6.1.1/standalone/configuration/server.keystore"
+                      truststore-password="123456" 
+                      trust-manager-factory-algorithm="SunX509" 
+                      trust-manager-factory-provider="SunJSSE"/>



    
> Bug in JBossJSSESecurityDomain.java - attempting to use wrong provider
> ----------------------------------------------------------------------
>
>                 Key: SECURITY-762
>                 URL: https://issues.jboss.org/browse/SECURITY-762
>             Project: PicketBox 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: PicketBox_4_0_19.Final
>            Reporter: Derek Horton
>            Assignee: Anil Saldhana
>
> There is a bug in JBossJSSESecurityDomain.java where it attempts to use the keystore/truststore provider to get instances of the trust manager.
> The code reads:
>          if (trustManagerFactoryProvider != null)
>             trustManagerFactory = TrustManagerFactory.getInstance(algorithm, trustStoreProvider);
>          else
>             trustManagerFactory = TrustManagerFactory.getInstance(algorithm);
> I think it should read:
>          if (trustManagerFactoryProvider != null)
>             trustManagerFactory = TrustManagerFactory.getInstance(algorithm, trustManagerFactoryProvider);
>          else
>             trustManagerFactory = TrustManagerFactory.getInstance(algorithm);

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 11:28:01 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Thu, 24 Oct 2013 11:28:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2379) Can't call "describe" via JMX
In-Reply-To: <JIRA.12508718.1382628380033@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508718.1382628380033@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508718.1382628380033.16175.1382628481944@jira02.app.mwc.hst.phx2.redhat.com>

Ladislav Thon created WFLY-2379:
-----------------------------------

             Summary: Can't call "describe" via JMX
                 Key: WFLY-2379
                 URL: https://issues.jboss.org/browse/WFLY-2379
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Domain Management, JMX
            Reporter: Ladislav Thon
            Assignee: Kabir Khan
            Priority: Minor


It's not possible to call "non-published" operations (those that are not visible in the resource tree, e.g. {{describe}}) via JMX, while it's entirely possible to call them via CLI (e.g. {{/subsystem=security:describe}}) and other management interfaces.

The problem lies in the fact that {{ModelControllerMBeanHelper.invoke}} method checks {{if (!accessControl.isExecutableOperation(operationName))}} and the {{isExecutableOperation}} method assumes that the operation will be visible in the resource tree. In fact, there is a comment stating _should not happen_, but now we know that it indeed _can_ happen.

What's more, it gives a misleading error message. The {{isExecutableOperation}} returns {{false}} for unknown operations, which results in {{Not authorized to invoke operation}} message. Which is wrong in two different ways simultaneously: 1. the problem isn't authorization, but the fact that the operation can't be found; 2. the user (e.g. in the {{SuperUser}} role) _is_ authorized.

I'm considering this low priority, because 1. JMX is likely to be very rarely used to access the management interface, 2. hiding information isn't nearly as important as leaking them, 3. non-published operations aren't nearly as important as the published ones. It's worth a JIRA nevertheless.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 11:28:01 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Thu, 24 Oct 2013 11:28:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2379) Can't call "describe" via JMX
In-Reply-To: <JIRA.12508718.1382628380000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508718.1382628380000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508718.1382628380000.16178.1382628481996@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ladislav Thon updated WFLY-2379:
--------------------------------

        Parent: WFLY-490
    Issue Type: Sub-task  (was: Bug)

    
> Can't call "describe" via JMX
> -----------------------------
>
>                 Key: WFLY-2379
>                 URL: https://issues.jboss.org/browse/WFLY-2379
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, JMX
>            Reporter: Ladislav Thon
>            Assignee: Kabir Khan
>            Priority: Minor
>              Labels: rbac-filed-by-qa
>
> It's not possible to call "non-published" operations (those that are not visible in the resource tree, e.g. {{describe}}) via JMX, while it's entirely possible to call them via CLI (e.g. {{/subsystem=security:describe}}) and other management interfaces.
> The problem lies in the fact that {{ModelControllerMBeanHelper.invoke}} method checks {{if (!accessControl.isExecutableOperation(operationName))}} and the {{isExecutableOperation}} method assumes that the operation will be visible in the resource tree. In fact, there is a comment stating _should not happen_, but now we know that it indeed _can_ happen.
> What's more, it gives a misleading error message. The {{isExecutableOperation}} returns {{false}} for unknown operations, which results in {{Not authorized to invoke operation}} message. Which is wrong in two different ways simultaneously: 1. the problem isn't authorization, but the fact that the operation can't be found; 2. the user (e.g. in the {{SuperUser}} role) _is_ authorized.
> I'm considering this low priority, because 1. JMX is likely to be very rarely used to access the management interface, 2. hiding information isn't nearly as important as leaking them, 3. non-published operations aren't nearly as important as the published ones. It's worth a JIRA nevertheless.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 11:28:02 2013
From: jira-events at lists.jboss.org (Emmanuel Hugonnet (JIRA))
Date: Thu, 24 Oct 2013 11:28:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBAS-9550) Upgrade EJB3 Core to 1.3.10
In-Reply-To: <JIRA.12508719.1382628421001@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508719.1382628421001@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508719.1382628421001.16181.1382628482078@jira02.app.mwc.hst.phx2.redhat.com>

Emmanuel Hugonnet created JBAS-9550:
---------------------------------------

             Summary: Upgrade EJB3 Core to 1.3.10
                 Key: JBAS-9550
                 URL: https://issues.jboss.org/browse/JBAS-9550
             Project: Application Server 3  4  5 and 6
          Issue Type: Component  Upgrade
      Security Level: Public (Everyone can see)
          Components: EJB
            Reporter: Emmanuel Hugonnet
            Assignee: Carlo de Wolf


Fix for  JBPAPP-9411 is in EJB3 Core r114546

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 11:32:02 2013
From: jira-events at lists.jboss.org (Jozef Hartinger (JIRA))
Date: Thu, 24 Oct 2013 11:32:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1746) CDI beans in static modules
 cannot see each other
In-Reply-To: <JIRA.12497127.1374582261000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497127.1374582261000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497127.1374582261000.16188.1382628722103@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Hartinger reassigned WFLY-1746:
-------------------------------------

    Assignee: Jozef Hartinger  (was: Stuart Douglas)

    
> CDI beans in static modules cannot see each other
> -------------------------------------------------
>
>                 Key: WFLY-1746
>                 URL: https://issues.jboss.org/browse/WFLY-1746
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Stuart Douglas
>            Assignee: Jozef Hartinger
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 11:32:02 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 24 Oct 2013 11:32:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2379) Can't call "describe" via JMX
In-Reply-To: <JIRA.12508718.1382628380000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508718.1382628380000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508718.1382628380000.16197.1382628722307@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824691#comment-12824691 ] 

Tomaz Cerar commented on WFLY-2379:
-----------------------------------

We should not publicize :describe operation, as this is really rally low level operation that is not meant for end-user usage.
                
> Can't call "describe" via JMX
> -----------------------------
>
>                 Key: WFLY-2379
>                 URL: https://issues.jboss.org/browse/WFLY-2379
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, JMX
>            Reporter: Ladislav Thon
>            Assignee: Kabir Khan
>            Priority: Minor
>              Labels: rbac-filed-by-qa
>
> It's not possible to call "non-published" operations (those that are not visible in the resource tree, e.g. {{describe}}) via JMX, while it's entirely possible to call them via CLI (e.g. {{/subsystem=security:describe}}) and other management interfaces.
> The problem lies in the fact that {{ModelControllerMBeanHelper.invoke}} method checks {{if (!accessControl.isExecutableOperation(operationName))}} and the {{isExecutableOperation}} method assumes that the operation will be visible in the resource tree. In fact, there is a comment stating _should not happen_, but now we know that it indeed _can_ happen.
> What's more, it gives a misleading error message. The {{isExecutableOperation}} returns {{false}} for unknown operations, which results in {{Not authorized to invoke operation}} message. Which is wrong in two different ways simultaneously: 1. the problem isn't authorization, but the fact that the operation can't be found; 2. the user (e.g. in the {{SuperUser}} role) _is_ authorized.
> I'm considering this low priority, because 1. JMX is likely to be very rarely used to access the management interface, 2. hiding information isn't nearly as important as leaking them, 3. non-published operations aren't nearly as important as the published ones. It's worth a JIRA nevertheless.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 11:32:02 2013
From: jira-events at lists.jboss.org (Jozef Hartinger (JIRA))
Date: Thu, 24 Oct 2013 11:32:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1746) CDI beans in static modules
 cannot see each other
In-Reply-To: <JIRA.12497127.1374582261000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497127.1374582261000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497127.1374582261000.16200.1382628722403@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Hartinger updated WFLY-1746:
----------------------------------

    Fix Version/s: 8.0.0.CR1

    
> CDI beans in static modules cannot see each other
> -------------------------------------------------
>
>                 Key: WFLY-1746
>                 URL: https://issues.jboss.org/browse/WFLY-1746
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Stuart Douglas
>            Assignee: Jozef Hartinger
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 11:34:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 24 Oct 2013 11:34:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2379) Can't call "describe" via JMX
In-Reply-To: <JIRA.12508718.1382628380000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508718.1382628380000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508718.1382628380000.16221.1382628842258@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2379:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1023100

    
> Can't call "describe" via JMX
> -----------------------------
>
>                 Key: WFLY-2379
>                 URL: https://issues.jboss.org/browse/WFLY-2379
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, JMX
>            Reporter: Ladislav Thon
>            Assignee: Kabir Khan
>            Priority: Minor
>              Labels: rbac-filed-by-qa
>
> It's not possible to call "non-published" operations (those that are not visible in the resource tree, e.g. {{describe}}) via JMX, while it's entirely possible to call them via CLI (e.g. {{/subsystem=security:describe}}) and other management interfaces.
> The problem lies in the fact that {{ModelControllerMBeanHelper.invoke}} method checks {{if (!accessControl.isExecutableOperation(operationName))}} and the {{isExecutableOperation}} method assumes that the operation will be visible in the resource tree. In fact, there is a comment stating _should not happen_, but now we know that it indeed _can_ happen.
> What's more, it gives a misleading error message. The {{isExecutableOperation}} returns {{false}} for unknown operations, which results in {{Not authorized to invoke operation}} message. Which is wrong in two different ways simultaneously: 1. the problem isn't authorization, but the fact that the operation can't be found; 2. the user (e.g. in the {{SuperUser}} role) _is_ authorized.
> I'm considering this low priority, because 1. JMX is likely to be very rarely used to access the management interface, 2. hiding information isn't nearly as important as leaking them, 3. non-published operations aren't nearly as important as the published ones. It's worth a JIRA nevertheless.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 11:36:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 24 Oct 2013 11:36:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2379) Can't call "describe" via JMX
In-Reply-To: <JIRA.12508718.1382628380000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508718.1382628380000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508718.1382628380000.16228.1382628962174@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824692#comment-12824692 ] 

RH Bugzilla Integration commented on WFLY-2379:
-----------------------------------------------

Ladislav Thon <lthon at redhat.com> made a comment on [bug 1023100|https://bugzilla.redhat.com/show_bug.cgi?id=1023100]

Description of problem:

It's not possible to call "non-published" operations (those that are not visible in the resource tree, e.g. "describe") via JMX, while it's entirely possible to call them via CLI (e.g. "/subsystem=security:describe") and other management interfaces.

The problem lies in the fact that "ModelControllerMBeanHelper.invoke" method checks "if (!accessControl.isExecutableOperation(operationName))" and the "isExecutableOperation" method assumes that the operation will be visible in the resource tree. In fact, there is a comment stating "should not happen", but now we know that it indeed _can_ happen.

What's more, it gives a misleading error message. The "isExecutableOperation" returns "false" for unknown operations, which results in "Not authorized to invoke operation" message. Which is wrong in two different ways simultaneously: 1. the problem isn't authorization, but the fact that the operation can't be found; 2. the user (e.g. in the SuperUser role) is authorized.

I'm considering this low priority, because 1. JMX is likely to be very rarely used to access the management interface, 2. hiding information isn't nearly as important as leaking them, 3. non-published operations aren't nearly as important as the published ones.

Version-Release number of selected component (if applicable):

6.2.0.ER6

How reproducible:

Always

Steps to Reproduce:
1. Start EAP in standalone mode
2. Try to invoke the equivalent of "/subsystem=security:describe" via JMX programmatically against the running EAP

Actual results:

JBAS011363: Not authorized to invoke operation: 'describe'

Expected results:

The equivalent of the result in CLI.
                
> Can't call "describe" via JMX
> -----------------------------
>
>                 Key: WFLY-2379
>                 URL: https://issues.jboss.org/browse/WFLY-2379
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, JMX
>            Reporter: Ladislav Thon
>            Assignee: Kabir Khan
>            Priority: Minor
>              Labels: rbac-filed-by-qa
>
> It's not possible to call "non-published" operations (those that are not visible in the resource tree, e.g. {{describe}}) via JMX, while it's entirely possible to call them via CLI (e.g. {{/subsystem=security:describe}}) and other management interfaces.
> The problem lies in the fact that {{ModelControllerMBeanHelper.invoke}} method checks {{if (!accessControl.isExecutableOperation(operationName))}} and the {{isExecutableOperation}} method assumes that the operation will be visible in the resource tree. In fact, there is a comment stating _should not happen_, but now we know that it indeed _can_ happen.
> What's more, it gives a misleading error message. The {{isExecutableOperation}} returns {{false}} for unknown operations, which results in {{Not authorized to invoke operation}} message. Which is wrong in two different ways simultaneously: 1. the problem isn't authorization, but the fact that the operation can't be found; 2. the user (e.g. in the {{SuperUser}} role) _is_ authorized.
> I'm considering this low priority, because 1. JMX is likely to be very rarely used to access the management interface, 2. hiding information isn't nearly as important as leaking them, 3. non-published operations aren't nearly as important as the published ones. It's worth a JIRA nevertheless.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 11:36:02 2013
From: jira-events at lists.jboss.org (metcox metcox (JIRA))
Date: Thu, 24 Oct 2013 11:36:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1723) Corrupted input stream on
	STATE exchange
In-Reply-To: <JIRA.12508721.1382628956020@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508721.1382628956020@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508721.1382628956020.16254.1382628962789@jira02.app.mwc.hst.phx2.redhat.com>

metcox metcox created JGRP-1723:
-----------------------------------

             Summary: Corrupted input stream on STATE exchange
                 Key: JGRP-1723
                 URL: https://issues.jboss.org/browse/JGRP-1723
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 3.4, 3.3.4
         Environment: java7u25
            Reporter: metcox metcox
            Assignee: Bela Ban


Using the pbcast.STATE state transfer protocol with a high volume of data, the receiver member on setState seem to get a corrupted input stream.

I was able to reproduce this issue with a simple project in which the data get corrupted from the 8192th byte. So it may be related to frag size with default value of 8192. We get this bug either with FRAG or FRAG2.

Related discussion on the mailing list could be found here : http://jgroups.1086181.n5.nabble.com/Corrupted-input-stream-on-STATE-exchange-td9938.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 11:40:02 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Thu, 24 Oct 2013 11:40:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2379) Can't call "describe" via JMX
In-Reply-To: <JIRA.12508718.1382628380000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508718.1382628380000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508718.1382628380000.16259.1382629201999@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824694#comment-12824694 ] 

Ladislav Thon commented on WFLY-2379:
-------------------------------------

I'm not asking to publicize it. In fact, I would be entirely satisfied if the non-published operations were only accessible via the native protocol and other management interfaces gave a "not found" response. We can reformulate this issue to say "give me a proper error message, please".
                
> Can't call "describe" via JMX
> -----------------------------
>
>                 Key: WFLY-2379
>                 URL: https://issues.jboss.org/browse/WFLY-2379
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, JMX
>            Reporter: Ladislav Thon
>            Assignee: Kabir Khan
>            Priority: Minor
>              Labels: rbac-filed-by-qa
>
> It's not possible to call "non-published" operations (those that are not visible in the resource tree, e.g. {{describe}}) via JMX, while it's entirely possible to call them via CLI (e.g. {{/subsystem=security:describe}}) and other management interfaces.
> The problem lies in the fact that {{ModelControllerMBeanHelper.invoke}} method checks {{if (!accessControl.isExecutableOperation(operationName))}} and the {{isExecutableOperation}} method assumes that the operation will be visible in the resource tree. In fact, there is a comment stating _should not happen_, but now we know that it indeed _can_ happen.
> What's more, it gives a misleading error message. The {{isExecutableOperation}} returns {{false}} for unknown operations, which results in {{Not authorized to invoke operation}} message. Which is wrong in two different ways simultaneously: 1. the problem isn't authorization, but the fact that the operation can't be found; 2. the user (e.g. in the {{SuperUser}} role) _is_ authorized.
> I'm considering this low priority, because 1. JMX is likely to be very rarely used to access the management interface, 2. hiding information isn't nearly as important as leaking them, 3. non-published operations aren't nearly as important as the published ones. It's worth a JIRA nevertheless.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 11:40:02 2013
From: jira-events at lists.jboss.org (metcox metcox (JIRA))
Date: Thu, 24 Oct 2013 11:40:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1723) Corrupted input stream on
	STATE exchange
In-Reply-To: <JIRA.12508721.1382628956000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508721.1382628956000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508721.1382628956000.16263.1382629202097@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

metcox metcox updated JGRP-1723:
--------------------------------

    Attachment: corruptedStreamOnStateExchange.zip


Here is the test case i was talking about that reproduces the bug
                
> Corrupted input stream on STATE exchange
> ----------------------------------------
>
>                 Key: JGRP-1723
>                 URL: https://issues.jboss.org/browse/JGRP-1723
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.3.4, 3.4
>         Environment: java7u25
>            Reporter: metcox metcox
>            Assignee: Bela Ban
>         Attachments: corruptedStreamOnStateExchange.zip
>
>
> Using the pbcast.STATE state transfer protocol with a high volume of data, the receiver member on setState seem to get a corrupted input stream.
> I was able to reproduce this issue with a simple project in which the data get corrupted from the 8192th byte. So it may be related to frag size with default value of 8192. We get this bug either with FRAG or FRAG2.
> Related discussion on the mailing list could be found here : http://jgroups.1086181.n5.nabble.com/Corrupted-input-stream-on-STATE-exchange-td9938.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 12:06:02 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Thu, 24 Oct 2013 12:06:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2379) Can't call "describe" via JMX
In-Reply-To: <JIRA.12508718.1382628380000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508718.1382628380000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508718.1382628380000.16294.1382630762027@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824701#comment-12824701 ] 

Ladislav Thon commented on WFLY-2379:
-------------------------------------

(To make myself entirely clear: what I'm asking for is consistency. I can't see a reason why it's possible to invoke {{:describe}} via the HTTP interface, but not via JMX. Either both should  succeed, or both should fail with a _not found_ message.)
                
> Can't call "describe" via JMX
> -----------------------------
>
>                 Key: WFLY-2379
>                 URL: https://issues.jboss.org/browse/WFLY-2379
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, JMX
>            Reporter: Ladislav Thon
>            Assignee: Kabir Khan
>            Priority: Minor
>              Labels: rbac-filed-by-qa
>
> It's not possible to call "non-published" operations (those that are not visible in the resource tree, e.g. {{describe}}) via JMX, while it's entirely possible to call them via CLI (e.g. {{/subsystem=security:describe}}) and other management interfaces.
> The problem lies in the fact that {{ModelControllerMBeanHelper.invoke}} method checks {{if (!accessControl.isExecutableOperation(operationName))}} and the {{isExecutableOperation}} method assumes that the operation will be visible in the resource tree. In fact, there is a comment stating _should not happen_, but now we know that it indeed _can_ happen.
> What's more, it gives a misleading error message. The {{isExecutableOperation}} returns {{false}} for unknown operations, which results in {{Not authorized to invoke operation}} message. Which is wrong in two different ways simultaneously: 1. the problem isn't authorization, but the fact that the operation can't be found; 2. the user (e.g. in the {{SuperUser}} role) _is_ authorized.
> I'm considering this low priority, because 1. JMX is likely to be very rarely used to access the management interface, 2. hiding information isn't nearly as important as leaking them, 3. non-published operations aren't nearly as important as the published ones. It's worth a JIRA nevertheless.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 12:10:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 24 Oct 2013 12:10:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1458) Allow specifying timeout for
 org.jboss.as.arquillian.container.ManagementClient.isServerInRunningState()
In-Reply-To: <JIRA.12493672.1370454383000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493672.1370454383000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493672.1370454383000.16305.1382631002027@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824703#comment-12824703 ] 

RH Bugzilla Integration commented on WFLY-1458:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1021487|https://bugzilla.redhat.com/show_bug.cgi?id=1021487] from ASSIGNED to POST
                
> Allow specifying timeout for org.jboss.as.arquillian.container.ManagementClient.isServerInRunningState()
> --------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1458
>                 URL: https://issues.jboss.org/browse/WFLY-1458
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Test Suite
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Richard Achmatowicz
>            Assignee: Ladislav Thon
>             Fix For: 8.0.0.CR1
>
>         Attachments: thread.dump.txt
>
>
> When deploying a container, Arquillian will use a management client to connect to the deployed container to see if it is in a running state. If the management address and management port are incorrect, the connection to the container hangs indefinitely.
> Please allow configuration of a timeout so that if the connection paramaters are not correct, at least the container deployment will fail with a meaningful error.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 12:14:02 2013
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Thu, 24 Oct 2013 12:14:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2380) DefaultJMSConnectionFactory
 binding must be accessing from application client deployment
In-Reply-To: <JIRA.12508725.1382631204402@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508725.1382631204402@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508725.1382631204402.16326.1382631242152@jira02.app.mwc.hst.phx2.redhat.com>

Jeff Mesnil created WFLY-2380:
---------------------------------

             Summary: DefaultJMSConnectionFactory binding must be accessing from application client deployment
                 Key: WFLY-2380
                 URL: https://issues.jboss.org/browse/WFLY-2380
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: JMS
            Reporter: Jeff Mesnil
            Assignee: Jeff Mesnil
             Fix For: 8.0.0.CR1


According to the spec (and TCK), an application client deployment must be able to look up the default JMS Connection Factory from "java:comp/DefaultJMSConnectionFactory" but this binding is no longer added to the module description in DefaultJMSConnectionFactoryBindingProcessor.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 12:18:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 24 Oct 2013 12:18:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2379) Can't call "describe" via JMX
In-Reply-To: <JIRA.12508718.1382628380000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508718.1382628380000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508718.1382628380000.16337.1382631482242@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824709#comment-12824709 ] 

RH Bugzilla Integration commented on WFLY-2379:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> made a comment on [bug 1023100|https://bugzilla.redhat.com/show_bug.cgi?id=1023100]

I changed the title. We won't be exposing these over the other interfaces. This isn't really related to RBAC.
                
> Can't call "describe" via JMX
> -----------------------------
>
>                 Key: WFLY-2379
>                 URL: https://issues.jboss.org/browse/WFLY-2379
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, JMX
>            Reporter: Ladislav Thon
>            Assignee: Kabir Khan
>            Priority: Minor
>              Labels: rbac-filed-by-qa
>
> It's not possible to call "non-published" operations (those that are not visible in the resource tree, e.g. {{describe}}) via JMX, while it's entirely possible to call them via CLI (e.g. {{/subsystem=security:describe}}) and other management interfaces.
> The problem lies in the fact that {{ModelControllerMBeanHelper.invoke}} method checks {{if (!accessControl.isExecutableOperation(operationName))}} and the {{isExecutableOperation}} method assumes that the operation will be visible in the resource tree. In fact, there is a comment stating _should not happen_, but now we know that it indeed _can_ happen.
> What's more, it gives a misleading error message. The {{isExecutableOperation}} returns {{false}} for unknown operations, which results in {{Not authorized to invoke operation}} message. Which is wrong in two different ways simultaneously: 1. the problem isn't authorization, but the fact that the operation can't be found; 2. the user (e.g. in the {{SuperUser}} role) _is_ authorized.
> I'm considering this low priority, because 1. JMX is likely to be very rarely used to access the management interface, 2. hiding information isn't nearly as important as leaking them, 3. non-published operations aren't nearly as important as the published ones. It's worth a JIRA nevertheless.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 13:30:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 24 Oct 2013 13:30:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-369) Domain mode: kill an
	unresponsive JVM
In-Reply-To: <JIRA.12480351.1354566315000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12480351.1354566315000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12480351.1354566315000.16448.1382635802530@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824733#comment-12824733 ] 

RH Bugzilla Integration commented on WFLY-369:
----------------------------------------------

Dimitris Andreadis <dandread at redhat.com> made a comment on [bug 901232|https://bugzilla.redhat.com/show_bug.cgi?id=901232]

Hi Brian, the HAL upgrade is merged so I assume this needs can be marked MODIFIED, right?
                
> Domain mode: kill an unresponsive JVM
> -------------------------------------
>
>                 Key: WFLY-369
>                 URL: https://issues.jboss.org/browse/WFLY-369
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Dennis Reed
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.Alpha1
>
>
> If an AS instance gets into a state where it cannot be controlled normally by the host controller, local OS commands must be used to kill it.
> It would be helpful to be able to kill an unresponsive JVM through the management interface.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 13:38:02 2013
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Thu, 24 Oct 2013 13:38:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBASMP-56) Add support for maven 3.1
In-Reply-To: <JIRA.12508730.1382636249341@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508730.1382636249341@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508730.1382636249341.16454.1382636282010@jira02.app.mwc.hst.phx2.redhat.com>

James Perkins created JBASMP-56:
-----------------------------------

             Summary: Add support for maven 3.1
                 Key: JBASMP-56
                 URL: https://issues.jboss.org/browse/JBASMP-56
             Project: JBoss AS Maven Plugins
          Issue Type: Feature Request
            Reporter: James Perkins
            Assignee: James Perkins
             Fix For: 7.5.Final


Maven 3.1.x uses eclipse aether and maven 3.0.x uses Sonatype aether. There is a need to support both versions on the {{run}} and {{start}} goals.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 14:22:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 24 Oct 2013 14:22:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-369) Domain mode: kill an
	unresponsive JVM
In-Reply-To: <JIRA.12480351.1354566315000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12480351.1354566315000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12480351.1354566315000.16526.1382638922001@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824745#comment-12824745 ] 

RH Bugzilla Integration commented on WFLY-369:
----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> made a comment on [bug 901232|https://bugzilla.redhat.com/show_bug.cgi?id=901232]

Yes; thanks for the reminder!
                
> Domain mode: kill an unresponsive JVM
> -------------------------------------
>
>                 Key: WFLY-369
>                 URL: https://issues.jboss.org/browse/WFLY-369
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Dennis Reed
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.Alpha1
>
>
> If an AS instance gets into a state where it cannot be controlled normally by the host controller, local OS commands must be used to kill it.
> It would be helpful to be able to kill an unresponsive JVM through the management interface.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 14:22:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 24 Oct 2013 14:22:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-369) Domain mode: kill an
	unresponsive JVM
In-Reply-To: <JIRA.12480351.1354566315000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12480351.1354566315000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12480351.1354566315000.16532.1382638922128@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824747#comment-12824747 ] 

RH Bugzilla Integration commented on WFLY-369:
----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 901232|https://bugzilla.redhat.com/show_bug.cgi?id=901232] from POST to MODIFIED
                
> Domain mode: kill an unresponsive JVM
> -------------------------------------
>
>                 Key: WFLY-369
>                 URL: https://issues.jboss.org/browse/WFLY-369
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Dennis Reed
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.Alpha1
>
>
> If an AS instance gets into a state where it cannot be controlled normally by the host controller, local OS commands must be used to kill it.
> It would be helpful to be able to kill an unresponsive JVM through the management interface.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 14:28:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 24 Oct 2013 14:28:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1810) SFSB tx lock not released in
 exception was thrown in Synchronization callback
In-Reply-To: <JIRA.12497840.1375446538000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497840.1375446538000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497840.1375446538000.16561.1382639282283@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824756#comment-12824756 ] 

RH Bugzilla Integration commented on WFLY-1810:
-----------------------------------------------

Dimitris Andreadis <dandread at redhat.com> made a comment on [bug 990102|https://bugzilla.redhat.com/show_bug.cgi?id=990102]

Assigning jpai at redhat.com EJB issues to david.lloyd at redhat.com. Please re-assign to Cheng or others as needed.
                
> SFSB tx lock not released in exception was thrown in Synchronization callback
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-1810
>                 URL: https://issues.jboss.org/browse/WFLY-1810
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Paul Ferraro
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Alpha4
>
>
> Because the owning tx was never pushed into the OwnableReentrantLock ownership stack in org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.handleThrowableInTxSync(...).
> This will cause subsequent Lock.tryAcquire(..) to fail for a different tx.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 14:28:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 24 Oct 2013 14:28:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2021) EE Component interceptor
 chains should be stateless
In-Reply-To: <JIRA.12500214.1378475131000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500214.1378475131000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500214.1378475131000.16564.1382639282339@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824758#comment-12824758 ] 

RH Bugzilla Integration commented on WFLY-2021:
-----------------------------------------------

Dimitris Andreadis <dandread at redhat.com> made a comment on [bug 1022265|https://bugzilla.redhat.com/show_bug.cgi?id=1022265]

Assigning jpai at redhat.com EJB issues to david.lloyd at redhat.com. Please re-assign to Cheng or others as needed.
                
> EE Component interceptor chains should be stateless
> ---------------------------------------------------
>
>                 Key: WFLY-2021
>                 URL: https://issues.jboss.org/browse/WFLY-2021
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: EE, EJB
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>
> This will allow them to be shared by all instances, rather than having a new chain allocated for each method.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 14:28:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 24 Oct 2013 14:28:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-834) org.jboss.as.cmp dependency
 added only to EJB subdeployments
In-Reply-To: <JIRA.12487745.1363921408000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12487745.1363921408000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487745.1363921408000.16579.1382639282635@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824768#comment-12824768 ] 

RH Bugzilla Integration commented on WFLY-834:
----------------------------------------------

Dimitris Andreadis <dandread at redhat.com> made a comment on [bug 924548|https://bugzilla.redhat.com/show_bug.cgi?id=924548]

Assigning jpai at redhat.com EJB issues to david.lloyd at redhat.com. Please re-assign to Cheng or others as needed.
                
> org.jboss.as.cmp dependency added only to EJB subdeployments
> ------------------------------------------------------------
>
>                 Key: WFLY-834
>                 URL: https://issues.jboss.org/browse/WFLY-834
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>            Reporter: James Livingston
>            Assignee: jaikiran pai
>
> The CMP code adds a module dependency on org.jboss.as.cmp if there are any CMP beans in it (via the CMP marker).
> If the <ejb-class> refers to a class not in the EJB jar itself, such as in a library jar, this will result in the proxy being created in the EAR classloader and not being able to find JBoss' CmpProxy class.
> The solution is to add the dependency to the top-level deployment so it is available in all sub-deployments, rather than the such the ejb subdeployment.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 14:30:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 24 Oct 2013 14:30:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2011) jboss-ejb3.xml deployment
 descriptor is not parsed correct for the clustering element
In-Reply-To: <JIRA.12500087.1378394515000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500087.1378394515000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500087.1378394515000.16587.1382639403527@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824770#comment-12824770 ] 

RH Bugzilla Integration commented on WFLY-2011:
-----------------------------------------------

Dimitris Andreadis <dandread at redhat.com> made a comment on [bug 1004856|https://bugzilla.redhat.com/show_bug.cgi?id=1004856]

Assigning jpai at redhat.com EJB issues to david.lloyd at redhat.com. Please re-assign to Cheng or others as needed.
                
> jboss-ejb3.xml deployment descriptor is not parsed correct for the clustering element
> -------------------------------------------------------------------------------------
>
>                 Key: WFLY-2011
>                 URL: https://issues.jboss.org/browse/WFLY-2011
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Wolf-Dieter Fink
>            Assignee: jaikiran pai
>              Labels: ejb-jar.xml
>
> If beans of an application are marked as clustered by using the jboss-ejb3.xml DD the behaviour is not consistent.
> From the XSD the <ejb-name> element can not be added multiple times.
> And the following configuration will be not valid:
>   <assembly-descriptor>
>     <c:clustering>
>       <ejb-name>Bean1</ejb-name>
>       <ejb-name>Bean2</ejb-name>
>       <c:clustered>true</c:clustered>
>     </c:clustering>
>   </assembly-descriptor>
> The parser should throw an Exception and the application should not be deployed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 14:30:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 24 Oct 2013 14:30:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-88) Recovery not fully triggered
 when distributed transaction falls down at prepare phase of 2PC
In-Reply-To: <JIRA.12473332.1346248890000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12473332.1346248890000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12473332.1346248890000.16601.1382639403920@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824776#comment-12824776 ] 

RH Bugzilla Integration commented on WFLY-88:
---------------------------------------------

Dimitris Andreadis <dandread at redhat.com> made a comment on [bug 952746|https://bugzilla.redhat.com/show_bug.cgi?id=952746]

Assigning jpai at redhat.com EJB issues to david.lloyd at redhat.com. Please re-assign to Cheng or others as needed.
                
> Recovery not fully triggered when distributed transaction falls down at prepare phase of 2PC
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-88
>                 URL: https://issues.jboss.org/browse/WFLY-88
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB, Remoting
>            Reporter: Ivo Studensky
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Alpha1
>
>         Attachments: logs_prepareHaltClient.tgz
>
>
> It looks like recovery process is not fully triggered on a distributed transaction when the transaction falls down at prepare phase of 2PC. In the new crash recovery tests over propagated transactions only one of two servers recovers from the crash, but the other keeps an unfinished tx in its tx log. 
> It corresponds to prepareHaltClient and prepareHaltServer test methods of org.jboss.as.test.jbossts.crashrec.txpropagation.TxPropagationCrashRecoveryTestCase, see JBQA-2604 for general description of the new tests. The prepareHaltClient test crashes the server which initiated the transaction, while as the prepareHaltServer test crashes the second server.
> The tests are written against EAP6.x branch, so for reproducing this it is needed a built server from the 7.1 branch of AS7.
> Steps to reproduce.
> 1. git clone -b as7 git://git.app.eng.bos.redhat.com/jbossqe/eap-tests-transactions.git
> 2. cd eap-tests-transactions
> 3. git checkout tx_propag_crashrec_tests
> 4a. mvn clean verify -Dtest=TxPropagationCrashRecoveryTestCase#prepareHaltClient -Djboss.dist=<path to jboss-as-7.1.3.Final-SNAPSHOT>
> or
> 4b. mvn clean verify -Dtest=TxPropagationCrashRecoveryTestCase#prepareHaltServer -Djboss.dist=<path to jboss-as-7.1.3.Final-SNAPSHOT>
> The logs of prepareHaltClient run attached to this jira.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 15:03:01 2013
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Thu, 24 Oct 2013 15:03:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBASMP-55) Undeploy requires dependency
 resolution of artifacts in scope: runtime
In-Reply-To: <JIRA.12508236.1382213434000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508236.1382213434000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508236.1382213434000.16664.1382641381968@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBASMP-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins reopened JBASMP-55:
---------------------------------


    
> Undeploy requires dependency resolution of artifacts in scope: runtime
> ----------------------------------------------------------------------
>
>                 Key: JBASMP-55
>                 URL: https://issues.jboss.org/browse/JBASMP-55
>             Project: JBoss AS Maven Plugins
>          Issue Type: Bug
>            Reporter: Dojcs?k S?ndor
>            Assignee: James Perkins
>
> I attached deploy goal to the clean lifecycle phase. I changed resolution scope in Undeploy.java to ResolutionScope.NONE. After I do not require mvn install for dependency resolution before I run clean.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Thu Oct 24 15:03:02 2013
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Thu, 24 Oct 2013 15:03:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBASMP-55) Undeploy requires dependency
 resolution of artifacts in scope: runtime
In-Reply-To: <JIRA.12508236.1382213434000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508236.1382213434000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508236.1382213434000.16667.1382641382030@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBASMP-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824786#comment-12824786 ] 

James Perkins commented on JBASMP-55:
-------------------------------------

It looks like I completely misunderstood (and misread) the issue here. This is valid there should be no {{ResolutionScope}} for the undeploy goals. Thanks for the clarification.
                
> Undeploy requires dependency resolution of artifacts in scope: runtime
> ----------------------------------------------------------------------
>
>                 Key: JBASMP-55
>                 URL: https://issues.jboss.org/browse/JBASMP-55
>             Project: JBoss AS Maven Plugins
>          Issue Type: Bug
>            Reporter: Dojcs?k S?ndor
>            Assignee: James Perkins
>
> I attached deploy goal to the clean lifecycle phase. I changed resolution scope in Undeploy.java to ResolutionScope.NONE. After I do not require mvn install for dependency resolution before I run clean.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Thu Oct 24 15:14:02 2013
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Thu, 24 Oct 2013 15:14:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBBUILD-732) Lock Exception
In-Reply-To: <JIRA.12508248.1382251736000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508248.1382251736000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508248.1382251736000.16677.1382642042034@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBBUILD-732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier closed JBBUILD-732.
-----------------------------

    Resolution: Cannot Reproduce Bug


Not sure what this has to do with the jboss-parent pom
                
> Lock Exception
> --------------
>
>                 Key: JBBUILD-732
>                 URL: https://issues.jboss.org/browse/JBBUILD-732
>             Project: JBoss Build System
>          Issue Type: Bug
>          Components: JBoss Parent POM
>    Affects Versions: JBoss Parent POM - 9
>         Environment: Windows
>            Reporter: chandra shekhar joshi
>            Assignee: Paul Gier
>
> java.sql.SQLException: Unable to obtain lock in 60 seconds
> Caused by: java.sql.SQLException: Unable to obtain lock in 60 seconds: org.jboss.resource.adapter.jdbc.xa.XAManagedConnection at 1d314d
>     at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.tryLock(BaseWrapperManagedConnection.java:267)
>     at org.jboss.resource.adapter.jdbc.WrappedConnection.lock(WrappedConnection.java:79)
>     at org.jboss.resource.adapter.jdbc.WrappedConnection.prepareStatement(WrappedConnection.java:237)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 16:55:02 2013
From: jira-events at lists.jboss.org (Marco Rietveld (JIRA))
Date: Thu, 24 Oct 2013 16:55:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBRULES-3226) Make the Drools hudson
 jobs compile using the Java 5 compiler.
In-Reply-To: <JIRA.12447902.1317115850000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12447902.1317115850000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12447902.1317115850000.16833.1382648102242@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBRULES-3226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marco Rietveld resolved JBRULES-3226.
-------------------------------------

    Resolution: Out of Date

    
> Make the Drools hudson jobs compile using the Java 5 compiler. 
> ---------------------------------------------------------------
>
>                 Key: JBRULES-3226
>                 URL: https://issues.jboss.org/browse/JBRULES-3226
>             Project: JBRULES
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.3.0.Final
>            Reporter: Marco Rietveld
>            Assignee: Geoffrey De Smet
>            Priority: Minor
>             Fix For: FUTURE
>
>
> The Hudson/Jenkins jobs at https://hudson.jboss.org/jenkins/view/Drools%20jBPM/ currently use the java 6 compiler to build drools. 
> However, Drools (and jBPM) are explicitly Java 5 compliant. Because the jobs use Java 6, code which is not compatible with Java 5 sometimes gets into the source tree.  
> It would be helpful if all Drools jobs ran under the Java 5 JDK. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 17:30:01 2013
From: jira-events at lists.jboss.org (David Jorm (JIRA))
Date: Thu, 24 Oct 2013 17:30:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1721) AUTH and ENCRYPT protocols
 configured with plain text passwords
In-Reply-To: <JIRA.12508425.1382426440000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508425.1382426440000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508425.1382426440000.16870.1382650201954@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824819#comment-12824819 ] 

David Jorm commented on JGRP-1721:
----------------------------------

Usage of vault is a mandatory security feature where applicable, i.e. in XML config files for a component that will run on WildFly/EAP. When passwords are set programmatically by the user, or via another mechanism, then it is not applicable.
                
> AUTH and ENCRYPT protocols configured with plain text passwords
> ---------------------------------------------------------------
>
>                 Key: JGRP-1721
>                 URL: https://issues.jboss.org/browse/JGRP-1721
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Martin Gencur
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> The following parameters of AUTH protocol are stored as plain text:
> * keystore_password
> The following parameters of ENCRYPT protocol are stored as plain text:
> * store_password
> * key_password
> Example:
> {code}
> <ENCRYPT key_store_name="defaultStore.keystore" store_password="changeit" alias="myKey"/>
> {code}
> Requirements for storing passwords: https://docspace.corp.redhat.com/docs/DOC-131628

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 18:59:02 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 24 Oct 2013 18:59:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2018) Configuring
 HttpsListenerServices xnio OptionMap
In-Reply-To: <JIRA.12500197.1378463685000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500197.1378463685000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500197.1378463685000.16980.1382655542025@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-2018:
------------------------------

    Fix Version/s: 8.0.0.CR1

    
> Configuring HttpsListenerServices xnio OptionMap
> ------------------------------------------------
>
>                 Key: WFLY-2018
>                 URL: https://issues.jboss.org/browse/WFLY-2018
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Alpha4
>         Environment: Linux, Java 7, WildFly from git
>            Reporter: Bernd Koecke
>            Assignee: Tomaz Cerar
>             Fix For: 8.0.0.CR1
>
>
> There was another issue (WFLY-1924) when two WildFly server called each other through SSL/TLS. This is all done and its working. But during the discussion it came up that the configuration of the xnio endpoint in class {{org.wildfly.extension.undertow.HttpsListenerService.startListening}} is hardcoded. In other parts of the system I have the ability to define my own set of options for xnios OptionMap through CLI. Would it be a good idea to enhance the Http(s)ListenerService that the defaults are still there, but can be overwritten from the XML/CLI?
> Because I can now configure the client side, I don't really need it in the undertow subsystem at the moment. But there my be other use cases where a configuration option in the above listener would be nice.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 21:09:02 2013
From: jira-events at lists.jboss.org (hui gao (JIRA))
Date: Thu, 24 Oct 2013 21:09:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2125) wildfly8 can't identify
	port-offset
In-Reply-To: <JIRA.12501168.1379906107000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501168.1379906107000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501168.1379906107000.17088.1382663342250@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

hui gao closed WFLY-2125.
-------------------------



OK,thanks very much.

                
> wildfly8 can't identify port-offset
> -----------------------------------
>
>                 Key: WFLY-2125
>                 URL: https://issues.jboss.org/browse/WFLY-2125
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 8.0.0.Alpha4
>         Environment: wildfly-8.0.0.Alpha4.tar.gz
> jdk-7u25-linux-i586.rpm
> mod_cluster-1.2.0.Final-linux2-x64-ssl.tar.gz
>            Reporter: hui gao
>            Assignee: Tomaz Cerar
>             Fix For: 8.0.0.Beta1
>
>
> I installed wildfly8 and mod_cluster  reference steps of https://docs.jboss.org/author/display/AS72/AS7+Cluster+Howto
> The cluster contains four servers,start up with domain mode:
> 10.19.222.52:server1/server2
> 10.19.222.53:server3/server4
> 10.19.222.50:apache
> But it only detects server1 and server3 which the port is 8009.
> The port-offset is 100,it can't identify the other port(8109) for server2 and server4.
> Search errorlog of Apache ,the proxy:AJP always acquired connection through initial AJP port(8009) defined in domain.xml.
> [Fri Sep 13 21:07:40 2013] [debug] mod_proxy_cluster.c(773): ajp_cping_cpong: Done
> [Fri Sep 13 21:07:40 2013] [debug] proxy_util.c(2029): proxy: ajp: has released connection for (10.19.222.52)
> [Fri Sep 13 21:07:43 2013] [debug] proxy_util.c(2011): proxy: ajp: has acquired connection for (10.19.222.53)
> [Fri Sep 13 21:07:43 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://10.19.222.53:8009/ to 10.19.222.53:8009
> [Fri Sep 13 21:07:43 2013] [debug] proxy_util.c(2193): proxy: connected ajp://10.19.222.53:8009/ to 10.19.222.53:8009
> [Fri Sep 13 21:07:43 2013] [debug] mod_proxy_cluster.c(773): ajp_cping_cpong: Done
> [Fri Sep 13 21:07:43 2013] [debug] proxy_util.c(2029): proxy: ajp: has released connection for (10.19.222.53)
> [Fri Sep 13 21:07:45 2013] [debug] proxy_util.c(2011): proxy: ajp: has acquired connection for (10.19.222.52)
> [Fri Sep 13 21:07:45 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://10.19.222.52:8009/ to 10.19.222.52:8009
> [Fri Sep 13 21:07:45 2013] [debug] proxy_util.c(2193): proxy: connected ajp://10.19.222.52:8009/ to 10.19.222.52:8009
> [Fri Sep 13 21:07:45 2013] [debug] mod_proxy_cluster.c(773): ajp_cping_cpong: Done
> [Fri Sep 13 21:07:45 2013] [debug] proxy_util.c(2029): proxy: ajp: has released connection for (10.19.222.52)
> [Fri Sep 13 21:07:46 2013] [debug] mod_manager.c(1667): manager_trans STATUS (/)
> [Fri Sep 13 21:07:46 2013] [debug] mod_manager.c(2323): manager_handler STATUS (/) processing: "JVMRoute=2644d861-0ead-352c-ba1e-619f1e1f25e8&Load=100"
> [Fri Sep 13 21:07:46 2013] [debug] mod_manager.c(1404): Processing STATUS
> [Fri Sep 13 21:07:46 2013] [debug] proxy_util.c(2011): proxy: ajp: has acquired connection for (10.19.222.53)
> [Fri Sep 13 21:07:46 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://10.19.222.53:8009/ to 10.19.222.53:8009
> [Fri Sep 13 21:07:46 2013] [debug] proxy_util.c(2193): proxy: connected ajp://10.19.222.53:8009/ to 10.19.222.53:8009
> [Fri Sep 13 21:07:46 2013] [debug] mod_proxy_cluster.c(773): ajp_cping_cpong: Done
> [Fri Sep 13 21:07:46 2013] [debug] proxy_util.c(2029): proxy: ajp: has released connection for (10.19.222.53)
> [Fri Sep 13 21:07:46 2013] [debug] mod_manager.c(2366): manager_handler STATUS  OK
> [Fri Sep 13 21:07:47 2013] [debug] mod_manager.c(1667): manager_trans STATUS (/)
> [Fri Sep 13 21:07:47 2013] [debug] mod_manager.c(2323): manager_handler STATUS (/) processing: "JVMRoute=ea81701b-f847-34a8-9534-0ac5c489af90&Load=100"
> [Fri Sep 13 21:07:47 2013] [debug] mod_manager.c(1404): Processing STATUS
> [Fri Sep 13 21:07:47 2013] [debug] proxy_util.c(2011): proxy: ajp: has acquired connection for (10.19.222.52)
> [Fri Sep 13 21:07:47 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://10.19.222.52:8009/ to 10.19.222.52:8009
> [Fri Sep 13 21:07:47 2013] [debug] proxy_util.c(2193): proxy: connected ajp://10.19.222.52:8009/ to 10.19.222.52:8009

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 21:13:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 24 Oct 2013 21:13:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1094) Use own JSSE Provider for
	http Connector
In-Reply-To: <JIRA.12480379.1354616410000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12480379.1354616410000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12480379.1354616410000.17099.1382663582236@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824867#comment-12824867 ] 

RH Bugzilla Integration commented on WFLY-1094:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 956391|https://bugzilla.redhat.com/show_bug.cgi?id=956391] from POST to MODIFIED
                
> Use own JSSE Provider for http Connector
> ----------------------------------------
>
>                 Key: WFLY-1094
>                 URL: https://issues.jboss.org/browse/WFLY-1094
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Web (JBoss Web)
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Hauke Mehrtens
>            Assignee: Tomaz Cerar
>              Labels: https, jsse, ssl
>             Fix For: 8.0.0.Alpha1
>
>         Attachments: ssl-protocol.patch
>
>
> We are using our own JSSE Provider implementation for TLS to add support for HTTPS with preshared key to one http connector, while the others still use the default JSSE provider.
> In JBoss 5 we added sslProtocol="RFC4279", while RFC4279 is the name of our provider, to one Connector entry in the file server/default/deploy/jbossweb.sar/server.xml. This option is not available in JBoss 7.1 any more and we could not find a way to make one connector use our provider while the others are using the default one.
> To fix this issue for use we used the attached patch. We would like to get this patch into the next version of JBoss, so we do not have to modify the source code by our self any more. This patch was tested with JBoss 7.1.2, but it still applies against the master branch. If we should do any changed to the patch or if you want to get it in an other form please inform us.
> With this patch we are able to specify our JSSE provider like this:
> {code:xml}
> <connector name="httpspsk" protocol="HTTP/1.1" scheme="https" socket-binding="httpspsk" secure="true">
>   <ssl name="ssl" key-alias="intended purpose ssl test from bremen online services" password="123456" certificate-key-file="${jboss.server.config.dir}/governikus_ssl.jks" protocol="ALL" keystore-type="JKS" ssl_protocol="RFC4279"/>
> </connector>
> {code}
> This is related to Red Hat Customer Portal support case 00721624 "Additional JSSE Provider on socket bindings and connectors"

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 21:18:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 24 Oct 2013 21:18:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2371)
 SizeRotatingHandlerTestCase.rotationTest fails with "the file is bigger
 than allowed size"
In-Reply-To: <JIRA.12508645.1382597019000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508645.1382597019000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508645.1382597019000.17105.1382663882074@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824868#comment-12824868 ] 

RH Bugzilla Integration commented on WFLY-2371:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1020339|https://bugzilla.redhat.com/show_bug.cgi?id=1020339] from POST to MODIFIED
                
> SizeRotatingHandlerTestCase.rotationTest fails with "the file is bigger than allowed size"
> ------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2371
>                 URL: https://issues.jboss.org/browse/WFLY-2371
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Petr Kremensky
>            Assignee: Petr Kremensky
>
> The test org.jboss.as.test.integration.logging.operations.SizeRotatingHandlerTestCase.rotationTest consistently fails with:
> java.lang.AssertionError: This file is bigger than allowed rotate-size: size-rotating-reload-rotationTest.log.1
> Link to job:
> https://jenkins.mw.lab.eng.bos.redhat.com/job/eap-6x-manu-acceptance-as-ts-RHEL6_x86-oracleJDK6-srczip/25/testReport/junit/org.jboss.as.test.integration.logging.operations/SizeRotatingHandlerTestCase/rotationTest/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 21:20:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 24 Oct 2013 21:20:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1458) Allow specifying timeout for
 org.jboss.as.arquillian.container.ManagementClient.isServerInRunningState()
In-Reply-To: <JIRA.12493672.1370454383000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493672.1370454383000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493672.1370454383000.17110.1382664002071@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824869#comment-12824869 ] 

RH Bugzilla Integration commented on WFLY-1458:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1021487|https://bugzilla.redhat.com/show_bug.cgi?id=1021487] from POST to MODIFIED
                
> Allow specifying timeout for org.jboss.as.arquillian.container.ManagementClient.isServerInRunningState()
> --------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1458
>                 URL: https://issues.jboss.org/browse/WFLY-1458
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Test Suite
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Richard Achmatowicz
>            Assignee: Ladislav Thon
>             Fix For: 8.0.0.CR1
>
>         Attachments: thread.dump.txt
>
>
> When deploying a container, Arquillian will use a management client to connect to the deployed container to see if it is in a running state. If the management address and management port are incorrect, the connection to the container hangs indefinitely.
> Please allow configuration of a timeout so that if the connection paramaters are not correct, at least the container deployment will fail with a meaningful error.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 21:22:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 24 Oct 2013 21:22:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-758) AdvancedLdapLoginModule
 doesn't isn't mapping nested roles
In-Reply-To: <JIRA.12508503.1382458902000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508503.1382458902000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508503.1382458902000.17116.1382664122228@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/SECURITY-758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824871#comment-12824871 ] 

RH Bugzilla Integration commented on SECURITY-758:
--------------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1017974|https://bugzilla.redhat.com/show_bug.cgi?id=1017974] from ASSIGNED to MODIFIED
                
> AdvancedLdapLoginModule doesn't isn't mapping nested roles
> ----------------------------------------------------------
>
>                 Key: SECURITY-758
>                 URL: https://issues.jboss.org/browse/SECURITY-758
>             Project: PicketBox 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>    Affects Versions: Negotiation_2_2_5
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: Negotiation_2_2_6
>
>
> The recursive role searching is currently broken, believed to be caused by the introduction of quotes for a previous role searching fix.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 21:22:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 24 Oct 2013 21:22:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-761) Release JBoss Negotiation
	2.2.6
In-Reply-To: <JIRA.12508671.1382608770000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508671.1382608770000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508671.1382608770000.17122.1382664122556@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/SECURITY-761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824874#comment-12824874 ] 

RH Bugzilla Integration commented on SECURITY-761:
--------------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1017974|https://bugzilla.redhat.com/show_bug.cgi?id=1017974] from ASSIGNED to MODIFIED
                
> Release JBoss Negotiation 2.2.6
> -------------------------------
>
>                 Key: SECURITY-761
>                 URL: https://issues.jboss.org/browse/SECURITY-761
>             Project: PicketBox 
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: Negotiation_2_2_6
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 21:59:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 24 Oct 2013 21:59:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2278) Deployer can't modify data
 source when datasources set as application resources
In-Reply-To: <JIRA.12502701.1381412857000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502701.1381412857000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502701.1381412857000.17129.1382666342191@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824875#comment-12824875 ] 

RH Bugzilla Integration commented on WFLY-2278:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1017786|https://bugzilla.redhat.com/show_bug.cgi?id=1017786] from POST to MODIFIED
                
> Deployer can't modify data source when datasources set as application resources
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-2278
>                 URL: https://issues.jboss.org/browse/WFLY-2278
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Brian Stansberry
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.CR1
>
>
> When data sources are made application resources, deployer should be able to modify them. This doesn't work, as opposed to e.g. mail sessions. For example:
> {code}
> /core-service=management/access=authorization/constraint=application-classification/type=datasources/classification=data-source:write-attribute(name=configured-application, value=true)
> {"outcome" => "success"}
> [standalone at localhost:9990 /] /subsystem=datasources/data-source=ExampleDS:write-attribute(name=jndi-name, value="java:jboss/datasources/ExampleDS_XXX"){roles=deployer}
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS013456: Unauthorized to execute operation 'write-attribute' for resource '[
>     (\"subsystem\" => \"datasources\"),
>     (\"data-source\" => \"ExampleDS\")
> ]' -- \"JBAS013475: Permission denied\"",
>     "rolled-back" => true
> }
> [standalone at localhost:9990 /] /core-service=management/access=authorization/constraint=application-classification/type=mail/classification=mail-session:write-attribute(name=configured-application, value=true)
> {"outcome" => "success"}
> [standalone at localhost:9990 /] /subsystem=mail/mail-session=java\:jboss\/mail\/Default:write-attribute(name=jndi-name, value="java:jboss/mail/Default_XXX"){roles=deployer} 
> {
>     "outcome" => "success",
>     "response-headers" => {
>         "operation-requires-reload" => true,
>         "process-state" => "reload-required"
>     }
> }
> {code}
> I have a test case for this as a last commit in my branch https://github.com/Ladicek/wildfly/commits/rbac (that is the commit called _RBAC test case for application types_).
> Brian, in case you are not the right assignee, please reassign.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 22:03:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 24 Oct 2013 22:03:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2352) Domain controller fails to
 restart due to an inconsistent rollback of a redeploy
In-Reply-To: <JIRA.12508413.1382409608000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508413.1382409608000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508413.1382409608000.17136.1382666582082@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824877#comment-12824877 ] 

RH Bugzilla Integration commented on WFLY-2352:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> made a comment on [bug 1021763|https://bugzilla.redhat.com/show_bug.cgi?id=1021763]


                
> Domain controller fails to restart due to an inconsistent rollback of a redeploy
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-2352
>                 URL: https://issues.jboss.org/browse/WFLY-2352
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Osamu Nagano
>            Assignee: Brian Stansberry
>
> When you try to redeploy (or deploy with --force option) the same application which has the same contents hash, and a necessary dependency like a datasource beeing injected in the application is lost by some reason, the redeploy operation will delete the contents under $JBOSS_HOME/domain/data/content directory but won't delete entries in domain.xml. Then the domain controller fails to start up because no contents found in the directory. This likely happens when you frequently changes settings during other servers shutting down.
> The domain controller fails to restart with the following log messages.
> {code}
> 12:04:10,623 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("add") failed - address: ([("deployment" => "exampleapp.war")]) - failure description: "JBAS010876: No deployment content with hash c1306bc4855f4ed9914c9616f2b999c5c62a79d3 is available in the deployment content repository for deployment 'exampleapp.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuraiton file and restart."
> 12:04:10,628 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010933: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> {code}
> The domain controller should be independent from such a server specific issue and there should be a way to fix this via CLI or Console, not by a manual editing of domain.xml.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 22:11:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 24 Oct 2013 22:11:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2317) Trying to remove a server
 group as a server-group-scoped role leaks information
In-Reply-To: <JIRA.12503235.1381924172000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503235.1381924172000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503235.1381924172000.17149.1382667062202@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824882#comment-12824882 ] 

RH Bugzilla Integration commented on WFLY-2317:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1019784|https://bugzilla.redhat.com/show_bug.cgi?id=1019784] from NEW to POST
                
> Trying to remove a server group as a server-group-scoped role leaks information
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-2317
>                 URL: https://issues.jboss.org/browse/WFLY-2317
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Brian Stansberry
>              Labels: rbac-filed-by-qa
>
> When writing a small test case for WFLY-2190, I stumbled upon a problem: trying to remove an existing server group by a server-group-scoped user that does NOT have permissions to that server group leaks information. On a freshly built WildFly with added {{admin}} user into {{domain/configuration/mgmt-users.properties}}, it can be reproduced like this:
> {code}
> [1] ./bin/domain.sh
> [2] ./bin/jboss-cli.sh -c
>     /core-service=management/access=authorization/server-group-scoped-role=NewRole:add(base-role=administrator, server-groups=[main-server-group])
>     /core-service=management/access=authorization/role-mapping=NewRole:add
>     /core-service=management/access=authorization/role-mapping=NewRole/include=user-admin:add(name=admin, type=user)
>     /core-service=management/access=authorization:write-attribute(name=provider, value=rbac)
>     exit
> [1] ^C
>     ./bin/domain.sh
> [2] ./bin/jboss-cli.sh -c --user=admin --password=XXX
>     /server-group=other-server-group:read-resource
>     /server-group=other-server-group:remove
> {code}
> What does that mean? The {{NewRole}} is scoped to the {{main-server-group}} server group and can't see {{other-server-group}}. When doing {{/server-group=other-server-group:read-resource}}, this is correctly enforced and the output looks like this:
> {code}
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014807: Management resource '[(\"server-group\" => \"other-server-group\")]' not found",
>     "rolled-back" => true
> }
> {code}
> However, trying to do {{/server-group=other-server-group:remove}}, which is only a different operation _on the same resource_, I get a different error message:
> {code}
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "JBAS013456: Unauthorized to execute operation 'remove' for resource '[(\"server-group\" => \"other-server-group\")]' -- \"JBAS013475: Permission denied\""},
>     "rolled-back" => true
> }
> {code}
> I expect the error message to be completely the same as in previous case, not leaking any information that the {{other-server-group}} actually exists.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 22:26:02 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 24 Oct 2013 22:26:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2376) DataSource properties are not
 persisting via CLI
In-Reply-To: <JIRA.12508706.1382624115000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508706.1382624115000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508706.1382624115000.17168.1382667962049@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen reassigned WFLY-2376:
-------------------------------------

    Assignee: Stefano Maestri  (was: Jesper Pedersen)

    
> DataSource properties are not persisting via CLI
> ------------------------------------------------
>
>                 Key: WFLY-2376
>                 URL: https://issues.jboss.org/browse/WFLY-2376
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Jay Kumar SenSharma
>            Assignee: Stefano Maestri
>
> - The CLI command show that there are some valid configuration properties available like following while configuring DataSources, However those properties never get persisted in the DataSource configuration:
> {quote}
>  ./jboss-cli.sh  --user=admin --password=admin at 123 -c --controller=remote://localhost:9999  command="/subsystem=datasources/data-source=testpool:read-resource-description(recursive=true)" 
>             "stale-connection-checker-properties" => {
>                 "type" => OBJECT,
>                 "description" => "The stale connection checker properties",
>                 "expressions-allowed" => true,
>                 "nillable" => true,
>                 "value-type" => STRING,
>                 "access-type" => "read-write",
>                 "storage" => "configuration",
>                 "restart-required" => "no-services"
>             },
>             "reauth-plugin-properties" => {
>                 "type" => OBJECT,
>                 "description" => "The properties for the reauthentication plugin",
>                 "expressions-allowed" => true,
>                 "nillable" => true,
>                 "value-type" => STRING,
>                 "access-type" => "read-write",
>                 "storage" => "configuration",
>                 "restart-required" => "no-services"
>             },
>             "exception-sorter-properties" => {
>                 "type" => OBJECT,
>                 "description" => "The exception sorter properties",
>                 "expressions-allowed" => true,
>                 "nillable" => true,
>                 "value-type" => STRING,
>                 "access-type" => "read-write",
>                 "storage" => "configuration",
>                 "restart-required" => "no-services"
>             },
> {quote}
> - Following command never complains about any issue and the following command executed without any issue but the above properties are not persisted in the DataSource.
>  ./jboss-cli.sh --user=admin --password=admin at 123 -c --controller=remote://localhost:9999 command="/subsystem=datasources/data-source=testpool:add(jndi-name=\"java:jboss/TestDS\",driver-name=\"ojdbc6.jar\",connection-url=\"jdbc:oracle:thin:@DBHostName:1521:DBName\",user-name=\"user\",password=\"pass\",new-connection-sql=\"select 1 from dual\", check-valid-connection-sql=\"select 2 from dual\",valid-connection-checker-class-name=\"org.jboss.resource.adapter.jdbc.vendor.OracleValidConnectionChecker\",exception-sorter-properties={\"prop1\"=>\"value1\"},reauth-plugin-properties={\"reauthProp1\"=>\"reauthValue1\"},exception-sorter-properties={\"exceptionSorterProp1\"=>\"exceptionSorterValue1\"})"
> - The Generated DataSource looks like following:
> ${quote}
>                 <datasource jndi-name="java:jboss/TestDS" pool-name="testpool" enabled="true">
>                     <connection-url>jdbc:oracle:thin:@DBHostName:1521:DBName</connection-url>
>                     <driver>ojdbc6.jar</driver>
>                     <new-connection-sql>select 1 from dual</new-connection-sql>
>                     <security>
>                         <user-name>user</user-name>
>                         <password>pass</password>
>                     </security>
>                     <validation>
>                         <valid-connection-checker class-name="org.jboss.resource.adapter.jdbc.vendor.OracleValidConnectionChecker"/>
>                         <check-valid-connection-sql>select 2 from dual</check-valid-connection-sql>
>                     </validation>
>                 </datasource>
> ${quote}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 22:36:02 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 24 Oct 2013 22:36:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1108) IronJacamar 1.1.1.Final
In-Reply-To: <JIRA.12508754.1382668530450@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508754.1382668530450@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508754.1382668530450.17186.1382668562031@jira02.app.mwc.hst.phx2.redhat.com>

Jesper Pedersen created JBJCA-1108:
--------------------------------------

             Summary: IronJacamar 1.1.1.Final
                 Key: JBJCA-1108
                 URL: https://issues.jboss.org/browse/JBJCA-1108
             Project: IronJacamar
          Issue Type: Release
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.1.1.Final


Release notes: https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12310691&version=12322339

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 22:50:02 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 24 Oct 2013 22:50:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1108) IronJacamar 1.1.1.Final
In-Reply-To: <JIRA.12508754.1382668530000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508754.1382668530000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508754.1382668530000.17215.1382669402083@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-1108.
------------------------------------

    Resolution: Done

    
> IronJacamar 1.1.1.Final
> -----------------------
>
>                 Key: JBJCA-1108
>                 URL: https://issues.jboss.org/browse/JBJCA-1108
>             Project: IronJacamar
>          Issue Type: Release
>          Components: Build
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.1.1.Final
>
>
> Release notes: https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12310691&version=12322339

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 22:56:01 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 24 Oct 2013 22:56:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2021) EE Component interceptor
 chains should be stateless
In-Reply-To: <JIRA.12500214.1378475131000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500214.1378475131000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500214.1378475131000.17219.1382669761919@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824888#comment-12824888 ] 

RH Bugzilla Integration commented on WFLY-2021:
-----------------------------------------------

David M. Lloyd <david.lloyd at redhat.com> made a comment on [bug 1022265|https://bugzilla.redhat.com/show_bug.cgi?id=1022265]

Assigned to Stuart since he's actually working in this area right now.
                
> EE Component interceptor chains should be stateless
> ---------------------------------------------------
>
>                 Key: WFLY-2021
>                 URL: https://issues.jboss.org/browse/WFLY-2021
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: EE, EJB
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>
> This will allow them to be shared by all instances, rather than having a new chain allocated for each method.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 24 23:59:01 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 24 Oct 2013 23:59:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2381) IronJacamar 1.1.1.Final
In-Reply-To: <JIRA.12508757.1382673433360@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508757.1382673433360@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508757.1382673433360.17266.1382673541987@jira02.app.mwc.hst.phx2.redhat.com>

Jesper Pedersen created WFLY-2381:
-------------------------------------

             Summary: IronJacamar 1.1.1.Final
                 Key: WFLY-2381
                 URL: https://issues.jboss.org/browse/WFLY-2381
             Project: WildFly
          Issue Type: Component  Upgrade
      Security Level: Public (Everyone can see)
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 8.0.0.CR1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 00:45:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 25 Oct 2013 00:45:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2376) DataSource properties are not
 persisting via CLI
In-Reply-To: <JIRA.12508706.1382624115000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508706.1382624115000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508706.1382624115000.17292.1382676302371@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2376:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1023064

    
> DataSource properties are not persisting via CLI
> ------------------------------------------------
>
>                 Key: WFLY-2376
>                 URL: https://issues.jboss.org/browse/WFLY-2376
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Jay Kumar SenSharma
>            Assignee: Stefano Maestri
>
> - The CLI command show that there are some valid configuration properties available like following while configuring DataSources, However those properties never get persisted in the DataSource configuration:
> {quote}
>  ./jboss-cli.sh  --user=admin --password=admin at 123 -c --controller=remote://localhost:9999  command="/subsystem=datasources/data-source=testpool:read-resource-description(recursive=true)" 
>             "stale-connection-checker-properties" => {
>                 "type" => OBJECT,
>                 "description" => "The stale connection checker properties",
>                 "expressions-allowed" => true,
>                 "nillable" => true,
>                 "value-type" => STRING,
>                 "access-type" => "read-write",
>                 "storage" => "configuration",
>                 "restart-required" => "no-services"
>             },
>             "reauth-plugin-properties" => {
>                 "type" => OBJECT,
>                 "description" => "The properties for the reauthentication plugin",
>                 "expressions-allowed" => true,
>                 "nillable" => true,
>                 "value-type" => STRING,
>                 "access-type" => "read-write",
>                 "storage" => "configuration",
>                 "restart-required" => "no-services"
>             },
>             "exception-sorter-properties" => {
>                 "type" => OBJECT,
>                 "description" => "The exception sorter properties",
>                 "expressions-allowed" => true,
>                 "nillable" => true,
>                 "value-type" => STRING,
>                 "access-type" => "read-write",
>                 "storage" => "configuration",
>                 "restart-required" => "no-services"
>             },
> {quote}
> - Following command never complains about any issue and the following command executed without any issue but the above properties are not persisted in the DataSource.
>  ./jboss-cli.sh --user=admin --password=admin at 123 -c --controller=remote://localhost:9999 command="/subsystem=datasources/data-source=testpool:add(jndi-name=\"java:jboss/TestDS\",driver-name=\"ojdbc6.jar\",connection-url=\"jdbc:oracle:thin:@DBHostName:1521:DBName\",user-name=\"user\",password=\"pass\",new-connection-sql=\"select 1 from dual\", check-valid-connection-sql=\"select 2 from dual\",valid-connection-checker-class-name=\"org.jboss.resource.adapter.jdbc.vendor.OracleValidConnectionChecker\",exception-sorter-properties={\"prop1\"=>\"value1\"},reauth-plugin-properties={\"reauthProp1\"=>\"reauthValue1\"},exception-sorter-properties={\"exceptionSorterProp1\"=>\"exceptionSorterValue1\"})"
> - The Generated DataSource looks like following:
> ${quote}
>                 <datasource jndi-name="java:jboss/TestDS" pool-name="testpool" enabled="true">
>                     <connection-url>jdbc:oracle:thin:@DBHostName:1521:DBName</connection-url>
>                     <driver>ojdbc6.jar</driver>
>                     <new-connection-sql>select 1 from dual</new-connection-sql>
>                     <security>
>                         <user-name>user</user-name>
>                         <password>pass</password>
>                     </security>
>                     <validation>
>                         <valid-connection-checker class-name="org.jboss.resource.adapter.jdbc.vendor.OracleValidConnectionChecker"/>
>                         <check-valid-connection-sql>select 2 from dual</check-valid-connection-sql>
>                     </validation>
>                 </datasource>
> ${quote}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 00:47:02 2013
From: jira-events at lists.jboss.org (Jay Kumar SenSharma (JIRA))
Date: Fri, 25 Oct 2013 00:47:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2376) DataSource properties are not
 persisting via CLI
In-Reply-To: <JIRA.12508706.1382624115000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508706.1382624115000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508706.1382624115000.17297.1382676422060@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824903#comment-12824903 ] 

Jay Kumar SenSharma commented on WFLY-2376:
-------------------------------------------

- Any of the concerned attribute like *"stale-connection-checker-properties"* or *"reauth-plugin-properties"* or *"exception-sorter-properties"* are not declared inside any of the following XSDs still CLI command shows that those are valid properties/tags

wildfly-8.0.0.Beta2-SNAPSHOT/docs/schema/wildfly-datasources_2_0.xsd
wildfly-8.0.0.Beta2-SNAPSHOT/docs/schema/jboss-as-datasources_1_0.xsd
wildfly-8.0.0.Beta2-SNAPSHOT/docs/schema/jboss-as-datasources_1_1.xsd

                
> DataSource properties are not persisting via CLI
> ------------------------------------------------
>
>                 Key: WFLY-2376
>                 URL: https://issues.jboss.org/browse/WFLY-2376
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Jay Kumar SenSharma
>            Assignee: Stefano Maestri
>
> - The CLI command show that there are some valid configuration properties available like following while configuring DataSources, However those properties never get persisted in the DataSource configuration:
> {quote}
>  ./jboss-cli.sh  --user=admin --password=admin at 123 -c --controller=remote://localhost:9999  command="/subsystem=datasources/data-source=testpool:read-resource-description(recursive=true)" 
>             "stale-connection-checker-properties" => {
>                 "type" => OBJECT,
>                 "description" => "The stale connection checker properties",
>                 "expressions-allowed" => true,
>                 "nillable" => true,
>                 "value-type" => STRING,
>                 "access-type" => "read-write",
>                 "storage" => "configuration",
>                 "restart-required" => "no-services"
>             },
>             "reauth-plugin-properties" => {
>                 "type" => OBJECT,
>                 "description" => "The properties for the reauthentication plugin",
>                 "expressions-allowed" => true,
>                 "nillable" => true,
>                 "value-type" => STRING,
>                 "access-type" => "read-write",
>                 "storage" => "configuration",
>                 "restart-required" => "no-services"
>             },
>             "exception-sorter-properties" => {
>                 "type" => OBJECT,
>                 "description" => "The exception sorter properties",
>                 "expressions-allowed" => true,
>                 "nillable" => true,
>                 "value-type" => STRING,
>                 "access-type" => "read-write",
>                 "storage" => "configuration",
>                 "restart-required" => "no-services"
>             },
> {quote}
> - Following command never complains about any issue and the following command executed without any issue but the above properties are not persisted in the DataSource.
>  ./jboss-cli.sh --user=admin --password=admin at 123 -c --controller=remote://localhost:9999 command="/subsystem=datasources/data-source=testpool:add(jndi-name=\"java:jboss/TestDS\",driver-name=\"ojdbc6.jar\",connection-url=\"jdbc:oracle:thin:@DBHostName:1521:DBName\",user-name=\"user\",password=\"pass\",new-connection-sql=\"select 1 from dual\", check-valid-connection-sql=\"select 2 from dual\",valid-connection-checker-class-name=\"org.jboss.resource.adapter.jdbc.vendor.OracleValidConnectionChecker\",exception-sorter-properties={\"prop1\"=>\"value1\"},reauth-plugin-properties={\"reauthProp1\"=>\"reauthValue1\"},exception-sorter-properties={\"exceptionSorterProp1\"=>\"exceptionSorterValue1\"})"
> - The Generated DataSource looks like following:
> ${quote}
>                 <datasource jndi-name="java:jboss/TestDS" pool-name="testpool" enabled="true">
>                     <connection-url>jdbc:oracle:thin:@DBHostName:1521:DBName</connection-url>
>                     <driver>ojdbc6.jar</driver>
>                     <new-connection-sql>select 1 from dual</new-connection-sql>
>                     <security>
>                         <user-name>user</user-name>
>                         <password>pass</password>
>                     </security>
>                     <validation>
>                         <valid-connection-checker class-name="org.jboss.resource.adapter.jdbc.vendor.OracleValidConnectionChecker"/>
>                         <check-valid-connection-sql>select 2 from dual</check-valid-connection-sql>
>                     </validation>
>                 </datasource>
> ${quote}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 01:27:02 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Fri, 25 Oct 2013 01:27:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-312) STATING a JUSTIFIED fact
 will actually delete that fact
In-Reply-To: <JIRA.12508759.1382678737208@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508759.1382678737208@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508759.1382678737208.17305.1382678822536@jira02.app.mwc.hst.phx2.redhat.com>

Davide Sottara created DROOLS-312:
-------------------------------------

             Summary: STATING a JUSTIFIED fact will actually delete that fact
                 Key: DROOLS-312
                 URL: https://issues.jboss.org/browse/DROOLS-312
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 6.0.0.CR5
            Reporter: Davide Sottara
            Assignee: Mark Proctor
            Priority: Critical


When a previously JUSTIFIED fact is STATED, all its logical dependencies are removed. However, the TMS will delete a managed fact with no dependencies.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 02:55:02 2013
From: jira-events at lists.jboss.org (Jozef Hartinger (JIRA))
Date: Fri, 25 Oct 2013 02:55:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2375) Servlet component classes do
 not support interceptors
In-Reply-To: <JIRA.12508703.1382623256000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508703.1382623256000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508703.1382623256000.17334.1382684102021@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Hartinger updated WFLY-2375:
----------------------------------

       Assignee: Jozef Hartinger  (was: Stuart Douglas)
    Component/s: CDI / Weld

    
> Servlet component classes do not support interceptors
> -----------------------------------------------------
>
>                 Key: WFLY-2375
>                 URL: https://issues.jboss.org/browse/WFLY-2375
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld, Web (Undertow)
>            Reporter: Martin Kouba
>            Assignee: Jozef Hartinger
>
> In Java EE 7 component classes with "Standard" injection support level must support the use of interceptors (see Table EE.5-1 and EE.5.24 Support for Dependency Injection). Servlets, servlet filters and event listeners do not support interceptors at the moment.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 02:57:02 2013
From: jira-events at lists.jboss.org (Jozef Hartinger (JIRA))
Date: Fri, 25 Oct 2013 02:57:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2372) @Model stops working with
 bean-discovery-mode="annotated"
In-Reply-To: <JIRA.12508667.1382607038000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508667.1382607038000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508667.1382607038000.17338.1382684222156@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Hartinger updated WFLY-2372:
----------------------------------

       Assignee: Jozef Hartinger  (was: Stuart Douglas)
    Component/s: CDI / Weld

    
> @Model stops working with bean-discovery-mode="annotated"
> ---------------------------------------------------------
>
>                 Key: WFLY-2372
>                 URL: https://issues.jboss.org/browse/WFLY-2372
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld, Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Juergen Zimmermann
>            Assignee: Jozef Hartinger
>
> First of all: I'm not sure whether this is a bug of Undertow or a bug of Weld or a limitation of Mojarra 2.1.
> I changed WEB-INF/beans.xml so that the root element looks as follows, i.e. "annotated" instead of "all":
> {code}
> <beans ... bean-discovery-mode="annotated" ...>
> {code}
> When I access this CDI-enabled bean in a JSF page via EL using #{artikelModel.load}, I'm getting the stacktrace below:
> {code}
> @Model
> public class ArtikelModel implements Serializable {
> {code}
> If I replace @Model with @RequestScoped @Named, then the issue is gone. Also if I go back from "annotated" to "all".
> Stacktrace:
> {code}
> 11:26:49,340 ERROR [io.undertow.request] (default task-3) Servlet request failed HttpServerExchange{ GET /shop/index.jsf}: javax.servlet.ServletException: /indexDesktop.xhtml @15,79 listener="#{artikelModel.load}": Target Unreachable, identifier 'artikelModel' resolved to null
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:606) [jsf-api-2.1.26.jar:2.1]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta19.jar:1.0.0.Beta19]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:93) [undertow-servlet-1.0.0.Beta19.jar:1.0.0.Beta19]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta19.jar:1.0.0.Beta19]
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta19.jar:1.0.0.Beta19]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta19.jar:1.0.0.Beta19]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta19.jar:1.0.0.Beta19]
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.0.Beta19.jar:1.0.0.Beta19]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta19.jar:1.0.0.Beta19]
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:55) [undertow-servlet-1.0.0.Beta19.jar:1.0.0.Beta19]
> 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.0.Beta19.jar:1.0.0.Beta19]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta19.jar:1.0.0.Beta19]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta19.jar:1.0.0.Beta19]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta19.jar:1.0.0.Beta19]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta19.jar:1.0.0.Beta19]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:218) [undertow-servlet-1.0.0.Beta19.jar:1.0.0.Beta19]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta19.jar:1.0.0.Beta19]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta19.jar:1.0.0.Beta19]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta19.jar:1.0.0.Beta19]
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:138) [undertow-core-1.0.0.Beta19.jar:1.0.0.Beta19]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:622) [undertow-core-1.0.0.Beta19.jar:1.0.0.Beta19]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: javax.el.PropertyNotFoundException: /indexDesktop.xhtml @15,79 listener="#{artikelModel.load}": Target Unreachable, identifier 'artikelModel' resolved to null
> 	at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:107) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.facelets.tag.jsf.core.DeclarativeSystemEventListener.processEvent(EventHandler.java:128) [jsf-impl-2.1.26.jar:2.1.26]
> 	at javax.faces.component.UIComponent$ComponentSystemEventListenerAdapter.processEvent(UIComponent.java:2526) [jsf-api-2.1.26.jar:2.1]
> 	at javax.faces.event.SystemEvent.processListener(SystemEvent.java:106) [jsf-api-2.1.26.jar:2.1]
> 	at com.sun.faces.application.ApplicationImpl.processListeners(ApplicationImpl.java:2163) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.application.ApplicationImpl.invokeComponentListenersFor(ApplicationImpl.java:2111) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:289) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:247) [jsf-impl-2.1.26.jar:2.1.26]
> 	at org.jboss.as.jsf.injection.weld.ForwardingApplication.publishEvent(ForwardingApplication.java:299) [wildfly-jsf-injection-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:107) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139) [jsf-impl-2.1.26.jar:2.1.26]
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594) [jsf-api-2.1.26.jar:2.1]
> 	... 24 more
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 02:59:01 2013
From: jira-events at lists.jboss.org (Jozef Hartinger (JIRA))
Date: Fri, 25 Oct 2013 02:59:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2374) Add tests for component
 classes supporting injection
In-Reply-To: <JIRA.12508687.1382617154000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508687.1382617154000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508687.1382617154000.17342.1382684341960@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Hartinger updated WFLY-2374:
----------------------------------

    Component/s: CDI / Weld

    
> Add tests for component classes supporting injection
> ----------------------------------------------------
>
>                 Key: WFLY-2374
>                 URL: https://issues.jboss.org/browse/WFLY-2374
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld, Test Suite
>            Reporter: Martin Kouba
>            Assignee: Martin Kouba
>
> Right now the test suite does not contain tests for component classes with "Standard" injection support level (see Table EE.5-1 and EE.5.24 Support for Dependency Injection). The problem is such tests are missing in Java EE CTS as well. Actually CDI TCK tests some basic injection scenarios (servlet, filter, etc.) but it does not cover everything. And the division of responsibilities for testing is work in progress (see also http://lists.jboss.org/pipermail/cdi-dev/2013-October/004345.html). 
> Note that in Java EE 7 component classes must support the use of interceptors as well.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 02:59:02 2013
From: jira-events at lists.jboss.org (Jozef Hartinger (JIRA))
Date: Fri, 25 Oct 2013 02:59:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2362) Support CDI interception of
 all EE components
In-Reply-To: <JIRA.12508575.1382536533000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508575.1382536533000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508575.1382536533000.17345.1382684342068@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Hartinger updated WFLY-2362:
----------------------------------

    Component/s: CDI / Weld

    
> Support CDI interception of all EE components
> ---------------------------------------------
>
>                 Key: WFLY-2362
>                 URL: https://issues.jboss.org/browse/WFLY-2362
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>            Reporter: Jozef Hartinger
>            Assignee: Jozef Hartinger
>            Priority: Blocker
>             Fix For: 8.0.0.CR1
>
>
> As required by EE 7 Table EE.5-1.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 03:46:02 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Fri, 25 Oct 2013 03:46:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2379) End users can call
 non-published management API operations
In-Reply-To: <JIRA.12508718.1382628380000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508718.1382628380000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508718.1382628380000.17401.1382687162802@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ladislav Thon updated WFLY-2379:
--------------------------------

    Summary: End users can call non-published management API operations  (was: Can't call "describe" via JMX)

    
> End users can call non-published management API operations
> ----------------------------------------------------------
>
>                 Key: WFLY-2379
>                 URL: https://issues.jboss.org/browse/WFLY-2379
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, JMX
>            Reporter: Ladislav Thon
>            Assignee: Kabir Khan
>            Priority: Minor
>              Labels: rbac-filed-by-qa
>
> It's not possible to call "non-published" operations (those that are not visible in the resource tree, e.g. {{describe}}) via JMX, while it's entirely possible to call them via CLI (e.g. {{/subsystem=security:describe}}) and other management interfaces.
> The problem lies in the fact that {{ModelControllerMBeanHelper.invoke}} method checks {{if (!accessControl.isExecutableOperation(operationName))}} and the {{isExecutableOperation}} method assumes that the operation will be visible in the resource tree. In fact, there is a comment stating _should not happen_, but now we know that it indeed _can_ happen.
> What's more, it gives a misleading error message. The {{isExecutableOperation}} returns {{false}} for unknown operations, which results in {{Not authorized to invoke operation}} message. Which is wrong in two different ways simultaneously: 1. the problem isn't authorization, but the fact that the operation can't be found; 2. the user (e.g. in the {{SuperUser}} role) _is_ authorized.
> I'm considering this low priority, because 1. JMX is likely to be very rarely used to access the management interface, 2. hiding information isn't nearly as important as leaking them, 3. non-published operations aren't nearly as important as the published ones. It's worth a JIRA nevertheless.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 03:46:03 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Fri, 25 Oct 2013 03:46:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2379) End users can call
 non-published management API operations
In-Reply-To: <JIRA.12508718.1382628380000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508718.1382628380000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508718.1382628380000.17408.1382687163153@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ladislav Thon updated WFLY-2379:
--------------------------------

        Parent:     (was: WFLY-490)
    Issue Type: Bug  (was: Sub-task)

    
> End users can call non-published management API operations
> ----------------------------------------------------------
>
>                 Key: WFLY-2379
>                 URL: https://issues.jboss.org/browse/WFLY-2379
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, JMX
>            Reporter: Ladislav Thon
>            Assignee: Kabir Khan
>            Priority: Minor
>              Labels: rbac-filed-by-qa
>
> It's not possible to call "non-published" operations (those that are not visible in the resource tree, e.g. {{describe}}) via JMX, while it's entirely possible to call them via CLI (e.g. {{/subsystem=security:describe}}) and other management interfaces.
> The problem lies in the fact that {{ModelControllerMBeanHelper.invoke}} method checks {{if (!accessControl.isExecutableOperation(operationName))}} and the {{isExecutableOperation}} method assumes that the operation will be visible in the resource tree. In fact, there is a comment stating _should not happen_, but now we know that it indeed _can_ happen.
> What's more, it gives a misleading error message. The {{isExecutableOperation}} returns {{false}} for unknown operations, which results in {{Not authorized to invoke operation}} message. Which is wrong in two different ways simultaneously: 1. the problem isn't authorization, but the fact that the operation can't be found; 2. the user (e.g. in the {{SuperUser}} role) _is_ authorized.
> I'm considering this low priority, because 1. JMX is likely to be very rarely used to access the management interface, 2. hiding information isn't nearly as important as leaking them, 3. non-published operations aren't nearly as important as the published ones. It's worth a JIRA nevertheless.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 03:46:03 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Fri, 25 Oct 2013 03:46:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2379) End users can call
 non-published management API operations
In-Reply-To: <JIRA.12508718.1382628380000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508718.1382628380000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508718.1382628380000.17413.1382687163391@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ladislav Thon updated WFLY-2379:
--------------------------------

    Labels:   (was: rbac-filed-by-qa)

    
> End users can call non-published management API operations
> ----------------------------------------------------------
>
>                 Key: WFLY-2379
>                 URL: https://issues.jboss.org/browse/WFLY-2379
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, JMX
>            Reporter: Ladislav Thon
>            Assignee: Kabir Khan
>            Priority: Minor
>
> It's not possible to call "non-published" operations (those that are not visible in the resource tree, e.g. {{describe}}) via JMX, while it's entirely possible to call them via CLI (e.g. {{/subsystem=security:describe}}) and other management interfaces.
> The problem lies in the fact that {{ModelControllerMBeanHelper.invoke}} method checks {{if (!accessControl.isExecutableOperation(operationName))}} and the {{isExecutableOperation}} method assumes that the operation will be visible in the resource tree. In fact, there is a comment stating _should not happen_, but now we know that it indeed _can_ happen.
> What's more, it gives a misleading error message. The {{isExecutableOperation}} returns {{false}} for unknown operations, which results in {{Not authorized to invoke operation}} message. Which is wrong in two different ways simultaneously: 1. the problem isn't authorization, but the fact that the operation can't be found; 2. the user (e.g. in the {{SuperUser}} role) _is_ authorized.
> I'm considering this low priority, because 1. JMX is likely to be very rarely used to access the management interface, 2. hiding information isn't nearly as important as leaking them, 3. non-published operations aren't nearly as important as the published ones. It's worth a JIRA nevertheless.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 03:46:03 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Fri, 25 Oct 2013 03:46:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2379) End users can call
 non-published management API operations
In-Reply-To: <JIRA.12508718.1382628380000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508718.1382628380000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508718.1382628380000.17418.1382687163578@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ladislav Thon updated WFLY-2379:
--------------------------------

    Assignee: Brian Stansberry  (was: Kabir Khan)

    
> End users can call non-published management API operations
> ----------------------------------------------------------
>
>                 Key: WFLY-2379
>                 URL: https://issues.jboss.org/browse/WFLY-2379
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, JMX
>            Reporter: Ladislav Thon
>            Assignee: Brian Stansberry
>            Priority: Minor
>
> It's not possible to call "non-published" operations (those that are not visible in the resource tree, e.g. {{describe}}) via JMX, while it's entirely possible to call them via CLI (e.g. {{/subsystem=security:describe}}) and other management interfaces.
> The problem lies in the fact that {{ModelControllerMBeanHelper.invoke}} method checks {{if (!accessControl.isExecutableOperation(operationName))}} and the {{isExecutableOperation}} method assumes that the operation will be visible in the resource tree. In fact, there is a comment stating _should not happen_, but now we know that it indeed _can_ happen.
> What's more, it gives a misleading error message. The {{isExecutableOperation}} returns {{false}} for unknown operations, which results in {{Not authorized to invoke operation}} message. Which is wrong in two different ways simultaneously: 1. the problem isn't authorization, but the fact that the operation can't be found; 2. the user (e.g. in the {{SuperUser}} role) _is_ authorized.
> I'm considering this low priority, because 1. JMX is likely to be very rarely used to access the management interface, 2. hiding information isn't nearly as important as leaking them, 3. non-published operations aren't nearly as important as the published ones. It's worth a JIRA nevertheless.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 03:52:02 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 25 Oct 2013 03:52:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2361) WorkManager callback security
	never set
In-Reply-To: <JIRA.12508556.1382526535000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508556.1382526535000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508556.1382526535000.17434.1382687522136@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen closed WFLY-2361.
---------------------------------

    Fix Version/s:     (was: 8.0.0.CR1)
       Resolution: Rejected


Brain meltdown
                
> WorkManager callback security never set
> ---------------------------------------
>
>                 Key: WFLY-2361
>                 URL: https://issues.jboss.org/browse/WFLY-2361
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Jesper Pedersen
>            Assignee: Stefano Maestri
>            Priority: Blocker
>
> The
> {noformat}
> org.jboss.as.connector.services.workmanager.WorkManagerService
> {noformat}
> never calls "setCallbackSecurity" with the specified policy.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 04:04:01 2013
From: jira-events at lists.jboss.org (Eduardo Martins (JIRA))
Date: Fri, 25 Oct 2013 04:04:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2382) Default EE bindings must be
 available to application clients
In-Reply-To: <JIRA.12508765.1382688138991@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508765.1382688138991@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508765.1382688138991.17454.1382688241967@jira02.app.mwc.hst.phx2.redhat.com>

Eduardo Martins created WFLY-2382:
-------------------------------------

             Summary: Default EE bindings must be available to application clients
                 Key: WFLY-2382
                 URL: https://issues.jboss.org/browse/WFLY-2382
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Application Client, EE
            Reporter: Eduardo Martins
            Assignee: Eduardo Martins


The processors which do the default EE bindings introduced by JEE 7 do not add these to application clients java:comp.

WFLY-2380 is wrt the particular case of the default JMS factory.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 04:04:02 2013
From: jira-events at lists.jboss.org (Eduardo Martins (JIRA))
Date: Fri, 25 Oct 2013 04:04:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2380) DefaultJMSConnectionFactory
 binding must be accessing from application client deployment
In-Reply-To: <JIRA.12508725.1382631204000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508725.1382631204000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508725.1382631204000.17458.1382688242185@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824922#comment-12824922 ] 

Eduardo Martins commented on WFLY-2380:
---------------------------------------

same applies to the default data source and EE concurrency resources, created WFLY-2382 to fix the "others"
                
> DefaultJMSConnectionFactory binding must be accessing from application client deployment
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-2380
>                 URL: https://issues.jboss.org/browse/WFLY-2380
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.CR1
>
>
> According to the spec (and TCK), an application client deployment must be able to look up the default JMS Connection Factory from "java:comp/DefaultJMSConnectionFactory" but this binding is no longer added to the module description in DefaultJMSConnectionFactoryBindingProcessor.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 04:04:02 2013
From: jira-events at lists.jboss.org (Eduardo Martins (JIRA))
Date: Fri, 25 Oct 2013 04:04:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2380) DefaultJMSConnectionFactory
 binding must be accessing from application client deployment
In-Reply-To: <JIRA.12508725.1382631204000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508725.1382631204000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508725.1382631204000.17460.1382688242324@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824922#comment-12824922 ] 

Eduardo Martins edited comment on WFLY-2380 at 10/25/13 4:02 AM:
-----------------------------------------------------------------

same applies to the default data source and EE concurrency resources, created WFLY-2382 to fix these
                
      was (Author: emmartins):
    same applies to the default data source and EE concurrency resources, created WFLY-2382 to fix the "others"
                  
> DefaultJMSConnectionFactory binding must be accessing from application client deployment
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-2380
>                 URL: https://issues.jboss.org/browse/WFLY-2380
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.CR1
>
>
> According to the spec (and TCK), an application client deployment must be able to look up the default JMS Connection Factory from "java:comp/DefaultJMSConnectionFactory" but this binding is no longer added to the module description in DefaultJMSConnectionFactoryBindingProcessor.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 04:30:01 2013
From: jira-events at lists.jboss.org (=?UTF-8?Q?Dojcs=C3=A1k_S=C3=A1ndor_=28JIRA=29?=)
Date: Fri, 25 Oct 2013 04:30:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBASMP-54) Maven phase executing twice
In-Reply-To: <JIRA.12508235.1382212598000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508235.1382212598000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508235.1382212598000.17487.1382689801986@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBASMP-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824924#comment-12824924 ] 

Dojcs?k S?ndor commented on JBASMP-54:
--------------------------------------

Thank you for your answer. I like deploy-only goal.
                
> Maven phase executing twice
> ---------------------------
>
>                 Key: JBASMP-54
>                 URL: https://issues.jboss.org/browse/JBASMP-54
>             Project: JBoss AS Maven Plugins
>          Issue Type: Bug
>            Reporter: Dojcs?k S?ndor
>            Assignee: James Perkins
>
> I attached deploy goal to the package lifecycle phase.
> When I run mvn package it works fine, but I noticed that all phase executes twice.
> I removed @Execute(phase = LifecyclePhase.PACKAGE) line from Deploy.java. This solved the problem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Fri Oct 25 05:38:02 2013
From: jira-events at lists.jboss.org (Jozef Hartinger (JIRA))
Date: Fri, 25 Oct 2013 05:38:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2372) @Model stops working with
 bean-discovery-mode="annotated"
In-Reply-To: <JIRA.12508667.1382607038000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508667.1382607038000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508667.1382607038000.17602.1382693882311@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Hartinger resolved WFLY-2372.
-----------------------------------

    Resolution: Rejected


The CDI 1.1 specification requires a scope to be applied directly to a bean class for the class to be discovered in the "annotated" mode. WildFly could go further and support @Model as well, however that would mean that an application using this feature could not be portably deployed to a different EE application server. Instead, I filed a feature request for the CDI spec: CDI-406
                
> @Model stops working with bean-discovery-mode="annotated"
> ---------------------------------------------------------
>
>                 Key: WFLY-2372
>                 URL: https://issues.jboss.org/browse/WFLY-2372
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld, Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Juergen Zimmermann
>            Assignee: Jozef Hartinger
>
> First of all: I'm not sure whether this is a bug of Undertow or a bug of Weld or a limitation of Mojarra 2.1.
> I changed WEB-INF/beans.xml so that the root element looks as follows, i.e. "annotated" instead of "all":
> {code}
> <beans ... bean-discovery-mode="annotated" ...>
> {code}
> When I access this CDI-enabled bean in a JSF page via EL using #{artikelModel.load}, I'm getting the stacktrace below:
> {code}
> @Model
> public class ArtikelModel implements Serializable {
> {code}
> If I replace @Model with @RequestScoped @Named, then the issue is gone. Also if I go back from "annotated" to "all".
> Stacktrace:
> {code}
> 11:26:49,340 ERROR [io.undertow.request] (default task-3) Servlet request failed HttpServerExchange{ GET /shop/index.jsf}: javax.servlet.ServletException: /indexDesktop.xhtml @15,79 listener="#{artikelModel.load}": Target Unreachable, identifier 'artikelModel' resolved to null
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:606) [jsf-api-2.1.26.jar:2.1]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta19.jar:1.0.0.Beta19]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:93) [undertow-servlet-1.0.0.Beta19.jar:1.0.0.Beta19]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta19.jar:1.0.0.Beta19]
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta19.jar:1.0.0.Beta19]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta19.jar:1.0.0.Beta19]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta19.jar:1.0.0.Beta19]
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.0.Beta19.jar:1.0.0.Beta19]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta19.jar:1.0.0.Beta19]
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:55) [undertow-servlet-1.0.0.Beta19.jar:1.0.0.Beta19]
> 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.0.Beta19.jar:1.0.0.Beta19]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta19.jar:1.0.0.Beta19]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta19.jar:1.0.0.Beta19]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta19.jar:1.0.0.Beta19]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta19.jar:1.0.0.Beta19]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:218) [undertow-servlet-1.0.0.Beta19.jar:1.0.0.Beta19]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta19.jar:1.0.0.Beta19]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta19.jar:1.0.0.Beta19]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta19.jar:1.0.0.Beta19]
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:138) [undertow-core-1.0.0.Beta19.jar:1.0.0.Beta19]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:622) [undertow-core-1.0.0.Beta19.jar:1.0.0.Beta19]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: javax.el.PropertyNotFoundException: /indexDesktop.xhtml @15,79 listener="#{artikelModel.load}": Target Unreachable, identifier 'artikelModel' resolved to null
> 	at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:107) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.facelets.tag.jsf.core.DeclarativeSystemEventListener.processEvent(EventHandler.java:128) [jsf-impl-2.1.26.jar:2.1.26]
> 	at javax.faces.component.UIComponent$ComponentSystemEventListenerAdapter.processEvent(UIComponent.java:2526) [jsf-api-2.1.26.jar:2.1]
> 	at javax.faces.event.SystemEvent.processListener(SystemEvent.java:106) [jsf-api-2.1.26.jar:2.1]
> 	at com.sun.faces.application.ApplicationImpl.processListeners(ApplicationImpl.java:2163) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.application.ApplicationImpl.invokeComponentListenersFor(ApplicationImpl.java:2111) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:289) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:247) [jsf-impl-2.1.26.jar:2.1.26]
> 	at org.jboss.as.jsf.injection.weld.ForwardingApplication.publishEvent(ForwardingApplication.java:299) [wildfly-jsf-injection-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> 	at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:107) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139) [jsf-impl-2.1.26.jar:2.1.26]
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594) [jsf-api-2.1.26.jar:2.1]
> 	... 24 more
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 05:48:02 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 25 Oct 2013 05:48:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2381) IronJacamar 1.1.1.Final
In-Reply-To: <JIRA.12508757.1382673433000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508757.1382673433000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508757.1382673433000.17612.1382694482051@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved WFLY-2381.
-----------------------------------

    Resolution: Done

    
> IronJacamar 1.1.1.Final
> -----------------------
>
>                 Key: WFLY-2381
>                 URL: https://issues.jboss.org/browse/WFLY-2381
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 06:00:03 2013
From: jira-events at lists.jboss.org (Stefano Maestri (JIRA))
Date: Fri, 25 Oct 2013 06:00:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2383) resource-adapter id attribute
 has to match ra name otherwise MDB is not deployed
In-Reply-To: <JIRA.12508785.1382695105746@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508785.1382695105746@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508785.1382695105746.17632.1382695203514@jira02.app.mwc.hst.phx2.redhat.com>

Stefano Maestri created WFLY-2383:
-------------------------------------

             Summary: resource-adapter id attribute has to match ra name otherwise MDB is not deployed
                 Key: WFLY-2383
                 URL: https://issues.jboss.org/browse/WFLY-2383
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Stefano Maestri


The resource-adapter id has to have the same name as the ra archive has. Otherwise the the MDB is not deployed. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 06:00:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 25 Oct 2013 06:00:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2383) resource-adapter id attribute
 has to match ra name otherwise MDB is not deployed
In-Reply-To: <JIRA.12508785.1382695105000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508785.1382695105000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508785.1382695105000.17641.1382695203922@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2383:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1012044

    
> resource-adapter id attribute has to match ra name otherwise MDB is not deployed
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-2383
>                 URL: https://issues.jboss.org/browse/WFLY-2383
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Stefano Maestri
>
> The resource-adapter id has to have the same name as the ra archive has. Otherwise the the MDB is not deployed. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 06:04:01 2013
From: jira-events at lists.jboss.org (Ivo Studensky (JIRA))
Date: Fri, 25 Oct 2013 06:04:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1109)
 SimpleResourceAdapterRepository fails to convert RA uniqueId to RA name
In-Reply-To: <JIRA.12508786.1382695415360@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508786.1382695415360@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508786.1382695415360.17643.1382695441944@jira02.app.mwc.hst.phx2.redhat.com>

Ivo Studensky created JBJCA-1109:
------------------------------------

             Summary: SimpleResourceAdapterRepository fails to convert RA uniqueId to RA name
                 Key: JBJCA-1109
                 URL: https://issues.jboss.org/browse/JBJCA-1109
             Project: IronJacamar
          Issue Type: Bug
          Components: Core
    Affects Versions: 1.1.1.Final, 1.0.21.Final
            Reporter: Ivo Studensky
            Assignee: Jesper Pedersen


SimpleResourceAdapterRepository compares a given ResourceAdapter class with resource adapters from MetadataRepository just by their class names. So if there are 2 separate RAs deployed in the server both with the same ResourceAdapter class (e.g. org.hornetq.ra.HornetQResourceAdapter), it randomly takes one of those and cannot safely distinguish them. 

3 places affected by this:
1. #getMessageListeners() [1]
2. #getEnpoint() because of usage of getMDRIdentifier   [2] [3]
3. #getResourceAdapters()   [4]

I used a dirty hack to work around this issue which changes API and doesn't fix #3, see [5] + a few changes according to [5] in WF's EJBUtilities.
A possible fix could be to "encode" the RA name into its {{uniqueId}}, so that such a uniqueId would contain RA class name, RA name and eventually a counter (increasing number).


[1] https://github.com/ironjacamar/ironjacamar/blob/1.1/core/src/main/java/org/jboss/jca/core/rar/SimpleResourceAdapterRepository.java#L367
[2] https://github.com/ironjacamar/ironjacamar/blob/1.1/core/src/main/java/org/jboss/jca/core/rar/SimpleResourceAdapterRepository.java#L316
[3]  https://github.com/ironjacamar/ironjacamar/blob/1.1/core/src/main/java/org/jboss/jca/core/rar/SimpleResourceAdapterRepository.java#L538
[4] https://github.com/ironjacamar/ironjacamar/blob/1.1/core/src/main/java/org/jboss/jca/core/rar/SimpleResourceAdapterRepository.java#L251

[5] https://github.com/istudens/ironjacamar/commit/0f716538ea91e2b547f83f41c67c554e3d1383db



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 06:08:01 2013
From: jira-events at lists.jboss.org (Ivo Studensky (JIRA))
Date: Fri, 25 Oct 2013 06:08:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2384) 2 RAs with the same
 ResourceAdapter class do not work (they overlap in JCA internals)
In-Reply-To: <JIRA.12508787.1382695642179@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508787.1382695642179@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508787.1382695642179.17648.1382695681903@jira02.app.mwc.hst.phx2.redhat.com>

Ivo Studensky created WFLY-2384:
-----------------------------------

             Summary: 2 RAs with the same ResourceAdapter class do not work (they overlap in JCA internals)
                 Key: WFLY-2384
                 URL: https://issues.jboss.org/browse/WFLY-2384
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JCA
    Affects Versions: 8.0.0.Beta1
            Reporter: Ivo Studensky
            Assignee: Jesper Pedersen


SimpleResourceAdapterRepository implementation breaks the possibility to deploy 2 separate resource adapters with the same resource adapter class to WildFly server. 
More details in the linked IJ jira.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 06:12:02 2013
From: jira-events at lists.jboss.org (Ivo Studensky (JIRA))
Date: Fri, 25 Oct 2013 06:12:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2384) 2 RAs with the same
 ResourceAdapter classes do not work (they overlap in JCA internals)
In-Reply-To: <JIRA.12508787.1382695642000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508787.1382695642000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508787.1382695642000.17654.1382695922005@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ivo Studensky updated WFLY-2384:
--------------------------------

    Summary: 2 RAs with the same ResourceAdapter classes do not work (they overlap in JCA internals)  (was: 2 RAs with the same ResourceAdapter class do not work (they overlap in JCA internals))

    
> 2 RAs with the same ResourceAdapter classes do not work (they overlap in JCA internals)
> ---------------------------------------------------------------------------------------
>
>                 Key: WFLY-2384
>                 URL: https://issues.jboss.org/browse/WFLY-2384
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Ivo Studensky
>            Assignee: Jesper Pedersen
>
> SimpleResourceAdapterRepository implementation breaks the possibility to deploy 2 separate resource adapters with the same resource adapter class to WildFly server. 
> More details in the linked IJ jira.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 06:16:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 25 Oct 2013 06:16:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2384) 2 RAs with the same
 ResourceAdapter classes do not work (they overlap in JCA internals)
In-Reply-To: <JIRA.12508787.1382695642000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508787.1382695642000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508787.1382695642000.17661.1382696162483@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2384:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1023380

    
> 2 RAs with the same ResourceAdapter classes do not work (they overlap in JCA internals)
> ---------------------------------------------------------------------------------------
>
>                 Key: WFLY-2384
>                 URL: https://issues.jboss.org/browse/WFLY-2384
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Ivo Studensky
>            Assignee: Jesper Pedersen
>
> SimpleResourceAdapterRepository implementation breaks the possibility to deploy 2 separate resource adapters with the same resource adapter class to WildFly server. 
> More details in the linked IJ jira.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 06:16:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 25 Oct 2013 06:16:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2384) 2 RAs with the same
 ResourceAdapter classes do not work (they overlap in JCA internals)
In-Reply-To: <JIRA.12508787.1382695642000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508787.1382695642000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508787.1382695642000.17665.1382696162685@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824945#comment-12824945 ] 

RH Bugzilla Integration commented on WFLY-2384:
-----------------------------------------------

Ivo Studensky <istudens at redhat.com> made a comment on [bug 1023380|https://bugzilla.redhat.com/show_bug.cgi?id=1023380]

Description of problem:
SimpleResourceAdapterRepository implementation breaks the possibility to deploy 2 separate resource adapters with the same resource adapter class to WildFly server.
More details in the linked IJ jira.
                
> 2 RAs with the same ResourceAdapter classes do not work (they overlap in JCA internals)
> ---------------------------------------------------------------------------------------
>
>                 Key: WFLY-2384
>                 URL: https://issues.jboss.org/browse/WFLY-2384
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Ivo Studensky
>            Assignee: Jesper Pedersen
>
> SimpleResourceAdapterRepository implementation breaks the possibility to deploy 2 separate resource adapters with the same resource adapter class to WildFly server. 
> More details in the linked IJ jira.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 07:39:01 2013
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Fri, 25 Oct 2013 07:39:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1260) Remove workaround for
 shutting down the ModelControllerClientOperationHandlers
In-Reply-To: <JIRA.12454378.1323444128000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12454378.1323444128000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12454378.1323444128000.17705.1382701141921@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824956#comment-12824956 ] 

Emanuel Muckenhuber commented on WFLY-1260:
-------------------------------------------

We actually did remove the workarounds from the operation handlers to wait for completion. Now on a shutdown we don't allow new requests, but wait for the completion of currently running operations. This however does not use a graceful shutdown API and just relies on the service shutdown events.
                
> Remove workaround for shutting down the ModelControllerClientOperationHandlers
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-1260
>                 URL: https://issues.jboss.org/browse/WFLY-1260
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Emanuel Muckenhuber
>
> Once the graceful shutdown API is in place we need to cleanup the way the ModelControllerClientOperationHandler channels are closed. Currently we are waiting for all current operations to complete, in order that the response for :reload / :shutdown operations are sent.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 07:55:01 2013
From: jira-events at lists.jboss.org (Stefano Maestri (JIRA))
Date: Fri, 25 Oct 2013 07:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2385) Resource adapter recovery
 doesn't allow fallback to security credentials
In-Reply-To: <JIRA.12508796.1382702010751@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508796.1382702010751@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508796.1382702010751.17759.1382702101983@jira02.app.mwc.hst.phx2.redhat.com>

Stefano Maestri created WFLY-2385:
-------------------------------------

             Summary:  Resource adapter recovery doesn't allow fallback to security credentials
                 Key: WFLY-2385
                 URL: https://issues.jboss.org/browse/WFLY-2385
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Stefano Maestri




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 07:55:02 2013
From: jira-events at lists.jboss.org (Stefano Maestri (JIRA))
Date: Fri, 25 Oct 2013 07:55:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2385) Resource adapter recovery
 doesn't allow fallback to security credentials
In-Reply-To: <JIRA.12508796.1382702010000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508796.1382702010000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508796.1382702010000.17762.1382702102107@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefano Maestri reassigned WFLY-2385:
-------------------------------------

    Assignee: Stefano Maestri

    
>  Resource adapter recovery doesn't allow fallback to security credentials
> -------------------------------------------------------------------------
>
>                 Key: WFLY-2385
>                 URL: https://issues.jboss.org/browse/WFLY-2385
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Stefano Maestri
>            Assignee: Stefano Maestri
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 08:05:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 25 Oct 2013 08:05:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1960) CDI @Inject of @Stateless
 @WebService cause WELD-001408 Unsatisfied dependencies
In-Reply-To: <JIRA.12499428.1377603560000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499428.1377603560000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499428.1377603560000.17809.1382702702120@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824971#comment-12824971 ] 

RH Bugzilla Integration commented on WFLY-1960:
-----------------------------------------------

Jozef Hartinger <jharting at redhat.com> changed the Status of [bug 1001610|https://bugzilla.redhat.com/show_bug.cgi?id=1001610] from NEW to CLOSED
                
> CDI @Inject of @Stateless @WebService cause WELD-001408 Unsatisfied dependencies
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-1960
>                 URL: https://issues.jboss.org/browse/WFLY-1960
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld, EJB, Web Services
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Aslak Knutsen
>            Assignee: Martin Kouba
>
> CDI @Inject of @WebService does not work. 
> {code}
> import javax.ejb.Stateless;
> import javax.jws.WebService;
>  
> @Stateless
> @WebService
> public class TestBean {
> }
>  
>  
> import javax.inject.Inject;
>  
> import org.jboss.arquillian.container.test.api.Deployment;
> import org.jboss.arquillian.junit.Arquillian;
> import org.jboss.shrinkwrap.api.ShrinkWrap;
> import org.jboss.shrinkwrap.api.asset.EmptyAsset;
> import org.jboss.shrinkwrap.api.spec.WebArchive;
> import org.junit.Test;
> import org.junit.runner.RunWith;
>  
>  
> @RunWith(Arquillian.class)
> public class TestBeanIT {
>  
>     @Inject
>     TestBean bean;
>  
>     @Deployment
>     public static WebArchive createDeployment() {
>         WebArchive arch =  ShrinkWrap.create(WebArchive.class);
>         arch.addClass(TestBean.class);
>         arch.addAsWebInfResource(EmptyAsset.INSTANCE, "beans.xml");
>         return arch;
>     }
>  
>     @Test
>     public void fooTest() throws Exception {
>  
>     }
> }
> {code}
> Using CDI to do a non contextual injection on a class where @EJB is used instead of @Inject works.
> {code}
> @RunWith(Arquillian.class)
> public class TestBeanIT {
>  
>     @EJB
>     TestBean bean;
>     ...
> }
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 08:10:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 25 Oct 2013 08:10:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-78) Intermittent failures in
	RespawnTestCase
In-Reply-To: <JIRA.12483133.1358904844000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12483133.1358904844000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12483133.1358904844000.17823.1382703002117@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824975#comment-12824975 ] 

RH Bugzilla Integration commented on WFLY-78:
---------------------------------------------

Pavel Jelinek <pjelinek at redhat.com> made a comment on [bug 1012809|https://bugzilla.redhat.com/show_bug.cgi?id=1012809]

Verified for EAP6.2.0.ER6.
                
> Intermittent failures in RespawnTestCase
> ----------------------------------------
>
>                 Key: WFLY-78
>                 URL: https://issues.jboss.org/browse/WFLY-78
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.Alpha1
>
>
> Problems like [1] still pop up fairly frequently. It seems the same 3 tests fail.
> Failed tests:   testReloadHcButNotServers(org.jboss.as.test.integration.respawn.RespawnTestCase)
> testReloadHcButNotServersWithFailedServer(org.jboss.as.test.integration.respawn.RespawnTestCase)  testHCReloadAbortPreservesServers(org.jboss.as.test.integration.respawn.RespawnTestCase)
> [1] http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-master-ignore/327/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 08:10:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 25 Oct 2013 08:10:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-78) Intermittent failures in
	RespawnTestCase
In-Reply-To: <JIRA.12483133.1358904844000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12483133.1358904844000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12483133.1358904844000.17826.1382703002287@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824976#comment-12824976 ] 

RH Bugzilla Integration commented on WFLY-78:
---------------------------------------------

Pavel Jelinek <pjelinek at redhat.com> changed the Status of [bug 1012809|https://bugzilla.redhat.com/show_bug.cgi?id=1012809] from ON_QA to VERIFIED
                
> Intermittent failures in RespawnTestCase
> ----------------------------------------
>
>                 Key: WFLY-78
>                 URL: https://issues.jboss.org/browse/WFLY-78
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.Alpha1
>
>
> Problems like [1] still pop up fairly frequently. It seems the same 3 tests fail.
> Failed tests:   testReloadHcButNotServers(org.jboss.as.test.integration.respawn.RespawnTestCase)
> testReloadHcButNotServersWithFailedServer(org.jboss.as.test.integration.respawn.RespawnTestCase)  testHCReloadAbortPreservesServers(org.jboss.as.test.integration.respawn.RespawnTestCase)
> [1] http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-master-ignore/327/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 08:12:02 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 25 Oct 2013 08:12:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2386) Hibernate envers related
	issues on JDK8
In-Reply-To: <JIRA.12508800.1382703070477@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508800.1382703070477@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508800.1382703070477.17832.1382703122033@jira02.app.mwc.hst.phx2.redhat.com>

Tomaz Cerar created WFLY-2386:
---------------------------------

             Summary: Hibernate envers related issues on JDK8
                 Key: WFLY-2386
                 URL: https://issues.jboss.org/browse/WFLY-2386
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JPA / Hibernate
    Affects Versions: 8.0.0.Beta1
         Environment: latest JDK8 build
            Reporter: Tomaz Cerar
            Assignee: Scott Marlow


There are many hibernate / envers related tests that fail when running Testsuite on JDK8
{noformat}
[31m17:03:15,195 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 4) MSC000001: Failed to start service jboss.persistenceunit."hibernate_dom4j.ear/hibernate_dom4j.war#web_hibernate3_pc": org.jboss.msc.service.StartException in service jboss.persistenceunit."hibernate_dom4j.ear/hibernate_dom4j.war#web_hibernate3_pc": java.lang.IllegalAccessError: tried to access method java.lang.Object.clone()Ljava/lang/Object; from class org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator
    at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:169)
    at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117)
    at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0-ea]
    at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:463) [wildfly-security-manager-1.0.0.Beta3.jar:1.0.0.Beta3]
    at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:178)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0-ea]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0-ea]
    at java.lang.Thread.run(Thread.java:724) [rt.jar:1.8.0-ea]
    at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
Caused by: java.lang.IllegalAccessError: tried to access method java.lang.Object.clone()Ljava/lang/Object; from class org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator
    at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.cloneAndSetupRevisionInfoRelationMapping(AuditMetadataGenerator.java:140)
    at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.addRevisionInfoRelation(AuditMetadataGenerator.java:152)
    at org.hibernate.envers.configuration.internal.metadata.IdMetadataGenerator.addId(IdMetadataGenerator.java:210)
    at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.generateFirstPass(AuditMetadataGenerator.java:561)
    at org.hibernate.envers.configuration.internal.EntitiesConfigurator.configure(EntitiesConfigurator.java:110)
    at org.hibernate.envers.configuration.spi.AuditConfiguration.<init>(AuditConfiguration.java:130)
    at org.hibernate.envers.configuration.spi.AuditConfiguration.getFor(AuditConfiguration.java:180)
    at org.hibernate.envers.event.spi.EnversIntegrator.integrate(EnversIntegrator.java:76)
    at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:310)
    at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1837)
    at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:854)
    at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:847)
    at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:396)
    at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:846)
    at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
    at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:151)
    ... 8 more
{noformat}


for details see:
http://brontes.lab.eng.brq.redhat.com/viewType.html?buildTypeId=WF_MasterLinuxJdk8&branch_WF=__all_branches__

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 08:36:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 25 Oct 2013 08:36:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-794)
 javax.naming.NameNotFoundException: rmi://127.0.0.1:1090/jmxrmi thrown when
 creating MBeanServerConnection
In-Reply-To: <JIRA.12488795.1365437999000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12488795.1365437999000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488795.1365437999000.17902.1382704562594@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824982#comment-12824982 ] 

RH Bugzilla Integration commented on WFLY-794:
----------------------------------------------

Stuart Douglas <sdouglas at redhat.com> made a comment on [bug 958166|https://bugzilla.redhat.com/show_bug.cgi?id=958166]

I am going to nack this. Work is being done on this in Wildfly upstream by Eduardo but it is quite invasive and I do not feel comfortable putting it into EAP 6.2 at this time. Assuming we find no problems with it in Wildfly it should be possible to get this into 6.3.
                
> javax.naming.NameNotFoundException: rmi://127.0.0.1:1090/jmxrmi thrown when creating MBeanServerConnection
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-794
>                 URL: https://issues.jboss.org/browse/WFLY-794
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>            Reporter: Alex Corvino
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>         Attachments: jmx-test.jar, JmxClient.java, JMXConnectionBean.java, JmxServer.java
>
>
> When trying to create a MBeanServerConnection to a NON-JBoss application from within an EJB a "javax.naming.NameNotFoundException" is thrown. 
> Steps to reproduce:
> Set up a stand-alone application that exposes an MBean. (ActiveMQ will work in this case.)
> Modify the attached JMXConnectionBean.java to connect to the ActiveMQ instance.
> Deploy the bean. A NameNotFoundException will be thrown.
> I've seen this behavior in 7.1.1.Final, 7.1.2.Final (EAP), 7.1.3.Final (EAP), EAP 6.1.0.Alpha (7.2.0.Final). 
> Note that this behavior is NOT seen when connecting to another JBoss server. 
> Full stack trace:
> {code} 
> Caused by: java.io.IOException: Failed to retrieve RMIServer stub: javax.naming.NameNotFoundException: rmi://127.0.0.1:1090/jmxrmi -- service jboss.naming.context.java.rmi:."127.0.0.1:1090".jmxrmi
> 	at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:340) [:1.6.0_26]
> 	at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:248) [:1.6.0_26]
> 	at com.example.JMXConnectionBean.init(JMXConnectionBean.java:28)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_26]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_26]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_26]
> 	at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_26]
> 	at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:70)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.ee.component.ManagedReferenceInterceptor.processInvocation(ManagedReferenceInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:44)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor$CustomSessionInvocationContext.proceed(SessionInvocationContextInterceptor.java:126)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:211)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.requiresNew(CMTTxInterceptor.java:313)
> 	at org.jboss.as.ejb3.tx.SingletonLifecycleCMTTxInterceptor.processInvocation(SingletonLifecycleCMTTxInterceptor.java:56)
> 	at org.jboss.as.ejb3.tx.SingletonLifecycleCMTTxInterceptor.processInvocation(SingletonLifecycleCMTTxInterceptor.java:42)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor.processInvocation(SessionInvocationContextInterceptor.java:71)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:152)
> 	... 9 more
> Caused by: javax.naming.NameNotFoundException: rmi://127.0.0.1:1090/jmxrmi -- service jboss.naming.context.java.rmi:."127.0.0.1:1090".jmxrmi
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:87)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:173)
> 	at org.jboss.as.naming.InitialContext.lookup(InitialContext.java:47)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:209)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:392) [:1.6.0_26]
> 	at javax.management.remote.rmi.RMIConnector.findRMIServerJNDI(RMIConnector.java:1888) [:1.6.0_26]
> 	at javax.management.remote.rmi.RMIConnector.findRMIServer(RMIConnector.java:1858) [:1.6.0_26]
> 	at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:257) [:1.6.0_26]
> 	... 37 more
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 08:56:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 25 Oct 2013 08:56:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2385) Resource adapter recovery
 doesn't allow fallback to security credentials
In-Reply-To: <JIRA.12508796.1382702010000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508796.1382702010000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508796.1382702010000.17926.1382705762079@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2385:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1023446

    
>  Resource adapter recovery doesn't allow fallback to security credentials
> -------------------------------------------------------------------------
>
>                 Key: WFLY-2385
>                 URL: https://issues.jboss.org/browse/WFLY-2385
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Stefano Maestri
>            Assignee: Stefano Maestri
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 08:56:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 25 Oct 2013 08:56:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2385) Resource adapter recovery
 doesn't allow fallback to security credentials
In-Reply-To: <JIRA.12508796.1382702010000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508796.1382702010000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508796.1382702010000.17929.1382705762194@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824988#comment-12824988 ] 

RH Bugzilla Integration commented on WFLY-2385:
-----------------------------------------------

Stefano Maestri <smaestri at redhat.com> made a comment on [bug 1023446|https://bugzilla.redhat.com/show_bug.cgi?id=1023446]

Description of problem:
 Resource adapter recovery doesn't allow fallback to security credentials
                
>  Resource adapter recovery doesn't allow fallback to security credentials
> -------------------------------------------------------------------------
>
>                 Key: WFLY-2385
>                 URL: https://issues.jboss.org/browse/WFLY-2385
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Stefano Maestri
>            Assignee: Stefano Maestri
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 09:04:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 25 Oct 2013 09:04:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2385) Resource adapter recovery
 doesn't allow fallback to security credentials
In-Reply-To: <JIRA.12508796.1382702010000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508796.1382702010000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508796.1382702010000.17957.1382706242236@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12824996#comment-12824996 ] 

RH Bugzilla Integration commented on WFLY-2385:
-----------------------------------------------

Stefano Maestri <smaestri at redhat.com> changed the Status of [bug 1023446|https://bugzilla.redhat.com/show_bug.cgi?id=1023446] from NEW to ASSIGNED
                
>  Resource adapter recovery doesn't allow fallback to security credentials
> -------------------------------------------------------------------------
>
>                 Key: WFLY-2385
>                 URL: https://issues.jboss.org/browse/WFLY-2385
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Stefano Maestri
>            Assignee: Stefano Maestri
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 09:04:02 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Fri, 25 Oct 2013 09:04:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2341) WildFly-8.0.0.Beta1 throws an
 exception during persistence unit starting on java 1.8.0-ea-b111
In-Reply-To: <JIRA.12508227.1382181208000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508227.1382181208000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508227.1382181208000.17962.1382706242475@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow resolved WFLY-2341.
--------------------------------

    Resolution: Duplicate Issue


This looks like a duplicate of https://bugs.openjdk.java.net/browse/JDK-8026394
                
> WildFly-8.0.0.Beta1 throws an exception during persistence unit starting on java 1.8.0-ea-b111
> ----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2341
>                 URL: https://issues.jboss.org/browse/WFLY-2341
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Beta1
>         Environment: % java -version
> java version "1.8.0-ea"
> Java(TM) SE Runtime Environment (build 1.8.0-ea-b111)
> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b53, mixed mode)
> % uname -a
> Linux irtysh.kostousov.net 3.11.1-200.fc19.x86_64 #1 SMP Sat Sep 14 15:04:51 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
>            Reporter: Denis Kostousov
>            Assignee: Scott Marlow
>            Priority: Critical
>         Attachments: hibernate.HEAD.build.log
>
>
> An exception occurs during application deploying on Wildfly 8.0.0.Beta1 after jdk was changed from 1.8.0-ea-b109 to 1.8.0-ea-b111. On 1.8.0-ea-b109 same code works fine.
> {code}
> 2013-10-19 16:52:49,975 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 52) MSC000001: Failed to start service jboss.persistenceunit."acquiring-gate-ear-0.5-SNAPSHOT.ear/server-0.5-SNAPSHOT.war#AGDirectory": org.jboss.msc.service.StartException in service jboss.persistenceunit."acquiring-gate-ear-0.5-SNAPSHOT.ear/server-0.5-SNAPSHOT.war#AGDirectory": java.lang.IllegalAccessError: tried to access method java.lang.Object.clone()Ljava/lang/Object; from class org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:169) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0-ea]
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:463) [wildfly-security-manager-1.0.0.Beta3.jar:1.0.0.Beta3]
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:178) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0-ea]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0-ea]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.8.0-ea]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: java.lang.IllegalAccessError: tried to access method java.lang.Object.clone()Ljava/lang/Object; from class org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator
> 	at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.cloneAndSetupRevisionInfoRelationMapping(AuditMetadataGenerator.java:140)
> 	at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.addRevisionInfoRelation(AuditMetadataGenerator.java:152)
> 	at org.hibernate.envers.configuration.internal.metadata.IdMetadataGenerator.addId(IdMetadataGenerator.java:210)
> 	at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.generateFirstPass(AuditMetadataGenerator.java:561)
> 	at org.hibernate.envers.configuration.internal.EntitiesConfigurator.configure(EntitiesConfigurator.java:110)
> 	at org.hibernate.envers.configuration.spi.AuditConfiguration.<init>(AuditConfiguration.java:130)
> 	at org.hibernate.envers.configuration.spi.AuditConfiguration.getFor(AuditConfiguration.java:180)
> 	at org.hibernate.envers.event.spi.EnversIntegrator.integrate(EnversIntegrator.java:76)
> 	at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:310)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1837)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:854)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:847)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:396)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:846)
> 	at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:151) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	... 8 more
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 09:04:02 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Fri, 25 Oct 2013 09:04:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2386) Hibernate envers related
	issues on JDK8
In-Reply-To: <JIRA.12508800.1382703070000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508800.1382703070000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508800.1382703070000.17967.1382706242763@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow resolved WFLY-2386.
--------------------------------

    Resolution: Duplicate Issue


duplicate of https://bugs.openjdk.java.net/browse/JDK-8026394
                
> Hibernate envers related issues on JDK8
> ---------------------------------------
>
>                 Key: WFLY-2386
>                 URL: https://issues.jboss.org/browse/WFLY-2386
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Beta1
>         Environment: latest JDK8 build
>            Reporter: Tomaz Cerar
>            Assignee: Scott Marlow
>
> There are many hibernate / envers related tests that fail when running Testsuite on JDK8
> {noformat}
> [31m17:03:15,195 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 4) MSC000001: Failed to start service jboss.persistenceunit."hibernate_dom4j.ear/hibernate_dom4j.war#web_hibernate3_pc": org.jboss.msc.service.StartException in service jboss.persistenceunit."hibernate_dom4j.ear/hibernate_dom4j.war#web_hibernate3_pc": java.lang.IllegalAccessError: tried to access method java.lang.Object.clone()Ljava/lang/Object; from class org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator
>     at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:169)
>     at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117)
>     at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0-ea]
>     at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:463) [wildfly-security-manager-1.0.0.Beta3.jar:1.0.0.Beta3]
>     at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:178)
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0-ea]
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0-ea]
>     at java.lang.Thread.run(Thread.java:724) [rt.jar:1.8.0-ea]
>     at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: java.lang.IllegalAccessError: tried to access method java.lang.Object.clone()Ljava/lang/Object; from class org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator
>     at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.cloneAndSetupRevisionInfoRelationMapping(AuditMetadataGenerator.java:140)
>     at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.addRevisionInfoRelation(AuditMetadataGenerator.java:152)
>     at org.hibernate.envers.configuration.internal.metadata.IdMetadataGenerator.addId(IdMetadataGenerator.java:210)
>     at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.generateFirstPass(AuditMetadataGenerator.java:561)
>     at org.hibernate.envers.configuration.internal.EntitiesConfigurator.configure(EntitiesConfigurator.java:110)
>     at org.hibernate.envers.configuration.spi.AuditConfiguration.<init>(AuditConfiguration.java:130)
>     at org.hibernate.envers.configuration.spi.AuditConfiguration.getFor(AuditConfiguration.java:180)
>     at org.hibernate.envers.event.spi.EnversIntegrator.integrate(EnversIntegrator.java:76)
>     at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:310)
>     at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1837)
>     at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:854)
>     at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:847)
>     at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:396)
>     at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:846)
>     at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
>     at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:151)
>     ... 8 more
> {noformat}
> for details see:
> http://brontes.lab.eng.brq.redhat.com/viewType.html?buildTypeId=WF_MasterLinuxJdk8&branch_WF=__all_branches__

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 09:06:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 25 Oct 2013 09:06:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-794)
 javax.naming.NameNotFoundException: rmi://127.0.0.1:1090/jmxrmi thrown when
 creating MBeanServerConnection
In-Reply-To: <JIRA.12488795.1365437999000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12488795.1365437999000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488795.1365437999000.17971.1382706362039@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825000#comment-12825000 ] 

RH Bugzilla Integration commented on WFLY-794:
----------------------------------------------

Stuart Douglas <sdouglas at redhat.com> made a comment on [bug 958166|https://bugzilla.redhat.com/show_bug.cgi?id=958166]

Assigning to Eduardo, as he is doing the work in Wildfly.
                
> javax.naming.NameNotFoundException: rmi://127.0.0.1:1090/jmxrmi thrown when creating MBeanServerConnection
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-794
>                 URL: https://issues.jboss.org/browse/WFLY-794
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>            Reporter: Alex Corvino
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>         Attachments: jmx-test.jar, JmxClient.java, JMXConnectionBean.java, JmxServer.java
>
>
> When trying to create a MBeanServerConnection to a NON-JBoss application from within an EJB a "javax.naming.NameNotFoundException" is thrown. 
> Steps to reproduce:
> Set up a stand-alone application that exposes an MBean. (ActiveMQ will work in this case.)
> Modify the attached JMXConnectionBean.java to connect to the ActiveMQ instance.
> Deploy the bean. A NameNotFoundException will be thrown.
> I've seen this behavior in 7.1.1.Final, 7.1.2.Final (EAP), 7.1.3.Final (EAP), EAP 6.1.0.Alpha (7.2.0.Final). 
> Note that this behavior is NOT seen when connecting to another JBoss server. 
> Full stack trace:
> {code} 
> Caused by: java.io.IOException: Failed to retrieve RMIServer stub: javax.naming.NameNotFoundException: rmi://127.0.0.1:1090/jmxrmi -- service jboss.naming.context.java.rmi:."127.0.0.1:1090".jmxrmi
> 	at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:340) [:1.6.0_26]
> 	at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:248) [:1.6.0_26]
> 	at com.example.JMXConnectionBean.init(JMXConnectionBean.java:28)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_26]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_26]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_26]
> 	at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_26]
> 	at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:70)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.ee.component.ManagedReferenceInterceptor.processInvocation(ManagedReferenceInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:44)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor$CustomSessionInvocationContext.proceed(SessionInvocationContextInterceptor.java:126)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:211)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.requiresNew(CMTTxInterceptor.java:313)
> 	at org.jboss.as.ejb3.tx.SingletonLifecycleCMTTxInterceptor.processInvocation(SingletonLifecycleCMTTxInterceptor.java:56)
> 	at org.jboss.as.ejb3.tx.SingletonLifecycleCMTTxInterceptor.processInvocation(SingletonLifecycleCMTTxInterceptor.java:42)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor.processInvocation(SessionInvocationContextInterceptor.java:71)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:152)
> 	... 9 more
> Caused by: javax.naming.NameNotFoundException: rmi://127.0.0.1:1090/jmxrmi -- service jboss.naming.context.java.rmi:."127.0.0.1:1090".jmxrmi
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:87)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:173)
> 	at org.jboss.as.naming.InitialContext.lookup(InitialContext.java:47)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:209)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:392) [:1.6.0_26]
> 	at javax.management.remote.rmi.RMIConnector.findRMIServerJNDI(RMIConnector.java:1888) [:1.6.0_26]
> 	at javax.management.remote.rmi.RMIConnector.findRMIServer(RMIConnector.java:1858) [:1.6.0_26]
> 	at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:257) [:1.6.0_26]
> 	... 37 more
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 09:08:02 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Fri, 25 Oct 2013 09:08:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2341) WildFly-8.0.0.Beta1 throws an
 exception during persistence unit starting on java 1.8.0-ea-b111
In-Reply-To: <JIRA.12508227.1382181208000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508227.1382181208000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508227.1382181208000.17985.1382706482091@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825002#comment-12825002 ] 

Scott Marlow commented on WFLY-2341:
------------------------------------

>From looking at https://bugs.openjdk.java.net/browse/JDK-8026394, it sounds like the clone bug may of been fixed, other there are comments that its not.  Best to try again with the jdk patch.
                
> WildFly-8.0.0.Beta1 throws an exception during persistence unit starting on java 1.8.0-ea-b111
> ----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2341
>                 URL: https://issues.jboss.org/browse/WFLY-2341
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Beta1
>         Environment: % java -version
> java version "1.8.0-ea"
> Java(TM) SE Runtime Environment (build 1.8.0-ea-b111)
> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b53, mixed mode)
> % uname -a
> Linux irtysh.kostousov.net 3.11.1-200.fc19.x86_64 #1 SMP Sat Sep 14 15:04:51 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
>            Reporter: Denis Kostousov
>            Assignee: Scott Marlow
>            Priority: Critical
>         Attachments: hibernate.HEAD.build.log
>
>
> An exception occurs during application deploying on Wildfly 8.0.0.Beta1 after jdk was changed from 1.8.0-ea-b109 to 1.8.0-ea-b111. On 1.8.0-ea-b109 same code works fine.
> {code}
> 2013-10-19 16:52:49,975 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 52) MSC000001: Failed to start service jboss.persistenceunit."acquiring-gate-ear-0.5-SNAPSHOT.ear/server-0.5-SNAPSHOT.war#AGDirectory": org.jboss.msc.service.StartException in service jboss.persistenceunit."acquiring-gate-ear-0.5-SNAPSHOT.ear/server-0.5-SNAPSHOT.war#AGDirectory": java.lang.IllegalAccessError: tried to access method java.lang.Object.clone()Ljava/lang/Object; from class org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:169) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0-ea]
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:463) [wildfly-security-manager-1.0.0.Beta3.jar:1.0.0.Beta3]
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:178) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0-ea]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0-ea]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.8.0-ea]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: java.lang.IllegalAccessError: tried to access method java.lang.Object.clone()Ljava/lang/Object; from class org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator
> 	at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.cloneAndSetupRevisionInfoRelationMapping(AuditMetadataGenerator.java:140)
> 	at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.addRevisionInfoRelation(AuditMetadataGenerator.java:152)
> 	at org.hibernate.envers.configuration.internal.metadata.IdMetadataGenerator.addId(IdMetadataGenerator.java:210)
> 	at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.generateFirstPass(AuditMetadataGenerator.java:561)
> 	at org.hibernate.envers.configuration.internal.EntitiesConfigurator.configure(EntitiesConfigurator.java:110)
> 	at org.hibernate.envers.configuration.spi.AuditConfiguration.<init>(AuditConfiguration.java:130)
> 	at org.hibernate.envers.configuration.spi.AuditConfiguration.getFor(AuditConfiguration.java:180)
> 	at org.hibernate.envers.event.spi.EnversIntegrator.integrate(EnversIntegrator.java:76)
> 	at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:310)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1837)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:854)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:847)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:396)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:846)
> 	at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:151) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	... 8 more
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 09:12:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Fri, 25 Oct 2013 09:12:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2333) Web deployment code assumes
 only a single ServletContainerInitializer is present in each jar
In-Reply-To: <JIRA.12508164.1382090257000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508164.1382090257000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508164.1382090257000.18004.1382706722124@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-2333.
----------------------------------

    Resolution: Done

    
> Web deployment code assumes only a single ServletContainerInitializer is present in each jar
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2333
>                 URL: https://issues.jboss.org/browse/WFLY-2333
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.CR1
>
>         Attachments: diycdemo.zip, hellomyfaces.zip
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 09:12:02 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Fri, 25 Oct 2013 09:12:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2386) Hibernate envers related
	issues on JDK8
In-Reply-To: <JIRA.12508800.1382703070000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508800.1382703070000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508800.1382703070000.18008.1382706722304@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow closed WFLY-2386.
------------------------------


    
> Hibernate envers related issues on JDK8
> ---------------------------------------
>
>                 Key: WFLY-2386
>                 URL: https://issues.jboss.org/browse/WFLY-2386
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Beta1
>         Environment: latest JDK8 build
>            Reporter: Tomaz Cerar
>            Assignee: Scott Marlow
>
> There are many hibernate / envers related tests that fail when running Testsuite on JDK8
> {noformat}
> [31m17:03:15,195 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 4) MSC000001: Failed to start service jboss.persistenceunit."hibernate_dom4j.ear/hibernate_dom4j.war#web_hibernate3_pc": org.jboss.msc.service.StartException in service jboss.persistenceunit."hibernate_dom4j.ear/hibernate_dom4j.war#web_hibernate3_pc": java.lang.IllegalAccessError: tried to access method java.lang.Object.clone()Ljava/lang/Object; from class org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator
>     at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:169)
>     at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117)
>     at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0-ea]
>     at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:463) [wildfly-security-manager-1.0.0.Beta3.jar:1.0.0.Beta3]
>     at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:178)
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0-ea]
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0-ea]
>     at java.lang.Thread.run(Thread.java:724) [rt.jar:1.8.0-ea]
>     at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: java.lang.IllegalAccessError: tried to access method java.lang.Object.clone()Ljava/lang/Object; from class org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator
>     at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.cloneAndSetupRevisionInfoRelationMapping(AuditMetadataGenerator.java:140)
>     at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.addRevisionInfoRelation(AuditMetadataGenerator.java:152)
>     at org.hibernate.envers.configuration.internal.metadata.IdMetadataGenerator.addId(IdMetadataGenerator.java:210)
>     at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.generateFirstPass(AuditMetadataGenerator.java:561)
>     at org.hibernate.envers.configuration.internal.EntitiesConfigurator.configure(EntitiesConfigurator.java:110)
>     at org.hibernate.envers.configuration.spi.AuditConfiguration.<init>(AuditConfiguration.java:130)
>     at org.hibernate.envers.configuration.spi.AuditConfiguration.getFor(AuditConfiguration.java:180)
>     at org.hibernate.envers.event.spi.EnversIntegrator.integrate(EnversIntegrator.java:76)
>     at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:310)
>     at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1837)
>     at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:854)
>     at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:847)
>     at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:396)
>     at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:846)
>     at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
>     at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:151)
>     ... 8 more
> {noformat}
> for details see:
> http://brontes.lab.eng.brq.redhat.com/viewType.html?buildTypeId=WF_MasterLinuxJdk8&branch_WF=__all_branches__

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 09:14:02 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Fri, 25 Oct 2013 09:14:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2341) WildFly-8.0.0.Beta1 throws an
 exception during persistence unit starting on java 1.8.0-ea-b111
In-Reply-To: <JIRA.12508227.1382181208000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508227.1382181208000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508227.1382181208000.18013.1382706842016@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow closed WFLY-2341.
------------------------------


    
> WildFly-8.0.0.Beta1 throws an exception during persistence unit starting on java 1.8.0-ea-b111
> ----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2341
>                 URL: https://issues.jboss.org/browse/WFLY-2341
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Beta1
>         Environment: % java -version
> java version "1.8.0-ea"
> Java(TM) SE Runtime Environment (build 1.8.0-ea-b111)
> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b53, mixed mode)
> % uname -a
> Linux irtysh.kostousov.net 3.11.1-200.fc19.x86_64 #1 SMP Sat Sep 14 15:04:51 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
>            Reporter: Denis Kostousov
>            Assignee: Scott Marlow
>            Priority: Critical
>         Attachments: hibernate.HEAD.build.log
>
>
> An exception occurs during application deploying on Wildfly 8.0.0.Beta1 after jdk was changed from 1.8.0-ea-b109 to 1.8.0-ea-b111. On 1.8.0-ea-b109 same code works fine.
> {code}
> 2013-10-19 16:52:49,975 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 52) MSC000001: Failed to start service jboss.persistenceunit."acquiring-gate-ear-0.5-SNAPSHOT.ear/server-0.5-SNAPSHOT.war#AGDirectory": org.jboss.msc.service.StartException in service jboss.persistenceunit."acquiring-gate-ear-0.5-SNAPSHOT.ear/server-0.5-SNAPSHOT.war#AGDirectory": java.lang.IllegalAccessError: tried to access method java.lang.Object.clone()Ljava/lang/Object; from class org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:169) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0-ea]
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:463) [wildfly-security-manager-1.0.0.Beta3.jar:1.0.0.Beta3]
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:178) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0-ea]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0-ea]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.8.0-ea]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: java.lang.IllegalAccessError: tried to access method java.lang.Object.clone()Ljava/lang/Object; from class org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator
> 	at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.cloneAndSetupRevisionInfoRelationMapping(AuditMetadataGenerator.java:140)
> 	at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.addRevisionInfoRelation(AuditMetadataGenerator.java:152)
> 	at org.hibernate.envers.configuration.internal.metadata.IdMetadataGenerator.addId(IdMetadataGenerator.java:210)
> 	at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.generateFirstPass(AuditMetadataGenerator.java:561)
> 	at org.hibernate.envers.configuration.internal.EntitiesConfigurator.configure(EntitiesConfigurator.java:110)
> 	at org.hibernate.envers.configuration.spi.AuditConfiguration.<init>(AuditConfiguration.java:130)
> 	at org.hibernate.envers.configuration.spi.AuditConfiguration.getFor(AuditConfiguration.java:180)
> 	at org.hibernate.envers.event.spi.EnversIntegrator.integrate(EnversIntegrator.java:76)
> 	at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:310)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1837)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:854)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:847)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:396)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:846)
> 	at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:151) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	... 8 more
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 09:16:03 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Fri, 25 Oct 2013 09:16:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2386) Hibernate envers related
	issues on JDK8
In-Reply-To: <JIRA.12508800.1382703070000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508800.1382703070000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508800.1382703070000.18019.1382706963272@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825006#comment-12825006 ] 

Scott Marlow commented on WFLY-2386:
------------------------------------

will be fixed in jdk8 b113
                
> Hibernate envers related issues on JDK8
> ---------------------------------------
>
>                 Key: WFLY-2386
>                 URL: https://issues.jboss.org/browse/WFLY-2386
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Beta1
>         Environment: latest JDK8 build
>            Reporter: Tomaz Cerar
>            Assignee: Scott Marlow
>
> There are many hibernate / envers related tests that fail when running Testsuite on JDK8
> {noformat}
> [31m17:03:15,195 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 4) MSC000001: Failed to start service jboss.persistenceunit."hibernate_dom4j.ear/hibernate_dom4j.war#web_hibernate3_pc": org.jboss.msc.service.StartException in service jboss.persistenceunit."hibernate_dom4j.ear/hibernate_dom4j.war#web_hibernate3_pc": java.lang.IllegalAccessError: tried to access method java.lang.Object.clone()Ljava/lang/Object; from class org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator
>     at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:169)
>     at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117)
>     at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0-ea]
>     at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:463) [wildfly-security-manager-1.0.0.Beta3.jar:1.0.0.Beta3]
>     at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:178)
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0-ea]
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0-ea]
>     at java.lang.Thread.run(Thread.java:724) [rt.jar:1.8.0-ea]
>     at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: java.lang.IllegalAccessError: tried to access method java.lang.Object.clone()Ljava/lang/Object; from class org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator
>     at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.cloneAndSetupRevisionInfoRelationMapping(AuditMetadataGenerator.java:140)
>     at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.addRevisionInfoRelation(AuditMetadataGenerator.java:152)
>     at org.hibernate.envers.configuration.internal.metadata.IdMetadataGenerator.addId(IdMetadataGenerator.java:210)
>     at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.generateFirstPass(AuditMetadataGenerator.java:561)
>     at org.hibernate.envers.configuration.internal.EntitiesConfigurator.configure(EntitiesConfigurator.java:110)
>     at org.hibernate.envers.configuration.spi.AuditConfiguration.<init>(AuditConfiguration.java:130)
>     at org.hibernate.envers.configuration.spi.AuditConfiguration.getFor(AuditConfiguration.java:180)
>     at org.hibernate.envers.event.spi.EnversIntegrator.integrate(EnversIntegrator.java:76)
>     at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:310)
>     at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1837)
>     at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:854)
>     at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:847)
>     at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:396)
>     at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:846)
>     at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
>     at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:151)
>     ... 8 more
> {noformat}
> for details see:
> http://brontes.lab.eng.brq.redhat.com/viewType.html?buildTypeId=WF_MasterLinuxJdk8&branch_WF=__all_branches__

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 09:18:01 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Fri, 25 Oct 2013 09:18:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2341) WildFly-8.0.0.Beta1 throws an
 exception during persistence unit starting on java 1.8.0-ea-b111
In-Reply-To: <JIRA.12508227.1382181208000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508227.1382181208000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508227.1382181208000.18022.1382707081924@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825007#comment-12825007 ] 

Scott Marlow commented on WFLY-2341:
------------------------------------

Will be fixed in jdk8 b113
                
> WildFly-8.0.0.Beta1 throws an exception during persistence unit starting on java 1.8.0-ea-b111
> ----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2341
>                 URL: https://issues.jboss.org/browse/WFLY-2341
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Beta1
>         Environment: % java -version
> java version "1.8.0-ea"
> Java(TM) SE Runtime Environment (build 1.8.0-ea-b111)
> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b53, mixed mode)
> % uname -a
> Linux irtysh.kostousov.net 3.11.1-200.fc19.x86_64 #1 SMP Sat Sep 14 15:04:51 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
>            Reporter: Denis Kostousov
>            Assignee: Scott Marlow
>            Priority: Critical
>         Attachments: hibernate.HEAD.build.log
>
>
> An exception occurs during application deploying on Wildfly 8.0.0.Beta1 after jdk was changed from 1.8.0-ea-b109 to 1.8.0-ea-b111. On 1.8.0-ea-b109 same code works fine.
> {code}
> 2013-10-19 16:52:49,975 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 52) MSC000001: Failed to start service jboss.persistenceunit."acquiring-gate-ear-0.5-SNAPSHOT.ear/server-0.5-SNAPSHOT.war#AGDirectory": org.jboss.msc.service.StartException in service jboss.persistenceunit."acquiring-gate-ear-0.5-SNAPSHOT.ear/server-0.5-SNAPSHOT.war#AGDirectory": java.lang.IllegalAccessError: tried to access method java.lang.Object.clone()Ljava/lang/Object; from class org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:169) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0-ea]
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:463) [wildfly-security-manager-1.0.0.Beta3.jar:1.0.0.Beta3]
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:178) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0-ea]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0-ea]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.8.0-ea]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: java.lang.IllegalAccessError: tried to access method java.lang.Object.clone()Ljava/lang/Object; from class org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator
> 	at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.cloneAndSetupRevisionInfoRelationMapping(AuditMetadataGenerator.java:140)
> 	at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.addRevisionInfoRelation(AuditMetadataGenerator.java:152)
> 	at org.hibernate.envers.configuration.internal.metadata.IdMetadataGenerator.addId(IdMetadataGenerator.java:210)
> 	at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.generateFirstPass(AuditMetadataGenerator.java:561)
> 	at org.hibernate.envers.configuration.internal.EntitiesConfigurator.configure(EntitiesConfigurator.java:110)
> 	at org.hibernate.envers.configuration.spi.AuditConfiguration.<init>(AuditConfiguration.java:130)
> 	at org.hibernate.envers.configuration.spi.AuditConfiguration.getFor(AuditConfiguration.java:180)
> 	at org.hibernate.envers.event.spi.EnversIntegrator.integrate(EnversIntegrator.java:76)
> 	at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:310)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1837)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:854)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:847)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:396)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:846)
> 	at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:151) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	... 8 more
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 09:29:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 25 Oct 2013 09:29:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-88) Recovery not fully triggered
 when distributed transaction falls down at prepare phase of 2PC
In-Reply-To: <JIRA.12473332.1346248890000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12473332.1346248890000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12473332.1346248890000.18045.1382707742197@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825011#comment-12825011 ] 

RH Bugzilla Integration commented on WFLY-88:
---------------------------------------------

David M. Lloyd <david.lloyd at redhat.com> made a comment on [bug 952746|https://bugzilla.redhat.com/show_bug.cgi?id=952746]

Per agreement with Ondrej, I'm marking this as "not a blocker".
                
> Recovery not fully triggered when distributed transaction falls down at prepare phase of 2PC
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-88
>                 URL: https://issues.jboss.org/browse/WFLY-88
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB, Remoting
>            Reporter: Ivo Studensky
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Alpha1
>
>         Attachments: logs_prepareHaltClient.tgz
>
>
> It looks like recovery process is not fully triggered on a distributed transaction when the transaction falls down at prepare phase of 2PC. In the new crash recovery tests over propagated transactions only one of two servers recovers from the crash, but the other keeps an unfinished tx in its tx log. 
> It corresponds to prepareHaltClient and prepareHaltServer test methods of org.jboss.as.test.jbossts.crashrec.txpropagation.TxPropagationCrashRecoveryTestCase, see JBQA-2604 for general description of the new tests. The prepareHaltClient test crashes the server which initiated the transaction, while as the prepareHaltServer test crashes the second server.
> The tests are written against EAP6.x branch, so for reproducing this it is needed a built server from the 7.1 branch of AS7.
> Steps to reproduce.
> 1. git clone -b as7 git://git.app.eng.bos.redhat.com/jbossqe/eap-tests-transactions.git
> 2. cd eap-tests-transactions
> 3. git checkout tx_propag_crashrec_tests
> 4a. mvn clean verify -Dtest=TxPropagationCrashRecoveryTestCase#prepareHaltClient -Djboss.dist=<path to jboss-as-7.1.3.Final-SNAPSHOT>
> or
> 4b. mvn clean verify -Dtest=TxPropagationCrashRecoveryTestCase#prepareHaltServer -Djboss.dist=<path to jboss-as-7.1.3.Final-SNAPSHOT>
> The logs of prepareHaltClient run attached to this jira.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 09:37:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 25 Oct 2013 09:37:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-88) Recovery not fully triggered
 when distributed transaction falls down at prepare phase of 2PC
In-Reply-To: <JIRA.12473332.1346248890000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12473332.1346248890000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12473332.1346248890000.18080.1382708222447@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825016#comment-12825016 ] 

RH Bugzilla Integration commented on WFLY-88:
---------------------------------------------

Ondrej Chaloupka <ochaloup at redhat.com> made a comment on [bug 952746|https://bugzilla.redhat.com/show_bug.cgi?id=952746]

Agreed that this is not a blocker. Customers will use JTS transactions for distributed cases as it's supported way.

The JTA distributed transactions are not ready till this will be validated and fixed.
                
> Recovery not fully triggered when distributed transaction falls down at prepare phase of 2PC
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-88
>                 URL: https://issues.jboss.org/browse/WFLY-88
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB, Remoting
>            Reporter: Ivo Studensky
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Alpha1
>
>         Attachments: logs_prepareHaltClient.tgz
>
>
> It looks like recovery process is not fully triggered on a distributed transaction when the transaction falls down at prepare phase of 2PC. In the new crash recovery tests over propagated transactions only one of two servers recovers from the crash, but the other keeps an unfinished tx in its tx log. 
> It corresponds to prepareHaltClient and prepareHaltServer test methods of org.jboss.as.test.jbossts.crashrec.txpropagation.TxPropagationCrashRecoveryTestCase, see JBQA-2604 for general description of the new tests. The prepareHaltClient test crashes the server which initiated the transaction, while as the prepareHaltServer test crashes the second server.
> The tests are written against EAP6.x branch, so for reproducing this it is needed a built server from the 7.1 branch of AS7.
> Steps to reproduce.
> 1. git clone -b as7 git://git.app.eng.bos.redhat.com/jbossqe/eap-tests-transactions.git
> 2. cd eap-tests-transactions
> 3. git checkout tx_propag_crashrec_tests
> 4a. mvn clean verify -Dtest=TxPropagationCrashRecoveryTestCase#prepareHaltClient -Djboss.dist=<path to jboss-as-7.1.3.Final-SNAPSHOT>
> or
> 4b. mvn clean verify -Dtest=TxPropagationCrashRecoveryTestCase#prepareHaltServer -Djboss.dist=<path to jboss-as-7.1.3.Final-SNAPSHOT>
> The logs of prepareHaltClient run attached to this jira.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 09:43:01 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 25 Oct 2013 09:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2385) Resource adapter recovery
 doesn't allow fallback to security credentials
In-Reply-To: <JIRA.12508796.1382702010000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508796.1382702010000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508796.1382702010000.18118.1382708581916@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825023#comment-12825023 ] 

RH Bugzilla Integration commented on WFLY-2385:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1023446|https://bugzilla.redhat.com/show_bug.cgi?id=1023446] from ASSIGNED to POST
                
>  Resource adapter recovery doesn't allow fallback to security credentials
> -------------------------------------------------------------------------
>
>                 Key: WFLY-2385
>                 URL: https://issues.jboss.org/browse/WFLY-2385
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Stefano Maestri
>            Assignee: Stefano Maestri
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 09:49:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 25 Oct 2013 09:49:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-88) Recovery not fully triggered
 when distributed transaction falls down at prepare phase of 2PC
In-Reply-To: <JIRA.12473332.1346248890000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12473332.1346248890000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12473332.1346248890000.18129.1382708944333@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825027#comment-12825027 ] 

RH Bugzilla Integration commented on WFLY-88:
---------------------------------------------

mark yarborough <myarboro at redhat.com> made a comment on [bug 952746|https://bugzilla.redhat.com/show_bug.cgi?id=952746]

Triage: QE and Dev agree not a blocker for 6.2.
                
> Recovery not fully triggered when distributed transaction falls down at prepare phase of 2PC
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-88
>                 URL: https://issues.jboss.org/browse/WFLY-88
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB, Remoting
>            Reporter: Ivo Studensky
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Alpha1
>
>         Attachments: logs_prepareHaltClient.tgz
>
>
> It looks like recovery process is not fully triggered on a distributed transaction when the transaction falls down at prepare phase of 2PC. In the new crash recovery tests over propagated transactions only one of two servers recovers from the crash, but the other keeps an unfinished tx in its tx log. 
> It corresponds to prepareHaltClient and prepareHaltServer test methods of org.jboss.as.test.jbossts.crashrec.txpropagation.TxPropagationCrashRecoveryTestCase, see JBQA-2604 for general description of the new tests. The prepareHaltClient test crashes the server which initiated the transaction, while as the prepareHaltServer test crashes the second server.
> The tests are written against EAP6.x branch, so for reproducing this it is needed a built server from the 7.1 branch of AS7.
> Steps to reproduce.
> 1. git clone -b as7 git://git.app.eng.bos.redhat.com/jbossqe/eap-tests-transactions.git
> 2. cd eap-tests-transactions
> 3. git checkout tx_propag_crashrec_tests
> 4a. mvn clean verify -Dtest=TxPropagationCrashRecoveryTestCase#prepareHaltClient -Djboss.dist=<path to jboss-as-7.1.3.Final-SNAPSHOT>
> or
> 4b. mvn clean verify -Dtest=TxPropagationCrashRecoveryTestCase#prepareHaltServer -Djboss.dist=<path to jboss-as-7.1.3.Final-SNAPSHOT>
> The logs of prepareHaltClient run attached to this jira.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 10:30:02 2013
From: jira-events at lists.jboss.org (Emond Papegaaij (JIRA))
Date: Fri, 25 Oct 2013 10:30:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2387) CDI injection in entity
	listeners failing
In-Reply-To: <JIRA.12508815.1382711350293@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508815.1382711350293@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508815.1382711350293.18185.1382711402150@jira02.app.mwc.hst.phx2.redhat.com>

Emond Papegaaij created WFLY-2387:
-------------------------------------

             Summary: CDI injection in entity listeners failing
                 Key: WFLY-2387
                 URL: https://issues.jboss.org/browse/WFLY-2387
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: CDI / Weld, Class Loading, JPA / Hibernate
    Affects Versions: 8.0.0.Beta1
            Reporter: Emond Papegaaij
            Assignee: Stuart Douglas


When trying to use CDI injection in JPA entity listeners, deployment fails with the following exception:
{code}
16:16:37,448 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 15) MSC000001: Failed to start service jboss.persistenceunit."inject-ear.ear#primary": org.jboss.msc.service.StartException in service jboss.persistenceunit."inject-ear.ear#primary": java.lang.IllegalStateException: JBAS016071: Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader at 4eeb95dc. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment.
	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:169)
	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117)
	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:463) [wildfly-security-manager-1.0.0.Beta3.jar:1.0.0.Beta3]
	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:178)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
Caused by: java.lang.IllegalStateException: JBAS016071: Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader at 4eeb95dc. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment.
	at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:75)
	at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:128)
	at org.jboss.weld.Container.instance(Container.java:65)
	at org.jboss.weld.manager.BeanManagerImpl.getBeans(BeanManagerImpl.java:563)
	at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:90)
	at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:358)
	at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:369)
	at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:72)
	at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:60)
	at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:66)
	at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
	at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64)
	at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:90)
	at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$BeanMetaData.<init>(BeanManagerListenerFactory.java:82)
	at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$BeanMetaData.<init>(BeanManagerListenerFactory.java:71)
	at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory.buildListener(BeanManagerListenerFactory.java:57)
	at org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.resolveCallbacks(LegacyCallbackProcessor.java:168)
	at org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.processCallbacksForEntity(LegacyCallbackProcessor.java:71)
	at org.hibernate.jpa.event.spi.JpaIntegrator.integrate(JpaIntegrator.java:150)
	at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:310)
	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1837)
	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:854)
	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:847)
	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:396)
	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:846)
	at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:151)
	... 8 more
{code}

I've created a small showcase of the problem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 10:32:01 2013
From: jira-events at lists.jboss.org (Emond Papegaaij (JIRA))
Date: Fri, 25 Oct 2013 10:32:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2387) CDI injection in entity
	listeners failing
In-Reply-To: <JIRA.12508815.1382711350000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508815.1382711350000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508815.1382711350000.18187.1382711521930@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emond Papegaaij updated WFLY-2387:
----------------------------------

    Description: 
When trying to use CDI injection in JPA entity listeners, deployment fails with the following exception:
{code}
16:16:37,448 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 15) MSC000001: Failed to start service jboss.persistenceunit."inject-ear.ear#primary": org.jboss.msc.service.StartException in service jboss.persistenceunit."inject-ear.ear#primary": java.lang.IllegalStateException: JBAS016071: Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader at 4eeb95dc. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment.
	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:169)
	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117)
	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:463) [wildfly-security-manager-1.0.0.Beta3.jar:1.0.0.Beta3]
	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:178)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
Caused by: java.lang.IllegalStateException: JBAS016071: Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader at 4eeb95dc. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment.
	at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:75)
	at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:128)
	at org.jboss.weld.Container.instance(Container.java:65)
	at org.jboss.weld.manager.BeanManagerImpl.getBeans(BeanManagerImpl.java:563)
	at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:90)
	at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:358)
	at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:369)
	at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:72)
	at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:60)
	at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:66)
	at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
	at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64)
	at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:90)
	at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$BeanMetaData.<init>(BeanManagerListenerFactory.java:82)
	at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$BeanMetaData.<init>(BeanManagerListenerFactory.java:71)
	at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory.buildListener(BeanManagerListenerFactory.java:57)
	at org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.resolveCallbacks(LegacyCallbackProcessor.java:168)
	at org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.processCallbacksForEntity(LegacyCallbackProcessor.java:71)
	at org.hibernate.jpa.event.spi.JpaIntegrator.integrate(JpaIntegrator.java:150)
	at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:310)
	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1837)
	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:854)
	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:847)
	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:396)
	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:846)
	at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:151)
	... 8 more
{code}

I've created a small showcase of the problem: https://github.com/papegaaij/listener-injection

  was:
When trying to use CDI injection in JPA entity listeners, deployment fails with the following exception:
{code}
16:16:37,448 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 15) MSC000001: Failed to start service jboss.persistenceunit."inject-ear.ear#primary": org.jboss.msc.service.StartException in service jboss.persistenceunit."inject-ear.ear#primary": java.lang.IllegalStateException: JBAS016071: Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader at 4eeb95dc. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment.
	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:169)
	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117)
	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:463) [wildfly-security-manager-1.0.0.Beta3.jar:1.0.0.Beta3]
	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:178)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
Caused by: java.lang.IllegalStateException: JBAS016071: Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader at 4eeb95dc. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment.
	at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:75)
	at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:128)
	at org.jboss.weld.Container.instance(Container.java:65)
	at org.jboss.weld.manager.BeanManagerImpl.getBeans(BeanManagerImpl.java:563)
	at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:90)
	at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:358)
	at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:369)
	at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:72)
	at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:60)
	at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:66)
	at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
	at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64)
	at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:90)
	at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$BeanMetaData.<init>(BeanManagerListenerFactory.java:82)
	at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$BeanMetaData.<init>(BeanManagerListenerFactory.java:71)
	at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory.buildListener(BeanManagerListenerFactory.java:57)
	at org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.resolveCallbacks(LegacyCallbackProcessor.java:168)
	at org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.processCallbacksForEntity(LegacyCallbackProcessor.java:71)
	at org.hibernate.jpa.event.spi.JpaIntegrator.integrate(JpaIntegrator.java:150)
	at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:310)
	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1837)
	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:854)
	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:847)
	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:396)
	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:846)
	at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:151)
	... 8 more
{code}

I've created a small showcase of the problem.


    
> CDI injection in entity listeners failing
> -----------------------------------------
>
>                 Key: WFLY-2387
>                 URL: https://issues.jboss.org/browse/WFLY-2387
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld, Class Loading, JPA / Hibernate
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Emond Papegaaij
>            Assignee: Stuart Douglas
>
> When trying to use CDI injection in JPA entity listeners, deployment fails with the following exception:
> {code}
> 16:16:37,448 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 15) MSC000001: Failed to start service jboss.persistenceunit."inject-ear.ear#primary": org.jboss.msc.service.StartException in service jboss.persistenceunit."inject-ear.ear#primary": java.lang.IllegalStateException: JBAS016071: Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader at 4eeb95dc. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment.
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:169)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117)
> 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:463) [wildfly-security-manager-1.0.0.Beta3.jar:1.0.0.Beta3]
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:178)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: java.lang.IllegalStateException: JBAS016071: Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader at 4eeb95dc. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment.
> 	at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:75)
> 	at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:128)
> 	at org.jboss.weld.Container.instance(Container.java:65)
> 	at org.jboss.weld.manager.BeanManagerImpl.getBeans(BeanManagerImpl.java:563)
> 	at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:90)
> 	at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:358)
> 	at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:369)
> 	at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:72)
> 	at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:60)
> 	at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:66)
> 	at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
> 	at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64)
> 	at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:90)
> 	at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$BeanMetaData.<init>(BeanManagerListenerFactory.java:82)
> 	at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$BeanMetaData.<init>(BeanManagerListenerFactory.java:71)
> 	at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory.buildListener(BeanManagerListenerFactory.java:57)
> 	at org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.resolveCallbacks(LegacyCallbackProcessor.java:168)
> 	at org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.processCallbacksForEntity(LegacyCallbackProcessor.java:71)
> 	at org.hibernate.jpa.event.spi.JpaIntegrator.integrate(JpaIntegrator.java:150)
> 	at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:310)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1837)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:854)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:847)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:396)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:846)
> 	at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:151)
> 	... 8 more
> {code}
> I've created a small showcase of the problem: https://github.com/papegaaij/listener-injection

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 10:42:02 2013
From: jira-events at lists.jboss.org (Tom Fonteyne (JIRA))
Date: Fri, 25 Oct 2013 10:42:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-723) SPNEGO backport of
 additional Kerberos ticket decoding
In-Reply-To: <JIRA.12483911.1359631794000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12483911.1359631794000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12483911.1359631794000.18215.1382712122301@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Fonteyne resolved SECURITY-723.
-----------------------------------

    Resolution: Done


Fixed in 2.1. branch - cannot set "Fix Version" field as 2.1.4 is not present yet
                
> SPNEGO backport of additional Kerberos ticket decoding
> ------------------------------------------------------
>
>                 Key: SECURITY-723
>                 URL: https://issues.jboss.org/browse/SECURITY-723
>             Project: PicketBox 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>    Affects Versions: Negotiation_2_1_3
>            Reporter: Tom Fonteyne
>            Assignee: Tom Fonteyne
>
> /jboss-negotiation-spnego/src/main/java/org/jboss/security/negotiation/spnego/encoding/TokenParser.java
> is lacking additional decoding of the Kerberos ticket.
> This patch backports the missing code from trunk
> Testing: the standard unit test for remote EJB calls over SPNEGO.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 10:44:01 2013
From: jira-events at lists.jboss.org (Tom Fonteyne (JIRA))
Date: Fri, 25 Oct 2013 10:44:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-763) Upgrade negotiation to
	2.1.4
In-Reply-To: <JIRA.12508816.1382712141936@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508816.1382712141936@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508816.1382712141936.18230.1382712241942@jira02.app.mwc.hst.phx2.redhat.com>

Tom Fonteyne created SECURITY-763:
-------------------------------------

             Summary: Upgrade negotiation to 2.1.4
                 Key: SECURITY-763
                 URL: https://issues.jboss.org/browse/SECURITY-763
             Project: PicketBox 
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Negotiation
    Affects Versions: Negotiation_2_1_3
            Reporter: Tom Fonteyne
            Assignee: Tom Fonteyne


/jboss-negotiation-spnego/src/main/java/org/jboss/security/negotiation/spnego/encoding/TokenParser.java

is lacking additional decoding of the Kerberos ticket.

This patch backports the missing code from trunk

Testing: the standard unit test for remote EJB calls over SPNEGO.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 13:04:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 25 Oct 2013 13:04:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1852) Populate the Subject with the
 required prinicpals for rbac/audit logging earlier
In-Reply-To: <JIRA.12498266.1375974256000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498266.1375974256000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498266.1375974256000.18554.1382720642269@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825093#comment-12825093 ] 

RH Bugzilla Integration commented on WFLY-1852:
-----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> changed the Status of [bug 1022993|https://bugzilla.redhat.com/show_bug.cgi?id=1022993] from ASSIGNED to POST
                
> Populate the Subject with the required prinicpals for rbac/audit logging earlier
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-1852
>                 URL: https://issues.jboss.org/browse/WFLY-1852
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: Kabir Khan
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> At the moment these are added in a number of places, see TODO comments with this JIRA id.
> I also commented your concern a few lines down for https://github.com/wildfly/wildfly/pull/4889#commitcomment-3808535: "Do we need to use the Remoting version of this Principal - not sure if a new Principal may be better that is used both for web and for Remoting."

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 13:04:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 25 Oct 2013 13:04:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2337) Eliminate additional round
 trip exchange of Subject from host controller to app server or slave host
 controllers.
In-Reply-To: <JIRA.12508207.1382112747000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508207.1382112747000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508207.1382112747000.18557.1382720642423@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825094#comment-12825094 ] 

RH Bugzilla Integration commented on WFLY-2337:
-----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> changed the Status of [bug 1022993|https://bugzilla.redhat.com/show_bug.cgi?id=1022993] from ASSIGNED to POST
                
> Eliminate additional round trip exchange of Subject from host controller to app server or slave host controllers.
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2337
>                 URL: https://issues.jboss.org/browse/WFLY-2337
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 13:06:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 25 Oct 2013 13:06:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2044) Rework Subject propagation to
 avoid marshaling.
In-Reply-To: <JIRA.12500441.1378828999000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500441.1378828999000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500441.1378828999000.18564.1382720762193@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825098#comment-12825098 ] 

RH Bugzilla Integration commented on WFLY-2044:
-----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> changed the Status of [bug 1022993|https://bugzilla.redhat.com/show_bug.cgi?id=1022993] from ASSIGNED to POST
                
> Rework Subject propagation to avoid marshaling.
> -----------------------------------------------
>
>                 Key: WFLY-2044
>                 URL: https://issues.jboss.org/browse/WFLY-2044
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Rework Subject propagation to avoid marshalling - i.e. describe the contents of the Subject within the protocol and allow it to be reconstructed on the far side.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 14:21:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 25 Oct 2013 14:21:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2053) JSR-115 JACC 1.5 (also known
	as MREL 3)
In-Reply-To: <JIRA.12500625.1378997404000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500625.1378997404000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500625.1378997404000.18640.1382725262136@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2053:
-----------------------------------

    Priority: Critical  (was: Major)

    
> JSR-115 JACC 1.5 (also known as MREL 3)
> ---------------------------------------
>
>                 Key: WFLY-2053
>                 URL: https://issues.jboss.org/browse/WFLY-2053
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: David Lloyd
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.CR1
>
>
> Implement the changes in the third MREL of the JACC spec.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 14:52:02 2013
From: jira-events at lists.jboss.org (Aaron Ogburn (JIRA))
Date: Fri, 25 Oct 2013 14:52:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-284)
 PageContextImpl.doFindAttribute on 2.1 can improperly throw
 IllegalStateException
In-Reply-To: <JIRA.12508832.1382727090445@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508832.1382727090445@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508832.1382727090445.18651.1382727121998@jira02.app.mwc.hst.phx2.redhat.com>

Aaron Ogburn created JBWEB-284:
----------------------------------

             Summary: PageContextImpl.doFindAttribute on 2.1 can improperly throw IllegalStateException
                 Key: JBWEB-284
                 URL: https://issues.jboss.org/browse/JBWEB-284
             Project: JBoss Web
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: JBossWeb-2.1.13.GA
            Reporter: Aaron Ogburn
            Assignee: Remy Maucherat


This is already fixed upstream, but this is needed on 2.1 for EAP 5.

original tomcat bug:

https://issues.apache.org/bugzilla/show_bug.cgi?id=37929

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 14:56:01 2013
From: jira-events at lists.jboss.org (Aaron Ogburn (JIRA))
Date: Fri, 25 Oct 2013 14:56:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2336) Decreasing max-threads on a
 unbounded queuesless executor generates IllegalArgumentException
In-Reply-To: <JIRA.12508206.1382111218000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508206.1382111218000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508206.1382111218000.18656.1382727361870@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825117#comment-12825117 ] 

Aaron Ogburn commented on WFLY-2336:
------------------------------------

Merged now upstream so this can be closed.
                
> Decreasing max-threads on a unbounded queuesless executor generates IllegalArgumentException
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2336
>                 URL: https://issues.jboss.org/browse/WFLY-2336
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Aaron Ogburn
>            Priority: Minor
>
> Create an unbounded queueless executor
> <unbounded-queue-thread-pool name="uq-thread-pool">
> <max-threads count="350"/>
> <keepalive-time time="5" unit="minutes"/>
> </unbounded-queue-thread-pool>
> Modifying max-threads fails:
> /subsystem=threads/unbounded-queue-thread-pool=uq-thread-pool:write-attribute(name=max-threads,value=300)
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014749: Operation handler failed: null",
>     "rolled-back" => true
> }
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) JBAS014612: Operation ("write-attribute") failed - address: ([
>     ("subsystem" => "threads"),
>     ("unbounded-queue-thread-pool" => "uq-thread-pool")
> ]): java.lang.IllegalArgumentException
> 	at java.util.concurrent.ThreadPoolExecutor.setMaximumPoolSize(ThreadPoolExecutor.java:1620) [rt.jar:1.7.0]
> 	at org.jboss.threads.JBossThreadPoolExecutor.setMaxThreads(JBossThreadPoolExecutor.java:95) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> 	at org.jboss.as.threads.ManagedJBossThreadPoolExecutorService.setMaxThreads(ManagedJBossThreadPoolExecutorService.java:86)
> 	at org.jboss.as.threads.UnboundedQueueThreadPoolService.setMaxThreads(UnboundedQueueThreadPoolService.java:91)
> The core pool size needs to be adjusted in line with the max pool size and in the right order to avoid that since max threads can't be less than core threads.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 14:58:01 2013
From: jira-events at lists.jboss.org (Aaron Ogburn (JIRA))
Date: Fri, 25 Oct 2013 14:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2336) Decreasing max-threads on a
 unbounded queuesless executor generates IllegalArgumentException
In-Reply-To: <JIRA.12508206.1382111218000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508206.1382111218000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508206.1382111218000.18658.1382727481898@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aaron Ogburn resolved WFLY-2336.
--------------------------------

    Fix Version/s: 8.0.0.CR1
       Resolution: Done

    
> Decreasing max-threads on a unbounded queuesless executor generates IllegalArgumentException
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2336
>                 URL: https://issues.jboss.org/browse/WFLY-2336
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Aaron Ogburn
>            Priority: Minor
>             Fix For: 8.0.0.CR1
>
>
> Create an unbounded queueless executor
> <unbounded-queue-thread-pool name="uq-thread-pool">
> <max-threads count="350"/>
> <keepalive-time time="5" unit="minutes"/>
> </unbounded-queue-thread-pool>
> Modifying max-threads fails:
> /subsystem=threads/unbounded-queue-thread-pool=uq-thread-pool:write-attribute(name=max-threads,value=300)
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014749: Operation handler failed: null",
>     "rolled-back" => true
> }
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) JBAS014612: Operation ("write-attribute") failed - address: ([
>     ("subsystem" => "threads"),
>     ("unbounded-queue-thread-pool" => "uq-thread-pool")
> ]): java.lang.IllegalArgumentException
> 	at java.util.concurrent.ThreadPoolExecutor.setMaximumPoolSize(ThreadPoolExecutor.java:1620) [rt.jar:1.7.0]
> 	at org.jboss.threads.JBossThreadPoolExecutor.setMaxThreads(JBossThreadPoolExecutor.java:95) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> 	at org.jboss.as.threads.ManagedJBossThreadPoolExecutorService.setMaxThreads(ManagedJBossThreadPoolExecutorService.java:86)
> 	at org.jboss.as.threads.UnboundedQueueThreadPoolService.setMaxThreads(UnboundedQueueThreadPoolService.java:91)
> The core pool size needs to be adjusted in line with the max pool size and in the right order to avoid that since max threads can't be less than core threads.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 15:02:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 25 Oct 2013 15:02:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2354) Webservice13 tck failures
 introduced by ejb3 and security change
In-Reply-To: <JIRA.12508431.1382433027000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508431.1382433027000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508431.1382433027000.18661.1382727722097@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825118#comment-12825118 ] 

RH Bugzilla Integration commented on WFLY-2354:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1021543|https://bugzilla.redhat.com/show_bug.cgi?id=1021543] from ASSIGNED to MODIFIED
                
> Webservice13 tck failures introduced by ejb3 and security change 
> -----------------------------------------------------------------
>
>                 Key: WFLY-2354
>                 URL: https://issues.jboss.org/browse/WFLY-2354
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>
> There 2 tck regression failures under webserivice13 directory in EAP 6.2.0.ER6. 
> IT turns out the change[2] introduced this two failures:
> [1]https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP6/view/TCK6-EAP6/job/tck6-eap6-webservices13/lastCompletedBuild/testReport/unknownTestSuite.0/
> [2][2]https://github.com/jbossas/jboss-eap/commit/72d5cd3f96540519a9747579dd3b85f0f564b64c
> EAP 6.2.0.ER6 sever error message:
> ------------------------------------------------------------------------------
> 18:32:00,338 ERROR [org.jboss.as.ejb3.invocation] (http-myserver.com/127.0.0.1:8080-1) JBAS014134: EJB Invocation failed on component WSEjbSingletonTest for method public java.lang.String com.sun.ts.tests.webservices13.ejb.annotations.WSEjbSingletonTest.HelloBean.bye(java.lang.String): javax.ejb.EJBException: java.lang.IllegalStateException: JBAS014485: EJB WSEjbSingletonTest is enabled for security but doesn't have a security domain set
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:189) [jboss-as-ejb3-7.3.0.Final-redhat-SNAPSHOT.jar:7.3.0.Final-redhat-SNAPSHOT]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 15:02:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 25 Oct 2013 15:02:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2373) patching resource does not
 get registered on slave hosts
In-Reply-To: <JIRA.12508684.1382615298000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508684.1382615298000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508684.1382615298000.18664.1382727722315@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825119#comment-12825119 ] 

RH Bugzilla Integration commented on WFLY-2373:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1022973|https://bugzilla.redhat.com/show_bug.cgi?id=1022973] from ASSIGNED to MODIFIED
                
> patching resource does not get registered on slave hosts
> --------------------------------------------------------
>
>                 Key: WFLY-2373
>                 URL: https://issues.jboss.org/browse/WFLY-2373
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Patching
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Emanuel Muckenhuber
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 15:32:01 2013
From: jira-events at lists.jboss.org (Aaron Ogburn (JIRA))
Date: Fri, 25 Oct 2013 15:32:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2336) Decreasing max-threads on a
 unbounded queueless executor generates IllegalArgumentException
In-Reply-To: <JIRA.12508206.1382111218000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508206.1382111218000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508206.1382111218000.18721.1382729521883@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aaron Ogburn updated WFLY-2336:
-------------------------------

    Summary: Decreasing max-threads on a unbounded queueless executor generates IllegalArgumentException  (was: Decreasing max-threads on a unbounded queuesless executor generates IllegalArgumentException)

    
> Decreasing max-threads on a unbounded queueless executor generates IllegalArgumentException
> -------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2336
>                 URL: https://issues.jboss.org/browse/WFLY-2336
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Aaron Ogburn
>            Priority: Minor
>             Fix For: 8.0.0.CR1
>
>
> Create an unbounded queueless executor
> <unbounded-queue-thread-pool name="uq-thread-pool">
> <max-threads count="350"/>
> <keepalive-time time="5" unit="minutes"/>
> </unbounded-queue-thread-pool>
> Modifying max-threads fails:
> /subsystem=threads/unbounded-queue-thread-pool=uq-thread-pool:write-attribute(name=max-threads,value=300)
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014749: Operation handler failed: null",
>     "rolled-back" => true
> }
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) JBAS014612: Operation ("write-attribute") failed - address: ([
>     ("subsystem" => "threads"),
>     ("unbounded-queue-thread-pool" => "uq-thread-pool")
> ]): java.lang.IllegalArgumentException
> 	at java.util.concurrent.ThreadPoolExecutor.setMaximumPoolSize(ThreadPoolExecutor.java:1620) [rt.jar:1.7.0]
> 	at org.jboss.threads.JBossThreadPoolExecutor.setMaxThreads(JBossThreadPoolExecutor.java:95) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> 	at org.jboss.as.threads.ManagedJBossThreadPoolExecutorService.setMaxThreads(ManagedJBossThreadPoolExecutorService.java:86)
> 	at org.jboss.as.threads.UnboundedQueueThreadPoolService.setMaxThreads(UnboundedQueueThreadPoolService.java:91)
> The core pool size needs to be adjusted in line with the max pool size and in the right order to avoid that since max threads can't be less than core threads.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 15:34:01 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 25 Oct 2013 15:34:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2336) Decreasing max-threads on a
 unbounded queueless executor generates IllegalArgumentException
In-Reply-To: <JIRA.12508206.1382111218000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508206.1382111218000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508206.1382111218000.18723.1382729641904@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825131#comment-12825131 ] 

RH Bugzilla Integration commented on WFLY-2336:
-----------------------------------------------

Aaron Ogburn <aogburn at redhat.com> made a comment on [bug 1021077|https://bugzilla.redhat.com/show_bug.cgi?id=1021077]

PR:

https://github.com/jbossas/jboss-eap/pull/636
                
> Decreasing max-threads on a unbounded queueless executor generates IllegalArgumentException
> -------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2336
>                 URL: https://issues.jboss.org/browse/WFLY-2336
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Aaron Ogburn
>            Priority: Minor
>             Fix For: 8.0.0.CR1
>
>
> Create an unbounded queueless executor
> <unbounded-queue-thread-pool name="uq-thread-pool">
> <max-threads count="350"/>
> <keepalive-time time="5" unit="minutes"/>
> </unbounded-queue-thread-pool>
> Modifying max-threads fails:
> /subsystem=threads/unbounded-queue-thread-pool=uq-thread-pool:write-attribute(name=max-threads,value=300)
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014749: Operation handler failed: null",
>     "rolled-back" => true
> }
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) JBAS014612: Operation ("write-attribute") failed - address: ([
>     ("subsystem" => "threads"),
>     ("unbounded-queue-thread-pool" => "uq-thread-pool")
> ]): java.lang.IllegalArgumentException
> 	at java.util.concurrent.ThreadPoolExecutor.setMaximumPoolSize(ThreadPoolExecutor.java:1620) [rt.jar:1.7.0]
> 	at org.jboss.threads.JBossThreadPoolExecutor.setMaxThreads(JBossThreadPoolExecutor.java:95) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> 	at org.jboss.as.threads.ManagedJBossThreadPoolExecutorService.setMaxThreads(ManagedJBossThreadPoolExecutorService.java:86)
> 	at org.jboss.as.threads.UnboundedQueueThreadPoolService.setMaxThreads(UnboundedQueueThreadPoolService.java:91)
> The core pool size needs to be adjusted in line with the max pool size and in the right order to avoid that since max threads can't be less than core threads.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 15:42:01 2013
From: jira-events at lists.jboss.org (Aaron Ogburn (JIRA))
Date: Fri, 25 Oct 2013 15:42:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-284)
 PageContextImpl.doFindAttribute on 2.1 can improperly throw
 IllegalStateException
In-Reply-To: <JIRA.12508832.1382727090000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508832.1382727090000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508832.1382727090000.18731.1382730121983@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBWEB-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825134#comment-12825134 ] 

Aaron Ogburn commented on JBWEB-284:
------------------------------------

r2292
                
> PageContextImpl.doFindAttribute on 2.1 can improperly throw IllegalStateException
> ---------------------------------------------------------------------------------
>
>                 Key: JBWEB-284
>                 URL: https://issues.jboss.org/browse/JBWEB-284
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossWeb-2.1.13.GA
>            Reporter: Aaron Ogburn
>            Assignee: Remy Maucherat
>
> This is already fixed upstream, but this is needed on 2.1 for EAP 5.
> original tomcat bug:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=37929

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 15:44:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 25 Oct 2013 15:44:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1056) Certificate to principal
	mapping
In-Reply-To: <JIRA.12453126.1322395905000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12453126.1322395905000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12453126.1322395905000.18740.1382730242021@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825135#comment-12825135 ] 

RH Bugzilla Integration commented on WFLY-1056:
-----------------------------------------------

Stefan Guilhen <sguilhen at redhat.com> made a comment on [bug 901309|https://bugzilla.redhat.com/show_bug.cgi?id=901309]

A property to allow configuration of the certificate mapper should have been added to the web subsystem since its inception. Adding it now is not trivial (there is no place to configure the WebRealm in the web subsystem). We could look into adding a system property to allow for the config of the mapper or just use the workaround Derek described above.

I'm setting devel_ack to "-". There is a workaround available and I think we need more time to come up with a proper solution. If anybody thinks that adding a system property is a good idea we can probably code something next week.
                
> Certificate to principal mapping
> --------------------------------
>
>                 Key: WFLY-1056
>                 URL: https://issues.jboss.org/browse/WFLY-1056
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: Yves Peter
>            Assignee: Anil Saldhana
>
> In JBoss 7 it is no longer possible to configure how a certificate is mapped to a principal using client-cert authentication. The dynamic code was removed in JBoss 7 in the JBossWebRealm and is now hard coded to use the SubjectDNMapping:
> http://grepcode.com/file/repository.jboss.org/nexus/content/repositories/releases/org.jboss.jbossas/jboss-as-tomcat/6.1.0.Final/org/jboss/web/tomcat/security/JBossWebRealm.java
> http://grepcode.com/file/repository.jboss.org/nexus/content/repositories/releases/org.jboss.as/jboss-as-web/7.0.1.Final/org/jboss/as/web/security/JBossWebRealm.java
> Also the JBossWebRealm does only consider role- but no principal-mapping modules.
> We use this to authenticate users against an ldap server where the dn of the user doesn't match the dn in the ldap server. Also it's useful for display purpose in an application.
> An example and some further information is in the linked user form thread.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 15:55:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 25 Oct 2013 15:55:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-759)
 JASPIServerAuthenticationManager.isValid method should log configuration
 problems at WARN or ERROR level
In-Reply-To: <JIRA.12508529.1382490341000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508529.1382490341000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508529.1382490341000.18761.1382730903469@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/SECURITY-759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825140#comment-12825140 ] 

RH Bugzilla Integration commented on SECURITY-759:
--------------------------------------------------

Stefan Guilhen <sguilhen at redhat.com> changed the Status of [bug 901074|https://bugzilla.redhat.com/show_bug.cgi?id=901074] from NEW to MODIFIED
                
> JASPIServerAuthenticationManager.isValid method should log configuration problems at WARN or ERROR level
> --------------------------------------------------------------------------------------------------------
>
>                 Key: SECURITY-759
>                 URL: https://issues.jboss.org/browse/SECURITY-759
>             Project: PicketBox 
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: PicketBox_4_0_20.Beta1
>            Reporter: Stefan Guilhen
>            Assignee: Stefan Guilhen
>             Fix For: 2.0.3.Beta2
>
>
> As reported by Josef Cacek:
> All fatal exception are swallowed in JASPIServerAuthenticationManager.isValid() method.
> {code}
> // PicketBox 4.0.9 used in EAP 6.0.0 - TRACE level
>       catch(AuthException ae)
>       {
>          if(trace)
>             log.trace("AuthException:",ae);
>       }
> // PicketBox 4.0.14 - DEBUG level
>       catch(AuthException ae)
>       {
>           PicketBoxLogger.LOGGER.debugIgnoredException(ae);
>       }
> {code}
> It includes configuration errors, which should absolutely be visible on ERROR log level or another relevant level.
> We need to make sure to use ERROR log if the user-defined module cannot be found for instance.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 15:57:01 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 25 Oct 2013 15:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-751) Misleading stacktrace on
 server startup with malformed security-domain
In-Reply-To: <JIRA.12499692.1377872122000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499692.1377872122000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499692.1377872122000.18764.1382731021954@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/SECURITY-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825141#comment-12825141 ] 

RH Bugzilla Integration commented on SECURITY-751:
--------------------------------------------------

Stefan Guilhen <sguilhen at redhat.com> changed the Status of [bug 979117|https://bugzilla.redhat.com/show_bug.cgi?id=979117] from POST to MODIFIED
                
> Misleading stacktrace on server startup with malformed security-domain
> ----------------------------------------------------------------------
>
>                 Key: SECURITY-751
>                 URL: https://issues.jboss.org/browse/SECURITY-751
>             Project: PicketBox 
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: PicketBox
>            Reporter: Stefan Guilhen
>            Assignee: Stefan Guilhen
>             Fix For: PicketBox_4_0_19.Final
>
>
> Description of problem:
> Misleading stack trace upon server startup. Occurs when adding a <security-domain> with a malformed <jsse> element. 
> Version-Release number of selected component (if applicable):
> Picketbox version: 4.0.17.Final-redhat-1
> How reproducible:
> Always
> Steps to Reproduce:
> 1. Start the server in standalone mode.
> ./standalone.sh 
> 2. Run the following jboss-cli.sh commands:
> /subsystem=security/security-domain=test:add()
> /subsystem=security/security-domain=test1/jsse=classic:add(keystore={password=123456})
> :reload
> 3. See the stacktrace: 
> 11:49:45,138 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.security.security-domain.test: org.jboss.msc.service.StartException in service jboss.security.security-domain.test: JBAS013308: Unable to start the SecurityDomainService service
> 	at org.jboss.as.security.service.SecurityDomainService.start(SecurityDomainService.java:107)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: java.lang.RuntimeException: PBOX000117: Invalid KeyStore type: JKS
> 	at org.jboss.security.JBossJSSESecurityDomain.loadKeyAndTrustStore(JBossJSSESecurityDomain.java:469)
> 	at org.jboss.security.JBossJSSESecurityDomain.reloadKeyAndTrustStore(JBossJSSESecurityDomain.java:335)
> 	at org.jboss.as.security.service.SecurityDomainService.start(SecurityDomainService.java:104)
> 	... 5 more
> Actual results:
> Stacktrace says that the keystore type "JKS" is not supported. This is the default keystore type, so this is not true. 
> Expected results:
> I believe that the stacktrace should report that the keystore-url attribute is missing, since adding only that attribute causes the stacktrace to disappear.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 15:59:01 2013
From: jira-events at lists.jboss.org (Derek Horton (JIRA))
Date: Fri, 25 Oct 2013 15:59:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-762) Bug in
 JBossJSSESecurityDomain.java - attempting to use wrong provider
In-Reply-To: <JIRA.12508715.1382627586000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508715.1382627586000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508715.1382627586000.18769.1382731141886@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/SECURITY-762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Derek Horton resolved SECURITY-762.
-----------------------------------

    Resolution: Done


Fixed in picketbox trunk:
https://svn.jboss.org/repos/picketbox/trunk

                
> Bug in JBossJSSESecurityDomain.java - attempting to use wrong provider
> ----------------------------------------------------------------------
>
>                 Key: SECURITY-762
>                 URL: https://issues.jboss.org/browse/SECURITY-762
>             Project: PicketBox 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: PicketBox_4_0_19.Final
>            Reporter: Derek Horton
>            Assignee: Anil Saldhana
>
> There is a bug in JBossJSSESecurityDomain.java where it attempts to use the keystore/truststore provider to get instances of the trust manager.
> The code reads:
>          if (trustManagerFactoryProvider != null)
>             trustManagerFactory = TrustManagerFactory.getInstance(algorithm, trustStoreProvider);
>          else
>             trustManagerFactory = TrustManagerFactory.getInstance(algorithm);
> I think it should read:
>          if (trustManagerFactoryProvider != null)
>             trustManagerFactory = TrustManagerFactory.getInstance(algorithm, trustManagerFactoryProvider);
>          else
>             trustManagerFactory = TrustManagerFactory.getInstance(algorithm);

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 16:01:02 2013
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Fri, 25 Oct 2013 16:01:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2296) Patched state is missing the
 updated resulting version
In-Reply-To: <JIRA.12502946.1381752036000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502946.1381752036000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502946.1381752036000.18773.1382731262569@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emanuel Muckenhuber resolved WFLY-2296.
---------------------------------------

    Resolution: Done

    
> Patched state is missing the updated resulting version
> ------------------------------------------------------
>
>                 Key: WFLY-2296
>                 URL: https://issues.jboss.org/browse/WFLY-2296
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Patching
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Emanuel Muckenhuber
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 16:01:02 2013
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Fri, 25 Oct 2013 16:01:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2373) patching resource does not
 get registered on slave hosts
In-Reply-To: <JIRA.12508684.1382615298000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508684.1382615298000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508684.1382615298000.18776.1382731262921@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emanuel Muckenhuber resolved WFLY-2373.
---------------------------------------

    Resolution: Done

    
> patching resource does not get registered on slave hosts
> --------------------------------------------------------
>
>                 Key: WFLY-2373
>                 URL: https://issues.jboss.org/browse/WFLY-2373
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Patching
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Emanuel Muckenhuber
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 17:02:01 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 25 Oct 2013 17:02:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2336) Decreasing max-threads on a
 unbounded queueless executor generates IllegalArgumentException
In-Reply-To: <JIRA.12508206.1382111218000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508206.1382111218000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508206.1382111218000.18836.1382734921880@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825149#comment-12825149 ] 

RH Bugzilla Integration commented on WFLY-2336:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1021077|https://bugzilla.redhat.com/show_bug.cgi?id=1021077] from NEW to POST
                
> Decreasing max-threads on a unbounded queueless executor generates IllegalArgumentException
> -------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2336
>                 URL: https://issues.jboss.org/browse/WFLY-2336
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Aaron Ogburn
>            Priority: Minor
>             Fix For: 8.0.0.CR1
>
>
> Create an unbounded queueless executor
> <unbounded-queue-thread-pool name="uq-thread-pool">
> <max-threads count="350"/>
> <keepalive-time time="5" unit="minutes"/>
> </unbounded-queue-thread-pool>
> Modifying max-threads fails:
> /subsystem=threads/unbounded-queue-thread-pool=uq-thread-pool:write-attribute(name=max-threads,value=300)
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014749: Operation handler failed: null",
>     "rolled-back" => true
> }
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) JBAS014612: Operation ("write-attribute") failed - address: ([
>     ("subsystem" => "threads"),
>     ("unbounded-queue-thread-pool" => "uq-thread-pool")
> ]): java.lang.IllegalArgumentException
> 	at java.util.concurrent.ThreadPoolExecutor.setMaximumPoolSize(ThreadPoolExecutor.java:1620) [rt.jar:1.7.0]
> 	at org.jboss.threads.JBossThreadPoolExecutor.setMaxThreads(JBossThreadPoolExecutor.java:95) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> 	at org.jboss.as.threads.ManagedJBossThreadPoolExecutorService.setMaxThreads(ManagedJBossThreadPoolExecutorService.java:86)
> 	at org.jboss.as.threads.UnboundedQueueThreadPoolService.setMaxThreads(UnboundedQueueThreadPoolService.java:91)
> The core pool size needs to be adjusted in line with the max pool size and in the right order to avoid that since max threads can't be less than core threads.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 17:54:01 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Fri, 25 Oct 2013 17:54:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2320) EJB should not be remotely
 accessible until all of its dependencies have been started
In-Reply-To: <JIRA.12503266.1381935962000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503266.1381935962000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503266.1381935962000.18859.1382738041942@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-2320.
----------------------------------

    Fix Version/s: 8.0.0.CR1
       Resolution: Done

    
> EJB should not be remotely accessible until all of its dependencies have been started
> -------------------------------------------------------------------------------------
>
>                 Key: WFLY-2320
>                 URL: https://issues.jboss.org/browse/WFLY-2320
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Brad Maxwell
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.CR1
>
>
> If an EJB injects or depends on a resource such as an @Singleton which has not been started, the EJB's remote interface java:jboss/exported/* is already bound and this allows remote EJB clients to try to invoke it.  This causes the EJB clients to hang because the EJB will not be started until its dependencies have been started.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 18:12:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 25 Oct 2013 18:12:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2320) EJB should not be remotely
 accessible until all of its dependencies have been started
In-Reply-To: <JIRA.12503266.1381935962000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503266.1381935962000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503266.1381935962000.18873.1382739122031@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825161#comment-12825161 ] 

RH Bugzilla Integration commented on WFLY-2320:
-----------------------------------------------

Brad Maxwell <bmaxwell at redhat.com> changed the Status of [bug 1019894|https://bugzilla.redhat.com/show_bug.cgi?id=1019894] from NEW to MODIFIED
                
> EJB should not be remotely accessible until all of its dependencies have been started
> -------------------------------------------------------------------------------------
>
>                 Key: WFLY-2320
>                 URL: https://issues.jboss.org/browse/WFLY-2320
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Brad Maxwell
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.CR1
>
>
> If an EJB injects or depends on a resource such as an @Singleton which has not been started, the EJB's remote interface java:jboss/exported/* is already bound and this allows remote EJB clients to try to invoke it.  This causes the EJB clients to hang because the EJB will not be started until its dependencies have been started.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 18:19:01 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 25 Oct 2013 18:19:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2383) resource-adapter id attribute
 has to match ra name otherwise MDB is not deployed
In-Reply-To: <JIRA.12508785.1382695105000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508785.1382695105000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508785.1382695105000.18879.1382739541888@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825163#comment-12825163 ] 

RH Bugzilla Integration commented on WFLY-2383:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1012044|https://bugzilla.redhat.com/show_bug.cgi?id=1012044] from ASSIGNED to MODIFIED
                
> resource-adapter id attribute has to match ra name otherwise MDB is not deployed
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-2383
>                 URL: https://issues.jboss.org/browse/WFLY-2383
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Stefano Maestri
>
> The resource-adapter id has to have the same name as the ra archive has. Otherwise the the MDB is not deployed. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 18:21:01 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 25 Oct 2013 18:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2320) EJB should not be remotely
 accessible until all of its dependencies have been started
In-Reply-To: <JIRA.12503266.1381935962000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503266.1381935962000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503266.1381935962000.18885.1382739661922@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2320:
------------------------------------------

    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1019894, https://bugzilla.redhat.com/show_bug.cgi?id=1023602  (was: https://bugzilla.redhat.com/show_bug.cgi?id=1019894)

    
> EJB should not be remotely accessible until all of its dependencies have been started
> -------------------------------------------------------------------------------------
>
>                 Key: WFLY-2320
>                 URL: https://issues.jboss.org/browse/WFLY-2320
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Brad Maxwell
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.CR1
>
>
> If an EJB injects or depends on a resource such as an @Singleton which has not been started, the EJB's remote interface java:jboss/exported/* is already bound and this allows remote EJB clients to try to invoke it.  This causes the EJB clients to hang because the EJB will not be started until its dependencies have been started.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Oct 25 18:23:01 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 25 Oct 2013 18:23:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2320) EJB should not be remotely
 accessible until all of its dependencies have been started
In-Reply-To: <JIRA.12503266.1381935962000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503266.1381935962000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503266.1381935962000.18892.1382739781937@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825165#comment-12825165 ] 

RH Bugzilla Integration commented on WFLY-2320:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1019894|https://bugzilla.redhat.com/show_bug.cgi?id=1019894] from MODIFIED to POST
                
> EJB should not be remotely accessible until all of its dependencies have been started
> -------------------------------------------------------------------------------------
>
>                 Key: WFLY-2320
>                 URL: https://issues.jboss.org/browse/WFLY-2320
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Brad Maxwell
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.CR1
>
>
> If an EJB injects or depends on a resource such as an @Singleton which has not been started, the EJB's remote interface java:jboss/exported/* is already bound and this allows remote EJB clients to try to invoke it.  This causes the EJB clients to hang because the EJB will not be started until its dependencies have been started.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 26 00:54:02 2013
From: jira-events at lists.jboss.org (Denis Kostousov (JIRA))
Date: Sat, 26 Oct 2013 00:54:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2341) WildFly-8.0.0.Beta1 throws an
 exception during persistence unit starting on java 1.8.0-ea-b111
In-Reply-To: <JIRA.12508227.1382181208000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508227.1382181208000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508227.1382181208000.18935.1382763242376@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825177#comment-12825177 ] 

Denis Kostousov commented on WFLY-2341:
---------------------------------------

I try b113. Nothing changed. 
                
> WildFly-8.0.0.Beta1 throws an exception during persistence unit starting on java 1.8.0-ea-b111
> ----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2341
>                 URL: https://issues.jboss.org/browse/WFLY-2341
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Beta1
>         Environment: % java -version
> java version "1.8.0-ea"
> Java(TM) SE Runtime Environment (build 1.8.0-ea-b111)
> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b53, mixed mode)
> % uname -a
> Linux irtysh.kostousov.net 3.11.1-200.fc19.x86_64 #1 SMP Sat Sep 14 15:04:51 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
>            Reporter: Denis Kostousov
>            Assignee: Scott Marlow
>            Priority: Critical
>         Attachments: hibernate.HEAD.build.log
>
>
> An exception occurs during application deploying on Wildfly 8.0.0.Beta1 after jdk was changed from 1.8.0-ea-b109 to 1.8.0-ea-b111. On 1.8.0-ea-b109 same code works fine.
> {code}
> 2013-10-19 16:52:49,975 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 52) MSC000001: Failed to start service jboss.persistenceunit."acquiring-gate-ear-0.5-SNAPSHOT.ear/server-0.5-SNAPSHOT.war#AGDirectory": org.jboss.msc.service.StartException in service jboss.persistenceunit."acquiring-gate-ear-0.5-SNAPSHOT.ear/server-0.5-SNAPSHOT.war#AGDirectory": java.lang.IllegalAccessError: tried to access method java.lang.Object.clone()Ljava/lang/Object; from class org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:169) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0-ea]
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:463) [wildfly-security-manager-1.0.0.Beta3.jar:1.0.0.Beta3]
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:178) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0-ea]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0-ea]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.8.0-ea]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: java.lang.IllegalAccessError: tried to access method java.lang.Object.clone()Ljava/lang/Object; from class org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator
> 	at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.cloneAndSetupRevisionInfoRelationMapping(AuditMetadataGenerator.java:140)
> 	at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.addRevisionInfoRelation(AuditMetadataGenerator.java:152)
> 	at org.hibernate.envers.configuration.internal.metadata.IdMetadataGenerator.addId(IdMetadataGenerator.java:210)
> 	at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.generateFirstPass(AuditMetadataGenerator.java:561)
> 	at org.hibernate.envers.configuration.internal.EntitiesConfigurator.configure(EntitiesConfigurator.java:110)
> 	at org.hibernate.envers.configuration.spi.AuditConfiguration.<init>(AuditConfiguration.java:130)
> 	at org.hibernate.envers.configuration.spi.AuditConfiguration.getFor(AuditConfiguration.java:180)
> 	at org.hibernate.envers.event.spi.EnversIntegrator.integrate(EnversIntegrator.java:76)
> 	at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:310)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1837)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:854)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:847)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:396)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:846)
> 	at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:151) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	... 8 more
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 26 03:27:02 2013
From: jira-events at lists.jboss.org (Christian Kaltepoth (JIRA))
Date: Sat, 26 Oct 2013 03:27:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2388) Calling getRequestURI()
 returns wrong address for root URL of webapp
In-Reply-To: <JIRA.12508840.1382772318573@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508840.1382772318573@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508840.1382772318573.18940.1382772422003@jira02.app.mwc.hst.phx2.redhat.com>

Christian Kaltepoth created WFLY-2388:
-----------------------------------------

             Summary: Calling getRequestURI() returns wrong address for root URL of webapp
                 Key: WFLY-2388
                 URL: https://issues.jboss.org/browse/WFLY-2388
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Web (Undertow)
    Affects Versions: 8.0.0.Beta1
            Reporter: Christian Kaltepoth
            Assignee: Stuart Douglas
         Attachments: start-page.zip

Reading {{HttpServletRequest.getRequestURI()}} from a servlet filter gives incorrect result if requesting the root URL of a webapp:

||Requested URL||getRequestURI()||Correct?||
|{{http://localhost:8080/myapp/foobar}}|{{/myapp/foobar}}|OK|
|{{http://localhost:8080/myapp/}}|{{/myapp/index.jsp}}|Incorrect! Should be {{/myapp/}}|

It seems like the filter sees the name of the welcome page instead of the incoming request URL. That's not correct.

I tested this with other containers like Tomcat, AS7 and Glassfish and all of them show the incoming request URL instead.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 26 03:27:02 2013
From: jira-events at lists.jboss.org (Christian Kaltepoth (JIRA))
Date: Sat, 26 Oct 2013 03:27:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2388) Calling getRequestURI()
 returns wrong address for root URL of webapp
In-Reply-To: <JIRA.12508840.1382772318000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508840.1382772318000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508840.1382772318000.18943.1382772422156@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christian Kaltepoth updated WFLY-2388:
--------------------------------------

    Attachment: start-page.zip


Sample app to reproduce the bug
                
> Calling getRequestURI() returns wrong address for root URL of webapp
> --------------------------------------------------------------------
>
>                 Key: WFLY-2388
>                 URL: https://issues.jboss.org/browse/WFLY-2388
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Christian Kaltepoth
>            Assignee: Stuart Douglas
>         Attachments: start-page.zip
>
>
> Reading {{HttpServletRequest.getRequestURI()}} from a servlet filter gives incorrect result if requesting the root URL of a webapp:
> ||Requested URL||getRequestURI()||Correct?||
> |{{http://localhost:8080/myapp/foobar}}|{{/myapp/foobar}}|OK|
> |{{http://localhost:8080/myapp/}}|{{/myapp/index.jsp}}|Incorrect! Should be {{/myapp/}}|
> It seems like the filter sees the name of the welcome page instead of the incoming request URL. That's not correct.
> I tested this with other containers like Tomcat, AS7 and Glassfish and all of them show the incoming request URL instead.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 26 08:18:01 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Sat, 26 Oct 2013 08:18:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2389) configuration/*.properties
 files use AS 7 in comments
In-Reply-To: <JIRA.12508842.1382789826740@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508842.1382789826740@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508842.1382789826740.18962.1382789881861@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-2389:
--------------------------------------

             Summary: configuration/*.properties files use AS 7 in comments
                 Key: WFLY-2389
                 URL: https://issues.jboss.org/browse/WFLY-2389
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Server
    Affects Versions: 8.0.0.Beta1
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
            Priority: Minor
             Fix For: 8.0.0.CR1


The comments in the .properties files used for the property-file based security realms use "AS 7" in their comments. Change to WildFly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 26 08:59:01 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Sat, 26 Oct 2013 08:59:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1723) Corrupted input stream on
	STATE exchange
In-Reply-To: <JIRA.12508721.1382628956000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508721.1382628956000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508721.1382628956000.18980.1382792341963@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1723:
---------------------------

    Fix Version/s: 3.5

    
> Corrupted input stream on STATE exchange
> ----------------------------------------
>
>                 Key: JGRP-1723
>                 URL: https://issues.jboss.org/browse/JGRP-1723
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.3.4, 3.4
>         Environment: java7u25
>            Reporter: Mathieu Bernatet
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>         Attachments: corruptedStreamOnStateExchange.zip
>
>
> Using the pbcast.STATE state transfer protocol with a high volume of data, the receiver member on setState seem to get a corrupted input stream.
> I was able to reproduce this issue with a simple project in which the data get corrupted from the 8192th byte. So it may be related to frag size with default value of 8192. We get this bug either with FRAG or FRAG2.
> Related discussion on the mailing list could be found here : http://jgroups.1086181.n5.nabble.com/Corrupted-input-stream-on-STATE-exchange-td9938.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 26 09:03:01 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Sat, 26 Oct 2013 09:03:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2389) configuration/*.properties
 files use AS 7 in comments
In-Reply-To: <JIRA.12508842.1382789826000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508842.1382789826000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508842.1382789826000.18982.1382792581898@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry resolved WFLY-2389.
------------------------------------

    Resolution: Done

    
> configuration/*.properties files use AS 7 in comments
> -----------------------------------------------------
>
>                 Key: WFLY-2389
>                 URL: https://issues.jboss.org/browse/WFLY-2389
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Minor
>             Fix For: 8.0.0.CR1
>
>
> The comments in the .properties files used for the property-file based security realms use "AS 7" in their comments. Change to WildFly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 26 14:02:01 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Sat, 26 Oct 2013 14:02:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-158) Constant fields that are not
	final
In-Reply-To: <JIRA.12487846.1364043277000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12487846.1364043277000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487846.1364043277000.18997.1382810521907@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825183#comment-12825183 ] 

RH Bugzilla Integration commented on WFLY-158:
----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 926050|https://bugzilla.redhat.com/show_bug.cgi?id=926050] from ASSIGNED to POST
                
> Constant fields that are not final
> ----------------------------------
>
>                 Key: WFLY-158
>                 URL: https://issues.jboss.org/browse/WFLY-158
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Alpha1
>
>         Attachments: non-final-fields.txt
>
>
> Analysis by Stephan Mueller shows that the AS codebase includes a significant number of public constant fields that are missing the "final" keyword, which could allow incorrect or nefarious code to change them. This task is to fix these.
> As part of the work for a few cases I'll reduce the field visibility.
> I'll attach file listing the cases.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 26 14:06:01 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Sat, 26 Oct 2013 14:06:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2390)
 SimpleOperationDefinitionBuilder.withFlags discards existing flags
In-Reply-To: <JIRA.12508848.1382810715850@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508848.1382810715850@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508848.1382810715850.19001.1382810761854@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-2390:
--------------------------------------

             Summary: SimpleOperationDefinitionBuilder.withFlags discards existing flags
                 Key: WFLY-2390
                 URL: https://issues.jboss.org/browse/WFLY-2390
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Domain Management
    Affects Versions: 8.0.0.Beta1
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: 8.0.0.CR1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 26 14:14:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Sat, 26 Oct 2013 14:14:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2337) Eliminate additional round
 trip exchange of Subject from host controller to app server or slave host
 controllers.
In-Reply-To: <JIRA.12508207.1382112747000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508207.1382112747000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508207.1382112747000.19009.1382811242052@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825187#comment-12825187 ] 

RH Bugzilla Integration commented on WFLY-2337:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1022993|https://bugzilla.redhat.com/show_bug.cgi?id=1022993] from POST to MODIFIED
                
> Eliminate additional round trip exchange of Subject from host controller to app server or slave host controllers.
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2337
>                 URL: https://issues.jboss.org/browse/WFLY-2337
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 26 14:14:01 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Sat, 26 Oct 2013 14:14:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2385) Resource adapter recovery
 doesn't allow fallback to security credentials
In-Reply-To: <JIRA.12508796.1382702010000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508796.1382702010000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508796.1382702010000.19006.1382811241984@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825186#comment-12825186 ] 

RH Bugzilla Integration commented on WFLY-2385:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1023446|https://bugzilla.redhat.com/show_bug.cgi?id=1023446] from POST to MODIFIED
                
>  Resource adapter recovery doesn't allow fallback to security credentials
> -------------------------------------------------------------------------
>
>                 Key: WFLY-2385
>                 URL: https://issues.jboss.org/browse/WFLY-2385
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Stefano Maestri
>            Assignee: Stefano Maestri
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 26 14:14:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Sat, 26 Oct 2013 14:14:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1852) Populate the Subject with the
 required prinicpals for rbac/audit logging earlier
In-Reply-To: <JIRA.12498266.1375974256000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498266.1375974256000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498266.1375974256000.19016.1382811242255@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825189#comment-12825189 ] 

RH Bugzilla Integration commented on WFLY-1852:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1022993|https://bugzilla.redhat.com/show_bug.cgi?id=1022993] from POST to MODIFIED
                
> Populate the Subject with the required prinicpals for rbac/audit logging earlier
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-1852
>                 URL: https://issues.jboss.org/browse/WFLY-1852
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: Kabir Khan
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> At the moment these are added in a number of places, see TODO comments with this JIRA id.
> I also commented your concern a few lines down for https://github.com/wildfly/wildfly/pull/4889#commitcomment-3808535: "Do we need to use the Remoting version of this Principal - not sure if a new Principal may be better that is used both for web and for Remoting."

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 26 14:14:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Sat, 26 Oct 2013 14:14:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2317) Trying to remove a server
 group as a server-group-scoped role leaks information
In-Reply-To: <JIRA.12503235.1381924172000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503235.1381924172000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503235.1381924172000.19019.1382811242335@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825190#comment-12825190 ] 

RH Bugzilla Integration commented on WFLY-2317:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1019784|https://bugzilla.redhat.com/show_bug.cgi?id=1019784] from POST to MODIFIED
                
> Trying to remove a server group as a server-group-scoped role leaks information
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-2317
>                 URL: https://issues.jboss.org/browse/WFLY-2317
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Brian Stansberry
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.CR1
>
>
> When writing a small test case for WFLY-2190, I stumbled upon a problem: trying to remove an existing server group by a server-group-scoped user that does NOT have permissions to that server group leaks information. On a freshly built WildFly with added {{admin}} user into {{domain/configuration/mgmt-users.properties}}, it can be reproduced like this:
> {code}
> [1] ./bin/domain.sh
> [2] ./bin/jboss-cli.sh -c
>     /core-service=management/access=authorization/server-group-scoped-role=NewRole:add(base-role=administrator, server-groups=[main-server-group])
>     /core-service=management/access=authorization/role-mapping=NewRole:add
>     /core-service=management/access=authorization/role-mapping=NewRole/include=user-admin:add(name=admin, type=user)
>     /core-service=management/access=authorization:write-attribute(name=provider, value=rbac)
>     exit
> [1] ^C
>     ./bin/domain.sh
> [2] ./bin/jboss-cli.sh -c --user=admin --password=XXX
>     /server-group=other-server-group:read-resource
>     /server-group=other-server-group:remove
> {code}
> What does that mean? The {{NewRole}} is scoped to the {{main-server-group}} server group and can't see {{other-server-group}}. When doing {{/server-group=other-server-group:read-resource}}, this is correctly enforced and the output looks like this:
> {code}
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014807: Management resource '[(\"server-group\" => \"other-server-group\")]' not found",
>     "rolled-back" => true
> }
> {code}
> However, trying to do {{/server-group=other-server-group:remove}}, which is only a different operation _on the same resource_, I get a different error message:
> {code}
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "JBAS013456: Unauthorized to execute operation 'remove' for resource '[(\"server-group\" => \"other-server-group\")]' -- \"JBAS013475: Permission denied\""},
>     "rolled-back" => true
> }
> {code}
> I expect the error message to be completely the same as in previous case, not leaking any information that the {{other-server-group}} actually exists.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 26 14:14:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Sat, 26 Oct 2013 14:14:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2044) Rework Subject propagation to
 avoid marshaling.
In-Reply-To: <JIRA.12500441.1378828999000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500441.1378828999000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500441.1378828999000.19012.1382811242123@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825188#comment-12825188 ] 

RH Bugzilla Integration commented on WFLY-2044:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1022993|https://bugzilla.redhat.com/show_bug.cgi?id=1022993] from POST to MODIFIED
                
> Rework Subject propagation to avoid marshaling.
> -----------------------------------------------
>
>                 Key: WFLY-2044
>                 URL: https://issues.jboss.org/browse/WFLY-2044
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Rework Subject propagation to avoid marshalling - i.e. describe the contents of the Subject within the protocol and allow it to be reconstructed on the far side.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 26 15:07:01 2013
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Sat, 26 Oct 2013 15:07:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2331) Update JSF based on Mojarra
	2.2.4 final
In-Reply-To: <JIRA.12508130.1382039926000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508130.1382039926000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508130.1382039926000.19024.1382814421889@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stan Silvert resolved WFLY-2331.
--------------------------------

    Resolution: Done

    
> Update JSF based on Mojarra 2.2.4 final
> ---------------------------------------
>
>                 Key: WFLY-2331
>                 URL: https://issues.jboss.org/browse/WFLY-2331
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: JSF
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Stan Silvert
>            Assignee: Stan Silvert
>             Fix For: 8.0.0.CR1
>
>
> Update JSF based on Mojarra 2.2.4 final.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 26 18:08:01 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Sat, 26 Oct 2013 18:08:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-280) lock-on-active broken
In-Reply-To: <JIRA.12501976.1380702873000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501976.1380702873000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501976.1380702873000.19042.1382825281911@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825199#comment-12825199 ] 

Davide Sottara commented on DROOLS-280:
---------------------------------------

The workaround is to mark both rules as @Eager(true)
                
> lock-on-active broken
> ---------------------
>
>                 Key: DROOLS-280
>                 URL: https://issues.jboss.org/browse/DROOLS-280
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>            Reporter: Anthony Patricio
>
> Hi,
> lock-on-active is not working as expected.
> I seems to work as activation-group.
> Works fine with 5.x
> Fails with 6.0.0 CR3 and CR4
> Fact:
> {code:java}
> public class Poc implements Serializable {
> 	private static final long serialVersionUID = 1L;
> 	private long id = 1;
> 	private boolean test1 = false;
> 	private boolean test2 = false;
> 	private int foundTest = 0;
> ...
> }
> {code}
> Rule:
> {code:java}
> rule "test1"
> lock-on-active 
> dialect "mvel"
>     when
>     	$poc:Poc( isTest1() )
>     then
>     	System.out.println("test1 found");
>     	modify($poc) { setFoundTest($poc.getFoundTest() + 1) }    	
> end
> rule "test2"
> lock-on-active 
> dialect "mvel"
>     when
>     	$poc:Poc( isTest2() )
>     then
>     	System.out.println("test2 found");
>     	modify($poc) { setFoundTest($poc.getFoundTest() + 1) }    	
> end
> {code}
> Test:
> {code:java}
> @Test
> public void lockOnActiveTest() {
> 	// Get the Knowledge base from the DRL file 
> 	KieSession kSession = getSF();
> 			
> 	Poc poc = new Poc();
> 	poc.setTest1(true);
> 	poc.setTest2(true);
> 	
> 	kSession.insert(poc);
> 	
> 	// Fire the rules
> 	kSession.fireAllRules();
> 	
> 	assertTrue("broken",poc.getFoundTest()==2);
> 	
> 	// Clean up
> 	kSession.dispose();
> }
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 26 18:37:01 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Sat, 26 Oct 2013 18:37:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-313) Support internal
 @Annotations with default values
In-Reply-To: <JIRA.12508851.1382826935587@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508851.1382826935587@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508851.1382826935587.19045.1382827021918@jira02.app.mwc.hst.phx2.redhat.com>

Davide Sottara created DROOLS-313:
-------------------------------------

             Summary: Support internal @Annotations with default values
                 Key: DROOLS-313
                 URL: https://issues.jboss.org/browse/DROOLS-313
             Project: Drools
          Issue Type: Enhancement
      Security Level: Public (Everyone can see)
    Affects Versions: 6.0.0.CR5
            Reporter: Davide Sottara
            Assignee: Mark Proctor
            Priority: Minor


Annotations such as @Eager and @ActivationListener require an explicit value, or an exception will be thrown

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Oct 26 22:26:01 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Sat, 26 Oct 2013 22:26:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-158) Constant fields that are not
	final
In-Reply-To: <JIRA.12487846.1364043277000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12487846.1364043277000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487846.1364043277000.19097.1382840761880@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825207#comment-12825207 ] 

RH Bugzilla Integration commented on WFLY-158:
----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 926050|https://bugzilla.redhat.com/show_bug.cgi?id=926050] from POST to MODIFIED
                
> Constant fields that are not final
> ----------------------------------
>
>                 Key: WFLY-158
>                 URL: https://issues.jboss.org/browse/WFLY-158
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Alpha1
>
>         Attachments: non-final-fields.txt
>
>
> Analysis by Stephan Mueller shows that the AS codebase includes a significant number of public constant fields that are missing the "final" keyword, which could allow incorrect or nefarious code to change them. This task is to fix these.
> As part of the work for a few cases I'll reduce the field visibility.
> I'll attach file listing the cases.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Oct 27 18:22:01 2013
From: jira-events at lists.jboss.org (Dieter Scholz (JIRA))
Date: Sun, 27 Oct 2013 18:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBASMP-57) Dependency is ignored when
 using "undeploy-artifact"
In-Reply-To: <JIRA.12508861.1382912433626@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508861.1382912433626@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508861.1382912433626.19150.1382912521997@jira02.app.mwc.hst.phx2.redhat.com>

Dieter Scholz created JBASMP-57:
-----------------------------------

             Summary: Dependency is ignored when using "undeploy-artifact"
                 Key: JBASMP-57
                 URL: https://issues.jboss.org/browse/JBASMP-57
             Project: JBoss AS Maven Plugins
          Issue Type: Bug
          Components: deploy
    Affects Versions: 7.5.Final
         Environment: Windows 7 - Maven 3.0.5 - EAP 6.1
            Reporter: Dieter Scholz
            Assignee: James Perkins


Hello,

I don't know if it's a bug.

This is my situation:

I define the configuration of the JBoss plugin in a profile that is located in the parent POM module of my project.

Another module creates an EAR distribution.

The last module uses the profile defined in the parent POM and runs the (local) JBoss instance. The EAR is listed as a dependency and inside the undeploy configuration with group and artifact id.

Everything works fine but the undeploy (in the post-integration-test phase). The exception occurs in line 92 of the UndeployArtifact class.

I found that in this case the call project.getArtifacts() (used a few lines before) returns a null-Set. If I change the call to project.getDependencyArtifacts() all dependencies are returned and the undeploy phase runs just fine.

Is this a bug or a misconfiguration on my side? I am able to provide code samples if necessary.

Greetings, Dieter

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 28 02:52:01 2013
From: jira-events at lists.jboss.org (Steven Peh (JIRA))
Date: Mon, 28 Oct 2013 02:52:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-285) Allow web application
 deployments to point static content to any local folder
In-Reply-To: <JIRA.12508865.1382943081926@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508865.1382943081926@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508865.1382943081926.19220.1382943121935@jira02.app.mwc.hst.phx2.redhat.com>

Steven Peh created JBWEB-285:
--------------------------------

             Summary: Allow web application deployments to point static content to any local folder
                 Key: JBWEB-285
                 URL: https://issues.jboss.org/browse/JBWEB-285
             Project: JBoss Web
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Tomcat
    Affects Versions: JBossWeb-7.2.1.GA
         Environment: DEV
            Reporter: Steven Peh
            Assignee: Remy Maucherat
            Priority: Minor


This is more to facilitate rapid software development.  The ability to point to a local folder for deployment of a web application's static content allows developers to develop and update static content without redeployment or even rebuilding or executing any build task.

This is particularly more pertinent now that Chrome allows mapping of loaded web resources onto local static files and any update to the static files (i.e. css, html, javascript, etc.) in Chrome will synchronize with the mapped resource in both directions.  Essentially, web front-end developers can develop with a WYSIWYG experience in Chrome to rapidly tune and enhance the presentation layer.

Essentially this feature is provide similar support which Tomcat and Jetty provides in terms of providing a static location for a web application

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 28 04:06:02 2013
From: jira-events at lists.jboss.org (Stefano Maestri (JIRA))
Date: Mon, 28 Oct 2013 04:06:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2383) resource-adapter id attribute
 has to match ra name otherwise MDB is not deployed
In-Reply-To: <JIRA.12508785.1382695105000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508785.1382695105000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508785.1382695105000.19255.1382947562045@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefano Maestri reassigned WFLY-2383:
-------------------------------------

    Assignee: Stefano Maestri

    
> resource-adapter id attribute has to match ra name otherwise MDB is not deployed
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-2383
>                 URL: https://issues.jboss.org/browse/WFLY-2383
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Stefano Maestri
>            Assignee: Stefano Maestri
>
> The resource-adapter id has to have the same name as the ra archive has. Otherwise the the MDB is not deployed. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 28 05:04:02 2013
From: jira-events at lists.jboss.org (gui borland (JIRA))
Date: Mon, 28 Oct 2013 05:04:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1110) Pool statistics are not
	cleared
In-Reply-To: <JIRA.12508869.1382951017972@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508869.1382951017972@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508869.1382951017972.19270.1382951042063@jira02.app.mwc.hst.phx2.redhat.com>

gui borland created JBJCA-1110:
----------------------------------

             Summary: Pool statistics are not cleared
                 Key: JBJCA-1110
                 URL: https://issues.jboss.org/browse/JBJCA-1110
             Project: IronJacamar
          Issue Type: Bug
          Components: Core
    Affects Versions: 1.0.19.Final
            Reporter: gui borland
            Assignee: Jesper Pedersen


Invoking the 'clear statistics' JMX method on a connection pool has no effect. 
Quite annoying since it forces me to restart to get a useful value for the 'average' values such as 'averageblockingtime' 
Better implement the method or don't provide a clear method at all.


Today, org.jboss.jca.core.connectionmanager.pool.mcp.ManagedConnectionPoolStatisticsImpl#clear is a no-op...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 28 05:30:02 2013
From: jira-events at lists.jboss.org (Gytis Trikleris (JIRA))
Date: Mon, 28 Oct 2013 05:30:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2145) Automatically add XTS and
 TXBridge handlers to Web Services that use JTA annotations
In-Reply-To: <JIRA.12500584.1378979979000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500584.1378979979000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500584.1378979979000.19283.1382952602058@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gytis Trikleris updated WFLY-2145:
----------------------------------

    Git Pull Request: https://github.com/wildfly/wildfly/pull/5262  (was: https://github.com/wildfly/wildfly/pull/5135)

    
> Automatically add XTS and TXBridge handlers to Web Services that use JTA annotations
> ------------------------------------------------------------------------------------
>
>                 Key: WFLY-2145
>                 URL: https://issues.jboss.org/browse/WFLY-2145
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: XTS
>            Reporter: Paul Robinson
>            Assignee: Gytis Trikleris
>             Fix For: 8.0.0.CR1
>
>
> Currently the developer needs to specify the XTS and Bridge handlers on the Web Service that wishes inflow a WS-AT transaction. This is cumbersome and error prone.
> It is quite easy to infer if the user needs these handlers by checking to see if the Web Service uses @Transactional or @TransactionAtttibute and by looking for a WS-AT transaction context on the inbound message.
> The same can also be done for the Compensations API, by looking for @Compensatable annotations on the Web Service. In which case, only the XTS handler should be added as no bridging is required.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 28 05:30:02 2013
From: jira-events at lists.jboss.org (Gytis Trikleris (JIRA))
Date: Mon, 28 Oct 2013 05:30:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2145) Automatically add XTS and
 TXBridge handlers to Web Services that use JTA annotations
In-Reply-To: <JIRA.12500584.1378979979000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500584.1378979979000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500584.1378979979000.19287.1382952602257@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gytis Trikleris closed WFLY-2145.
---------------------------------


    
> Automatically add XTS and TXBridge handlers to Web Services that use JTA annotations
> ------------------------------------------------------------------------------------
>
>                 Key: WFLY-2145
>                 URL: https://issues.jboss.org/browse/WFLY-2145
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: XTS
>            Reporter: Paul Robinson
>            Assignee: Gytis Trikleris
>             Fix For: 8.0.0.CR1
>
>
> Currently the developer needs to specify the XTS and Bridge handlers on the Web Service that wishes inflow a WS-AT transaction. This is cumbersome and error prone.
> It is quite easy to infer if the user needs these handlers by checking to see if the Web Service uses @Transactional or @TransactionAtttibute and by looking for a WS-AT transaction context on the inbound message.
> The same can also be done for the Compensations API, by looking for @Compensatable annotations on the Web Service. In which case, only the XTS handler should be added as no bridging is required.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 28 05:30:02 2013
From: jira-events at lists.jboss.org (Gytis Trikleris (JIRA))
Date: Mon, 28 Oct 2013 05:30:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2285) Upgrade Narayana to 5.0.0.M6
In-Reply-To: <JIRA.12502762.1381483950000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502762.1381483950000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502762.1381483950000.19288.1382952602339@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gytis Trikleris closed WFLY-2285.
---------------------------------


    
> Upgrade Narayana to 5.0.0.M6
> ----------------------------
>
>                 Key: WFLY-2285
>                 URL: https://issues.jboss.org/browse/WFLY-2285
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Transactions
>            Reporter: Gytis Trikleris
>            Assignee: Gytis Trikleris
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 28 06:30:02 2013
From: jira-events at lists.jboss.org (Arun Gupta (JIRA))
Date: Mon, 28 Oct 2013 06:30:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2027) EE Default DataSource is not
	working
In-Reply-To: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500313.1378739268000.19317.1382956202530@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825251#comment-12825251 ] 

Arun Gupta commented on WFLY-2027:
----------------------------------

Its my understanding that Java EE 7 require a default data source to be available. It could map to whatever the underlying JDBC resource might be.

I asked Linda DeMichiel (spec lead for JPA and Java EE 7 platform) about the default data source and here is what she said:

-- cut here --
Java EE 7 does require that a platform product provide a default
 data source.  This is covered in section EE.5.19 of the Platform
 spec:

   "The Java EE Platform requires that a Java EE Product Provider
   provide a database in the operational environment (see Section
   EE.2.6, ?Database?). The Java EE Product Provider must also provide
   a preconfigured, default data source for use by the application in
   accessing this database.

   "The Java EE Product Provider must make the default data source
   accessible to the application under the JNDI name
   java:comp/DefaultDataSource."
-- cut here --

It does not matter what java:comp/DefaultDataSource point to, an in-memory database or MySQL or some other data source. But the main idea behind all this was to ensure more seamless OOTB experience where developers do not have to configure an additional item in order to get started.
                
> EE Default DataSource is not working
> ------------------------------------
>
>                 Key: WFLY-2027
>                 URL: https://issues.jboss.org/browse/WFLY-2027
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ConfigAdmin, Domain Management, EE, JCA, JPA / Hibernate, Web Console
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Lincoln Baxter III
>            Assignee: Eduardo Martins
>             Fix For: 8.0.0.Beta1
>
>
> The EE spec states that a default datasource must be supplied under: java:comp/DefaultDataSource, and if none is specified by the @Resource or persistence.xml, it must be assumed:
>  {code}EE 5.19
> The Java EE Platform requires that a Java EE Product Provider provide a database 
> in the operational environment (see Section EE.2.6, ?Database?). The Java EE 
> Product Provider must also provide a preconfigured, default data source for use by 
> the application in accessing this database.
> The Java EE Product Provider must make the default data source accessible to 
> the application under the JNDI name java:comp/DefaultDataSource.
> The Application Component Provider or Deployer may explicitly bind a 
> DataSource resource reference to the default data source using the lookup element 
> of the Resource annotation or the lookup-name element of the resource-ref
> deployment descriptor element. For example,
> @Resource(lookup="java:comp/DefaultDataSource")
> DataSource myDS;
> In the absence of such a binding, the mapping of the reference will default to 
> the product's default data source.
> For example, the following will map to a preconfigured data source for the 
> product's default database:
> @Resource
> DataSource myDS;{code}
> This, isn't working however:
> {code}
> <persistence version="2.1" xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>    xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/persistence/persistence_2_1.xsd">
>    <persistence-unit name="default" transaction-type="JTA">
>    </persistence-unit>
> </persistence>{code}
> Results in: 
> {code}
> 10:41:31,002 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 50) MSC000001: Failed to start service jboss.persistenceunit."jpa-standard.war#default": org.jboss.msc.service.StartException in service jboss.persistenceunit."jpa-standard.war#default": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:134) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.determineDialect(DialectFactoryImpl.java:98)
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.buildDialect(DialectFactoryImpl.java:66)
> 	at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:193)
> 	at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:88)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:159)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131)
> 	at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration.java:1844)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1802)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:844)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835)
> 	at org.jboss.as.jpa.hibernate4.management.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:115) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	... 4 more
> 10:41:31,010 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"jpa-standard.war#default\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"jpa-standard.war#default\": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
>     Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set"}}
> {code}
> Additionally, actually specifying the expected JDNI name of the default DS like this:
> {code}   <persistence-unit name="default" transaction-type="JTA">
>       <jta-data-source>java:comp/DefaultDataSource</jta-data-source>
>       <exclude-unlisted-classes>false</exclude-unlisted-classes>
>    </persistence-unit>{code}
> Results in this:
> {code}
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.naming.context.java.module.jpa-standard.jpa-standard.DefaultDataSource (missing) dependents: [service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__] 
>       service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__ (missing) dependents: [service jboss.deployment.unit."jpa-standard.war".POST_MODULE] 
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Mon Oct 28 06:32:01 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Mon, 28 Oct 2013 06:32:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2388) Calling getRequestURI()
 returns wrong address for root URL of webapp
In-Reply-To: <JIRA.12508840.1382772318000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508840.1382772318000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508840.1382772318000.19320.1382956321976@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-2388.
----------------------------------

    Fix Version/s: 8.0.0.CR1
       Resolution: Done

    
> Calling getRequestURI() returns wrong address for root URL of webapp
> --------------------------------------------------------------------
>
>                 Key: WFLY-2388
>                 URL: https://issues.jboss.org/browse/WFLY-2388
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Christian Kaltepoth
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.CR1
>
>         Attachments: start-page.zip
>
>
> Reading {{HttpServletRequest.getRequestURI()}} from a servlet filter gives incorrect result if requesting the root URL of a webapp:
> ||Requested URL||getRequestURI()||Correct?||
> |{{http://localhost:8080/myapp/foobar}}|{{/myapp/foobar}}|OK|
> |{{http://localhost:8080/myapp/}}|{{/myapp/index.jsp}}|Incorrect! Should be {{/myapp/}}|
> It seems like the filter sees the name of the welcome page instead of the incoming request URL. That's not correct.
> I tested this with other containers like Tomcat, AS7 and Glassfish and all of them show the incoming request URL instead.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 28 06:35:01 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 28 Oct 2013 06:35:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2021) EE Component interceptor
 chains should be stateless
In-Reply-To: <JIRA.12500214.1378475131000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500214.1378475131000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500214.1378475131000.19323.1382956501938@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825253#comment-12825253 ] 

RH Bugzilla Integration commented on WFLY-2021:
-----------------------------------------------

Stuart Douglas <sdouglas at redhat.com> made a comment on [bug 1022265|https://bugzilla.redhat.com/show_bug.cgi?id=1022265]

Upstream commit is https://github.com/wildfly/wildfly/commit/c4dceafe3f52e61a8bb318f10722eae193da8c62

Upstream PR is https://github.com/wildfly/wildfly/pull/5326
                
> EE Component interceptor chains should be stateless
> ---------------------------------------------------
>
>                 Key: WFLY-2021
>                 URL: https://issues.jboss.org/browse/WFLY-2021
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: EE, EJB
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.CR1
>
>
> This will allow them to be shared by all instances, rather than having a new chain allocated for each method.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 28 06:47:02 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Mon, 28 Oct 2013 06:47:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2027) EE Default DataSource is not
	working
In-Reply-To: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500313.1378739268000.19339.1382957222344@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825254#comment-12825254 ] 

Scott Marlow commented on WFLY-2027:
------------------------------------

Arun, 

Please see earlier comments in this jira about JPA not being required to use the EE default datasource (java:comp.DefaultDataSource).  I don't particularly care if I am right or wrong but can only go by the facts (JPA spec wording about a default data source is pre-EE7.)

Did Linda specifically point out that JPA persistence units would be able to find the default data source via java:comp/DefaultDataSource?  From an EE point of view, it would be good to clarify exactly what portable applications can expect.  

Scott
                
> EE Default DataSource is not working
> ------------------------------------
>
>                 Key: WFLY-2027
>                 URL: https://issues.jboss.org/browse/WFLY-2027
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ConfigAdmin, Domain Management, EE, JCA, JPA / Hibernate, Web Console
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Lincoln Baxter III
>            Assignee: Eduardo Martins
>             Fix For: 8.0.0.Beta1
>
>
> The EE spec states that a default datasource must be supplied under: java:comp/DefaultDataSource, and if none is specified by the @Resource or persistence.xml, it must be assumed:
>  {code}EE 5.19
> The Java EE Platform requires that a Java EE Product Provider provide a database 
> in the operational environment (see Section EE.2.6, ?Database?). The Java EE 
> Product Provider must also provide a preconfigured, default data source for use by 
> the application in accessing this database.
> The Java EE Product Provider must make the default data source accessible to 
> the application under the JNDI name java:comp/DefaultDataSource.
> The Application Component Provider or Deployer may explicitly bind a 
> DataSource resource reference to the default data source using the lookup element 
> of the Resource annotation or the lookup-name element of the resource-ref
> deployment descriptor element. For example,
> @Resource(lookup="java:comp/DefaultDataSource")
> DataSource myDS;
> In the absence of such a binding, the mapping of the reference will default to 
> the product's default data source.
> For example, the following will map to a preconfigured data source for the 
> product's default database:
> @Resource
> DataSource myDS;{code}
> This, isn't working however:
> {code}
> <persistence version="2.1" xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>    xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/persistence/persistence_2_1.xsd">
>    <persistence-unit name="default" transaction-type="JTA">
>    </persistence-unit>
> </persistence>{code}
> Results in: 
> {code}
> 10:41:31,002 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 50) MSC000001: Failed to start service jboss.persistenceunit."jpa-standard.war#default": org.jboss.msc.service.StartException in service jboss.persistenceunit."jpa-standard.war#default": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:134) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.determineDialect(DialectFactoryImpl.java:98)
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.buildDialect(DialectFactoryImpl.java:66)
> 	at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:193)
> 	at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:88)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:159)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131)
> 	at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration.java:1844)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1802)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:844)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835)
> 	at org.jboss.as.jpa.hibernate4.management.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:115) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	... 4 more
> 10:41:31,010 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"jpa-standard.war#default\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"jpa-standard.war#default\": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
>     Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set"}}
> {code}
> Additionally, actually specifying the expected JDNI name of the default DS like this:
> {code}   <persistence-unit name="default" transaction-type="JTA">
>       <jta-data-source>java:comp/DefaultDataSource</jta-data-source>
>       <exclude-unlisted-classes>false</exclude-unlisted-classes>
>    </persistence-unit>{code}
> Results in this:
> {code}
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.naming.context.java.module.jpa-standard.jpa-standard.DefaultDataSource (missing) dependents: [service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__] 
>       service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__ (missing) dependents: [service jboss.deployment.unit."jpa-standard.war".POST_MODULE] 
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Mon Oct 28 09:25:01 2013
From: jira-events at lists.jboss.org (Xavier Coulon (JIRA))
Date: Mon, 28 Oct 2013 09:25:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2391) Wildfly caches content in
 exploded mode, breaking developer productivity
In-Reply-To: <JIRA.12508879.1382966687950@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508879.1382966687950@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508879.1382966687950.19470.1382966701893@jira02.app.mwc.hst.phx2.redhat.com>

Xavier Coulon created WFLY-2391:
-----------------------------------

             Summary: Wildfly caches content in exploded mode, breaking developer productivity
                 Key: WFLY-2391
                 URL: https://issues.jboss.org/browse/WFLY-2391
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 8.0.0.Beta1
         Environment: MacOSX with JBossTools 4.1.1.Beta1
            Reporter: Xavier Coulon


While I was building a sample application with JBoss Tools 4.1.1.beta1 on WildFly 8.0.Beta1, I noticed that after a few minutes (or a few browser requests), the content of my index.html file seemed to be cached by the server, although I used the "exploded content" deployment mode (since I published the content using the WildFly Server Adapter in JBoss Tools).

 

I checked the actual content of the index.html in the deployments folder and it contained the latest changes, which means that the JBoss Tools Server Adapter is doing its job well ;-)

I also tried to edit the index.html file directly in the deployments folder, and once again, I got no update in both Chrome and Firefox browsers.

 

I checked in the "Network" tab of the browsers and could see that the server response for the index.html page had a "200 OK" status, which means that there's no browser caching involved.

I tried to get the index.html page with cUrl and got the same old version, which definitely excludes a browser caching issue.

At the end of the dat, this means that after a few changes, my browsers keep getting an old version of the deployed resources, which in turns means that I have to stop and restart the server to get the new content, and this is pretty bad in term of dev productivity.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 28 09:46:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Mon, 28 Oct 2013 09:46:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2365) DuplicateServiceException
 when deploying ear containing jar and war with same name
In-Reply-To: <JIRA.12508602.1382543911000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508602.1382543911000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508602.1382543911000.19492.1382967962568@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFLY-2365:
------------------------------------

    Assignee: Eduardo Martins  (was: David Lloyd)


Assigning to Eduardo, is it is related to concurrency. Proposed patch is no longer valid, due to existing code changes.

Basically the real problem is that these service names are not built by appending to the service name returned by DeploymentUnit.getServiceName(). In order to avoid conflicts all deployment related services (with very few exceptions such as global JNDI binding services) should be based on this.
                
> DuplicateServiceException when deploying ear containing jar and war with same name
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-2365
>                 URL: https://issues.jboss.org/browse/WFLY-2365
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EE
>            Reporter: Alessio Soldano
>            Assignee: Eduardo Martins
>             Fix For: 8.0.0.CR1
>
>
> The following exception is thrown when deploying a EAR archive containing a war and jar with the same name (except for the file extension, of course).
> See https://community.jboss.org/thread/233648
>     2013-10-17 10:32:59,266 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.subunit."specj.ear"."specj.jar".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."specj.ear"."specj.jar".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of subdeployment "specj.jar" of deployment "specj.ear"  
>       at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]  
>       at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]  
>       at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]  
>       at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]  
>       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]  
>       at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]  
>     Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.concurrent.ee.context.config.specj.specj is already registered  
>       at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]  
>       at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]  
>       at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:767) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]  
>       at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]  
>       at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2384) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]  
>       at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]  
>       at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2384) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]  
>       at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]  
>       at org.jboss.as.ee.concurrent.deployers.EEConcurrentContextProcessor.setupConcurrentContext(EEConcurrentContextProcessor.java:110)  
>       at org.jboss.as.ee.concurrent.deployers.EEConcurrentContextProcessor.processModuleDescription(EEConcurrentContextProcessor.java:71)  
>       at org.jboss.as.ee.concurrent.deployers.EEConcurrentContextProcessor.deploy(EEConcurrentContextProcessor.java:54)  
>       at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]  
>       ... 5 more  
>       
>       
>     2013-10-17 10:32:59,283 ERROR [org.jboss.as.controller.management-operation] (XNIO-1 task-3) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "specj.ear")]) - failure description: {  
>         "JBAS014671: Failed services" => {"jboss.deployment.subunit.\"specj.ear\".\"specj.jar\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.subunit.\"specj.ear\".\"specj.jar\".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of subdeployment \"specj.jar\" of deployment \"specj.ear\"  
>         Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.concurrent.ee.context.config.specj.specj is already registered"},  
>         "JBAS014771: Services with missing/unavailable dependencies" => ["jboss.deployment.unit.\"specj.ear\".weld.weldClassIntrospector is missing [jboss.deployment.unit.\"specj.ear\".beanmanager]"]  
>     }  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 28 09:48:01 2013
From: jira-events at lists.jboss.org (Alessio Soldano (JIRA))
Date: Mon, 28 Oct 2013 09:48:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2365) DuplicateServiceException
 when deploying ear containing jar and war with same name
In-Reply-To: <JIRA.12508602.1382543911000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508602.1382543911000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508602.1382543911000.19498.1382968081979@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825277#comment-12825277 ] 

Alessio Soldano commented on WFLY-2365:
---------------------------------------

Thanks Stuart
                
> DuplicateServiceException when deploying ear containing jar and war with same name
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-2365
>                 URL: https://issues.jboss.org/browse/WFLY-2365
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EE
>            Reporter: Alessio Soldano
>            Assignee: Eduardo Martins
>             Fix For: 8.0.0.CR1
>
>
> The following exception is thrown when deploying a EAR archive containing a war and jar with the same name (except for the file extension, of course).
> See https://community.jboss.org/thread/233648
>     2013-10-17 10:32:59,266 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.subunit."specj.ear"."specj.jar".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."specj.ear"."specj.jar".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of subdeployment "specj.jar" of deployment "specj.ear"  
>       at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]  
>       at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]  
>       at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]  
>       at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]  
>       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]  
>       at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]  
>     Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.concurrent.ee.context.config.specj.specj is already registered  
>       at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]  
>       at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]  
>       at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:767) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]  
>       at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]  
>       at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2384) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]  
>       at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]  
>       at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2384) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]  
>       at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]  
>       at org.jboss.as.ee.concurrent.deployers.EEConcurrentContextProcessor.setupConcurrentContext(EEConcurrentContextProcessor.java:110)  
>       at org.jboss.as.ee.concurrent.deployers.EEConcurrentContextProcessor.processModuleDescription(EEConcurrentContextProcessor.java:71)  
>       at org.jboss.as.ee.concurrent.deployers.EEConcurrentContextProcessor.deploy(EEConcurrentContextProcessor.java:54)  
>       at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]  
>       ... 5 more  
>       
>       
>     2013-10-17 10:32:59,283 ERROR [org.jboss.as.controller.management-operation] (XNIO-1 task-3) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "specj.ear")]) - failure description: {  
>         "JBAS014671: Failed services" => {"jboss.deployment.subunit.\"specj.ear\".\"specj.jar\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.subunit.\"specj.ear\".\"specj.jar\".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of subdeployment \"specj.jar\" of deployment \"specj.ear\"  
>         Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.concurrent.ee.context.config.specj.specj is already registered"},  
>         "JBAS014771: Services with missing/unavailable dependencies" => ["jboss.deployment.unit.\"specj.ear\".weld.weldClassIntrospector is missing [jboss.deployment.unit.\"specj.ear\".beanmanager]"]  
>     }  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 28 09:50:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Mon, 28 Oct 2013 09:50:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2392)
 org.jboss.as.naming.service.NamingStoreService is not restartable
In-Reply-To: <JIRA.12508884.1382968133467@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508884.1382968133467@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508884.1382968133467.19504.1382968202283@jira02.app.mwc.hst.phx2.redhat.com>

Stuart Douglas created WFLY-2392:
------------------------------------

             Summary: org.jboss.as.naming.service.NamingStoreService is not restartable
                 Key: WFLY-2392
                 URL: https://issues.jboss.org/browse/WFLY-2392
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Naming
            Reporter: Stuart Douglas
            Assignee: Eduardo Martins
            Priority: Minor


If you create this naming store by passing a store into the constructor this store will be cleared on stop, and a new one created on start. Perhaps it should be passed some kind of factory, or have a protected createStore method that can be overriden.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 28 09:52:01 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 28 Oct 2013 09:52:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2391) Wildfly caches content in
 exploded mode, breaking developer productivity
In-Reply-To: <JIRA.12508879.1382966687000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508879.1382966687000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508879.1382966687000.19508.1382968321939@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-2391:
------------------------------

    Component/s: Web (Undertow)

    
> Wildfly caches content in exploded mode, breaking developer productivity
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2391
>                 URL: https://issues.jboss.org/browse/WFLY-2391
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>         Environment: MacOSX with JBossTools 4.1.1.Beta1
>            Reporter: Xavier Coulon
>
> While I was building a sample application with JBoss Tools 4.1.1.beta1 on WildFly 8.0.Beta1, I noticed that after a few minutes (or a few browser requests), the content of my index.html file seemed to be cached by the server, although I used the "exploded content" deployment mode (since I published the content using the WildFly Server Adapter in JBoss Tools).
>  
> I checked the actual content of the index.html in the deployments folder and it contained the latest changes, which means that the JBoss Tools Server Adapter is doing its job well ;-)
> I also tried to edit the index.html file directly in the deployments folder, and once again, I got no update in both Chrome and Firefox browsers.
>  
> I checked in the "Network" tab of the browsers and could see that the server response for the index.html page had a "200 OK" status, which means that there's no browser caching involved.
> I tried to get the index.html page with cUrl and got the same old version, which definitely excludes a browser caching issue.
> At the end of the dat, this means that after a few changes, my browsers keep getting an old version of the deployed resources, which in turns means that I have to stop and restart the server to get the new content, and this is pretty bad in term of dev productivity.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 28 10:37:01 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 28 Oct 2013 10:37:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2370) NPE in
	DelegatingServerInventory
In-Reply-To: <JIRA.12508635.1382579451000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508635.1382579451000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508635.1382579451000.19563.1382971021979@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFLY-2370:
--------------------------------------

    Assignee: Brian Stansberry  (was: Emanuel Muckenhuber)

    
> NPE in DelegatingServerInventory
> --------------------------------
>
>                 Key: WFLY-2370
>                 URL: https://issues.jboss.org/browse/WFLY-2370
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=4738&tab=buildResultsDiv&buildTypeId=WF_MasterIgnoreWindowsDomainOnly
> Test failure:
> java.lang.AssertionError
>     at org.junit.Assert.fail(Assert.java:86)
>     at org.junit.Assert.assertTrue(Assert.java:41)
>     at org.junit.Assert.assertTrue(Assert.java:52)
>     at org.jboss.as.test.integration.domain.DomainControllerMigrationTestCase.testDCFailover(DomainControllerMigrationTestCase.java:223)
> This appears in the log:
> [Host Controller] 03:26:38,028 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014612: Operation ("read-attribute") failed - address: ([
> [Host Controller]     ("host" => "failover-h1"),
> [Host Controller]     ("server-config" => "failover-one")
> [Host Controller] ]): java.lang.NullPointerException
> [Host Controller]     at org.jboss.as.host.controller.DomainModelControllerService$DelegatingServerInventory.determineServerStatus(DomainModelControllerService.java:788)
> [Host Controller]     at org.jboss.as.host.controller.operations.ServerStatusHandler.execute(ServerStatusHandler.java:66)
> [Host Controller]     at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecuteInternal(ReadAttributeHandler.java:177) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller]     at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecute(ReadAttributeHandler.java:97) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller]     at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractMultiTargetHandler.execute(GlobalOperationHandlers.java:151) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 28 11:04:02 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Mon, 28 Oct 2013 11:04:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2212) Update JPA subsystem to use
 EE default datasource
In-Reply-To: <JIRA.12502126.1380810972000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502126.1380810972000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502126.1380810972000.19627.1382972642035@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825296#comment-12825296 ] 

Scott Marlow commented on WFLY-2212:
------------------------------------

Having the ee default ds override the jpa default ds, will be easier (so that the jpa default ds doesn't have to be set).  If the EE default ds is not set, we will still use the jpa default ds.
                
> Update JPA subsystem to use EE default datasource
> -------------------------------------------------
>
>                 Key: WFLY-2212
>                 URL: https://issues.jboss.org/browse/WFLY-2212
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 8.0.0.CR1
>
>
> See comments in WFLY-2027 before starting the work on this jira...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 28 11:30:01 2013
From: jira-events at lists.jboss.org (Max Rydahl Andersen (JIRA))
Date: Mon, 28 Oct 2013 11:30:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2391) Wildfly caches content in
 exploded mode, breaking developer productivity
In-Reply-To: <JIRA.12508879.1382966687000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508879.1382966687000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508879.1382966687000.19639.1382974201941@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825301#comment-12825301 ] 

Max Rydahl Andersen commented on WFLY-2391:
-------------------------------------------

UNDERTOW-17 seems related
                
> Wildfly caches content in exploded mode, breaking developer productivity
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2391
>                 URL: https://issues.jboss.org/browse/WFLY-2391
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>         Environment: MacOSX with JBossTools 4.1.1.Beta1
>            Reporter: Xavier Coulon
>
> While I was building a sample application with JBoss Tools 4.1.1.beta1 on WildFly 8.0.Beta1, I noticed that after a few minutes (or a few browser requests), the content of my index.html file seemed to be cached by the server, although I used the "exploded content" deployment mode (since I published the content using the WildFly Server Adapter in JBoss Tools).
>  
> I checked the actual content of the index.html in the deployments folder and it contained the latest changes, which means that the JBoss Tools Server Adapter is doing its job well ;-)
> I also tried to edit the index.html file directly in the deployments folder, and once again, I got no update in both Chrome and Firefox browsers.
>  
> I checked in the "Network" tab of the browsers and could see that the server response for the index.html page had a "200 OK" status, which means that there's no browser caching involved.
> I tried to get the index.html page with cUrl and got the same old version, which definitely excludes a browser caching issue.
> At the end of the dat, this means that after a few changes, my browsers keep getting an old version of the deployed resources, which in turns means that I have to stop and restart the server to get the new content, and this is pretty bad in term of dev productivity.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 28 11:32:01 2013
From: jira-events at lists.jboss.org (Max Rydahl Andersen (JIRA))
Date: Mon, 28 Oct 2013 11:32:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2391) Wildfly caches content in
 exploded mode, breaking developer productivity
In-Reply-To: <JIRA.12508879.1382966687000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508879.1382966687000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508879.1382966687000.19641.1382974321924@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825301#comment-12825301 ] 

Max Rydahl Andersen edited comment on WFLY-2391 at 10/28/13 11:30 AM:
----------------------------------------------------------------------

UNDERTOW-117 seems related
                
      was (Author: maxandersen):
    UNDERTOW-17 seems related
                  
> Wildfly caches content in exploded mode, breaking developer productivity
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2391
>                 URL: https://issues.jboss.org/browse/WFLY-2391
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>         Environment: MacOSX with JBossTools 4.1.1.Beta1
>            Reporter: Xavier Coulon
>
> While I was building a sample application with JBoss Tools 4.1.1.beta1 on WildFly 8.0.Beta1, I noticed that after a few minutes (or a few browser requests), the content of my index.html file seemed to be cached by the server, although I used the "exploded content" deployment mode (since I published the content using the WildFly Server Adapter in JBoss Tools).
>  
> I checked the actual content of the index.html in the deployments folder and it contained the latest changes, which means that the JBoss Tools Server Adapter is doing its job well ;-)
> I also tried to edit the index.html file directly in the deployments folder, and once again, I got no update in both Chrome and Firefox browsers.
>  
> I checked in the "Network" tab of the browsers and could see that the server response for the index.html page had a "200 OK" status, which means that there's no browser caching involved.
> I tried to get the index.html page with cUrl and got the same old version, which definitely excludes a browser caching issue.
> At the end of the dat, this means that after a few changes, my browsers keep getting an old version of the deployed resources, which in turns means that I have to stop and restart the server to get the new content, and this is pretty bad in term of dev productivity.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 28 12:17:02 2013
From: jira-events at lists.jboss.org (Max Rydahl Andersen (JIRA))
Date: Mon, 28 Oct 2013 12:17:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2391) Wildfly caches content in
 exploded mode, breaking developer productivity
In-Reply-To: <JIRA.12508879.1382966687000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508879.1382966687000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508879.1382966687000.19672.1382977022411@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825307#comment-12825307 ] 

Max Rydahl Andersen commented on WFLY-2391:
-------------------------------------------

I've done a bit to reproduce this.

First of, it does not happen on just a few requests. 
Before 5 hits updates happens including noticing restarts and .dodeploy markers.

Force refreshing the browser ~5 times and suddenly things gets weird.
updates to html has no effect.
restarting via management service sees the module be restarted but the content is still the old one.
restarting via .dodeploy works too - but content not refreshed.

This last one I can't find a way to reproduce reliably but it has happend 3 times now:
...I'm even seeing the app being undeployed by the server (I didn't request it, but .undeployed file is there and log prints its undeployed) and the content is still being served. 
                
> Wildfly caches content in exploded mode, breaking developer productivity
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2391
>                 URL: https://issues.jboss.org/browse/WFLY-2391
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>         Environment: MacOSX with JBossTools 4.1.1.Beta1
>            Reporter: Xavier Coulon
>
> While I was building a sample application with JBoss Tools 4.1.1.beta1 on WildFly 8.0.Beta1, I noticed that after a few minutes (or a few browser requests), the content of my index.html file seemed to be cached by the server, although I used the "exploded content" deployment mode (since I published the content using the WildFly Server Adapter in JBoss Tools).
>  
> I checked the actual content of the index.html in the deployments folder and it contained the latest changes, which means that the JBoss Tools Server Adapter is doing its job well ;-)
> I also tried to edit the index.html file directly in the deployments folder, and once again, I got no update in both Chrome and Firefox browsers.
>  
> I checked in the "Network" tab of the browsers and could see that the server response for the index.html page had a "200 OK" status, which means that there's no browser caching involved.
> I tried to get the index.html page with cUrl and got the same old version, which definitely excludes a browser caching issue.
> At the end of the dat, this means that after a few changes, my browsers keep getting an old version of the deployed resources, which in turns means that I have to stop and restart the server to get the new content, and this is pretty bad in term of dev productivity.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 28 12:19:01 2013
From: jira-events at lists.jboss.org (Max Rydahl Andersen (JIRA))
Date: Mon, 28 Oct 2013 12:19:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2391) Wildfly caches content in
 exploded mode, breaking developer productivity
In-Reply-To: <JIRA.12508879.1382966687000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508879.1382966687000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508879.1382966687000.19676.1382977141905@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825309#comment-12825309 ] 

Max Rydahl Andersen commented on WFLY-2391:
-------------------------------------------

only way I found it to be able to reliable reload content is by restarting the server.
                
> Wildfly caches content in exploded mode, breaking developer productivity
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2391
>                 URL: https://issues.jboss.org/browse/WFLY-2391
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>         Environment: MacOSX with JBossTools 4.1.1.Beta1
>            Reporter: Xavier Coulon
>
> While I was building a sample application with JBoss Tools 4.1.1.beta1 on WildFly 8.0.Beta1, I noticed that after a few minutes (or a few browser requests), the content of my index.html file seemed to be cached by the server, although I used the "exploded content" deployment mode (since I published the content using the WildFly Server Adapter in JBoss Tools).
>  
> I checked the actual content of the index.html in the deployments folder and it contained the latest changes, which means that the JBoss Tools Server Adapter is doing its job well ;-)
> I also tried to edit the index.html file directly in the deployments folder, and once again, I got no update in both Chrome and Firefox browsers.
>  
> I checked in the "Network" tab of the browsers and could see that the server response for the index.html page had a "200 OK" status, which means that there's no browser caching involved.
> I tried to get the index.html page with cUrl and got the same old version, which definitely excludes a browser caching issue.
> At the end of the dat, this means that after a few changes, my browsers keep getting an old version of the deployed resources, which in turns means that I have to stop and restart the server to get the new content, and this is pretty bad in term of dev productivity.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 28 12:27:02 2013
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 28 Oct 2013 12:27:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2393) deprecate messaging's
	-jms.xml deployment
In-Reply-To: <JIRA.12508894.1382977509221@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508894.1382977509221@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508894.1382977509221.19684.1382977622092@jira02.app.mwc.hst.phx2.redhat.com>

Jeff Mesnil created WFLY-2393:
---------------------------------

             Summary: deprecate messaging's -jms.xml deployment
                 Key: WFLY-2393
                 URL: https://issues.jboss.org/browse/WFLY-2393
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JMS
    Affects Versions: 8.0.0.Beta1
            Reporter: Jeff Mesnil
            Assignee: Jeff Mesnil
             Fix For: 8.0.0.CR1


JMS destinations can be deployed using a non-standard -jms.xml description files.

With JMS 2.0 and Java EE7, the same can be achieved in a standard portable way using jms-destination in Java EE deployment descriptors.

Deprecate the non-standard -jms.xml with a message stating to use the standard descriptor deployment instead.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 28 12:40:02 2013
From: jira-events at lists.jboss.org (Max Rydahl Andersen (JIRA))
Date: Mon, 28 Oct 2013 12:40:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2391) Wildfly caches content in
 exploded mode, breaking developer productivity
In-Reply-To: <JIRA.12508879.1382966687000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508879.1382966687000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508879.1382966687000.19736.1382978402160@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825315#comment-12825315 ] 

Max Rydahl Andersen commented on WFLY-2391:
-------------------------------------------

Eventually I end up having that index.html is not serving out content anymore, it returns 0 bytes. Again I have to restart the server.



                
> Wildfly caches content in exploded mode, breaking developer productivity
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2391
>                 URL: https://issues.jboss.org/browse/WFLY-2391
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>         Environment: MacOSX with JBossTools 4.1.1.Beta1
>            Reporter: Xavier Coulon
>
> While I was building a sample application with JBoss Tools 4.1.1.beta1 on WildFly 8.0.Beta1, I noticed that after a few minutes (or a few browser requests), the content of my index.html file seemed to be cached by the server, although I used the "exploded content" deployment mode (since I published the content using the WildFly Server Adapter in JBoss Tools).
>  
> I checked the actual content of the index.html in the deployments folder and it contained the latest changes, which means that the JBoss Tools Server Adapter is doing its job well ;-)
> I also tried to edit the index.html file directly in the deployments folder, and once again, I got no update in both Chrome and Firefox browsers.
>  
> I checked in the "Network" tab of the browsers and could see that the server response for the index.html page had a "200 OK" status, which means that there's no browser caching involved.
> I tried to get the index.html page with cUrl and got the same old version, which definitely excludes a browser caching issue.
> At the end of the dat, this means that after a few changes, my browsers keep getting an old version of the deployed resources, which in turns means that I have to stop and restart the server to get the new content, and this is pretty bad in term of dev productivity.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 28 12:42:02 2013
From: jira-events at lists.jboss.org (Max Rydahl Andersen (JIRA))
Date: Mon, 28 Oct 2013 12:42:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2391) Wildfly caches content in
 exploded mode, breaking developer productivity
In-Reply-To: <JIRA.12508879.1382966687000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508879.1382966687000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508879.1382966687000.19741.1382978522014@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Max Rydahl Andersen updated WFLY-2391:
--------------------------------------

    Attachment: jboss-as-kitchensink-html5-mobile.war.zip


jboss-as-kitchensink-html5-mobile.war.zip is what I put (unzipped) into deployments folder.

Notice that this app in its state is not a fully working app but it should still not bring wf8/undertow into this state I can't recover from.


                
> Wildfly caches content in exploded mode, breaking developer productivity
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2391
>                 URL: https://issues.jboss.org/browse/WFLY-2391
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>         Environment: MacOSX with JBossTools 4.1.1.Beta1
>            Reporter: Xavier Coulon
>         Attachments: jboss-as-kitchensink-html5-mobile.war.zip
>
>
> While I was building a sample application with JBoss Tools 4.1.1.beta1 on WildFly 8.0.Beta1, I noticed that after a few minutes (or a few browser requests), the content of my index.html file seemed to be cached by the server, although I used the "exploded content" deployment mode (since I published the content using the WildFly Server Adapter in JBoss Tools).
>  
> I checked the actual content of the index.html in the deployments folder and it contained the latest changes, which means that the JBoss Tools Server Adapter is doing its job well ;-)
> I also tried to edit the index.html file directly in the deployments folder, and once again, I got no update in both Chrome and Firefox browsers.
>  
> I checked in the "Network" tab of the browsers and could see that the server response for the index.html page had a "200 OK" status, which means that there's no browser caching involved.
> I tried to get the index.html page with cUrl and got the same old version, which definitely excludes a browser caching issue.
> At the end of the dat, this means that after a few changes, my browsers keep getting an old version of the deployed resources, which in turns means that I have to stop and restart the server to get the new content, and this is pretty bad in term of dev productivity.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 28 13:14:02 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Mon, 28 Oct 2013 13:14:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-314) Build in accumulate
 functions are highly unreliable for long's and BigDecimals
In-Reply-To: <JIRA.12348768.1194621918000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12348768.1194621918000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12348768.1194621918000.19838.1382980442127@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Davide Sottara moved JBRULES-1322 to DROOLS-314:
------------------------------------------------

              Project: Drools  (was: JBRULES)
                  Key: DROOLS-314  (was: JBRULES-1322)
             Workflow: GIT Pull Request workflow   (was: classic default workflow)
    Affects Version/s:     (was: 4.0.3)
          Component/s:     (was: drools-compiler)
        Fix Version/s:     (was: FUTURE)

    
> Build in accumulate functions are highly unreliable for long's and BigDecimals
> ------------------------------------------------------------------------------
>
>                 Key: DROOLS-314
>                 URL: https://issues.jboss.org/browse/DROOLS-314
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Geoffrey De Smet
>            Assignee: Edson Tirelli
>            Priority: Critical
>         Attachments: JBRULES-1322-testcase.patch
>
>
> When dealing with financial data, one should never ever use double's. Instead BigDecimal should be used.
> Not because BigDecimal is bigger (that's rarely a problem) but because it doesn't do any decimal to binary transformation.
> For example, it's impossible for a double to correctly represent "0.2", aka 1/5.
> Summing many doubles (or even a few differing in scale), can easily give wrong results (and for financial data this tends to be important).
> Using doubles to sum longs have the exact same problem.
> Attached is a testcase patch which proves this by checking if (MAX_LONG - 4L) and 3L sum up to be (MAX_LONG - 1L).
> Currently they don't.
> One possible way to solve this is to fix JBRULES-1075,
> which just happens to give drools-solver 3% more performance ;) what a coincidence ^^

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 28 13:16:03 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Mon, 28 Oct 2013 13:16:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-315) Support overloading of
 accumulate functions: Add int (or long) based sum's, int based avarage's,
 etc
In-Reply-To: <JIRA.12343025.1186928694000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12343025.1186928694000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12343025.1186928694000.19844.1382980563089@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Davide Sottara moved JBRULES-1075 to DROOLS-315:
------------------------------------------------

              Project: Drools  (was: JBRULES)
                  Key: DROOLS-315  (was: JBRULES-1075)
             Workflow: GIT Pull Request workflow   (was: classic default workflow)
    Affects Version/s:     (was:  4.0.0.GA)
          Component/s:     (was: drools-compiler)
        Fix Version/s:     (was: FUTURE)

    
> Support overloading of accumulate functions: Add int (or long) based sum's, int based avarage's, etc 
> -----------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-315
>                 URL: https://issues.jboss.org/browse/DROOLS-315
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Geoffrey De Smet
>            Assignee: Edson Tirelli
>            Priority: Minor
>         Attachments: JBRULES-1075.patch
>
>
> TTP nl10 solver has about a 3% performance increase when switching from sumDouble to sumLong (and possibly a bit more when switching to sumInteger)
> There are 2 ways I see to implement this:
> 1) Force the user to explicitly declare he wants to use an integer based sum and add a sumInteger.
> This is not so user-friendly. This is what I 've done in the patch.
> 2) Support overloading of accumulate functions based on the function arguments.
> AFAIK drl is strongly typed (at least with the java dialect), so it should be theoretically possible for the drl parser to see
>  sum($myInteger)
> and bind it to SumIntegerAccumulateFunction,
> while binding
>  sum($myInteger.doubleValue())
> to SumDoubleAccumulateFunction.
> And added advantage is that the drl compiler will also mark some bugs as compiler errors. For example
>   sum($myString)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 28 14:11:01 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 28 Oct 2013 14:11:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2394) AccessControlContext and
 management users Subject leaking into thread pool of host controller
 executor.
In-Reply-To: <JIRA.12508901.1382983851172@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508901.1382983851172@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508901.1382983851172.19899.1382983861960@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-2394:
--------------------------------------

             Summary: AccessControlContext and management users Subject leaking into thread pool of host controller executor.
                 Key: WFLY-2394
                 URL: https://issues.jboss.org/browse/WFLY-2394
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Domain Management, Security
    Affects Versions: 8.0.0.Beta1
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
            Priority: Blocker
             Fix For: 8.0.0.CR1


The JBossThreadFactory in use for the executor service is allowing for the AccessControlContext of the thread submitting the Runnable task to the executor to be associated with the Thread created.

Additional precautions should be taken within the HostController to prevent this association.

Where a Subject does need to be associated this should be handled manually.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 28 14:13:01 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 28 Oct 2013 14:13:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2394) AccessControlContext and
 management users Subject leaking into thread pool of host controller
 executor.
In-Reply-To: <JIRA.12508901.1382983851000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508901.1382983851000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508901.1382983851000.19901.1382983981935@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2394:
-----------------------------------

        Parent: WFLY-490
    Issue Type: Sub-task  (was: Bug)

    
> AccessControlContext and management users Subject leaking into thread pool of host controller executor.
> -------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2394
>                 URL: https://issues.jboss.org/browse/WFLY-2394
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 8.0.0.CR1
>
>
> The JBossThreadFactory in use for the executor service is allowing for the AccessControlContext of the thread submitting the Runnable task to the executor to be associated with the Thread created.
> Additional precautions should be taken within the HostController to prevent this association.
> Where a Subject does need to be associated this should be handled manually.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 28 14:15:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 28 Oct 2013 14:15:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2394) AccessControlContext and
 management users Subject leaking into thread pool of host controller
 executor.
In-Reply-To: <JIRA.12508901.1382983851000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508901.1382983851000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508901.1382983851000.19905.1382984102907@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825335#comment-12825335 ] 

RH Bugzilla Integration commented on WFLY-2394:
-----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> made a comment on [bug 1024072|https://bugzilla.redhat.com/show_bug.cgi?id=1024072]

Description of problem:

Additional steps need to be taken to ensure the correct AccessControlContext association when passing tasks to an Executor within the host controller.
                
> AccessControlContext and management users Subject leaking into thread pool of host controller executor.
> -------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2394
>                 URL: https://issues.jboss.org/browse/WFLY-2394
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 8.0.0.CR1
>
>
> The JBossThreadFactory in use for the executor service is allowing for the AccessControlContext of the thread submitting the Runnable task to the executor to be associated with the Thread created.
> Additional precautions should be taken within the HostController to prevent this association.
> Where a Subject does need to be associated this should be handled manually.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 28 14:15:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 28 Oct 2013 14:15:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2394) AccessControlContext and
 management users Subject leaking into thread pool of host controller
 executor.
In-Reply-To: <JIRA.12508901.1382983851000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508901.1382983851000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508901.1382983851000.19911.1382984103336@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825336#comment-12825336 ] 

RH Bugzilla Integration commented on WFLY-2394:
-----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> changed the Status of [bug 1024072|https://bugzilla.redhat.com/show_bug.cgi?id=1024072] from NEW to ASSIGNED
                
> AccessControlContext and management users Subject leaking into thread pool of host controller executor.
> -------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2394
>                 URL: https://issues.jboss.org/browse/WFLY-2394
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 8.0.0.CR1
>
>
> The JBossThreadFactory in use for the executor service is allowing for the AccessControlContext of the thread submitting the Runnable task to the executor to be associated with the Thread created.
> Additional precautions should be taken within the HostController to prevent this association.
> Where a Subject does need to be associated this should be handled manually.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 28 14:15:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 28 Oct 2013 14:15:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2394) AccessControlContext and
 management users Subject leaking into thread pool of host controller
 executor.
In-Reply-To: <JIRA.12508901.1382983851000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508901.1382983851000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508901.1382983851000.19908.1382984103186@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2394:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1024072

    
> AccessControlContext and management users Subject leaking into thread pool of host controller executor.
> -------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2394
>                 URL: https://issues.jboss.org/browse/WFLY-2394
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 8.0.0.CR1
>
>
> The JBossThreadFactory in use for the executor service is allowing for the AccessControlContext of the thread submitting the Runnable task to the executor to be associated with the Thread created.
> Additional precautions should be taken within the HostController to prevent this association.
> Where a Subject does need to be associated this should be handled manually.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 28 15:04:02 2013
From: jira-events at lists.jboss.org (Junhui Luo (JIRA))
Date: Mon, 28 Oct 2013 15:04:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBAS-6348) Problem with
 QueuedPessimisticEJBLock and Arjuna
In-Reply-To: <JIRA.12374206.1230646865000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12374206.1230646865000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12374206.1230646865000.19960.1382987042161@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBAS-6348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825345#comment-12825345 ] 

Junhui Luo commented on JBAS-6348:
----------------------------------

Is a fix for this bug available for JBoss community edition 4.2.3 GA or must I migrate to JBoss 6.0 or above to get the fix?
                
> Problem with QueuedPessimisticEJBLock and Arjuna
> ------------------------------------------------
>
>                 Key: JBAS-6348
>                 URL: https://issues.jboss.org/browse/JBAS-6348
>             Project: Application Server 3  4  5 and 6
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Transaction Manager Integration (Arjuna)
>    Affects Versions: JBossAS-4.2.3.GA
>            Reporter: husgaard
>            Assignee: Alexey Loubyansky
>             Fix For: 6.0.0.Final
>
>
> When using Arjuna, QueuedPessimisticEJBLock does not always properly detect that a waiting tx has timed out. The problem is that QueuedPessimisticEJBLock was written for the old TM, which did not rollback transactions on timeout, but only marked them for rollback. Now that Arjuna is in play, it has to check for rolled back transactions too.
> The isTxExpired() method should be changed to something like this:
> protected boolean isTxExpired(Transaction miTx) throws Exception {
> 	if (miTx != null
> 			&& (miTx.getStatus() == Status.STATUS_MARKED_ROLLBACK || miTx.getStatus() == Status.STATUS_ROLLEDBACK)) {
> 		return true;
> 	}
> 	return false;
> }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 28 16:34:01 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 28 Oct 2013 16:34:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2394) AccessControlContext and
 management users Subject leaking into thread pool of host controller
 executor.
In-Reply-To: <JIRA.12508901.1382983851000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508901.1382983851000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508901.1382983851000.20134.1382992441960@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825365#comment-12825365 ] 

RH Bugzilla Integration commented on WFLY-2394:
-----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> changed the Status of [bug 1024072|https://bugzilla.redhat.com/show_bug.cgi?id=1024072] from ASSIGNED to POST
                
> AccessControlContext and management users Subject leaking into thread pool of host controller executor.
> -------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2394
>                 URL: https://issues.jboss.org/browse/WFLY-2394
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 8.0.0.CR1
>
>
> The JBossThreadFactory in use for the executor service is allowing for the AccessControlContext of the thread submitting the Runnable task to the executor to be associated with the Thread created.
> Additional precautions should be taken within the HostController to prevent this association.
> Where a Subject does need to be associated this should be handled manually.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 28 16:59:02 2013
From: jira-events at lists.jboss.org (Eduardo Martins (JIRA))
Date: Mon, 28 Oct 2013 16:59:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2164) Read only App,
 Module and Comp Naming Contexts
In-Reply-To: <JIRA.12501609.1380195647000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501609.1380195647000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501609.1380195647000.20148.1382993942083@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Eduardo Martins updated WFLY-2164:
----------------------------------

    Fix Version/s: 8.0.0.CR1

    
> Read only App, Module and Comp Naming Contexts
> ----------------------------------------------
>
>                 Key: WFLY-2164
>                 URL: https://issues.jboss.org/browse/WFLY-2164
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: EE, Naming
>            Reporter: Eduardo Martins
>            Assignee: Eduardo Martins
>             Fix For: 8.0.0.CR1
>
>
> Java EE 7 (and its TCK) mandates that java:app, java:module and java:comp contexts to be read only. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 28 17:03:03 2013
From: jira-events at lists.jboss.org (Eduardo Martins (JIRA))
Date: Mon, 28 Oct 2013 17:03:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2365) DuplicateServiceException
 when deploying ear containing jar and war with same name
In-Reply-To: <JIRA.12508602.1382543911000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508602.1382543911000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508602.1382543911000.20208.1382994183664@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825374#comment-12825374 ] 

Eduardo Martins commented on WFLY-2365:
---------------------------------------

[~asoldano] Can you check if the issue is still valid on master? This issue seems a duplicate of WFLY-2223, which fix was recently merged.
                
> DuplicateServiceException when deploying ear containing jar and war with same name
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-2365
>                 URL: https://issues.jboss.org/browse/WFLY-2365
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EE
>            Reporter: Alessio Soldano
>            Assignee: Eduardo Martins
>             Fix For: 8.0.0.CR1
>
>
> The following exception is thrown when deploying a EAR archive containing a war and jar with the same name (except for the file extension, of course).
> See https://community.jboss.org/thread/233648
>     2013-10-17 10:32:59,266 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.subunit."specj.ear"."specj.jar".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."specj.ear"."specj.jar".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of subdeployment "specj.jar" of deployment "specj.ear"  
>       at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]  
>       at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]  
>       at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]  
>       at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]  
>       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]  
>       at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]  
>     Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.concurrent.ee.context.config.specj.specj is already registered  
>       at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]  
>       at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]  
>       at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:767) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]  
>       at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]  
>       at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2384) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]  
>       at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]  
>       at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2384) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]  
>       at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]  
>       at org.jboss.as.ee.concurrent.deployers.EEConcurrentContextProcessor.setupConcurrentContext(EEConcurrentContextProcessor.java:110)  
>       at org.jboss.as.ee.concurrent.deployers.EEConcurrentContextProcessor.processModuleDescription(EEConcurrentContextProcessor.java:71)  
>       at org.jboss.as.ee.concurrent.deployers.EEConcurrentContextProcessor.deploy(EEConcurrentContextProcessor.java:54)  
>       at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]  
>       ... 5 more  
>       
>       
>     2013-10-17 10:32:59,283 ERROR [org.jboss.as.controller.management-operation] (XNIO-1 task-3) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "specj.ear")]) - failure description: {  
>         "JBAS014671: Failed services" => {"jboss.deployment.subunit.\"specj.ear\".\"specj.jar\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.subunit.\"specj.ear\".\"specj.jar\".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of subdeployment \"specj.jar\" of deployment \"specj.ear\"  
>         Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.concurrent.ee.context.config.specj.specj is already registered"},  
>         "JBAS014771: Services with missing/unavailable dependencies" => ["jboss.deployment.unit.\"specj.ear\".weld.weldClassIntrospector is missing [jboss.deployment.unit.\"specj.ear\".beanmanager]"]  
>     }  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 28 17:09:01 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 28 Oct 2013 17:09:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2336) Decreasing max-threads on a
 unbounded queueless executor generates IllegalArgumentException
In-Reply-To: <JIRA.12508206.1382111218000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508206.1382111218000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508206.1382111218000.20211.1382994541989@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825375#comment-12825375 ] 

RH Bugzilla Integration commented on WFLY-2336:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1021077|https://bugzilla.redhat.com/show_bug.cgi?id=1021077] from POST to MODIFIED
                
> Decreasing max-threads on a unbounded queueless executor generates IllegalArgumentException
> -------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2336
>                 URL: https://issues.jboss.org/browse/WFLY-2336
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Aaron Ogburn
>            Priority: Minor
>             Fix For: 8.0.0.CR1
>
>
> Create an unbounded queueless executor
> <unbounded-queue-thread-pool name="uq-thread-pool">
> <max-threads count="350"/>
> <keepalive-time time="5" unit="minutes"/>
> </unbounded-queue-thread-pool>
> Modifying max-threads fails:
> /subsystem=threads/unbounded-queue-thread-pool=uq-thread-pool:write-attribute(name=max-threads,value=300)
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014749: Operation handler failed: null",
>     "rolled-back" => true
> }
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) JBAS014612: Operation ("write-attribute") failed - address: ([
>     ("subsystem" => "threads"),
>     ("unbounded-queue-thread-pool" => "uq-thread-pool")
> ]): java.lang.IllegalArgumentException
> 	at java.util.concurrent.ThreadPoolExecutor.setMaximumPoolSize(ThreadPoolExecutor.java:1620) [rt.jar:1.7.0]
> 	at org.jboss.threads.JBossThreadPoolExecutor.setMaxThreads(JBossThreadPoolExecutor.java:95) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> 	at org.jboss.as.threads.ManagedJBossThreadPoolExecutorService.setMaxThreads(ManagedJBossThreadPoolExecutorService.java:86)
> 	at org.jboss.as.threads.UnboundedQueueThreadPoolService.setMaxThreads(UnboundedQueueThreadPoolService.java:91)
> The core pool size needs to be adjusted in line with the max pool size and in the right order to avoid that since max threads can't be less than core threads.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 28 17:09:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 28 Oct 2013 17:09:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2336) Decreasing max-threads on a
 unbounded queueless executor generates IllegalArgumentException
In-Reply-To: <JIRA.12508206.1382111218000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508206.1382111218000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508206.1382111218000.20213.1382994542083@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825376#comment-12825376 ] 

RH Bugzilla Integration commented on WFLY-2336:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> made a comment on [bug 1021077|https://bugzilla.redhat.com/show_bug.cgi?id=1021077]

I don't know who the QE contact should, be, but as it was acked, it's now merged.
                
> Decreasing max-threads on a unbounded queueless executor generates IllegalArgumentException
> -------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2336
>                 URL: https://issues.jboss.org/browse/WFLY-2336
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Aaron Ogburn
>            Priority: Minor
>             Fix For: 8.0.0.CR1
>
>
> Create an unbounded queueless executor
> <unbounded-queue-thread-pool name="uq-thread-pool">
> <max-threads count="350"/>
> <keepalive-time time="5" unit="minutes"/>
> </unbounded-queue-thread-pool>
> Modifying max-threads fails:
> /subsystem=threads/unbounded-queue-thread-pool=uq-thread-pool:write-attribute(name=max-threads,value=300)
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014749: Operation handler failed: null",
>     "rolled-back" => true
> }
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) JBAS014612: Operation ("write-attribute") failed - address: ([
>     ("subsystem" => "threads"),
>     ("unbounded-queue-thread-pool" => "uq-thread-pool")
> ]): java.lang.IllegalArgumentException
> 	at java.util.concurrent.ThreadPoolExecutor.setMaximumPoolSize(ThreadPoolExecutor.java:1620) [rt.jar:1.7.0]
> 	at org.jboss.threads.JBossThreadPoolExecutor.setMaxThreads(JBossThreadPoolExecutor.java:95) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> 	at org.jboss.as.threads.ManagedJBossThreadPoolExecutorService.setMaxThreads(ManagedJBossThreadPoolExecutorService.java:86)
> 	at org.jboss.as.threads.UnboundedQueueThreadPoolService.setMaxThreads(UnboundedQueueThreadPoolService.java:91)
> The core pool size needs to be adjusted in line with the max pool size and in the right order to avoid that since max threads can't be less than core threads.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 28 17:11:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 28 Oct 2013 17:11:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2320) EJB should not be remotely
 accessible until all of its dependencies have been started
In-Reply-To: <JIRA.12503266.1381935962000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503266.1381935962000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503266.1381935962000.20219.1382994662114@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825377#comment-12825377 ] 

RH Bugzilla Integration commented on WFLY-2320:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1019894|https://bugzilla.redhat.com/show_bug.cgi?id=1019894] from POST to MODIFIED
                
> EJB should not be remotely accessible until all of its dependencies have been started
> -------------------------------------------------------------------------------------
>
>                 Key: WFLY-2320
>                 URL: https://issues.jboss.org/browse/WFLY-2320
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Brad Maxwell
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.CR1
>
>
> If an EJB injects or depends on a resource such as an @Singleton which has not been started, the EJB's remote interface java:jboss/exported/* is already bound and this allows remote EJB clients to try to invoke it.  This causes the EJB clients to hang because the EJB will not be started until its dependencies have been started.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 28 18:25:01 2013
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Mon, 28 Oct 2013 18:25:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2395)
 RootSubsystemOperationsTestCase fails if log directory wasn't properly
 cleaned
In-Reply-To: <JIRA.12508911.1382999078875@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508911.1382999078875@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508911.1382999078875.20246.1382999101891@jira02.app.mwc.hst.phx2.redhat.com>

James Perkins created WFLY-2395:
-----------------------------------

             Summary: RootSubsystemOperationsTestCase fails if log directory wasn't properly cleaned
                 Key: WFLY-2395
                 URL: https://issues.jboss.org/browse/WFLY-2395
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Logging
            Reporter: James Perkins
            Assignee: James Perkins
             Fix For: 8.0.0.CR1


Some test appears to not be cleaning up the {{target/logs}} directory which causes the tests to fail. While tests should be cleaning up after themselves, the test in the {{RootSubsystemOperationsTestCase}} should also not look for empty directories, but look for the files that _shouldn't_ be there.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 28 18:45:02 2013
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Mon, 28 Oct 2013 18:45:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2395)
 RootSubsystemOperationsTestCase fails if log directory wasn't properly
 cleaned
In-Reply-To: <JIRA.12508911.1382999078000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508911.1382999078000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508911.1382999078000.20276.1383000302431@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins updated WFLY-2395:
--------------------------------

    Description: 
Some test appears to not be cleaning up the {{target/logs}} directory which causes the tests to fail. While tests should be cleaning up after themselves, the test in the {{RootSubsystemOperationsTestCase}} should also not look for empty directories, but look for the files that _shouldn't_ be there.

Files left  behind:
{code}
[root at build01 logging]# ls -l target/logs/
total 0
-rw-r--r-- 1 root root 0 Oct 28 23:00 another.log
-rw-r--r-- 1 root root 0 Oct 28 23:00 anotherProfile.log
-rw-r--r-- 1 root root 0 Oct 28 23:00 fileHandler.log
-rw-r--r-- 1 root root 0 Oct 28 23:00 profileFileHandler.log
-rw-r--r-- 1 root root 0 Oct 28 23:00 server.log
-rw-r--r-- 1 root root 0 Oct 28 23:00 sizeLogger.log
{code}

  was:Some test appears to not be cleaning up the {{target/logs}} directory which causes the tests to fail. While tests should be cleaning up after themselves, the test in the {{RootSubsystemOperationsTestCase}} should also not look for empty directories, but look for the files that _shouldn't_ be there.


    
> RootSubsystemOperationsTestCase fails if log directory wasn't properly cleaned
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-2395
>                 URL: https://issues.jboss.org/browse/WFLY-2395
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 8.0.0.CR1
>
>
> Some test appears to not be cleaning up the {{target/logs}} directory which causes the tests to fail. While tests should be cleaning up after themselves, the test in the {{RootSubsystemOperationsTestCase}} should also not look for empty directories, but look for the files that _shouldn't_ be there.
> Files left  behind:
> {code}
> [root at build01 logging]# ls -l target/logs/
> total 0
> -rw-r--r-- 1 root root 0 Oct 28 23:00 another.log
> -rw-r--r-- 1 root root 0 Oct 28 23:00 anotherProfile.log
> -rw-r--r-- 1 root root 0 Oct 28 23:00 fileHandler.log
> -rw-r--r-- 1 root root 0 Oct 28 23:00 profileFileHandler.log
> -rw-r--r-- 1 root root 0 Oct 28 23:00 server.log
> -rw-r--r-- 1 root root 0 Oct 28 23:00 sizeLogger.log
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 28 19:24:02 2013
From: jira-events at lists.jboss.org (Divya Mehra (JIRA))
Date: Mon, 28 Oct 2013 19:24:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1716) Regression between 3.2.x and
 3.3.x/3.4.x in Infinispan read simulation
In-Reply-To: <JIRA.12503100.1381850347000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503100.1381850347000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503100.1381850347000.20352.1383002642118@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Divya Mehra updated JGRP-1716:
------------------------------

    Labels: jdg620_dm  (was: )

    
> Regression between 3.2.x and 3.3.x/3.4.x in Infinispan read simulation
> ----------------------------------------------------------------------
>
>                 Key: JGRP-1716
>                 URL: https://issues.jboss.org/browse/JGRP-1716
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.3, 3.4
>            Reporter: Dan Berindei
>            Assignee: Bela Ban
>              Labels: jdg620_dm
>             Fix For: 3.4.1, 3.5
>
>         Attachments: benchmark-jgroups.xml, jgroups-udp.pdf, jgroups-udp.xml
>
>
> Comparing JGroups 3.2/3.3/3.4 performance with Radargun, the throughput of reads in scenario simulating Infinispan went down by ~10%. See the attached chart.
> * getall: the get request is sent to single node (randomly picked owner)
> * getfirst: the get requests are sent to 2 nodes with ResponseMode.GET_FIRST - the second response is discarded.
> .h5 Suspects:
> Erik Salter profiled his application and noticed that the message parsing in the UDP receiver thread seemed to slow things down. He wrote a patch that brought his throughput back to 3.2 levels: https://github.com/an1310/JGroups/compare/t_perfhack
> The UDP receiver thread may not tell the whole story, however: in the Radargun tests, performance with his patch was even lower.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 28 19:24:02 2013
From: jira-events at lists.jboss.org (Divya Mehra (JIRA))
Date: Mon, 28 Oct 2013 19:24:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1487) AUTH: X509Token
 Authentication is vulnerable to replay attacks
In-Reply-To: <JIRA.12469666.1340962910000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12469666.1340962910000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12469666.1340962910000.20359.1383002642421@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Divya Mehra updated JGRP-1487:
------------------------------

    Labels: jdg620_dm  (was: )

    
> AUTH: X509Token Authentication is vulnerable to replay attacks
> --------------------------------------------------------------
>
>                 Key: JGRP-1487
>                 URL: https://issues.jboss.org/browse/JGRP-1487
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.0.9
>            Reporter: sreenivas chinimilli
>            Assignee: Bela Ban
>              Labels: jdg620_dm
>             Fix For: 3.5
>
>
> In the implementation of X509Token Authentication
> The auth_value is enrypted with the certificate within the keystore and
> during verification encrypted auth value is decrypted with the private key
> compared against the orignial auth value.
> This implementation is prone to replay attacks, that is
> any user with out having any knowledge of the auth value can join the group
> by replaying the enrypted auth value captured in earlier sessions.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 28 19:37:02 2013
From: jira-events at lists.jboss.org (Divya Mehra (JIRA))
Date: Mon, 28 Oct 2013 19:37:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1721) AUTH and ENCRYPT protocols
 configured with plain text passwords
In-Reply-To: <JIRA.12508425.1382426440000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508425.1382426440000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508425.1382426440000.20382.1383003422202@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Divya Mehra updated JGRP-1721:
------------------------------

    Labels: jdg620_dm  (was: )

    
> AUTH and ENCRYPT protocols configured with plain text passwords
> ---------------------------------------------------------------
>
>                 Key: JGRP-1721
>                 URL: https://issues.jboss.org/browse/JGRP-1721
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Martin Gencur
>            Assignee: Bela Ban
>              Labels: jdg620_dm
>             Fix For: 3.5
>
>
> The following parameters of AUTH protocol are stored as plain text:
> * keystore_password
> The following parameters of ENCRYPT protocol are stored as plain text:
> * store_password
> * key_password
> Example:
> {code}
> <ENCRYPT key_store_name="defaultStore.keystore" store_password="changeit" alias="myKey"/>
> {code}
> Requirements for storing passwords: https://docspace.corp.redhat.com/docs/DOC-131628

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 28 19:39:01 2013
From: jira-events at lists.jboss.org (Divya Mehra (JIRA))
Date: Mon, 28 Oct 2013 19:39:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1722) Improve performance of
	ENCRYPT protocol
In-Reply-To: <JIRA.12508426.1382426974000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508426.1382426974000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508426.1382426974000.20385.1383003541951@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Divya Mehra updated JGRP-1722:
------------------------------

    Labels: jdg620_dm  (was: )

    
> Improve performance of ENCRYPT protocol
> ---------------------------------------
>
>                 Key: JGRP-1722
>                 URL: https://issues.jboss.org/browse/JGRP-1722
>             Project: JGroups
>          Issue Type: Enhancement
>    Affects Versions: 3.4
>            Reporter: Martin Gencur
>            Assignee: Bela Ban
>              Labels: jdg620_dm
>             Fix For: 3.5
>
>
> A stress tests with the following setup showed that performance (reads and writes/sec) is halved when ENCRYPT protocol is enabled:
> Infinispan had distributed sync cache with 2 owners on 4 nodes, no transactions. The stress test used 10 threads on each node accessing 1024 byte entries, no conflicts on keys, 20 % writes, 80 % reads. 
> It would be great if we could improve the performance of ENCRYPT protocol.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 28 22:08:01 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 28 Oct 2013 22:08:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2198) Remote Naming throws the same
 exception for different causes
In-Reply-To: <JIRA.12501957.1380669681000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501957.1380669681000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501957.1380669681000.20440.1383012481997@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825397#comment-12825397 ] 

RH Bugzilla Integration commented on WFLY-2198:
-----------------------------------------------

Brad Maxwell <bmaxwell at redhat.com> changed the Status of [bug 1014414|https://bugzilla.redhat.com/show_bug.cgi?id=1014414] from NEW to POST
                
> Remote Naming throws the same exception for different causes
> ------------------------------------------------------------
>
>                 Key: WFLY-2198
>                 URL: https://issues.jboss.org/browse/WFLY-2198
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming
>            Reporter: Brad Maxwell
>            Assignee: Brad Maxwell
>
> A generic NamingException are thrown if all of the servers specified are unreachable as well as if the user/pass are invalid and a security exception is thrown up, they both are converted into a RuntimeException and a message listing the servers it was unable to call is reported.
> We should be throwing a different exception in the cases we know the cause, such as connection timeout or authentication exception. 
> If all the the servers specified are not not running:
> --------------------------------------------------------------------------------------------
> javax.naming.NamingException: Failed to connect to any server. Servers tried: [remote://localhost:4447]
>   at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:213)
> If one of the servers is running, but the client's username/password are incorrect
> --------------------------------------------------------------------------------------------
> javax.naming.NamingException: Failed to connect to any server. Servers tried: [remote://localhost:4447]
>   at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:213)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Oct 28 23:27:01 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 28 Oct 2013 23:27:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2394) AccessControlContext and
 management users Subject leaking into thread pool of host controller
 executor.
In-Reply-To: <JIRA.12508901.1382983851000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508901.1382983851000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508901.1382983851000.20448.1383017221955@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825400#comment-12825400 ] 

RH Bugzilla Integration commented on WFLY-2394:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1024072|https://bugzilla.redhat.com/show_bug.cgi?id=1024072] from POST to MODIFIED
                
> AccessControlContext and management users Subject leaking into thread pool of host controller executor.
> -------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2394
>                 URL: https://issues.jboss.org/browse/WFLY-2394
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 8.0.0.CR1
>
>
> The JBossThreadFactory in use for the executor service is allowing for the AccessControlContext of the thread submitting the Runnable task to the executor to be associated with the Thread created.
> Additional precautions should be taken within the HostController to prevent this association.
> Where a Subject does need to be associated this should be handled manually.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 00:10:02 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Tue, 29 Oct 2013 00:10:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2396) MessagingSubsystem20TestCase
	keeps failing
In-Reply-To: <JIRA.12508917.1383019754117@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508917.1383019754117@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508917.1383019754117.20454.1383019802526@jira02.app.mwc.hst.phx2.redhat.com>

Jesper Pedersen created WFLY-2396:
-------------------------------------

             Summary: MessagingSubsystem20TestCase keeps failing
                 Key: WFLY-2396
                 URL: https://issues.jboss.org/browse/WFLY-2396
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JMS, Test Suite
    Affects Versions: 8.0.0.CR1
            Reporter: Jesper Pedersen
            Assignee: Jeff Mesnil


Current master (2013/10/29) - commit f68fb13c12bdf756c29f56e696edc8549b0279bd

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 00:12:01 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Tue, 29 Oct 2013 00:12:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2396) MessagingSubsystem20TestCase
	keeps failing
In-Reply-To: <JIRA.12508917.1383019754000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508917.1383019754000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508917.1383019754000.20457.1383019921945@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated WFLY-2396:
----------------------------------

    Attachment: org.jboss.as.messaging.test.MessagingSubsystem20TestCase.txt

    
> MessagingSubsystem20TestCase keeps failing
> ------------------------------------------
>
>                 Key: WFLY-2396
>                 URL: https://issues.jboss.org/browse/WFLY-2396
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS, Test Suite
>    Affects Versions: 8.0.0.CR1
>            Reporter: Jesper Pedersen
>            Assignee: Jeff Mesnil
>         Attachments: org.jboss.as.messaging.test.MessagingSubsystem20TestCase.txt
>
>
> Current master (2013/10/29) - commit f68fb13c12bdf756c29f56e696edc8549b0279bd

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 00:14:03 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Tue, 29 Oct 2013 00:14:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2396) MessagingSubsystem20TestCase
	keeps failing
In-Reply-To: <JIRA.12508917.1383019754000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508917.1383019754000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508917.1383019754000.20461.1383020043130@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825402#comment-12825402 ] 

Jesper Pedersen commented on WFLY-2396:
---------------------------------------

Ignoring the test case - https://github.com/wildfly/wildfly/pull/5368
                
> MessagingSubsystem20TestCase keeps failing
> ------------------------------------------
>
>                 Key: WFLY-2396
>                 URL: https://issues.jboss.org/browse/WFLY-2396
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS, Test Suite
>    Affects Versions: 8.0.0.CR1
>            Reporter: Jesper Pedersen
>            Assignee: Jeff Mesnil
>         Attachments: org.jboss.as.messaging.test.MessagingSubsystem20TestCase.txt
>
>
> Current master (2013/10/29) - commit f68fb13c12bdf756c29f56e696edc8549b0279bd

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 02:10:02 2013
From: jira-events at lists.jboss.org (Chris R. (JIRA))
Date: Tue, 29 Oct 2013 02:10:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2391) Wildfly caches content in
 exploded mode, breaking developer productivity
In-Reply-To: <JIRA.12508879.1382966687000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508879.1382966687000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508879.1382966687000.20485.1383027002360@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825405#comment-12825405 ] 

Chris R. commented on WFLY-2391:
--------------------------------

I reproduced this issue with Wildfly Beta1. Pleace notice:

The problem still appeared after I removed the tmp folder from wildfly.
I can't debug my EJB's, even though the handshake has been successful. Debug mode just won't let me access my EJB code...
I'll try to reinstall Wildfly Beta1

https://community.jboss.org/thread/233965



                
> Wildfly caches content in exploded mode, breaking developer productivity
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2391
>                 URL: https://issues.jboss.org/browse/WFLY-2391
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>         Environment: MacOSX with JBossTools 4.1.1.Beta1
>            Reporter: Xavier Coulon
>         Attachments: jboss-as-kitchensink-html5-mobile.war.zip
>
>
> While I was building a sample application with JBoss Tools 4.1.1.beta1 on WildFly 8.0.Beta1, I noticed that after a few minutes (or a few browser requests), the content of my index.html file seemed to be cached by the server, although I used the "exploded content" deployment mode (since I published the content using the WildFly Server Adapter in JBoss Tools).
>  
> I checked the actual content of the index.html in the deployments folder and it contained the latest changes, which means that the JBoss Tools Server Adapter is doing its job well ;-)
> I also tried to edit the index.html file directly in the deployments folder, and once again, I got no update in both Chrome and Firefox browsers.
>  
> I checked in the "Network" tab of the browsers and could see that the server response for the index.html page had a "200 OK" status, which means that there's no browser caching involved.
> I tried to get the index.html page with cUrl and got the same old version, which definitely excludes a browser caching issue.
> At the end of the dat, this means that after a few changes, my browsers keep getting an old version of the deployed resources, which in turns means that I have to stop and restart the server to get the new content, and this is pretty bad in term of dev productivity.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 02:12:01 2013
From: jira-events at lists.jboss.org (Chris R. (JIRA))
Date: Tue, 29 Oct 2013 02:12:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2391) Wildfly caches content in
 exploded mode, breaking developer productivity
In-Reply-To: <JIRA.12508879.1382966687000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508879.1382966687000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508879.1382966687000.20489.1383027121992@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825405#comment-12825405 ] 

Chris R. edited comment on WFLY-2391 at 10/29/13 2:10 AM:
----------------------------------------------------------

I reproduced this issue with Wildfly Beta1. Pleace notice:

I deployed a simple WAR file containing a Spring project and JSP's.
The problem still appeared after I removed the tmp folder from wildfly.
I can't debug my EJB's, even though the handshake has been successful. Debug mode just won't let me access my EJB code...
I'll try to reinstall Wildfly Beta1

https://community.jboss.org/thread/233965



                
      was (Author: goot):
    I reproduced this issue with Wildfly Beta1. Pleace notice:

The problem still appeared after I removed the tmp folder from wildfly.
I can't debug my EJB's, even though the handshake has been successful. Debug mode just won't let me access my EJB code...
I'll try to reinstall Wildfly Beta1

https://community.jboss.org/thread/233965



                  
> Wildfly caches content in exploded mode, breaking developer productivity
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2391
>                 URL: https://issues.jboss.org/browse/WFLY-2391
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>         Environment: MacOSX with JBossTools 4.1.1.Beta1
>            Reporter: Xavier Coulon
>         Attachments: jboss-as-kitchensink-html5-mobile.war.zip
>
>
> While I was building a sample application with JBoss Tools 4.1.1.beta1 on WildFly 8.0.Beta1, I noticed that after a few minutes (or a few browser requests), the content of my index.html file seemed to be cached by the server, although I used the "exploded content" deployment mode (since I published the content using the WildFly Server Adapter in JBoss Tools).
>  
> I checked the actual content of the index.html in the deployments folder and it contained the latest changes, which means that the JBoss Tools Server Adapter is doing its job well ;-)
> I also tried to edit the index.html file directly in the deployments folder, and once again, I got no update in both Chrome and Firefox browsers.
>  
> I checked in the "Network" tab of the browsers and could see that the server response for the index.html page had a "200 OK" status, which means that there's no browser caching involved.
> I tried to get the index.html page with cUrl and got the same old version, which definitely excludes a browser caching issue.
> At the end of the dat, this means that after a few changes, my browsers keep getting an old version of the deployed resources, which in turns means that I have to stop and restart the server to get the new content, and this is pretty bad in term of dev productivity.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 03:13:01 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Tue, 29 Oct 2013 03:13:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2397) When using weld resource
 injection happens twice
In-Reply-To: <JIRA.12508920.1383030661450@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508920.1383030661450@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508920.1383030661450.20543.1383030781966@jira02.app.mwc.hst.phx2.redhat.com>

Stuart Douglas created WFLY-2397:
------------------------------------

             Summary: When using weld resource injection happens twice
                 Key: WFLY-2397
                 URL: https://issues.jboss.org/browse/WFLY-2397
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: CDI / Weld
    Affects Versions: 8.0.0.Beta1
            Reporter: Stuart Douglas
            Assignee: Stuart Douglas


When using CDI to inject non-EJB components such as Servlets it appears both Weld and WF are performing resource injections.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 03:44:01 2013
From: jira-events at lists.jboss.org (Frank Langelage (JIRA))
Date: Tue, 29 Oct 2013 03:44:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2398)
 org.jboss.as.test.smoke.deployment.rar.tests.inflow.InflowTestCase fails
In-Reply-To: <JIRA.12508921.1383032569756@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508921.1383032569756@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508921.1383032569756.20549.1383032641987@jira02.app.mwc.hst.phx2.redhat.com>

Frank Langelage created WFLY-2398:
-------------------------------------

             Summary: org.jboss.as.test.smoke.deployment.rar.tests.inflow.InflowTestCase fails
                 Key: WFLY-2398
                 URL: https://issues.jboss.org/browse/WFLY-2398
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JCA, Test Suite
    Affects Versions: 8.0.0.Beta1
         Environment: Solaris SPARC 10, Oracle Java 1.7.0_45
            Reporter: Frank Langelage
            Assignee: Jesper Pedersen
         Attachments: org.jboss.as.test.smoke.deployment.rar.tests.inflow.InflowTestCase-output.txt, org.jboss.as.test.smoke.deployment.rar.tests.inflow.InflowTestCase.txt

Running a source build with complete testsuite this test is failing with
testRegistryConfiguration(org.jboss.as.test.smoke.deployment.rar.tests.inflow.InflowTestCase): expected:<1> but was:<2>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 03:44:02 2013
From: jira-events at lists.jboss.org (Frank Langelage (JIRA))
Date: Tue, 29 Oct 2013 03:44:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2398)
 org.jboss.as.test.smoke.deployment.rar.tests.inflow.InflowTestCase fails
In-Reply-To: <JIRA.12508921.1383032569000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508921.1383032569000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508921.1383032569000.20552.1383032642100@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Frank Langelage updated WFLY-2398:
----------------------------------

    Attachment: org.jboss.as.test.smoke.deployment.rar.tests.inflow.InflowTestCase.txt
                org.jboss.as.test.smoke.deployment.rar.tests.inflow.InflowTestCase-output.txt

    
> org.jboss.as.test.smoke.deployment.rar.tests.inflow.InflowTestCase fails
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2398
>                 URL: https://issues.jboss.org/browse/WFLY-2398
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA, Test Suite
>    Affects Versions: 8.0.0.Beta1
>         Environment: Solaris SPARC 10, Oracle Java 1.7.0_45
>            Reporter: Frank Langelage
>            Assignee: Jesper Pedersen
>         Attachments: org.jboss.as.test.smoke.deployment.rar.tests.inflow.InflowTestCase-output.txt, org.jboss.as.test.smoke.deployment.rar.tests.inflow.InflowTestCase.txt
>
>
> Running a source build with complete testsuite this test is failing with
> testRegistryConfiguration(org.jboss.as.test.smoke.deployment.rar.tests.inflow.InflowTestCase): expected:<1> but was:<2>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 03:46:02 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Tue, 29 Oct 2013 03:46:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2398)
 org.jboss.as.test.smoke.deployment.rar.tests.inflow.InflowTestCase fails
In-Reply-To: <JIRA.12508921.1383032569000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508921.1383032569000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508921.1383032569000.20556.1383032762745@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen reassigned WFLY-2398:
-------------------------------------

    Assignee: Stefano Maestri  (was: Jesper Pedersen)

    
> org.jboss.as.test.smoke.deployment.rar.tests.inflow.InflowTestCase fails
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2398
>                 URL: https://issues.jboss.org/browse/WFLY-2398
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA, Test Suite
>    Affects Versions: 8.0.0.Beta1
>         Environment: Solaris SPARC 10, Oracle Java 1.7.0_45
>            Reporter: Frank Langelage
>            Assignee: Stefano Maestri
>         Attachments: org.jboss.as.test.smoke.deployment.rar.tests.inflow.InflowTestCase-output.txt, org.jboss.as.test.smoke.deployment.rar.tests.inflow.InflowTestCase.txt
>
>
> Running a source build with complete testsuite this test is failing with
> testRegistryConfiguration(org.jboss.as.test.smoke.deployment.rar.tests.inflow.InflowTestCase): expected:<1> but was:<2>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 03:46:02 2013
From: jira-events at lists.jboss.org (Frank Langelage (JIRA))
Date: Tue, 29 Oct 2013 03:46:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2399)
 org.jboss.as.test.smoke.deployment.rar.tests.pure.PureTestCase fails
In-Reply-To: <JIRA.12508922.1383032710789@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508922.1383032710789@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508922.1383032710789.20558.1383032762876@jira02.app.mwc.hst.phx2.redhat.com>

Frank Langelage created WFLY-2399:
-------------------------------------

             Summary: org.jboss.as.test.smoke.deployment.rar.tests.pure.PureTestCase fails
                 Key: WFLY-2399
                 URL: https://issues.jboss.org/browse/WFLY-2399
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JCA, Test Suite
    Affects Versions: 8.0.0.Beta1
         Environment: Solaris SPARC 10, Oracle Java 1.7.0_45
            Reporter: Frank Langelage
            Assignee: Stefano Maestri


Running a source build with complete testsuite this test is failing with
testRegistryConfiguration(org.jboss.as.test.smoke.deployment.rar.tests.inflow.InflowTestCase): expected:<1> but was:<2>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 03:48:02 2013
From: jira-events at lists.jboss.org (Frank Langelage (JIRA))
Date: Tue, 29 Oct 2013 03:48:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2399)
 org.jboss.as.test.smoke.deployment.rar.tests.pure.PureTestCase fails
In-Reply-To: <JIRA.12508922.1383032710000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508922.1383032710000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508922.1383032710000.20569.1383032882204@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Frank Langelage updated WFLY-2399:
----------------------------------

    Description: 
Running a source build with complete testsuite this test is failing with
testRegistryConfiguration(org.jboss.as.test.smoke.deployment.rar.tests.pure.PureTestCase): expected:<1> but was:<2>



  was:
Running a source build with complete testsuite this test is failing with
testRegistryConfiguration(org.jboss.as.test.smoke.deployment.rar.tests.inflow.InflowTestCase): expected:<1> but was:<2>



    
> org.jboss.as.test.smoke.deployment.rar.tests.pure.PureTestCase fails
> --------------------------------------------------------------------
>
>                 Key: WFLY-2399
>                 URL: https://issues.jboss.org/browse/WFLY-2399
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA, Test Suite
>    Affects Versions: 8.0.0.Beta1
>         Environment: Solaris SPARC 10, Oracle Java 1.7.0_45
>            Reporter: Frank Langelage
>            Assignee: Stefano Maestri
>         Attachments: org.jboss.as.test.smoke.deployment.rar.tests.pure.PureTestCase-output.txt, org.jboss.as.test.smoke.deployment.rar.tests.pure.PureTestCase.txt
>
>
> Running a source build with complete testsuite this test is failing with
> testRegistryConfiguration(org.jboss.as.test.smoke.deployment.rar.tests.pure.PureTestCase): expected:<1> but was:<2>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 03:48:02 2013
From: jira-events at lists.jboss.org (Frank Langelage (JIRA))
Date: Tue, 29 Oct 2013 03:48:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2399)
 org.jboss.as.test.smoke.deployment.rar.tests.pure.PureTestCase fails
In-Reply-To: <JIRA.12508922.1383032710000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508922.1383032710000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508922.1383032710000.20574.1383032882411@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Frank Langelage updated WFLY-2399:
----------------------------------

    Attachment: org.jboss.as.test.smoke.deployment.rar.tests.pure.PureTestCase.txt
                org.jboss.as.test.smoke.deployment.rar.tests.pure.PureTestCase-output.txt

    
> org.jboss.as.test.smoke.deployment.rar.tests.pure.PureTestCase fails
> --------------------------------------------------------------------
>
>                 Key: WFLY-2399
>                 URL: https://issues.jboss.org/browse/WFLY-2399
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA, Test Suite
>    Affects Versions: 8.0.0.Beta1
>         Environment: Solaris SPARC 10, Oracle Java 1.7.0_45
>            Reporter: Frank Langelage
>            Assignee: Stefano Maestri
>         Attachments: org.jboss.as.test.smoke.deployment.rar.tests.pure.PureTestCase-output.txt, org.jboss.as.test.smoke.deployment.rar.tests.pure.PureTestCase.txt
>
>
> Running a source build with complete testsuite this test is failing with
> testRegistryConfiguration(org.jboss.as.test.smoke.deployment.rar.tests.pure.PureTestCase): expected:<1> but was:<2>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 03:50:02 2013
From: jira-events at lists.jboss.org (Frank Langelage (JIRA))
Date: Tue, 29 Oct 2013 03:50:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2398)
 org.jboss.as.test.smoke.deployment.rar.tests.inflow.InflowTestCase fails
In-Reply-To: <JIRA.12508921.1383032569000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508921.1383032569000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508921.1383032569000.20580.1383033002062@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Frank Langelage updated WFLY-2398:
----------------------------------

    Description: 
Running a build of current sources with complete testsuite this test is failing with
testRegistryConfiguration(org.jboss.as.test.smoke.deployment.rar.tests.inflow.InflowTestCase): expected:<1> but was:<2>


  was:
Running a source build with complete testsuite this test is failing with
testRegistryConfiguration(org.jboss.as.test.smoke.deployment.rar.tests.inflow.InflowTestCase): expected:<1> but was:<2>



    
> org.jboss.as.test.smoke.deployment.rar.tests.inflow.InflowTestCase fails
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2398
>                 URL: https://issues.jboss.org/browse/WFLY-2398
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA, Test Suite
>    Affects Versions: 8.0.0.Beta1
>         Environment: Solaris SPARC 10, Oracle Java 1.7.0_45
>            Reporter: Frank Langelage
>            Assignee: Stefano Maestri
>         Attachments: org.jboss.as.test.smoke.deployment.rar.tests.inflow.InflowTestCase-output.txt, org.jboss.as.test.smoke.deployment.rar.tests.inflow.InflowTestCase.txt
>
>
> Running a build of current sources with complete testsuite this test is failing with
> testRegistryConfiguration(org.jboss.as.test.smoke.deployment.rar.tests.inflow.InflowTestCase): expected:<1> but was:<2>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 03:50:01 2013
From: jira-events at lists.jboss.org (Frank Langelage (JIRA))
Date: Tue, 29 Oct 2013 03:50:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2399)
 org.jboss.as.test.smoke.deployment.rar.tests.pure.PureTestCase fails
In-Reply-To: <JIRA.12508922.1383032710000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508922.1383032710000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508922.1383032710000.20578.1383033001977@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Frank Langelage updated WFLY-2399:
----------------------------------

    Description: 
Running a build of current sources with complete testsuite this test is failing with
testRegistryConfiguration(org.jboss.as.test.smoke.deployment.rar.tests.pure.PureTestCase): expected:<1> but was:<2>



  was:
Running a source build with complete testsuite this test is failing with
testRegistryConfiguration(org.jboss.as.test.smoke.deployment.rar.tests.pure.PureTestCase): expected:<1> but was:<2>




    
> org.jboss.as.test.smoke.deployment.rar.tests.pure.PureTestCase fails
> --------------------------------------------------------------------
>
>                 Key: WFLY-2399
>                 URL: https://issues.jboss.org/browse/WFLY-2399
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA, Test Suite
>    Affects Versions: 8.0.0.Beta1
>         Environment: Solaris SPARC 10, Oracle Java 1.7.0_45
>            Reporter: Frank Langelage
>            Assignee: Stefano Maestri
>         Attachments: org.jboss.as.test.smoke.deployment.rar.tests.pure.PureTestCase-output.txt, org.jboss.as.test.smoke.deployment.rar.tests.pure.PureTestCase.txt
>
>
> Running a build of current sources with complete testsuite this test is failing with
> testRegistryConfiguration(org.jboss.as.test.smoke.deployment.rar.tests.pure.PureTestCase): expected:<1> but was:<2>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 03:52:02 2013
From: jira-events at lists.jboss.org (Frank Langelage (JIRA))
Date: Tue, 29 Oct 2013 03:52:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2400)
 org.jboss.as.test.smoke.mgmt.servermodule.ValidateModelTestCase fails
In-Reply-To: <JIRA.12508923.1383033028663@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508923.1383033028663@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508923.1383033028663.20584.1383033122042@jira02.app.mwc.hst.phx2.redhat.com>

Frank Langelage created WFLY-2400:
-------------------------------------

             Summary: org.jboss.as.test.smoke.mgmt.servermodule.ValidateModelTestCase fails
                 Key: WFLY-2400
                 URL: https://issues.jboss.org/browse/WFLY-2400
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JCA, Test Suite
    Affects Versions: 8.0.0.Beta1
         Environment: Solaris SPARC 10, Oracle Java 1.7.0_45
            Reporter: Frank Langelage
            Assignee: Stefano Maestri


Running a build of current sources with complete testsuite this test is failing with
testRegistryConfiguration(org.jboss.as.test.smoke.deployment.rar.tests.inflow.InflowTestCase): expected:<1> but was:<2>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 03:52:02 2013
From: jira-events at lists.jboss.org (Frank Langelage (JIRA))
Date: Tue, 29 Oct 2013 03:52:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2400)
 org.jboss.as.test.smoke.mgmt.servermodule.ValidateModelTestCase fails
In-Reply-To: <JIRA.12508923.1383033028000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508923.1383033028000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508923.1383033028000.20587.1383033122187@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Frank Langelage updated WFLY-2400:
----------------------------------

    Component/s: Server
                     (was: JCA)

    
> org.jboss.as.test.smoke.mgmt.servermodule.ValidateModelTestCase fails
> ---------------------------------------------------------------------
>
>                 Key: WFLY-2400
>                 URL: https://issues.jboss.org/browse/WFLY-2400
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server, Test Suite
>    Affects Versions: 8.0.0.Beta1
>         Environment: Solaris SPARC 10, Oracle Java 1.7.0_45
>            Reporter: Frank Langelage
>            Assignee: Stefano Maestri
>
> Running a build of current sources with complete testsuite this test is failing with
> testRegistryConfiguration(org.jboss.as.test.smoke.deployment.rar.tests.inflow.InflowTestCase): expected:<1> but was:<2>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 03:52:02 2013
From: jira-events at lists.jboss.org (Frank Langelage (JIRA))
Date: Tue, 29 Oct 2013 03:52:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2400)
 org.jboss.as.test.smoke.mgmt.servermodule.ValidateModelTestCase fails
In-Reply-To: <JIRA.12508923.1383033028000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508923.1383033028000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508923.1383033028000.20592.1383033122436@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Frank Langelage updated WFLY-2400:
----------------------------------

    Description: 
Running a build of current sources with complete testsuite this test is failing with
testValidateModel(org.jboss.as.test.smoke.mgmt.servermodule.ValidateModelTestCase): The model failed validation


  was:
Running a build of current sources with complete testsuite this test is failing with
testRegistryConfiguration(org.jboss.as.test.smoke.deployment.rar.tests.inflow.InflowTestCase): expected:<1> but was:<2>



    
> org.jboss.as.test.smoke.mgmt.servermodule.ValidateModelTestCase fails
> ---------------------------------------------------------------------
>
>                 Key: WFLY-2400
>                 URL: https://issues.jboss.org/browse/WFLY-2400
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server, Test Suite
>    Affects Versions: 8.0.0.Beta1
>         Environment: Solaris SPARC 10, Oracle Java 1.7.0_45
>            Reporter: Frank Langelage
>            Assignee: Stefano Maestri
>
> Running a build of current sources with complete testsuite this test is failing with
> testValidateModel(org.jboss.as.test.smoke.mgmt.servermodule.ValidateModelTestCase): The model failed validation

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 03:54:01 2013
From: jira-events at lists.jboss.org (Frank Langelage (JIRA))
Date: Tue, 29 Oct 2013 03:54:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2400)
 org.jboss.as.test.smoke.mgmt.servermodule.ValidateModelTestCase fails
In-Reply-To: <JIRA.12508923.1383033028000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508923.1383033028000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508923.1383033028000.20595.1383033241914@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Frank Langelage updated WFLY-2400:
----------------------------------

    Attachment: org.jboss.as.test.smoke.mgmt.servermodule.ValidateModelTestCase.txt
                org.jboss.as.test.smoke.mgmt.servermodule.ValidateModelTestCase-output.txt

    
> org.jboss.as.test.smoke.mgmt.servermodule.ValidateModelTestCase fails
> ---------------------------------------------------------------------
>
>                 Key: WFLY-2400
>                 URL: https://issues.jboss.org/browse/WFLY-2400
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server, Test Suite
>    Affects Versions: 8.0.0.Beta1
>         Environment: Solaris SPARC 10, Oracle Java 1.7.0_45
>            Reporter: Frank Langelage
>            Assignee: Stefano Maestri
>         Attachments: org.jboss.as.test.smoke.mgmt.servermodule.ValidateModelTestCase-output.txt, org.jboss.as.test.smoke.mgmt.servermodule.ValidateModelTestCase.txt
>
>
> Running a build of current sources with complete testsuite this test is failing with
> testValidateModel(org.jboss.as.test.smoke.mgmt.servermodule.ValidateModelTestCase): The model failed validation

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 03:56:02 2013
From: jira-events at lists.jboss.org (Frank Langelage (JIRA))
Date: Tue, 29 Oct 2013 03:56:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2400)
 org.jboss.as.test.smoke.mgmt.servermodule.ValidateModelTestCase fails
In-Reply-To: <JIRA.12508923.1383033028000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508923.1383033028000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508923.1383033028000.20599.1383033362228@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Frank Langelage updated WFLY-2400:
----------------------------------

    Component/s:     (was: Server)
                     (was: Test Suite)

    
> org.jboss.as.test.smoke.mgmt.servermodule.ValidateModelTestCase fails
> ---------------------------------------------------------------------
>
>                 Key: WFLY-2400
>                 URL: https://issues.jboss.org/browse/WFLY-2400
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Beta1
>         Environment: Solaris SPARC 10, Oracle Java 1.7.0_45
>            Reporter: Frank Langelage
>            Assignee: Stefano Maestri
>         Attachments: org.jboss.as.test.smoke.mgmt.servermodule.ValidateModelTestCase-output.txt, org.jboss.as.test.smoke.mgmt.servermodule.ValidateModelTestCase.txt
>
>
> Running a build of current sources with complete testsuite this test is failing with
> testValidateModel(org.jboss.as.test.smoke.mgmt.servermodule.ValidateModelTestCase): The model failed validation

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 03:56:02 2013
From: jira-events at lists.jboss.org (Frank Langelage (JIRA))
Date: Tue, 29 Oct 2013 03:56:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2400)
 org.jboss.as.test.smoke.mgmt.servermodule.ValidateModelTestCase fails
In-Reply-To: <JIRA.12508923.1383033028000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508923.1383033028000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508923.1383033028000.20601.1383033362398@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Frank Langelage updated WFLY-2400:
----------------------------------

    Component/s: Server
                 Test Suite

    
> org.jboss.as.test.smoke.mgmt.servermodule.ValidateModelTestCase fails
> ---------------------------------------------------------------------
>
>                 Key: WFLY-2400
>                 URL: https://issues.jboss.org/browse/WFLY-2400
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server, Test Suite
>    Affects Versions: 8.0.0.Beta1
>         Environment: Solaris SPARC 10, Oracle Java 1.7.0_45
>            Reporter: Frank Langelage
>            Assignee: Stefano Maestri
>         Attachments: org.jboss.as.test.smoke.mgmt.servermodule.ValidateModelTestCase-output.txt, org.jboss.as.test.smoke.mgmt.servermodule.ValidateModelTestCase.txt
>
>
> Running a build of current sources with complete testsuite this test is failing with
> testValidateModel(org.jboss.as.test.smoke.mgmt.servermodule.ValidateModelTestCase): The model failed validation

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 03:59:01 2013
From: jira-events at lists.jboss.org (Frank Langelage (JIRA))
Date: Tue, 29 Oct 2013 03:59:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2401)
 org.jboss.as.test.smoke.mgmt.BasicOperationsUnitTestCase fails
In-Reply-To: <JIRA.12508924.1383033520537@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508924.1383033520537@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508924.1383033520537.20604.1383033541915@jira02.app.mwc.hst.phx2.redhat.com>

Frank Langelage created WFLY-2401:
-------------------------------------

             Summary: org.jboss.as.test.smoke.mgmt.BasicOperationsUnitTestCase fails
                 Key: WFLY-2401
                 URL: https://issues.jboss.org/browse/WFLY-2401
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Test Suite
    Affects Versions: 8.0.0.Beta1
         Environment: Solaris SPARC 10, Oracle Java 1.7.0_45
            Reporter: Frank Langelage
            Assignee: Ondrej Zizka


Running a build of current sources with complete testsuite this test is failing with
testReadAttributeWildcards(org.jboss.as.test.smoke.mgmt.BasicOperationsUnitTestCase)


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 04:01:02 2013
From: jira-events at lists.jboss.org (Frank Langelage (JIRA))
Date: Tue, 29 Oct 2013 04:01:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2401)
 org.jboss.as.test.smoke.mgmt.BasicOperationsUnitTestCase fails
In-Reply-To: <JIRA.12508924.1383033520000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508924.1383033520000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508924.1383033520000.20608.1383033662636@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Frank Langelage updated WFLY-2401:
----------------------------------

    Attachment: org.jboss.as.test.smoke.mgmt.BasicOperationsUnitTestCase.txt

    
> org.jboss.as.test.smoke.mgmt.BasicOperationsUnitTestCase fails
> --------------------------------------------------------------
>
>                 Key: WFLY-2401
>                 URL: https://issues.jboss.org/browse/WFLY-2401
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.Beta1
>         Environment: Solaris SPARC 10, Oracle Java 1.7.0_45
>            Reporter: Frank Langelage
>            Assignee: Ondrej Zizka
>         Attachments: org.jboss.as.test.smoke.mgmt.BasicOperationsUnitTestCase.txt
>
>
> Running a build of current sources with complete testsuite this test is failing with
> testReadAttributeWildcards(org.jboss.as.test.smoke.mgmt.BasicOperationsUnitTestCase)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 04:15:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 04:15:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-223) Serializing and
 deserializing a PackageDescr causes imports to change to import null
In-Reply-To: <JIRA.12498705.1376591313000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498705.1376591313000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498705.1376591313000.20628.1383034502990@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-223:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> Serializing and deserializing a PackageDescr causes imports to change to import null
> ------------------------------------------------------------------------------------
>
>                 Key: DROOLS-223
>                 URL: https://issues.jboss.org/browse/DROOLS-223
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Bobby Graham
>            Assignee: Mario Fusco
>
> Serializing and deserializing a PackageDescr causes imports to change to import null (import Person becomes import null).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 04:15:03 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 04:15:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-223) Serializing and
 deserializing a PackageDescr causes imports to change to import null
In-Reply-To: <JIRA.12498705.1376591313000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498705.1376591313000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498705.1376591313000.20631.1383034503297@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-223.
--------------------------------

    Fix Version/s: 5.5.1.Final
                   6.0.0.Final
       Resolution: Done

    
> Serializing and deserializing a PackageDescr causes imports to change to import null
> ------------------------------------------------------------------------------------
>
>                 Key: DROOLS-223
>                 URL: https://issues.jboss.org/browse/DROOLS-223
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Bobby Graham
>            Assignee: Mario Fusco
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> Serializing and deserializing a PackageDescr causes imports to change to import null (import Person becomes import null).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 04:21:01 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Tue, 29 Oct 2013 04:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2393) deprecate messaging's
	-jms.xml deployment
In-Reply-To: <JIRA.12508894.1382977509000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508894.1382977509000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508894.1382977509000.20671.1383034861971@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825421#comment-12825421 ] 

Stuart Douglas commented on WFLY-2393:
--------------------------------------

The EE deployment descriptors do not provide the same functionality, as -jms.xml files can be deployed directly, while EE descriptors can only be deployed as part of an archive.
                
> deprecate messaging's -jms.xml deployment
> -----------------------------------------
>
>                 Key: WFLY-2393
>                 URL: https://issues.jboss.org/browse/WFLY-2393
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.CR1
>
>
> JMS destinations can be deployed using a non-standard -jms.xml description files.
> With JMS 2.0 and Java EE7, the same can be achieved in a standard portable way using jms-destination in Java EE deployment descriptors.
> Deprecate the non-standard -jms.xml with a message stating to use the standard descriptor deployment instead.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 04:27:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 04:27:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-18) DRL constraint on property x
 on a class with isX() and getX() fails with [Error: incompatible types in
 statement: boolean]
In-Reply-To: <JIRA.12483413.1359025037000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12483413.1359025037000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12483413.1359025037000.20693.1383035222290@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-18?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-18.
-------------------------------

    Fix Version/s: 5.5.1.Final
                   6.0.0.Final
       Resolution: Done


Now a compilation warning is generated in case of 2 conflicting accessors for the same field.
                
> DRL constraint on property x on a class with isX() and getX() fails with [Error: incompatible types in statement: boolean]
> --------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-18
>                 URL: https://issues.jboss.org/browse/DROOLS-18
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Windows 7 64Bit
> Java 1.7.0
> Drools-core 5.5.0.Final
> Drools-compiler 5.5.0.Final
> Mvel2 2.1.3.Final
>            Reporter: Michiel Vermandel
>            Assignee: Mario Fusco
>            Priority: Critical
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> In about one out of ten JUnit runs, I get a crash with stack trace. 
> The process terminates immediately. 
> Unit test output is 100% the same on successful runs.
> Stack trace:
> [Error: incompatible types in statement: boolean (compared from: class be.axi.planner.domain.Task)]
> [Near : {... this == lead ....}]
>              ^
> [Line: 1, Column: 1]
>     at org.mvel2.ast.BinaryOperation.<init>(BinaryOperation.java:84)
>     at org.mvel2.util.CompilerTools.finalizePayload(CompilerTools.java:118)
>     at org.mvel2.compiler.ExpressionCompiler._compile(ExpressionCompiler.java:287)
>     at org.mvel2.compiler.ExpressionCompiler.compile(ExpressionCompiler.java:62)
>     at org.mvel2.MVEL.compileExpression(MVEL.java:810)
>     at org.drools.base.mvel.MVELCompilationUnit.compile(MVELCompilationUnit.java:435)
>     at org.drools.base.mvel.MVELCompilationUnit.getCompiledExpression(MVELCompilationUnit.java:238)
>     at org.drools.rule.constraint.MvelConstraint.createMvelConditionEvaluator(MvelConstraint.java:206)
>     at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:190)
>     at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:157)
>     at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:137)
>     at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:497)
>     at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:382)
>     at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235)
>     at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240)
>     at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:350)
>     at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:311)
>     at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903)
>     at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:847)
>     at org.drools.planner.core.score.director.drools.DroolsScoreDirector.afterEntityAdded(DroolsScoreDirector.java:103)
>     at org.drools.planner.core.heuristic.selector.variable.PlanningVariableWalker.moveIterator(PlanningVariableWalker.java:145)
>     at org.drools.planner.core.constructionheuristic.greedyFit.decider.DefaultGreedyDecider.decideNextStep(DefaultGreedyDecider.java:74)
>     at org.drools.planner.core.constructionheuristic.greedyFit.DefaultGreedyFitSolverPhase.solve(DefaultGreedyFitSolverPhase.java:65)
>     at org.drools.planner.core.solver.DefaultSolver.runSolverPhases(DefaultSolver.java:190)
>     at org.drools.planner.core.solver.DefaultSolver.solve(DefaultSolver.java:155)
>     at be.axi.planner.app.InspectionSchedule.solve(InspectionSchedule.java:192)
>     at be.axi.planner.testcore.AbstractPlanningTestClass.solve(AbstractPlanningTestClass.java:288)
>     at be.axi.planner.testcore.AbstractPlanningTestClass.solve(AbstractPlanningTestClass.java:298)
>     at be.axi.planner.testcore.AbstractPlanningTestClass.solve(AbstractPlanningTestClass.java:315)
>     at be.axi.planner.TaskGroupingTest.communitySuccess02(TaskGroupingTest.java:289)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>     at java.lang.reflect.Method.invoke(Unknown Source)
>     at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
>     at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
>     at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
>     at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
>     at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
>     at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
>     at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
>     at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
>     at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
>     at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
>     at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
>     at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
>     at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
>     at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
>     at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
>     at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
>     at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 04:27:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 04:27:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-87)
 org.drools.time.impl.DefaultJobHandle causes NullPointer in hashCode
In-Reply-To: <JIRA.12487856.1364145865000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12487856.1364145865000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487856.1364145865000.20697.1383035222535@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-87:
---------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> org.drools.time.impl.DefaultJobHandle causes NullPointer in hashCode
> --------------------------------------------------------------------
>
>                 Key: DROOLS-87
>                 URL: https://issues.jboss.org/browse/DROOLS-87
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Christian Klock
>            Assignee: Mario Fusco
>
> When timerJobInstance is null, the following NPE is thrown:
> Caused by: java.lang.NullPointerException
>         at org.drools.time.impl.DefaultJobHandle.getJob(DefaultJobHandle.java:55)
>         at org.drools.time.impl.DefaultJobHandle.hashCode(DefaultJobHandle.java:70)
>         at java.lang.Object.toString(Object.java:237)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 04:27:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 04:27:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-87)
 org.drools.time.impl.DefaultJobHandle causes NullPointer in hashCode
In-Reply-To: <JIRA.12487856.1364145865000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12487856.1364145865000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487856.1364145865000.20700.1383035222691@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-87.
-------------------------------

    Fix Version/s: 5.5.1.Final
                   6.0.0.Final
       Resolution: Done

    
> org.drools.time.impl.DefaultJobHandle causes NullPointer in hashCode
> --------------------------------------------------------------------
>
>                 Key: DROOLS-87
>                 URL: https://issues.jboss.org/browse/DROOLS-87
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Christian Klock
>            Assignee: Mario Fusco
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> When timerJobInstance is null, the following NPE is thrown:
> Caused by: java.lang.NullPointerException
>         at org.drools.time.impl.DefaultJobHandle.getJob(DefaultJobHandle.java:55)
>         at org.drools.time.impl.DefaultJobHandle.hashCode(DefaultJobHandle.java:70)
>         at java.lang.Object.toString(Object.java:237)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 04:39:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 04:39:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-240) ResourceChangeScanner not
 removing UrlResources
In-Reply-To: <JIRA.12499317.1377374484000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499317.1377374484000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499317.1377374484000.20718.1383035942154@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-240:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> ResourceChangeScanner not removing UrlResources
> -----------------------------------------------
>
>                 Key: DROOLS-240
>                 URL: https://issues.jboss.org/browse/DROOLS-240
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>         Environment: java version "1.7.0_21"
> Java(TM) SE Runtime Environment (build 1.7.0_21-b11)
> Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode)
>            Reporter: Demian Calcaprina
>            Assignee: Mario Fusco
>            Priority: Critical
>         Attachments: UrlTest.java
>
>
> I am seing that the resources in the KnowledgeBase are being deleted without aparent reason.
> I have some URL resources configured to get it from guvnor using the basic auth.
> It seems this method,
> https://github.com/droolsjbpm/drools/blob/5.5.x/drools-core/src/main/java/org/drools/io/impl/UrlResource.java#L252
> is not including auth parameters to get the last modified date from the resource url. This is causing (in my environment), to get last modified date as 0, and this makes the ResourceChangeScanner to remove the resource from the kbase. I made the fix and seems to work fine in my machine.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 04:41:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 04:41:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-47) Recovery from ChangeSet
	compilation fail
In-Reply-To: <JIRA.12485345.1361443208000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485345.1361443208000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485345.1361443208000.20723.1383036062186@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-47:
---------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> Recovery from ChangeSet compilation fail
> ----------------------------------------
>
>                 Key: DROOLS-47
>                 URL: https://issues.jboss.org/browse/DROOLS-47
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Drools Expert 5.4.0, 5.5.0
>            Reporter: Karel Cemus
>            Assignee: Mario Fusco
>            Priority: Minor
>
> Drools org.drools.compiler.PackageBuilder has a bug in loading change-sets containing damaged resources. Compilation of such change-set prevents builder recovery even by using undo() method.
> When user adds new Drools resource into KnowledgeBuilder, its implementation KnowledgeBuilderImpl on line 50 calls PackageBuilder to register the change set file as an official resource.
> In a following step the PackageBuilder extracts all mentioned resources from that change-set file and processes each of them separately but without their official registration in loaded resources. But these resources are processed under their own resource name which is the key in the set of reported errors. 
> Due to such behavior there remains errors preventing building stable org.drools.KnowledgeBase with an IllegalArgumentException even after calling KnowledgeBuilder#undo(), because it removes only errors reported directly with the change-set resource, but not the errors reported with resources from the change-set.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 04:41:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 04:41:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-47) Recovery from ChangeSet
	compilation fail
In-Reply-To: <JIRA.12485345.1361443208000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485345.1361443208000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485345.1361443208000.20727.1383036062417@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-47.
-------------------------------

    Fix Version/s: 5.5.1.Final
                   6.0.0.Final
       Resolution: Done

    
> Recovery from ChangeSet compilation fail
> ----------------------------------------
>
>                 Key: DROOLS-47
>                 URL: https://issues.jboss.org/browse/DROOLS-47
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Drools Expert 5.4.0, 5.5.0
>            Reporter: Karel Cemus
>            Assignee: Mario Fusco
>            Priority: Minor
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> Drools org.drools.compiler.PackageBuilder has a bug in loading change-sets containing damaged resources. Compilation of such change-set prevents builder recovery even by using undo() method.
> When user adds new Drools resource into KnowledgeBuilder, its implementation KnowledgeBuilderImpl on line 50 calls PackageBuilder to register the change set file as an official resource.
> In a following step the PackageBuilder extracts all mentioned resources from that change-set file and processes each of them separately but without their official registration in loaded resources. But these resources are processed under their own resource name which is the key in the set of reported errors. 
> Due to such behavior there remains errors preventing building stable org.drools.KnowledgeBase with an IllegalArgumentException even after calling KnowledgeBuilder#undo(), because it removes only errors reported directly with the change-set resource, but not the errors reported with resources from the change-set.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 04:41:03 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 04:41:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-257) Past events beyond
 expiration are not expired
In-Reply-To: <JIRA.12500351.1378778236000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500351.1378778236000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500351.1378778236000.20739.1383036063285@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-257:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> Past events beyond expiration are not expired
> ---------------------------------------------
>
>                 Key: DROOLS-257
>                 URL: https://issues.jboss.org/browse/DROOLS-257
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final,  6.0.0.CR3
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Critical
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 04:41:03 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 04:41:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-257) Past events beyond
 expiration are not expired
In-Reply-To: <JIRA.12500351.1378778236000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500351.1378778236000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500351.1378778236000.20743.1383036063481@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-257.
--------------------------------

    Resolution: Done

    
> Past events beyond expiration are not expired
> ---------------------------------------------
>
>                 Key: DROOLS-257
>                 URL: https://issues.jboss.org/browse/DROOLS-257
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final,  6.0.0.CR3
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Critical
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 04:43:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 04:43:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-211) Race condition causing
	jitting error
In-Reply-To: <JIRA.12498096.1375813051000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498096.1375813051000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498096.1375813051000.20751.1383036182064@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-211:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> Race condition causing jitting error
> ------------------------------------
>
>                 Key: DROOLS-211
>                 URL: https://issues.jboss.org/browse/DROOLS-211
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.1.Final
>            Reporter: Ming Fang
>            Assignee: Mario Fusco
>         Attachments: JittingTest.java, test.drl
>
>
> When there is a rule that retracts a fact while a MvelConstraint.ConditionJitter task runs, then sometimes the jitting task fails with this error...
> java.lang.NullPointerException
> 	at org.drools.base.defaultpkg.Person13506221$getField10.getValue(Unknown Source)
> 	at org.drools.base.ClassFieldReader.getValue(ClassFieldReader.java:87)
> 	at org.drools.rule.Declaration.getValue(Declaration.java:233)
> 	at org.drools.base.mvel.MVELCompilationUnit.updateFactory(MVELCompilationUnit.java:344)
> 	at org.drools.base.mvel.MVELCompilationUnit.updateFactory(MVELCompilationUnit.java:289)
> 	at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:62)
> 	at org.drools.rule.constraint.MvelConditionEvaluator.ensureBranchEvaluation(MvelConditionEvaluator.java:120)
> 	at org.drools.rule.constraint.MvelConditionEvaluator.ensureCompleteEvaluation(MvelConditionEvaluator.java:105)
> 	at org.drools.rule.constraint.MvelConditionEvaluator.ensureCompleteEvaluation(MvelConditionEvaluator.java:93)
> 	at org.drools.rule.constraint.MvelConditionEvaluator.getAnalyzedCondition(MvelConditionEvaluator.java:85)
> 	at org.drools.rule.constraint.MvelConstraint.executeJitting(MvelConstraint.java:284)
> 	at org.drools.rule.constraint.MvelConstraint.access$200(MvelConstraint.java:54)
> 	at org.drools.rule.constraint.MvelConstraint$ConditionJitter.run(MvelConstraint.java:263)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:662)
>  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 04:43:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 04:43:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-211) Race condition causing
	jitting error
In-Reply-To: <JIRA.12498096.1375813051000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498096.1375813051000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498096.1375813051000.20754.1383036182236@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-211.
--------------------------------

    Fix Version/s: 5.5.1.Final
                   6.0.0.Final
       Resolution: Done

    
> Race condition causing jitting error
> ------------------------------------
>
>                 Key: DROOLS-211
>                 URL: https://issues.jboss.org/browse/DROOLS-211
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.1.Final
>            Reporter: Ming Fang
>            Assignee: Mario Fusco
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>         Attachments: JittingTest.java, test.drl
>
>
> When there is a rule that retracts a fact while a MvelConstraint.ConditionJitter task runs, then sometimes the jitting task fails with this error...
> java.lang.NullPointerException
> 	at org.drools.base.defaultpkg.Person13506221$getField10.getValue(Unknown Source)
> 	at org.drools.base.ClassFieldReader.getValue(ClassFieldReader.java:87)
> 	at org.drools.rule.Declaration.getValue(Declaration.java:233)
> 	at org.drools.base.mvel.MVELCompilationUnit.updateFactory(MVELCompilationUnit.java:344)
> 	at org.drools.base.mvel.MVELCompilationUnit.updateFactory(MVELCompilationUnit.java:289)
> 	at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:62)
> 	at org.drools.rule.constraint.MvelConditionEvaluator.ensureBranchEvaluation(MvelConditionEvaluator.java:120)
> 	at org.drools.rule.constraint.MvelConditionEvaluator.ensureCompleteEvaluation(MvelConditionEvaluator.java:105)
> 	at org.drools.rule.constraint.MvelConditionEvaluator.ensureCompleteEvaluation(MvelConditionEvaluator.java:93)
> 	at org.drools.rule.constraint.MvelConditionEvaluator.getAnalyzedCondition(MvelConditionEvaluator.java:85)
> 	at org.drools.rule.constraint.MvelConstraint.executeJitting(MvelConstraint.java:284)
> 	at org.drools.rule.constraint.MvelConstraint.access$200(MvelConstraint.java:54)
> 	at org.drools.rule.constraint.MvelConstraint$ConditionJitter.run(MvelConstraint.java:263)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:662)
>  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 04:45:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 04:45:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-175) Deadlock when invoking
 queries concurrently
In-Reply-To: <JIRA.12494729.1371726167000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494729.1371726167000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494729.1371726167000.20759.1383036302000@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-175.
--------------------------------

    Fix Version/s: 5.5.1.Final
                   6.0.0.Final
       Resolution: Done

    
> Deadlock when invoking queries concurrently
> -------------------------------------------
>
>                 Key: DROOLS-175
>                 URL: https://issues.jboss.org/browse/DROOLS-175
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Gabor Gyongyi
>            Assignee: Mario Fusco
>            Priority: Blocker
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> I have a query that I want to execute from multiple threads using statefulKnowledgeSession.getQueryResults. One of the threads wants to invoke lock.writeLock().lock() in the 105th line of UpgradableReentrantReadWriteLock. The problem is that the other threads already own the readLock and they cannot proceed until the first query thread finishes with its job. They will wait for each other.
> I experienced the same problem with 5.4.0.Final as well.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 04:47:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 04:47:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-270) Primitve globals will result
 in a runtime exception
In-Reply-To: <JIRA.12500985.1379581188000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500985.1379581188000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500985.1379581188000.20763.1383036422185@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-270:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> Primitve globals will result in a runtime exception
> ---------------------------------------------------
>
>                 Key: DROOLS-270
>                 URL: https://issues.jboss.org/browse/DROOLS-270
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final,  6.0.0.CR3
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Minor
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> package test; 
> global int foo;
> ...
> the KnowledgeBuilder will accept primitive typed globals, but they will
> later result in a runtime exception when the KB is built.
> A compile-time error should be raised instead

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 04:47:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 04:47:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-270) Primitve globals will result
 in a runtime exception
In-Reply-To: <JIRA.12500985.1379581188000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500985.1379581188000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500985.1379581188000.20767.1383036422781@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-270.
--------------------------------

    Resolution: Done

    
> Primitve globals will result in a runtime exception
> ---------------------------------------------------
>
>                 Key: DROOLS-270
>                 URL: https://issues.jboss.org/browse/DROOLS-270
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final,  6.0.0.CR3
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Minor
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> package test; 
> global int foo;
> ...
> the KnowledgeBuilder will accept primitive typed globals, but they will
> later result in a runtime exception when the KB is built.
> A compile-time error should be raised instead

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 04:47:03 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 04:47:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-285)
 JtaTransactionSynchronizationAdapter contains infite loop
In-Reply-To: <JIRA.12502197.1380886759000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502197.1380886759000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502197.1380886759000.20772.1383036423152@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-285:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> JtaTransactionSynchronizationAdapter contains infite loop
> ---------------------------------------------------------
>
>                 Key: DROOLS-285
>                 URL: https://issues.jboss.org/browse/DROOLS-285
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Nils Miehe
>            Assignee: Mario Fusco
>             Fix For: 6.0.0.Final
>
>
> I stumbled upon this while searching for a potential cause of JBPM-4132 .
> In the method afterCompletion of JtaTransactionSynchronizationAdapter a call with STATUS_ACTIVE would cause an infinite loop. As this value in itself indicates an inconsistent state the error probably wasn't noticed earlier.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 04:47:03 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 04:47:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-285)
 JtaTransactionSynchronizationAdapter contains infite loop
In-Reply-To: <JIRA.12502197.1380886759000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502197.1380886759000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502197.1380886759000.20774.1383036423291@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-285.
--------------------------------

    Fix Version/s: 5.5.1.Final
       Resolution: Done

    
> JtaTransactionSynchronizationAdapter contains infite loop
> ---------------------------------------------------------
>
>                 Key: DROOLS-285
>                 URL: https://issues.jboss.org/browse/DROOLS-285
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Nils Miehe
>            Assignee: Mario Fusco
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> I stumbled upon this while searching for a potential cause of JBPM-4132 .
> In the method afterCompletion of JtaTransactionSynchronizationAdapter a call with STATUS_ACTIVE would cause an infinite loop. As this value in itself indicates an inconsistent state the error probably wasn't noticed earlier.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 04:49:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 04:49:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-287) Rule names with
 non-alphabetic characters may lead to name clashes
In-Reply-To: <JIRA.12502262.1380953728000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502262.1380953728000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502262.1380953728000.20780.1383036542066@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-287:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> Rule names with non-alphabetic characters may lead to name clashes
> ------------------------------------------------------------------
>
>                 Key: DROOLS-287
>                 URL: https://issues.jboss.org/browse/DROOLS-287
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final,  6.0.0.CR4
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Critical
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> A KB with the two following rules will not compile:
> {code}
> rule "Rule_>"
> when then end
> rule "Rule_<"
> when then end
> {code}
> Here's a more realistic example:
> {code}
> rule "dollar > euro"
> when then end
> rule "dollar < euro"
> when then end
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 04:49:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 04:49:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-287) Rule names with
 non-alphabetic characters may lead to name clashes
In-Reply-To: <JIRA.12502262.1380953728000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502262.1380953728000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502262.1380953728000.20785.1383036542357@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-287.
--------------------------------

    Resolution: Done

    
> Rule names with non-alphabetic characters may lead to name clashes
> ------------------------------------------------------------------
>
>                 Key: DROOLS-287
>                 URL: https://issues.jboss.org/browse/DROOLS-287
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final,  6.0.0.CR4
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Critical
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> A KB with the two following rules will not compile:
> {code}
> rule "Rule_>"
> when then end
> rule "Rule_<"
> when then end
> {code}
> Here's a more realistic example:
> {code}
> rule "dollar > euro"
> when then end
> rule "dollar < euro"
> when then end
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 04:49:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 04:49:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-239) InitialFact leaks into other
 patterns via inheritence
In-Reply-To: <JIRA.12499314.1377312719000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499314.1377312719000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499314.1377312719000.20787.1383036542470@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-239:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> InitialFact leaks into other patterns via inheritence
> -----------------------------------------------------
>
>                 Key: DROOLS-239
>                 URL: https://issues.jboss.org/browse/DROOLS-239
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>            Assignee: Mario Fusco
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 04:51:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 04:51:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-239) InitialFact leaks into other
 patterns via inheritence
In-Reply-To: <JIRA.12499314.1377312719000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499314.1377312719000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499314.1377312719000.20791.1383036662700@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-239.
--------------------------------

    Fix Version/s: 5.5.1.Final
                   6.0.0.Final
       Resolution: Done

    
> InitialFact leaks into other patterns via inheritence
> -----------------------------------------------------
>
>                 Key: DROOLS-239
>                 URL: https://issues.jboss.org/browse/DROOLS-239
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>            Assignee: Mario Fusco
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 04:51:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 04:51:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-288) Expose PMML compilation
	errors
In-Reply-To: <JIRA.12502378.1381171123000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502378.1381171123000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502378.1381171123000.20795.1383036662996@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-288:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> Expose PMML compilation errors
> ------------------------------
>
>                 Key: DROOLS-288
>                 URL: https://issues.jboss.org/browse/DROOLS-288
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Minor
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 04:51:03 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 04:51:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-288) Expose PMML compilation
	errors
In-Reply-To: <JIRA.12502378.1381171123000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502378.1381171123000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502378.1381171123000.20797.1383036663175@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-288.
--------------------------------

    Fix Version/s: 5.5.1.Final
                   6.0.0.Final
       Resolution: Done

    
> Expose PMML compilation errors
> ------------------------------
>
>                 Key: DROOLS-288
>                 URL: https://issues.jboss.org/browse/DROOLS-288
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Minor
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 04:53:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 04:53:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-289) PackageBuilder throws NPE
 when a declared class extends another, undeclared one
In-Reply-To: <JIRA.12502404.1381189422000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502404.1381189422000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502404.1381189422000.20808.1383036782490@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-289:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> PackageBuilder throws NPE when a declared class extends another, undeclared one
> -------------------------------------------------------------------------------
>
>                 Key: DROOLS-289
>                 URL: https://issues.jboss.org/browse/DROOLS-289
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>
> Parent class(es) used with declare must be declared themselves.
> However, instead of returning a compilation error, the package builder
> throws a runtime NPE

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 04:53:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 04:53:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-289) PackageBuilder throws NPE
 when a declared class extends another, undeclared one
In-Reply-To: <JIRA.12502404.1381189422000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502404.1381189422000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502404.1381189422000.20814.1383036782809@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-289.
--------------------------------

    Fix Version/s: 5.5.1.Final
                   6.0.0.Final
       Resolution: Done

    
> PackageBuilder throws NPE when a declared class extends another, undeclared one
> -------------------------------------------------------------------------------
>
>                 Key: DROOLS-289
>                 URL: https://issues.jboss.org/browse/DROOLS-289
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> Parent class(es) used with declare must be declared themselves.
> However, instead of returning a compilation error, the package builder
> throws a runtime NPE

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 04:55:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 04:55:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-43) Binding makes parser accept
 non-boolean constraint
In-Reply-To: <JIRA.12485102.1361202697000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485102.1361202697000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485102.1361202697000.20824.1383036902049@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-43.
-------------------------------

    Fix Version/s: 5.5.1.Final
                   6.0.0.Final
       Resolution: Done

    
> Binding makes parser accept non-boolean constraint
> --------------------------------------------------
>
>                 Key: DROOLS-43
>                 URL: https://issues.jboss.org/browse/DROOLS-43
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> Below is a self-contained DRL which should not compile because the sum isn't a boolean expression. (Note that omitting "$x:" results in the correct diagnostic "predicate ... must be a boolean".)
> {code}
> declare Foo
>   a: double
>   b: double
> end
> rule what
> when
>     $c: Foo( $x: a + b )
> then
>     System.out.println( "foo: " + $c );
> end
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 04:55:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 04:55:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-312) STATING a JUSTIFIED fact
 will actually delete that fact
In-Reply-To: <JIRA.12508759.1382678737000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508759.1382678737000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508759.1382678737000.20828.1383036902250@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-312:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> STATING a JUSTIFIED fact will actually delete that fact
> -------------------------------------------------------
>
>                 Key: DROOLS-312
>                 URL: https://issues.jboss.org/browse/DROOLS-312
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.CR5
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Critical
>
> When a previously JUSTIFIED fact is STATED, all its logical dependencies are removed. However, the TMS will delete a managed fact with no dependencies.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 04:55:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 04:55:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-312) STATING a JUSTIFIED fact
 will actually delete that fact
In-Reply-To: <JIRA.12508759.1382678737000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508759.1382678737000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508759.1382678737000.20831.1383036902402@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-312.
--------------------------------

    Fix Version/s: 5.5.1.Final
                   6.0.0.Final
       Resolution: Done

    
> STATING a JUSTIFIED fact will actually delete that fact
> -------------------------------------------------------
>
>                 Key: DROOLS-312
>                 URL: https://issues.jboss.org/browse/DROOLS-312
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.CR5
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Critical
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> When a previously JUSTIFIED fact is STATED, all its logical dependencies are removed. However, the TMS will delete a managed fact with no dependencies.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 04:57:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 04:57:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-154) Improve the isA trait
 evaluator to work with literals
In-Reply-To: <JIRA.12493162.1369871403000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493162.1369871403000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493162.1369871403000.20834.1383037022172@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-154:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> Improve the isA trait evaluator to work with literals
> -----------------------------------------------------
>
>                 Key: DROOLS-154
>                 URL: https://issues.jboss.org/browse/DROOLS-154
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Minor
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 04:57:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 04:57:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-154) Improve the isA trait
 evaluator to work with literals
In-Reply-To: <JIRA.12493162.1369871403000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493162.1369871403000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493162.1369871403000.20838.1383037022402@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-154.
--------------------------------

    Fix Version/s: 5.5.1.Final
                   6.0.0.Final
       Resolution: Done

    
> Improve the isA trait evaluator to work with literals
> -----------------------------------------------------
>
>                 Key: DROOLS-154
>                 URL: https://issues.jboss.org/browse/DROOLS-154
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Minor
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 04:57:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 04:57:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-160) Improve trait @aliasing
	capabilities
In-Reply-To: <JIRA.12493545.1370355601000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493545.1370355601000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493545.1370355601000.20842.1383037022657@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-160:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> Improve trait @aliasing capabilities
> ------------------------------------
>
>                 Key: DROOLS-160
>                 URL: https://issues.jboss.org/browse/DROOLS-160
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Minor
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 04:57:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 04:57:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-160) Improve trait @aliasing
	capabilities
In-Reply-To: <JIRA.12493545.1370355601000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493545.1370355601000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493545.1370355601000.20845.1383037022779@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-160.
--------------------------------

    Fix Version/s: 5.5.1.Final
                   6.0.0.Final
       Resolution: Done

    
> Improve trait @aliasing capabilities
> ------------------------------------
>
>                 Key: DROOLS-160
>                 URL: https://issues.jboss.org/browse/DROOLS-160
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Minor
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 04:57:03 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 04:57:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-172) Multiple proxy instances for
	same trait
In-Reply-To: <JIRA.12494613.1371634978000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494613.1371634978000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494613.1371634978000.20850.1383037023070@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-172:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> Multiple proxy instances for same trait
> ---------------------------------------
>
>                 Key: DROOLS-172
>                 URL: https://issues.jboss.org/browse/DROOLS-172
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Beta3
>            Reporter: Fabian Meyer
>            Assignee: Mario Fusco
>            Priority: Minor
>
> If two traits with the same super trait are don to an object, two proxy instances of the super trait are created.
> !https://dl.dropboxusercontent.com/u/26663016/Trait.png!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 04:57:03 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 04:57:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-172) Multiple proxy instances for
	same trait
In-Reply-To: <JIRA.12494613.1371634978000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494613.1371634978000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494613.1371634978000.20853.1383037023232@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-172.
--------------------------------

    Fix Version/s: 5.5.1.Final
                   6.0.0.Final
       Resolution: Done

    
> Multiple proxy instances for same trait
> ---------------------------------------
>
>                 Key: DROOLS-172
>                 URL: https://issues.jboss.org/browse/DROOLS-172
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Beta3
>            Reporter: Fabian Meyer
>            Assignee: Mario Fusco
>            Priority: Minor
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> If two traits with the same super trait are don to an object, two proxy instances of the super trait are created.
> !https://dl.dropboxusercontent.com/u/26663016/Trait.png!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 04:59:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 04:59:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-189) Enable type-driven property
 reactivity for traits
In-Reply-To: <JIRA.12496241.1373588970000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496241.1373588970000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496241.1373588970000.20857.1383037142236@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-189:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> Enable type-driven property reactivity for traits
> -------------------------------------------------
>
>                 Key: DROOLS-189
>                 URL: https://issues.jboss.org/browse/DROOLS-189
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> Extend property reactivity to work with traits.
> The set of dynamic types should be considered a property, so that traiting-driven modifications do not trigger unwanted reevaluations

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 04:59:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 04:59:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-189) Enable type-driven property
 reactivity for traits
In-Reply-To: <JIRA.12496241.1373588970000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496241.1373588970000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496241.1373588970000.20861.1383037142520@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-189.
--------------------------------

    Resolution: Done

    
> Enable type-driven property reactivity for traits
> -------------------------------------------------
>
>                 Key: DROOLS-189
>                 URL: https://issues.jboss.org/browse/DROOLS-189
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> Extend property reactivity to work with traits.
> The set of dynamic types should be considered a property, so that traiting-driven modifications do not trigger unwanted reevaluations

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 04:59:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 04:59:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-190) Remove traits when traited
 object is retracted
In-Reply-To: <JIRA.12496413.1373730896000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496413.1373730896000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496413.1373730896000.20868.1383037142950@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-190.
--------------------------------

    Resolution: Done

    
> Remove traits when traited object is retracted
> ----------------------------------------------
>
>                 Key: DROOLS-190
>                 URL: https://issues.jboss.org/browse/DROOLS-190
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.Beta5
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> Trait proxies should not persist in the WM when the core object is retracted

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 04:59:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 04:59:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-190) Remove traits when traited
 object is retracted
In-Reply-To: <JIRA.12496413.1373730896000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496413.1373730896000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496413.1373730896000.20865.1383037142752@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-190:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> Remove traits when traited object is retracted
> ----------------------------------------------
>
>                 Key: DROOLS-190
>                 URL: https://issues.jboss.org/browse/DROOLS-190
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.Beta5
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> Trait proxies should not persist in the WM when the core object is retracted

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 04:59:03 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 04:59:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-218) trait field @aliasing does
 not work when Maps are traited
In-Reply-To: <JIRA.12498529.1376459625000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498529.1376459625000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498529.1376459625000.20881.1383037143608@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-218:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> trait field @aliasing does not work when Maps are traited
> ---------------------------------------------------------
>
>                 Key: DROOLS-218
>                 URL: https://issues.jboss.org/browse/DROOLS-218
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.1.Final, 6.0.0.CR1
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Minor
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 04:59:04 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 04:59:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-219) @aliasing soft fields may
 fail silently or throw exceptions
In-Reply-To: <JIRA.12498530.1376459764000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498530.1376459764000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498530.1376459764000.20888.1383037144041@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-219:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> @aliasing soft fields may fail silently or throw exceptions
> -----------------------------------------------------------
>
>                 Key: DROOLS-219
>                 URL: https://issues.jboss.org/browse/DROOLS-219
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>
> the behavior of @alias is undefined for soft fields and may be erratic at best.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 04:59:03 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 04:59:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-218) trait field @aliasing does
 not work when Maps are traited
In-Reply-To: <JIRA.12498529.1376459625000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498529.1376459625000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498529.1376459625000.20884.1383037143778@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-218.
--------------------------------

    Fix Version/s: 5.5.1.Final
                   6.0.0.Final
       Resolution: Done

    
> trait field @aliasing does not work when Maps are traited
> ---------------------------------------------------------
>
>                 Key: DROOLS-218
>                 URL: https://issues.jboss.org/browse/DROOLS-218
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.1.Final, 6.0.0.CR1
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Minor
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 04:59:04 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 04:59:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-238) (Trait) hierarchy indexing
 and lookup is dramatically slower than needed
In-Reply-To: <JIRA.12499302.1377277962000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499302.1377277962000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499302.1377277962000.20895.1383037144392@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-238:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> (Trait) hierarchy indexing and lookup is dramatically slower than needed
> ------------------------------------------------------------------------
>
>                 Key: DROOLS-238
>                 URL: https://issues.jboss.org/browse/DROOLS-238
>             Project: Drools
>          Issue Type: Quality Risk
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.CR1
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Critical
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> The encoding is not optimized for performance, and suffers particularly in case of large, flat taxonomies

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 04:59:04 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 04:59:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-219) @aliasing soft fields may
 fail silently or throw exceptions
In-Reply-To: <JIRA.12498530.1376459764000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498530.1376459764000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498530.1376459764000.20890.1383037144136@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-219.
--------------------------------

    Fix Version/s: 5.5.1.Final
                   6.0.0.Final
       Resolution: Done

    
> @aliasing soft fields may fail silently or throw exceptions
> -----------------------------------------------------------
>
>                 Key: DROOLS-219
>                 URL: https://issues.jboss.org/browse/DROOLS-219
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> the behavior of @alias is undefined for soft fields and may be erratic at best.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 05:01:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 05:01:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-238) (Trait) hierarchy indexing
 and lookup is dramatically slower than needed
In-Reply-To: <JIRA.12499302.1377277962000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499302.1377277962000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499302.1377277962000.20898.1383037262379@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-238.
--------------------------------

    Resolution: Done

    
> (Trait) hierarchy indexing and lookup is dramatically slower than needed
> ------------------------------------------------------------------------
>
>                 Key: DROOLS-238
>                 URL: https://issues.jboss.org/browse/DROOLS-238
>             Project: Drools
>          Issue Type: Quality Risk
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.CR1
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Critical
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> The encoding is not optimized for performance, and suffers particularly in case of large, flat taxonomies

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 05:01:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 05:01:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-246) Ensure traitable classes are
 declared as @Traitable
In-Reply-To: <JIRA.12499718.1377915062000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499718.1377915062000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499718.1377915062000.20902.1383037262577@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-246:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> Ensure traitable classes are declared as @Traitable
> ---------------------------------------------------
>
>                 Key: DROOLS-246
>                 URL: https://issues.jboss.org/browse/DROOLS-246
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.CR2
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Minor
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> @Traitable classes - classes whose instances will don trait types - must be declared as such, otherwise the engine won't be able to allocate the appropriate data structures (namely the FactHandle)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 05:01:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 05:01:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-246) Ensure traitable classes are
 declared as @Traitable
In-Reply-To: <JIRA.12499718.1377915062000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499718.1377915062000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499718.1377915062000.20905.1383037262700@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-246.
--------------------------------

    Resolution: Done

    
> Ensure traitable classes are declared as @Traitable
> ---------------------------------------------------
>
>                 Key: DROOLS-246
>                 URL: https://issues.jboss.org/browse/DROOLS-246
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.CR2
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Minor
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> @Traitable classes - classes whose instances will don trait types - must be declared as such, otherwise the engine won't be able to allocate the appropriate data structures (namely the FactHandle)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 05:01:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 05:01:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-248) Declared Traits do not
 inherit fields if multiple inheritance is used
In-Reply-To: <JIRA.12500012.1378363690000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500012.1378363690000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500012.1378363690000.20909.1383037262925@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-248:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> Declared Traits do not inherit fields if multiple inheritance is used
> ---------------------------------------------------------------------
>
>                 Key: DROOLS-248
>                 URL: https://issues.jboss.org/browse/DROOLS-248
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.CR2
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Blocker
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> declare trait A 
>  f : String
> end
> declare trait B
>  g : String
> end
> declare trait C extends A, B
>  h : String
> end
> C will only inherit fields from A

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 05:01:03 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 05:01:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-248) Declared Traits do not
 inherit fields if multiple inheritance is used
In-Reply-To: <JIRA.12500012.1378363690000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500012.1378363690000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500012.1378363690000.20912.1383037263135@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-248.
--------------------------------

    Resolution: Done

    
> Declared Traits do not inherit fields if multiple inheritance is used
> ---------------------------------------------------------------------
>
>                 Key: DROOLS-248
>                 URL: https://issues.jboss.org/browse/DROOLS-248
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.CR2
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Blocker
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> declare trait A 
>  f : String
> end
> declare trait B
>  g : String
> end
> declare trait C extends A, B
>  h : String
> end
> C will only inherit fields from A

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 05:01:03 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 05:01:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-255) Parent traits may block child
In-Reply-To: <JIRA.12500266.1378639395000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500266.1378639395000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500266.1378639395000.20916.1383037263347@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-255:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> Parent traits may block child
> -----------------------------
>
>                 Key: DROOLS-255
>                 URL: https://issues.jboss.org/browse/DROOLS-255
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final,  6.0.0.CR3
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>
> TBD

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 05:01:03 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 05:01:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-255) Parent traits may block child
In-Reply-To: <JIRA.12500266.1378639395000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500266.1378639395000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500266.1378639395000.20924.1383037263664@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-255.
--------------------------------

    Fix Version/s: 5.5.1.Final
                   6.0.0.Final
       Resolution: Done

    
> Parent traits may block child
> -----------------------------
>
>                 Key: DROOLS-255
>                 URL: https://issues.jboss.org/browse/DROOLS-255
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final,  6.0.0.CR3
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> TBD

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 05:01:03 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 05:01:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-265) Enable recursive traiting
 and dynamic field typing
In-Reply-To: <JIRA.12500877.1379467491000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500877.1379467491000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500877.1379467491000.20931.1383037263989@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-265:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> Enable recursive traiting and dynamic field typing
> --------------------------------------------------
>
>                 Key: DROOLS-265
>                 URL: https://issues.jboss.org/browse/DROOLS-265
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Critical
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> Consider the following scenario: 
> declare trait A 
>   sub : int 
> end
> declare X end
> declare trait Foo
>   fld : A
> end
> declare Bar
> @Traitable( logic = true )  // new mode
>   fld : X
> end
> If an instance b of Bar is traited with Foo, the value of its field "fld" 
> should in turn be traited with A.
> Truth maintenance and transparent casting are required. 
> The goal is to write rules such as:
> when Foo( fld isA A, fld.sub == 0, .... ) then ..

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 05:01:04 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 05:01:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-265) Enable recursive traiting
 and dynamic field typing
In-Reply-To: <JIRA.12500877.1379467491000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500877.1379467491000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500877.1379467491000.20933.1383037264117@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-265.
--------------------------------

    Resolution: Done

    
> Enable recursive traiting and dynamic field typing
> --------------------------------------------------
>
>                 Key: DROOLS-265
>                 URL: https://issues.jboss.org/browse/DROOLS-265
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Critical
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> Consider the following scenario: 
> declare trait A 
>   sub : int 
> end
> declare X end
> declare trait Foo
>   fld : A
> end
> declare Bar
> @Traitable( logic = true )  // new mode
>   fld : X
> end
> If an instance b of Bar is traited with Foo, the value of its field "fld" 
> should in turn be traited with A.
> Truth maintenance and transparent casting are required. 
> The goal is to write rules such as:
> when Foo( fld isA A, fld.sub == 0, .... ) then ..

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 05:03:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 05:03:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-277) Trait Handles are not
 (de)serialized correctly
In-Reply-To: <JIRA.12501759.1380309540000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501759.1380309540000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501759.1380309540000.20938.1383037382183@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-277:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> Trait Handles are not (de)serialized correctly
> ----------------------------------------------
>
>                 Key: DROOLS-277
>                 URL: https://issues.jboss.org/browse/DROOLS-277
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final,  6.0.0.CR3
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>
> TraitFactHandles are not covered by the Protobuf Input/Output Marshallers, which return normal fact handles. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 05:03:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 05:03:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-277) Trait Handles are not
 (de)serialized correctly
In-Reply-To: <JIRA.12501759.1380309540000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501759.1380309540000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501759.1380309540000.20941.1383037382363@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-277.
--------------------------------

    Fix Version/s: 5.5.1.Final
                   6.0.0.Final
       Resolution: Done

    
> Trait Handles are not (de)serialized correctly
> ----------------------------------------------
>
>                 Key: DROOLS-277
>                 URL: https://issues.jboss.org/browse/DROOLS-277
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final,  6.0.0.CR3
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> TraitFactHandles are not covered by the Protobuf Input/Output Marshallers, which return normal fact handles. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 05:03:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 05:03:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-301) NPE when a trait's soft
 field has index 32 or more
In-Reply-To: <JIRA.12503808.1381992872000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503808.1381992872000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503808.1381992872000.20944.1383037382475@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-301:
----------------------------------

    Assignee: Mario Fusco  (was: Davide Sottara)

    
> NPE when a trait's soft field has index 32 or more
> --------------------------------------------------
>
>                 Key: DROOLS-301
>                 URL: https://issues.jboss.org/browse/DROOLS-301
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.CR5
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> Create a trait with more than 32 fields
> Make sure that any field beyond the 32nd is a "soft" field when donning a core object: and NPE will be thrown

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 05:03:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 05:03:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-301) NPE when a trait's soft
 field has index 32 or more
In-Reply-To: <JIRA.12503808.1381992872000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503808.1381992872000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503808.1381992872000.20947.1383037382700@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-301.
--------------------------------

    Resolution: Done

    
> NPE when a trait's soft field has index 32 or more
> --------------------------------------------------
>
>                 Key: DROOLS-301
>                 URL: https://issues.jboss.org/browse/DROOLS-301
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.CR5
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> Create a trait with more than 32 fields
> Make sure that any field beyond the 32nd is a "soft" field when donning a core object: and NPE will be thrown

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 05:03:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 05:03:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-309) Multiple threads working
 with traits against same knowledge base hangs
In-Reply-To: <JIRA.12508490.1382455844000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508490.1382455844000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508490.1382455844000.20951.1383037382900@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-309:
----------------------------------

    Assignee: Mario Fusco  (was: Davide Sottara)

    
> Multiple threads working with traits against same knowledge base hangs
> ----------------------------------------------------------------------
>
>                 Key: DROOLS-309
>                 URL: https://issues.jboss.org/browse/DROOLS-309
>             Project: Drools
>          Issue Type: Quality Risk
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: James Myers
>            Assignee: Mario Fusco
>
> In our web system, we are creating new StatefulKnowledgeSession per user session and executing a set of rules containing trait donning.  This starts to hang (seemingly indefinitely) with following type of stack trace (usually initiated from insert/update):
> {quote}
>    java.lang.Thread.State: RUNNABLE
> 	at org.drools.core.util.TripleStore.getAll(TripleStore.java:188)
> 	at org.drools.factmodel.traits.TripleBasedStruct.getTriplesForSubject(TripleBasedStruct.java:165)
> 	at org.drools.factmodel.traits.ThingorgdroolsfactmodeltraitsTraitSession$ItemWrapperProxyWrapper.hashCode(Unknown Source)
> 	at org.drools.factmodel.traits.TraitProxy.hashCode(TraitProxy.java:110)
> 	at org.drools.factmodel.traits.ThingorgdroolsfactmodeltraitsTraitSession$ItemWrapperProxy.hashCode(Unknown Source)
> 	at org.drools.common.DefaultFactHandle.<init>(DefaultFactHandle.java:110)
> 	at org.drools.common.DefaultFactHandle.<init>(DefaultFactHandle.java:98)
> 	at org.drools.common.TraitFactHandle.<init>(TraitFactHandle.java:26)
> 	at org.drools.reteoo.ReteooFactHandleFactory.newFactHandle(ReteooFactHandleFactory.java:80)
> 	at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:68)
> 	at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:53)
> 	at org.drools.common.NamedEntryPoint.createHandle(NamedEntryPoint.java:765)
> 	at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:301)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903)
> {quote}
> Here is a unit test for org.drools.factmodel.traits.TraitTest.  It's not perfect because it will spawn thread that might never die and may need thread/iteration count increased to fail consistently, but capturing a stack trace a few seconds in should show all threads in "getAll()":
> {code}
>     @Traitable
>     public static class Item {
>     	private String id;
>     	public String getId() {
>     		return id;
>     	}
>     	public void setId(String id) {
>     		this.id = id;
>     	}
>     }
>     public static class TraitRulesThread implements Runnable {
>     	int threadIndex;
>     	int numRepetitions;
>     	StatefulKnowledgeSession ksession;
>     	public TraitRulesThread(int threadIndex, int numRepetitions, final StatefulKnowledgeSession ksession) {
>     		this.threadIndex = threadIndex;
>     		this.numRepetitions = numRepetitions;
>     		this.ksession = ksession;
>     	}
>     	public void run() {
>     		for (int repetitionIndex = 0; repetitionIndex < numRepetitions; repetitionIndex++) {
>     			final Item i = new Item();
>     			i.setId(String.format("testId_%d%d", threadIndex, repetitionIndex));
>     			ksession.insert(i);
>     			ksession.fireAllRules();
>     		}
>     	}
>     }
>     @Test
>     public void testMultithreadingTraits() throws InterruptedException {
>     	final String s1 = "package test;\n" +
>     	"import org.drools.factmodel.traits.TraitTest.Item;\n" +
>     	"declare Item end\n" +
>     	"declare trait ItemStyle\n" +
>     	"	id: String\n" +
>     	"	adjustable: boolean\n" +
>     	"end\n" +
>     	"rule \"Don ItemStyle\"\n" +
>     	"	no-loop true\n" +
>     	"	when\n" +
>     	"		$p : Item ()\n" +
>     	"		not ItemStyle ( id == $p.id )\n" +
>     	"	then\n" +
>     	"		don($p, ItemStyle.class);\n" +
>     	"end\n" +
>     	"rule \"Item Style - Adjustable\"" +
>     	"	no-loop true" +
>     	"	when" +
>     	"		$style : ItemStyle ( !adjustable )" +
>     	"		Item (" +
>     	"			id == $style.id " +
>     	"		)" +
>     	"	then" +
>     	"		modify($style) {" +
>     	"			setAdjustable(true)" +
>     	"		};" +
>     	"end";
>     	final KnowledgeBase kbase = getKnowledgeBaseFromString(s1);
>     	// might need to tweak these numbers.  often works with 7-10,100,60, but often fails 15-20,100,60
>     	int MAX_THREADS = 20;
>     	int MAX_REPETITIONS = 100;
>     	int MAX_WAIT_SECONDS = 60;
>     	final ExecutorService executorService = Executors.newFixedThreadPool(MAX_THREADS);
>     	for (int threadIndex = 0; threadIndex < MAX_THREADS; threadIndex++) {
>     		executorService.execute(new TraitRulesThread(threadIndex, MAX_REPETITIONS, kbase.newStatefulKnowledgeSession()));
>     	}
>     	executorService.shutdown();
>     	executorService.awaitTermination(MAX_WAIT_SECONDS, TimeUnit.SECONDS);
>     	final List<Runnable> queuedTasks = executorService.shutdownNow();
>     	assertEquals(0, queuedTasks.size());
>     	assertEquals(true, executorService.isTerminated());
>     }
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 05:03:03 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 05:03:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-309) Multiple threads working
 with traits against same knowledge base hangs
In-Reply-To: <JIRA.12508490.1382455844000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508490.1382455844000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508490.1382455844000.20955.1383037383173@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-309.
--------------------------------

    Fix Version/s: 5.5.1.Final
                   6.0.0.Final
       Resolution: Done

    
> Multiple threads working with traits against same knowledge base hangs
> ----------------------------------------------------------------------
>
>                 Key: DROOLS-309
>                 URL: https://issues.jboss.org/browse/DROOLS-309
>             Project: Drools
>          Issue Type: Quality Risk
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: James Myers
>            Assignee: Mario Fusco
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> In our web system, we are creating new StatefulKnowledgeSession per user session and executing a set of rules containing trait donning.  This starts to hang (seemingly indefinitely) with following type of stack trace (usually initiated from insert/update):
> {quote}
>    java.lang.Thread.State: RUNNABLE
> 	at org.drools.core.util.TripleStore.getAll(TripleStore.java:188)
> 	at org.drools.factmodel.traits.TripleBasedStruct.getTriplesForSubject(TripleBasedStruct.java:165)
> 	at org.drools.factmodel.traits.ThingorgdroolsfactmodeltraitsTraitSession$ItemWrapperProxyWrapper.hashCode(Unknown Source)
> 	at org.drools.factmodel.traits.TraitProxy.hashCode(TraitProxy.java:110)
> 	at org.drools.factmodel.traits.ThingorgdroolsfactmodeltraitsTraitSession$ItemWrapperProxy.hashCode(Unknown Source)
> 	at org.drools.common.DefaultFactHandle.<init>(DefaultFactHandle.java:110)
> 	at org.drools.common.DefaultFactHandle.<init>(DefaultFactHandle.java:98)
> 	at org.drools.common.TraitFactHandle.<init>(TraitFactHandle.java:26)
> 	at org.drools.reteoo.ReteooFactHandleFactory.newFactHandle(ReteooFactHandleFactory.java:80)
> 	at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:68)
> 	at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:53)
> 	at org.drools.common.NamedEntryPoint.createHandle(NamedEntryPoint.java:765)
> 	at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:301)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903)
> {quote}
> Here is a unit test for org.drools.factmodel.traits.TraitTest.  It's not perfect because it will spawn thread that might never die and may need thread/iteration count increased to fail consistently, but capturing a stack trace a few seconds in should show all threads in "getAll()":
> {code}
>     @Traitable
>     public static class Item {
>     	private String id;
>     	public String getId() {
>     		return id;
>     	}
>     	public void setId(String id) {
>     		this.id = id;
>     	}
>     }
>     public static class TraitRulesThread implements Runnable {
>     	int threadIndex;
>     	int numRepetitions;
>     	StatefulKnowledgeSession ksession;
>     	public TraitRulesThread(int threadIndex, int numRepetitions, final StatefulKnowledgeSession ksession) {
>     		this.threadIndex = threadIndex;
>     		this.numRepetitions = numRepetitions;
>     		this.ksession = ksession;
>     	}
>     	public void run() {
>     		for (int repetitionIndex = 0; repetitionIndex < numRepetitions; repetitionIndex++) {
>     			final Item i = new Item();
>     			i.setId(String.format("testId_%d%d", threadIndex, repetitionIndex));
>     			ksession.insert(i);
>     			ksession.fireAllRules();
>     		}
>     	}
>     }
>     @Test
>     public void testMultithreadingTraits() throws InterruptedException {
>     	final String s1 = "package test;\n" +
>     	"import org.drools.factmodel.traits.TraitTest.Item;\n" +
>     	"declare Item end\n" +
>     	"declare trait ItemStyle\n" +
>     	"	id: String\n" +
>     	"	adjustable: boolean\n" +
>     	"end\n" +
>     	"rule \"Don ItemStyle\"\n" +
>     	"	no-loop true\n" +
>     	"	when\n" +
>     	"		$p : Item ()\n" +
>     	"		not ItemStyle ( id == $p.id )\n" +
>     	"	then\n" +
>     	"		don($p, ItemStyle.class);\n" +
>     	"end\n" +
>     	"rule \"Item Style - Adjustable\"" +
>     	"	no-loop true" +
>     	"	when" +
>     	"		$style : ItemStyle ( !adjustable )" +
>     	"		Item (" +
>     	"			id == $style.id " +
>     	"		)" +
>     	"	then" +
>     	"		modify($style) {" +
>     	"			setAdjustable(true)" +
>     	"		};" +
>     	"end";
>     	final KnowledgeBase kbase = getKnowledgeBaseFromString(s1);
>     	// might need to tweak these numbers.  often works with 7-10,100,60, but often fails 15-20,100,60
>     	int MAX_THREADS = 20;
>     	int MAX_REPETITIONS = 100;
>     	int MAX_WAIT_SECONDS = 60;
>     	final ExecutorService executorService = Executors.newFixedThreadPool(MAX_THREADS);
>     	for (int threadIndex = 0; threadIndex < MAX_THREADS; threadIndex++) {
>     		executorService.execute(new TraitRulesThread(threadIndex, MAX_REPETITIONS, kbase.newStatefulKnowledgeSession()));
>     	}
>     	executorService.shutdown();
>     	executorService.awaitTermination(MAX_WAIT_SECONDS, TimeUnit.SECONDS);
>     	final List<Runnable> queuedTasks = executorService.shutdownNow();
>     	assertEquals(0, queuedTasks.size());
>     	assertEquals(true, executorService.isTerminated());
>     }
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 05:05:01 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 05:05:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-313) Support internal
 @Annotations with default values
In-Reply-To: <JIRA.12508851.1382826935000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508851.1382826935000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508851.1382826935000.20958.1383037501969@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-313:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> Support internal @Annotations with default values
> -------------------------------------------------
>
>                 Key: DROOLS-313
>                 URL: https://issues.jboss.org/browse/DROOLS-313
>             Project: Drools
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.CR5
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Minor
>
> Annotations such as @Eager and @ActivationListener require an explicit value, or an exception will be thrown

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 05:05:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 05:05:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-313) Support internal
 @Annotations with default values
In-Reply-To: <JIRA.12508851.1382826935000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508851.1382826935000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508851.1382826935000.20963.1383037502228@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-313.
--------------------------------

    Fix Version/s: 5.5.1.Final
                   6.0.0.Final
       Resolution: Done

    
> Support internal @Annotations with default values
> -------------------------------------------------
>
>                 Key: DROOLS-313
>                 URL: https://issues.jboss.org/browse/DROOLS-313
>             Project: Drools
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.CR5
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Minor
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> Annotations such as @Eager and @ActivationListener require an explicit value, or an exception will be thrown

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 05:10:01 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 05:10:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-293) Out of order RightTuples
 when adding rules dynamically
In-Reply-To: <JIRA.12502549.1381317479000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502549.1381317479000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502549.1381317479000.20966.1383037801953@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-293.
--------------------------------

    Fix Version/s: 5.5.1.Final
                   6.0.0.Final
       Resolution: Done

    
> Out of order RightTuples when adding rules dynamically
> ------------------------------------------------------
>
>                 Key: DROOLS-293
>                 URL: https://issues.jboss.org/browse/DROOLS-293
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final,  6.0.0.CR4
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> When a a rule is dynamically added to the rule base the otnId for the newly created nodes is set on them lazily. In some cases this otnId setting is done too late causing the RightTuples, created as consequence of the addition of the new rule itself, to be added out of order in the respective FactHandles.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 05:12:01 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 05:12:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-300) Add optional start and end
 arguments to timers
In-Reply-To: <JIRA.12503113.1381861876000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503113.1381861876000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503113.1381861876000.20968.1383037921915@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-300.
--------------------------------

    Fix Version/s: 5.5.1.Final
                   6.0.0.Final
       Resolution: Done

    
> Add optional start and end arguments to timers
> ----------------------------------------------
>
>                 Key: DROOLS-300
>                 URL: https://issues.jboss.org/browse/DROOLS-300
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 05:35:01 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 29 Oct 2013 05:35:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1724) GMS: join and immediate leave
 of coordinator doesn't install new view
In-Reply-To: <JIRA.12508931.1383039280397@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508931.1383039280397@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508931.1383039280397.21020.1383039301971@jira02.app.mwc.hst.phx2.redhat.com>

Bela Ban created JGRP-1724:
------------------------------

             Summary: GMS: join and immediate leave of coordinator doesn't install new view
                 Key: JGRP-1724
                 URL: https://issues.jboss.org/browse/JGRP-1724
             Project: JGroups
          Issue Type: Bug
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 3.4.1, 3.5


When we have coord A and B, the following can happen:
* A joins: view=A|0
* B joins: view=A|1
* A leaves, view B|2 should be multicast by A to B
--> B|2 is never received by B. B has to wait until failure detection detects that A is absent and installs a new view
--> This is not incorrect, but takes more time than A installing the last view B|2 before it leaves

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 05:39:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 29 Oct 2013 05:39:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1724) GMS: join and immediate leave
 of coordinator doesn't install new view
In-Reply-To: <JIRA.12508931.1383039280000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508931.1383039280000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508931.1383039280000.21023.1383039542037@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1724:
---------------------------

    Description: 
When we have coord A and B, the following can happen:
* A joins: view=A|0
* B joins: view=A|1
* A leaves, view B|2 should be multicast by A to B
--> B|2 is never received by B. B has to wait until failure detection detects that A is absent and installs a new view
--> This is not incorrect, but takes more time than A installing the last view B|2 before it leaves

The reason is that CoordGmsImpl.leave() sets {{leaving}} to true, which changes the impl from CoordGmsImpl to ClientGmsImpl. However, the latter doesn't handle the LEAVE request.

SOLUTION:
* Instead of using field {{leaving}}, use a (stack-based) variable {{is_leaving}} in handleMembershipChange().

  was:
When we have coord A and B, the following can happen:
* A joins: view=A|0
* B joins: view=A|1
* A leaves, view B|2 should be multicast by A to B
--> B|2 is never received by B. B has to wait until failure detection detects that A is absent and installs a new view
--> This is not incorrect, but takes more time than A installing the last view B|2 before it leaves


    
> GMS: join and immediate leave of coordinator doesn't install new view
> ---------------------------------------------------------------------
>
>                 Key: JGRP-1724
>                 URL: https://issues.jboss.org/browse/JGRP-1724
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4.1, 3.5
>
>
> When we have coord A and B, the following can happen:
> * A joins: view=A|0
> * B joins: view=A|1
> * A leaves, view B|2 should be multicast by A to B
> --> B|2 is never received by B. B has to wait until failure detection detects that A is absent and installs a new view
> --> This is not incorrect, but takes more time than A installing the last view B|2 before it leaves
> The reason is that CoordGmsImpl.leave() sets {{leaving}} to true, which changes the impl from CoordGmsImpl to ClientGmsImpl. However, the latter doesn't handle the LEAVE request.
> SOLUTION:
> * Instead of using field {{leaving}}, use a (stack-based) variable {{is_leaving}} in handleMembershipChange().

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 05:48:02 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Tue, 29 Oct 2013 05:48:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2396) MessagingSubsystem20TestCase
	keeps failing
In-Reply-To: <JIRA.12508917.1383019754000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508917.1383019754000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508917.1383019754000.21042.1383040082068@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen closed WFLY-2396.
---------------------------------

    Resolution: Rejected


Stupid Maven
                
> MessagingSubsystem20TestCase keeps failing
> ------------------------------------------
>
>                 Key: WFLY-2396
>                 URL: https://issues.jboss.org/browse/WFLY-2396
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS, Test Suite
>    Affects Versions: 8.0.0.CR1
>            Reporter: Jesper Pedersen
>            Assignee: Jeff Mesnil
>         Attachments: org.jboss.as.messaging.test.MessagingSubsystem20TestCase.txt
>
>
> Current master (2013/10/29) - commit f68fb13c12bdf756c29f56e696edc8549b0279bd

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 05:52:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Tue, 29 Oct 2013 05:52:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2391) Wildfly caches content in
 exploded mode, breaking developer productivity
In-Reply-To: <JIRA.12508879.1382966687000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508879.1382966687000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508879.1382966687000.21053.1383040322182@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas updated WFLY-2391:
---------------------------------

    Workaround Description: Delete the <buffer-cache> element from the undertow subsystem.
                Workaround: Workaround Exists

    
> Wildfly caches content in exploded mode, breaking developer productivity
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2391
>                 URL: https://issues.jboss.org/browse/WFLY-2391
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>         Environment: MacOSX with JBossTools 4.1.1.Beta1
>            Reporter: Xavier Coulon
>         Attachments: jboss-as-kitchensink-html5-mobile.war.zip
>
>
> While I was building a sample application with JBoss Tools 4.1.1.beta1 on WildFly 8.0.Beta1, I noticed that after a few minutes (or a few browser requests), the content of my index.html file seemed to be cached by the server, although I used the "exploded content" deployment mode (since I published the content using the WildFly Server Adapter in JBoss Tools).
>  
> I checked the actual content of the index.html in the deployments folder and it contained the latest changes, which means that the JBoss Tools Server Adapter is doing its job well ;-)
> I also tried to edit the index.html file directly in the deployments folder, and once again, I got no update in both Chrome and Firefox browsers.
>  
> I checked in the "Network" tab of the browsers and could see that the server response for the index.html page had a "200 OK" status, which means that there's no browser caching involved.
> I tried to get the index.html page with cUrl and got the same old version, which definitely excludes a browser caching issue.
> At the end of the dat, this means that after a few changes, my browsers keep getting an old version of the deployed resources, which in turns means that I have to stop and restart the server to get the new content, and this is pretty bad in term of dev productivity.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 05:54:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Tue, 29 Oct 2013 05:54:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2391) Wildfly caches content in
 exploded mode, breaking developer productivity
In-Reply-To: <JIRA.12508879.1382966687000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508879.1382966687000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508879.1382966687000.21059.1383040442097@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFLY-2391:
------------------------------------

    Assignee: Stuart Douglas

    
> Wildfly caches content in exploded mode, breaking developer productivity
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2391
>                 URL: https://issues.jboss.org/browse/WFLY-2391
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>         Environment: MacOSX with JBossTools 4.1.1.Beta1
>            Reporter: Xavier Coulon
>            Assignee: Stuart Douglas
>         Attachments: jboss-as-kitchensink-html5-mobile.war.zip
>
>
> While I was building a sample application with JBoss Tools 4.1.1.beta1 on WildFly 8.0.Beta1, I noticed that after a few minutes (or a few browser requests), the content of my index.html file seemed to be cached by the server, although I used the "exploded content" deployment mode (since I published the content using the WildFly Server Adapter in JBoss Tools).
>  
> I checked the actual content of the index.html in the deployments folder and it contained the latest changes, which means that the JBoss Tools Server Adapter is doing its job well ;-)
> I also tried to edit the index.html file directly in the deployments folder, and once again, I got no update in both Chrome and Firefox browsers.
>  
> I checked in the "Network" tab of the browsers and could see that the server response for the index.html page had a "200 OK" status, which means that there's no browser caching involved.
> I tried to get the index.html page with cUrl and got the same old version, which definitely excludes a browser caching issue.
> At the end of the dat, this means that after a few changes, my browsers keep getting an old version of the deployed resources, which in turns means that I have to stop and restart the server to get the new content, and this is pretty bad in term of dev productivity.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 06:08:02 2013
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Tue, 29 Oct 2013 06:08:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2402) fix clustered attribute
 transformation warning
In-Reply-To: <JIRA.12508935.1383041231383@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508935.1383041231383@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508935.1383041231383.21125.1383041282221@jira02.app.mwc.hst.phx2.redhat.com>

Jeff Mesnil created WFLY-2402:
---------------------------------

             Summary: fix clustered attribute transformation warning
                 Key: WFLY-2402
                 URL: https://issues.jboss.org/browse/WFLY-2402
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JMS
    Affects Versions: 8.0.0.Beta1
            Reporter: Jeff Mesnil
            Assignee: Jeff Mesnil
            Priority: Minor
             Fix For: 8.0.0.CR1


The code in MessagingTransformers#registerTransformers_1_2_0 to check whether there is a conflict between the clustered state of hornetq-server and the attribute value is not correct and the user is not warned in case of conflict.

context.readResource(PathAddress.EMPTY_ADDRESS) corresponds to the root of the server (/) and there is never any "cluster-connection" children there.
Correct path to read the hornetq-server resource is contex.readResource(address)


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 06:10:02 2013
From: jira-events at lists.jboss.org (Stefano Maestri (JIRA))
Date: Tue, 29 Oct 2013 06:10:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2403) Cannot disable Datasource or
 XADatasource in standalone and domain modes
In-Reply-To: <JIRA.12508938.1383041378355@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508938.1383041378355@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508938.1383041378355.21137.1383041402154@jira02.app.mwc.hst.phx2.redhat.com>

Stefano Maestri created WFLY-2403:
-------------------------------------

             Summary: Cannot disable Datasource or XADatasource in standalone and domain modes
                 Key: WFLY-2403
                 URL: https://issues.jboss.org/browse/WFLY-2403
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Stefano Maestri
            Assignee: Stefano Maestri


Description of problem:
Cannot disable a Datasource or XADatasource in standalone mode. It's back to enabled state after server reload.

Version-Release number of selected component (if applicable):
6.1

How reproducible:
Always

Steps to Reproduce:
Use the http management interface or the CLI
1.Create a Datasource of XADatasource
2.Disable it
3.The response indicates a server reload is required
4.Execute the reload operation

Actual results:
The datasource is back to enabled state

Expected results:
The datasource should be in disabled state

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 06:12:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 29 Oct 2013 06:12:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2403) Cannot disable Datasource or
 XADatasource in standalone and domain modes
In-Reply-To: <JIRA.12508938.1383041378000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508938.1383041378000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508938.1383041378000.21142.1383041522262@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2403:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=970679

    
> Cannot disable Datasource or XADatasource in standalone and domain modes
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2403
>                 URL: https://issues.jboss.org/browse/WFLY-2403
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Stefano Maestri
>            Assignee: Stefano Maestri
>
> Description of problem:
> Cannot disable a Datasource or XADatasource in standalone mode. It's back to enabled state after server reload.
> Version-Release number of selected component (if applicable):
> 6.1
> How reproducible:
> Always
> Steps to Reproduce:
> Use the http management interface or the CLI
> 1.Create a Datasource of XADatasource
> 2.Disable it
> 3.The response indicates a server reload is required
> 4.Execute the reload operation
> Actual results:
> The datasource is back to enabled state
> Expected results:
> The datasource should be in disabled state

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 06:30:02 2013
From: jira-events at lists.jboss.org (Chris R. (JIRA))
Date: Tue, 29 Oct 2013 06:30:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2391) Wildfly caches content in
 exploded mode, breaking developer productivity
In-Reply-To: <JIRA.12508879.1382966687000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508879.1382966687000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508879.1382966687000.21206.1383042602109@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825455#comment-12825455 ] 

Chris R. commented on WFLY-2391:
--------------------------------

I removed 
                <buffer-cache name="default" buffer-size="1024" buffers-per-region="1024" max-regions="10"/>

I'm unable to deploy my projects now:

11:27:20,808 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "foo_frontend.war")]) - failure description: {"JBAS014879: One or more services were unable to start due to one or more indirect dependencies not being available." => {
    "Services that were unable to start:" => ["jboss.deployment.unit.\"foo_frontend.war\".INSTALL"],
    "Services that may be the cause:" => [
        "jboss.remoting.remotingConnectorInfoService.http-remoting-connector",
        "jboss.undertow.bufferCache.default"
    ]
}}


                
> Wildfly caches content in exploded mode, breaking developer productivity
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2391
>                 URL: https://issues.jboss.org/browse/WFLY-2391
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>         Environment: MacOSX with JBossTools 4.1.1.Beta1
>            Reporter: Xavier Coulon
>            Assignee: Stuart Douglas
>         Attachments: jboss-as-kitchensink-html5-mobile.war.zip
>
>
> While I was building a sample application with JBoss Tools 4.1.1.beta1 on WildFly 8.0.Beta1, I noticed that after a few minutes (or a few browser requests), the content of my index.html file seemed to be cached by the server, although I used the "exploded content" deployment mode (since I published the content using the WildFly Server Adapter in JBoss Tools).
>  
> I checked the actual content of the index.html in the deployments folder and it contained the latest changes, which means that the JBoss Tools Server Adapter is doing its job well ;-)
> I also tried to edit the index.html file directly in the deployments folder, and once again, I got no update in both Chrome and Firefox browsers.
>  
> I checked in the "Network" tab of the browsers and could see that the server response for the index.html page had a "200 OK" status, which means that there's no browser caching involved.
> I tried to get the index.html page with cUrl and got the same old version, which definitely excludes a browser caching issue.
> At the end of the dat, this means that after a few changes, my browsers keep getting an old version of the deployed resources, which in turns means that I have to stop and restart the server to get the new content, and this is pretty bad in term of dev productivity.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 07:09:02 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 29 Oct 2013 07:09:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2276) URI ENCODING does not work in
 the beta1 version (UTF-8)
In-Reply-To: <JIRA.12502684.1381404449000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502684.1381404449000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502684.1381404449000.21260.1383044942007@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-2276:
------------------------------

    Fix Version/s: 8.0.0.CR1

    
> URI ENCODING does not work in the beta1 version (UTF-8)
> -------------------------------------------------------
>
>                 Key: WFLY-2276
>                 URL: https://issues.jboss.org/browse/WFLY-2276
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>         Environment: Java 7, ubuntu 12.04
>            Reporter: alexandre xypas
>            Assignee: Tomaz Cerar
>              Labels: encoding, utf-8
>             Fix For: 8.0.0.CR1
>
>
> In standalone.xml, the following is working in Alpha4, but not anymore in Beta1.
> <property name="org.apache.catalina.connector.URI_ENCODING" value="UTF-8"/>
> <property name="org.apache.catalina.connector.USE_BODY_ENCODING_FOR_QUERY_STRING" value="true"/>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 07:13:01 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 29 Oct 2013 07:13:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1724) GMS: join and immediate leave
 of coordinator doesn't install new view
In-Reply-To: <JIRA.12508931.1383039280000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508931.1383039280000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508931.1383039280000.21263.1383045181929@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1724.
----------------------------

    Resolution: Done

    
> GMS: join and immediate leave of coordinator doesn't install new view
> ---------------------------------------------------------------------
>
>                 Key: JGRP-1724
>                 URL: https://issues.jboss.org/browse/JGRP-1724
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4.1, 3.5
>
>
> When we have coord A and B, the following can happen:
> * A joins: view=A|0
> * B joins: view=A|1
> * A leaves, view B|2 should be multicast by A to B
> --> B|2 is never received by B. B has to wait until failure detection detects that A is absent and installs a new view
> --> This is not incorrect, but takes more time than A installing the last view B|2 before it leaves
> The reason is that CoordGmsImpl.leave() sets {{leaving}} to true, which changes the impl from CoordGmsImpl to ClientGmsImpl. However, the latter doesn't handle the LEAVE request.
> SOLUTION:
> * Instead of using field {{leaving}}, use a (stack-based) variable {{is_leaving}} in handleMembershipChange().

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 07:17:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Tue, 29 Oct 2013 07:17:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2391) Wildfly caches content in
 exploded mode, breaking developer productivity
In-Reply-To: <JIRA.12508879.1382966687000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508879.1382966687000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508879.1382966687000.21269.1383045422270@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas updated WFLY-2391:
---------------------------------

    Workaround Description: Delete the <buffer-cache> element from the undertow subsystem, and also remove the default-buffer-cache="default"  element from the servlet container.  (was: Delete the <buffer-cache> element from the undertow subsystem.)

    
> Wildfly caches content in exploded mode, breaking developer productivity
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2391
>                 URL: https://issues.jboss.org/browse/WFLY-2391
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>         Environment: MacOSX with JBossTools 4.1.1.Beta1
>            Reporter: Xavier Coulon
>            Assignee: Stuart Douglas
>         Attachments: jboss-as-kitchensink-html5-mobile.war.zip
>
>
> While I was building a sample application with JBoss Tools 4.1.1.beta1 on WildFly 8.0.Beta1, I noticed that after a few minutes (or a few browser requests), the content of my index.html file seemed to be cached by the server, although I used the "exploded content" deployment mode (since I published the content using the WildFly Server Adapter in JBoss Tools).
>  
> I checked the actual content of the index.html in the deployments folder and it contained the latest changes, which means that the JBoss Tools Server Adapter is doing its job well ;-)
> I also tried to edit the index.html file directly in the deployments folder, and once again, I got no update in both Chrome and Firefox browsers.
>  
> I checked in the "Network" tab of the browsers and could see that the server response for the index.html page had a "200 OK" status, which means that there's no browser caching involved.
> I tried to get the index.html page with cUrl and got the same old version, which definitely excludes a browser caching issue.
> At the end of the dat, this means that after a few changes, my browsers keep getting an old version of the deployed resources, which in turns means that I have to stop and restart the server to get the new content, and this is pretty bad in term of dev productivity.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 07:25:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 29 Oct 2013 07:25:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2319) LDAP Search containing URL -
 InvalidNameException: ldap:: [LDAP: error code 34 - Invalid root Dn given
In-Reply-To: <JIRA.12503254.1381931058000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503254.1381931058000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503254.1381931058000.21290.1383045902202@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825472#comment-12825472 ] 

RH Bugzilla Integration commented on WFLY-2319:
-----------------------------------------------

emartins at redhat.com made a comment on [bug 1014911|https://bugzilla.redhat.com/show_bug.cgi?id=1014911]

Have you tried to use String base = "dc=sample,dc=com"; ? ldap:// names are to be used with no environment properties map, and the handling of such jndi names is mostly what we are fixing here, so proper names for LdapCtxFactory should work at the moment.

Here is an example of proper usage on Oracle JNDI LDAP docs:

http://docs.oracle.com/javase/jndi/tutorial/basics/directory/src/SearchRetAll.java
                
> LDAP Search containing URL - InvalidNameException: ldap:: [LDAP: error code 34 - Invalid root Dn given
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2319
>                 URL: https://issues.jboss.org/browse/WFLY-2319
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Darran Lofthouse
>            Assignee: Eduardo Martins
>             Fix For: 8.0.0.CR1
>
>         Attachments: LdapSearching.tgz
>
>
> The following code: -
> {code}
>         Hashtable env = new Hashtable();
>         env.put("java.naming.factory.initial", "com.sun.jndi.ldap.LdapCtxFactory");
>         env.put("java.naming.security.authentication", "simple");
>         env.put("java.naming.provider.url", "ldap://localhost:10389");
>         env.put(InitialDirContext.SECURITY_PRINCIPAL, "uid=admin,ou=system");
>         env.put(InitialDirContext.SECURITY_CREDENTIALS, "secret");
>         SearchControls ctl = null;
>         String attrArr[] = new String[1];
>         attrArr[0] = "sn";
>         ctl = new SearchControls(2, 0L, 0, attrArr, false, false);
>         String base = "ldap://localhost:10389/dc=simple,dc=wildfly,dc=org";
>         String filter = "(uid=UserOne)";
>         NamingEnumeration nenum = null;
>         DirContext ictx = null;
>             ictx = new InitialDirContext(env);
>             nenum = ictx.search(base, filter, ctl);
> {code}
> Results in the following exception: -
> {noquote}
> 13:03:45,598 ERROR [stderr] (default task-1) javax.naming.InvalidNameException: ldap:: [LDAP: error code 34 - Invalid root Dn given : ldap: (0x6C 0x64 0x61 0x70 0x3A ) is invalid]; remaining name 'ldap://localhost:10389/dc=simple,dc=wildfly,dc=org'
> 13:03:45,599 ERROR [stderr] (default task-1) 	at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3025)
> 13:03:45,600 ERROR [stderr] (default task-1) 	at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2840)
> 13:03:45,600 ERROR [stderr] (default task-1) 	at com.sun.jndi.ldap.LdapCtx.c_lookup(LdapCtx.java:1034)
> {noquote}
> Switching to a base that does not begin with a URL and the search works, executing this code outside of WildFly also works.
> The underlying issue is that the default InitialContext implementation contains the following method: -
> {code}
>     protected Context getURLOrDefaultInitCtx(String name)
>         throws NamingException {
>         if (NamingManager.hasInitialContextFactoryBuilder()) {
>             return getDefaultInitCtx();
>         }
>         String scheme = getURLScheme(name);
>         if (scheme != null) {
>             Context ctx = NamingManager.getURLContext(scheme, myProps);
>             if (ctx != null) {
>                 return ctx;
>             }
>         }
>         return getDefaultInitCtx();
>     }
> {code}
> As the naming subsystem has registered a InitialContextFactoryBuilder this code will never fall down to the scheme specific section.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 07:44:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 29 Oct 2013 07:44:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-764) Move JBoss Negotiation to
	GIT
In-Reply-To: <JIRA.12508944.1383046978155@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508944.1383046978155@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508944.1383046978155.21298.1383047042241@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created SECURITY-764:
-----------------------------------------

             Summary: Move JBoss Negotiation to GIT
                 Key: SECURITY-764
                 URL: https://issues.jboss.org/browse/SECURITY-764
             Project: PicketBox 
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Negotiation
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: Negotiation_2_2_7


Updates to JBoss Negotiation how now slowed down considerably, time to get it moved over to git so that for ongoing maintenance it is in a repository consistent with the project making use of it.

https://github.com/wildfly/jboss-negotiation

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 07:58:01 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 29 Oct 2013 07:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-760) Make the JBoss Negotiation
 dependency on JBoss Web - Provided
In-Reply-To: <JIRA.12508666.1382606869000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508666.1382606869000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508666.1382606869000.21317.1383047881936@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/SECURITY-760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825475#comment-12825475 ] 

RH Bugzilla Integration commented on SECURITY-760:
--------------------------------------------------

sgilda at redhat.com made a comment on [bug 1022679|https://bugzilla.redhat.com/show_bug.cgi?id=1022679]

What is the current status of this bug? I'm still getting Jenkins build errors.
                
> Make the JBoss Negotiation dependency on JBoss Web - Provided
> -------------------------------------------------------------
>
>                 Key: SECURITY-760
>                 URL: https://issues.jboss.org/browse/SECURITY-760
>             Project: PicketBox 
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: Negotiation_2_2_6
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 08:06:01 2013
From: jira-events at lists.jboss.org (Julien Derveeuw (JIRA))
Date: Tue, 29 Oct 2013 08:06:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBASMP-58) jboss-as-maven-plugin freezes
 on authentication
In-Reply-To: <JIRA.12508946.1383048331274@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508946.1383048331274@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508946.1383048331274.21325.1383048361978@jira02.app.mwc.hst.phx2.redhat.com>

Julien Derveeuw created JBASMP-58:
-------------------------------------

             Summary: jboss-as-maven-plugin freezes on authentication
                 Key: JBASMP-58
                 URL: https://issues.jboss.org/browse/JBASMP-58
             Project: JBoss AS Maven Plugins
          Issue Type: Bug
          Components: deploy
    Affects Versions: 7.5.Final
         Environment: mac os x 10.8.5
            Reporter: Julien Derveeuw
            Assignee: James Perkins
            Priority: Critical


I have jboss 7.1.1 in standalone mode running on machine A (linux).
I want to deploy remotely to it using client machine B @ mac os X 10.8.5 / JDK 1.7.0_45-b18.

If I connect from B to A using jboss-cli, everything works fine, I am able to login.

If I try to deploy from maven with this :
            <plugin>
                <groupId>org.jboss.as.plugins</groupId>
                <artifactId>jboss-as-maven-plugin</artifactId>
                <version>7.5.Final</version>
                <configuration>
                    <hostname>${deploy.jboss.host}</hostname>
                    <port>${deploy.jboss.port}</port>
                    <username>${deploy.jboss.user}</username>
                    <password>${deploy.jboss.password}</password>
                </configuration>

                <executions>
                    <execution>
                        <phase>install</phase>
                        <goals>
                            <goal>deploy</goal>
                        </goals>
                    </execution>
                </executions>

plugin freezes indefinitely on 
Authenticating against security realm: ManagementRealm
No more details are available with mvn -X

If I remove the password or username from pom, it fails correctly with :
The connection failed: Authentication failed: all available authentication mechanisms failed

After digging on google, I ended up adding -Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.KQueueSelectorProvider to mvn runner options because NIOs on jdk7 at macosx is said to be buggy but it didn't help.



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 08:19:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 29 Oct 2013 08:19:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1723) Corrupted input stream on
	STATE exchange
In-Reply-To: <JIRA.12508721.1382628956000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508721.1382628956000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508721.1382628956000.21345.1383049142428@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825479#comment-12825479 ] 

Bela Ban commented on JGRP-1723:
--------------------------------

Looks like only STATE.buffer_size bytes are written to the BlockingInputStream at the receiver (even though 1'000'000 bytes are received).
                
> Corrupted input stream on STATE exchange
> ----------------------------------------
>
>                 Key: JGRP-1723
>                 URL: https://issues.jboss.org/browse/JGRP-1723
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.3.4, 3.4
>         Environment: java7u25
>            Reporter: Mathieu Bernatet
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>         Attachments: corruptedStreamOnStateExchange.zip
>
>
> Using the pbcast.STATE state transfer protocol with a high volume of data, the receiver member on setState seem to get a corrupted input stream.
> I was able to reproduce this issue with a simple project in which the data get corrupted from the 8192th byte. So it may be related to frag size with default value of 8192. We get this bug either with FRAG or FRAG2.
> Related discussion on the mailing list could be found here : http://jgroups.1086181.n5.nabble.com/Corrupted-input-stream-on-STATE-exchange-td9938.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 08:23:02 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 29 Oct 2013 08:23:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2404) Port SingleSignOn Valve to
 Undertow auth mechanism
In-Reply-To: <JIRA.12508947.1383049267065@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508947.1383049267065@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508947.1383049267065.21352.1383049382016@jira02.app.mwc.hst.phx2.redhat.com>

Tomaz Cerar created WFLY-2404:
---------------------------------

             Summary: Port SingleSignOn Valve to Undertow auth mechanism
                 Key: WFLY-2404
                 URL: https://issues.jboss.org/browse/WFLY-2404
             Project: WildFly
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Web (Undertow)
    Affects Versions: 8.0.0.Beta1
            Reporter: Tomaz Cerar
            Assignee: Stuart Douglas


We need to support same sso configuration we used to have for web subsystem.
That consists of Clustered and non clustered SSO support

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 08:35:02 2013
From: jira-events at lists.jboss.org (Anthony Patricio (JIRA))
Date: Tue, 29 Oct 2013 08:35:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-280) lock-on-active broken
In-Reply-To: <JIRA.12501976.1380702873000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501976.1380702873000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501976.1380702873000.21382.1383050102561@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825481#comment-12825481 ] 

Anthony Patricio commented on DROOLS-280:
-----------------------------------------

Thanks for the workaround, it seems to work.
However, is this considered as the way to use lock-on-active? Or is this just a workaround?
I didn't manage to find documentation on @Eager, what is it supposed to do?

Thanks.

                
> lock-on-active broken
> ---------------------
>
>                 Key: DROOLS-280
>                 URL: https://issues.jboss.org/browse/DROOLS-280
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>            Reporter: Anthony Patricio
>
> Hi,
> lock-on-active is not working as expected.
> I seems to work as activation-group.
> Works fine with 5.x
> Fails with 6.0.0 CR3 and CR4
> Fact:
> {code:java}
> public class Poc implements Serializable {
> 	private static final long serialVersionUID = 1L;
> 	private long id = 1;
> 	private boolean test1 = false;
> 	private boolean test2 = false;
> 	private int foundTest = 0;
> ...
> }
> {code}
> Rule:
> {code:java}
> rule "test1"
> lock-on-active 
> dialect "mvel"
>     when
>     	$poc:Poc( isTest1() )
>     then
>     	System.out.println("test1 found");
>     	modify($poc) { setFoundTest($poc.getFoundTest() + 1) }    	
> end
> rule "test2"
> lock-on-active 
> dialect "mvel"
>     when
>     	$poc:Poc( isTest2() )
>     then
>     	System.out.println("test2 found");
>     	modify($poc) { setFoundTest($poc.getFoundTest() + 1) }    	
> end
> {code}
> Test:
> {code:java}
> @Test
> public void lockOnActiveTest() {
> 	// Get the Knowledge base from the DRL file 
> 	KieSession kSession = getSF();
> 			
> 	Poc poc = new Poc();
> 	poc.setTest1(true);
> 	poc.setTest2(true);
> 	
> 	kSession.insert(poc);
> 	
> 	// Fire the rules
> 	kSession.fireAllRules();
> 	
> 	assertTrue("broken",poc.getFoundTest()==2);
> 	
> 	// Clean up
> 	kSession.dispose();
> }
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 08:49:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 29 Oct 2013 08:49:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1723) Corrupted input stream on
	STATE exchange
In-Reply-To: <JIRA.12508721.1382628956000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508721.1382628956000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508721.1382628956000.21421.1383050942481@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825484#comment-12825484 ] 

Bela Ban commented on JGRP-1723:
--------------------------------

The bug is in {{BlockingInputStream.read(byte[] buf, int offset, int length)}}: we only read one buffer (default=8192 bytes) instead of {{min(buf.length, length)}}.
                
> Corrupted input stream on STATE exchange
> ----------------------------------------
>
>                 Key: JGRP-1723
>                 URL: https://issues.jboss.org/browse/JGRP-1723
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.3.4, 3.4
>         Environment: java7u25
>            Reporter: Mathieu Bernatet
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>         Attachments: corruptedStreamOnStateExchange.zip
>
>
> Using the pbcast.STATE state transfer protocol with a high volume of data, the receiver member on setState seem to get a corrupted input stream.
> I was able to reproduce this issue with a simple project in which the data get corrupted from the 8192th byte. So it may be related to frag size with default value of 8192. We get this bug either with FRAG or FRAG2.
> Related discussion on the mailing list could be found here : http://jgroups.1086181.n5.nabble.com/Corrupted-input-stream-on-STATE-exchange-td9938.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 08:49:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 29 Oct 2013 08:49:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1723) Corrupted input stream on
	STATE exchange
In-Reply-To: <JIRA.12508721.1382628956000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508721.1382628956000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508721.1382628956000.21425.1383050942624@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825484#comment-12825484 ] 

Bela Ban edited comment on JGRP-1723 at 10/29/13 8:48 AM:
----------------------------------------------------------

The bug is in {{BlockingInputStream.read(byte[] buf, int offset, int length)}}: we only read one buffer (default=8192 bytes) instead of {{min(buf.length, length)}}.
Added a unit test: {{BlockingInputStreamTest.testLargeTransfer2()}}
                
      was (Author: belaban):
    The bug is in {{BlockingInputStream.read(byte[] buf, int offset, int length)}}: we only read one buffer (default=8192 bytes) instead of {{min(buf.length, length)}}.
                  
> Corrupted input stream on STATE exchange
> ----------------------------------------
>
>                 Key: JGRP-1723
>                 URL: https://issues.jboss.org/browse/JGRP-1723
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.3.4, 3.4
>         Environment: java7u25
>            Reporter: Mathieu Bernatet
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>         Attachments: corruptedStreamOnStateExchange.zip
>
>
> Using the pbcast.STATE state transfer protocol with a high volume of data, the receiver member on setState seem to get a corrupted input stream.
> I was able to reproduce this issue with a simple project in which the data get corrupted from the 8192th byte. So it may be related to frag size with default value of 8192. We get this bug either with FRAG or FRAG2.
> Related discussion on the mailing list could be found here : http://jgroups.1086181.n5.nabble.com/Corrupted-input-stream-on-STATE-exchange-td9938.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 09:21:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 29 Oct 2013 09:21:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2268) Add Generic JMS RA
In-Reply-To: <JIRA.12502537.1381312737000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502537.1381312737000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502537.1381312737000.21513.1383052862528@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825504#comment-12825504 ] 

RH Bugzilla Integration commented on WFLY-2268:
-----------------------------------------------

Vladimir Rastseluev <vrastsel at redhat.com> changed the Status of [bug 1016762|https://bugzilla.redhat.com/show_bug.cgi?id=1016762] from ON_QA to VERIFIED
                
> Add Generic JMS RA
> ------------------
>
>                 Key: WFLY-2268
>                 URL: https://issues.jboss.org/browse/WFLY-2268
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JCA, JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.CR1
>
>
> WildFly could integrate the Generic JMS RA[1] to be able to use JMS brokers that does not provide a resource adapter.
> [1] https://github.com/jms-ra/generic-jms-ra

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 09:21:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 29 Oct 2013 09:21:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2268) Add Generic JMS RA
In-Reply-To: <JIRA.12502537.1381312737000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502537.1381312737000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502537.1381312737000.21510.1383052862410@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825503#comment-12825503 ] 

RH Bugzilla Integration commented on WFLY-2268:
-----------------------------------------------

Vladimir Rastseluev <vrastsel at redhat.com> made a comment on [bug 1016762|https://bugzilla.redhat.com/show_bug.cgi?id=1016762]

VERIFIED on EAP 6.2 ER6
                
> Add Generic JMS RA
> ------------------
>
>                 Key: WFLY-2268
>                 URL: https://issues.jboss.org/browse/WFLY-2268
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JCA, JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.CR1
>
>
> WildFly could integrate the Generic JMS RA[1] to be able to use JMS brokers that does not provide a resource adapter.
> [1] https://github.com/jms-ra/generic-jms-ra

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 09:23:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 29 Oct 2013 09:23:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-760) Make the JBoss Negotiation
 dependency on JBoss Web - Provided
In-Reply-To: <JIRA.12508666.1382606869000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508666.1382606869000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508666.1382606869000.21516.1383052983041@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/SECURITY-760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825505#comment-12825505 ] 

RH Bugzilla Integration commented on SECURITY-760:
--------------------------------------------------

Peter Skopek <pskopek at redhat.com> changed the Status of [bug 1022679|https://bugzilla.redhat.com/show_bug.cgi?id=1022679] from NEW to POST
                
> Make the JBoss Negotiation dependency on JBoss Web - Provided
> -------------------------------------------------------------
>
>                 Key: SECURITY-760
>                 URL: https://issues.jboss.org/browse/SECURITY-760
>             Project: PicketBox 
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: Negotiation_2_2_6
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 09:23:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 29 Oct 2013 09:23:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-760) Make the JBoss Negotiation
 dependency on JBoss Web - Provided
In-Reply-To: <JIRA.12508666.1382606869000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508666.1382606869000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508666.1382606869000.21518.1383052983161@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/SECURITY-760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825506#comment-12825506 ] 

RH Bugzilla Integration commented on SECURITY-760:
--------------------------------------------------

Peter Skopek <pskopek at redhat.com> made a comment on [bug 1022679|https://bugzilla.redhat.com/show_bug.cgi?id=1022679]

jbossxacml excluded from quickstart build.
PR: https://github.com/jboss-developer/jboss-eap-quickstarts/pull/704
                
> Make the JBoss Negotiation dependency on JBoss Web - Provided
> -------------------------------------------------------------
>
>                 Key: SECURITY-760
>                 URL: https://issues.jboss.org/browse/SECURITY-760
>             Project: PicketBox 
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: Negotiation_2_2_6
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 09:28:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 29 Oct 2013 09:28:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2214) Allow existing environment
 properties to be set for outbound LDAP connections used by security realms.
In-Reply-To: <JIRA.12502155.1380834418000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502155.1380834418000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502155.1380834418000.21523.1383053282084@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2214:
-----------------------------------

    Summary: Allow existing environment properties to be set for outbound LDAP connections used by security realms.  (was: LDAP security realm needs to have configurable timeouts)

    
> Allow existing environment properties to be set for outbound LDAP connections used by security realms.
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2214
>                 URL: https://issues.jboss.org/browse/WFLY-2214
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Derek Horton
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> LDAP security realm needs to have configurable timeouts.
> The default LDAP connection timeout appears to be 2 minutes.  If the ldap server is down, it could take 2 minutes for the connection to timeout.  This can cause unneeded delay if you have configured multiple ldap servers for  failover / redundancy.
> The following hack appears to work:
> +++ domain-management/src/main/java/org/jboss/as/domain/management/connections/ldap/LdapConnectionManagerService.java
> @@ -132,6 +132,7 @@ public class LdapConnectionManagerService implements Service<LdapConnectionManag
>          result.put(Context.INITIAL_CONTEXT_FACTORY,initialContextFactory);
>          String url = config.require(URL).asString();
>          result.put(Context.PROVIDER_URL,url);
> +        result.put("com.sun.jndi.ldap.connect.timeout", "500");
>          return result;
>      }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 09:34:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 29 Oct 2013 09:34:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2214) Allow existing environment
 properties to be set for outbound LDAP connections used by security realms.
In-Reply-To: <JIRA.12502155.1380834418000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502155.1380834418000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502155.1380834418000.21563.1383053642520@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825511#comment-12825511 ] 

Darran Lofthouse commented on WFLY-2214:
----------------------------------------

Just changed the title to this one, going to add support for some additional environment properties to be set for the LDAP connection, things like timeouts are moving into an area that non-standard properties are now set - also there are additional non-standard properties would could potentially support so adding some generic support for properties will allow for those as well.

                
> Allow existing environment properties to be set for outbound LDAP connections used by security realms.
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2214
>                 URL: https://issues.jboss.org/browse/WFLY-2214
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Derek Horton
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> LDAP security realm needs to have configurable timeouts.
> The default LDAP connection timeout appears to be 2 minutes.  If the ldap server is down, it could take 2 minutes for the connection to timeout.  This can cause unneeded delay if you have configured multiple ldap servers for  failover / redundancy.
> The following hack appears to work:
> +++ domain-management/src/main/java/org/jboss/as/domain/management/connections/ldap/LdapConnectionManagerService.java
> @@ -132,6 +132,7 @@ public class LdapConnectionManagerService implements Service<LdapConnectionManag
>          result.put(Context.INITIAL_CONTEXT_FACTORY,initialContextFactory);
>          String url = config.require(URL).asString();
>          result.put(Context.PROVIDER_URL,url);
> +        result.put("com.sun.jndi.ldap.connect.timeout", "500");
>          return result;
>      }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 09:38:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 29 Oct 2013 09:38:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2173) Get subsystem test framework
 working with AS 7.2.0 legacy controller
In-Reply-To: <JIRA.12501755.1380296954000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501755.1380296954000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501755.1380296954000.21576.1383053882253@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825513#comment-12825513 ] 

RH Bugzilla Integration commented on WFLY-2173:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> made a comment on [bug 1015245|https://bugzilla.redhat.com/show_bug.cgi?id=1015245]

Verified on EAP 6.2.0.ER6.
                
> Get subsystem test framework working with AS 7.2.0 legacy controller
> --------------------------------------------------------------------
>
>                 Key: WFLY-2173
>                 URL: https://issues.jboss.org/browse/WFLY-2173
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 09:38:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 29 Oct 2013 09:38:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2185) Get core model test framework
 working with 7.2.0.Final legacy controller
In-Reply-To: <JIRA.12501848.1380553676000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501848.1380553676000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501848.1380553676000.21582.1383053882542@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825514#comment-12825514 ] 

RH Bugzilla Integration commented on WFLY-2185:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> made a comment on [bug 1015245|https://bugzilla.redhat.com/show_bug.cgi?id=1015245]

Verified on EAP 6.2.0.ER6.
                
> Get core model test framework working with 7.2.0.Final legacy controller
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2185
>                 URL: https://issues.jboss.org/browse/WFLY-2185
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 09:38:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 29 Oct 2013 09:38:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2185) Get core model test framework
 working with 7.2.0.Final legacy controller
In-Reply-To: <JIRA.12501848.1380553676000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501848.1380553676000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501848.1380553676000.21585.1383053882659@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825515#comment-12825515 ] 

RH Bugzilla Integration commented on WFLY-2185:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> changed the Status of [bug 1015245|https://bugzilla.redhat.com/show_bug.cgi?id=1015245] from ON_QA to VERIFIED
                
> Get core model test framework working with 7.2.0.Final legacy controller
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2185
>                 URL: https://issues.jboss.org/browse/WFLY-2185
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 09:38:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 29 Oct 2013 09:38:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2173) Get subsystem test framework
 working with AS 7.2.0 legacy controller
In-Reply-To: <JIRA.12501755.1380296954000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501755.1380296954000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501755.1380296954000.21587.1383053882738@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825516#comment-12825516 ] 

RH Bugzilla Integration commented on WFLY-2173:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> changed the Status of [bug 1015245|https://bugzilla.redhat.com/show_bug.cgi?id=1015245] from ON_QA to VERIFIED
                
> Get subsystem test framework working with AS 7.2.0 legacy controller
> --------------------------------------------------------------------
>
>                 Key: WFLY-2173
>                 URL: https://issues.jboss.org/browse/WFLY-2173
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 10:13:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 29 Oct 2013 10:13:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1723) Corrupted input stream on
	STATE exchange
In-Reply-To: <JIRA.12508721.1382628956000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508721.1382628956000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508721.1382628956000.21655.1383055982098@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825531#comment-12825531 ] 

Bela Ban commented on JGRP-1723:
--------------------------------

Re STATE_SOCK: if you use {{readFully()}} instead of {{read()}}, STATE_SOCK works as well.
Tested your program with STATE_TRANSFER, STATE and STATE_SOCK and all 3 work.

Note that it would make sense to wrap the output stream in a BufferedOutputStream, or else writing the length of the buffer (4 bytes) results in 4 messages being sent.
                
> Corrupted input stream on STATE exchange
> ----------------------------------------
>
>                 Key: JGRP-1723
>                 URL: https://issues.jboss.org/browse/JGRP-1723
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.3.4, 3.4
>         Environment: java7u25
>            Reporter: Mathieu Bernatet
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>         Attachments: corruptedStreamOnStateExchange.zip
>
>
> Using the pbcast.STATE state transfer protocol with a high volume of data, the receiver member on setState seem to get a corrupted input stream.
> I was able to reproduce this issue with a simple project in which the data get corrupted from the 8192th byte. So it may be related to frag size with default value of 8192. We get this bug either with FRAG or FRAG2.
> Related discussion on the mailing list could be found here : http://jgroups.1086181.n5.nabble.com/Corrupted-input-stream-on-STATE-exchange-td9938.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 10:17:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 29 Oct 2013 10:17:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1723) Corrupted input stream on
	STATE exchange
In-Reply-To: <JIRA.12508721.1382628956000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508721.1382628956000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508721.1382628956000.21673.1383056222244@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1723:
---------------------------

    Fix Version/s: 3.4.1

    
> Corrupted input stream on STATE exchange
> ----------------------------------------
>
>                 Key: JGRP-1723
>                 URL: https://issues.jboss.org/browse/JGRP-1723
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.3.4, 3.4
>         Environment: java7u25
>            Reporter: Mathieu Bernatet
>            Assignee: Bela Ban
>             Fix For: 3.4.1, 3.5
>
>         Attachments: corruptedStreamOnStateExchange.zip
>
>
> Using the pbcast.STATE state transfer protocol with a high volume of data, the receiver member on setState seem to get a corrupted input stream.
> I was able to reproduce this issue with a simple project in which the data get corrupted from the 8192th byte. So it may be related to frag size with default value of 8192. We get this bug either with FRAG or FRAG2.
> Related discussion on the mailing list could be found here : http://jgroups.1086181.n5.nabble.com/Corrupted-input-stream-on-STATE-exchange-td9938.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 10:19:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 29 Oct 2013 10:19:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1723) Corrupted input stream on
	STATE exchange
In-Reply-To: <JIRA.12508721.1382628956000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508721.1382628956000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508721.1382628956000.21698.1383056342673@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1723.
----------------------------

    Resolution: Done

    
> Corrupted input stream on STATE exchange
> ----------------------------------------
>
>                 Key: JGRP-1723
>                 URL: https://issues.jboss.org/browse/JGRP-1723
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.3.4, 3.4
>         Environment: java7u25
>            Reporter: Mathieu Bernatet
>            Assignee: Bela Ban
>             Fix For: 3.4.1, 3.5
>
>         Attachments: corruptedStreamOnStateExchange.zip
>
>
> Using the pbcast.STATE state transfer protocol with a high volume of data, the receiver member on setState seem to get a corrupted input stream.
> I was able to reproduce this issue with a simple project in which the data get corrupted from the 8192th byte. So it may be related to frag size with default value of 8192. We get this bug either with FRAG or FRAG2.
> Related discussion on the mailing list could be found here : http://jgroups.1086181.n5.nabble.com/Corrupted-input-stream-on-STATE-exchange-td9938.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 10:33:02 2013
From: jira-events at lists.jboss.org (Tristan Tarrant (JIRA))
Date: Tue, 29 Oct 2013 10:33:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1721) AUTH and ENCRYPT protocols
 configured with plain text passwords
In-Reply-To: <JIRA.12508425.1382426440000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508425.1382426440000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508425.1382426440000.21843.1383057182658@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825542#comment-12825542 ] 

Tristan Tarrant commented on JGRP-1721:
---------------------------------------

Protocol property values in the jgroups subsystem support expressions, and therefore transitively support ${VAULT::...}  expansion
                
> AUTH and ENCRYPT protocols configured with plain text passwords
> ---------------------------------------------------------------
>
>                 Key: JGRP-1721
>                 URL: https://issues.jboss.org/browse/JGRP-1721
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Martin Gencur
>            Assignee: Bela Ban
>              Labels: jdg620_dm
>             Fix For: 3.5
>
>
> The following parameters of AUTH protocol are stored as plain text:
> * keystore_password
> The following parameters of ENCRYPT protocol are stored as plain text:
> * store_password
> * key_password
> Example:
> {code}
> <ENCRYPT key_store_name="defaultStore.keystore" store_password="changeit" alias="myKey"/>
> {code}
> Requirements for storing passwords: https://docspace.corp.redhat.com/docs/DOC-131628

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 10:35:06 2013
From: jira-events at lists.jboss.org (Chris R. (JIRA))
Date: Tue, 29 Oct 2013 10:35:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2391) Wildfly caches content in
 exploded mode, breaking developer productivity
In-Reply-To: <JIRA.12508879.1382966687000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508879.1382966687000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508879.1382966687000.21878.1383057306182@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825455#comment-12825455 ] 

Chris R. edited comment on WFLY-2391 at 10/29/13 10:34 AM:
-----------------------------------------------------------

EDIT: 

I removed caching from servlet container, deploying is now possible

I removed:
                <buffer-cache name="default" buffer-size="1024" buffers-per-region="1024" max-regions="10"/>

I'm unable to deploy my projects now:

11:27:20,808 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "foo_frontend.war")]) - failure description: {"JBAS014879: One or more services were unable to start due to one or more indirect dependencies not being available." => {
    "Services that were unable to start:" => ["jboss.deployment.unit.\"foo_frontend.war\".INSTALL"],
    "Services that may be the cause:" => [
        "jboss.remoting.remotingConnectorInfoService.http-remoting-connector",
        "jboss.undertow.bufferCache.default"
    ]
}}


                
      was (Author: goot):
    I removed 
                <buffer-cache name="default" buffer-size="1024" buffers-per-region="1024" max-regions="10"/>

I'm unable to deploy my projects now:

11:27:20,808 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "foo_frontend.war")]) - failure description: {"JBAS014879: One or more services were unable to start due to one or more indirect dependencies not being available." => {
    "Services that were unable to start:" => ["jboss.deployment.unit.\"foo_frontend.war\".INSTALL"],
    "Services that may be the cause:" => [
        "jboss.remoting.remotingConnectorInfoService.http-remoting-connector",
        "jboss.undertow.bufferCache.default"
    ]
}}


                  
> Wildfly caches content in exploded mode, breaking developer productivity
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2391
>                 URL: https://issues.jboss.org/browse/WFLY-2391
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>         Environment: MacOSX with JBossTools 4.1.1.Beta1
>            Reporter: Xavier Coulon
>            Assignee: Stuart Douglas
>         Attachments: jboss-as-kitchensink-html5-mobile.war.zip
>
>
> While I was building a sample application with JBoss Tools 4.1.1.beta1 on WildFly 8.0.Beta1, I noticed that after a few minutes (or a few browser requests), the content of my index.html file seemed to be cached by the server, although I used the "exploded content" deployment mode (since I published the content using the WildFly Server Adapter in JBoss Tools).
>  
> I checked the actual content of the index.html in the deployments folder and it contained the latest changes, which means that the JBoss Tools Server Adapter is doing its job well ;-)
> I also tried to edit the index.html file directly in the deployments folder, and once again, I got no update in both Chrome and Firefox browsers.
>  
> I checked in the "Network" tab of the browsers and could see that the server response for the index.html page had a "200 OK" status, which means that there's no browser caching involved.
> I tried to get the index.html page with cUrl and got the same old version, which definitely excludes a browser caching issue.
> At the end of the dat, this means that after a few changes, my browsers keep getting an old version of the deployed resources, which in turns means that I have to stop and restart the server to get the new content, and this is pretty bad in term of dev productivity.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 10:35:07 2013
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Tue, 29 Oct 2013 10:35:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2378) Re-enable
	StatefulWithXPCFailoverTestCase
In-Reply-To: <JIRA.12508714.1382627574000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508714.1382627574000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508714.1382627574000.21888.1383057307136@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro updated WFLY-2378:
-------------------------------

    Git Pull Request:   (was: https://github.com/wildfly/wildfly/pull/5357)

    
> Re-enable StatefulWithXPCFailoverTestCase
> -----------------------------------------
>
>                 Key: WFLY-2378
>                 URL: https://issues.jboss.org/browse/WFLY-2378
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>
> So I don't forget...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 10:47:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 29 Oct 2013 10:47:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-760) Make the JBoss Negotiation
 dependency on JBoss Web - Provided
In-Reply-To: <JIRA.12508666.1382606869000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508666.1382606869000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508666.1382606869000.21958.1383058022315@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/SECURITY-760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825551#comment-12825551 ] 

RH Bugzilla Integration commented on SECURITY-760:
--------------------------------------------------

Rafael Benevides <benevides at redhat.com> changed the Status of [bug 1022679|https://bugzilla.redhat.com/show_bug.cgi?id=1022679] from POST to MODIFIED
                
> Make the JBoss Negotiation dependency on JBoss Web - Provided
> -------------------------------------------------------------
>
>                 Key: SECURITY-760
>                 URL: https://issues.jboss.org/browse/SECURITY-760
>             Project: PicketBox 
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: Negotiation_2_2_6
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 10:47:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 29 Oct 2013 10:47:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-760) Make the JBoss Negotiation
 dependency on JBoss Web - Provided
In-Reply-To: <JIRA.12508666.1382606869000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508666.1382606869000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508666.1382606869000.21961.1383058022474@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/SECURITY-760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825552#comment-12825552 ] 

RH Bugzilla Integration commented on SECURITY-760:
--------------------------------------------------

Rafael Benevides <benevides at redhat.com> made a comment on [bug 1022679|https://bugzilla.redhat.com/show_bug.cgi?id=1022679]

PR merged
                
> Make the JBoss Negotiation dependency on JBoss Web - Provided
> -------------------------------------------------------------
>
>                 Key: SECURITY-760
>                 URL: https://issues.jboss.org/browse/SECURITY-760
>             Project: PicketBox 
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: Negotiation_2_2_6
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 10:53:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 29 Oct 2013 10:53:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2057)
 org.jboss.as.server.deployment.RegisteredDeploymentUnitProcessor has
 unstable compareTo()
In-Reply-To: <JIRA.12500645.1379015464000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500645.1379015464000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500645.1379015464000.22056.1383058382765@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825556#comment-12825556 ] 

RH Bugzilla Integration commented on WFLY-2057:
-----------------------------------------------

Jakub Cechacek <jcechace at redhat.com> changed the Status of [bug 1013470|https://bugzilla.redhat.com/show_bug.cgi?id=1013470] from ON_QA to VERIFIED
                
> org.jboss.as.server.deployment.RegisteredDeploymentUnitProcessor has unstable compareTo()
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-2057
>                 URL: https://issues.jboss.org/browse/WFLY-2057
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server
>            Reporter: David Lloyd
>            Assignee: Stuart Douglas
>            Priority: Blocker
>             Fix For: 8.0.0.Beta1
>
>
> As the description says, org.jboss.as.server.deployment.RegisteredDeploymentUnitProcessor's compareTo is wrong.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 10:53:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 29 Oct 2013 10:53:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2057)
 org.jboss.as.server.deployment.RegisteredDeploymentUnitProcessor has
 unstable compareTo()
In-Reply-To: <JIRA.12500645.1379015464000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500645.1379015464000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500645.1379015464000.22073.1383058383537@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825557#comment-12825557 ] 

RH Bugzilla Integration commented on WFLY-2057:
-----------------------------------------------

Jakub Cechacek <jcechace at redhat.com> made a comment on [bug 1013470|https://bugzilla.redhat.com/show_bug.cgi?id=1013470]

Verified for 6.2.0.ER6 based on Stuart's email [1] -- we haven not encountered any issues regarding deployments. 

[1] email mentioned above:
>There is no way to reproduce the circumstances that caused the server to fail to start. AFAIK even on later JDK8 builds it should work fine.
>
>This change is right in the heart of the deployment code, if it is wrong then it >will show up in problems with the deployment process, there is no way to test it in isolation.
                
> org.jboss.as.server.deployment.RegisteredDeploymentUnitProcessor has unstable compareTo()
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-2057
>                 URL: https://issues.jboss.org/browse/WFLY-2057
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server
>            Reporter: David Lloyd
>            Assignee: Stuart Douglas
>            Priority: Blocker
>             Fix For: 8.0.0.Beta1
>
>
> As the description says, org.jboss.as.server.deployment.RegisteredDeploymentUnitProcessor's compareTo is wrong.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 11:19:02 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Tue, 29 Oct 2013 11:19:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2327) [Wildfly][RFE] ERROR Level
 message when unsuccessful drop sequence hibernate_sequence occurs
In-Reply-To: <JIRA.12504395.1381998139000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12504395.1381998139000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12504395.1381998139000.22228.1383059942123@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825570#comment-12825570 ] 

Scott Marlow commented on WFLY-2327:
------------------------------------

Please report this issue via https://hibernate.onjira.com/browse/HHH, as the requested change would be a Hibernate (ORM) code change.  
                
> [Wildfly][RFE] ERROR Level message when unsuccessful drop sequence hibernate_sequence occurs
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2327
>                 URL: https://issues.jboss.org/browse/WFLY-2327
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Frederic Hornain
>            Assignee: Scott Marlow
>            Priority: Minor
>
> Dear *,
> Would it be possible to change the ERROR log level to something between "WARN" and "ERROR" when a non yet existing table is dropped ?
> 10:08:49,828 ERROR [org.hibernate.tool.hbm2ddl.SchemaExport] (ServerService Thread Pool -- 52) HHH000389: Unsuccessful: drop sequence hibernate_sequence
> 10:08:49,829 ERROR [org.hibernate.tool.hbm2ddl.SchemaExport] (ServerService Thread Pool -- 52) Sequence "HIBERNATE_SEQUENCE" not found; SQL statement:
>     drop sequence hibernate_sequence [90036-173]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 11:19:02 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Tue, 29 Oct 2013 11:19:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2327) [Wildfly][RFE] ERROR Level
 message when unsuccessful drop sequence hibernate_sequence occurs
In-Reply-To: <JIRA.12504395.1381998139000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12504395.1381998139000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12504395.1381998139000.22231.1383059942229@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow resolved WFLY-2327.
--------------------------------

    Resolution: Rejected

    
> [Wildfly][RFE] ERROR Level message when unsuccessful drop sequence hibernate_sequence occurs
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2327
>                 URL: https://issues.jboss.org/browse/WFLY-2327
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Frederic Hornain
>            Assignee: Scott Marlow
>            Priority: Minor
>
> Dear *,
> Would it be possible to change the ERROR log level to something between "WARN" and "ERROR" when a non yet existing table is dropped ?
> 10:08:49,828 ERROR [org.hibernate.tool.hbm2ddl.SchemaExport] (ServerService Thread Pool -- 52) HHH000389: Unsuccessful: drop sequence hibernate_sequence
> 10:08:49,829 ERROR [org.hibernate.tool.hbm2ddl.SchemaExport] (ServerService Thread Pool -- 52) Sequence "HIBERNATE_SEQUENCE" not found; SQL statement:
>     drop sequence hibernate_sequence [90036-173]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 11:56:02 2013
From: jira-events at lists.jboss.org (Julien Derveeuw (JIRA))
Date: Tue, 29 Oct 2013 11:56:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBASMP-58) jboss-as-maven-plugin freezes
 on authentication
In-Reply-To: <JIRA.12508946.1383048331000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508946.1383048331000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508946.1383048331000.22363.1383062162022@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBASMP-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Julien Derveeuw updated JBASMP-58:
----------------------------------

    Description: 
I have jboss 7.1.1 in standalone mode running on machine A (linux).
I want to deploy remotely to it using client machine B @ mac os X 10.8.5 / JDK 1.7.0_45-b18.

If I connect from B to A using {{jboss-cli}}, everything works fine, I am able to login.

If I try to deploy from maven with this :
{code:xml}
            <plugin>
                <groupId>org.jboss.as.plugins</groupId>
                <artifactId>jboss-as-maven-plugin</artifactId>
                <version>7.5.Final</version>
                <configuration>
                    <hostname>${deploy.jboss.host}</hostname>
                    <port>${deploy.jboss.port}</port>
                    <username>${deploy.jboss.user}</username>
                    <password>${deploy.jboss.password}</password>
                </configuration>

                <executions>
                    <execution>
                        <phase>install</phase>
                        <goals>
                            <goal>deploy</goal>
                        </goals>
                    </execution>
                </executions>
{code}
plugin freezes indefinitely on 
{{Authenticating against security realm: ManagementRealm}}
No more details are available with {{mvn -X}}

If I remove the password or username from pom, it fails correctly with :
{{The connection failed: Authentication failed: all available authentication mechanisms failed}}

After digging on google, I ended up adding {{-Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.KQueueSelectorProvider}} to mvn runner options because NIOs on jdk7 at macosx is said to be buggy but it didn't help.



  was:
I have jboss 7.1.1 in standalone mode running on machine A (linux).
I want to deploy remotely to it using client machine B @ mac os X 10.8.5 / JDK 1.7.0_45-b18.

If I connect from B to A using jboss-cli, everything works fine, I am able to login.

If I try to deploy from maven with this :
            <plugin>
                <groupId>org.jboss.as.plugins</groupId>
                <artifactId>jboss-as-maven-plugin</artifactId>
                <version>7.5.Final</version>
                <configuration>
                    <hostname>${deploy.jboss.host}</hostname>
                    <port>${deploy.jboss.port}</port>
                    <username>${deploy.jboss.user}</username>
                    <password>${deploy.jboss.password}</password>
                </configuration>

                <executions>
                    <execution>
                        <phase>install</phase>
                        <goals>
                            <goal>deploy</goal>
                        </goals>
                    </execution>
                </executions>

plugin freezes indefinitely on 
Authenticating against security realm: ManagementRealm
No more details are available with mvn -X

If I remove the password or username from pom, it fails correctly with :
The connection failed: Authentication failed: all available authentication mechanisms failed

After digging on google, I ended up adding -Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.KQueueSelectorProvider to mvn runner options because NIOs on jdk7 at macosx is said to be buggy but it didn't help.




    
> jboss-as-maven-plugin freezes on authentication
> -----------------------------------------------
>
>                 Key: JBASMP-58
>                 URL: https://issues.jboss.org/browse/JBASMP-58
>             Project: JBoss AS Maven Plugins
>          Issue Type: Bug
>          Components: deploy
>    Affects Versions: 7.5.Final
>         Environment: mac os x 10.8.5
>            Reporter: Julien Derveeuw
>            Assignee: James Perkins
>            Priority: Critical
>
> I have jboss 7.1.1 in standalone mode running on machine A (linux).
> I want to deploy remotely to it using client machine B @ mac os X 10.8.5 / JDK 1.7.0_45-b18.
> If I connect from B to A using {{jboss-cli}}, everything works fine, I am able to login.
> If I try to deploy from maven with this :
> {code:xml}
>             <plugin>
>                 <groupId>org.jboss.as.plugins</groupId>
>                 <artifactId>jboss-as-maven-plugin</artifactId>
>                 <version>7.5.Final</version>
>                 <configuration>
>                     <hostname>${deploy.jboss.host}</hostname>
>                     <port>${deploy.jboss.port}</port>
>                     <username>${deploy.jboss.user}</username>
>                     <password>${deploy.jboss.password}</password>
>                 </configuration>
>                 <executions>
>                     <execution>
>                         <phase>install</phase>
>                         <goals>
>                             <goal>deploy</goal>
>                         </goals>
>                     </execution>
>                 </executions>
> {code}
> plugin freezes indefinitely on 
> {{Authenticating against security realm: ManagementRealm}}
> No more details are available with {{mvn -X}}
> If I remove the password or username from pom, it fails correctly with :
> {{The connection failed: Authentication failed: all available authentication mechanisms failed}}
> After digging on google, I ended up adding {{-Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.KQueueSelectorProvider}} to mvn runner options because NIOs on jdk7 at macosx is said to be buggy but it didn't help.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 11:56:02 2013
From: jira-events at lists.jboss.org (Julien Derveeuw (JIRA))
Date: Tue, 29 Oct 2013 11:56:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBASMP-58) jboss-as-maven-plugin freezes
 on authentication
In-Reply-To: <JIRA.12508946.1383048331000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508946.1383048331000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508946.1383048331000.22366.1383062162190@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBASMP-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Julien Derveeuw updated JBASMP-58:
----------------------------------

    Description: 
I have jboss 7.1.1 in standalone mode running on machine A (linux).
I want to deploy remotely to it using client machine B @ mac os X 10.8.5 / JDK 1.7.0_45-b18.

If I connect from B to A using {{jboss-cli}}, everything works fine, I am able to login.

If I try to deploy from maven with this :
{code:xml}
                <groupId>org.jboss.as.plugins</groupId>
                <artifactId>jboss-as-maven-plugin</artifactId>
                <version>7.5.Final</version>
                <configuration>
                    <hostname>${deploy.jboss.host}</hostname>
                    <port>${deploy.jboss.port}</port>
                    <username>${deploy.jboss.user}</username>
                    <password>${deploy.jboss.password}</password>
                </configuration>

                <executions>
                    <execution>
                        <phase>install</phase>
                        <goals>
                            <goal>deploy</goal>
                        </goals>
                    </execution>
                </executions>
{code}
plugin freezes indefinitely on 
{{Authenticating against security realm: ManagementRealm}}
No more details are available with {{mvn -X}}

If I remove the password or username from pom, it fails correctly with :
{{The connection failed: Authentication failed: all available authentication mechanisms failed}}

After digging on google, I ended up adding {{-Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.KQueueSelectorProvider}} to mvn runner options because NIOs on jdk7 at macosx is said to be buggy but it didn't help.



  was:
I have jboss 7.1.1 in standalone mode running on machine A (linux).
I want to deploy remotely to it using client machine B @ mac os X 10.8.5 / JDK 1.7.0_45-b18.

If I connect from B to A using {{jboss-cli}}, everything works fine, I am able to login.

If I try to deploy from maven with this :
{code:xml}
            <plugin>
                <groupId>org.jboss.as.plugins</groupId>
                <artifactId>jboss-as-maven-plugin</artifactId>
                <version>7.5.Final</version>
                <configuration>
                    <hostname>${deploy.jboss.host}</hostname>
                    <port>${deploy.jboss.port}</port>
                    <username>${deploy.jboss.user}</username>
                    <password>${deploy.jboss.password}</password>
                </configuration>

                <executions>
                    <execution>
                        <phase>install</phase>
                        <goals>
                            <goal>deploy</goal>
                        </goals>
                    </execution>
                </executions>
{code}
plugin freezes indefinitely on 
{{Authenticating against security realm: ManagementRealm}}
No more details are available with {{mvn -X}}

If I remove the password or username from pom, it fails correctly with :
{{The connection failed: Authentication failed: all available authentication mechanisms failed}}

After digging on google, I ended up adding {{-Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.KQueueSelectorProvider}} to mvn runner options because NIOs on jdk7 at macosx is said to be buggy but it didn't help.




    
> jboss-as-maven-plugin freezes on authentication
> -----------------------------------------------
>
>                 Key: JBASMP-58
>                 URL: https://issues.jboss.org/browse/JBASMP-58
>             Project: JBoss AS Maven Plugins
>          Issue Type: Bug
>          Components: deploy
>    Affects Versions: 7.5.Final
>         Environment: mac os x 10.8.5
>            Reporter: Julien Derveeuw
>            Assignee: James Perkins
>            Priority: Critical
>
> I have jboss 7.1.1 in standalone mode running on machine A (linux).
> I want to deploy remotely to it using client machine B @ mac os X 10.8.5 / JDK 1.7.0_45-b18.
> If I connect from B to A using {{jboss-cli}}, everything works fine, I am able to login.
> If I try to deploy from maven with this :
> {code:xml}
>                 <groupId>org.jboss.as.plugins</groupId>
>                 <artifactId>jboss-as-maven-plugin</artifactId>
>                 <version>7.5.Final</version>
>                 <configuration>
>                     <hostname>${deploy.jboss.host}</hostname>
>                     <port>${deploy.jboss.port}</port>
>                     <username>${deploy.jboss.user}</username>
>                     <password>${deploy.jboss.password}</password>
>                 </configuration>
>                 <executions>
>                     <execution>
>                         <phase>install</phase>
>                         <goals>
>                             <goal>deploy</goal>
>                         </goals>
>                     </execution>
>                 </executions>
> {code}
> plugin freezes indefinitely on 
> {{Authenticating against security realm: ManagementRealm}}
> No more details are available with {{mvn -X}}
> If I remove the password or username from pom, it fails correctly with :
> {{The connection failed: Authentication failed: all available authentication mechanisms failed}}
> After digging on google, I ended up adding {{-Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.KQueueSelectorProvider}} to mvn runner options because NIOs on jdk7 at macosx is said to be buggy but it didn't help.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 12:02:02 2013
From: jira-events at lists.jboss.org (Julien Derveeuw (JIRA))
Date: Tue, 29 Oct 2013 12:02:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBASMP-58) jboss-as-maven-plugin freezes
 on authentication
In-Reply-To: <JIRA.12508946.1383048331000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508946.1383048331000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508946.1383048331000.22376.1383062522033@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBASMP-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Julien Derveeuw updated JBASMP-58:
----------------------------------

    Description: 
I have jboss 7.1.1 in standalone mode running on machine A (linux).
I want to deploy remotely to it using client machine B @ mac os X 10.8.5 / JDK 1.7.0_45-b18.

If I connect from B to A using {{jboss-cli}}, everything works fine, I am able to login.

If I try to deploy from maven with this :
{code:xml}
                <groupId>org.jboss.as.plugins</groupId>
                <artifactId>jboss-as-maven-plugin</artifactId>
                <version>7.5.Final</version>
                <configuration>
                    <hostname>${deploy.jboss.host}</hostname>
                    <port>${deploy.jboss.port}</port>
                    <username>${deploy.jboss.user}</username>
                    <password>${deploy.jboss.password}</password>
                </configuration>

                <executions>
                    <execution>
                        <phase>install</phase>
                        <goals>
                            <goal>deploy</goal>
                        </goals>
                    </execution>
                </executions>
{code}
plugin freezes indefinitely on 
{{Authenticating against security realm: ManagementRealm}}
No more details are available with {{mvn -X}}

If I remove the password or username from pom, it fails correctly with :
{{The connection failed: Authentication failed: all available authentication mechanisms failed}}
so it seems that the plugin somehow manages to connect to machine A.

After digging on google, I ended up adding {{-Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.KQueueSelectorProvider}} to mvn runner options because NIOs on jdk7 at macosx is said to be buggy but it didn't help.



  was:
I have jboss 7.1.1 in standalone mode running on machine A (linux).
I want to deploy remotely to it using client machine B @ mac os X 10.8.5 / JDK 1.7.0_45-b18.

If I connect from B to A using {{jboss-cli}}, everything works fine, I am able to login.

If I try to deploy from maven with this :
{code:xml}
                <groupId>org.jboss.as.plugins</groupId>
                <artifactId>jboss-as-maven-plugin</artifactId>
                <version>7.5.Final</version>
                <configuration>
                    <hostname>${deploy.jboss.host}</hostname>
                    <port>${deploy.jboss.port}</port>
                    <username>${deploy.jboss.user}</username>
                    <password>${deploy.jboss.password}</password>
                </configuration>

                <executions>
                    <execution>
                        <phase>install</phase>
                        <goals>
                            <goal>deploy</goal>
                        </goals>
                    </execution>
                </executions>
{code}
plugin freezes indefinitely on 
{{Authenticating against security realm: ManagementRealm}}
No more details are available with {{mvn -X}}

If I remove the password or username from pom, it fails correctly with :
{{The connection failed: Authentication failed: all available authentication mechanisms failed}}

After digging on google, I ended up adding {{-Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.KQueueSelectorProvider}} to mvn runner options because NIOs on jdk7 at macosx is said to be buggy but it didn't help.




    
> jboss-as-maven-plugin freezes on authentication
> -----------------------------------------------
>
>                 Key: JBASMP-58
>                 URL: https://issues.jboss.org/browse/JBASMP-58
>             Project: JBoss AS Maven Plugins
>          Issue Type: Bug
>          Components: deploy
>    Affects Versions: 7.5.Final
>         Environment: mac os x 10.8.5
>            Reporter: Julien Derveeuw
>            Assignee: James Perkins
>            Priority: Critical
>
> I have jboss 7.1.1 in standalone mode running on machine A (linux).
> I want to deploy remotely to it using client machine B @ mac os X 10.8.5 / JDK 1.7.0_45-b18.
> If I connect from B to A using {{jboss-cli}}, everything works fine, I am able to login.
> If I try to deploy from maven with this :
> {code:xml}
>                 <groupId>org.jboss.as.plugins</groupId>
>                 <artifactId>jboss-as-maven-plugin</artifactId>
>                 <version>7.5.Final</version>
>                 <configuration>
>                     <hostname>${deploy.jboss.host}</hostname>
>                     <port>${deploy.jboss.port}</port>
>                     <username>${deploy.jboss.user}</username>
>                     <password>${deploy.jboss.password}</password>
>                 </configuration>
>                 <executions>
>                     <execution>
>                         <phase>install</phase>
>                         <goals>
>                             <goal>deploy</goal>
>                         </goals>
>                     </execution>
>                 </executions>
> {code}
> plugin freezes indefinitely on 
> {{Authenticating against security realm: ManagementRealm}}
> No more details are available with {{mvn -X}}
> If I remove the password or username from pom, it fails correctly with :
> {{The connection failed: Authentication failed: all available authentication mechanisms failed}}
> so it seems that the plugin somehow manages to connect to machine A.
> After digging on google, I ended up adding {{-Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.KQueueSelectorProvider}} to mvn runner options because NIOs on jdk7 at macosx is said to be buggy but it didn't help.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 12:20:01 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 29 Oct 2013 12:20:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2403) Cannot disable Datasource or
 XADatasource in standalone and domain modes
In-Reply-To: <JIRA.12508938.1383041378000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508938.1383041378000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508938.1383041378000.22425.1383063601911@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825583#comment-12825583 ] 

RH Bugzilla Integration commented on WFLY-2403:
-----------------------------------------------

Stefano Maestri <smaestri at redhat.com> changed the Status of [bug 970679|https://bugzilla.redhat.com/show_bug.cgi?id=970679] from NEW to POST
                
> Cannot disable Datasource or XADatasource in standalone and domain modes
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2403
>                 URL: https://issues.jboss.org/browse/WFLY-2403
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Stefano Maestri
>            Assignee: Stefano Maestri
>
> Description of problem:
> Cannot disable a Datasource or XADatasource in standalone mode. It's back to enabled state after server reload.
> Version-Release number of selected component (if applicable):
> 6.1
> How reproducible:
> Always
> Steps to Reproduce:
> Use the http management interface or the CLI
> 1.Create a Datasource of XADatasource
> 2.Disable it
> 3.The response indicates a server reload is required
> 4.Execute the reload operation
> Actual results:
> The datasource is back to enabled state
> Expected results:
> The datasource should be in disabled state

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 12:30:02 2013
From: jira-events at lists.jboss.org (Kay Wrobel (JIRA))
Date: Tue, 29 Oct 2013 12:30:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-145) Missing validationFailed and
 isValidationFailed Methods in FacesContext
In-Reply-To: <JIRA.12509018.1383064169499@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509018.1383064169499@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509018.1383064169499.22444.1383064202110@jira02.app.mwc.hst.phx2.redhat.com>

Kay Wrobel created JBEE-145:
-------------------------------

             Summary: Missing validationFailed and isValidationFailed Methods in FacesContext
                 Key: JBEE-145
                 URL: https://issues.jboss.org/browse/JBEE-145
             Project: JBoss JavaEE Spec APIs
          Issue Type: Bug
            Reporter: Kay Wrobel
            Assignee: Shelly McGowan




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 12:32:02 2013
From: jira-events at lists.jboss.org (Kay Wrobel (JIRA))
Date: Tue, 29 Oct 2013 12:32:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-145) Missing validationFailed and
 isValidationFailed Methods in FacesContext
In-Reply-To: <JIRA.12509018.1383064169000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509018.1383064169000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509018.1383064169000.22448.1383064322000@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBEE-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kay Wrobel updated JBEE-145:
----------------------------

    Environment: 
Debian GNU Linux 7 64-Bit
Java: 1.7.0_25; OpenJDK 64-Bit Server VM 23.7-b01
Runtime: OpenJDK Runtime Environment 1.7.0_25-b30
System: Linux version 3.2.0-4-amd64 running on amd64; UTF-8; en_US (nb)
JBoss 7.1.1 Final
    Component/s: jboss-jsf-api

    
> Missing validationFailed and isValidationFailed Methods in FacesContext
> -----------------------------------------------------------------------
>
>                 Key: JBEE-145
>                 URL: https://issues.jboss.org/browse/JBEE-145
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: jboss-jsf-api
>         Environment: Debian GNU Linux 7 64-Bit
> Java: 1.7.0_25; OpenJDK 64-Bit Server VM 23.7-b01
> Runtime: OpenJDK Runtime Environment 1.7.0_25-b30
> System: Linux version 3.2.0-4-amd64 running on amd64; UTF-8; en_US (nb)
> JBoss 7.1.1 Final
>            Reporter: Kay Wrobel
>            Assignee: Shelly McGowan
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 12:36:02 2013
From: jira-events at lists.jboss.org (Kay Wrobel (JIRA))
Date: Tue, 29 Oct 2013 12:36:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-145) Missing validationFailed and
 isValidationFailed Methods in FacesContext
In-Reply-To: <JIRA.12509018.1383064169000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509018.1383064169000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509018.1383064169000.22456.1383064562115@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBEE-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kay Wrobel updated JBEE-145:
----------------------------

         Labels: FacesContext JSF2  (was: )
    Description: I have a NetBeans module called PrimeFaces CRUD Generator. One thing I do when an error was detected on a page is add a FacesMessage to the current FacesContext and the invalidate the page with validationFailed() method. My IDE (NetBeans 7.4) cannot compile this code because of missing symbols for validationFailed and isValidationFailed for javax.faces.context.FacesContext. These are supposed to be there according to Oracle Java EE 6 Spec.

    
> Missing validationFailed and isValidationFailed Methods in FacesContext
> -----------------------------------------------------------------------
>
>                 Key: JBEE-145
>                 URL: https://issues.jboss.org/browse/JBEE-145
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: jboss-jsf-api
>         Environment: Debian GNU Linux 7 64-Bit
> Java: 1.7.0_25; OpenJDK 64-Bit Server VM 23.7-b01
> Runtime: OpenJDK Runtime Environment 1.7.0_25-b30
> System: Linux version 3.2.0-4-amd64 running on amd64; UTF-8; en_US (nb)
> JBoss 7.1.1 Final
>            Reporter: Kay Wrobel
>            Assignee: Shelly McGowan
>              Labels: FacesContext, JSF2
>
> I have a NetBeans module called PrimeFaces CRUD Generator. One thing I do when an error was detected on a page is add a FacesMessage to the current FacesContext and the invalidate the page with validationFailed() method. My IDE (NetBeans 7.4) cannot compile this code because of missing symbols for validationFailed and isValidationFailed for javax.faces.context.FacesContext. These are supposed to be there according to Oracle Java EE 6 Spec.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 12:36:02 2013
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Tue, 29 Oct 2013 12:36:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1712) Erroneous name attribute on
 root-logger after add-handler operation
In-Reply-To: <JIRA.12496729.1374094060000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496729.1374094060000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496729.1374094060000.22457.1383064562204@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825588#comment-12825588 ] 

James Perkins commented on WFLY-1712:
-------------------------------------

The name is added in the {{validateAndSet}} which should be assigning to the model. This should likely happen on a new model and the runtime needs a way to get the correct handler name to set or just use the {{setHandlers()}}, but needs to also include any previous handlers.

{code:java}
    static final OperationStepHandler ADD_HANDLER = new LoggerUpdateOperationStepHandler() {

        @Override
        public void updateModel(final ModelNode operation, final ModelNode model) throws OperationFailedException {
            HANDLER_NAME.validateAndSet(operation, model);
            model.get(HANDLERS.getName()).add(operation.get(HANDLER_NAME.getName()));
        }

        @Override
        public void performRuntime(final OperationContext context, final ModelNode operation, final LoggerConfiguration configuration, final String name, final ModelNode model) throws OperationFailedException {
            // Get the handler name
            final String handlerName = HANDLER_NAME.resolveModelAttribute(context, model).asString();
            final String loggerName = getLogManagerLoggerName(name);
            if (configuration.getHandlerNames().contains(handlerName)) {
                throw createOperationFailure(LoggingMessages.MESSAGES.handlerAlreadyDefined(handlerName));
            }
            LoggingLogger.ROOT_LOGGER.tracef("Adding handler '%s' to logger '%s' at '%s'", handlerName, getLogManagerLoggerName(loggerName), LoggingOperations.getAddress(operation));
            configuration.addHandlerName(handlerName);
        }
    };
{code}
                
> Erroneous name attribute on root-logger after add-handler operation 
> --------------------------------------------------------------------
>
>                 Key: WFLY-1712
>                 URL: https://issues.jboss.org/browse/WFLY-1712
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Minor
>
> Execution of the {{add-handler}} operation adds a name attribute with the handlers name to the root-logger model.
> {code}
> "root-logger" => {"ROOT" => {
>             "filter" => undefined,
>             "filter-spec" => undefined,
>             "handlers" => [
>                 "FILE",
>                 "CONSOLE"
>             ],
>             "level" => "INFO",
>             "name" => "CONSOLE"
>         }}
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 12:38:01 2013
From: jira-events at lists.jboss.org (Kay Wrobel (JIRA))
Date: Tue, 29 Oct 2013 12:38:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-145) Missing validationFailed and
 isValidationFailed Methods in FacesContext
In-Reply-To: <JIRA.12509018.1383064169000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509018.1383064169000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509018.1383064169000.22461.1383064681962@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBEE-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kay Wrobel updated JBEE-145:
----------------------------

    Steps to Reproduce: 
Download and install NetBeans 7.4
Add JBoss AS 7.1.1 as a server
Download PrimeFaces CRUD Generator from SourceForge. Make sure it's for implementation 7.4. Install the plugin.
Now, add some entities from a database using the Entity Classes From Database wizard.
Run the PrimeFaces Pages from Entity Classes wizard
Once finished, look at JsfUtil.java. NetBeans highlights lines 29 and 51 with invalid symbol errors.

    
> Missing validationFailed and isValidationFailed Methods in FacesContext
> -----------------------------------------------------------------------
>
>                 Key: JBEE-145
>                 URL: https://issues.jboss.org/browse/JBEE-145
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: jboss-jsf-api
>         Environment: Debian GNU Linux 7 64-Bit
> Java: 1.7.0_25; OpenJDK 64-Bit Server VM 23.7-b01
> Runtime: OpenJDK Runtime Environment 1.7.0_25-b30
> System: Linux version 3.2.0-4-amd64 running on amd64; UTF-8; en_US (nb)
> JBoss 7.1.1 Final
>            Reporter: Kay Wrobel
>            Assignee: Shelly McGowan
>              Labels: FacesContext, JSF2
>
> I have a NetBeans module called PrimeFaces CRUD Generator. One thing I do when an error was detected on a page is add a FacesMessage to the current FacesContext and the invalidate the page with validationFailed() method. My IDE (NetBeans 7.4) cannot compile this code because of missing symbols for validationFailed and isValidationFailed for javax.faces.context.FacesContext. These are supposed to be there according to Oracle Java EE 6 Spec.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 12:46:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 29 Oct 2013 12:46:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1712) Erroneous name attribute on
 root-logger after add-handler operation
In-Reply-To: <JIRA.12496729.1374094060000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496729.1374094060000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496729.1374094060000.22503.1383065163881@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-1712:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1017881

    
> Erroneous name attribute on root-logger after add-handler operation 
> --------------------------------------------------------------------
>
>                 Key: WFLY-1712
>                 URL: https://issues.jboss.org/browse/WFLY-1712
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Minor
>
> Execution of the {{add-handler}} operation adds a name attribute with the handlers name to the root-logger model.
> {code}
> "root-logger" => {"ROOT" => {
>             "filter" => undefined,
>             "filter-spec" => undefined,
>             "handlers" => [
>                 "FILE",
>                 "CONSOLE"
>             ],
>             "level" => "INFO",
>             "name" => "CONSOLE"
>         }}
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 12:46:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 29 Oct 2013 12:46:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1712) Erroneous name attribute on
 root-logger after add-handler operation
In-Reply-To: <JIRA.12496729.1374094060000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496729.1374094060000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496729.1374094060000.22506.1383065163981@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825590#comment-12825590 ] 

RH Bugzilla Integration commented on WFLY-1712:
-----------------------------------------------

James Perkins <jperkins at redhat.com> made a comment on [bug 1017881|https://bugzilla.redhat.com/show_bug.cgi?id=1017881]

I forgot to add. I think we should delay from EAP 6.2 because the workaround is easy enough. The error is only going to occur in composite operations when using multiple add-handler operations to the same logger. 

If we need to get this into 6.2 it is possible, but at this stage I'm not sure it's worth the change for the simple workaround. Also I doubt this use-case, adding handlers to the same logger in a composite operation, is used all that often. This same issue is present in EAP 6.1.x and it's the first time I've seen it.
                
> Erroneous name attribute on root-logger after add-handler operation 
> --------------------------------------------------------------------
>
>                 Key: WFLY-1712
>                 URL: https://issues.jboss.org/browse/WFLY-1712
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Minor
>
> Execution of the {{add-handler}} operation adds a name attribute with the handlers name to the root-logger model.
> {code}
> "root-logger" => {"ROOT" => {
>             "filter" => undefined,
>             "filter-spec" => undefined,
>             "handlers" => [
>                 "FILE",
>                 "CONSOLE"
>             ],
>             "level" => "INFO",
>             "name" => "CONSOLE"
>         }}
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 12:48:03 2013
From: jira-events at lists.jboss.org (Kay Wrobel (JIRA))
Date: Tue, 29 Oct 2013 12:48:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-145) Missing validationFailed and
 isValidationFailed Methods in FacesContext
In-Reply-To: <JIRA.12509018.1383064169000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509018.1383064169000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509018.1383064169000.22539.1383065283888@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBEE-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825591#comment-12825591 ] 

Kay Wrobel commented on JBEE-145:
---------------------------------

Please see http://docs.oracle.com/javaee/6/api/javax/faces/context/FacesContext.html of the Java EE 6 API Documentation.
                
> Missing validationFailed and isValidationFailed Methods in FacesContext
> -----------------------------------------------------------------------
>
>                 Key: JBEE-145
>                 URL: https://issues.jboss.org/browse/JBEE-145
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: jboss-jsf-api
>         Environment: Debian GNU Linux 7 64-Bit
> Java: 1.7.0_25; OpenJDK 64-Bit Server VM 23.7-b01
> Runtime: OpenJDK Runtime Environment 1.7.0_25-b30
> System: Linux version 3.2.0-4-amd64 running on amd64; UTF-8; en_US (nb)
> JBoss 7.1.1 Final
>            Reporter: Kay Wrobel
>            Assignee: Shelly McGowan
>              Labels: FacesContext, JSF2
>
> I have a NetBeans module called PrimeFaces CRUD Generator. One thing I do when an error was detected on a page is add a FacesMessage to the current FacesContext and the invalidate the page with validationFailed() method. My IDE (NetBeans 7.4) cannot compile this code because of missing symbols for validationFailed and isValidationFailed for javax.faces.context.FacesContext. These are supposed to be there according to Oracle Java EE 6 Spec.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 13:02:02 2013
From: jira-events at lists.jboss.org (Kay Wrobel (JIRA))
Date: Tue, 29 Oct 2013 13:02:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-145) Missing validationFailed and
 isValidationFailed Methods in FacesContext
In-Reply-To: <JIRA.12509018.1383064169000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509018.1383064169000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509018.1383064169000.22575.1383066122018@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBEE-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825597#comment-12825597 ] 

Kay Wrobel commented on JBEE-145:
---------------------------------

Just noticed that I am looking at the wrong jar file. JBoss has another jar also containing FacesContext inside jboss-jsf-api_2.1_spec-2.0.1.Final.jar, which DOES contain those two methods. Seems as if the IDE is at fault here.
                
> Missing validationFailed and isValidationFailed Methods in FacesContext
> -----------------------------------------------------------------------
>
>                 Key: JBEE-145
>                 URL: https://issues.jboss.org/browse/JBEE-145
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: jboss-jsf-api
>         Environment: Debian GNU Linux 7 64-Bit
> Java: 1.7.0_25; OpenJDK 64-Bit Server VM 23.7-b01
> Runtime: OpenJDK Runtime Environment 1.7.0_25-b30
> System: Linux version 3.2.0-4-amd64 running on amd64; UTF-8; en_US (nb)
> JBoss 7.1.1 Final
>            Reporter: Kay Wrobel
>            Assignee: Shelly McGowan
>              Labels: FacesContext, JSF2
>
> I have a NetBeans module called PrimeFaces CRUD Generator. One thing I do when an error was detected on a page is add a FacesMessage to the current FacesContext and the invalidate the page with validationFailed() method. My IDE (NetBeans 7.4) cannot compile this code because of missing symbols for validationFailed and isValidationFailed for javax.faces.context.FacesContext. These are supposed to be there according to Oracle Java EE 6 Spec.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 13:04:01 2013
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Tue, 29 Oct 2013 13:04:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-145) Missing validationFailed and
 isValidationFailed Methods in FacesContext
In-Reply-To: <JIRA.12509018.1383064169000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509018.1383064169000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509018.1383064169000.22593.1383066241915@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBEE-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825599#comment-12825599 ] 

Shelly McGowan commented on JBEE-145:
-------------------------------------

What version of the org.jboss.spec.javax.faces version are you using?

The methods are in the 2.0.9.Final version:
https://github.com/jboss/jboss-jsf-api_spec/blob/jboss-jsf-api_2.1_spec-2.0.9.Final/src/main/java/javax/faces/context/FacesContext.java
and 2.1.26.Final
https://github.com/jboss/jboss-jsf-api_spec/blob/jboss-jsf-api_2.1_spec-2.1.26.Final/src/main/java/javax/faces/context/FacesContext.java
                
> Missing validationFailed and isValidationFailed Methods in FacesContext
> -----------------------------------------------------------------------
>
>                 Key: JBEE-145
>                 URL: https://issues.jboss.org/browse/JBEE-145
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: jboss-jsf-api
>         Environment: Debian GNU Linux 7 64-Bit
> Java: 1.7.0_25; OpenJDK 64-Bit Server VM 23.7-b01
> Runtime: OpenJDK Runtime Environment 1.7.0_25-b30
> System: Linux version 3.2.0-4-amd64 running on amd64; UTF-8; en_US (nb)
> JBoss 7.1.1 Final
>            Reporter: Kay Wrobel
>            Assignee: Shelly McGowan
>              Labels: FacesContext, JSF2
>
> I have a NetBeans module called PrimeFaces CRUD Generator. One thing I do when an error was detected on a page is add a FacesMessage to the current FacesContext and the invalidate the page with validationFailed() method. My IDE (NetBeans 7.4) cannot compile this code because of missing symbols for validationFailed and isValidationFailed for javax.faces.context.FacesContext. These are supposed to be there according to Oracle Java EE 6 Spec.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 13:38:02 2013
From: jira-events at lists.jboss.org (Kay Wrobel (JIRA))
Date: Tue, 29 Oct 2013 13:38:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-145) Missing validationFailed and
 isValidationFailed Methods in FacesContext
In-Reply-To: <JIRA.12509018.1383064169000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509018.1383064169000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509018.1383064169000.22650.1383068282713@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBEE-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825609#comment-12825609 ] 

Kay Wrobel commented on JBEE-145:
---------------------------------

You can close this bug. It seems the NetBeans IDE erroneously puts the older JAR in front of the newer jar in the class path for the project inside project.properties. I manually moved the jar references around and can now enjoy my application on JBoss. Maybe it is because alphabetically, the older jar sits in front of the newer jar?
                
> Missing validationFailed and isValidationFailed Methods in FacesContext
> -----------------------------------------------------------------------
>
>                 Key: JBEE-145
>                 URL: https://issues.jboss.org/browse/JBEE-145
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: jboss-jsf-api
>         Environment: Debian GNU Linux 7 64-Bit
> Java: 1.7.0_25; OpenJDK 64-Bit Server VM 23.7-b01
> Runtime: OpenJDK Runtime Environment 1.7.0_25-b30
> System: Linux version 3.2.0-4-amd64 running on amd64; UTF-8; en_US (nb)
> JBoss 7.1.1 Final
>            Reporter: Kay Wrobel
>            Assignee: Shelly McGowan
>              Labels: FacesContext, JSF2
>
> I have a NetBeans module called PrimeFaces CRUD Generator. One thing I do when an error was detected on a page is add a FacesMessage to the current FacesContext and the invalidate the page with validationFailed() method. My IDE (NetBeans 7.4) cannot compile this code because of missing symbols for validationFailed and isValidationFailed for javax.faces.context.FacesContext. These are supposed to be there according to Oracle Java EE 6 Spec.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 13:40:03 2013
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Tue, 29 Oct 2013 13:40:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-145) Missing validationFailed and
 isValidationFailed Methods in FacesContext
In-Reply-To: <JIRA.12509018.1383064169000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509018.1383064169000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509018.1383064169000.22678.1383068403634@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBEE-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan resolved JBEE-145.
---------------------------------

    Resolution: Cannot Reproduce Bug

    
> Missing validationFailed and isValidationFailed Methods in FacesContext
> -----------------------------------------------------------------------
>
>                 Key: JBEE-145
>                 URL: https://issues.jboss.org/browse/JBEE-145
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: jboss-jsf-api
>         Environment: Debian GNU Linux 7 64-Bit
> Java: 1.7.0_25; OpenJDK 64-Bit Server VM 23.7-b01
> Runtime: OpenJDK Runtime Environment 1.7.0_25-b30
> System: Linux version 3.2.0-4-amd64 running on amd64; UTF-8; en_US (nb)
> JBoss 7.1.1 Final
>            Reporter: Kay Wrobel
>            Assignee: Shelly McGowan
>              Labels: FacesContext, JSF2
>
> I have a NetBeans module called PrimeFaces CRUD Generator. One thing I do when an error was detected on a page is add a FacesMessage to the current FacesContext and the invalidate the page with validationFailed() method. My IDE (NetBeans 7.4) cannot compile this code because of missing symbols for validationFailed and isValidationFailed for javax.faces.context.FacesContext. These are supposed to be there according to Oracle Java EE 6 Spec.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 14:00:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 14:00:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-117) The "from" CE does not
 manage @events correctly
In-Reply-To: <JIRA.12475270.1348521759000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12475270.1348521759000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12475270.1348521759000.22756.1383069602637@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-117:
----------------------------------

    Assignee: Mario Fusco  (was: Edson Tirelli)

    
> The "from" CE does not manage @events correctly
> -----------------------------------------------
>
>                 Key: DROOLS-117
>                 URL: https://issues.jboss.org/browse/DROOLS-117
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Critical
>
> If an event type (i.e. an instance of a class marked with @role(event)) is returned by a "from" node, it is not wrapped by an EventFactHandle as expected, so e.g. any attempt to use temporal operators will fail. 
> See the test case below for an example
> The problem is in FromNode.java around line 200, where the new handles are created without passing an ObjectTypeConfiguration, leading to the default creation of a DefaultFactHandle.
> I wonder if it's possible to simply retrieve the ObjectTypeConf:
> workingMemory.getObjectTypeConfigurationRegistry().getObjectTypeConf( context.getEntryPoint(), object )
> and pass it to the handle factory method. 
> I tested it and it works for the test case below, but there may be other
> side-effects I'm not seeing.
> ---------------------------------------------------------------------------
> May be related (but not the same as) #JBRULES-2423

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 14:00:03 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 14:00:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-243) CEP Operators in Rules
 failing to compile when getting PKG
In-Reply-To: <JIRA.12499470.1377630045000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499470.1377630045000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499470.1377630045000.22773.1383069603721@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-243:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> CEP Operators in Rules failing to compile when getting PKG
> ----------------------------------------------------------
>
>                 Key: DROOLS-243
>                 URL: https://issues.jboss.org/browse/DROOLS-243
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Demian Calcaprina
>            Assignee: Mario Fusco
>            Priority: Critical
>
> The issue is described in the following community post:
> http://drools.46999.n3.nabble.com/Problem-with-PKG-from-guvnor-tc4025687.html
> This code can reproduce it:
>     	KnowledgeBaseConfiguration config = KnowledgeBaseFactory.newKnowledgeBaseConfiguration();
>     	config.setOption( EventProcessingOption.STREAM );
>     	KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase(config);
>     	
>     	KnowledgeAgentConfiguration aconf = KnowledgeAgentFactory
> 				.newKnowledgeAgentConfiguration();
> 		aconf.setProperty("drools.agent.scanDirectories", "true");
> 		aconf.setProperty("drools.agent.scanResources", "true");
> 		aconf.setProperty("drools.agent.newInstance", "false");
>         KnowledgeAgent kagent = KnowledgeAgentFactory.newKnowledgeAgent("MortgageAgent", kbase, aconf);
>         Resource changeset = ResourceFactory.newClassPathResource(
>                 "cs.xml");
>         kagent.applyChangeSet(changeset);
>         KnowledgeBase kbase2 = kagent.getKnowledgeBase();
> Creating a changeset that points to a binary package in guvnor, with a rules which uses the temporal operator. For example, somthing like this:
> when 
>         myfact: EventA( main > 21 ) over window:length (1) 
>         myfact2 : EventA( main <= 21 , this before myfact ) over window:length (2) 
> What is happening in that when it tries to compare the temporal distance, it will throw a NPE:
> Caused by: java.lang.NullPointerException 
>         at org.drools.base.evaluators.BeforeEvaluatorDefinition$BeforeEvaluator.getInterval(BeforeEvaluatorDefinition.java:268) [drools-core-5.5.0.Final.jar:5.5.0.Final] 
>         at org.drools.rule.constraint.EvaluatorConstraint.getInterval(EvaluatorConstraint.java:100) [drools-core-5.5.0.Final.jar:5.5.0.Final] 
>         at org.drools.reteoo.builder.BuildUtils.gatherTemporalRelationships(BuildUtils.java:326) [drools-core-5.5.0.Final.jar:5.5.0.Final] 
>         at org.drools.reteoo.builder.BuildUtils.calculateTemporalDistance(BuildUtils.java:292) [drools-core-5.5.0.Final.jar:5.5.0.Final] 
>         at org.drools.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:119) [drools-core-5.5.0.Final.jar:5.5.0.Final] 
>         at org.drools.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:113) [drools-core-5.5.0.Final.jar:5.5.0.Final] 
>         at org.drools.reteoo.ReteooRuleBase.addRule(ReteooRuleBase.java:445) [drools-core-5.5.0.Final.jar:5.5.0.Final] 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 14:00:03 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 14:00:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-117) The "from" CE does not
 manage @events correctly
In-Reply-To: <JIRA.12475270.1348521759000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12475270.1348521759000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12475270.1348521759000.22768.1383069603461@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-117.
--------------------------------

    Fix Version/s: 5.5.1.Final
                   6.0.0.Final
       Resolution: Done

    
> The "from" CE does not manage @events correctly
> -----------------------------------------------
>
>                 Key: DROOLS-117
>                 URL: https://issues.jboss.org/browse/DROOLS-117
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Critical
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> If an event type (i.e. an instance of a class marked with @role(event)) is returned by a "from" node, it is not wrapped by an EventFactHandle as expected, so e.g. any attempt to use temporal operators will fail. 
> See the test case below for an example
> The problem is in FromNode.java around line 200, where the new handles are created without passing an ObjectTypeConfiguration, leading to the default creation of a DefaultFactHandle.
> I wonder if it's possible to simply retrieve the ObjectTypeConf:
> workingMemory.getObjectTypeConfigurationRegistry().getObjectTypeConf( context.getEntryPoint(), object )
> and pass it to the handle factory method. 
> I tested it and it works for the test case below, but there may be other
> side-effects I'm not seeing.
> ---------------------------------------------------------------------------
> May be related (but not the same as) #JBRULES-2423

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 14:02:02 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Tue, 29 Oct 2013 14:02:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-243) CEP Operators in Rules
 failing to compile when getting PKG
In-Reply-To: <JIRA.12499470.1377630045000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499470.1377630045000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499470.1377630045000.22776.1383069722012@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-243.
--------------------------------

    Fix Version/s: 5.5.1.Final
                   6.0.0.Final
       Resolution: Done

    
> CEP Operators in Rules failing to compile when getting PKG
> ----------------------------------------------------------
>
>                 Key: DROOLS-243
>                 URL: https://issues.jboss.org/browse/DROOLS-243
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Demian Calcaprina
>            Assignee: Mario Fusco
>            Priority: Critical
>             Fix For: 5.5.1.Final, 6.0.0.Final
>
>
> The issue is described in the following community post:
> http://drools.46999.n3.nabble.com/Problem-with-PKG-from-guvnor-tc4025687.html
> This code can reproduce it:
>     	KnowledgeBaseConfiguration config = KnowledgeBaseFactory.newKnowledgeBaseConfiguration();
>     	config.setOption( EventProcessingOption.STREAM );
>     	KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase(config);
>     	
>     	KnowledgeAgentConfiguration aconf = KnowledgeAgentFactory
> 				.newKnowledgeAgentConfiguration();
> 		aconf.setProperty("drools.agent.scanDirectories", "true");
> 		aconf.setProperty("drools.agent.scanResources", "true");
> 		aconf.setProperty("drools.agent.newInstance", "false");
>         KnowledgeAgent kagent = KnowledgeAgentFactory.newKnowledgeAgent("MortgageAgent", kbase, aconf);
>         Resource changeset = ResourceFactory.newClassPathResource(
>                 "cs.xml");
>         kagent.applyChangeSet(changeset);
>         KnowledgeBase kbase2 = kagent.getKnowledgeBase();
> Creating a changeset that points to a binary package in guvnor, with a rules which uses the temporal operator. For example, somthing like this:
> when 
>         myfact: EventA( main > 21 ) over window:length (1) 
>         myfact2 : EventA( main <= 21 , this before myfact ) over window:length (2) 
> What is happening in that when it tries to compare the temporal distance, it will throw a NPE:
> Caused by: java.lang.NullPointerException 
>         at org.drools.base.evaluators.BeforeEvaluatorDefinition$BeforeEvaluator.getInterval(BeforeEvaluatorDefinition.java:268) [drools-core-5.5.0.Final.jar:5.5.0.Final] 
>         at org.drools.rule.constraint.EvaluatorConstraint.getInterval(EvaluatorConstraint.java:100) [drools-core-5.5.0.Final.jar:5.5.0.Final] 
>         at org.drools.reteoo.builder.BuildUtils.gatherTemporalRelationships(BuildUtils.java:326) [drools-core-5.5.0.Final.jar:5.5.0.Final] 
>         at org.drools.reteoo.builder.BuildUtils.calculateTemporalDistance(BuildUtils.java:292) [drools-core-5.5.0.Final.jar:5.5.0.Final] 
>         at org.drools.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:119) [drools-core-5.5.0.Final.jar:5.5.0.Final] 
>         at org.drools.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:113) [drools-core-5.5.0.Final.jar:5.5.0.Final] 
>         at org.drools.reteoo.ReteooRuleBase.addRule(ReteooRuleBase.java:445) [drools-core-5.5.0.Final.jar:5.5.0.Final] 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 14:04:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 29 Oct 2013 14:04:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1712) Erroneous name attribute on
 root-logger after add-handler operation
In-Reply-To: <JIRA.12496729.1374094060000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496729.1374094060000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496729.1374094060000.22801.1383069843212@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825621#comment-12825621 ] 

RH Bugzilla Integration commented on WFLY-1712:
-----------------------------------------------

James Perkins <jperkins at redhat.com> made a comment on [bug 1017881|https://bugzilla.redhat.com/show_bug.cgi?id=1017881]

A selected the incorrect flag, I should have nack'd this one. I apologize for that.
                
> Erroneous name attribute on root-logger after add-handler operation 
> --------------------------------------------------------------------
>
>                 Key: WFLY-1712
>                 URL: https://issues.jboss.org/browse/WFLY-1712
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Minor
>
> Execution of the {{add-handler}} operation adds a name attribute with the handlers name to the root-logger model.
> {code}
> "root-logger" => {"ROOT" => {
>             "filter" => undefined,
>             "filter-spec" => undefined,
>             "handlers" => [
>                 "FILE",
>                 "CONSOLE"
>             ],
>             "level" => "INFO",
>             "name" => "CONSOLE"
>         }}
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 14:11:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 29 Oct 2013 14:11:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1499) Clustering tests
 intermittently fail mainly because they do not clean their deployments
 properly
In-Reply-To: <JIRA.12494046.1370968424000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494046.1370968424000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494046.1370968424000.22842.1383070262063@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825623#comment-12825623 ] 

RH Bugzilla Integration commented on WFLY-1499:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 998371|https://bugzilla.redhat.com/show_bug.cgi?id=998371] from ASSIGNED to MODIFIED
                
> Clustering tests intermittently fail mainly because they do not clean their deployments properly
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1499
>                 URL: https://issues.jboss.org/browse/WFLY-1499
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Ivo Studensky
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.Alpha4
>
>
> Almost all clustering tests from the testsuite deploys what they need to perform the test, but almost none of those tests do undeploy of their deployments. Then, if the tests are run in an unexpected order (different JVM) or if some of them fail their deployments keeps at servers and often cause a failure of subsequent tests.
> For example {{RemoteStatelessFailoverTestCase(ejb3)}} stops {{CONTAINER-1}} in the middle of a testLoadBalance method and never tries to undeploy DEPLOYMENT_1 from it. So if it hits any failure in the subsequent {{this.establishView(listener, NODES[1]);}} the {{CONTAINER-1}} will never be started up again by RemoteStatelessFailoverTestCase and hence will never be cleaned up by Arquillian which normally undeploys all deployments from the running custom containers on after-class event. And then StatefulFailoverTestCase fails with 
> {noformat}
> org.jboss.as.test.clustering.ViewChangeListenerServlet threw exception:
> java.lang.InterruptedException: Cluster 'ejb' failed to establish view [node-1/ejb] within 15000 ms.  Current view is: [node-0/ejb, node-1/ejb]
> {noformat}
> Another frequent issue with clustering tests is that they blindly deploy the same deployments manytimes which leads to duplicate deploy failures.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 14:19:02 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Tue, 29 Oct 2013 14:19:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2218) Subsystem transformers
	against 7.2.0
In-Reply-To: <JIRA.12502213.1380892269000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502213.1380892269000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502213.1380892269000.22860.1383070742086@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825626#comment-12825626 ] 

Kabir Khan commented on WFLY-2218:
----------------------------------

We should also test against previous EAP versions to make sure that WF upstream does not stray too far from EAP making backwards compatibility for EAP hard in the future when WF becomes EAP.

Since the EAP legacy maven artifacts are only available for Red Hat employees with access to the VPM, we don't want to make it impossible for third-party contributors to contribute. Also we don't want to make build times jump for everyday subsystem builds.
To help with this there is an AbstractSubsystemTest.ignoreThisTestIfEAPRepositoryIsNotReachable() method. An example of its usage can be found in https://github.com/wildfly/wildfly/blob/master/weld/src/test/java/org/jboss/as/weld/WeldSubsystemTestCase.java.This checks if the following two conditions are true:
* -Djboss.test.transformers.eap is set when starting the build
* The EAP repository is available (i.e. you are currently connected to the VPN)

If those conditions are not true, tests calling that method end up being skipped (similar to if they had been @Ignore'd but more dynamic/environmental)
                
> Subsystem transformers against 7.2.0
> ------------------------------------
>
>                 Key: WFLY-2218
>                 URL: https://issues.jboss.org/browse/WFLY-2218
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.CR1
>            Reporter: Kabir Khan
>            Assignee: Brian Stansberry
>
> We have not tested the majority of subsystem transformers against AS 7.2.0. I have attempted to document why we need subsystem transformation here, and also how to use the framework: 
> https://docs.jboss.org/author/display/WFLY8/Domain+Mode+Subsystem+Transformers
> This document is WIP, and I will be updating it a bit more over the next few days.
> https://gist.github.com/kabir/6825607 contains the difference of a running WildFly instance against AS 7.2.0 in domain mode (for subsystems you don't really need to bother about this one)
> https://gist.github.com/kabir/6825559 contains the difference of a running WildFly instance against AS 7.2.0 in standalone mode, here you can see what has changed in the subsystems.
> When creating a new subsystem transformers test against 7.2.0, you will need the resource definition for the ModelVersion your subsystem uses in 7.2.0. If this is not found, you need to add a test to your subsystem, which you can delete once you have the .dmr file containing the resource defintion. Here is what I did to generate the file for JMX
> {code}
>     @Test
>     public void deleteMeWhenDone() throws Exception {
>         ModelTestControllerVersion controllerVersion = ModelTestControllerVersion.V7_2_0_FINAL;
>         ModelVersion modelVersion = ModelVersion.create(1, 1, 0); //Whatever version of your subsystem 7.2.0.Final has
>         KernelServicesBuilder builder = createKernelServicesBuilder(null);
>         builder.createLegacyKernelServicesBuilder(null, controllerVersion, modelVersion)
>             .addMavenResourceURL("org.jboss.as:jboss-as-jmx:" + controllerVersion.getMavenGavVersion());
>         KernelServices services = builder.build();
>         generateLegacySubsystemResourceRegistrationDmr(services, modelVersion);
>     }
> {code}
> Now run the test and delete it. The legacy .dmr file should be in {{target/test-classes/org/jboss/as/subsystem/test/<your-subsystem-name>-<your-version>.dmr}}. Copy this .dmr file to {{subsystem-test/framework/src/main/resources/org/jboss/as/subsystem/test}}.
> You will likely also need to update org.jboss.as.subsystem.test.KnownVersions to include your latest subsystem version, once you start doing real testing.
> Bear in mind that if you need to add some transformation to 7.2.0 due to some new feature in WildFly 8, you will probably also need to add the same transformation to 7.1.x as well!
> Although some subsystems already have added transformers, we still need to add tests.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 14:29:02 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Tue, 29 Oct 2013 14:29:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2218) Subsystem transformers
	against 7.2.0
In-Reply-To: <JIRA.12502213.1380892269000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502213.1380892269000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502213.1380892269000.22881.1383071342133@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825629#comment-12825629 ] 

Kabir Khan commented on WFLY-2218:
----------------------------------

WIP of the testing of transformers for prior EAP versions can be found on my https://github.com/kabir/wildfly/compare/subsystem-test-previous-eap-versions branch. I'll do this for all subsystems that have transformers for 7.2.0 at this stage.
                
> Subsystem transformers against 7.2.0
> ------------------------------------
>
>                 Key: WFLY-2218
>                 URL: https://issues.jboss.org/browse/WFLY-2218
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.CR1
>            Reporter: Kabir Khan
>            Assignee: Brian Stansberry
>
> We have not tested the majority of subsystem transformers against AS 7.2.0. I have attempted to document why we need subsystem transformation here, and also how to use the framework: 
> https://docs.jboss.org/author/display/WFLY8/Domain+Mode+Subsystem+Transformers
> This document is WIP, and I will be updating it a bit more over the next few days.
> https://gist.github.com/kabir/6825607 contains the difference of a running WildFly instance against AS 7.2.0 in domain mode (for subsystems you don't really need to bother about this one)
> https://gist.github.com/kabir/6825559 contains the difference of a running WildFly instance against AS 7.2.0 in standalone mode, here you can see what has changed in the subsystems.
> When creating a new subsystem transformers test against 7.2.0, you will need the resource definition for the ModelVersion your subsystem uses in 7.2.0. If this is not found, you need to add a test to your subsystem, which you can delete once you have the .dmr file containing the resource defintion. Here is what I did to generate the file for JMX
> {code}
>     @Test
>     public void deleteMeWhenDone() throws Exception {
>         ModelTestControllerVersion controllerVersion = ModelTestControllerVersion.V7_2_0_FINAL;
>         ModelVersion modelVersion = ModelVersion.create(1, 1, 0); //Whatever version of your subsystem 7.2.0.Final has
>         KernelServicesBuilder builder = createKernelServicesBuilder(null);
>         builder.createLegacyKernelServicesBuilder(null, controllerVersion, modelVersion)
>             .addMavenResourceURL("org.jboss.as:jboss-as-jmx:" + controllerVersion.getMavenGavVersion());
>         KernelServices services = builder.build();
>         generateLegacySubsystemResourceRegistrationDmr(services, modelVersion);
>     }
> {code}
> Now run the test and delete it. The legacy .dmr file should be in {{target/test-classes/org/jboss/as/subsystem/test/<your-subsystem-name>-<your-version>.dmr}}. Copy this .dmr file to {{subsystem-test/framework/src/main/resources/org/jboss/as/subsystem/test}}.
> You will likely also need to update org.jboss.as.subsystem.test.KnownVersions to include your latest subsystem version, once you start doing real testing.
> Bear in mind that if you need to add some transformation to 7.2.0 due to some new feature in WildFly 8, you will probably also need to add the same transformation to 7.1.x as well!
> Although some subsystems already have added transformers, we still need to add tests.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 14:38:03 2013
From: jira-events at lists.jboss.org (sai sri harsha gudladona (JIRA))
Date: Tue, 29 Oct 2013 14:38:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBAS-6998) ProfileServiceBootstrap:
 Failed to build ManagedDeployment
In-Reply-To: <JIRA.12387417.1244015933000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12387417.1244015933000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12387417.1244015933000.22909.1383071883190@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBAS-6998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825631#comment-12825631 ] 

sai sri harsha gudladona commented on JBAS-6998:
------------------------------------------------

The Link for the cause of this issue posted under http://www.jboss.org/community/wiki/ClassLoaderhasnotbeensetexceptioninbootlog is not working. A fix or the new Link is appreciated.
                
> ProfileServiceBootstrap: Failed to build ManagedDeployment
> ----------------------------------------------------------
>
>                 Key: JBAS-6998
>                 URL: https://issues.jboss.org/browse/JBAS-6998
>             Project: Application Server 3  4  5 and 6
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: JBoss AS 5.1.0, WinXP, jdk 1.6.0u13
>            Reporter: Ondrej Medek
>            Assignee: Andrew Rubinger
>             Fix For: No Release
>
>         Attachments: boot.log, boot.log.zip
>
>
> I see two exception in my boot.log: DEBUG [ProfileServiceBootstrap] Failed to build ManagedDeployment for:
> 1) AbstractKernelDeployment at 1cd427a{name=file:/C:/data/a/jboss-5.1.0.GA/server/default/conf/bootstrap/vfs.xml installed=true beanFactories=[AbstractBeanMetaData at c791f4{name=VFSCache bean=null properties=[realCache, permanentRoots] constructor=AbstractConstructorMetaData at 198defc{parameters=[null] factoryClass=org.jboss.virtual.spi.cache.VFSCacheFactory factoryMethod=getInstance} autowireCandidate=true start=AbstractLifecycleMetaData at 1579a30{ whenRequired=ControllerState at 3f58bb{Start} parameters= }}, AbstractBeanMetaData at da9067{name=VfsNamesExceptionHandler bean=org.jboss.virtual.plugins.context.helpers.NamesExceptionHandler properties= constructor=AbstractConstructorMetaData at 13e9934{parameters=[java.lang.String]} autowireCandidate=true}]}
> org.jboss.deployers.spi.DeploymentException: Error deploying: file:/C:/data/a/jboss-5.1.0.GA/server/default/conf/bootstrap/vfs.xml
> 	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
> 2) AbstractKernelDeployment at 17044c5{name=file:/C:/data/a/jboss-5.1.0.GA/server/default/conf/bootstrap/logging.xml installed=true beanFactories=[AbstractBeanMetaData at 1b2e44d{name=LogBridgeHandler bean=org.jboss.logbridge.LogBridgeHandler properties= constructor=null autowireCandidate=true}]}
> org.jboss.deployers.spi.DeploymentException: Error deploying: file:/C:/data/a/jboss-5.1.0.GA/server/default/conf/bootstrap/logging.xml
> 	at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 15:04:01 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 29 Oct 2013 15:04:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2405) Update
 'LdapConnectionManagerService' to use the attribute definitions to read
 from the model.
In-Reply-To: <JIRA.12509037.1383073391543@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509037.1383073391543@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509037.1383073391543.22955.1383073441942@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-2405:
--------------------------------------

             Summary: Update 'LdapConnectionManagerService' to use the attribute definitions to read from the model.
                 Key: WFLY-2405
                 URL: https://issues.jboss.org/browse/WFLY-2405
             Project: WildFly
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Domain Management, Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 15:06:01 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 29 Oct 2013 15:06:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2406) Inconsistence in runtime
 updates for outbound LDAP connections.
In-Reply-To: <JIRA.12509038.1383073483396@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509038.1383073483396@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509038.1383073483396.22959.1383073561992@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-2406:
--------------------------------------

             Summary: Inconsistence in runtime updates for outbound LDAP connections.
                 Key: WFLY-2406
                 URL: https://issues.jboss.org/browse/WFLY-2406
             Project: WildFly
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Domain Management, Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 8.0.0.CR1


Adding a new outbound LDAP connection results in runtime updates for all processes but modifying an attribute runtime is only updates for a normal server.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 16:55:02 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 29 Oct 2013 16:55:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2169) Add support to change various
 Undertow listener options
In-Reply-To: <JIRA.12501691.1380249028000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501691.1380249028000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501691.1380249028000.23008.1383080102156@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar resolved WFLY-2169.
-------------------------------

    Fix Version/s: 8.0.0.CR1
       Resolution: Done


Exposed all options available under UndertowOptions
                
> Add support to change various Undertow listener options
> -------------------------------------------------------
>
>                 Key: WFLY-2169
>                 URL: https://issues.jboss.org/browse/WFLY-2169
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Alpha4
>         Environment: Ubuntu 12.04 LTS, openjdk-7-jdk-7u25-2.3.10-1ubuntu0.12.04.2
>            Reporter: Bernd Nigmann
>            Assignee: Tomaz Cerar
>             Fix For: 8.0.0.CR1
>
>
> Undertow's default for the maximum number of HTTP parameter it parses in a GET or POST is 1000:
> {noformat}
> 15:05:41,276 ERROR [io.undertow.request] (default task-17)
>    Servlet request failed HttpServerExchange{ POST /***/*******/****}:
>    java.lang.IllegalStateException: UT000047: The number of
>    parameters exceeded the maximum of 1000
> {noformat}
> In the Undertow sources (https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io/undertow/UndertowOptions.java), I found this to be a configurable option: "{{MAX_PARAMETERS}}".
> Please allow changing some of these Undertow options through the WildFly {{standalone.xml}}. Tomaz Cerar asked me to create a ticket for this, based on the referenced forum thread.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 17:03:02 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 29 Oct 2013 17:03:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2017) Add ability to set XNIO
 options for listeners
In-Reply-To: <JIRA.12500194.1378462536000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500194.1378462536000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500194.1378462536000.23022.1383080582098@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar resolved WFLY-2017.
-------------------------------

    Fix Version/s: 8.0.0.CR1
       Resolution: Done


now you can set all options defined in UndertowOptions on all listeners  SSL_CLIENT_AUTH_MODE for https listener.
                
> Add ability to set XNIO options for listeners
> ---------------------------------------------
>
>                 Key: WFLY-2017
>                 URL: https://issues.jboss.org/browse/WFLY-2017
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>            Reporter: Stuart Douglas
>            Assignee: Tomaz Cerar
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Oct 29 17:35:01 2013
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Tue, 29 Oct 2013 17:35:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2407) Upgrade to MSC 1.2.0.CR1
In-Reply-To: <JIRA.12509048.1383082489864@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509048.1383082489864@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509048.1383082489864.23089.1383082501893@jira02.app.mwc.hst.phx2.redhat.com>

Richard Opalka created WFLY-2407:
------------------------------------

             Summary: Upgrade to MSC 1.2.0.CR1
                 Key: WFLY-2407
                 URL: https://issues.jboss.org/browse/WFLY-2407
             Project: WildFly
          Issue Type: Component  Upgrade
      Security Level: Public (Everyone can see)
          Components: MSC
            Reporter: Richard Opalka
            Assignee: Richard Opalka
             Fix For: 8.0.0.CR1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 04:21:02 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Wed, 30 Oct 2013 04:21:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2027) EE Default DataSource is not
	working
In-Reply-To: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500313.1378739268000.23300.1383121262501@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow closed WFLY-2027.
------------------------------

    Resolution: Done


Fix for WFLY-2212 was merged.
                
> EE Default DataSource is not working
> ------------------------------------
>
>                 Key: WFLY-2027
>                 URL: https://issues.jboss.org/browse/WFLY-2027
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ConfigAdmin, Domain Management, EE, JCA, JPA / Hibernate, Web Console
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Lincoln Baxter III
>            Assignee: Eduardo Martins
>             Fix For: 8.0.0.Beta1
>
>
> The EE spec states that a default datasource must be supplied under: java:comp/DefaultDataSource, and if none is specified by the @Resource or persistence.xml, it must be assumed:
>  {code}EE 5.19
> The Java EE Platform requires that a Java EE Product Provider provide a database 
> in the operational environment (see Section EE.2.6, ?Database?). The Java EE 
> Product Provider must also provide a preconfigured, default data source for use by 
> the application in accessing this database.
> The Java EE Product Provider must make the default data source accessible to 
> the application under the JNDI name java:comp/DefaultDataSource.
> The Application Component Provider or Deployer may explicitly bind a 
> DataSource resource reference to the default data source using the lookup element 
> of the Resource annotation or the lookup-name element of the resource-ref
> deployment descriptor element. For example,
> @Resource(lookup="java:comp/DefaultDataSource")
> DataSource myDS;
> In the absence of such a binding, the mapping of the reference will default to 
> the product's default data source.
> For example, the following will map to a preconfigured data source for the 
> product's default database:
> @Resource
> DataSource myDS;{code}
> This, isn't working however:
> {code}
> <persistence version="2.1" xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>    xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/persistence/persistence_2_1.xsd">
>    <persistence-unit name="default" transaction-type="JTA">
>    </persistence-unit>
> </persistence>{code}
> Results in: 
> {code}
> 10:41:31,002 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 50) MSC000001: Failed to start service jboss.persistenceunit."jpa-standard.war#default": org.jboss.msc.service.StartException in service jboss.persistenceunit."jpa-standard.war#default": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:134) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.determineDialect(DialectFactoryImpl.java:98)
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.buildDialect(DialectFactoryImpl.java:66)
> 	at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:193)
> 	at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:88)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:159)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131)
> 	at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration.java:1844)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1802)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:844)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835)
> 	at org.jboss.as.jpa.hibernate4.management.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:115) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	... 4 more
> 10:41:31,010 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"jpa-standard.war#default\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"jpa-standard.war#default\": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
>     Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set"}}
> {code}
> Additionally, actually specifying the expected JDNI name of the default DS like this:
> {code}   <persistence-unit name="default" transaction-type="JTA">
>       <jta-data-source>java:comp/DefaultDataSource</jta-data-source>
>       <exclude-unlisted-classes>false</exclude-unlisted-classes>
>    </persistence-unit>{code}
> Results in this:
> {code}
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.naming.context.java.module.jpa-standard.jpa-standard.DefaultDataSource (missing) dependents: [service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__] 
>       service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__ (missing) dependents: [service jboss.deployment.unit."jpa-standard.war".POST_MODULE] 
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Wed Oct 30 05:49:01 2013
From: jira-events at lists.jboss.org (Gytis Trikleris (JIRA))
Date: Wed, 30 Oct 2013 05:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2201) Server-side XTS handlers not
 added if @WebService#portName is missing
In-Reply-To: <JIRA.12501360.1380015769000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501360.1380015769000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501360.1380015769000.23384.1383126541972@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gytis Trikleris closed WFLY-2201.
---------------------------------


    
> Server-side XTS handlers not added if @WebService#portName is missing
> ---------------------------------------------------------------------
>
>                 Key: WFLY-2201
>                 URL: https://issues.jboss.org/browse/WFLY-2201
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: XTS
>            Reporter: Paul Robinson
>            Assignee: Gytis Trikleris
>            Priority: Minor
>             Fix For: 8.0.0.CR1
>
>
> To reproduce, remove portName or targetNameSpace attributes from org.jboss.narayana.compensations.functional.distributed.DistributedTest in the TXFramework suite. You will see that the test fails with:
> {code}
> "MustUnderstand headers: [{http://docs.oasis-open.org/ws-tx/wscoor/2006/06}CoordinationContext] are not understood"
> {code}
> The problem is that the Endpoint is not recognised, by the XTS subsytem, as having a valid @WebService annotation if these attributes are missing. In reality they are optional and an application should be allowed to leave them off. However, these attribute values are used by the XTS subsytem, so we would need to find a way of using the defaults if they are missing from the annotation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 06:43:01 2013
From: jira-events at lists.jboss.org (Eduardo Martins (JIRA))
Date: Wed, 30 Oct 2013 06:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1979) Default EE default bindings
	per-deployment
In-Reply-To: <JIRA.12499747.1378117211000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499747.1378117211000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499747.1378117211000.23505.1383129781974@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Eduardo Martins resolved WFLY-1979.
-----------------------------------

    Resolution: Won't Fix


I will reject this for now, and wait for community asking for such feature.
                
> Default EE default bindings per-deployment
> ------------------------------------------
>
>                 Key: WFLY-1979
>                 URL: https://issues.jboss.org/browse/WFLY-1979
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: EE
>            Reporter: Eduardo Martins
>            Assignee: Eduardo Martins
>
> Deployments/Components should have the possibility of overriding what EE default bindings, introduced by WFLY-2158.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 06:58:02 2013
From: jira-events at lists.jboss.org (Jozef Hartinger (JIRA))
Date: Wed, 30 Oct 2013 06:58:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2397) When using weld resource
 injection happens twice
In-Reply-To: <JIRA.12508920.1383030661000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508920.1383030661000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508920.1383030661000.23525.1383130682054@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825727#comment-12825727 ] 

Jozef Hartinger commented on WFLY-2397:
---------------------------------------

I will check and fix as part of WFLY-2375.
                
> When using weld resource injection happens twice
> ------------------------------------------------
>
>                 Key: WFLY-2397
>                 URL: https://issues.jboss.org/browse/WFLY-2397
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>
> When using CDI to inject non-EJB components such as Servlets it appears both Weld and WF are performing resource injections.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 06:58:02 2013
From: jira-events at lists.jboss.org (Jozef Hartinger (JIRA))
Date: Wed, 30 Oct 2013 06:58:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2397) When using weld resource
 injection happens twice
In-Reply-To: <JIRA.12508920.1383030661000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508920.1383030661000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508920.1383030661000.23528.1383130682265@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Hartinger reassigned WFLY-2397:
-------------------------------------

    Assignee: Jozef Hartinger  (was: Stuart Douglas)

    
> When using weld resource injection happens twice
> ------------------------------------------------
>
>                 Key: WFLY-2397
>                 URL: https://issues.jboss.org/browse/WFLY-2397
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Stuart Douglas
>            Assignee: Jozef Hartinger
>
> When using CDI to inject non-EJB components such as Servlets it appears both Weld and WF are performing resource injections.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 08:41:01 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 30 Oct 2013 08:41:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2408) Add TRACE logging for
 connection properties used to connect to LDAP from realm.
In-Reply-To: <JIRA.12509083.1383136851347@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509083.1383136851347@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509083.1383136851347.23771.1383136861953@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-2408:
--------------------------------------

             Summary: Add TRACE logging for connection properties used to connect to LDAP from realm.
                 Key: WFLY-2408
                 URL: https://issues.jboss.org/browse/WFLY-2408
             Project: WildFly
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Domain Management, Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 8.0.0.CR1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 08:58:02 2013
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Wed, 30 Oct 2013 08:58:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2409) Intermittent failures in
 SessionClusterDbPersistenceTestCase
In-Reply-To: <JIRA.12509093.1383137843178@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509093.1383137843178@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509093.1383137843178.23834.1383137882529@jira02.app.mwc.hst.phx2.redhat.com>

Paul Ferraro created WFLY-2409:
----------------------------------

             Summary: Intermittent failures in SessionClusterDbPersistenceTestCase
                 Key: WFLY-2409
                 URL: https://issues.jboss.org/browse/WFLY-2409
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Clustering, Test Suite
            Reporter: Paul Ferraro
            Assignee: Tomas Remes


&amp;#27;[0m&amp;#27;[31m08:43:00,006 ERROR [org.infinispan.persistence.jdbc.binary.JdbcBinaryStore] (default task-7) ISPN008012: Sql failure while inserting bucket: Bucket{entries={7KMFRGBkll3_n5BYO0U3U-0c=MarshalledEntryImpl{keyBytes=35 bytes, valueBytes=270 bytes, metadataBytes=25 bytes, key=7KMFRGBkll3_n5BYO0U3U-0c, value={test=1}, metadata=InternalMetadataImpl{actual=EmbeddedMetadata{version=null}, created=-1, lastUsed=-1}, marshaller=org.infinispan.marshall.core.CacheMarshaller at 5b081828}}, bucketId=&apos;865627136&apos;}: org.h2.jdbc.JdbcSQLException: Unique index or primary key violation: &quot;PRIMARY_KEY_A ON PUBLIC.&quot;&quot;binarybased_default_host_session_db_cluster&quot;&quot;(ID) VALUES ( /* key:2 */ &apos;865627136&apos;, X&apos; &apos;, -1)&quot;; SQL statement:
INSERT INTO &quot;binarybased_default_host_session_db_cluster&quot; (datum, version, id) VALUES(?,?,?) [23505-173]
	at org.h2.message.DbException.getJdbcSQLException(DbException.java:331)
	at org.h2.message.DbException.get(DbException.java:171)
	at org.h2.message.DbException.get(DbException.java:148)
	at org.h2.index.BaseIndex.getDuplicateKeyException(BaseIndex.java:101)
	at org.h2.index.TreeIndex.add(TreeIndex.java:68)
	at org.h2.table.RegularTable.addRow(RegularTable.java:125)
	at org.h2.command.dml.Insert.insertRows(Insert.java:127)
	at org.h2.command.dml.Insert.update(Insert.java:86)
	at org.h2.command.CommandContainer.update(CommandContainer.java:79)
	at org.h2.command.Command.executeUpdate(Command.java:235)
	at org.h2.jdbc.JdbcPreparedStatement.executeUpdateInternal(JdbcPreparedStatement.java:154)
	at org.h2.jdbc.JdbcPreparedStatement.executeUpdate(JdbcPreparedStatement.java:140)
	at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:493)
	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.insertBucket(JdbcBinaryStore.java:405)
	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.storeInBucket(JdbcBinaryStore.java:519)
	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.write(JdbcBinaryStore.java:122)
	at org.infinispan.persistence.manager.PersistenceManagerImpl.writeToAllStores(PersistenceManagerImpl.java:432) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.CacheWriterInterceptor$Updater.visitSingleStore(CacheWriterInterceptor.java:306) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.CacheWriterInterceptor$Updater.visitPutKeyValueCommand(CacheWriterInterceptor.java:250) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.CacheWriterInterceptor.store(CacheWriterInterceptor.java:212) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.CacheWriterInterceptor.commitCommand(CacheWriterInterceptor.java:115) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.CacheWriterInterceptor.visitPrepareCommand(CacheWriterInterceptor.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.EntryWrappingInterceptor.visitPrepareCommand(EntryWrappingInterceptor.java:93) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.invokeNextAndCommitIf1Pc(AbstractTxLockingInterceptor.java:93) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitPrepareCommand(PessimisticLockingInterceptor.java:83) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.NotificationInterceptor.visitPrepareCommand(NotificationInterceptor.java:36) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.TxInterceptor.invokeNextInterceptorAndVerifyTransaction(TxInterceptor.java:114) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.TxInterceptor.visitPrepareCommand(TxInterceptor.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitPrepareCommand(TransactionSynchronizerInterceptor.java:42) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:253) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.statetransfer.StateTransferInterceptor.handleTxCommand(StateTransferInterceptor.java:184) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.statetransfer.StateTransferInterceptor.visitPrepareCommand(StateTransferInterceptor.java:89) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:106) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:70) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:70) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:321) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.transaction.TransactionCoordinator.commit(TransactionCoordinator.java:154) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:58) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.transaction.tm.DummyTransaction.notifyAfterCompletion(DummyTransaction.java:263) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.transaction.tm.DummyTransaction.runCommitTx(DummyTransaction.java:312) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:69) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:80) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:83) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:64) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.CacheImpl.endBatch(CacheImpl.java:768) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:53) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.end(InfinispanSessionManager.java:151)
	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.close(InfinispanSessionManager.java:141)
	at org.wildfly.clustering.web.undertow.session.SessionAdapter.requestDone(SessionAdapter.java:69)
	at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:708) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:501) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:258) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:138) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:622) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]

&amp;#27;[0m&amp;#27;[31m08:43:00,018 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-7) ISPN000136: Execution error: org.infinispan.persistence.CacheLoaderException: Sql failure while inserting bucket: Bucket{entries={7KMFRGBkll3_n5BYO0U3U-0c=MarshalledEntryImpl{keyBytes=35 bytes, valueBytes=270 bytes, metadataBytes=25 bytes, key=7KMFRGBkll3_n5BYO0U3U-0c, value={test=1}, metadata=InternalMetadataImpl{actual=EmbeddedMetadata{version=null}, created=-1, lastUsed=-1}, marshaller=org.infinispan.marshall.core.CacheMarshaller at 5b081828}}, bucketId=&apos;865627136&apos;}
	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.insertBucket(JdbcBinaryStore.java:411)
	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.storeInBucket(JdbcBinaryStore.java:519)
	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.write(JdbcBinaryStore.java:122)
	at org.infinispan.persistence.manager.PersistenceManagerImpl.writeToAllStores(PersistenceManagerImpl.java:432) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.CacheWriterInterceptor$Updater.visitSingleStore(CacheWriterInterceptor.java:306) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.CacheWriterInterceptor$Updater.visitPutKeyValueCommand(CacheWriterInterceptor.java:250) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.CacheWriterInterceptor.store(CacheWriterInterceptor.java:212) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.CacheWriterInterceptor.commitCommand(CacheWriterInterceptor.java:115) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.CacheWriterInterceptor.visitPrepareCommand(CacheWriterInterceptor.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.EntryWrappingInterceptor.visitPrepareCommand(EntryWrappingInterceptor.java:93) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.invokeNextAndCommitIf1Pc(AbstractTxLockingInterceptor.java:93) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitPrepareCommand(PessimisticLockingInterceptor.java:83) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.NotificationInterceptor.visitPrepareCommand(NotificationInterceptor.java:36) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.TxInterceptor.invokeNextInterceptorAndVerifyTransaction(TxInterceptor.java:114) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.TxInterceptor.visitPrepareCommand(TxInterceptor.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitPrepareCommand(TransactionSynchronizerInterceptor.java:42) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:253) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.statetransfer.StateTransferInterceptor.handleTxCommand(StateTransferInterceptor.java:184) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.statetransfer.StateTransferInterceptor.visitPrepareCommand(StateTransferInterceptor.java:89) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:106) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:70) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:70) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:321) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.transaction.TransactionCoordinator.commit(TransactionCoordinator.java:154) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:58) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.transaction.tm.DummyTransaction.notifyAfterCompletion(DummyTransaction.java:263) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.transaction.tm.DummyTransaction.runCommitTx(DummyTransaction.java:312) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:69) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:80) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:83) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:64) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.CacheImpl.endBatch(CacheImpl.java:768) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:53) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.end(InfinispanSessionManager.java:151)
	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.close(InfinispanSessionManager.java:141)
	at org.wildfly.clustering.web.undertow.session.SessionAdapter.requestDone(SessionAdapter.java:69)
	at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:708) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:501) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:258) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:138) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:622) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
Caused by: org.h2.jdbc.JdbcSQLException: Unique index or primary key violation: &quot;PRIMARY_KEY_A ON PUBLIC.&quot;&quot;binarybased_default_host_session_db_cluster&quot;&quot;(ID) VALUES ( /* key:2 */ &apos;865627136&apos;, X&apos; &apos;, -1)&quot;; SQL statement:
INSERT INTO &quot;binarybased_default_host_session_db_cluster&quot; (datum, version, id) VALUES(?,?,?) [23505-173]
	at org.h2.message.DbException.getJdbcSQLException(DbException.java:331)
	at org.h2.message.DbException.get(DbException.java:171)
	at org.h2.message.DbException.get(DbException.java:148)
	at org.h2.index.BaseIndex.getDuplicateKeyException(BaseIndex.java:101)
	at org.h2.index.TreeIndex.add(TreeIndex.java:68)
	at org.h2.table.RegularTable.addRow(RegularTable.java:125)
	at org.h2.command.dml.Insert.insertRows(Insert.java:127)
	at org.h2.command.dml.Insert.update(Insert.java:86)
	at org.h2.command.CommandContainer.update(CommandContainer.java:79)
	at org.h2.command.Command.executeUpdate(Command.java:235)
	at org.h2.jdbc.JdbcPreparedStatement.executeUpdateInternal(JdbcPreparedStatement.java:154)
	at org.h2.jdbc.JdbcPreparedStatement.executeUpdate(JdbcPreparedStatement.java:140)
	at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:493)
	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.insertBucket(JdbcBinaryStore.java:405)
	... 77 more

&amp;#27;[0m&amp;#27;[31m08:43:00,023 ERROR [org.infinispan.transaction.TransactionCoordinator] (default task-7) ISPN000097: Error while processing a prepare in a single-phase transaction: org.infinispan.persistence.CacheLoaderException: Sql failure while inserting bucket: Bucket{entries={7KMFRGBkll3_n5BYO0U3U-0c=MarshalledEntryImpl{keyBytes=35 bytes, valueBytes=270 bytes, metadataBytes=25 bytes, key=7KMFRGBkll3_n5BYO0U3U-0c, value={test=1}, metadata=InternalMetadataImpl{actual=EmbeddedMetadata{version=null}, created=-1, lastUsed=-1}, marshaller=org.infinispan.marshall.core.CacheMarshaller at 5b081828}}, bucketId=&apos;865627136&apos;}
	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.insertBucket(JdbcBinaryStore.java:411)
	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.storeInBucket(JdbcBinaryStore.java:519)
	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.write(JdbcBinaryStore.java:122)
	at org.infinispan.persistence.manager.PersistenceManagerImpl.writeToAllStores(PersistenceManagerImpl.java:432) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.CacheWriterInterceptor$Updater.visitSingleStore(CacheWriterInterceptor.java:306) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.CacheWriterInterceptor$Updater.visitPutKeyValueCommand(CacheWriterInterceptor.java:250) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.CacheWriterInterceptor.store(CacheWriterInterceptor.java:212) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.CacheWriterInterceptor.commitCommand(CacheWriterInterceptor.java:115) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.CacheWriterInterceptor.visitPrepareCommand(CacheWriterInterceptor.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.EntryWrappingInterceptor.visitPrepareCommand(EntryWrappingInterceptor.java:93) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.invokeNextAndCommitIf1Pc(AbstractTxLockingInterceptor.java:93) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitPrepareCommand(PessimisticLockingInterceptor.java:83) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.NotificationInterceptor.visitPrepareCommand(NotificationInterceptor.java:36) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.TxInterceptor.invokeNextInterceptorAndVerifyTransaction(TxInterceptor.java:114) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.TxInterceptor.visitPrepareCommand(TxInterceptor.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitPrepareCommand(TransactionSynchronizerInterceptor.java:42) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:253) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.statetransfer.StateTransferInterceptor.handleTxCommand(StateTransferInterceptor.java:184) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.statetransfer.StateTransferInterceptor.visitPrepareCommand(StateTransferInterceptor.java:89) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:106) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:70) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:70) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:321) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.transaction.TransactionCoordinator.commit(TransactionCoordinator.java:154) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:58) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.transaction.tm.DummyTransaction.notifyAfterCompletion(DummyTransaction.java:263) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.transaction.tm.DummyTransaction.runCommitTx(DummyTransaction.java:312) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:69) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:80) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:83) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:64) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.CacheImpl.endBatch(CacheImpl.java:768) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:53) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.end(InfinispanSessionManager.java:151)
	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.close(InfinispanSessionManager.java:141)
	at org.wildfly.clustering.web.undertow.session.SessionAdapter.requestDone(SessionAdapter.java:69)
	at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:708) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:501) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:258) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:138) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:622) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
Caused by: org.h2.jdbc.JdbcSQLException: Unique index or primary key violation: &quot;PRIMARY_KEY_A ON PUBLIC.&quot;&quot;binarybased_default_host_session_db_cluster&quot;&quot;(ID) VALUES ( /* key:2 */ &apos;865627136&apos;, X&apos; &apos;, -1)&quot;; SQL statement:
INSERT INTO &quot;binarybased_default_host_session_db_cluster&quot; (datum, version, id) VALUES(?,?,?) [23505-173]
	at org.h2.message.DbException.getJdbcSQLException(DbException.java:331)
	at org.h2.message.DbException.get(DbException.java:171)
	at org.h2.message.DbException.get(DbException.java:148)
	at org.h2.index.BaseIndex.getDuplicateKeyException(BaseIndex.java:101)
	at org.h2.index.TreeIndex.add(TreeIndex.java:68)
	at org.h2.table.RegularTable.addRow(RegularTable.java:125)
	at org.h2.command.dml.Insert.insertRows(Insert.java:127)
	at org.h2.command.dml.Insert.update(Insert.java:86)
	at org.h2.command.CommandContainer.update(CommandContainer.java:79)
	at org.h2.command.Command.executeUpdate(Command.java:235)
	at org.h2.jdbc.JdbcPreparedStatement.executeUpdateInternal(JdbcPreparedStatement.java:154)
	at org.h2.jdbc.JdbcPreparedStatement.executeUpdate(JdbcPreparedStatement.java:140)
	at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:493)
	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.insertBucket(JdbcBinaryStore.java:405)
	... 77 more

&amp;#27;[0m&amp;#27;[31m08:43:00,028 ERROR [org.infinispan.transaction.tm.DummyTransaction] (default task-7) ISPN000111: afterCompletion() failed for SynchronizationAdapter{localTransaction=LocalTransaction{remoteLockedNodes=null, isMarkedForRollback=false, lockedKeys=null, backupKeyLocks=null, topologyId=2, isFromStateTransfer=false} org.infinispan.transaction.synchronization.SyncLocalTransaction at 13} org.infinispan.transaction.synchronization.SynchronizationAdapter at 32: org.infinispan.commons.CacheException: Could not commit.
	at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:60) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.transaction.tm.DummyTransaction.notifyAfterCompletion(DummyTransaction.java:263) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.transaction.tm.DummyTransaction.runCommitTx(DummyTransaction.java:312) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:69) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:80) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:83) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:64) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.CacheImpl.endBatch(CacheImpl.java:768) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:53) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.end(InfinispanSessionManager.java:151)
	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.close(InfinispanSessionManager.java:141)
	at org.wildfly.clustering.web.undertow.session.SessionAdapter.requestDone(SessionAdapter.java:69)
	at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:708) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:501) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:258) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:138) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:622) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
Caused by: javax.transaction.xa.XAException
	at org.infinispan.transaction.TransactionCoordinator.handleCommitFailure(TransactionCoordinator.java:204) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.transaction.TransactionCoordinator.commit(TransactionCoordinator.java:156) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:58) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	... 23 more

&amp;#27;[0m08:43:00,032 INFO  [org.jboss.as.test.clustering.cluster.ClusterAbstractTestCase] (main) Requested http://127.0.0.1:8080/session-db-cluster/simple, got 1.
&amp;#27;[31m08:43:00,038 ERROR [org.infinispan.persistence.jdbc.binary.JdbcBinaryStore] (default task-8) ISPN008012: Sql failure while inserting bucket: Bucket{entries={7KMFRGBkll3_n5BYO0U3U-0c=MarshalledEntryImpl{keyBytes=29 bytes, valueBytes=27 bytes, metadataBytes=25 bytes, key=7KMFRGBkll3_n5BYO0U3U-0c, value=org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionCacheEntry at 415e75b5, metadata=InternalMetadataImpl{actual=EmbeddedMetadata{version=null}, created=-1, lastUsed=-1}, marshaller=org.infinispan.marshall.core.CacheMarshaller at 5b081828}}, bucketId=&apos;865627136&apos;}: org.h2.jdbc.JdbcSQLException: Unique index or primary key violation: &quot;PRIMARY_KEY_A ON PUBLIC.&quot;&quot;binarybased_default_host_session_db_cluster&quot;&quot;(ID) VALUES ( /* key:2 */ &apos;865627136&apos;, X&apos;0301fe030200013e18374b4d465247426b6c6c335f6e3542594f305533552d30630369036a1d0301fe3e18374b4d465247426b6c6c335f6e3542594f305533552d3063036a1b0301fe03ff80020000014209636c440000014209636c4500000708036a190301fe0368ffffffffffffffffffffffffffffffff03620001&apos;, -1)&quot;; SQL statement:
INSERT INTO &quot;binarybased_default_host_session_db_cluster&quot; (datum, version, id) VALUES(?,?,?) [23505-173]
	at org.h2.message.DbException.getJdbcSQLException(DbException.java:331)
	at org.h2.message.DbException.get(DbException.java:171)
	at org.h2.message.DbException.get(DbException.java:148)
	at org.h2.index.BaseIndex.getDuplicateKeyException(BaseIndex.java:101)
	at org.h2.index.TreeIndex.add(TreeIndex.java:68)
	at org.h2.table.RegularTable.addRow(RegularTable.java:125)
	at org.h2.command.dml.Insert.insertRows(Insert.java:127)
	at org.h2.command.dml.Insert.update(Insert.java:86)
	at org.h2.command.CommandContainer.update(CommandContainer.java:79)
	at org.h2.command.Command.executeUpdate(Command.java:235)
	at org.h2.jdbc.JdbcPreparedStatement.executeUpdateInternal(JdbcPreparedStatement.java:154)
	at org.h2.jdbc.JdbcPreparedStatement.executeUpdate(JdbcPreparedStatement.java:140)
	at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:493)
	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.insertBucket(JdbcBinaryStore.java:405)
	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.storeInBucket(JdbcBinaryStore.java:519)
	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.write(JdbcBinaryStore.java:122)
	at org.infinispan.persistence.manager.PersistenceManagerImpl.writeToAllStores(PersistenceManagerImpl.java:432) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.CacheWriterInterceptor$Updater.visitSingleStore(CacheWriterInterceptor.java:306) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.CacheWriterInterceptor$Updater.visitPutKeyValueCommand(CacheWriterInterceptor.java:250) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.CacheWriterInterceptor.store(CacheWriterInterceptor.java:212) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.CacheWriterInterceptor.commitCommand(CacheWriterInterceptor.java:115) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.CacheWriterInterceptor.visitPrepareCommand(CacheWriterInterceptor.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.EntryWrappingInterceptor.visitPrepareCommand(EntryWrappingInterceptor.java:93) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.invokeNextAndCommitIf1Pc(AbstractTxLockingInterceptor.java:93) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitPrepareCommand(PessimisticLockingInterceptor.java:83) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.NotificationInterceptor.visitPrepareCommand(NotificationInterceptor.java:36) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.TxInterceptor.invokeNextInterceptorAndVerifyTransaction(TxInterceptor.java:114) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.TxInterceptor.visitPrepareCommand(TxInterceptor.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitPrepareCommand(TransactionSynchronizerInterceptor.java:42) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:253) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.statetransfer.StateTransferInterceptor.handleTxCommand(StateTransferInterceptor.java:184) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.statetransfer.StateTransferInterceptor.visitPrepareCommand(StateTransferInterceptor.java:89) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:106) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:70) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:70) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:321) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.transaction.TransactionCoordinator.commit(TransactionCoordinator.java:154) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:58) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.transaction.tm.DummyTransaction.notifyAfterCompletion(DummyTransaction.java:263) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.transaction.tm.DummyTransaction.runCommitTx(DummyTransaction.java:312) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:69) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:80) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:83) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:64) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.CacheImpl.endBatch(CacheImpl.java:768) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:53) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.end(InfinispanSessionManager.java:151)
	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.close(InfinispanSessionManager.java:141)
	at org.wildfly.clustering.web.undertow.session.SessionAdapter.requestDone(SessionAdapter.java:69)
	at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:708) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:501) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:258) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:138) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:622) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]

&amp;#27;[0m&amp;#27;[31m08:43:00,043 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-8) ISPN000136: Execution error: org.infinispan.persistence.CacheLoaderException: Sql failure while inserting bucket: Bucket{entries={7KMFRGBkll3_n5BYO0U3U-0c=MarshalledEntryImpl{keyBytes=29 bytes, valueBytes=27 bytes, metadataBytes=25 bytes, key=7KMFRGBkll3_n5BYO0U3U-0c, value=org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionCacheEntry at 415e75b5, metadata=InternalMetadataImpl{actual=EmbeddedMetadata{version=null}, created=-1, lastUsed=-1}, marshaller=org.infinispan.marshall.core.CacheMarshaller at 5b081828}}, bucketId=&apos;865627136&apos;}
	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.insertBucket(JdbcBinaryStore.java:411)
	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.storeInBucket(JdbcBinaryStore.java:519)
	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.write(JdbcBinaryStore.java:122)
	at org.infinispan.persistence.manager.PersistenceManagerImpl.writeToAllStores(PersistenceManagerImpl.java:432) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.CacheWriterInterceptor$Updater.visitSingleStore(CacheWriterInterceptor.java:306) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.CacheWriterInterceptor$Updater.visitPutKeyValueCommand(CacheWriterInterceptor.java:250) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.CacheWriterInterceptor.store(CacheWriterInterceptor.java:212) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.CacheWriterInterceptor.commitCommand(CacheWriterInterceptor.java:115) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.CacheWriterInterceptor.visitPrepareCommand(CacheWriterInterceptor.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.EntryWrappingInterceptor.visitPrepareCommand(EntryWrappingInterceptor.java:93) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.invokeNextAndCommitIf1Pc(AbstractTxLockingInterceptor.java:93) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitPrepareCommand(PessimisticLockingInterceptor.java:83) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.NotificationInterceptor.visitPrepareCommand(NotificationInterceptor.java:36) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.TxInterceptor.invokeNextInterceptorAndVerifyTransaction(TxInterceptor.java:114) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.TxInterceptor.visitPrepareCommand(TxInterceptor.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitPrepareCommand(TransactionSynchronizerInterceptor.java:42) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:253) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.statetransfer.StateTransferInterceptor.handleTxCommand(StateTransferInterceptor.java:184) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.statetransfer.StateTransferInterceptor.visitPrepareCommand(StateTransferInterceptor.java:89) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:106) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:70) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:70) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:321) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.transaction.TransactionCoordinator.commit(TransactionCoordinator.java:154) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:58) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.transaction.tm.DummyTransaction.notifyAfterCompletion(DummyTransaction.java:263) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.transaction.tm.DummyTransaction.runCommitTx(DummyTransaction.java:312) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:69) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:80) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:83) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:64) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.CacheImpl.endBatch(CacheImpl.java:768) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:53) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.end(InfinispanSessionManager.java:151)
	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.close(InfinispanSessionManager.java:141)
	at org.wildfly.clustering.web.undertow.session.SessionAdapter.requestDone(SessionAdapter.java:69)
	at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:708) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:501) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:258) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:138) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:622) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
Caused by: org.h2.jdbc.JdbcSQLException: Unique index or primary key violation: &quot;PRIMARY_KEY_A ON PUBLIC.&quot;&quot;binarybased_default_host_session_db_cluster&quot;&quot;(ID) VALUES ( /* key:2 */ &apos;865627136&apos;, X&apos;0301fe030200013e18374b4d465247426b6c6c335f6e3542594f305533552d30630369036a1d0301fe3e18374b4d465247426b6c6c335f6e3542594f305533552d3063036a1b0301fe03ff80020000014209636c440000014209636c4500000708036a190301fe0368ffffffffffffffffffffffffffffffff03620001&apos;, -1)&quot;; SQL statement:
INSERT INTO &quot;binarybased_default_host_session_db_cluster&quot; (datum, version, id) VALUES(?,?,?) [23505-173]
	at org.h2.message.DbException.getJdbcSQLException(DbException.java:331)
	at org.h2.message.DbException.get(DbException.java:171)
	at org.h2.message.DbException.get(DbException.java:148)
	at org.h2.index.BaseIndex.getDuplicateKeyException(BaseIndex.java:101)
	at org.h2.index.TreeIndex.add(TreeIndex.java:68)
	at org.h2.table.RegularTable.addRow(RegularTable.java:125)
	at org.h2.command.dml.Insert.insertRows(Insert.java:127)
	at org.h2.command.dml.Insert.update(Insert.java:86)
	at org.h2.command.CommandContainer.update(CommandContainer.java:79)
	at org.h2.command.Command.executeUpdate(Command.java:235)
	at org.h2.jdbc.JdbcPreparedStatement.executeUpdateInternal(JdbcPreparedStatement.java:154)
	at org.h2.jdbc.JdbcPreparedStatement.executeUpdate(JdbcPreparedStatement.java:140)
	at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:493)
	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.insertBucket(JdbcBinaryStore.java:405)
	... 77 more

&amp;#27;[0m&amp;#27;[31m08:43:00,067 ERROR [org.infinispan.transaction.TransactionCoordinator] (default task-8) ISPN000097: Error while processing a prepare in a single-phase transaction: org.infinispan.persistence.CacheLoaderException: Sql failure while inserting bucket: Bucket{entries={7KMFRGBkll3_n5BYO0U3U-0c=MarshalledEntryImpl{keyBytes=29 bytes, valueBytes=27 bytes, metadataBytes=25 bytes, key=7KMFRGBkll3_n5BYO0U3U-0c, value=org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionCacheEntry at 415e75b5, metadata=InternalMetadataImpl{actual=EmbeddedMetadata{version=null}, created=-1, lastUsed=-1}, marshaller=org.infinispan.marshall.core.CacheMarshaller at 5b081828}}, bucketId=&apos;865627136&apos;}
	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.insertBucket(JdbcBinaryStore.java:411)
	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.storeInBucket(JdbcBinaryStore.java:519)
	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.write(JdbcBinaryStore.java:122)
	at org.infinispan.persistence.manager.PersistenceManagerImpl.writeToAllStores(PersistenceManagerImpl.java:432) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.CacheWriterInterceptor$Updater.visitSingleStore(CacheWriterInterceptor.java:306) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.CacheWriterInterceptor$Updater.visitPutKeyValueCommand(CacheWriterInterceptor.java:250) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.CacheWriterInterceptor.store(CacheWriterInterceptor.java:212) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.CacheWriterInterceptor.commitCommand(CacheWriterInterceptor.java:115) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.CacheWriterInterceptor.visitPrepareCommand(CacheWriterInterceptor.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.EntryWrappingInterceptor.visitPrepareCommand(EntryWrappingInterceptor.java:93) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.invokeNextAndCommitIf1Pc(AbstractTxLockingInterceptor.java:93) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitPrepareCommand(PessimisticLockingInterceptor.java:83) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.NotificationInterceptor.visitPrepareCommand(NotificationInterceptor.java:36) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.TxInterceptor.invokeNextInterceptorAndVerifyTransaction(TxInterceptor.java:114) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.TxInterceptor.visitPrepareCommand(TxInterceptor.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitPrepareCommand(TransactionSynchronizerInterceptor.java:42) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:253) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.statetransfer.StateTransferInterceptor.handleTxCommand(StateTransferInterceptor.java:184) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.statetransfer.StateTransferInterceptor.visitPrepareCommand(StateTransferInterceptor.java:89) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:106) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:70) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:70) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:321) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.transaction.TransactionCoordinator.commit(TransactionCoordinator.java:154) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.transaction.tm.DummyTransaction.notifyAfterCompletion(DummyTransaction.java:263) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.transaction.tm.DummyTransaction.runCommitTx(DummyTransaction.java:312) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:69) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:80) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:83) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:64) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.CacheImpl.endBatch(CacheImpl.java:768) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:53) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.end(InfinispanSessionManager.java:151)
	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.close(InfinispanSessionManager.java:141)
	at org.wildfly.clustering.web.undertow.session.SessionAdapter.requestDone(SessionAdapter.java:69)
	at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:708) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:501) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:258) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:138) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:622) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
Caused by: org.h2.jdbc.JdbcSQLException: Unique index or primary key violation: &quot;PRIMARY_KEY_A ON PUBLIC.&quot;&quot;binarybased_default_host_session_db_cluster&quot;&quot;(ID) VALUES ( /* key:2 */ &apos;865627136&apos;, X&apos;0301fe030200013e18374b4d465247426b6c6c335f6e3542594f305533552d30630369036a1d0301fe3e18374b4d465247426b6c6c335f6e3542594f305533552d3063036a1b0301fe03ff80020000014209636c440000014209636c4500000708036a190301fe0368ffffffffffffffffffffffffffffffff03620001&apos;, -1)&quot;; SQL statement:
INSERT INTO &quot;binarybased_default_host_session_db_cluster&quot; (datum, version, id) VALUES(?,?,?) [23505-173]
	at org.h2.message.DbException.getJdbcSQLException(DbException.java:331)
	at org.h2.message.DbException.get(DbException.java:171)
	at org.h2.message.DbException.get(DbException.java:148)
	at org.h2.index.BaseIndex.getDuplicateKeyException(BaseIndex.java:101)
	at org.h2.index.TreeIndex.add(TreeIndex.java:68)
	at org.h2.table.RegularTable.addRow(RegularTable.java:125)
	at org.h2.command.dml.Insert.insertRows(Insert.java:127)
	at org.h2.command.dml.Insert.update(Insert.java:86)
	at org.h2.command.CommandContainer.update(CommandContainer.java:79)
	at org.h2.command.Command.executeUpdate(Command.java:235)
	at org.h2.jdbc.JdbcPreparedStatement.executeUpdateInternal(JdbcPreparedStatement.java:154)
	at org.h2.jdbc.JdbcPreparedStatement.executeUpdate(JdbcPreparedStatement.java:140)
	at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:493)
	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.insertBucket(JdbcBinaryStore.java:405)
	... 77 more

&amp;#27;[0m&amp;#27;[31m08:43:00,072 ERROR [org.infinispan.transaction.tm.DummyTransaction] (default task-8) ISPN000111: afterCompletion() failed for SynchronizationAdapter{localTransaction=LocalTransaction{remoteLockedNodes=null, isMarkedForRollback=false, lockedKeys=null, backupKeyLocks=null, topologyId=2, isFromStateTransfer=false} org.infinispan.transaction.synchronization.SyncLocalTransaction at 16} org.infinispan.transaction.synchronization.SynchronizationAdapter at 35: org.infinispan.commons.CacheException: Could not commit.
	at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:60) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.transaction.tm.DummyTransaction.notifyAfterCompletion(DummyTransaction.java:263) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.transaction.tm.DummyTransaction.runCommitTx(DummyTransaction.java:312) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:69) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:80) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:83) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:64) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.CacheImpl.endBatch(CacheImpl.java:768) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:53) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.end(InfinispanSessionManager.java:151)
	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.close(InfinispanSessionManager.java:141)
	at org.wildfly.clustering.web.undertow.session.SessionAdapter.requestDone(SessionAdapter.java:69)
	at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:708) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:501) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:258) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:138) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:622) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
Caused by: javax.transaction.xa.XAException
	at org.infinispan.transaction.TransactionCoordinator.handleCommitFailure(TransactionCoordinator.java:204) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.transaction.TransactionCoordinator.commit(TransactionCoordinator.java:156) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:58) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
	... 23 more


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Wed Oct 30 09:50:01 2013
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Wed, 30 Oct 2013 09:50:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2410) composite operation
 containing a host op does not get rolled out to all hosts
In-Reply-To: <JIRA.12509099.1383140990501@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509099.1383140990501@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509099.1383140990501.23986.1383141001925@jira02.app.mwc.hst.phx2.redhat.com>

Emanuel Muckenhuber created WFLY-2410:
-----------------------------------------

             Summary: composite operation containing a host op does not get rolled out to all hosts
                 Key: WFLY-2410
                 URL: https://issues.jboss.org/browse/WFLY-2410
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Domain Management
    Affects Versions: 8.0.0.Beta1
            Reporter: Emanuel Muckenhuber
            Assignee: Emanuel Muckenhuber
             Fix For: 8.0.0.CR1


If a composite operation contains an operation targeting the domain as well as a single host, it will only get rolled out to the host specified rather than to the complete domain.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 09:54:01 2013
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Wed, 30 Oct 2013 09:54:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2411) SecurityRealm authentication
 does not get marshalled when empty
In-Reply-To: <JIRA.12509100.1383141156454@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509100.1383141156454@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509100.1383141156454.23992.1383141241929@jira02.app.mwc.hst.phx2.redhat.com>

Emanuel Muckenhuber created WFLY-2411:
-----------------------------------------

             Summary: SecurityRealm authentication does not get marshalled when empty
                 Key: WFLY-2411
                 URL: https://issues.jboss.org/browse/WFLY-2411
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Domain Management
    Affects Versions: 8.0.0.Beta1
            Reporter: Emanuel Muckenhuber
            Assignee: Emanuel Muckenhuber
             Fix For: 8.0.0.CR1


The /core-service=management/security-realm=ManagementRealm/authentication=users resource does not get persisted in case it does not contain any users. This causes problems since the resource is not restored after a reload or restart of the server.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 10:06:02 2013
From: jira-events at lists.jboss.org (Jozef Hartinger (JIRA))
Date: Wed, 30 Oct 2013 10:06:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2387) CDI injection in entity
	listeners failing
In-Reply-To: <JIRA.12508815.1382711350000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508815.1382711350000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508815.1382711350000.24009.1383141962303@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825791#comment-12825791 ] 

Jozef Hartinger commented on WFLY-2387:
---------------------------------------

FYI [~bafco] is currently writing tests for various EE components as part of WFLY-2362. He is also covering entity listeners. So in case you decide to write extensive tests for entity listeners you can skip that in favor of [~bafco]'s work.
                
> CDI injection in entity listeners failing
> -----------------------------------------
>
>                 Key: WFLY-2387
>                 URL: https://issues.jboss.org/browse/WFLY-2387
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld, Class Loading, JPA / Hibernate
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Emond Papegaaij
>            Assignee: Stuart Douglas
>
> When trying to use CDI injection in JPA entity listeners, deployment fails with the following exception:
> {code}
> 16:16:37,448 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 15) MSC000001: Failed to start service jboss.persistenceunit."inject-ear.ear#primary": org.jboss.msc.service.StartException in service jboss.persistenceunit."inject-ear.ear#primary": java.lang.IllegalStateException: JBAS016071: Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader at 4eeb95dc. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment.
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:169)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117)
> 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:463) [wildfly-security-manager-1.0.0.Beta3.jar:1.0.0.Beta3]
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:178)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: java.lang.IllegalStateException: JBAS016071: Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader at 4eeb95dc. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment.
> 	at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:75)
> 	at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:128)
> 	at org.jboss.weld.Container.instance(Container.java:65)
> 	at org.jboss.weld.manager.BeanManagerImpl.getBeans(BeanManagerImpl.java:563)
> 	at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:90)
> 	at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:358)
> 	at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:369)
> 	at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:72)
> 	at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:60)
> 	at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:66)
> 	at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
> 	at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64)
> 	at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:90)
> 	at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$BeanMetaData.<init>(BeanManagerListenerFactory.java:82)
> 	at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$BeanMetaData.<init>(BeanManagerListenerFactory.java:71)
> 	at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory.buildListener(BeanManagerListenerFactory.java:57)
> 	at org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.resolveCallbacks(LegacyCallbackProcessor.java:168)
> 	at org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.processCallbacksForEntity(LegacyCallbackProcessor.java:71)
> 	at org.hibernate.jpa.event.spi.JpaIntegrator.integrate(JpaIntegrator.java:150)
> 	at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:310)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1837)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:854)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:847)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:396)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:846)
> 	at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:151)
> 	... 8 more
> {code}
> I've created a small showcase of the problem: https://github.com/papegaaij/listener-injection

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 10:15:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 30 Oct 2013 10:15:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1982) NPE in ModelControllerLock
In-Reply-To: <JIRA.12499783.1378179088000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499783.1378179088000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499783.1378179088000.24018.1383142503498@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-1982:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1024862

    
> NPE in ModelControllerLock
> --------------------------
>
>                 Key: WFLY-1982
>                 URL: https://issues.jboss.org/browse/WFLY-1982
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.CR1
>
>
> Just noticed this in the host-controller.log while looking into a non-progressing RespawnTestCase:
> 22:23:50,552 ERROR [org.jboss.as.controller.management-operation] (proxy-threads - 1) JBAS014612: Operation ("register-server") failed - address: ([]): java.lang.NullPointerException
> 	at org.jboss.as.controller.ModelControllerLock$Sync.tryAcquire(ModelControllerLock.java:75) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireInterruptibly(AbstractQueuedSynchronizer.java:1220) [rt.jar:1.7.0_15]
> 	at org.jboss.as.controller.ModelControllerLock.lockInterruptibly(ModelControllerLock.java:48) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.acquireLock(ModelControllerImpl.java:582) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.OperationContextImpl.takeWriteLock(OperationContextImpl.java:403) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.OperationContextImpl.acquireControllerLock(OperationContextImpl.java:700) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.host.controller.mgmt.ServerToHostProtocolHandler$ServerReconnectRequestHandler$1$1.execute(ServerToHostProtocolHandler.java:268)
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:610) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:488) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:257) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractControllerService.internalExecute(AbstractControllerService.java:292) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.host.controller.DomainModelControllerService.access$600(DomainModelControllerService.java:148)
> 	at org.jboss.as.host.controller.DomainModelControllerService$InternalExecutor.execute(DomainModelControllerService.java:899)
> 	at org.jboss.as.host.controller.mgmt.ServerToHostProtocolHandler$ServerReconnectRequestHandler$1.execute(ServerToHostProtocolHandler.java:282)
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [wildfly-protocol-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [wildfly-protocol-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_15]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_15]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_15]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 10:15:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 30 Oct 2013 10:15:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1982) NPE in ModelControllerLock
In-Reply-To: <JIRA.12499783.1378179088000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499783.1378179088000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499783.1378179088000.24021.1383142503656@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825793#comment-12825793 ] 

RH Bugzilla Integration commented on WFLY-1982:
-----------------------------------------------

Emanuel Muckenhuber <emuckenh at redhat.com> made a comment on [bug 1024862|https://bugzilla.redhat.com/show_bug.cgi?id=1024862]

There is a race condition in the ModelControllerLock causing a NullPointerException when trying to acquire the controller lock.
                
> NPE in ModelControllerLock
> --------------------------
>
>                 Key: WFLY-1982
>                 URL: https://issues.jboss.org/browse/WFLY-1982
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.CR1
>
>
> Just noticed this in the host-controller.log while looking into a non-progressing RespawnTestCase:
> 22:23:50,552 ERROR [org.jboss.as.controller.management-operation] (proxy-threads - 1) JBAS014612: Operation ("register-server") failed - address: ([]): java.lang.NullPointerException
> 	at org.jboss.as.controller.ModelControllerLock$Sync.tryAcquire(ModelControllerLock.java:75) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireInterruptibly(AbstractQueuedSynchronizer.java:1220) [rt.jar:1.7.0_15]
> 	at org.jboss.as.controller.ModelControllerLock.lockInterruptibly(ModelControllerLock.java:48) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.acquireLock(ModelControllerImpl.java:582) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.OperationContextImpl.takeWriteLock(OperationContextImpl.java:403) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.OperationContextImpl.acquireControllerLock(OperationContextImpl.java:700) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.host.controller.mgmt.ServerToHostProtocolHandler$ServerReconnectRequestHandler$1$1.execute(ServerToHostProtocolHandler.java:268)
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:610) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:488) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:257) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractControllerService.internalExecute(AbstractControllerService.java:292) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.host.controller.DomainModelControllerService.access$600(DomainModelControllerService.java:148)
> 	at org.jboss.as.host.controller.DomainModelControllerService$InternalExecutor.execute(DomainModelControllerService.java:899)
> 	at org.jboss.as.host.controller.mgmt.ServerToHostProtocolHandler$ServerReconnectRequestHandler$1.execute(ServerToHostProtocolHandler.java:282)
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [wildfly-protocol-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [wildfly-protocol-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_15]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_15]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_15]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 10:22:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 30 Oct 2013 10:22:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2411) SecurityRealm authentication
 does not get marshalled when empty
In-Reply-To: <JIRA.12509100.1383141156000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509100.1383141156000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509100.1383141156000.24046.1383142922281@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2411:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1023585

    
> SecurityRealm authentication does not get marshalled when empty
> ---------------------------------------------------------------
>
>                 Key: WFLY-2411
>                 URL: https://issues.jboss.org/browse/WFLY-2411
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Emanuel Muckenhuber
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.CR1
>
>
> The /core-service=management/security-realm=ManagementRealm/authentication=users resource does not get persisted in case it does not contain any users. This causes problems since the resource is not restored after a reload or restart of the server.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 10:22:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 30 Oct 2013 10:22:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2410) composite operation
 containing a host op does not get rolled out to all hosts
In-Reply-To: <JIRA.12509099.1383140990000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509099.1383140990000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509099.1383140990000.24050.1383142922461@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825799#comment-12825799 ] 

RH Bugzilla Integration commented on WFLY-2410:
-----------------------------------------------

Emanuel Muckenhuber <emuckenh at redhat.com> changed the Status of [bug 1015098|https://bugzilla.redhat.com/show_bug.cgi?id=1015098] from NEW to ASSIGNED
                
> composite operation containing a host op does not get rolled out to all hosts
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-2410
>                 URL: https://issues.jboss.org/browse/WFLY-2410
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Emanuel Muckenhuber
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.CR1
>
>
> If a composite operation contains an operation targeting the domain as well as a single host, it will only get rolled out to the host specified rather than to the complete domain.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 10:22:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 30 Oct 2013 10:22:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2410) composite operation
 containing a host op does not get rolled out to all hosts
In-Reply-To: <JIRA.12509099.1383140990000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509099.1383140990000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509099.1383140990000.24052.1383142922575@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2410:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1015098

    
> composite operation containing a host op does not get rolled out to all hosts
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-2410
>                 URL: https://issues.jboss.org/browse/WFLY-2410
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Emanuel Muckenhuber
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.CR1
>
>
> If a composite operation contains an operation targeting the domain as well as a single host, it will only get rolled out to the host specified rather than to the complete domain.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 10:43:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 30 Oct 2013 10:43:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1675) Threads stuck in
 FlowControl.decrementIfEnoughCredits
In-Reply-To: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498385.1376295331000.24101.1383144182254@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1675:
---------------------------

    Attachment: RemoteGetStressTest.java

    
> Threads stuck in FlowControl.decrementIfEnoughCredits
> -----------------------------------------------------
>
>                 Key: JGRP-1675
>                 URL: https://issues.jboss.org/browse/JGRP-1675
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>         Attachments: RemoteGetStressTest.java
>
>
> I have recently observed a repeated situation where many (or all) threads have been stuck waiting for credits in FlowControl protocol.
> The credit request was not handled on the other node as this is non-oob message and some (actually many of them - cause unknown) messages before the request have been lost - therefore the request was waiting for them to be re-sent.
> However, these have not been re-sent properly as the retransmission request was not received - all OOB threads were stuck in the FlowControl protocol as these handled some other request and tried to send a response - but the response could not be sent until FlowControl gets the credits.
> The probability of such situation could be lowered by tagging the credit request to be OOB - then it would be handled immediately. If the credit replenish message would then be processed in regular OOB pool, this could get already depleted by many requests, but setting up the internal thread pool would solve the problem.
> Other consideration would be to allow releasing thread from FlowControl (let it send the message even without credits) if it waits there for too long.
> h3. Workaround
> It appears that setting MFC and UFC max_credits to 10M or removing these protocols at all is a workaround for this issue.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 10:47:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 30 Oct 2013 10:47:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1675) Threads stuck in
 FlowControl.decrementIfEnoughCredits
In-Reply-To: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498385.1376295331000.24118.1383144422406@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825808#comment-12825808 ] 

Bela Ban commented on JGRP-1675:
--------------------------------

Tried to replicate the stress test in JGroups (RemoteGetStressTest ia attached). With 500 threads, the tests completes within 60 and 90 seconds. This is with a random delay de-serializing the BigObject between 1 and 10 ms, and with a DISCARD up-rate of 20%.

If {{USE_SLEEPS}} is changed to false, the test finishes within a few second (between 2 and 5 secs).
                
> Threads stuck in FlowControl.decrementIfEnoughCredits
> -----------------------------------------------------
>
>                 Key: JGRP-1675
>                 URL: https://issues.jboss.org/browse/JGRP-1675
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>         Attachments: RemoteGetStressTest.java
>
>
> I have recently observed a repeated situation where many (or all) threads have been stuck waiting for credits in FlowControl protocol.
> The credit request was not handled on the other node as this is non-oob message and some (actually many of them - cause unknown) messages before the request have been lost - therefore the request was waiting for them to be re-sent.
> However, these have not been re-sent properly as the retransmission request was not received - all OOB threads were stuck in the FlowControl protocol as these handled some other request and tried to send a response - but the response could not be sent until FlowControl gets the credits.
> The probability of such situation could be lowered by tagging the credit request to be OOB - then it would be handled immediately. If the credit replenish message would then be processed in regular OOB pool, this could get already depleted by many requests, but setting up the internal thread pool would solve the problem.
> Other consideration would be to allow releasing thread from FlowControl (let it send the message even without credits) if it waits there for too long.
> h3. Workaround
> It appears that setting MFC and UFC max_credits to 10M or removing these protocols at all is a workaround for this issue.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 10:49:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 30 Oct 2013 10:49:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1675) Threads stuck in
 FlowControl.decrementIfEnoughCredits
In-Reply-To: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498385.1376295331000.24123.1383144542065@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825808#comment-12825808 ] 

Bela Ban edited comment on JGRP-1675 at 10/30/13 10:47 AM:
-----------------------------------------------------------

Tried to replicate the stress test in JGroups (RemoteGetStressTest ia attached). With 500 threads, the tests completes within 60 and 90 seconds. This is with a random delay de-serializing the BigObject between 1 and 10 ms, and with a DISCARD up-rate of 20%.

If {{USE_SLEEPS}} is changed to false, the test finishes within a few second (between 2 and 5 secs).  This is with an OOB pool of min=1/max=5/no-queue.

The delaying and discarding certainly slows things downm, but I never experience a deadlock.
                
      was (Author: belaban):
    Tried to replicate the stress test in JGroups (RemoteGetStressTest ia attached). With 500 threads, the tests completes within 60 and 90 seconds. This is with a random delay de-serializing the BigObject between 1 and 10 ms, and with a DISCARD up-rate of 20%.

If {{USE_SLEEPS}} is changed to false, the test finishes within a few second (between 2 and 5 secs).
                  
> Threads stuck in FlowControl.decrementIfEnoughCredits
> -----------------------------------------------------
>
>                 Key: JGRP-1675
>                 URL: https://issues.jboss.org/browse/JGRP-1675
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>         Attachments: RemoteGetStressTest.java
>
>
> I have recently observed a repeated situation where many (or all) threads have been stuck waiting for credits in FlowControl protocol.
> The credit request was not handled on the other node as this is non-oob message and some (actually many of them - cause unknown) messages before the request have been lost - therefore the request was waiting for them to be re-sent.
> However, these have not been re-sent properly as the retransmission request was not received - all OOB threads were stuck in the FlowControl protocol as these handled some other request and tried to send a response - but the response could not be sent until FlowControl gets the credits.
> The probability of such situation could be lowered by tagging the credit request to be OOB - then it would be handled immediately. If the credit replenish message would then be processed in regular OOB pool, this could get already depleted by many requests, but setting up the internal thread pool would solve the problem.
> Other consideration would be to allow releasing thread from FlowControl (let it send the message even without credits) if it waits there for too long.
> h3. Workaround
> It appears that setting MFC and UFC max_credits to 10M or removing these protocols at all is a workaround for this issue.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 10:49:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 30 Oct 2013 10:49:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1675) Threads stuck in
 FlowControl.decrementIfEnoughCredits
In-Reply-To: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498385.1376295331000.24131.1383144542445@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825809#comment-12825809 ] 

Bela Ban commented on JGRP-1675:
--------------------------------

The test is on branch JGRP-1675: https://github.com/belaban/JGroups/blob/JGRP-1675/tests/stress/org/jgroups/tests/RemoteGetStressTest.java
                
> Threads stuck in FlowControl.decrementIfEnoughCredits
> -----------------------------------------------------
>
>                 Key: JGRP-1675
>                 URL: https://issues.jboss.org/browse/JGRP-1675
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>         Attachments: RemoteGetStressTest.java
>
>
> I have recently observed a repeated situation where many (or all) threads have been stuck waiting for credits in FlowControl protocol.
> The credit request was not handled on the other node as this is non-oob message and some (actually many of them - cause unknown) messages before the request have been lost - therefore the request was waiting for them to be re-sent.
> However, these have not been re-sent properly as the retransmission request was not received - all OOB threads were stuck in the FlowControl protocol as these handled some other request and tried to send a response - but the response could not be sent until FlowControl gets the credits.
> The probability of such situation could be lowered by tagging the credit request to be OOB - then it would be handled immediately. If the credit replenish message would then be processed in regular OOB pool, this could get already depleted by many requests, but setting up the internal thread pool would solve the problem.
> Other consideration would be to allow releasing thread from FlowControl (let it send the message even without credits) if it waits there for too long.
> h3. Workaround
> It appears that setting MFC and UFC max_credits to 10M or removing these protocols at all is a workaround for this issue.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 11:05:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 30 Oct 2013 11:05:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2412) security realms and ldap
 connections incorrectly hidden by default in domain mode.
In-Reply-To: <JIRA.12509108.1383145401858@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509108.1383145401858@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509108.1383145401858.24165.1383145502021@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-2412:
--------------------------------------

             Summary: security realms and ldap connections incorrectly hidden by default in domain mode.
                 Key: WFLY-2412
                 URL: https://issues.jboss.org/browse/WFLY-2412
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Domain Management, Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 8.0.0.CR1


Running WildFly master in domain mode and connect using the CLI.

{code}
[domain at localhost:9990 /] :whoami(verbose=true)
{
    "outcome" => "success",
    "result" => {
        "identity" => {
            "username" => "$local",
            "realm" => "ManagementRealm"
        },
        "mapped-roles" => ["SuperUser"]
    }
}
{code}

Although this shows the user has been authenticated against the ManagementRealm is apparently does not exist!

{code}
[domain at localhost:9990 /] ./core-service=management/security-realm=ManagementRealm:read-resource
{
    "outcome" => "failed",
    "failure-description" => "JBAS014807: Management resource '[
    (\"core-service\" => \"management\"),
    (\"security-realm\" => \"ManagementRealm\")
]' not found",
    "rolled-back" => true
}
{code}

First impression is that access control is hiding a sensitive resource even though with the default config it should not.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 11:25:02 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Wed, 30 Oct 2013 11:25:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2282) SFSB serialization fails if
 containing EntityManager or EntityManagerFactory field w/2LC enabled
In-Reply-To: <JIRA.12502735.1381434775000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502735.1381434775000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502735.1381434775000.24238.1383146702323@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825828#comment-12825828 ] 

Scott Marlow commented on WFLY-2282:
------------------------------------

I'm not having luck reproducing with org.jboss.as.test.integration.jpa.secondlevelcache.JPA2LCTestCase.  I started WF8 in clustering-standalone.xml mode and serialized the entity manager and entity manager factory. 

https://github.com/scottmarlow/wildfly/tree/cluster contains the test code changes.
                
> SFSB serialization fails if containing EntityManager or EntityManagerFactory field w/2LC enabled
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2282
>                 URL: https://issues.jboss.org/browse/WFLY-2282
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Paul Ferraro
>            Assignee: Scott Marlow
>
> 2013-10-10 15:03:46,636 WARN  [org.infinispan.factories.ComponentRegistry] (MSC service thread 1-3) ISPN000189: While stopping a cache or cache manager, one of its components failed to stop: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.eviction.PassivationManagerImpl.passivateAll() throws org.infinispan.persistence.CacheLoaderException on object of type PassivationManagerImpl
>         at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:185)
>         at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
>         at org.infinispan.factories.AbstractComponentRegistry.internalStop(AbstractComponentRegistry.java:674)
>         at org.infinispan.factories.AbstractComponentRegistry.stop(AbstractComponentRegistry.java:552)
>         at org.infinispan.factories.ComponentRegistry.stop(ComponentRegistry.java:241)
>         at org.infinispan.CacheImpl.stop(CacheImpl.java:690)
>         at org.infinispan.CacheImpl.stop(CacheImpl.java:685)
>         at org.infinispan.AbstractDelegatingCache.stop(AbstractDelegatingCache.java:316)
>         at org.jboss.as.clustering.infinispan.subsystem.CacheService.stop(CacheService.java:96)
>         at org.jboss.as.clustering.msc.AsynchronousService.stop(AsynchronousService.java:114) [wildfly-clustering-common-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
>         at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2052) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>         at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2013) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
>         at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: org.infinispan.persistence.CacheLoaderException: org.infinispan.persistence.CacheLoaderException: org.infinispan.commons.marshall.NotSerializableException: org.jboss.as.clustering.infinispan.DefaultCacheContainer
>         at org.infinispan.persistence.file.SingleFileStore.write(SingleFileStore.java:297)
>         at org.infinispan.persistence.manager.PersistenceManagerImpl.writeToAllStores(PersistenceManagerImpl.java:430)
>         at org.infinispan.eviction.PassivationManagerImpl.passivateAll(PassivationManagerImpl.java:98)
>         at sun.reflect.GeneratedMethodAccessor152.invoke(Unknown Source) [:1.7.0_25]
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_25]
>         at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_25]
>         at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:183)
>         ... 14 more
> Caused by: org.infinispan.persistence.CacheLoaderException: org.infinispan.commons.marshall.NotSerializableException: org.jboss.as.clustering.infinispan.DefaultCacheContainer
>         at org.infinispan.marshall.core.MarshalledEntryImpl.marshall(MarshalledEntryImpl.java:107)
>         at org.infinispan.marshall.core.MarshalledEntryImpl.getValueBytes(MarshalledEntryImpl.java:88)
>         at org.infinispan.persistence.file.SingleFileStore.write(SingleFileStore.java:260)
>         ... 20 more
> Caused by: org.infinispan.commons.marshall.NotSerializableException: org.jboss.as.clustering.infinispan.DefaultCacheContainer
> Caused by: an exception which occurred:
>         in field container
>         in field instance
>         in field instance
>         in object java.util.HashMap at 208cab3b
>         in object org.jboss.as.clustering.marshalling.SimpleMarshalledValue at 208cab3b

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 11:27:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 30 Oct 2013 11:27:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2412) security realms and ldap
 connections incorrectly hidden by default in domain mode.
In-Reply-To: <JIRA.12509108.1383145401000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509108.1383145401000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509108.1383145401000.24241.1383146822051@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825829#comment-12825829 ] 

RH Bugzilla Integration commented on WFLY-2412:
-----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> made a comment on [bug 1024930|https://bugzilla.redhat.com/show_bug.cgi?id=1024930]

Description of problem:

The realms are not readable, this is despite the access control provider being Simple: -

[domain at localhost:9999 /] :whoami(verbose=true)
{
    "outcome" => "success",
    "result" => {
        "identity" => {
            "username" => "$local",
            "realm" => "ManagementRealm"
        },
        "mapped-roles" => ["SuperUser"]
    }
}
[domain at localhost:9999 /] ./core-service=management/security-realm=ManagementRealm:read-resource
{
    "outcome" => "failed",
    "failure-description" => "JBAS014807: Management resource '[
    (\"core-service\" => \"management\"),
    (\"security-realm\" => \"ManagementRealm\")
]' not found",
    "rolled-back" => true
}
                
> security realms and ldap connections incorrectly hidden by default in domain mode.
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-2412
>                 URL: https://issues.jboss.org/browse/WFLY-2412
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Running WildFly master in domain mode and connect using the CLI.
> {code}
> [domain at localhost:9990 /] :whoami(verbose=true)
> {
>     "outcome" => "success",
>     "result" => {
>         "identity" => {
>             "username" => "$local",
>             "realm" => "ManagementRealm"
>         },
>         "mapped-roles" => ["SuperUser"]
>     }
> }
> {code}
> Although this shows the user has been authenticated against the ManagementRealm is apparently does not exist!
> {code}
> [domain at localhost:9990 /] ./core-service=management/security-realm=ManagementRealm:read-resource
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014807: Management resource '[
>     (\"core-service\" => \"management\"),
>     (\"security-realm\" => \"ManagementRealm\")
> ]' not found",
>     "rolled-back" => true
> }
> {code}
> First impression is that access control is hiding a sensitive resource even though with the default config it should not.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 11:27:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 30 Oct 2013 11:27:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2412) security realms and ldap
 connections incorrectly hidden by default in domain mode.
In-Reply-To: <JIRA.12509108.1383145401000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509108.1383145401000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509108.1383145401000.24244.1383146822203@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2412:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1024930

    
> security realms and ldap connections incorrectly hidden by default in domain mode.
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-2412
>                 URL: https://issues.jboss.org/browse/WFLY-2412
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Running WildFly master in domain mode and connect using the CLI.
> {code}
> [domain at localhost:9990 /] :whoami(verbose=true)
> {
>     "outcome" => "success",
>     "result" => {
>         "identity" => {
>             "username" => "$local",
>             "realm" => "ManagementRealm"
>         },
>         "mapped-roles" => ["SuperUser"]
>     }
> }
> {code}
> Although this shows the user has been authenticated against the ManagementRealm is apparently does not exist!
> {code}
> [domain at localhost:9990 /] ./core-service=management/security-realm=ManagementRealm:read-resource
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014807: Management resource '[
>     (\"core-service\" => \"management\"),
>     (\"security-realm\" => \"ManagementRealm\")
> ]' not found",
>     "rolled-back" => true
> }
> {code}
> First impression is that access control is hiding a sensitive resource even though with the default config it should not.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 11:27:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 30 Oct 2013 11:27:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2412) security realms and ldap
 connections incorrectly hidden by default in domain mode.
In-Reply-To: <JIRA.12509108.1383145401000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509108.1383145401000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509108.1383145401000.24247.1383146822351@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825830#comment-12825830 ] 

RH Bugzilla Integration commented on WFLY-2412:
-----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> changed the Status of [bug 1024930|https://bugzilla.redhat.com/show_bug.cgi?id=1024930] from NEW to ASSIGNED
                
> security realms and ldap connections incorrectly hidden by default in domain mode.
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-2412
>                 URL: https://issues.jboss.org/browse/WFLY-2412
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Running WildFly master in domain mode and connect using the CLI.
> {code}
> [domain at localhost:9990 /] :whoami(verbose=true)
> {
>     "outcome" => "success",
>     "result" => {
>         "identity" => {
>             "username" => "$local",
>             "realm" => "ManagementRealm"
>         },
>         "mapped-roles" => ["SuperUser"]
>     }
> }
> {code}
> Although this shows the user has been authenticated against the ManagementRealm is apparently does not exist!
> {code}
> [domain at localhost:9990 /] ./core-service=management/security-realm=ManagementRealm:read-resource
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014807: Management resource '[
>     (\"core-service\" => \"management\"),
>     (\"security-realm\" => \"ManagementRealm\")
> ]' not found",
>     "rolled-back" => true
> }
> {code}
> First impression is that access control is hiding a sensitive resource even though with the default config it should not.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 11:31:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 30 Oct 2013 11:31:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2412) security realms and ldap
 connections incorrectly hidden by default in domain mode.
In-Reply-To: <JIRA.12509108.1383145401000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509108.1383145401000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509108.1383145401000.24265.1383147062580@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2412:
-----------------------------------

        Parent: WFLY-490
    Issue Type: Sub-task  (was: Bug)

    
> security realms and ldap connections incorrectly hidden by default in domain mode.
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-2412
>                 URL: https://issues.jboss.org/browse/WFLY-2412
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Running WildFly master in domain mode and connect using the CLI.
> {code}
> [domain at localhost:9990 /] :whoami(verbose=true)
> {
>     "outcome" => "success",
>     "result" => {
>         "identity" => {
>             "username" => "$local",
>             "realm" => "ManagementRealm"
>         },
>         "mapped-roles" => ["SuperUser"]
>     }
> }
> {code}
> Although this shows the user has been authenticated against the ManagementRealm is apparently does not exist!
> {code}
> [domain at localhost:9990 /] ./core-service=management/security-realm=ManagementRealm:read-resource
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014807: Management resource '[
>     (\"core-service\" => \"management\"),
>     (\"security-realm\" => \"ManagementRealm\")
> ]' not found",
>     "rolled-back" => true
> }
> {code}
> First impression is that access control is hiding a sensitive resource even though with the default config it should not.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 11:37:02 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Wed, 30 Oct 2013 11:37:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2267) Persisting a new entity bean
 with certain patterns fails to ARJUNA016082 on flush stage.
In-Reply-To: <JIRA.12502535.1381312028000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502535.1381312028000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502535.1381312028000.24300.1383147422240@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825836#comment-12825836 ] 

Scott Marlow commented on WFLY-2267:
------------------------------------

Did you originally change from NON_XA to FULL_XA?  As far as I can tell, we default to NON_XA, so I am curious what led you to use FULL_XA mode?
                
> Persisting a new entity bean with certain patterns fails to ARJUNA016082 on flush stage.
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-2267
>                 URL: https://issues.jboss.org/browse/WFLY-2267
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Alpha4, 8.0.0.Beta1
>         Environment: Ubuntu Linux 13.04, JDK 1.7.0u40 64-bit.
>            Reporter: Jari Juslin
>            Assignee: Scott Marlow
>         Attachments: infinispan_bug_repro.zip, infinispan_bug_repro2.zip
>
>
> Persisting a new entity inside a CMT and then exiting the transactional method throws ARJUNA016082 in certain cases.
> I have extracted two cases where the bug manifests.
> 1) Creating a new entity bean and then changing one field after the persist call.
> 2) Creating a new entity bean that has another entity linked to it, and the newly created entity is on the blind side of the relationship.
> Here is the RESTeasy service and the entity bean needed to replicate this (also packaged to the attached test case):
> package bugrepro2;
> import javax.ejb.LocalBean;
> import javax.ejb.Stateless;
> import javax.persistence.EntityManager;
> import javax.persistence.PersistenceContext;
> import javax.ws.rs.POST;
> import javax.ws.rs.Path;
> /**
>  * @author Jari Juslin, zds at ecolane.com
>  */
> @Stateless
> @LocalBean
> @Path("/bug_repro2")
> public class BugRepro2Rest {
>     @PersistenceContext(unitName = "persistence_context2")
>     protected EntityManager entityManager;
>     
>     @POST
>     public String manifestArjunaBug() {
>         BugReproEntity entry = new BugReproEntity();
>         entityManager.persist(entry);
>         
>         entry.setHasChanges(true);
>         
>         return "Success\n";
>     }
> }
> package bugrepro2;
> import javax.persistence.Column;
> import javax.persistence.Entity;
> import javax.persistence.GeneratedValue;
> import javax.persistence.GenerationType;
> import javax.persistence.Id;
> import javax.persistence.Table;
> import org.hibernate.annotations.Cache;
> import org.hibernate.annotations.CacheConcurrencyStrategy;
> @Entity()
> @Table(name = "bugrepro_entity")
> @Cache(usage=CacheConcurrencyStrategy.TRANSACTIONAL)
> public class BugReproEntity {
>     private Integer id;
>     private boolean hasChanges;
>     public BugReproEntity() {
>     }
>     @Id
>     @GeneratedValue(strategy=GenerationType.IDENTITY)
>     @Column(name="id")
>     public Integer getId() {
>         return id;
>     }
>     public void setId(Integer id) {
>         this.id = id;
>     }
>     @Column(name="has_changes")
>     public boolean getHasChanges() {
>         return hasChanges;
>     }
>     public void setHasChanges(boolean hasChanges) {
>         this.hasChanges = hasChanges;
>     }
> }
> Infinispan config block on standalone.xml:
>             <cache-container name="hibernate" default-cache="local-query" module="org.hibernate">
>                 <local-cache name="entity">
>                     <transaction mode="FULL_XA"/>
>                     <eviction strategy="LRU" max-entries="10000"/>
>                     <expiration max-idle="100000"/>
>                     <indexing index="LOCAL">
>                         <property name="hibernate.search.default.directory_provider">                                                                                                                                                                                           
>                             ram                                                                                                                                                                                                                                                 
>                         </property>
>                     </indexing>
>                 </local-cache>
> ...
>             </cache-container>
> The resulting exception:
> 2013-10-09 12:44:07,362 WARN  [org.infinispan.transaction.TransactionTable] (default task-31:) ISPN000101: Failed synchronization registration: java.lang.IllegalStateException: ARJUNA016082: Synchronizations are not allowed! Transaction status isActionStatus.RUNNING
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronizationImple(TransactionImple.java:379)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronization(TransactionImple.java:356)
> 	at org.infinispan.transaction.TransactionTable.enlist(TransactionTable.java:196)
> 	at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:269)
> 	at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:231)
> 	at org.infinispan.interceptors.TxInterceptor.visitPutKeyValueCommand(TxInterceptor.java:177)
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.updateStoreStatistics(CacheMgmtInterceptor.java:148)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:134)
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:106)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:70)
> 	at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32)
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:321)
> 	at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1298)
> 	at org.infinispan.CacheImpl.putInternal(CacheImpl.java:871)
> 	at org.infinispan.CacheImpl.put(CacheImpl.java:863)
> 	at org.infinispan.DecoratedCache.put(DecoratedCache.java:401)
> 	at org.infinispan.AbstractDelegatingCache.put(AbstractDelegatingCache.java:276)
> 	at org.hibernate.cache.infinispan.access.TransactionalAccessDelegate.update(TransactionalAccessDelegate.java:187) [hibernate-infinispan-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.cache.infinispan.entity.TransactionalAccess.update(TransactionalAccess.java:89) [hibernate-infinispan-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.action.internal.EntityUpdateAction.execute(EntityUpdateAction.java:208) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:377) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:369) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:287) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:340) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:52) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1235) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:405) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:113) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:53) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76)
> 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:273)
> 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:93)
> 	at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1170)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
> 	at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:93) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:437)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72)
> 	at bugrepro2.BugRepro2Rest$$$view31.manifestArjunaBug(Unknown Source) [classes:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_40]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_40]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_40]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_40]
> 	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:280) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:234) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:221) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:59) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:218) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:619) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> The datasource definition from standalone.xml:
>                 <datasource jndi-name="java:/BugRepro2DS" pool-name="BugRepro2DS" enabled="true">
>                     <connection-url>jdbc:mysql://localhost:3306/bugrepro2</connection-url>
>                     <driver>mysql</driver>
>                     <security>
>                         <user-name>*******</user-name>
>                         <password>*******</password>
>                     </security>
>                 </datasource>
>                 <drivers>
>                     <driver name="mysql" module="com.mysql">
>                         <xa-datasource-class>com.mysql.jdbc.jdbc2.optional.MysqlXADataSource</xa-datasource-class>
>                     </driver>
>                 </drivers>
> I have reported this also to Infinispan, because I am not sure which party is to blame.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 11:50:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 30 Oct 2013 11:50:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2412) security realms and ldap
 connections incorrectly hidden by default in domain mode.
In-Reply-To: <JIRA.12509108.1383145401000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509108.1383145401000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509108.1383145401000.24336.1383148202728@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825844#comment-12825844 ] 

RH Bugzilla Integration commented on WFLY-2412:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> made a comment on [bug 1024930|https://bugzilla.redhat.com/show_bug.cgi?id=1024930]

There are no domain level security realm resources. You need to prefix that address with /host=<name of a host>.
                
> security realms and ldap connections incorrectly hidden by default in domain mode.
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-2412
>                 URL: https://issues.jboss.org/browse/WFLY-2412
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Running WildFly master in domain mode and connect using the CLI.
> {code}
> [domain at localhost:9990 /] :whoami(verbose=true)
> {
>     "outcome" => "success",
>     "result" => {
>         "identity" => {
>             "username" => "$local",
>             "realm" => "ManagementRealm"
>         },
>         "mapped-roles" => ["SuperUser"]
>     }
> }
> {code}
> Although this shows the user has been authenticated against the ManagementRealm is apparently does not exist!
> {code}
> [domain at localhost:9990 /] ./core-service=management/security-realm=ManagementRealm:read-resource
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014807: Management resource '[
>     (\"core-service\" => \"management\"),
>     (\"security-realm\" => \"ManagementRealm\")
> ]' not found",
>     "rolled-back" => true
> }
> {code}
> First impression is that access control is hiding a sensitive resource even though with the default config it should not.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 11:50:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 30 Oct 2013 11:50:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2412) security realms and ldap
 connections incorrectly hidden by default in domain mode.
In-Reply-To: <JIRA.12509108.1383145401000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509108.1383145401000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509108.1383145401000.24338.1383148202821@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825845#comment-12825845 ] 

RH Bugzilla Integration commented on WFLY-2412:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1024930|https://bugzilla.redhat.com/show_bug.cgi?id=1024930] from ASSIGNED to CLOSED
                
> security realms and ldap connections incorrectly hidden by default in domain mode.
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-2412
>                 URL: https://issues.jboss.org/browse/WFLY-2412
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Running WildFly master in domain mode and connect using the CLI.
> {code}
> [domain at localhost:9990 /] :whoami(verbose=true)
> {
>     "outcome" => "success",
>     "result" => {
>         "identity" => {
>             "username" => "$local",
>             "realm" => "ManagementRealm"
>         },
>         "mapped-roles" => ["SuperUser"]
>     }
> }
> {code}
> Although this shows the user has been authenticated against the ManagementRealm is apparently does not exist!
> {code}
> [domain at localhost:9990 /] ./core-service=management/security-realm=ManagementRealm:read-resource
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014807: Management resource '[
>     (\"core-service\" => \"management\"),
>     (\"security-realm\" => \"ManagementRealm\")
> ]' not found",
>     "rolled-back" => true
> }
> {code}
> First impression is that access control is hiding a sensitive resource even though with the default config it should not.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 12:02:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 30 Oct 2013 12:02:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1675) Threads stuck in
 FlowControl.decrementIfEnoughCredits
In-Reply-To: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498385.1376295331000.24371.1383148923409@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825808#comment-12825808 ] 

Bela Ban edited comment on JGRP-1675 at 10/30/13 12:00 PM:
-----------------------------------------------------------

Tried to replicate the stress test in JGroups ({{RemoteGetStressTest}} is attached). With 500 threads, the tests completes between 60 and 90 seconds. This is with a random delay de-serializing the BigObject between 1 and 10 ms, and with a DISCARD up-rate of 20%.

If {{USE_SLEEPS}} is changed to false, the test finishes within a few seconds (between 2 and 5 secs).  This is with an OOB pool of min=1/max=5/no-queue.

The delaying and discarding certainly slows things down, but I never experienced a deadlock.
                
      was (Author: belaban):
    Tried to replicate the stress test in JGroups (RemoteGetStressTest ia attached). With 500 threads, the tests completes within 60 and 90 seconds. This is with a random delay de-serializing the BigObject between 1 and 10 ms, and with a DISCARD up-rate of 20%.

If {{USE_SLEEPS}} is changed to false, the test finishes within a few second (between 2 and 5 secs).  This is with an OOB pool of min=1/max=5/no-queue.

The delaying and discarding certainly slows things downm, but I never experience a deadlock.
                  
> Threads stuck in FlowControl.decrementIfEnoughCredits
> -----------------------------------------------------
>
>                 Key: JGRP-1675
>                 URL: https://issues.jboss.org/browse/JGRP-1675
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>         Attachments: RemoteGetStressTest.java
>
>
> I have recently observed a repeated situation where many (or all) threads have been stuck waiting for credits in FlowControl protocol.
> The credit request was not handled on the other node as this is non-oob message and some (actually many of them - cause unknown) messages before the request have been lost - therefore the request was waiting for them to be re-sent.
> However, these have not been re-sent properly as the retransmission request was not received - all OOB threads were stuck in the FlowControl protocol as these handled some other request and tried to send a response - but the response could not be sent until FlowControl gets the credits.
> The probability of such situation could be lowered by tagging the credit request to be OOB - then it would be handled immediately. If the credit replenish message would then be processed in regular OOB pool, this could get already depleted by many requests, but setting up the internal thread pool would solve the problem.
> Other consideration would be to allow releasing thread from FlowControl (let it send the message even without credits) if it waits there for too long.
> h3. Workaround
> It appears that setting MFC and UFC max_credits to 10M or removing these protocols at all is a workaround for this issue.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 12:02:03 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Wed, 30 Oct 2013 12:02:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-882) Improve error message for
 bad/incomplete XML in deployment scanner
In-Reply-To: <JIRA.12489692.1366194283000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489692.1366194283000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489692.1366194283000.24373.1383148923761@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-882:
------------------------------

    Summary: Improve error message for bad/incomplete XML in deployment scanner  (was: Deploying dynamic VDB with invalid XML will cause incomprehensible error)
     Labels: jug_hackathon_candidate  (was: )


We could improve the error by saying something like "blah.xml is not well-formed waiting in case it is an incomplete copy."
                
> Improve error message for bad/incomplete XML in deployment scanner
> ------------------------------------------------------------------
>
>                 Key: WFLY-882
>                 URL: https://issues.jboss.org/browse/WFLY-882
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Filip Nguyen
>            Priority: Trivial
>              Labels: jug_hackathon_candidate
>         Attachments: loop-vdb.xml
>
>
> Deploying VDB with invalid XML (closed translator tag). Causes following error:
> [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1)  JBAS015009: Scan found incompletely copied file content for deployment standalone/deployments/loop-vdb.xml. Deployment changes will not be processed until all content is complete.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 12:04:02 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Wed, 30 Oct 2013 12:04:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-882) Improve error message for
 bad/incomplete XML in deployment scanner
In-Reply-To: <JIRA.12489692.1366194283000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489692.1366194283000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489692.1366194283000.24381.1383149042265@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-882:
------------------------------

    Labels:   (was: jug_hackathon_candidate)

    
> Improve error message for bad/incomplete XML in deployment scanner
> ------------------------------------------------------------------
>
>                 Key: WFLY-882
>                 URL: https://issues.jboss.org/browse/WFLY-882
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Filip Nguyen
>            Priority: Trivial
>         Attachments: loop-vdb.xml
>
>
> Deploying VDB with invalid XML (closed translator tag). Causes following error:
> [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1)  JBAS015009: Scan found incompletely copied file content for deployment standalone/deployments/loop-vdb.xml. Deployment changes will not be processed until all content is complete.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 12:04:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 30 Oct 2013 12:04:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2412) security realms and ldap
 connections incorrectly hidden by default in domain mode.
In-Reply-To: <JIRA.12509108.1383145401000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509108.1383145401000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509108.1383145401000.24385.1383149042627@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825850#comment-12825850 ] 

RH Bugzilla Integration commented on WFLY-2412:
-----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> made a comment on [bug 1024930|https://bugzilla.redhat.com/show_bug.cgi?id=1024930]

In that case probably a bad resource definition exposing those resources at domain level.
                
> security realms and ldap connections incorrectly hidden by default in domain mode.
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-2412
>                 URL: https://issues.jboss.org/browse/WFLY-2412
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Running WildFly master in domain mode and connect using the CLI.
> {code}
> [domain at localhost:9990 /] :whoami(verbose=true)
> {
>     "outcome" => "success",
>     "result" => {
>         "identity" => {
>             "username" => "$local",
>             "realm" => "ManagementRealm"
>         },
>         "mapped-roles" => ["SuperUser"]
>     }
> }
> {code}
> Although this shows the user has been authenticated against the ManagementRealm is apparently does not exist!
> {code}
> [domain at localhost:9990 /] ./core-service=management/security-realm=ManagementRealm:read-resource
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014807: Management resource '[
>     (\"core-service\" => \"management\"),
>     (\"security-realm\" => \"ManagementRealm\")
> ]' not found",
>     "rolled-back" => true
> }
> {code}
> First impression is that access control is hiding a sensitive resource even though with the default config it should not.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 12:04:02 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Wed, 30 Oct 2013 12:04:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-882) Improve error message for
 bad/incomplete XML in deployment scanner
In-Reply-To: <JIRA.12489692.1366194283000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489692.1366194283000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489692.1366194283000.24387.1383149042775@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-882:
------------------------------

    Estimated Difficulty: Medium

    
> Improve error message for bad/incomplete XML in deployment scanner
> ------------------------------------------------------------------
>
>                 Key: WFLY-882
>                 URL: https://issues.jboss.org/browse/WFLY-882
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Filip Nguyen
>            Priority: Trivial
>         Attachments: loop-vdb.xml
>
>
> Deploying VDB with invalid XML (closed translator tag). Causes following error:
> [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1)  JBAS015009: Scan found incompletely copied file content for deployment standalone/deployments/loop-vdb.xml. Deployment changes will not be processed until all content is complete.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 12:06:02 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Wed, 30 Oct 2013 12:06:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-882) Improve error message for
 bad/incomplete XML in deployment scanner
In-Reply-To: <JIRA.12489692.1366194283000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489692.1366194283000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489692.1366194283000.24399.1383149162308@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene reassigned WFLY-882:
---------------------------------

    Assignee: Tomaz Cerar

    
> Improve error message for bad/incomplete XML in deployment scanner
> ------------------------------------------------------------------
>
>                 Key: WFLY-882
>                 URL: https://issues.jboss.org/browse/WFLY-882
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Filip Nguyen
>            Assignee: Tomaz Cerar
>            Priority: Trivial
>         Attachments: loop-vdb.xml
>
>
> Deploying VDB with invalid XML (closed translator tag). Causes following error:
> [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1)  JBAS015009: Scan found incompletely copied file content for deployment standalone/deployments/loop-vdb.xml. Deployment changes will not be processed until all content is complete.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 12:08:02 2013
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Wed, 30 Oct 2013 12:08:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1129) Add VisualVm launch scripts
 to the AS7 distribution
In-Reply-To: <JIRA.12463661.1334132494000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12463661.1334132494000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12463661.1334132494000.24406.1383149282127@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene updated WFLY-1129:
-------------------------------

    Assignee:     (was: Jason Greene)

    
> Add VisualVm launch scripts to the AS7 distribution
> ---------------------------------------------------
>
>                 Key: WFLY-1129
>                 URL: https://issues.jboss.org/browse/WFLY-1129
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Scripts
>         Environment: All 
>            Reporter: John O'Hara
>            Priority: Trivial
>
> Launching VisualVM with remoting-jmx requires additional jars to be on the classpath, in the same way that launching jconsole does.
> Can we provice a .sh and a .bat with the correct classpath in the AS7 distribution to launch visualvm

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 12:14:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 30 Oct 2013 12:14:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2412) Security Realm and LDAP
 Connection incorrectly available as resourced under
 core-services=management in domain mode.
In-Reply-To: <JIRA.12509108.1383145401000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509108.1383145401000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509108.1383145401000.24445.1383149642349@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2412:
-----------------------------------

    Summary: Security Realm and LDAP Connection incorrectly available as resourced under core-services=management in domain mode.  (was: security realms and ldap connections incorrectly hidden by default in domain mode.)

    
> Security Realm and LDAP Connection incorrectly available as resourced under core-services=management in domain mode.
> --------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2412
>                 URL: https://issues.jboss.org/browse/WFLY-2412
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Running WildFly master in domain mode and connect using the CLI.
> {code}
> [domain at localhost:9990 /] :whoami(verbose=true)
> {
>     "outcome" => "success",
>     "result" => {
>         "identity" => {
>             "username" => "$local",
>             "realm" => "ManagementRealm"
>         },
>         "mapped-roles" => ["SuperUser"]
>     }
> }
> {code}
> Although this shows the user has been authenticated against the ManagementRealm is apparently does not exist!
> {code}
> [domain at localhost:9990 /] ./core-service=management/security-realm=ManagementRealm:read-resource
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014807: Management resource '[
>     (\"core-service\" => \"management\"),
>     (\"security-realm\" => \"ManagementRealm\")
> ]' not found",
>     "rolled-back" => true
> }
> {code}
> First impression is that access control is hiding a sensitive resource even though with the default config it should not.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 12:14:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 30 Oct 2013 12:14:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2412) Security Realm and LDAP
 Connection incorrectly available as resourced under
 core-services=management in domain mode.
In-Reply-To: <JIRA.12509108.1383145401000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509108.1383145401000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509108.1383145401000.24449.1383149642495@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2412:
-----------------------------------

    Description: 
Security realms and LDAP connections should only be definable under specific hosts in domain mode - the resources for these are currently available in the domain wide code-services=management resource.


  was:
Running WildFly master in domain mode and connect using the CLI.

{code}
[domain at localhost:9990 /] :whoami(verbose=true)
{
    "outcome" => "success",
    "result" => {
        "identity" => {
            "username" => "$local",
            "realm" => "ManagementRealm"
        },
        "mapped-roles" => ["SuperUser"]
    }
}
{code}

Although this shows the user has been authenticated against the ManagementRealm is apparently does not exist!

{code}
[domain at localhost:9990 /] ./core-service=management/security-realm=ManagementRealm:read-resource
{
    "outcome" => "failed",
    "failure-description" => "JBAS014807: Management resource '[
    (\"core-service\" => \"management\"),
    (\"security-realm\" => \"ManagementRealm\")
]' not found",
    "rolled-back" => true
}
{code}

First impression is that access control is hiding a sensitive resource even though with the default config it should not.


    
> Security Realm and LDAP Connection incorrectly available as resourced under core-services=management in domain mode.
> --------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2412
>                 URL: https://issues.jboss.org/browse/WFLY-2412
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Security realms and LDAP connections should only be definable under specific hosts in domain mode - the resources for these are currently available in the domain wide code-services=management resource.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 12:18:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 30 Oct 2013 12:18:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1717) Bundling reduces performance
 in scenario mimicking Inifinispan
In-Reply-To: <JIRA.12503239.1381926401000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503239.1381926401000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503239.1381926401000.24456.1383149882173@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825856#comment-12825856 ] 

Bela Ban commented on JGRP-1717:
--------------------------------

Added option to enable / disable DONT_BUNDLE for GETs and PUTs in UPerf. Preliminary tests with 4 members / 10 sender threads per member and each member sending 100'000 messages showed that *disabling DONT_BUNDLE* is a clear winner: +DONT_BUNDLE ca. 6'000 msgs/sec/node, -DONT_BUNDLE ca. 8'500 msgs/sec/node
                
> Bundling reduces performance in scenario mimicking Inifinispan
> --------------------------------------------------------------
>
>                 Key: JGRP-1717
>                 URL: https://issues.jboss.org/browse/JGRP-1717
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.3
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>         Attachments: benchmark-jgroups.xml, jgroups-udp.pdf, jgroups-udp.xml
>
>
> In Radargun benchmark of JGroups mimicking the behaviour of Infinispan we can see that performance with bundling on actually reduces the performance.
> See attached configurations and results.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 12:20:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 30 Oct 2013 12:20:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2412) Security Realm and LDAP
 Connection incorrectly available as resourced under
 core-services=management in domain mode.
In-Reply-To: <JIRA.12509108.1383145401000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509108.1383145401000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509108.1383145401000.24462.1383150002040@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825858#comment-12825858 ] 

RH Bugzilla Integration commented on WFLY-2412:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1024930|https://bugzilla.redhat.com/show_bug.cgi?id=1024930] from CLOSED to ASSIGNED
                
> Security Realm and LDAP Connection incorrectly available as resourced under core-services=management in domain mode.
> --------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2412
>                 URL: https://issues.jboss.org/browse/WFLY-2412
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Security realms and LDAP connections should only be definable under specific hosts in domain mode - the resources for these are currently available in the domain wide code-services=management resource.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 12:20:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 30 Oct 2013 12:20:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2412) Security Realm and LDAP
 Connection incorrectly available as resourced under
 core-services=management in domain mode.
In-Reply-To: <JIRA.12509108.1383145401000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509108.1383145401000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509108.1383145401000.24465.1383150002144@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825859#comment-12825859 ] 

RH Bugzilla Integration commented on WFLY-2412:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> made a comment on [bug 1024930|https://bugzilla.redhat.com/show_bug.cgi?id=1024930]

Good catch Darran. I'm re-opening with a changed title. The fix is to remove those from the metadata.
                
> Security Realm and LDAP Connection incorrectly available as resourced under core-services=management in domain mode.
> --------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2412
>                 URL: https://issues.jboss.org/browse/WFLY-2412
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Security realms and LDAP connections should only be definable under specific hosts in domain mode - the resources for these are currently available in the domain wide code-services=management resource.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 12:26:01 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 30 Oct 2013 12:26:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2412) Security Realm and LDAP
 Connection incorrectly available as resourced under
 core-services=management in domain mode.
In-Reply-To: <JIRA.12509108.1383145401000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509108.1383145401000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509108.1383145401000.24484.1383150361987@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825864#comment-12825864 ] 

RH Bugzilla Integration commented on WFLY-2412:
-----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> made a comment on [bug 1024930|https://bugzilla.redhat.com/show_bug.cgi?id=1024930]

Yes is it a one line fix (two if you count the closing bracket of the if statement) ;-)

Pull requests coming shortly.
                
> Security Realm and LDAP Connection incorrectly available as resourced under core-services=management in domain mode.
> --------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2412
>                 URL: https://issues.jboss.org/browse/WFLY-2412
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Security realms and LDAP connections should only be definable under specific hosts in domain mode - the resources for these are currently available in the domain wide code-services=management resource.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 12:30:02 2013
From: jira-events at lists.jboss.org (Alessio Soldano (JIRA))
Date: Wed, 30 Oct 2013 12:30:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2413) UnsupportedOperationException
 in WeldComponentService#findManagedBeanForWSComponent
In-Reply-To: <JIRA.12509120.1383150484632@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509120.1383150484632@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509120.1383150484632.24495.1383150602045@jira02.app.mwc.hst.phx2.redhat.com>

Alessio Soldano created WFLY-2413:
-------------------------------------

             Summary: UnsupportedOperationException in WeldComponentService#findManagedBeanForWSComponent
                 Key: WFLY-2413
                 URL: https://issues.jboss.org/browse/WFLY-2413
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: CDI / Weld
            Reporter: Alessio Soldano
            Assignee: Stuart Douglas
             Fix For: 8.0.0.CR1
         Attachments: jaxws-cxf-mixtype.war

I'm getting a java.lang.UnsupportedOperationException when deploying one of the jbossws-cxf testsuite test archive (attached to the case).

17:17:31,212 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.unit."jaxws-cxf-mixtype.war".component.Ep1Servlet.WeldInstantiator: org.jboss.msc.service.StartException in service jboss.deployment.unit."jaxws-cxf-mixtype.war".component.Ep1Servlet.WeldInstantiator: Failed to start service
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1900) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
Caused by: java.lang.UnsupportedOperationException
	at java.util.Collections$UnmodifiableCollection$1.remove(Collections.java:1069) [rt.jar:1.7.0_17]
	at org.jboss.as.weld.injection.WeldComponentService.findManagedBeanForWSComponent(WeldComponentService.java:174)
	at org.jboss.as.weld.injection.WeldComponentService.start(WeldComponentService.java:129)
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
	... 3 more

17:17:31,235 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "jaxws-cxf-mixtype.war")]) - failure description: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"jaxws-cxf-mixtype.war\".component.Ep1Servlet.WeldInstantiator" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"jaxws-cxf-mixtype.war\".component.Ep1Servlet.WeldInstantiator: Failed to start service
    Caused by: java.lang.UnsupportedOperationException"}}
17:17:31,238 ERROR [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS015870: Deploy of deployment "jaxws-cxf-mixtype.war" was rolled back with the following failure message: 
{"JBAS014671: Failed services" => {"jboss.deployment.unit.\"jaxws-cxf-mixtype.war\".component.Ep1Servlet.WeldInstantiator" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"jaxws-cxf-mixtype.war\".component.Ep1Servlet.WeldInstantiator: Failed to start service
    Caused by: java.lang.UnsupportedOperationException"}}


The problem is introduced by one of the commits in WFLY master listed at http://jbossws.jboss.org:8180/hudson/job/AS-8.0.0/267/changes 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 12:30:02 2013
From: jira-events at lists.jboss.org (Alessio Soldano (JIRA))
Date: Wed, 30 Oct 2013 12:30:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2413) UnsupportedOperationException
 in WeldComponentService#findManagedBeanForWSComponent
In-Reply-To: <JIRA.12509120.1383150484000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509120.1383150484000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509120.1383150484000.24500.1383150602288@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alessio Soldano updated WFLY-2413:
----------------------------------

    Attachment: jaxws-cxf-mixtype.war

    
> UnsupportedOperationException in WeldComponentService#findManagedBeanForWSComponent
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-2413
>                 URL: https://issues.jboss.org/browse/WFLY-2413
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>            Reporter: Alessio Soldano
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.CR1
>
>         Attachments: jaxws-cxf-mixtype.war
>
>
> I'm getting a java.lang.UnsupportedOperationException when deploying one of the jbossws-cxf testsuite test archive (attached to the case).
> 17:17:31,212 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.unit."jaxws-cxf-mixtype.war".component.Ep1Servlet.WeldInstantiator: org.jboss.msc.service.StartException in service jboss.deployment.unit."jaxws-cxf-mixtype.war".component.Ep1Servlet.WeldInstantiator: Failed to start service
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1900) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> Caused by: java.lang.UnsupportedOperationException
> 	at java.util.Collections$UnmodifiableCollection$1.remove(Collections.java:1069) [rt.jar:1.7.0_17]
> 	at org.jboss.as.weld.injection.WeldComponentService.findManagedBeanForWSComponent(WeldComponentService.java:174)
> 	at org.jboss.as.weld.injection.WeldComponentService.start(WeldComponentService.java:129)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	... 3 more
> 17:17:31,235 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "jaxws-cxf-mixtype.war")]) - failure description: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"jaxws-cxf-mixtype.war\".component.Ep1Servlet.WeldInstantiator" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"jaxws-cxf-mixtype.war\".component.Ep1Servlet.WeldInstantiator: Failed to start service
>     Caused by: java.lang.UnsupportedOperationException"}}
> 17:17:31,238 ERROR [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS015870: Deploy of deployment "jaxws-cxf-mixtype.war" was rolled back with the following failure message: 
> {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"jaxws-cxf-mixtype.war\".component.Ep1Servlet.WeldInstantiator" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"jaxws-cxf-mixtype.war\".component.Ep1Servlet.WeldInstantiator: Failed to start service
>     Caused by: java.lang.UnsupportedOperationException"}}
> The problem is introduced by one of the commits in WFLY master listed at http://jbossws.jboss.org:8180/hudson/job/AS-8.0.0/267/changes 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 12:35:02 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 30 Oct 2013 12:35:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-882) Improve error message for
 bad/incomplete XML in deployment scanner
In-Reply-To: <JIRA.12489692.1366194283000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489692.1366194283000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489692.1366194283000.24519.1383150902218@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825868#comment-12825868 ] 

Brian Stansberry commented on WFLY-882:
---------------------------------------

An additional INFO message saying that would be good. There's a specific method that detects malformed xml that could log that without any changes elsewhere.

Note the message in the JIRA description is at INFO.
                
> Improve error message for bad/incomplete XML in deployment scanner
> ------------------------------------------------------------------
>
>                 Key: WFLY-882
>                 URL: https://issues.jboss.org/browse/WFLY-882
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Filip Nguyen
>            Assignee: Tomaz Cerar
>            Priority: Trivial
>         Attachments: loop-vdb.xml
>
>
> Deploying VDB with invalid XML (closed translator tag). Causes following error:
> [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1)  JBAS015009: Scan found incompletely copied file content for deployment standalone/deployments/loop-vdb.xml. Deployment changes will not be processed until all content is complete.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 12:37:01 2013
From: jira-events at lists.jboss.org (Harald Pehl (JIRA))
Date: Wed, 30 Oct 2013 12:37:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2414) Update to HAL 2.0.6.Final
In-Reply-To: <JIRA.12509121.1383150917107@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509121.1383150917107@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509121.1383150917107.24522.1383151021935@jira02.app.mwc.hst.phx2.redhat.com>

Harald Pehl created WFLY-2414:
---------------------------------

             Summary: Update to HAL 2.0.6.Final
                 Key: WFLY-2414
                 URL: https://issues.jboss.org/browse/WFLY-2414
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Web Console
            Reporter: Harald Pehl
            Assignee: Heiko Braun
             Fix For: 8.0.0.CR1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 12:37:02 2013
From: jira-events at lists.jboss.org (Harald Pehl (JIRA))
Date: Wed, 30 Oct 2013 12:37:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2414) Update to HAL 2.0.6.Final
In-Reply-To: <JIRA.12509121.1383150917000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509121.1383150917000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509121.1383150917000.24524.1383151022019@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Harald Pehl reassigned WFLY-2414:
---------------------------------

    Assignee: Harald Pehl  (was: Heiko Braun)

    
> Update to HAL 2.0.6.Final
> -------------------------
>
>                 Key: WFLY-2414
>                 URL: https://issues.jboss.org/browse/WFLY-2414
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Console
>            Reporter: Harald Pehl
>            Assignee: Harald Pehl
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 12:57:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 30 Oct 2013 12:57:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2412) Security Realm and LDAP
 Connection incorrectly available as resourced under
 core-services=management in domain mode.
In-Reply-To: <JIRA.12509108.1383145401000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509108.1383145401000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509108.1383145401000.24560.1383152222046@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825874#comment-12825874 ] 

RH Bugzilla Integration commented on WFLY-2412:
-----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> changed the Status of [bug 1024930|https://bugzilla.redhat.com/show_bug.cgi?id=1024930] from ASSIGNED to POST
                
> Security Realm and LDAP Connection incorrectly available as resourced under core-services=management in domain mode.
> --------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2412
>                 URL: https://issues.jboss.org/browse/WFLY-2412
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Security realms and LDAP connections should only be definable under specific hosts in domain mode - the resources for these are currently available in the domain wide code-services=management resource.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 13:07:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 30 Oct 2013 13:07:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2214) Allow additional environment
 properties to be set for outbound LDAP connections used by security realms.
In-Reply-To: <JIRA.12502155.1380834418000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502155.1380834418000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502155.1380834418000.24577.1383152822519@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2214:
-----------------------------------

    Summary: Allow additional environment properties to be set for outbound LDAP connections used by security realms.  (was: Allow existing environment properties to be set for outbound LDAP connections used by security realms.)

    
> Allow additional environment properties to be set for outbound LDAP connections used by security realms.
> --------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2214
>                 URL: https://issues.jboss.org/browse/WFLY-2214
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Derek Horton
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> LDAP security realm needs to have configurable timeouts.
> The default LDAP connection timeout appears to be 2 minutes.  If the ldap server is down, it could take 2 minutes for the connection to timeout.  This can cause unneeded delay if you have configured multiple ldap servers for  failover / redundancy.
> The following hack appears to work:
> +++ domain-management/src/main/java/org/jboss/as/domain/management/connections/ldap/LdapConnectionManagerService.java
> @@ -132,6 +132,7 @@ public class LdapConnectionManagerService implements Service<LdapConnectionManag
>          result.put(Context.INITIAL_CONTEXT_FACTORY,initialContextFactory);
>          String url = config.require(URL).asString();
>          result.put(Context.PROVIDER_URL,url);
> +        result.put("com.sun.jndi.ldap.connect.timeout", "500");
>          return result;
>      }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 14:09:02 2013
From: jira-events at lists.jboss.org (Divya Mehra (JIRA))
Date: Wed, 30 Oct 2013 14:09:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1487) AUTH: X509Token
 Authentication is vulnerable to replay attacks
In-Reply-To: <JIRA.12469666.1340962910000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12469666.1340962910000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12469666.1340962910000.24726.1383156542296@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Divya Mehra updated JGRP-1487:
------------------------------

    Labels: jdg620_dm jdg62GAblocker  (was: jdg620_dm)

    
> AUTH: X509Token Authentication is vulnerable to replay attacks
> --------------------------------------------------------------
>
>                 Key: JGRP-1487
>                 URL: https://issues.jboss.org/browse/JGRP-1487
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.0.9
>            Reporter: sreenivas chinimilli
>            Assignee: Bela Ban
>              Labels: jdg620_dm, jdg62GAblocker
>             Fix For: 3.5
>
>
> In the implementation of X509Token Authentication
> The auth_value is enrypted with the certificate within the keystore and
> during verification encrypted auth value is decrypted with the private key
> compared against the orignial auth value.
> This implementation is prone to replay attacks, that is
> any user with out having any knowledge of the auth value can join the group
> by replaying the enrypted auth value captured in earlier sessions.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 14:09:02 2013
From: jira-events at lists.jboss.org (Divya Mehra (JIRA))
Date: Wed, 30 Oct 2013 14:09:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1721) AUTH and ENCRYPT protocols
 configured with plain text passwords
In-Reply-To: <JIRA.12508425.1382426440000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508425.1382426440000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508425.1382426440000.24733.1383156542604@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Divya Mehra updated JGRP-1721:
------------------------------

    Labels: jdg620_dm jdg62GAblocker  (was: jdg620_dm)

    
> AUTH and ENCRYPT protocols configured with plain text passwords
> ---------------------------------------------------------------
>
>                 Key: JGRP-1721
>                 URL: https://issues.jboss.org/browse/JGRP-1721
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Martin Gencur
>            Assignee: Bela Ban
>              Labels: jdg620_dm, jdg62GAblocker
>             Fix For: 3.5
>
>
> The following parameters of AUTH protocol are stored as plain text:
> * keystore_password
> The following parameters of ENCRYPT protocol are stored as plain text:
> * store_password
> * key_password
> Example:
> {code}
> <ENCRYPT key_store_name="defaultStore.keystore" store_password="changeit" alias="myKey"/>
> {code}
> Requirements for storing passwords: https://docspace.corp.redhat.com/docs/DOC-131628

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 14:09:02 2013
From: jira-events at lists.jboss.org (Divya Mehra (JIRA))
Date: Wed, 30 Oct 2013 14:09:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1722) Improve performance of
	ENCRYPT protocol
In-Reply-To: <JIRA.12508426.1382426974000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508426.1382426974000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508426.1382426974000.24736.1383156542745@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Divya Mehra updated JGRP-1722:
------------------------------

    Labels: jdg620_dm jdg62GAblocker  (was: jdg620_dm)

    
> Improve performance of ENCRYPT protocol
> ---------------------------------------
>
>                 Key: JGRP-1722
>                 URL: https://issues.jboss.org/browse/JGRP-1722
>             Project: JGroups
>          Issue Type: Enhancement
>    Affects Versions: 3.4
>            Reporter: Martin Gencur
>            Assignee: Bela Ban
>              Labels: jdg620_dm, jdg62GAblocker
>             Fix For: 3.5
>
>
> A stress tests with the following setup showed that performance (reads and writes/sec) is halved when ENCRYPT protocol is enabled:
> Infinispan had distributed sync cache with 2 owners on 4 nodes, no transactions. The stress test used 10 threads on each node accessing 1024 byte entries, no conflicts on keys, 20 % writes, 80 % reads. 
> It would be great if we could improve the performance of ENCRYPT protocol.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 14:25:01 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Wed, 30 Oct 2013 14:25:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2415) Add configuration option to
 enable/disable Infinispan statistics
In-Reply-To: <JIRA.12509131.1383157408174@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509131.1383157408174@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509131.1383157408174.24765.1383157501982@jira02.app.mwc.hst.phx2.redhat.com>

Scott Marlow created WFLY-2415:
----------------------------------

             Summary: Add configuration option to enable/disable Infinispan statistics
                 Key: WFLY-2415
                 URL: https://issues.jboss.org/browse/WFLY-2415
             Project: WildFly
          Issue Type: Enhancement
      Security Level: Public (Everyone can see)
          Components: Clustering
            Reporter: Scott Marlow
            Assignee: Paul Ferraro
             Fix For: 8.0.0.CR1


When the Infinispan MBean is enabled, Infinispan statistics are enabled by default.  Could we allow Infinispan statistics to be enabled/disabled via a WF configuration setting?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 14:36:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 30 Oct 2013 14:36:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2415) Add configuration option to
 enable/disable Infinispan statistics
In-Reply-To: <JIRA.12509131.1383157408000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509131.1383157408000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509131.1383157408000.24795.1383158163268@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2415:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1025023

    
> Add configuration option to enable/disable Infinispan statistics
> ----------------------------------------------------------------
>
>                 Key: WFLY-2415
>                 URL: https://issues.jboss.org/browse/WFLY-2415
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Scott Marlow
>            Assignee: Paul Ferraro
>             Fix For: 8.0.0.CR1
>
>
> When the Infinispan MBean is enabled, Infinispan statistics are enabled by default.  Could we allow Infinispan statistics to be enabled/disabled via a WF configuration setting?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 14:44:02 2013
From: jira-events at lists.jboss.org (John Teller (JIRA))
Date: Wed, 30 Oct 2013 14:44:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2416) Deployment fails with
 Atmosphere (probable regression from WFLY-2333)
In-Reply-To: <JIRA.12509132.1383158622829@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509132.1383158622829@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509132.1383158622829.24802.1383158642224@jira02.app.mwc.hst.phx2.redhat.com>

John Teller created WFLY-2416:
---------------------------------

             Summary: Deployment fails with Atmosphere (probable regression from WFLY-2333)
                 Key: WFLY-2416
                 URL: https://issues.jboss.org/browse/WFLY-2416
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Web (Undertow)
    Affects Versions: 8.0.0.CR1
         Environment: wildfly-8.0.0.Beta2-SNAPSHOT build #762
Atmosphere-runtime 2.0.3
            Reporter: John Teller
            Assignee: Stuart Douglas


Deploying a WAR file containing atmosphere-runtime jar fails with the following error:

14:16:33,411 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.deployment.unit."jboss-as-helloworld.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."jboss-as-helloworld.war"
.INSTALL: JBAS018733: Failed to process phase INSTALL of deployment "jboss-as-helloworld.war"
        at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.
0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
        at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS017327: Deployment error processing SCI for jar:
atmosphere-runtime-2.0.3.jar
        at org.wildfly.extension.undertow.deployment.ServletContainerInitializerDeploymentProcessor.loadSci(ServletContainerInitializerDeploymentProcessor.java:205)
        at org.wildfly.extension.undertow.deployment.ServletContainerInitializerDeploymentProcessor.deploy(ServletContainerInitializerDeploymentProcessor.java:128)
        at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
        ... 5 more
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS017327: Deployment error processing SCI for jar:
atmosphere-runtime-2.0.3.jar
        at org.wildfly.extension.undertow.deployment.ServletContainerInitializerDeploymentProcessor.loadSci(ServletContainerInitializerDeploymentProcessor.java:197)
        ... 7 more
Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: 0
        at java.lang.String.charAt(String.java:658) [rt.jar:1.7.0_17]
        at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:435) [jboss-modules.jar:1.3.0.Final]
        at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:431) [jboss-modules.jar:1.3.0.Final]
        at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:373) [jboss-modules.jar:1.3.0.Final]
        at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:118) [jboss-modules.jar:1.3.0.Final]
        at org.wildfly.extension.undertow.deployment.ServletContainerInitializerDeploymentProcessor.loadSci(ServletContainerInitializerDeploymentProcessor.java:190)
        ... 7 more


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 16:50:01 2013
From: jira-events at lists.jboss.org (Eduardo Martins (JIRA))
Date: Wed, 30 Oct 2013 16:50:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2417) Support URL Connection
 Factory Resource Injection
In-Reply-To: <JIRA.12509137.1383166087979@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509137.1383166087979@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509137.1383166087979.24889.1383166201910@jira02.app.mwc.hst.phx2.redhat.com>

Eduardo Martins created WFLY-2417:
-------------------------------------

             Summary: Support URL Connection Factory Resource Injection
                 Key: WFLY-2417
                 URL: https://issues.jboss.org/browse/WFLY-2417
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: EE
            Reporter: Eduardo Martins
            Assignee: Eduardo Martins


Wildfly needs to support URL Connection Factories @Resource injection, such as:

{code:java}
@Resource(lookup="http://www.wildfly.org")
private URL url;
{code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 16:50:02 2013
From: jira-events at lists.jboss.org (Frank Langelage (JIRA))
Date: Wed, 30 Oct 2013 16:50:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2400)
 org.jboss.as.test.smoke.mgmt.servermodule.ValidateModelTestCase fails
In-Reply-To: <JIRA.12508923.1383033028000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508923.1383033028000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508923.1383033028000.24894.1383166202177@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825932#comment-12825932 ] 

Frank Langelage commented on WFLY-2400:
---------------------------------------

I was running smoke test with "-DnoWebProfile". If I omit this option, problem disappears.
So test seems to be not compatible with full profile.
                
> org.jboss.as.test.smoke.mgmt.servermodule.ValidateModelTestCase fails
> ---------------------------------------------------------------------
>
>                 Key: WFLY-2400
>                 URL: https://issues.jboss.org/browse/WFLY-2400
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server, Test Suite
>    Affects Versions: 8.0.0.Beta1
>         Environment: Solaris SPARC 10, Oracle Java 1.7.0_45
>            Reporter: Frank Langelage
>            Assignee: Stefano Maestri
>         Attachments: org.jboss.as.test.smoke.mgmt.servermodule.ValidateModelTestCase-output.txt, org.jboss.as.test.smoke.mgmt.servermodule.ValidateModelTestCase.txt
>
>
> Running a build of current sources with complete testsuite this test is failing with
> testValidateModel(org.jboss.as.test.smoke.mgmt.servermodule.ValidateModelTestCase): The model failed validation

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 16:50:02 2013
From: jira-events at lists.jboss.org (Frank Langelage (JIRA))
Date: Wed, 30 Oct 2013 16:50:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2401)
 org.jboss.as.test.smoke.mgmt.BasicOperationsUnitTestCase fails
In-Reply-To: <JIRA.12508924.1383033520000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508924.1383033520000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508924.1383033520000.24892.1383166202085@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825931#comment-12825931 ] 

Frank Langelage commented on WFLY-2401:
---------------------------------------

I was running smoke test with "-DnoWebProfile". If I omit this option, problem disappears.
So test seems to be not compatible with full profile.
                
> org.jboss.as.test.smoke.mgmt.BasicOperationsUnitTestCase fails
> --------------------------------------------------------------
>
>                 Key: WFLY-2401
>                 URL: https://issues.jboss.org/browse/WFLY-2401
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.Beta1
>         Environment: Solaris SPARC 10, Oracle Java 1.7.0_45
>            Reporter: Frank Langelage
>            Assignee: Ondrej Zizka
>         Attachments: org.jboss.as.test.smoke.mgmt.BasicOperationsUnitTestCase.txt
>
>
> Running a build of current sources with complete testsuite this test is failing with
> testReadAttributeWildcards(org.jboss.as.test.smoke.mgmt.BasicOperationsUnitTestCase)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 16:50:02 2013
From: jira-events at lists.jboss.org (Frank Langelage (JIRA))
Date: Wed, 30 Oct 2013 16:50:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2399)
 org.jboss.as.test.smoke.deployment.rar.tests.pure.PureTestCase fails
In-Reply-To: <JIRA.12508922.1383032710000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508922.1383032710000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508922.1383032710000.24898.1383166202355@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825933#comment-12825933 ] 

Frank Langelage commented on WFLY-2399:
---------------------------------------

I was running smoke test with "-DnoWebProfile". If I omit this option, problem disappears.
So test seems to be not compatible with full profile.
                
> org.jboss.as.test.smoke.deployment.rar.tests.pure.PureTestCase fails
> --------------------------------------------------------------------
>
>                 Key: WFLY-2399
>                 URL: https://issues.jboss.org/browse/WFLY-2399
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA, Test Suite
>    Affects Versions: 8.0.0.Beta1
>         Environment: Solaris SPARC 10, Oracle Java 1.7.0_45
>            Reporter: Frank Langelage
>            Assignee: Stefano Maestri
>         Attachments: org.jboss.as.test.smoke.deployment.rar.tests.pure.PureTestCase-output.txt, org.jboss.as.test.smoke.deployment.rar.tests.pure.PureTestCase.txt
>
>
> Running a build of current sources with complete testsuite this test is failing with
> testRegistryConfiguration(org.jboss.as.test.smoke.deployment.rar.tests.pure.PureTestCase): expected:<1> but was:<2>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 16:52:01 2013
From: jira-events at lists.jboss.org (Frank Langelage (JIRA))
Date: Wed, 30 Oct 2013 16:52:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2398)
 org.jboss.as.test.smoke.deployment.rar.tests.inflow.InflowTestCase fails
In-Reply-To: <JIRA.12508921.1383032569000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508921.1383032569000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508921.1383032569000.24901.1383166321947@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825934#comment-12825934 ] 

Frank Langelage commented on WFLY-2398:
---------------------------------------

I was running smoke test with "-DnoWebProfile". If I omit this option, problem disappears.
So test seems to be not compatible with full profile.
                
> org.jboss.as.test.smoke.deployment.rar.tests.inflow.InflowTestCase fails
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2398
>                 URL: https://issues.jboss.org/browse/WFLY-2398
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA, Test Suite
>    Affects Versions: 8.0.0.Beta1
>         Environment: Solaris SPARC 10, Oracle Java 1.7.0_45
>            Reporter: Frank Langelage
>            Assignee: Stefano Maestri
>         Attachments: org.jboss.as.test.smoke.deployment.rar.tests.inflow.InflowTestCase-output.txt, org.jboss.as.test.smoke.deployment.rar.tests.inflow.InflowTestCase.txt
>
>
> Running a build of current sources with complete testsuite this test is failing with
> testRegistryConfiguration(org.jboss.as.test.smoke.deployment.rar.tests.inflow.InflowTestCase): expected:<1> but was:<2>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 16:58:01 2013
From: jira-events at lists.jboss.org (Frank Langelage (JIRA))
Date: Wed, 30 Oct 2013 16:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1948) JMXPropertyEditorsTestCase
 fails on Solaris SPARC
In-Reply-To: <JIRA.12499326.1377446989000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499326.1377446989000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499326.1377446989000.24906.1383166681893@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825935#comment-12825935 ] 

Frank Langelage commented on WFLY-1948:
---------------------------------------

Same cause.
Environment variable USER is mandatory currently on non windows systems.
                
> JMXPropertyEditorsTestCase fails on Solaris SPARC
> -------------------------------------------------
>
>                 Key: WFLY-1948
>                 URL: https://issues.jboss.org/browse/WFLY-1948
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.Beta1
>         Environment: Solaris SPARC 10 6/06, Oracle JDK 1.7.0_25
>            Reporter: Frank Langelage
>            Assignee: Ondrej Zizka
>
> Test org.jboss.as.test.integration.ee.jmx.property.JMXPropertyEditorsTestCase fails on Solaris, because environment variable USER is not set.
> From the source:
> USER_SYS_PROP = System.getProperty("os.name","linux").contains("indows")?"USERNAME":"USER";
> So there is already a differentiation between Windows and others.
> For Solaris LOGNAME is the variable to use. And os.name is SunOS.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 17:29:01 2013
From: jira-events at lists.jboss.org (John Smith (JIRA))
Date: Wed, 30 Oct 2013 17:29:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2418) Incorrect PIDFILE location
 (typo in wildfly name)
In-Reply-To: <JIRA.12509139.1383168507551@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509139.1383168507551@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509139.1383168507551.24939.1383168541936@jira02.app.mwc.hst.phx2.redhat.com>

John Smith created WFLY-2418:
--------------------------------

             Summary: Incorrect PIDFILE location (typo in wildfly name)
                 Key: WFLY-2418
                 URL: https://issues.jboss.org/browse/WFLY-2418
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Scripts
    Affects Versions: 8.0.0.Beta1
         Environment: redhat
            Reporter: John Smith
            Assignee: Brian Stansberry


Typo in: 

  https://github.com/wildfly/wildfly/blob/master/build/src/main/resources/bin/init.d/wildfly-init-redhat.sh

wildfly directory name is spelt incorrectly is wilfly.

Line:
  JBOSS_PIDFILE=/var/run/wilfly/wildfly.pid

Should be:
  JBOSS_PIDFILE=/var/run/wildfly/wildfly.pid

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 17:43:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 30 Oct 2013 17:43:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2206) Manualmode test suite copes
 the modules directory multiple times
In-Reply-To: <JIRA.12502031.1380731391000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502031.1380731391000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502031.1380731391000.24947.1383169382382@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825944#comment-12825944 ] 

RH Bugzilla Integration commented on WFLY-2206:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1014742|https://bugzilla.redhat.com/show_bug.cgi?id=1014742] from MODIFIED to ON_QA
                
> Manualmode test suite copes the modules directory multiple times
> ----------------------------------------------------------------
>
>                 Key: WFLY-2206
>                 URL: https://issues.jboss.org/browse/WFLY-2206
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Beta1
>
>
> This uses lots of disk space for no good reason

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 17:43:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 30 Oct 2013 17:43:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2320) EJB should not be remotely
 accessible until all of its dependencies have been started
In-Reply-To: <JIRA.12503266.1381935962000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503266.1381935962000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503266.1381935962000.24957.1383169382862@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825947#comment-12825947 ] 

RH Bugzilla Integration commented on WFLY-2320:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1019894|https://bugzilla.redhat.com/show_bug.cgi?id=1019894] from MODIFIED to ON_QA
                
> EJB should not be remotely accessible until all of its dependencies have been started
> -------------------------------------------------------------------------------------
>
>                 Key: WFLY-2320
>                 URL: https://issues.jboss.org/browse/WFLY-2320
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Brad Maxwell
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.CR1
>
>
> If an EJB injects or depends on a resource such as an @Singleton which has not been started, the EJB's remote interface java:jboss/exported/* is already bound and this allows remote EJB clients to try to invoke it.  This causes the EJB clients to hang because the EJB will not be started until its dependencies have been started.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 17:43:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 30 Oct 2013 17:43:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2371)
 SizeRotatingHandlerTestCase.rotationTest fails with "the file is bigger
 than allowed size"
In-Reply-To: <JIRA.12508645.1382597019000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508645.1382597019000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508645.1382597019000.24960.1383169383023@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825949#comment-12825949 ] 

RH Bugzilla Integration commented on WFLY-2371:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1020339|https://bugzilla.redhat.com/show_bug.cgi?id=1020339] from MODIFIED to ON_QA
                
> SizeRotatingHandlerTestCase.rotationTest fails with "the file is bigger than allowed size"
> ------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2371
>                 URL: https://issues.jboss.org/browse/WFLY-2371
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Petr Kremensky
>            Assignee: Petr Kremensky
>
> The test org.jboss.as.test.integration.logging.operations.SizeRotatingHandlerTestCase.rotationTest consistently fails with:
> java.lang.AssertionError: This file is bigger than allowed rotate-size: size-rotating-reload-rotationTest.log.1
> Link to job:
> https://jenkins.mw.lab.eng.bos.redhat.com/job/eap-6x-manu-acceptance-as-ts-RHEL6_x86-oracleJDK6-srczip/25/testReport/junit/org.jboss.as.test.integration.logging.operations/SizeRotatingHandlerTestCase/rotationTest/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 17:43:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 30 Oct 2013 17:43:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2336) Decreasing max-threads on a
 unbounded queueless executor generates IllegalArgumentException
In-Reply-To: <JIRA.12508206.1382111218000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508206.1382111218000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508206.1382111218000.24965.1383169383294@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825951#comment-12825951 ] 

RH Bugzilla Integration commented on WFLY-2336:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1021077|https://bugzilla.redhat.com/show_bug.cgi?id=1021077] from MODIFIED to ON_QA
                
> Decreasing max-threads on a unbounded queueless executor generates IllegalArgumentException
> -------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2336
>                 URL: https://issues.jboss.org/browse/WFLY-2336
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Aaron Ogburn
>            Priority: Minor
>             Fix For: 8.0.0.CR1
>
>
> Create an unbounded queueless executor
> <unbounded-queue-thread-pool name="uq-thread-pool">
> <max-threads count="350"/>
> <keepalive-time time="5" unit="minutes"/>
> </unbounded-queue-thread-pool>
> Modifying max-threads fails:
> /subsystem=threads/unbounded-queue-thread-pool=uq-thread-pool:write-attribute(name=max-threads,value=300)
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014749: Operation handler failed: null",
>     "rolled-back" => true
> }
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) JBAS014612: Operation ("write-attribute") failed - address: ([
>     ("subsystem" => "threads"),
>     ("unbounded-queue-thread-pool" => "uq-thread-pool")
> ]): java.lang.IllegalArgumentException
> 	at java.util.concurrent.ThreadPoolExecutor.setMaximumPoolSize(ThreadPoolExecutor.java:1620) [rt.jar:1.7.0]
> 	at org.jboss.threads.JBossThreadPoolExecutor.setMaxThreads(JBossThreadPoolExecutor.java:95) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> 	at org.jboss.as.threads.ManagedJBossThreadPoolExecutorService.setMaxThreads(ManagedJBossThreadPoolExecutorService.java:86)
> 	at org.jboss.as.threads.UnboundedQueueThreadPoolService.setMaxThreads(UnboundedQueueThreadPoolService.java:91)
> The core pool size needs to be adjusted in line with the max pool size and in the right order to avoid that since max threads can't be less than core threads.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 17:43:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 30 Oct 2013 17:43:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-158) Constant fields that are not
	final
In-Reply-To: <JIRA.12487846.1364043277000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12487846.1364043277000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487846.1364043277000.24992.1383169384469@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825955#comment-12825955 ] 

RH Bugzilla Integration commented on WFLY-158:
----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 926050|https://bugzilla.redhat.com/show_bug.cgi?id=926050] from MODIFIED to ON_QA
                
> Constant fields that are not final
> ----------------------------------
>
>                 Key: WFLY-158
>                 URL: https://issues.jboss.org/browse/WFLY-158
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Alpha1
>
>         Attachments: non-final-fields.txt
>
>
> Analysis by Stephan Mueller shows that the AS codebase includes a significant number of public constant fields that are missing the "final" keyword, which could allow incorrect or nefarious code to change them. This task is to fix these.
> As part of the work for a few cases I'll reduce the field visibility.
> I'll attach file listing the cases.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 17:45:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 30 Oct 2013 17:45:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-760) Make the JBoss Negotiation
 dependency on JBoss Web - Provided
In-Reply-To: <JIRA.12508666.1382606869000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508666.1382606869000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508666.1382606869000.24999.1383169502387@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/SECURITY-760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825959#comment-12825959 ] 

RH Bugzilla Integration commented on SECURITY-760:
--------------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1022679|https://bugzilla.redhat.com/show_bug.cgi?id=1022679] from MODIFIED to ON_QA
                
> Make the JBoss Negotiation dependency on JBoss Web - Provided
> -------------------------------------------------------------
>
>                 Key: SECURITY-760
>                 URL: https://issues.jboss.org/browse/SECURITY-760
>             Project: PicketBox 
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: Negotiation_2_2_6
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 17:45:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 30 Oct 2013 17:45:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2357) OperationStepHandlers do not
 properly check if runtime steps should be added
In-Reply-To: <JIRA.12508504.1382459867000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508504.1382459867000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508504.1382459867000.25007.1383169502735@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825963#comment-12825963 ] 

RH Bugzilla Integration commented on WFLY-2357:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1021633|https://bugzilla.redhat.com/show_bug.cgi?id=1021633] from MODIFIED to ON_QA
                
> OperationStepHandlers do not properly check if runtime steps should be added
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-2357
>                 URL: https://issues.jboss.org/browse/WFLY-2357
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Minor
>             Fix For: 8.0.0.CR1
>
>
> Currently only checks if the process type is a server which would add runtime steps if booted in admin only mode. This should use the {{OperationContext.isNormalServer()}} instead.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 17:45:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 30 Oct 2013 17:45:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-369) Domain mode: kill an
	unresponsive JVM
In-Reply-To: <JIRA.12480351.1354566315000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12480351.1354566315000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12480351.1354566315000.25013.1383169502965@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825964#comment-12825964 ] 

RH Bugzilla Integration commented on WFLY-369:
----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 901232|https://bugzilla.redhat.com/show_bug.cgi?id=901232] from MODIFIED to ON_QA
                
> Domain mode: kill an unresponsive JVM
> -------------------------------------
>
>                 Key: WFLY-369
>                 URL: https://issues.jboss.org/browse/WFLY-369
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Dennis Reed
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.Alpha1
>
>
> If an AS instance gets into a state where it cannot be controlled normally by the host controller, local OS commands must be used to kill it.
> It would be helpful to be able to kill an unresponsive JVM through the management interface.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 17:45:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 30 Oct 2013 17:45:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-88) Recovery not fully triggered
 when distributed transaction falls down at prepare phase of 2PC
In-Reply-To: <JIRA.12473332.1346248890000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12473332.1346248890000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12473332.1346248890000.25027.1383169503665@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825971#comment-12825971 ] 

RH Bugzilla Integration commented on WFLY-88:
---------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 952746|https://bugzilla.redhat.com/show_bug.cgi?id=952746] from MODIFIED to ON_QA
                
> Recovery not fully triggered when distributed transaction falls down at prepare phase of 2PC
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-88
>                 URL: https://issues.jboss.org/browse/WFLY-88
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB, Remoting
>            Reporter: Ivo Studensky
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Alpha1
>
>         Attachments: logs_prepareHaltClient.tgz
>
>
> It looks like recovery process is not fully triggered on a distributed transaction when the transaction falls down at prepare phase of 2PC. In the new crash recovery tests over propagated transactions only one of two servers recovers from the crash, but the other keeps an unfinished tx in its tx log. 
> It corresponds to prepareHaltClient and prepareHaltServer test methods of org.jboss.as.test.jbossts.crashrec.txpropagation.TxPropagationCrashRecoveryTestCase, see JBQA-2604 for general description of the new tests. The prepareHaltClient test crashes the server which initiated the transaction, while as the prepareHaltServer test crashes the second server.
> The tests are written against EAP6.x branch, so for reproducing this it is needed a built server from the 7.1 branch of AS7.
> Steps to reproduce.
> 1. git clone -b as7 git://git.app.eng.bos.redhat.com/jbossqe/eap-tests-transactions.git
> 2. cd eap-tests-transactions
> 3. git checkout tx_propag_crashrec_tests
> 4a. mvn clean verify -Dtest=TxPropagationCrashRecoveryTestCase#prepareHaltClient -Djboss.dist=<path to jboss-as-7.1.3.Final-SNAPSHOT>
> or
> 4b. mvn clean verify -Dtest=TxPropagationCrashRecoveryTestCase#prepareHaltServer -Djboss.dist=<path to jboss-as-7.1.3.Final-SNAPSHOT>
> The logs of prepareHaltClient run attached to this jira.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 17:45:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 30 Oct 2013 17:45:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-758) AdvancedLdapLoginModule
 doesn't isn't mapping nested roles
In-Reply-To: <JIRA.12508503.1382458902000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508503.1382458902000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508503.1382458902000.25037.1383169504175@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/SECURITY-758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825976#comment-12825976 ] 

RH Bugzilla Integration commented on SECURITY-758:
--------------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1017974|https://bugzilla.redhat.com/show_bug.cgi?id=1017974] from MODIFIED to ON_QA
                
> AdvancedLdapLoginModule doesn't isn't mapping nested roles
> ----------------------------------------------------------
>
>                 Key: SECURITY-758
>                 URL: https://issues.jboss.org/browse/SECURITY-758
>             Project: PicketBox 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>    Affects Versions: Negotiation_2_2_5
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: Negotiation_2_2_6
>
>
> The recursive role searching is currently broken, believed to be caused by the introduction of quotes for a previous role searching fix.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 17:45:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 30 Oct 2013 17:45:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-761) Release JBoss Negotiation
	2.2.6
In-Reply-To: <JIRA.12508671.1382608770000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508671.1382608770000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508671.1382608770000.25030.1383169503770@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/SECURITY-761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825972#comment-12825972 ] 

RH Bugzilla Integration commented on SECURITY-761:
--------------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1017974|https://bugzilla.redhat.com/show_bug.cgi?id=1017974] from MODIFIED to ON_QA
                
> Release JBoss Negotiation 2.2.6
> -------------------------------
>
>                 Key: SECURITY-761
>                 URL: https://issues.jboss.org/browse/SECURITY-761
>             Project: PicketBox 
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Negotiation
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: Negotiation_2_2_6
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 17:45:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 30 Oct 2013 17:45:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1094) Use own JSSE Provider for
	http Connector
In-Reply-To: <JIRA.12480379.1354616410000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12480379.1354616410000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12480379.1354616410000.25047.1383169504554@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825979#comment-12825979 ] 

RH Bugzilla Integration commented on WFLY-1094:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 956391|https://bugzilla.redhat.com/show_bug.cgi?id=956391] from MODIFIED to ON_QA
                
> Use own JSSE Provider for http Connector
> ----------------------------------------
>
>                 Key: WFLY-1094
>                 URL: https://issues.jboss.org/browse/WFLY-1094
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Web (JBoss Web)
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Hauke Mehrtens
>            Assignee: Tomaz Cerar
>              Labels: https, jsse, ssl
>             Fix For: 8.0.0.Alpha1
>
>         Attachments: ssl-protocol.patch
>
>
> We are using our own JSSE Provider implementation for TLS to add support for HTTPS with preshared key to one http connector, while the others still use the default JSSE provider.
> In JBoss 5 we added sslProtocol="RFC4279", while RFC4279 is the name of our provider, to one Connector entry in the file server/default/deploy/jbossweb.sar/server.xml. This option is not available in JBoss 7.1 any more and we could not find a way to make one connector use our provider while the others are using the default one.
> To fix this issue for use we used the attached patch. We would like to get this patch into the next version of JBoss, so we do not have to modify the source code by our self any more. This patch was tested with JBoss 7.1.2, but it still applies against the master branch. If we should do any changed to the patch or if you want to get it in an other form please inform us.
> With this patch we are able to specify our JSSE provider like this:
> {code:xml}
> <connector name="httpspsk" protocol="HTTP/1.1" scheme="https" socket-binding="httpspsk" secure="true">
>   <ssl name="ssl" key-alias="intended purpose ssl test from bremen online services" password="123456" certificate-key-file="${jboss.server.config.dir}/governikus_ssl.jks" protocol="ALL" keystore-type="JKS" ssl_protocol="RFC4279"/>
> </connector>
> {code}
> This is related to Red Hat Customer Portal support case 00721624 "Additional JSSE Provider on socket bindings and connectors"

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 17:45:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 30 Oct 2013 17:45:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-74) REMJMX-65 Overzealous
 disabling local authentication
In-Reply-To: <JIRA.12508386.1382374102000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508386.1382374102000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508386.1382374102000.25052.1383169504892@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/REMJMX-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825980#comment-12825980 ] 

RH Bugzilla Integration commented on REMJMX-74:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1021630|https://bugzilla.redhat.com/show_bug.cgi?id=1021630] from MODIFIED to ON_QA
                
> REMJMX-65 Overzealous disabling local authentication
> ----------------------------------------------------
>
>                 Key: REMJMX-74
>                 URL: https://issues.jboss.org/browse/REMJMX-74
>             Project: Remoting JMX
>          Issue Type: Bug
>          Components: Connection
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.2.Final, 2.0.0.CR4
>
>
> REMJMX-65 is overzealous at disabling local authentication, if a username and credential is supplied in the environment then it does make sense to disable local authentication - however the availability of a callback handler is not a sufficient flag to also disable it.
> In the case of the callback handler the user may still only want to be prompted if the other mechanisms fail.
> This issue will remove the disabling of local authentication based on the presence of a callback handler and will instead add a configuration option that can be set on the environment.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 17:45:05 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 30 Oct 2013 17:45:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1458) Allow specifying timeout for
 org.jboss.as.arquillian.container.ManagementClient.isServerInRunningState()
In-Reply-To: <JIRA.12493672.1370454383000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493672.1370454383000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493672.1370454383000.25060.1383169505332@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825985#comment-12825985 ] 

RH Bugzilla Integration commented on WFLY-1458:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1021487|https://bugzilla.redhat.com/show_bug.cgi?id=1021487] from MODIFIED to ON_QA
                
> Allow specifying timeout for org.jboss.as.arquillian.container.ManagementClient.isServerInRunningState()
> --------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1458
>                 URL: https://issues.jboss.org/browse/WFLY-1458
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Test Suite
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Richard Achmatowicz
>            Assignee: Ladislav Thon
>             Fix For: 8.0.0.CR1
>
>         Attachments: thread.dump.txt
>
>
> When deploying a container, Arquillian will use a management client to connect to the deployed container to see if it is in a running state. If the management address and management port are incorrect, the connection to the container hangs indefinitely.
> Please allow configuration of a timeout so that if the connection paramaters are not correct, at least the container deployment will fail with a meaningful error.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 17:45:05 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 30 Oct 2013 17:45:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2278) Deployer can't modify data
 source when datasources set as application resources
In-Reply-To: <JIRA.12502701.1381412857000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502701.1381412857000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502701.1381412857000.25067.1383169505627@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825986#comment-12825986 ] 

RH Bugzilla Integration commented on WFLY-2278:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1017786|https://bugzilla.redhat.com/show_bug.cgi?id=1017786] from MODIFIED to ON_QA
                
> Deployer can't modify data source when datasources set as application resources
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-2278
>                 URL: https://issues.jboss.org/browse/WFLY-2278
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Brian Stansberry
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.CR1
>
>
> When data sources are made application resources, deployer should be able to modify them. This doesn't work, as opposed to e.g. mail sessions. For example:
> {code}
> /core-service=management/access=authorization/constraint=application-classification/type=datasources/classification=data-source:write-attribute(name=configured-application, value=true)
> {"outcome" => "success"}
> [standalone at localhost:9990 /] /subsystem=datasources/data-source=ExampleDS:write-attribute(name=jndi-name, value="java:jboss/datasources/ExampleDS_XXX"){roles=deployer}
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS013456: Unauthorized to execute operation 'write-attribute' for resource '[
>     (\"subsystem\" => \"datasources\"),
>     (\"data-source\" => \"ExampleDS\")
> ]' -- \"JBAS013475: Permission denied\"",
>     "rolled-back" => true
> }
> [standalone at localhost:9990 /] /core-service=management/access=authorization/constraint=application-classification/type=mail/classification=mail-session:write-attribute(name=configured-application, value=true)
> {"outcome" => "success"}
> [standalone at localhost:9990 /] /subsystem=mail/mail-session=java\:jboss\/mail\/Default:write-attribute(name=jndi-name, value="java:jboss/mail/Default_XXX"){roles=deployer} 
> {
>     "outcome" => "success",
>     "response-headers" => {
>         "operation-requires-reload" => true,
>         "process-state" => "reload-required"
>     }
> }
> {code}
> I have a test case for this as a last commit in my branch https://github.com/Ladicek/wildfly/commits/rbac (that is the commit called _RBAC test case for application types_).
> Brian, in case you are not the right assignee, please reassign.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 17:47:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 30 Oct 2013 17:47:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2354) Webservice13 tck failures
 introduced by ejb3 and security change
In-Reply-To: <JIRA.12508431.1382433027000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508431.1382433027000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508431.1382433027000.25070.1383169622365@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825987#comment-12825987 ] 

RH Bugzilla Integration commented on WFLY-2354:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1021543|https://bugzilla.redhat.com/show_bug.cgi?id=1021543] from MODIFIED to ON_QA
                
> Webservice13 tck failures introduced by ejb3 and security change 
> -----------------------------------------------------------------
>
>                 Key: WFLY-2354
>                 URL: https://issues.jboss.org/browse/WFLY-2354
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>
> There 2 tck regression failures under webserivice13 directory in EAP 6.2.0.ER6. 
> IT turns out the change[2] introduced this two failures:
> [1]https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP6/view/TCK6-EAP6/job/tck6-eap6-webservices13/lastCompletedBuild/testReport/unknownTestSuite.0/
> [2][2]https://github.com/jbossas/jboss-eap/commit/72d5cd3f96540519a9747579dd3b85f0f564b64c
> EAP 6.2.0.ER6 sever error message:
> ------------------------------------------------------------------------------
> 18:32:00,338 ERROR [org.jboss.as.ejb3.invocation] (http-myserver.com/127.0.0.1:8080-1) JBAS014134: EJB Invocation failed on component WSEjbSingletonTest for method public java.lang.String com.sun.ts.tests.webservices13.ejb.annotations.WSEjbSingletonTest.HelloBean.bye(java.lang.String): javax.ejb.EJBException: java.lang.IllegalStateException: JBAS014485: EJB WSEjbSingletonTest is enabled for security but doesn't have a security domain set
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:189) [jboss-as-ejb3-7.3.0.Final-redhat-SNAPSHOT.jar:7.3.0.Final-redhat-SNAPSHOT]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 17:47:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 30 Oct 2013 17:47:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2270) Lack of model integrity
 checking regarding role mappings, standard role names and scoped role names.
In-Reply-To: <JIRA.12502541.1381314949000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502541.1381314949000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502541.1381314949000.25074.1383169622497@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825990#comment-12825990 ] 

RH Bugzilla Integration commented on WFLY-2270:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1018738|https://bugzilla.redhat.com/show_bug.cgi?id=1018738] from MODIFIED to ON_QA
                
> Lack of model integrity checking regarding role mappings, standard role names and scoped role names.
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2270
>                 URL: https://issues.jboss.org/browse/WFLY-2270
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Take the following scoped role definition and assignment: -
> {code}
>             <host-scoped-roles>
>                 <role name="master-Monitior" base-role="MONITOR">
>                     <host name="master"/>
>                 </role>
>             </host-scoped-roles>
> {code}
> {code}
>  <role name="master-Monitior" include-all="true"/>
> {code}
> Removal results in the following: -
> {code}
> [domain at localhost:9990 /] ./core-service=management/access=authorization/host-scoped-role=master-Monitior:remove
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "JBAS014749: Operation handler failed: JBAS013470: Unknown role 'MASTER-MONITIOR'"},
>     "rolled-back" => true
> }
> {code}
> Server side this is reported as: -
> {code}
> [Host Controller] 11:24:57,780 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014612: Operation ("remove") failed - address: ([
> [Host Controller]     ("core-service" => "management"),
> [Host Controller]     ("access" => "authorization"),
> [Host Controller]     ("host-scoped-role" => "master-Monitior")
> [Host Controller] ]): java.lang.IllegalArgumentException: JBAS013470: Unknown role 'MASTER-MONITIOR'
> [Host Controller] 	at org.jboss.as.controller.access.rbac.DefaultPermissionFactory.getUserPermissions(DefaultPermissionFactory.java:134) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.access.rbac.DefaultPermissionFactory.getUserPermissions(DefaultPermissionFactory.java:107) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.access.permission.ManagementPermissionAuthorizer.authorize(ManagementPermissionAuthorizer.java:99) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.access.management.DelegatingConfigurableAuthorizer.authorize(DelegatingConfigurableAuthorizer.java:98) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.OperationContextImpl.getBasicAuthorizationResponse(OperationContextImpl.java:1157) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1059) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.OperationContextImpl.readResourceFromRoot(OperationContextImpl.java:542) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationResolver.getServerOperations(ServerOperationResolver.java:232)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.getServerOperations(ServerOperationsResolverHandler.java:149)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.access$000(ServerOperationsResolverHandler.java:58)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler$2.getServerOperations(ServerOperationsResolverHandler.java:113)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.HostControllerExecutionSupport$Factory$DomainOpExecutionSupport.getServerOps(HostControllerExecutionSupport.java:265)
> [Host Controller] 	at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.execute(ServerOperationsResolverHandler.java:124)
> [Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:609) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:487) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:258) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:143) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:205) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:110) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:157) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:153) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_17]
> [Host Controller] 	at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_17]
> [Host Controller] 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [wildfly-protocol-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [wildfly-protocol-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> [Host Controller] 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> [Host Controller] 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> {code}
> At this point I believe that role removal is actually successful, however a subsequent operation is failing as the role previously associated with the user no longer exists.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 17:47:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 30 Oct 2013 17:47:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1740) ManagedSocketBinding class
 Impossible cast from java.net.InetAddress to java.net.InetSocketAddress
In-Reply-To: <JIRA.12497092.1374526330000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497092.1374526330000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497092.1374526330000.25078.1383169622653@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825991#comment-12825991 ] 

RH Bugzilla Integration commented on WFLY-1740:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1017747|https://bugzilla.redhat.com/show_bug.cgi?id=1017747] from MODIFIED to ON_QA
                
> ManagedSocketBinding class Impossible cast from java.net.InetAddress to java.net.InetSocketAddress
> --------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1740
>                 URL: https://issues.jboss.org/browse/WFLY-1740
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Server
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Cheng Fang
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.CR1
>
>
> Reported by FindBugs:
> Impossible cast from java.net.InetAddress to java.net.InetSocketAddress
> Class:
> ManagedSocketBinding (org.jboss.as.network) line 55
> Method:
> getBindAddress (org.jboss.as.network.ManagedSocketBinding.getBindAddress())
> Priority:
> ? ? ?High Confidence Correctness
> ?
> Problem classification:
> Correctness (Bad casts of object references)
> BC_IMPOSSIBLE_CAST (Impossible cast)
> Notes:
> Actual type java.net.InetAddress
> Expected java.net.InetSocketAddress
> Return value of Class.cast(Object)
> FindBadCast2 (BC|NP)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Wed Oct 30 17:47:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 30 Oct 2013 17:47:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1499) Clustering tests
 intermittently fail mainly because they do not clean their deployments
 properly
In-Reply-To: <JIRA.12494046.1370968424000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494046.1370968424000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494046.1370968424000.25083.1383169622852@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825993#comment-12825993 ] 

RH Bugzilla Integration commented on WFLY-1499:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 998371|https://bugzilla.redhat.com/show_bug.cgi?id=998371] from MODIFIED to ON_QA
                
> Clustering tests intermittently fail mainly because they do not clean their deployments properly
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1499
>                 URL: https://issues.jboss.org/browse/WFLY-1499
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Ivo Studensky
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.Alpha4
>
>
> Almost all clustering tests from the testsuite deploys what they need to perform the test, but almost none of those tests do undeploy of their deployments. Then, if the tests are run in an unexpected order (different JVM) or if some of them fail their deployments keeps at servers and often cause a failure of subsequent tests.
> For example {{RemoteStatelessFailoverTestCase(ejb3)}} stops {{CONTAINER-1}} in the middle of a testLoadBalance method and never tries to undeploy DEPLOYMENT_1 from it. So if it hits any failure in the subsequent {{this.establishView(listener, NODES[1]);}} the {{CONTAINER-1}} will never be started up again by RemoteStatelessFailoverTestCase and hence will never be cleaned up by Arquillian which normally undeploys all deployments from the running custom containers on after-class event. And then StatefulFailoverTestCase fails with 
> {noformat}
> org.jboss.as.test.clustering.ViewChangeListenerServlet threw exception:
> java.lang.InterruptedException: Cluster 'ejb' failed to establish view [node-1/ejb] within 15000 ms.  Current view is: [node-0/ejb, node-1/ejb]
> {noformat}
> Another frequent issue with clustering tests is that they blindly deploy the same deployments manytimes which leads to duplicate deploy failures.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 17:47:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 30 Oct 2013 17:47:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2383) resource-adapter id attribute
 has to match ra name otherwise MDB is not deployed
In-Reply-To: <JIRA.12508785.1382695105000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508785.1382695105000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508785.1382695105000.25091.1383169623155@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825996#comment-12825996 ] 

RH Bugzilla Integration commented on WFLY-2383:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1012044|https://bugzilla.redhat.com/show_bug.cgi?id=1012044] from MODIFIED to ON_QA
                
> resource-adapter id attribute has to match ra name otherwise MDB is not deployed
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-2383
>                 URL: https://issues.jboss.org/browse/WFLY-2383
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Stefano Maestri
>            Assignee: Stefano Maestri
>
> The resource-adapter id has to have the same name as the ra archive has. Otherwise the the MDB is not deployed. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 17:47:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 30 Oct 2013 17:47:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2385) Resource adapter recovery
 doesn't allow fallback to security credentials
In-Reply-To: <JIRA.12508796.1382702010000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508796.1382702010000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508796.1382702010000.25097.1383169623397@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825998#comment-12825998 ] 

RH Bugzilla Integration commented on WFLY-2385:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1023446|https://bugzilla.redhat.com/show_bug.cgi?id=1023446] from MODIFIED to ON_QA
                
>  Resource adapter recovery doesn't allow fallback to security credentials
> -------------------------------------------------------------------------
>
>                 Key: WFLY-2385
>                 URL: https://issues.jboss.org/browse/WFLY-2385
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Stefano Maestri
>            Assignee: Stefano Maestri
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 17:47:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 30 Oct 2013 17:47:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2338) When using a JDBC object
 store,
 the RecoveryManager service stop can occur after the datasource is already
 stopped
In-Reply-To: <JIRA.12508208.1382112933000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508208.1382112933000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508208.1382112933000.25101.1383169623553@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12825999#comment-12825999 ] 

RH Bugzilla Integration commented on WFLY-2338:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1020881|https://bugzilla.redhat.com/show_bug.cgi?id=1020881] from MODIFIED to ON_QA
                
> When using a JDBC object store, the RecoveryManager service stop can occur after the datasource is already stopped
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2338
>                 URL: https://issues.jboss.org/browse/WFLY-2338
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Transactions
>            Reporter: Tom Jenkinson
>            Assignee: Stefano Maestri
>         Attachments: 0001-patching-servicename-for-ds-dependency.patch
>
>
> It should be the cause of https://bugzilla.redhat.com/show_bug.cgi?id=1020881
> It has the effects described in the BZ, i.e. can cause warnings or can entirely block the application server from stopping

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 17:47:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 30 Oct 2013 17:47:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2317) Trying to remove a server
 group as a server-group-scoped role leaks information
In-Reply-To: <JIRA.12503235.1381924172000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503235.1381924172000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503235.1381924172000.25105.1383169623733@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12826000#comment-12826000 ] 

RH Bugzilla Integration commented on WFLY-2317:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1019784|https://bugzilla.redhat.com/show_bug.cgi?id=1019784] from MODIFIED to ON_QA
                
> Trying to remove a server group as a server-group-scoped role leaks information
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-2317
>                 URL: https://issues.jboss.org/browse/WFLY-2317
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Brian Stansberry
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.CR1
>
>
> When writing a small test case for WFLY-2190, I stumbled upon a problem: trying to remove an existing server group by a server-group-scoped user that does NOT have permissions to that server group leaks information. On a freshly built WildFly with added {{admin}} user into {{domain/configuration/mgmt-users.properties}}, it can be reproduced like this:
> {code}
> [1] ./bin/domain.sh
> [2] ./bin/jboss-cli.sh -c
>     /core-service=management/access=authorization/server-group-scoped-role=NewRole:add(base-role=administrator, server-groups=[main-server-group])
>     /core-service=management/access=authorization/role-mapping=NewRole:add
>     /core-service=management/access=authorization/role-mapping=NewRole/include=user-admin:add(name=admin, type=user)
>     /core-service=management/access=authorization:write-attribute(name=provider, value=rbac)
>     exit
> [1] ^C
>     ./bin/domain.sh
> [2] ./bin/jboss-cli.sh -c --user=admin --password=XXX
>     /server-group=other-server-group:read-resource
>     /server-group=other-server-group:remove
> {code}
> What does that mean? The {{NewRole}} is scoped to the {{main-server-group}} server group and can't see {{other-server-group}}. When doing {{/server-group=other-server-group:read-resource}}, this is correctly enforced and the output looks like this:
> {code}
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014807: Management resource '[(\"server-group\" => \"other-server-group\")]' not found",
>     "rolled-back" => true
> }
> {code}
> However, trying to do {{/server-group=other-server-group:remove}}, which is only a different operation _on the same resource_, I get a different error message:
> {code}
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "JBAS013456: Unauthorized to execute operation 'remove' for resource '[(\"server-group\" => \"other-server-group\")]' -- \"JBAS013475: Permission denied\""},
>     "rolled-back" => true
> }
> {code}
> I expect the error message to be completely the same as in previous case, not leaking any information that the {{other-server-group}} actually exists.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 17:47:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 30 Oct 2013 17:47:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2394) AccessControlContext and
 management users Subject leaking into thread pool of host controller
 executor.
In-Reply-To: <JIRA.12508901.1382983851000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508901.1382983851000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508901.1382983851000.25109.1383169623881@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12826001#comment-12826001 ] 

RH Bugzilla Integration commented on WFLY-2394:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1024072|https://bugzilla.redhat.com/show_bug.cgi?id=1024072] from MODIFIED to ON_QA
                
> AccessControlContext and management users Subject leaking into thread pool of host controller executor.
> -------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2394
>                 URL: https://issues.jboss.org/browse/WFLY-2394
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 8.0.0.CR1
>
>
> The JBossThreadFactory in use for the executor service is allowing for the AccessControlContext of the thread submitting the Runnable task to the executor to be associated with the Thread created.
> Additional precautions should be taken within the HostController to prevent this association.
> Where a Subject does need to be associated this should be handled manually.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 17:47:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 30 Oct 2013 17:47:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2337) Eliminate additional round
 trip exchange of Subject from host controller to app server or slave host
 controllers.
In-Reply-To: <JIRA.12508207.1382112747000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508207.1382112747000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508207.1382112747000.25116.1383169624125@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12826004#comment-12826004 ] 

RH Bugzilla Integration commented on WFLY-2337:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1022993|https://bugzilla.redhat.com/show_bug.cgi?id=1022993] from MODIFIED to ON_QA
                
> Eliminate additional round trip exchange of Subject from host controller to app server or slave host controllers.
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2337
>                 URL: https://issues.jboss.org/browse/WFLY-2337
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 17:47:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 30 Oct 2013 17:47:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1852) Populate the Subject with the
 required prinicpals for rbac/audit logging earlier
In-Reply-To: <JIRA.12498266.1375974256000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498266.1375974256000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498266.1375974256000.25120.1383169624272@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12826005#comment-12826005 ] 

RH Bugzilla Integration commented on WFLY-1852:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1022993|https://bugzilla.redhat.com/show_bug.cgi?id=1022993] from MODIFIED to ON_QA
                
> Populate the Subject with the required prinicpals for rbac/audit logging earlier
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-1852
>                 URL: https://issues.jboss.org/browse/WFLY-1852
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: Kabir Khan
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> At the moment these are added in a number of places, see TODO comments with this JIRA id.
> I also commented your concern a few lines down for https://github.com/wildfly/wildfly/pull/4889#commitcomment-3808535: "Do we need to use the Remoting version of this Principal - not sure if a new Principal may be better that is used both for web and for Remoting."

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 17:47:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 30 Oct 2013 17:47:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2044) Rework Subject propagation to
 avoid marshaling.
In-Reply-To: <JIRA.12500441.1378828999000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500441.1378828999000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500441.1378828999000.25123.1383169624405@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12826006#comment-12826006 ] 

RH Bugzilla Integration commented on WFLY-2044:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1022993|https://bugzilla.redhat.com/show_bug.cgi?id=1022993] from MODIFIED to ON_QA
                
> Rework Subject propagation to avoid marshaling.
> -----------------------------------------------
>
>                 Key: WFLY-2044
>                 URL: https://issues.jboss.org/browse/WFLY-2044
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Rework Subject propagation to avoid marshalling - i.e. describe the contents of the Subject within the protocol and allow it to be reconstructed on the far side.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 17:47:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 30 Oct 2013 17:47:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2305) add-user utility reports "No
 java.io.Console available to interact with user." when used silently with
 su and piped to a file.
In-Reply-To: <JIRA.12503071.1381836778000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503071.1381836778000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503071.1381836778000.25129.1383169624629@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12826009#comment-12826009 ] 

RH Bugzilla Integration commented on WFLY-2305:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1019264|https://bugzilla.redhat.com/show_bug.cgi?id=1019264] from MODIFIED to ON_QA
                
> add-user utility reports "No java.io.Console available to interact with user." when used silently with su and piped to a file.
> ------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2305
>                 URL: https://issues.jboss.org/browse/WFLY-2305
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>    Affects Versions: 8.0.0.Beta1
>         Environment: WildFly snapshot of master 15-oct-2013
>            Reporter: Tom Fonteyne
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Running add-user.sh in silent mode and redirecting the output to a file results in an exception:
> Exception in thread "main" java.lang.IllegalStateException: JBAS015232: No java.io.Console available to interact with user.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 17:47:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 30 Oct 2013 17:47:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2296) Patched state is missing the
 updated resulting version
In-Reply-To: <JIRA.12502946.1381752036000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502946.1381752036000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502946.1381752036000.25132.1383169624742@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12826010#comment-12826010 ] 

RH Bugzilla Integration commented on WFLY-2296:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1018181|https://bugzilla.redhat.com/show_bug.cgi?id=1018181] from MODIFIED to ON_QA
                
> Patched state is missing the updated resulting version
> ------------------------------------------------------
>
>                 Key: WFLY-2296
>                 URL: https://issues.jboss.org/browse/WFLY-2296
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Patching
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Emanuel Muckenhuber
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 17:47:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 30 Oct 2013 17:47:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2373) patching resource does not
 get registered on slave hosts
In-Reply-To: <JIRA.12508684.1382615298000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508684.1382615298000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508684.1382615298000.25135.1383169624855@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12826011#comment-12826011 ] 

RH Bugzilla Integration commented on WFLY-2373:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1022973|https://bugzilla.redhat.com/show_bug.cgi?id=1022973] from MODIFIED to ON_QA
                
> patching resource does not get registered on slave hosts
> --------------------------------------------------------
>
>                 Key: WFLY-2373
>                 URL: https://issues.jboss.org/browse/WFLY-2373
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Patching
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Emanuel Muckenhuber
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 17:57:01 2013
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Wed, 30 Oct 2013 17:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1725) JGroups testsuite output not
 processed correctly on Windows
In-Reply-To: <JIRA.12509140.1383170133959@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509140.1383170133959@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509140.1383170133959.25141.1383170221937@jira02.app.mwc.hst.phx2.redhat.com>

Richard Achmatowicz created JGRP-1725:
-----------------------------------------

             Summary: JGroups testsuite output not processed correctly on Windows
                 Key: JGRP-1725
                 URL: https://issues.jboss.org/browse/JGRP-1725
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 3.5
         Environment: Windows
            Reporter: Richard Achmatowicz
            Assignee: Bela Ban
             Fix For: 3.5


When running the testsuite on Windows, testsuite output ends up on the console and not in the test case reports.



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 18:03:01 2013
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Wed, 30 Oct 2013 18:03:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1725) JGroups testsuite output not
 processed correctly on Windows
In-Reply-To: <JIRA.12509140.1383170133000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509140.1383170133000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509140.1383170133000.25144.1383170581959@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12826014#comment-12826014 ] 

Richard Achmatowicz commented on JGRP-1725:
-------------------------------------------

The problem here is in JUnitXMLReporter. 

The classes MyOutput which are used to redirect System.out and System.err from test cases into per-test case files needs to initialise itself with a temporary file name. The file name hard-coded in the class is "/tmp/tmp.txt". On non-Windows hosts, this file name works fine; on Windows hosts, it causes the initialization of the redirection to fail with a FileNotFoundException:

{noformat}
    public void onStart(ITestContext context) {
        output_dir=context.getOutputDirectory();
        // Uncomment to delete dir created by previous run of this testsuite
        File dir=new File(output_dir);
        if(dir.exists())
            deleteContents(dir);

        try {
            System.setOut(new MyOutput(1));
            System.setErr(new MyOutput(2));
        }
        catch(FileNotFoundException e) {
          // EXCEPTION OCCURS HERE
        }
    }
{noformat}
 
Because the output redirection failed, all output goes to the console.
 
                
> JGroups testsuite output not processed correctly on Windows
> -----------------------------------------------------------
>
>                 Key: JGRP-1725
>                 URL: https://issues.jboss.org/browse/JGRP-1725
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.5
>         Environment: Windows
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> When running the testsuite on Windows, testsuite output ends up on the console and not in the test case reports.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 18:05:01 2013
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Wed, 30 Oct 2013 18:05:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1725) JGroups testsuite output not
 processed correctly on Windows
In-Reply-To: <JIRA.12509140.1383170133000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509140.1383170133000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509140.1383170133000.25146.1383170701953@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12826015#comment-12826015 ] 

Richard Achmatowicz commented on JGRP-1725:
-------------------------------------------

For a fix, I added some static code to the MyObject class which will choose a temporary filename which matches the OS type:

{noformat}
    protected static class MyOutput extends PrintStream {
        private static final String TMPFILE_NAME;
        static {
            if (Util.checkForWindows()) {
                TMPFILE_NAME = System.getProperty("java.io.tmpdir") + "\\" + "tmp.txt";
            } else {
                TMPFILE_NAME = System.getProperty("java.io.tmpdir") + "/" + "tmp.txt";
            }
        }
        final int type;

        public MyOutput(int type) throws FileNotFoundException {
            super(TMPFILE_NAME); // dummy name
            this.type=type;
            if(type != 1 && type != 2)
                throw new IllegalArgumentException("index has to be 1 or 2");
        }
       ...
{noformat}

                
> JGroups testsuite output not processed correctly on Windows
> -----------------------------------------------------------
>
>                 Key: JGRP-1725
>                 URL: https://issues.jboss.org/browse/JGRP-1725
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.5
>         Environment: Windows
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> When running the testsuite on Windows, testsuite output ends up on the console and not in the test case reports.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 18:33:01 2013
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Wed, 30 Oct 2013 18:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2419) SFSBs should be distributable
 by default in HA profiles
In-Reply-To: <JIRA.12509142.1383172327529@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509142.1383172327529@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509142.1383172327529.25151.1383172381991@jira02.app.mwc.hst.phx2.redhat.com>

Paul Ferraro created WFLY-2419:
----------------------------------

             Summary: SFSBs should be distributable by default in HA profiles
                 Key: WFLY-2419
                 URL: https://issues.jboss.org/browse/WFLY-2419
             Project: WildFly
          Issue Type: Enhancement
      Security Level: Public (Everyone can see)
          Components: Clustering
    Affects Versions: 8.0.0.Beta1
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro
             Fix For: 8.0.0.CR1


The @Clustered annotation currently has 2 orthogonal meanings:
1. If applied to a @Stateful EJB, then a specific cache will be used (as defined by the EJB subsystem)
2. If applied to a @Stateless or @Stateful EJB, remote EJB clients will have a dynamic view of the EJB's topology.

This is confusing.

If I want to replicate the state of my SFSB, I have to annotate my bean with @Clustered. However, this annotation could be ignored if my server profile does not support it. So, effectively, my server profile ultimately dictates whether or not my SFSB's state gets replicated. If that's the case, why bother with requiring @Clustered at all?

Additionally, EE7 adds spec support for specifying whether a given SFSB is passivation-capable. By default, the spec dictates that SFSBs are passivation capable. According to Section 4.6.5 of the EJB 3.2 specification (the section that describes passivationCapable):
"Note: application server vendors may use passivation as a technique to provide high availability of stateful session beans by replicating their state from one JVM instance to another across which the container is distributed."
Given this, it only seems natural that a server that provides high-availability to a SFSB that is passivation capable by default would have its state replicated by default.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 19:06:02 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 30 Oct 2013 19:06:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2420) Domain controller fails to
 restart due to an inconsistent rollback of a redeploy
In-Reply-To: <JIRA.12509143.1383174292062@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509143.1383174292062@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509143.1383174292062.25171.1383174362224@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-2420:
--------------------------------------

             Summary: Domain controller fails to restart due to an inconsistent rollback of a redeploy
                 Key: WFLY-2420
                 URL: https://issues.jboss.org/browse/WFLY-2420
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Domain Management
    Affects Versions: 8.0.0.Beta1
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: 8.0.0.CR1


Osamu Nagano reports:

When you try to redeploy (or deploy with --force option) the same application which has the same contents hash, and a necessary dependency like a datasource beeing injected in the application is lost by some reason, the redeploy operation will delete the contents under $JBOSS_HOME/domain/data/content directory but won't delete entries in domain.xml. Then the domain controller fails to start up because no contents found in the directory. This likely happens when you frequently changes settings during other servers shutting down.

The domain controller fails to restart with the following log messages.
--
12:04:10,623 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("add") failed - address: ([("deployment" => "exampleapp.war")]) - failure description: "JBAS010876: No deployment content with hash c1306bc4855f4ed9914c9616f2b999c5c62a79d3 is available in the deployment content repository for deployment 'exampleapp.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuraiton file and restart."
12:04:10,628 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010933: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details.
--

The domain controller should be independent from such a server specific issue and there should be a way to fix this via CLI or Console, not by a manual editing of domain.xml.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 19:09:01 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 30 Oct 2013 19:09:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2420) Domain controller fails to
 restart due to an inconsistent rollback of a redeploy
In-Reply-To: <JIRA.12509143.1383174292000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509143.1383174292000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509143.1383174292000.25174.1383174541891@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12826019#comment-12826019 ] 

Brian Stansberry commented on WFLY-2420:
----------------------------------------

The issue here is during rollback the DeploymentFullReplace handler isn't checking whether the hash of the "replacement" deployment is the same as the hash of the "replaced" deployment before removing the content from the repo. This is true in standalone as well, although reproducing it would take more effort.

These handlers (plural meaning the server and HC variants) can use a general cleanup too. They've gotten a bit convoluted.
                
> Domain controller fails to restart due to an inconsistent rollback of a redeploy
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-2420
>                 URL: https://issues.jboss.org/browse/WFLY-2420
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> Osamu Nagano reports:
> When you try to redeploy (or deploy with --force option) the same application which has the same contents hash, and a necessary dependency like a datasource beeing injected in the application is lost by some reason, the redeploy operation will delete the contents under $JBOSS_HOME/domain/data/content directory but won't delete entries in domain.xml. Then the domain controller fails to start up because no contents found in the directory. This likely happens when you frequently changes settings during other servers shutting down.
> The domain controller fails to restart with the following log messages.
> --
> 12:04:10,623 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("add") failed - address: ([("deployment" => "exampleapp.war")]) - failure description: "JBAS010876: No deployment content with hash c1306bc4855f4ed9914c9616f2b999c5c62a79d3 is available in the deployment content repository for deployment 'exampleapp.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuraiton file and restart."
> 12:04:10,628 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010933: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> --
> The domain controller should be independent from such a server specific issue and there should be a way to fix this via CLI or Console, not by a manual editing of domain.xml.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Oct 30 21:07:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 30 Oct 2013 21:07:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2352) Domain controller fails to
 restart due to an inconsistent rollback of a redeploy
In-Reply-To: <JIRA.12508413.1382409608000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508413.1382409608000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508413.1382409608000.25202.1383181622170@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12826026#comment-12826026 ] 

RH Bugzilla Integration commented on WFLY-2352:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1021763|https://bugzilla.redhat.com/show_bug.cgi?id=1021763] from NEW to POST
                
> Domain controller fails to restart due to an inconsistent rollback of a redeploy
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-2352
>                 URL: https://issues.jboss.org/browse/WFLY-2352
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Osamu Nagano
>            Assignee: Brian Stansberry
>
> When you try to redeploy (or deploy with --force option) the same application which has the same contents hash, and a necessary dependency like a datasource beeing injected in the application is lost by some reason, the redeploy operation will delete the contents under $JBOSS_HOME/domain/data/content directory but won't delete entries in domain.xml. Then the domain controller fails to start up because no contents found in the directory. This likely happens when you frequently changes settings during other servers shutting down.
> The domain controller fails to restart with the following log messages.
> {code}
> 12:04:10,623 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("add") failed - address: ([("deployment" => "exampleapp.war")]) - failure description: "JBAS010876: No deployment content with hash c1306bc4855f4ed9914c9616f2b999c5c62a79d3 is available in the deployment content repository for deployment 'exampleapp.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuraiton file and restart."
> 12:04:10,628 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010933: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> {code}
> The domain controller should be independent from such a server specific issue and there should be a way to fix this via CLI or Console, not by a manual editing of domain.xml.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 02:56:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 31 Oct 2013 02:56:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1725) JGroups testsuite output not
 processed correctly on Windows
In-Reply-To: <JIRA.12509140.1383170133000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509140.1383170133000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509140.1383170133000.25220.1383202562015@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1725:
---------------------------

    Priority: Optional  (was: Major)

    
> JGroups testsuite output not processed correctly on Windows
> -----------------------------------------------------------
>
>                 Key: JGRP-1725
>                 URL: https://issues.jboss.org/browse/JGRP-1725
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.5
>         Environment: Windows
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>            Priority: Optional
>             Fix For: 3.5
>
>
> When running the testsuite on Windows, testsuite output ends up on the console and not in the test case reports.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 02:56:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 31 Oct 2013 02:56:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1725) JGroups testsuite output not
 processed correctly on Windows
In-Reply-To: <JIRA.12509140.1383170133000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509140.1383170133000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509140.1383170133000.25223.1383202562168@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12826029#comment-12826029 ] 

Bela Ban commented on JGRP-1725:
--------------------------------

So this issue is fixed then ?
                
> JGroups testsuite output not processed correctly on Windows
> -----------------------------------------------------------
>
>                 Key: JGRP-1725
>                 URL: https://issues.jboss.org/browse/JGRP-1725
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.5
>         Environment: Windows
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>            Priority: Optional
>             Fix For: 3.5
>
>
> When running the testsuite on Windows, testsuite output ends up on the console and not in the test case reports.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 03:57:01 2013
From: jira-events at lists.jboss.org (Jan Martiska (JIRA))
Date: Thu, 31 Oct 2013 03:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2421) PatchInfoUnitTestCase should
 be skipped in case that patching module is not enabled
In-Reply-To: <JIRA.12509154.1383206152835@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509154.1383206152835@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509154.1383206152835.25241.1383206221885@jira02.app.mwc.hst.phx2.redhat.com>

Jan Martiska created WFLY-2421:
----------------------------------

             Summary:  PatchInfoUnitTestCase should be skipped in case that patching module is not enabled
                 Key: WFLY-2421
                 URL: https://issues.jboss.org/browse/WFLY-2421
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Patching
            Reporter: Jan Martiska
            Assignee: Jan Martiska
             Fix For: 8.0.0.CR1


PatchInfoUnitTestCase should be skipped (rather than report a fail) in case that patching module is not enabled. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 03:59:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 31 Oct 2013 03:59:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2421) PatchInfoUnitTestCase should
 be skipped in case that patching module is not enabled
In-Reply-To: <JIRA.12509154.1383206152000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509154.1383206152000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509154.1383206152000.25244.1383206342037@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2421:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1020315

    
>  PatchInfoUnitTestCase should be skipped in case that patching module is not enabled
> ------------------------------------------------------------------------------------
>
>                 Key: WFLY-2421
>                 URL: https://issues.jboss.org/browse/WFLY-2421
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Patching
>            Reporter: Jan Martiska
>            Assignee: Jan Martiska
>             Fix For: 8.0.0.CR1
>
>
> PatchInfoUnitTestCase should be skipped (rather than report a fail) in case that patching module is not enabled. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 04:28:02 2013
From: jira-events at lists.jboss.org (Jan Martiska (JIRA))
Date: Thu, 31 Oct 2013 04:28:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2421) PatchInfoUnitTestCase should
 be skipped in case that patching module is not enabled
In-Reply-To: <JIRA.12509154.1383206152000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509154.1383206152000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509154.1383206152000.25281.1383208082191@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12826039#comment-12826039 ] 

Jan Martiska commented on WFLY-2421:
------------------------------------

https://github.com/wildfly/wildfly/pull/5386
                
>  PatchInfoUnitTestCase should be skipped in case that patching module is not enabled
> ------------------------------------------------------------------------------------
>
>                 Key: WFLY-2421
>                 URL: https://issues.jboss.org/browse/WFLY-2421
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Patching
>            Reporter: Jan Martiska
>            Assignee: Jan Martiska
>             Fix For: 8.0.0.CR1
>
>
> PatchInfoUnitTestCase should be skipped (rather than report a fail) in case that patching module is not enabled. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 04:28:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 31 Oct 2013 04:28:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2421) PatchInfoUnitTestCase should
 be skipped in case that patching module is not enabled
In-Reply-To: <JIRA.12509154.1383206152000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509154.1383206152000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509154.1383206152000.25298.1383208083188@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12826041#comment-12826041 ] 

RH Bugzilla Integration commented on WFLY-2421:
-----------------------------------------------

Jan Martiska <jmartisk at redhat.com> changed the Status of [bug 1020315|https://bugzilla.redhat.com/show_bug.cgi?id=1020315] from ASSIGNED to POST
                
>  PatchInfoUnitTestCase should be skipped in case that patching module is not enabled
> ------------------------------------------------------------------------------------
>
>                 Key: WFLY-2421
>                 URL: https://issues.jboss.org/browse/WFLY-2421
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Patching
>            Reporter: Jan Martiska
>            Assignee: Jan Martiska
>             Fix For: 8.0.0.CR1
>
>
> PatchInfoUnitTestCase should be skipped (rather than report a fail) in case that patching module is not enabled. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 05:03:02 2013
From: jira-events at lists.jboss.org (Wolf-Dieter Fink (JIRA))
Date: Thu, 31 Oct 2013 05:03:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2422) Simplify the remote-outbound
	connections
In-Reply-To: <JIRA.12509159.1383210125892@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509159.1383210125892@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509159.1383210125892.25357.1383210182158@jira02.app.mwc.hst.phx2.redhat.com>

Wolf-Dieter Fink created WFLY-2422:
--------------------------------------

             Summary: Simplify the remote-outbound connections
                 Key: WFLY-2422
                 URL: https://issues.jboss.org/browse/WFLY-2422
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: EJB, Remoting
    Affects Versions: 8.0.0.Beta1
            Reporter: Wolf-Dieter Fink
            Assignee: David Lloyd


At the moment the application need to reference each outbound connection with a remote-ejb-receiver element in the jboss-ejb-client.xml.
But from an application perspective it is not relevant whether the server environment provide one or many receivers or whether the ejb-receiver is a cluster.
It should be possible to add many outbound-socket-binding-ref elements and related properties to the remote-outbound-connection element of the server configuration.
In this case it is possible to keep the application deployment independent from the server environment.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 05:03:02 2013
From: jira-events at lists.jboss.org (Jari Juslin (JIRA))
Date: Thu, 31 Oct 2013 05:03:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2267) Persisting a new entity bean
 with certain patterns fails to ARJUNA016082 on flush stage.
In-Reply-To: <JIRA.12502535.1381312028000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502535.1381312028000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502535.1381312028000.25360.1383210182307@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12826048#comment-12826048 ] 

Jari Juslin commented on WFLY-2267:
-----------------------------------

Yes, I changed the setting from default (NON_XA) to FULL_XA.

We have several databases and thus datasources configured and used by the same application and the datasources are in XA mode. Thus I assumed I need to turn the Infinispan, too, to XA mode.

                
> Persisting a new entity bean with certain patterns fails to ARJUNA016082 on flush stage.
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-2267
>                 URL: https://issues.jboss.org/browse/WFLY-2267
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Alpha4, 8.0.0.Beta1
>         Environment: Ubuntu Linux 13.04, JDK 1.7.0u40 64-bit.
>            Reporter: Jari Juslin
>            Assignee: Scott Marlow
>         Attachments: infinispan_bug_repro.zip, infinispan_bug_repro2.zip
>
>
> Persisting a new entity inside a CMT and then exiting the transactional method throws ARJUNA016082 in certain cases.
> I have extracted two cases where the bug manifests.
> 1) Creating a new entity bean and then changing one field after the persist call.
> 2) Creating a new entity bean that has another entity linked to it, and the newly created entity is on the blind side of the relationship.
> Here is the RESTeasy service and the entity bean needed to replicate this (also packaged to the attached test case):
> package bugrepro2;
> import javax.ejb.LocalBean;
> import javax.ejb.Stateless;
> import javax.persistence.EntityManager;
> import javax.persistence.PersistenceContext;
> import javax.ws.rs.POST;
> import javax.ws.rs.Path;
> /**
>  * @author Jari Juslin, zds at ecolane.com
>  */
> @Stateless
> @LocalBean
> @Path("/bug_repro2")
> public class BugRepro2Rest {
>     @PersistenceContext(unitName = "persistence_context2")
>     protected EntityManager entityManager;
>     
>     @POST
>     public String manifestArjunaBug() {
>         BugReproEntity entry = new BugReproEntity();
>         entityManager.persist(entry);
>         
>         entry.setHasChanges(true);
>         
>         return "Success\n";
>     }
> }
> package bugrepro2;
> import javax.persistence.Column;
> import javax.persistence.Entity;
> import javax.persistence.GeneratedValue;
> import javax.persistence.GenerationType;
> import javax.persistence.Id;
> import javax.persistence.Table;
> import org.hibernate.annotations.Cache;
> import org.hibernate.annotations.CacheConcurrencyStrategy;
> @Entity()
> @Table(name = "bugrepro_entity")
> @Cache(usage=CacheConcurrencyStrategy.TRANSACTIONAL)
> public class BugReproEntity {
>     private Integer id;
>     private boolean hasChanges;
>     public BugReproEntity() {
>     }
>     @Id
>     @GeneratedValue(strategy=GenerationType.IDENTITY)
>     @Column(name="id")
>     public Integer getId() {
>         return id;
>     }
>     public void setId(Integer id) {
>         this.id = id;
>     }
>     @Column(name="has_changes")
>     public boolean getHasChanges() {
>         return hasChanges;
>     }
>     public void setHasChanges(boolean hasChanges) {
>         this.hasChanges = hasChanges;
>     }
> }
> Infinispan config block on standalone.xml:
>             <cache-container name="hibernate" default-cache="local-query" module="org.hibernate">
>                 <local-cache name="entity">
>                     <transaction mode="FULL_XA"/>
>                     <eviction strategy="LRU" max-entries="10000"/>
>                     <expiration max-idle="100000"/>
>                     <indexing index="LOCAL">
>                         <property name="hibernate.search.default.directory_provider">                                                                                                                                                                                           
>                             ram                                                                                                                                                                                                                                                 
>                         </property>
>                     </indexing>
>                 </local-cache>
> ...
>             </cache-container>
> The resulting exception:
> 2013-10-09 12:44:07,362 WARN  [org.infinispan.transaction.TransactionTable] (default task-31:) ISPN000101: Failed synchronization registration: java.lang.IllegalStateException: ARJUNA016082: Synchronizations are not allowed! Transaction status isActionStatus.RUNNING
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronizationImple(TransactionImple.java:379)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronization(TransactionImple.java:356)
> 	at org.infinispan.transaction.TransactionTable.enlist(TransactionTable.java:196)
> 	at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:269)
> 	at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:231)
> 	at org.infinispan.interceptors.TxInterceptor.visitPutKeyValueCommand(TxInterceptor.java:177)
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.updateStoreStatistics(CacheMgmtInterceptor.java:148)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:134)
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:106)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:70)
> 	at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32)
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62)
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:321)
> 	at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1298)
> 	at org.infinispan.CacheImpl.putInternal(CacheImpl.java:871)
> 	at org.infinispan.CacheImpl.put(CacheImpl.java:863)
> 	at org.infinispan.DecoratedCache.put(DecoratedCache.java:401)
> 	at org.infinispan.AbstractDelegatingCache.put(AbstractDelegatingCache.java:276)
> 	at org.hibernate.cache.infinispan.access.TransactionalAccessDelegate.update(TransactionalAccessDelegate.java:187) [hibernate-infinispan-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.cache.infinispan.entity.TransactionalAccess.update(TransactionalAccess.java:89) [hibernate-infinispan-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.action.internal.EntityUpdateAction.execute(EntityUpdateAction.java:208) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:377) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:369) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:287) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:340) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:52) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1235) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:405) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:113) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:53) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76)
> 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:273)
> 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:93)
> 	at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1170)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
> 	at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:93) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:437)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72)
> 	at bugrepro2.BugRepro2Rest$$$view31.manifestArjunaBug(Unknown Source) [classes:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_40]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_40]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_40]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_40]
> 	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:280) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:234) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:221) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.4.Final.jar:]
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:59) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:218) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:619) [undertow-core-1.0.0.Beta17.jar:1.0.0.Beta17]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> The datasource definition from standalone.xml:
>                 <datasource jndi-name="java:/BugRepro2DS" pool-name="BugRepro2DS" enabled="true">
>                     <connection-url>jdbc:mysql://localhost:3306/bugrepro2</connection-url>
>                     <driver>mysql</driver>
>                     <security>
>                         <user-name>*******</user-name>
>                         <password>*******</password>
>                     </security>
>                 </datasource>
>                 <drivers>
>                     <driver name="mysql" module="com.mysql">
>                         <xa-datasource-class>com.mysql.jdbc.jdbc2.optional.MysqlXADataSource</xa-datasource-class>
>                     </driver>
>                 </drivers>
> I have reported this also to Infinispan, because I am not sure which party is to blame.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 05:09:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 05:09:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2416) Deployment fails with
 Atmosphere (probable regression from WFLY-2333)
In-Reply-To: <JIRA.12509132.1383158622000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509132.1383158622000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509132.1383158622000.25371.1383210542140@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-2416.
----------------------------------

    Fix Version/s: 8.0.0.CR1
       Resolution: Done


Deployment will not fail now. There is still an issue with the timing of when the web socket endpoints are registered that will be fixed in the next undertow upgrade.
                
> Deployment fails with Atmosphere (probable regression from WFLY-2333)
> ---------------------------------------------------------------------
>
>                 Key: WFLY-2416
>                 URL: https://issues.jboss.org/browse/WFLY-2416
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.CR1
>         Environment: wildfly-8.0.0.Beta2-SNAPSHOT build #762
> Atmosphere-runtime 2.0.3
>            Reporter: John Teller
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.CR1
>
>
> Deploying a WAR file containing atmosphere-runtime jar fails with the following error:
> 14:16:33,411 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.deployment.unit."jboss-as-helloworld.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."jboss-as-helloworld.war"
> .INSTALL: JBAS018733: Failed to process phase INSTALL of deployment "jboss-as-helloworld.war"
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.
> 0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
>         at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS017327: Deployment error processing SCI for jar:
> atmosphere-runtime-2.0.3.jar
>         at org.wildfly.extension.undertow.deployment.ServletContainerInitializerDeploymentProcessor.loadSci(ServletContainerInitializerDeploymentProcessor.java:205)
>         at org.wildfly.extension.undertow.deployment.ServletContainerInitializerDeploymentProcessor.deploy(ServletContainerInitializerDeploymentProcessor.java:128)
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
>         ... 5 more
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS017327: Deployment error processing SCI for jar:
> atmosphere-runtime-2.0.3.jar
>         at org.wildfly.extension.undertow.deployment.ServletContainerInitializerDeploymentProcessor.loadSci(ServletContainerInitializerDeploymentProcessor.java:197)
>         ... 7 more
> Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: 0
>         at java.lang.String.charAt(String.java:658) [rt.jar:1.7.0_17]
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:435) [jboss-modules.jar:1.3.0.Final]
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:431) [jboss-modules.jar:1.3.0.Final]
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:373) [jboss-modules.jar:1.3.0.Final]
>         at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:118) [jboss-modules.jar:1.3.0.Final]
>         at org.wildfly.extension.undertow.deployment.ServletContainerInitializerDeploymentProcessor.loadSci(ServletContainerInitializerDeploymentProcessor.java:190)
>         ... 7 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 05:37:02 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Thu, 31 Oct 2013 05:37:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2341) WildFly-8.0.0.Beta1 throws an
 exception during persistence unit starting on java 1.8.0-ea-b111
In-Reply-To: <JIRA.12508227.1382181208000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508227.1382181208000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508227.1382181208000.25401.1383212222186@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12826060#comment-12826060 ] 

Scott Marlow commented on WFLY-2341:
------------------------------------

https://bugs.openjdk.java.net/browse/JDK-8026394 mentions the bug being fixed in b56 hs25 but I'm not sure what that means exactly (whether the fix is released yet or not. 
                
> WildFly-8.0.0.Beta1 throws an exception during persistence unit starting on java 1.8.0-ea-b111
> ----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2341
>                 URL: https://issues.jboss.org/browse/WFLY-2341
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Beta1
>         Environment: % java -version
> java version "1.8.0-ea"
> Java(TM) SE Runtime Environment (build 1.8.0-ea-b111)
> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b53, mixed mode)
> % uname -a
> Linux irtysh.kostousov.net 3.11.1-200.fc19.x86_64 #1 SMP Sat Sep 14 15:04:51 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
>            Reporter: Denis Kostousov
>            Assignee: Scott Marlow
>            Priority: Critical
>         Attachments: hibernate.HEAD.build.log
>
>
> An exception occurs during application deploying on Wildfly 8.0.0.Beta1 after jdk was changed from 1.8.0-ea-b109 to 1.8.0-ea-b111. On 1.8.0-ea-b109 same code works fine.
> {code}
> 2013-10-19 16:52:49,975 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 52) MSC000001: Failed to start service jboss.persistenceunit."acquiring-gate-ear-0.5-SNAPSHOT.ear/server-0.5-SNAPSHOT.war#AGDirectory": org.jboss.msc.service.StartException in service jboss.persistenceunit."acquiring-gate-ear-0.5-SNAPSHOT.ear/server-0.5-SNAPSHOT.war#AGDirectory": java.lang.IllegalAccessError: tried to access method java.lang.Object.clone()Ljava/lang/Object; from class org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:169) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0-ea]
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:463) [wildfly-security-manager-1.0.0.Beta3.jar:1.0.0.Beta3]
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:178) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0-ea]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0-ea]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.8.0-ea]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: java.lang.IllegalAccessError: tried to access method java.lang.Object.clone()Ljava/lang/Object; from class org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator
> 	at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.cloneAndSetupRevisionInfoRelationMapping(AuditMetadataGenerator.java:140)
> 	at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.addRevisionInfoRelation(AuditMetadataGenerator.java:152)
> 	at org.hibernate.envers.configuration.internal.metadata.IdMetadataGenerator.addId(IdMetadataGenerator.java:210)
> 	at org.hibernate.envers.configuration.internal.metadata.AuditMetadataGenerator.generateFirstPass(AuditMetadataGenerator.java:561)
> 	at org.hibernate.envers.configuration.internal.EntitiesConfigurator.configure(EntitiesConfigurator.java:110)
> 	at org.hibernate.envers.configuration.spi.AuditConfiguration.<init>(AuditConfiguration.java:130)
> 	at org.hibernate.envers.configuration.spi.AuditConfiguration.getFor(AuditConfiguration.java:180)
> 	at org.hibernate.envers.event.spi.EnversIntegrator.integrate(EnversIntegrator.java:76)
> 	at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:310)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1837)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:854)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:847)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:396)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:846)
> 	at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:151) [wildfly-jpa-8.0.0.Beta1.jar:8.0.0.Beta1]
> 	... 8 more
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 05:55:02 2013
From: jira-events at lists.jboss.org (Jozef Hartinger (JIRA))
Date: Thu, 31 Oct 2013 05:55:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2362) Support CDI interception of
 all EE components
In-Reply-To: <JIRA.12508575.1382536533000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508575.1382536533000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508575.1382536533000.25454.1383213302772@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Hartinger updated WFLY-2362:
----------------------------------

    Description: 
As required by EE 7 Table EE.5-1.

||Component||CDI Injection||CDI Interception||
|Servlets|In progress|In progress|
|Filters|In progress|In progress|
|Listeners|In progress|In progress|
|HTTP upgrade handlers|UNDERTOW-118|UNDERTOW-118|
|tag handlers|?|?|
|tag library event listeners|?|?|
|JSF managed classes|?|?|
|JAX-WS|OK|OK|
|JAX-RS|OK|OK|
|WebSocket|In progress|In progress|
|EJB|OK|OK|
|JPA|WFLY-2387|Needs change in Weld|
|ManagedBeans|OK|In progress|
|login callback handler|?|?|





  was:As required by EE 7 Table EE.5-1.


    
> Support CDI interception of all EE components
> ---------------------------------------------
>
>                 Key: WFLY-2362
>                 URL: https://issues.jboss.org/browse/WFLY-2362
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>            Reporter: Jozef Hartinger
>            Assignee: Jozef Hartinger
>            Priority: Blocker
>             Fix For: 8.0.0.CR1
>
>
> As required by EE 7 Table EE.5-1.
> ||Component||CDI Injection||CDI Interception||
> |Servlets|In progress|In progress|
> |Filters|In progress|In progress|
> |Listeners|In progress|In progress|
> |HTTP upgrade handlers|UNDERTOW-118|UNDERTOW-118|
> |tag handlers|?|?|
> |tag library event listeners|?|?|
> |JSF managed classes|?|?|
> |JAX-WS|OK|OK|
> |JAX-RS|OK|OK|
> |WebSocket|In progress|In progress|
> |EJB|OK|OK|
> |JPA|WFLY-2387|Needs change in Weld|
> |ManagedBeans|OK|In progress|
> |login callback handler|?|?|

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 06:28:02 2013
From: jira-events at lists.jboss.org (Jozef Hartinger (JIRA))
Date: Thu, 31 Oct 2013 06:28:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2362) Support CDI interception of
 all EE components
In-Reply-To: <JIRA.12508575.1382536533000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508575.1382536533000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508575.1382536533000.25546.1383215282120@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Hartinger updated WFLY-2362:
----------------------------------

    Description: 
As required by EE 7 Table EE.5-1.

||Component||CDI Injection||CDI Interception||
|Servlets|In progress|In progress|
|Filters|In progress|In progress|
|Listeners|In progress|In progress|
|HTTP upgrade handlers|UNDERTOW-118|UNDERTOW-118|
|tag handlers|?|?|
|tag library event listeners|?|?|
|JSF managed classes|?|?|
|JAX-WS|OK|OK|
|JAX-RS|OK|OK|
|WebSocket|In progress|In progress|
|EJB|OK|OK|
|JPA|WFLY-2387|WELD-1541|
|ManagedBeans|OK|In progress|
|login callback handler|?|?|





  was:
As required by EE 7 Table EE.5-1.

||Component||CDI Injection||CDI Interception||
|Servlets|In progress|In progress|
|Filters|In progress|In progress|
|Listeners|In progress|In progress|
|HTTP upgrade handlers|UNDERTOW-118|UNDERTOW-118|
|tag handlers|?|?|
|tag library event listeners|?|?|
|JSF managed classes|?|?|
|JAX-WS|OK|OK|
|JAX-RS|OK|OK|
|WebSocket|In progress|In progress|
|EJB|OK|OK|
|JPA|WFLY-2387|Needs change in Weld|
|ManagedBeans|OK|In progress|
|login callback handler|?|?|






    
> Support CDI interception of all EE components
> ---------------------------------------------
>
>                 Key: WFLY-2362
>                 URL: https://issues.jboss.org/browse/WFLY-2362
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>            Reporter: Jozef Hartinger
>            Assignee: Jozef Hartinger
>            Priority: Blocker
>             Fix For: 8.0.0.CR1
>
>
> As required by EE 7 Table EE.5-1.
> ||Component||CDI Injection||CDI Interception||
> |Servlets|In progress|In progress|
> |Filters|In progress|In progress|
> |Listeners|In progress|In progress|
> |HTTP upgrade handlers|UNDERTOW-118|UNDERTOW-118|
> |tag handlers|?|?|
> |tag library event listeners|?|?|
> |JSF managed classes|?|?|
> |JAX-WS|OK|OK|
> |JAX-RS|OK|OK|
> |WebSocket|In progress|In progress|
> |EJB|OK|OK|
> |JPA|WFLY-2387|WELD-1541|
> |ManagedBeans|OK|In progress|
> |login callback handler|?|?|

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 06:30:02 2013
From: jira-events at lists.jboss.org (Jozef Hartinger (JIRA))
Date: Thu, 31 Oct 2013 06:30:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2362) Support CDI interception of
 all EE components
In-Reply-To: <JIRA.12508575.1382536533000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508575.1382536533000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508575.1382536533000.25559.1383215402444@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Hartinger updated WFLY-2362:
----------------------------------

    Description: 
As required by EE 7 Table EE.5-1.

||Component||CDI Injection||CDI Interception||
|Servlets|WFLY-2375|WFLY-2375|
|Filters|WFLY-2375|WFLY-2375|
|Listeners|WFLY-2375|WFLY-2375|
|HTTP upgrade handlers|UNDERTOW-118|UNDERTOW-118|
|tag handlers|?|?|
|tag library event listeners|?|?|
|JSF managed classes|?|?|
|JAX-WS|OK|OK|
|JAX-RS|OK|OK|
|WebSocket|WFLY-2375|WFLY-2375|
|EJB|OK|OK|
|JPA|WFLY-2387|WELD-1541|
|ManagedBeans|OK|In progress|
|login callback handler|?|?|





  was:
As required by EE 7 Table EE.5-1.

||Component||CDI Injection||CDI Interception||
|Servlets|In progress|In progress|
|Filters|In progress|In progress|
|Listeners|In progress|In progress|
|HTTP upgrade handlers|UNDERTOW-118|UNDERTOW-118|
|tag handlers|?|?|
|tag library event listeners|?|?|
|JSF managed classes|?|?|
|JAX-WS|OK|OK|
|JAX-RS|OK|OK|
|WebSocket|In progress|In progress|
|EJB|OK|OK|
|JPA|WFLY-2387|WELD-1541|
|ManagedBeans|OK|In progress|
|login callback handler|?|?|






    
> Support CDI interception of all EE components
> ---------------------------------------------
>
>                 Key: WFLY-2362
>                 URL: https://issues.jboss.org/browse/WFLY-2362
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>            Reporter: Jozef Hartinger
>            Assignee: Jozef Hartinger
>            Priority: Blocker
>             Fix For: 8.0.0.CR1
>
>
> As required by EE 7 Table EE.5-1.
> ||Component||CDI Injection||CDI Interception||
> |Servlets|WFLY-2375|WFLY-2375|
> |Filters|WFLY-2375|WFLY-2375|
> |Listeners|WFLY-2375|WFLY-2375|
> |HTTP upgrade handlers|UNDERTOW-118|UNDERTOW-118|
> |tag handlers|?|?|
> |tag library event listeners|?|?|
> |JSF managed classes|?|?|
> |JAX-WS|OK|OK|
> |JAX-RS|OK|OK|
> |WebSocket|WFLY-2375|WFLY-2375|
> |EJB|OK|OK|
> |JPA|WFLY-2387|WELD-1541|
> |ManagedBeans|OK|In progress|
> |login callback handler|?|?|

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 06:48:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 31 Oct 2013 06:48:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1717) Bundling reduces performance
 in scenario mimicking Inifinispan
In-Reply-To: <JIRA.12503239.1381926401000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503239.1381926401000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503239.1381926401000.25608.1383216482147@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12826099#comment-12826099 ] 

Bela Ban commented on JGRP-1717:
--------------------------------

Tests on my home cluster (4 boxes) showed (10 senders, 100'000 msgs):
- Bundling on: ca. 12'000 msgs/sec/node
- Bundling off (DONT_BUNDLE): ca. 17'000 msgs/sec !

I'll investigate whether parsing of message batching needs to be done in a separate thread pool, similar to JGRP-1716. 
                
> Bundling reduces performance in scenario mimicking Inifinispan
> --------------------------------------------------------------
>
>                 Key: JGRP-1717
>                 URL: https://issues.jboss.org/browse/JGRP-1717
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.3
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>         Attachments: benchmark-jgroups.xml, jgroups-udp.pdf, jgroups-udp.xml
>
>
> In Radargun benchmark of JGroups mimicking the behaviour of Infinispan we can see that performance with bundling on actually reduces the performance.
> See attached configurations and results.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 07:32:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 31 Oct 2013 07:32:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1717) Bundling reduces performance
 in scenario mimicking Inifinispan
In-Reply-To: <JIRA.12503239.1381926401000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503239.1381926401000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503239.1381926401000.25654.1383219122057@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12826105#comment-12826105 ] 

Bela Ban commented on JGRP-1717:
--------------------------------

Adding a separate thread pool for parsing of message batches didn't help: performance was exactly the same as above ! Plus, performance of running 4 nodes on the same box dropped, possibly due to increased thread context switching.
                
> Bundling reduces performance in scenario mimicking Inifinispan
> --------------------------------------------------------------
>
>                 Key: JGRP-1717
>                 URL: https://issues.jboss.org/browse/JGRP-1717
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.3
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>         Attachments: benchmark-jgroups.xml, jgroups-udp.pdf, jgroups-udp.xml
>
>
> In Radargun benchmark of JGroups mimicking the behaviour of Infinispan we can see that performance with bundling on actually reduces the performance.
> See attached configurations and results.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 07:54:02 2013
From: jira-events at lists.jboss.org (Jan Martiska (JIRA))
Date: Thu, 31 Oct 2013 07:54:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2421) PatchInfoUnitTestCase should
 be skipped in case that patching module is not enabled
In-Reply-To: <JIRA.12509154.1383206152000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509154.1383206152000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509154.1383206152000.25724.1383220442032@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Martiska updated WFLY-2421:
-------------------------------

    Comment: was deleted

(was: https://github.com/wildfly/wildfly/pull/5386)

    
>  PatchInfoUnitTestCase should be skipped in case that patching module is not enabled
> ------------------------------------------------------------------------------------
>
>                 Key: WFLY-2421
>                 URL: https://issues.jboss.org/browse/WFLY-2421
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Patching
>            Reporter: Jan Martiska
>            Assignee: Jan Martiska
>             Fix For: 8.0.0.CR1
>
>
> PatchInfoUnitTestCase should be skipped (rather than report a fail) in case that patching module is not enabled. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 08:00:05 2013
From: jira-events at lists.jboss.org (Jozef Hartinger (JIRA))
Date: Thu, 31 Oct 2013 08:00:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2362) Support CDI interception of
 all EE components
In-Reply-To: <JIRA.12508575.1382536533000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508575.1382536533000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508575.1382536533000.25747.1383220805449@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Hartinger updated WFLY-2362:
----------------------------------

    Description: 
As required by EE 7 Table EE.5-1.

||Component||CDI Injection||CDI Interception||
|Servlets|WFLY-2375|WFLY-2375|
|Filters|WFLY-2375|WFLY-2375|
|Listeners|WFLY-2375|WFLY-2375|
|HTTP upgrade handlers|UNDERTOW-118|UNDERTOW-118|
|tag handlers|?|?|
|tag library event listeners|?|?|
|JSF managed classes|?|?|
|JAX-WS|OK|OK|
|JAX-RS|OK|OK|
|WebSocket|WFLY-2375|WFLY-2375|
|EJB|OK|OK|
|JPA|WFLY-2387|WELD-1541|
|ManagedBeans|OK|https://github.com/wildfly/wildfly/pull/5388|
|login callback handler|?|?|





  was:
As required by EE 7 Table EE.5-1.

||Component||CDI Injection||CDI Interception||
|Servlets|WFLY-2375|WFLY-2375|
|Filters|WFLY-2375|WFLY-2375|
|Listeners|WFLY-2375|WFLY-2375|
|HTTP upgrade handlers|UNDERTOW-118|UNDERTOW-118|
|tag handlers|?|?|
|tag library event listeners|?|?|
|JSF managed classes|?|?|
|JAX-WS|OK|OK|
|JAX-RS|OK|OK|
|WebSocket|WFLY-2375|WFLY-2375|
|EJB|OK|OK|
|JPA|WFLY-2387|WELD-1541|
|ManagedBeans|OK|In progress|
|login callback handler|?|?|






    
> Support CDI interception of all EE components
> ---------------------------------------------
>
>                 Key: WFLY-2362
>                 URL: https://issues.jboss.org/browse/WFLY-2362
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>            Reporter: Jozef Hartinger
>            Assignee: Jozef Hartinger
>            Priority: Blocker
>             Fix For: 8.0.0.CR1
>
>
> As required by EE 7 Table EE.5-1.
> ||Component||CDI Injection||CDI Interception||
> |Servlets|WFLY-2375|WFLY-2375|
> |Filters|WFLY-2375|WFLY-2375|
> |Listeners|WFLY-2375|WFLY-2375|
> |HTTP upgrade handlers|UNDERTOW-118|UNDERTOW-118|
> |tag handlers|?|?|
> |tag library event listeners|?|?|
> |JSF managed classes|?|?|
> |JAX-WS|OK|OK|
> |JAX-RS|OK|OK|
> |WebSocket|WFLY-2375|WFLY-2375|
> |EJB|OK|OK|
> |JPA|WFLY-2387|WELD-1541|
> |ManagedBeans|OK|https://github.com/wildfly/wildfly/pull/5388|
> |login callback handler|?|?|

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 08:28:01 2013
From: jira-events at lists.jboss.org (Eduardo Martins (JIRA))
Date: Thu, 31 Oct 2013 08:28:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2423) LookupInjectionSource
 incorrect handling of non java: names
In-Reply-To: <JIRA.12509191.1383222455996@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509191.1383222455996@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509191.1383222455996.25806.1383222481906@jira02.app.mwc.hst.phx2.redhat.com>

Eduardo Martins created WFLY-2423:
-------------------------------------

             Summary: LookupInjectionSource incorrect handling of non java: names
                 Key: WFLY-2423
                 URL: https://issues.jboss.org/browse/WFLY-2423
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: EE
            Reporter: Eduardo Martins
            Assignee: Eduardo Martins


LookupInjectionSource assumes the source jndi name has scheme java:, which results in no support for other schemes such as ldap:.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 09:15:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 31 Oct 2013 09:15:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2338) When using a JDBC object
 store,
 the RecoveryManager service stop can occur after the datasource is already
 stopped
In-Reply-To: <JIRA.12508208.1382112933000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508208.1382112933000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508208.1382112933000.25902.1383225304186@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12826145#comment-12826145 ] 

RH Bugzilla Integration commented on WFLY-2338:
-----------------------------------------------

Ondrej Chaloupka <ochaloup at redhat.com> changed the Status of [bug 1020881|https://bugzilla.redhat.com/show_bug.cgi?id=1020881] from ON_QA to VERIFIED
                
> When using a JDBC object store, the RecoveryManager service stop can occur after the datasource is already stopped
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2338
>                 URL: https://issues.jboss.org/browse/WFLY-2338
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Transactions
>            Reporter: Tom Jenkinson
>            Assignee: Stefano Maestri
>         Attachments: 0001-patching-servicename-for-ds-dependency.patch
>
>
> It should be the cause of https://bugzilla.redhat.com/show_bug.cgi?id=1020881
> It has the effects described in the BZ, i.e. can cause warnings or can entirely block the application server from stopping

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 09:15:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 31 Oct 2013 09:15:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2338) When using a JDBC object
 store,
 the RecoveryManager service stop can occur after the datasource is already
 stopped
In-Reply-To: <JIRA.12508208.1382112933000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508208.1382112933000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508208.1382112933000.25905.1383225304335@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12826146#comment-12826146 ] 

RH Bugzilla Integration commented on WFLY-2338:
-----------------------------------------------

Ondrej Chaloupka <ochaloup at redhat.com> made a comment on [bug 1020881|https://bugzilla.redhat.com/show_bug.cgi?id=1020881]

Verified 6.2.0.ER7. 
The reload works in my case.
                
> When using a JDBC object store, the RecoveryManager service stop can occur after the datasource is already stopped
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2338
>                 URL: https://issues.jboss.org/browse/WFLY-2338
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Transactions
>            Reporter: Tom Jenkinson
>            Assignee: Stefano Maestri
>         Attachments: 0001-patching-servicename-for-ds-dependency.patch
>
>
> It should be the cause of https://bugzilla.redhat.com/show_bug.cgi?id=1020881
> It has the effects described in the BZ, i.e. can cause warnings or can entirely block the application server from stopping

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 09:31:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 31 Oct 2013 09:31:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1924) An EJB on a WildFly server
 can't call another bean on a second server with remoting and SSL
In-Reply-To: <JIRA.12499177.1377173596000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499177.1377173596000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499177.1377173596000.25988.1383226262224@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-1924:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1025319

    
> An EJB on a WildFly server can't call another bean on a second server with remoting and SSL
> -------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1924
>                 URL: https://issues.jboss.org/browse/WFLY-1924
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB, Remoting, Security
>    Affects Versions: 8.0.0.Alpha4
>         Environment: WildFly 8.0.0.Beta1-SNAPSHOT from Do 22. Aug 2013, 07:48 UTC
> on Linux with Java 1.7.0_25-b15
>            Reporter: Bernd Koecke
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Beta1
>
>
> I configured two WildFly server, one is the service provider (server), the other one the consumer (client). An EJB on the consumer server tries to call an EJB on the provider server and the remoting connection is secured by SSL. But it doesn't work. I can see the negotiation of the cipher suites and then the communication stops. I get a
> {{javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?}}
> on the provider side. A JavaSE client can call the service provider, but only when SSL_SARTTLS is not set. My current setup is:
> subsystem undertow, default-server:
> {code:xml}
> <https-listener name="defaults" socket-binding="https" security-realm="HttpsRealm"/>
> {code}
> subsystem ejb3:
> {code:xml}
> <remote connector-ref="https-remoting-connector" thread-pool-name="default"/>
> {code}
> Output on the service provider side when the communication stops:
> {noformat}
> [stdout] (default I/O-3) Using SSLEngineImpl.
> [stdout] (default I/O-3) Ignoring unavailable cipher suite: ...
> *** 13 lines more ***
> [stdout] (default I/O-3) Allow unsafe renegotiation: false
> [stdout] (default I/O-3) Allow legacy hello messages: true
> [stdout] (default I/O-3) Is initial handshake: true
> [stdout] (default I/O-3) Is secure renegotiation: false
> [stdout] (default I/O-3) default I/O-3, fatal error: 80: problem unwrapping net record
> [stdout] (default I/O-3) javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
> [stdout] (default I/O-3) default I/O-3, SEND TLSv1 ALERT:  fatal, description = internal_error
> [stdout] (default I/O-3) default I/O-3, WRITE: TLSv1 Alert, length = 2
> [stdout] (default I/O-3) default I/O-3, called closeOutbound()
> [stdout] (default I/O-3) default I/O-3, closeOutboundInternal()
> [stdout] (default I/O-3) [Raw write]: length = 7
> [stdout] (default I/O-3) 0000: 15 03 01 00 02 02 50                               ......P
> {noformat}
> WildFly consumer config
> subsystem remoting, outbound connections:
> {code:xml}
> <remote-outbound-connection name="provider-one-connection" outbound-socket-binding-ref="provider-ejb" security-realm="ProviderOneRealm" protocol="https-remoting">
>   <properties>
>     <property name="SASL_POLICY_NOANONYMOUS" value="false"/>
>   </properties>
> </remote-outbound-connection>
> {code}
> The realms contain the key- and truststores and all passwords are configured.
> The reason for the communication problem comes from the following code.
> The service consumer (or client) WildFly has a remote-outbound-connection in the remoting subsystem config which results in an {{org.jboss.as.remoting.RemoteOutboundConnectionService}}. There is a {{connect()}} method which contains the lines:
> {code:java}
> OptionMap.Builder builder = OptionMap.builder();
> builder.addAll(this.connectionCreationOptions);
> builder.set(SASL_POLICY_NOANONYMOUS, Boolean.FALSE);
> builder.set(SASL_POLICY_NOPLAINTEXT, Boolean.FALSE);
> builder.set(Options.SASL_DISALLOWED_MECHANISMS, Sequence.of(JBOSS_LOCAL_USER));
> builder.set(Options.SSL_ENABLED, true);
> builder.set(Options.SSL_STARTTLS, true);
> return endpoint.connect(uri, builder.getMap(), callbackHandler, sslContext);
> {code}
> My configuration comes from {{this.connectionOptions}} and is overwritten by the defaults. The service consumer will open the connection with {{SSL_STARTTLS==true}}.
> The service provider (or server) WildFly uses an https-listener from the undertow subsystem. Which generates an {{org.wildfly.extension.undertow.HttpsListenerService}}. Method {{startListening(XnioWorker worker,...)}} has the following code:
> {code:java}
> protected void startListening(XnioWorker worker, InetSocketAddress socketAddress, ChannelListener<AcceptingChannel<StreamConnection>> acceptListener) throws IOException {
>     SSLContext sslContext = securityRealm.getValue().getSSLContext();
>     Builder builder = OptionMap.builder().addAll(SERVER_OPTIONS);
>     builder.set(UndertowOptions.MAX_ENTITY_SIZE, maxUploadSize);
>     if (securityRealm.getValue().getSupportedAuthenticationMechanisms().contains(AuthMechanism.CLIENT_CERT)) {
>         builder.set(SSL_CLIENT_AUTH_MODE, REQUESTED);
>     }
>     builder.set(Options.USE_DIRECT_BUFFERS,true);
>     OptionMap combined = builder.getMap();
>     XnioSsl xnioSsl = new JsseXnioSsl(worker.getXnio(), combined, sslContext);
>     sslServer = xnioSsl.createSslConnectionServer(worker, socketAddress, (ChannelListener) acceptListener, combined);
>     sslServer.resumeAccepts();
>     UndertowLogger.ROOT_LOGGER.listenerStarted("HTTPS", getName(), socketAddress);
> }
> {code}
> The OptionMap {{combined}} is used for the {{JsseXnioSsl}} and I can't see a way how to add my own configuration options. The result is that {{SSL_STARTTLS}} is undefined and in {{JsseXnioSsl}} has a method {{connectSsl}} which calls {{openSslConnection}}. There is an event handler build which calls:
> {code:java}
> new JsseSslStreamConnection(connection, JsseSslUtils.createSSLEngine(sslContext, optionMap, destination), socketBufferPool, applicationBufferPool, optionMap.get(Options.SSL_STARTTLS, false));
> {code}
> This sets the flag {{startTls}} of the constructor to false and the member variable {{tls}} in {{org.xnio.ssl.JsseSslStreamConnection}} to true. And when I understand it right, will then the consumer start unencrypted and will only switch to TLS when it is told todo so. But the service provider expectes, because of {{tls==true}}, an encrypted connection right from the beginning. And this generates the above error message/exception. I can reproduce this by using a JavaSE client to call the service provider. This works well when I don't set {{SSL_STARTTLS}} on the client side. But when I set it to {{true}} I get the same behavior like when the client is another WildFly instance.
> [~ctomc] said that on the consumer side in the {{connect()}} method the {{builder.addAll(...)}} should be moved to the end after setting the defaults. Thats the reason for this issue.
> With this solution I can switch off {{SSL_STARTTLS}} on the consumer(client) side.
> Another additional possibility could be to make the provider (server) side configurable that the hard coded options can be overwritten. But I don't know if this fits in the original design.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 09:31:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 31 Oct 2013 09:31:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1924) An EJB on a WildFly server
 can't call another bean on a second server with remoting and SSL
In-Reply-To: <JIRA.12499177.1377173596000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499177.1377173596000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499177.1377173596000.25994.1383226262519@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12826158#comment-12826158 ] 

RH Bugzilla Integration commented on WFLY-1924:
-----------------------------------------------

wfink at redhat.com made a comment on [bug 1025319|https://bugzilla.redhat.com/show_bug.cgi?id=1025319]

If the remote-outbound-connection disable SSL or add SSL properties that might fail if there are different SSL related properties are overridden by default ones where it should be vice versa.

The analysis will be difficult as in EAP6 the failure messages are swallowed. They are only visible in org.jboss.as.ejb3 DEBUG mode.
                
> An EJB on a WildFly server can't call another bean on a second server with remoting and SSL
> -------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1924
>                 URL: https://issues.jboss.org/browse/WFLY-1924
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB, Remoting, Security
>    Affects Versions: 8.0.0.Alpha4
>         Environment: WildFly 8.0.0.Beta1-SNAPSHOT from Do 22. Aug 2013, 07:48 UTC
> on Linux with Java 1.7.0_25-b15
>            Reporter: Bernd Koecke
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Beta1
>
>
> I configured two WildFly server, one is the service provider (server), the other one the consumer (client). An EJB on the consumer server tries to call an EJB on the provider server and the remoting connection is secured by SSL. But it doesn't work. I can see the negotiation of the cipher suites and then the communication stops. I get a
> {{javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?}}
> on the provider side. A JavaSE client can call the service provider, but only when SSL_SARTTLS is not set. My current setup is:
> subsystem undertow, default-server:
> {code:xml}
> <https-listener name="defaults" socket-binding="https" security-realm="HttpsRealm"/>
> {code}
> subsystem ejb3:
> {code:xml}
> <remote connector-ref="https-remoting-connector" thread-pool-name="default"/>
> {code}
> Output on the service provider side when the communication stops:
> {noformat}
> [stdout] (default I/O-3) Using SSLEngineImpl.
> [stdout] (default I/O-3) Ignoring unavailable cipher suite: ...
> *** 13 lines more ***
> [stdout] (default I/O-3) Allow unsafe renegotiation: false
> [stdout] (default I/O-3) Allow legacy hello messages: true
> [stdout] (default I/O-3) Is initial handshake: true
> [stdout] (default I/O-3) Is secure renegotiation: false
> [stdout] (default I/O-3) default I/O-3, fatal error: 80: problem unwrapping net record
> [stdout] (default I/O-3) javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
> [stdout] (default I/O-3) default I/O-3, SEND TLSv1 ALERT:  fatal, description = internal_error
> [stdout] (default I/O-3) default I/O-3, WRITE: TLSv1 Alert, length = 2
> [stdout] (default I/O-3) default I/O-3, called closeOutbound()
> [stdout] (default I/O-3) default I/O-3, closeOutboundInternal()
> [stdout] (default I/O-3) [Raw write]: length = 7
> [stdout] (default I/O-3) 0000: 15 03 01 00 02 02 50                               ......P
> {noformat}
> WildFly consumer config
> subsystem remoting, outbound connections:
> {code:xml}
> <remote-outbound-connection name="provider-one-connection" outbound-socket-binding-ref="provider-ejb" security-realm="ProviderOneRealm" protocol="https-remoting">
>   <properties>
>     <property name="SASL_POLICY_NOANONYMOUS" value="false"/>
>   </properties>
> </remote-outbound-connection>
> {code}
> The realms contain the key- and truststores and all passwords are configured.
> The reason for the communication problem comes from the following code.
> The service consumer (or client) WildFly has a remote-outbound-connection in the remoting subsystem config which results in an {{org.jboss.as.remoting.RemoteOutboundConnectionService}}. There is a {{connect()}} method which contains the lines:
> {code:java}
> OptionMap.Builder builder = OptionMap.builder();
> builder.addAll(this.connectionCreationOptions);
> builder.set(SASL_POLICY_NOANONYMOUS, Boolean.FALSE);
> builder.set(SASL_POLICY_NOPLAINTEXT, Boolean.FALSE);
> builder.set(Options.SASL_DISALLOWED_MECHANISMS, Sequence.of(JBOSS_LOCAL_USER));
> builder.set(Options.SSL_ENABLED, true);
> builder.set(Options.SSL_STARTTLS, true);
> return endpoint.connect(uri, builder.getMap(), callbackHandler, sslContext);
> {code}
> My configuration comes from {{this.connectionOptions}} and is overwritten by the defaults. The service consumer will open the connection with {{SSL_STARTTLS==true}}.
> The service provider (or server) WildFly uses an https-listener from the undertow subsystem. Which generates an {{org.wildfly.extension.undertow.HttpsListenerService}}. Method {{startListening(XnioWorker worker,...)}} has the following code:
> {code:java}
> protected void startListening(XnioWorker worker, InetSocketAddress socketAddress, ChannelListener<AcceptingChannel<StreamConnection>> acceptListener) throws IOException {
>     SSLContext sslContext = securityRealm.getValue().getSSLContext();
>     Builder builder = OptionMap.builder().addAll(SERVER_OPTIONS);
>     builder.set(UndertowOptions.MAX_ENTITY_SIZE, maxUploadSize);
>     if (securityRealm.getValue().getSupportedAuthenticationMechanisms().contains(AuthMechanism.CLIENT_CERT)) {
>         builder.set(SSL_CLIENT_AUTH_MODE, REQUESTED);
>     }
>     builder.set(Options.USE_DIRECT_BUFFERS,true);
>     OptionMap combined = builder.getMap();
>     XnioSsl xnioSsl = new JsseXnioSsl(worker.getXnio(), combined, sslContext);
>     sslServer = xnioSsl.createSslConnectionServer(worker, socketAddress, (ChannelListener) acceptListener, combined);
>     sslServer.resumeAccepts();
>     UndertowLogger.ROOT_LOGGER.listenerStarted("HTTPS", getName(), socketAddress);
> }
> {code}
> The OptionMap {{combined}} is used for the {{JsseXnioSsl}} and I can't see a way how to add my own configuration options. The result is that {{SSL_STARTTLS}} is undefined and in {{JsseXnioSsl}} has a method {{connectSsl}} which calls {{openSslConnection}}. There is an event handler build which calls:
> {code:java}
> new JsseSslStreamConnection(connection, JsseSslUtils.createSSLEngine(sslContext, optionMap, destination), socketBufferPool, applicationBufferPool, optionMap.get(Options.SSL_STARTTLS, false));
> {code}
> This sets the flag {{startTls}} of the constructor to false and the member variable {{tls}} in {{org.xnio.ssl.JsseSslStreamConnection}} to true. And when I understand it right, will then the consumer start unencrypted and will only switch to TLS when it is told todo so. But the service provider expectes, because of {{tls==true}}, an encrypted connection right from the beginning. And this generates the above error message/exception. I can reproduce this by using a JavaSE client to call the service provider. This works well when I don't set {{SSL_STARTTLS}} on the client side. But when I set it to {{true}} I get the same behavior like when the client is another WildFly instance.
> [~ctomc] said that on the consumer side in the {{connect()}} method the {{builder.addAll(...)}} should be moved to the end after setting the defaults. Thats the reason for this issue.
> With this solution I can switch off {{SSL_STARTTLS}} on the consumer(client) side.
> Another additional possibility could be to make the provider (server) side configurable that the hard coded options can be overwritten. But I don't know if this fits in the original design.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 10:12:01 2013
From: jira-events at lists.jboss.org (Jozef Hartinger (JIRA))
Date: Thu, 31 Oct 2013 10:12:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2424) Component class registered in
 multiple BDAs
In-Reply-To: <JIRA.12509205.1383228647652@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509205.1383228647652@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509205.1383228647652.26147.1383228721997@jira02.app.mwc.hst.phx2.redhat.com>

Jozef Hartinger created WFLY-2424:
-------------------------------------

             Summary: Component class registered in multiple BDAs
                 Key: WFLY-2424
                 URL: https://issues.jboss.org/browse/WFLY-2424
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: CDI / Weld
            Reporter: Jozef Hartinger
            Assignee: Jozef Hartinger
            Priority: Blocker
             Fix For: 8.0.0.CR1


This is causing ambiguous dependencies in the TCK as there end up multiple CDI managed beans being created for a component class

This is a regression caused by https://github.com/wildfly/wildfly/commit
/49b6dfbcadfc8d0f9a47092834a57a65561b0993

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 10:20:01 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 10:20:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1816)
 StringIndexOutOfBoundsException in JSF web-app after commit for WFLY-476
In-Reply-To: <JIRA.12497905.1375568068000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497905.1375568068000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497905.1375568068000.26166.1383229201973@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-1816.
----------------------------------

    Resolution: Cannot Reproduce Bug


We can't reproduce this, so there is not really any way for us to determine what is going on. If you can make a reproducer feel free to re-open.
                
> StringIndexOutOfBoundsException in JSF web-app after commit for WFLY-476
> ------------------------------------------------------------------------
>
>                 Key: WFLY-1816
>                 URL: https://issues.jboss.org/browse/WFLY-1816
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Frank Langelage
>            Assignee: Stuart Douglas
>
> The commit c1959b31c0f5320d3ee7992e8a545ba497433162 breaks my web-app.
> With
>     git pull && git reset --hard 861a9ceaa80274edaf32f705887f0bb38068b68d
> my web-app works fine.
> But with
>     git pull && git reset --hard c1959b31c0f5320d3ee7992e8a545ba497433162 
> my web-app starts, index.xhtml renders. But when clicking one of the links the navigation fails.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 10:34:02 2013
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 31 Oct 2013 10:34:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2422) Simplify the remote-outbound
	connections
In-Reply-To: <JIRA.12509159.1383210125000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509159.1383210125000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509159.1383210125000.26211.1383230042124@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12826200#comment-12826200 ] 

jaikiran pai commented on WFLY-2422:
------------------------------------

David, to add a bit more context to this, this is the same requirement we discussed where the user application can just point to a logical name of outbound connection(s) group. And that group can have N number of connections which can be dynamically updated via management APIs and the user application doesn't have to be bothered to updated its deployment descriptor to take into account the new nodes that possibly get added.

IMO, this is a valid requirement.

                
> Simplify the remote-outbound connections
> ----------------------------------------
>
>                 Key: WFLY-2422
>                 URL: https://issues.jboss.org/browse/WFLY-2422
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: EJB, Remoting
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Wolf-Dieter Fink
>            Assignee: David Lloyd
>
> At the moment the application need to reference each outbound connection with a remote-ejb-receiver element in the jboss-ejb-client.xml.
> But from an application perspective it is not relevant whether the server environment provide one or many receivers or whether the ejb-receiver is a cluster.
> It should be possible to add many outbound-socket-binding-ref elements and related properties to the remote-outbound-connection element of the server configuration.
> In this case it is possible to keep the application deployment independent from the server environment.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 10:34:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 31 Oct 2013 10:34:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1726) Bundler: send message batch
 of 1 as single message
In-Reply-To: <JIRA.12509209.1383230042149@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509209.1383230042149@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509209.1383230042149.26224.1383230042749@jira02.app.mwc.hst.phx2.redhat.com>

Bela Ban created JGRP-1726:
------------------------------

             Summary: Bundler: send message batch of 1 as single message
                 Key: JGRP-1726
                 URL: https://issues.jboss.org/browse/JGRP-1726
             Project: JGroups
          Issue Type: Enhancement
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 3.5


When the TransferQueueBundler ("new" / default) sends bundled messages, if there is only a single message in the list, the message is still sent as a *batch* (of 1).
Currently, parsing of single messages is done in a separate thread (JGRP-1716) whereas parsing of message batches is done in the thread which received the messages from the socket.
If we therefore send a batch of 1 as a single message, we might get better perf (to be verified).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 10:49:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 10:49:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2281) Exception from lifecycle
 callback interceptor method intercepting a session bean gets suppressed
 without log message
In-Reply-To: <JIRA.12502724.1381429906000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502724.1381429906000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502724.1381429906000.26261.1383230942091@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFLY-2281:
------------------------------------

    Assignee: Jozef Hartinger  (was: Stuart Douglas)


Jozef, can you have a look at this?

The issue title is misleading, the exceptions are not suppressed, but rather it appears that the methods are not run at all, which makes me think it may be a problem with Weld interceptor bindings.

I'm not really sure where the issue might be. 
                
> Exception from lifecycle callback interceptor method intercepting a session bean gets suppressed without log message
> --------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2281
>                 URL: https://issues.jboss.org/browse/WFLY-2281
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld, EJB
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Matus Abaffy
>            Assignee: Jozef Hartinger
>
> From EJB spec., "9.3.3 Exceptions from AroundConstruct, PostConstruct and PreDestroy Lifecycle Callbacks", "Table 11" it follows that the container should log the exception or error thrown by a lifecycle callback interceptor method of a session bean or a message-driven bean.
> The thrown throwable gets suppressed. However, I cannot find any sign of it in the server log (using default settings - debug level).
> I'm not a spec. expert, but I think if the exception is not logged, it should at least not get suppressed. I made some tests that might be of help (available at https://github.com/bafco/wildfly/commits/WFLY-2281) - according to the spec., they probably don't have to pass.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 10:52:02 2013
From: jira-events at lists.jboss.org (Jozef Hartinger (JIRA))
Date: Thu, 31 Oct 2013 10:52:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2281) Exception from lifecycle
 callback interceptor method intercepting a session bean gets suppressed
 without log message
In-Reply-To: <JIRA.12502724.1381429906000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12502724.1381429906000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12502724.1381429906000.26270.1383231122150@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12826205#comment-12826205 ] 

Jozef Hartinger commented on WFLY-2281:
---------------------------------------

OK
                
> Exception from lifecycle callback interceptor method intercepting a session bean gets suppressed without log message
> --------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2281
>                 URL: https://issues.jboss.org/browse/WFLY-2281
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld, EJB
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Matus Abaffy
>            Assignee: Jozef Hartinger
>
> From EJB spec., "9.3.3 Exceptions from AroundConstruct, PostConstruct and PreDestroy Lifecycle Callbacks", "Table 11" it follows that the container should log the exception or error thrown by a lifecycle callback interceptor method of a session bean or a message-driven bean.
> The thrown throwable gets suppressed. However, I cannot find any sign of it in the server log (using default settings - debug level).
> I'm not a spec. expert, but I think if the exception is not logged, it should at least not get suppressed. I made some tests that might be of help (available at https://github.com/bafco/wildfly/commits/WFLY-2281) - according to the spec., they probably don't have to pass.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 10:54:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 10:54:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-795) jboss-ejb-iiop_1_0.xsd has
 both use="required" and default attributes on some elements
In-Reply-To: <JIRA.12482011.1357522084000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12482011.1357522084000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12482011.1357522084000.26275.1383231242847@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas updated WFLY-795:
--------------------------------

    Assignee: Stuart Douglas  (was: jaikiran pai)

    
> jboss-ejb-iiop_1_0.xsd has both use="required" and default attributes on some elements
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-795
>                 URL: https://issues.jboss.org/browse/WFLY-795
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>            Reporter: James Livingston
>            Assignee: Stuart Douglas
>
> In jboss-ejb-iiop_1_0.xsd, the "integrity", "confidentiality", "establish-trust-in-client", and "establish-trust-in-target" attributes on the "iorTransportConfigType" complexType, and the "auth-method", "realm" and "required" attributes on the "iorASContextType" complexType have both use="required" and a default attribute.
> This does not make sense because default values are only applicable to optional attributes. I'm not sure which is correct, but either the attributes should be optional or the default values removed. This problem causes the XSD to not validate.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 10:54:03 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 10:54:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-948) Increase log level when
 informing about missing security domain configuration in
 EJBSecurityViewConfigurator
In-Reply-To: <JIRA.12488299.1364554963000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12488299.1364554963000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488299.1364554963000.26279.1383231243088@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas updated WFLY-948:
--------------------------------

    Assignee: Stuart Douglas  (was: jaikiran pai)

    
> Increase log level when informing about missing security domain configuration in EJBSecurityViewConfigurator
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-948
>                 URL: https://issues.jboss.org/browse/WFLY-948
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>            Reporter: Josef Cacek
>            Assignee: Stuart Douglas
>
> Use WARN log-level for the message about missing security domain for EJBs introduced in https://github.com/jbossas/jboss-as/pull/3164/files (c.f. AS7-5581)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 10:54:03 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 10:54:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1565) Test failure observed in
 EJBClientClusterConfigurationTestCase
In-Reply-To: <JIRA.12494793.1371750050000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494793.1371750050000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494793.1371750050000.26284.1383231243498@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas updated WFLY-1565:
---------------------------------

    Assignee: Stuart Douglas  (was: jaikiran pai)

    
> Test failure observed in EJBClientClusterConfigurationTestCase
> --------------------------------------------------------------
>
>                 Key: WFLY-1565
>                 URL: https://issues.jboss.org/browse/WFLY-1565
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>         Environment: Operating system:  Windows Server 2008 R2, version 6.1
> 3072 MB RAM
> 1 x 1842MHz CPU
>            Reporter: David Lloyd
>            Assignee: Stuart Douglas
>
> The failed test was {{EJBClientClusterConfigurationTestCase.testServerToServerClusterFormation}} with this log:
> {noformat}
> javax.ejb.EJBException: java.lang.IllegalStateException: EJBCLIENT000028: No EJB receiver contexts available in cluster ejb
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:190)
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340)
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:90)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:55)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:305)
>     at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:428)
>     at org.wildfly.security.manager.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:63)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:305)
>     at java.security.AccessController.doPrivileged(Native Method)
>     at org.jboss.invocation.PrivilegedInterceptor.processInvocation(PrivilegedInterceptor.java:65)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>     at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
>     at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:329)
>     at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:70)
>     at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:203)
>     at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
>     at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
>     at java.util.concurrent.FutureTask.run(FutureTask.java:166)
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>     at java.lang.Thread.run(Thread.java:722)
>     at org.jboss.threads.JBossThread.run(JBossThread.java:122)
>     at ...asynchronous invocation...(Unknown Source)
>     at org.jboss.ejb.client.remoting.InvocationExceptionResponseHandler$MethodInvocationExceptionResultProducer.getResult(InvocationExceptionResponseHandler.java:99)
>     at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:272)
>     at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocationResult(EJBObjectInterceptor.java:64)
>     at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:274)
>     at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocationResult(EJBHomeInterceptor.java:88)
>     at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:274)
>     at org.jboss.ejb.client.TransactionInterceptor.handleInvocationResult(TransactionInterceptor.java:46)
>     at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:274)
>     at org.jboss.ejb.client.ReceiverInterceptor.handleInvocationResult(ReceiverInterceptor.java:129)
>     at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:262)
>     at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:437)
>     at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:202)
>     at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181)
>     at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144)
>     at sun.proxy.$Proxy21.getNodeName(Unknown Source)
>     at org.jboss.as.test.manualmode.ejb.client.cluster.EJBClientClusterConfigurationTestCase.testServerToServerClusterFormation(EJBClientClusterConfigurationTestCase.java:160)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(Method.java:601)
>     at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>     at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>     at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>     at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:270)
>     at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(Method.java:601)
>     at org.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.execution.ClientTestExecuter.execute(ClientTestExecuter.java:53)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(Method.java:601)
>     at org.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.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
>     at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(Method.java:601)
>     at org.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.createTestContext(TestContextHandler.java:89)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(Method.java:601)
>     at org.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.createClassContext(TestContextHandler.java:75)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(Method.java:601)
>     at org.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:60)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(Method.java:601)
>     at org.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.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111)
>     at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263)
>     at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226)
>     at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
>     at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
>     at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240)
>     at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>     at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>     at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>     at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>     at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>     at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>     at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>     at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>     at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185)
>     at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
>     at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
>     at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
>     at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>     at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
>     at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234)
>     at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133)
>     at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(Method.java:601)
>     at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188)
>     at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166)
>     at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
>     at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101)
>     at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
> Caused by: java.lang.IllegalStateException: EJBCLIENT000028: No EJB receiver contexts available in cluster ejb
>     at org.jboss.ejb.client.EJBClientContext.requireClusterEJBReceiverContext(EJBClientContext.java:983)
>     at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:84)
>     at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183)
>     at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:253)
>     at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:198)
>     at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181)
>     at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144)
>     at sun.proxy.$Proxy30.getNodeName(Unknown Source)
>     at org.jboss.as.test.manualmode.ejb.client.cluster.NonClusteredStatefulNodeNameEcho.getNodeName(NonClusteredStatefulNodeNameEcho.java:47)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(Method.java:601)
>     at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>     at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>     at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:58)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:156)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>     at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:66)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:273)
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340)
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:90)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:55)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:305)
>     at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:428)
>     at org.wildfly.security.manager.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:63)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:305)
>     at java.security.AccessController.doPrivileged(Native Method)
>     at org.jboss.invocation.PrivilegedInterceptor.processInvocation(PrivilegedInterceptor.java:65)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>     at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
>     at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:329)
>     at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:70)
>     at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:203)
>     at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
>     at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
>     at java.util.concurrent.FutureTask.run(FutureTask.java:166)
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>     at java.lang.Thread.run(Thread.java:722)
>     at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> ------- Stdout: -------
> 17:47:04,420 INFO  [org.xnio] (main) XNIO Version 3.1.0.CR3
> 17:47:04,428 INFO  [org.xnio.nio] (main) XNIO NIO Implementation Version 3.1.0.CR3
> 17:47:05,105 INFO  [org.jboss.remoting] (main) JBoss Remoting version 4.0.0.Beta1
> 17:47:10,668 WARN  [org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector] (main) Could not register a EJB receiver for connection to 127.0.0.1:4447: java.lang.RuntimeException: Operation failed with status WAITING
>     at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:93)
>     at org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:75)
>     at org.jboss.ejb.client.remoting.RemotingConnectionManager.getConnection(RemotingConnectionManager.java:51)
>     at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.setupEJBReceivers(ConfigBasedEJBClientContextSelector.java:130)
>     at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.<init>(ConfigBasedEJBClientContextSelector.java:100)
>     at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.<init>(ConfigBasedEJBClientContextSelector.java:68)
>     at org.jboss.ejb.client.EJBClientContext.<clinit>(EJBClientContext.java:81)
>     at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.<init>(ConfigBasedEJBClientContextSelector.java:85)
>     at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.<init>(ConfigBasedEJBClientContextSelector.java:68)
>     at org.jboss.as.test.manualmode.ejb.client.cluster.EJBClientClusterConfigurationTestCase.setupEJBClientContextSelector(EJBClientClusterConfigurationTestCase.java:197)
>     at org.jboss.as.test.manualmode.ejb.client.cluster.EJBClientClusterConfigurationTestCase.beforeClass(EJBClientClusterConfigurationTestCase.java:95)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(Method.java:601)
>     at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>     at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>     at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>     at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
>     at org.jboss.arquillian.junit.Arquillian$StatementLifecycleExecutor.invoke(Arquillian.java:351)
>     at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.execute(ClientBeforeAfterLifecycleEventExecuter.java:99)
>     at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.on(ClientBeforeAfterLifecycleEventExecuter.java:60)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(Method.java:601)
>     at org.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:75)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(Method.java:601)
>     at org.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:60)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(Method.java:601)
>     at org.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:234)
>     at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133)
>     at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(Method.java:601)
>     at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188)
>     at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166)
>     at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
>     at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101)
>     at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
> 17:47:15,866 WARN  [org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector] (main) Could not register a EJB receiver for connection to 127.0.0.1:4547: java.lang.RuntimeException: Operation failed with status WAITING
>     at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:93)
>     at org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:75)
>     at org.jboss.ejb.client.remoting.RemotingConnectionManager.getConnection(RemotingConnectionManager.java:51)
>     at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.setupEJBReceivers(ConfigBasedEJBClientContextSelector.java:130)
>     at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.<init>(ConfigBasedEJBClientContextSelector.java:100)
>     at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.<init>(ConfigBasedEJBClientContextSelector.java:68)
>     at org.jboss.as.test.manualmode.ejb.client.cluster.EJBClientClusterConfigurationTestCase.setupEJBClientContextSelector(EJBClientClusterConfigurationTestCase.java:197)
>     at org.jboss.as.test.manualmode.ejb.client.cluster.EJBClientClusterConfigurationTestCase.beforeClass(EJBClientClusterConfigurationTestCase.java:95)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(Method.java:601)
>     at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>     at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>     at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>     at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
>     at org.jboss.arquillian.junit.Arquillian$StatementLifecycleExecutor.invoke(Arquillian.java:351)
>     at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.execute(ClientBeforeAfterLifecycleEventExecuter.java:99)
>     at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.on(ClientBeforeAfterLifecycleEventExecuter.java:60)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(Method.java:601)
>     at org.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:75)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(Method.java:601)
>     at org.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:60)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(Method.java:601)
>     at org.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:234)
>     at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133)
>     at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(Method.java:601)
>     at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188)
>     at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166)
>     at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
>     at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101)
>     at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
> 17:47:16,285 INFO  [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual starting of a server instance
> 17:47:17,499 INFO  [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Starting container with: [C:\workspace\Java\jdk1.7.0_13\bin\java, -Xmx512m, -XX:MaxPermSize=256m, -Djboss.dist=C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode/../../../build/target/wildfly-8.0.0.Alpha2-SNAPSHOT, -Djava.net.preferIPv4Stack=true, -Djava.net.preferIPv6Addresses=false, -server, -Dts.timeout.factor=100, -Dnode0=127.0.0.1, -Dnode1=127.0.0.1, -Dmcast=230.0.0.4, -Djbossas.ts.submodule.dir=C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode, -Djbossas.ts.integ.dir=C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode/.., -Djbossas.ts.dir=C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode/../.., -Djbossas.project.dir=C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode/../../.., -Djboss.dist=C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode/../../../build/target/wildfly-8.0.0.Alpha2-SNAPSHOT, -Djboss.inst=C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode/target/jbossas, -Djboss.node.name=default-jbossas, -ea, -Djboss.home.dir=C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode/target/jbossas, -Dorg.jboss.boot.log.file=C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode\target\jbossas\standalone\log\boot.log, -Dlogging.configuration=file:/C:/BuildAgent/work/1943cb9aa6e69362/testsuite/integration/manualmode/target/jbossas/standalone/configuration/logging.properties, -Djboss.bundles.dir=C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode/../../../build/target/wildfly-8.0.0.Alpha2-SNAPSHOT/bundles, -jar, C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode\target\jbossas\jboss-modules.jar, -mp, C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode/../../../build/target/wildfly-8.0.0.Alpha2-SNAPSHOT/modules;C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode/target/modules, org.jboss.as.standalone, -server-config, standalone-ha.xml]
> 17:47:18,354 INFO  [org.jboss.modules] (main) JBoss Modules version 1.2.2.Final
> 17:47:19,196 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.0.Beta1
> 17:47:19,281 INFO  [org.jboss.as] (MSC service thread 1-2) JBAS015899: WildFly 8.0.0.Alpha2-SNAPSHOT "WildFly" starting
> 17:47:23,556 INFO  [org.jboss.as.server] (Controller Boot Thread) JBAS015888: Creating http management service using socket-binding (management-http)
> 17:47:24,017 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 52) JBAS015537: Activating WebServices Extension
> 17:47:24,023 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 51) JBAS017502: Undertow 1.0.0.Alpha20 starting
> 17:47:24,170 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 48) JBAS013171: Activating Security Subsystem
> 17:47:24,195 INFO  [org.xnio] (MSC service thread 1-1) XNIO Version 3.1.0.CR3
> 17:47:24,215 INFO  [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.1.0.CR3
> 17:47:24,240 INFO  [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 4.0.0.Beta1
> 17:47:24,257 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 43) JBAS011800: Activating Naming Subsystem
> 17:47:24,878 INFO  [org.jboss.as.jsf] (ServerService Thread Pool -- 40) JBAS012605: Activated the following JSF Implementations: [main]
> 17:47:24,973 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 37) JBAS010260: Activating JGroups subsystem.
> 17:47:25,012 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 33) JBAS010280: Activating Infinispan subsystem.
> 17:47:25,302 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 51) JBAS017527: Creating file handler for path C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode\target\jbossas/welcome-content
> 17:47:27,063 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 28) JBAS010403: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 17:47:27,623 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 33) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> 17:47:27,629 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 33) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> 17:47:28,617 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017502: Undertow 1.0.0.Alpha20 starting
> 17:47:28,633 INFO  [org.jboss.as.security] (MSC service thread 1-2) JBAS013170: Current PicketBox version=4.0.17.Final
> 17:47:28,643 INFO  [org.jboss.as.naming] (MSC service thread 1-2) JBAS011802: Starting Naming Service
> 17:47:28,650 INFO  [org.jboss.as.connector.logging] (MSC service thread 1-2) JBAS010408: Starting JCA Subsystem (IronJacamar 1.0.17.Final)
> 17:47:28,688 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017525: Started http handler io.undertow.server.handlers.resource.ResourceHandler at 10e6e5f.
> 17:47:29,263 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) JBAS010417: Started Driver service with driver-name = h2
> 17:47:29,296 INFO  [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBoss Web Services - Stack CXF Server 4.2.0.CR1
> 17:47:29,310 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-2) JBAS015012: Started FileSystemDeploymentService for directory C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode\target\jbossas\standalone\deployments
> 17:47:29,310 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-2) JBAS015400: Bound mail session [java:jboss/mail/Default]
> 17:47:29,311 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) Starting server server service: service jboss.undertow.server.default-server
> 17:47:29,314 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) Starting host default-host
> 17:47:29,319 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017528: registering handler io.undertow.server.handlers.resource.ResourceHandler at 10e6e5f under path '/'
> 17:47:29,378 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) JBAS017519: Undertow HTTP listener default listening on /127.0.0.1:8080
> 17:47:29,599 INFO  [org.jboss.as.remoting] (MSC service thread 1-2) JBAS017100: Listening on 127.0.0.1:9999
> 17:47:29,637 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017519: Undertow AJP listener ajp-connector listening on /127.0.0.1:8009
> 17:47:29,654 INFO  [org.jboss.as.remoting] (MSC service thread 1-1) JBAS017100: Listening on 127.0.0.1:4447
> 17:47:30,243 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
> 17:47:30,249 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("add") failed - address: ([("subsystem" => "modcluster")]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.mod-cluster is missing [jboss.web.connector.ajp, jboss.web]"]}
> 17:47:30,369 INFO  [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.web (missing) dependents: [service jboss.mod-cluster] 
>       service jboss.web.connector.ajp (missing) dependents: [service jboss.mod-cluster] 
> 17:47:30,432 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:9990/management
> 17:47:30,439 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990
> 17:47:30,440 ERROR [org.jboss.as] (Controller Boot Thread) JBAS015875: WildFly 8.0.0.Alpha2-SNAPSHOT "WildFly" started (with errors) in 12756ms - Started 156 of 250 services (1 services failed or missing dependencies, 115 services are lazy, passive or on-demand)
> 17:47:32,577 INFO  [org.jboss.as.repository] (management-handler-thread - 2) JBAS014900: Content added at location C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode\target\jbossas\standalone\data\content\57\ef1f6cb625fb992628a0511dee1d1967e804f0\content
> 17:47:32,592 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015876: Starting deployment of "server-to-server-clustered-ejb-invocation.jar" (runtime-name: "server-to-server-clustered-ejb-invocation.jar")
> 17:47:33,035 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-1) JNDI bindings for session bean named ClusteredStatefulNodeNameEcho in deployment unit deployment "server-to-server-clustered-ejb-invocation.jar" are as follows:
>     java:global/server-to-server-clustered-ejb-invocation/ClusteredStatefulNodeNameEcho!org.jboss.as.test.manualmode.ejb.client.cluster.NodeNameEcho
>     java:app/server-to-server-clustered-ejb-invocation/ClusteredStatefulNodeNameEcho!org.jboss.as.test.manualmode.ejb.client.cluster.NodeNameEcho
>     java:module/ClusteredStatefulNodeNameEcho!org.jboss.as.test.manualmode.ejb.client.cluster.NodeNameEcho
>     java:jboss/exported/server-to-server-clustered-ejb-invocation/ClusteredStatefulNodeNameEcho!org.jboss.as.test.manualmode.ejb.client.cluster.NodeNameEcho
>     java:global/server-to-server-clustered-ejb-invocation/ClusteredStatefulNodeNameEcho
>     java:app/server-to-server-clustered-ejb-invocation/ClusteredStatefulNodeNameEcho
>     java:module/ClusteredStatefulNodeNameEcho
> 17:47:35,597 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 3) ISPN000078: Starting JGroups Channel
> 17:47:35,612 INFO  [stdout] (ServerService Thread Pool -- 3) 
> 17:47:35,612 INFO  [stdout] (ServerService Thread Pool -- 3) -------------------------------------------------------------------
> 17:47:35,612 INFO  [stdout] (ServerService Thread Pool -- 3) GMS: address=default-jbossas/ejb, cluster=ejb, physical address=127.0.0.1:55200
> 17:47:35,613 INFO  [stdout] (ServerService Thread Pool -- 3) -------------------------------------------------------------------
> 17:47:37,637 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 3) ISPN000094: Received new cluster view: [default-jbossas/ejb|0] [default-jbossas/ejb]
> 17:47:37,798 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 3) ISPN000079: Cache local address is default-jbossas/ejb, physical addresses are [127.0.0.1:55200]
> 17:47:37,805 INFO  [org.infinispan.factories.GlobalComponentRegistry] (ServerService Thread Pool -- 3) ISPN000128: Infinispan version: Infinispan 'Tactical Nuclear Penguin' 5.3.0.CR1
> 17:47:37,835 INFO  [org.infinispan.factories.TransactionManagerFactory] (ServerService Thread Pool -- 2) ISPN000161: Using a batchMode transaction manager
> 17:47:38,053 INFO  [org.infinispan.jmx.CacheJmxRegistration] (ServerService Thread Pool -- 2) ISPN000031: MBeans were successfully registered to the platform MBean server.
> 17:47:38,062 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 2) JBAS010281: Started remote-connector-client-mappings cache from ejb container
> 17:47:38,087 INFO  [org.infinispan.factories.TransactionManagerFactory] (ServerService Thread Pool -- 3) ISPN000161: Using a batchMode transaction manager
> 17:47:38,340 INFO  [org.infinispan.jmx.CacheJmxRegistration] (ServerService Thread Pool -- 3) ISPN000031: MBeans were successfully registered to the platform MBean server.
> 17:47:38,342 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 3) JBAS010281: Started repl cache from ejb container
> 17:47:38,350 INFO  [org.jboss.as.clustering] (MSC service thread 1-2) JBAS010238: Number of cluster members: 1
> 17:47:38,378 INFO  [org.infinispan.factories.TransactionManagerFactory] (MSC service thread 1-2) ISPN000161: Using a batchMode transaction manager
> 17:47:38,390 INFO  [org.infinispan.jmx.CacheJmxRegistration] (MSC service thread 1-2) ISPN000031: MBeans were successfully registered to the platform MBean server.
> 17:47:38,392 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-2) JBAS010281: Started org.jboss.as.test.manualmode.ejb.client.cluster.ClusteredStatefulNodeNameEcho cache from ejb container
> 17:47:38,459 INFO  [org.jboss.as.server] (management-handler-thread - 2) JBAS018559: Deployed "server-to-server-clustered-ejb-invocation.jar" (runtime-name : "server-to-server-clustered-ejb-invocation.jar")
> 17:47:40,405 INFO  [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual starting of a server instance
> 17:47:41,533 INFO  [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Starting container with: [C:\workspace\Java\jdk1.7.0_13\bin\java, -Xmx512m, -XX:MaxPermSize=256m, -Djboss.dist=C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode/../../../build/target/wildfly-8.0.0.Alpha2-SNAPSHOT, -Djava.net.preferIPv4Stack=true, -Djava.net.preferIPv6Addresses=false, -server, -Dts.timeout.factor=100, -Dnode0=127.0.0.1, -Dnode1=127.0.0.1, -Dmcast=230.0.0.4, -Djbossas.ts.submodule.dir=C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode, -Djbossas.ts.integ.dir=C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode/.., -Djbossas.ts.dir=C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode/../.., -Djbossas.project.dir=C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode/../../.., -Djboss.dist=C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode/../../../build/target/wildfly-8.0.0.Alpha2-SNAPSHOT, -Djboss.inst=C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode/target/jbossas-with-remote-outbound-connection, -Djboss.node.name=jbossas-with-remote-outbound-connection, -ea, -Djboss.home.dir=C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode/target/jbossas-with-remote-outbound-connection, -Dorg.jboss.boot.log.file=C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode\target\jbossas-with-remote-outbound-connection\standalone\log\boot.log, -Dlogging.configuration=file:/C:/BuildAgent/work/1943cb9aa6e69362/testsuite/integration/manualmode/target/jbossas-with-remote-outbound-connection/standalone/configuration/logging.properties, -Djboss.bundles.dir=C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode/../../../build/target/wildfly-8.0.0.Alpha2-SNAPSHOT/bundles, -jar, C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode\target\jbossas-with-remote-outbound-connection\jboss-modules.jar, -mp, C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode/../../../build/target/wildfly-8.0.0.Alpha2-SNAPSHOT/modules;C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode/target/modules, org.jboss.as.standalone, -server-config, standalone-ha.xml]
> 17:47:42,791 INFO  [org.jboss.modules] (main) JBoss Modules version 1.2.2.Final
> 17:47:44,437 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.0.Beta1
> 17:47:44,582 INFO  [org.jboss.as] (MSC service thread 1-2) JBAS015899: WildFly 8.0.0.Alpha2-SNAPSHOT "WildFly" starting
> 17:47:50,729 INFO  [org.jboss.as.server] (Controller Boot Thread) JBAS015888: Creating http management service using socket-binding (management-http)
> 17:47:50,803 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 2) JBAS010403: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 17:47:51,246 INFO  [org.xnio] (MSC service thread 1-2) XNIO Version 3.1.0.CR3
> 17:47:51,261 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 52) JBAS015537: Activating WebServices Extension
> 17:47:51,277 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 51) JBAS017502: Undertow 1.0.0.Alpha20 starting
> 17:47:51,309 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 48) JBAS013171: Activating Security Subsystem
> 17:47:51,380 INFO  [org.xnio.nio] (MSC service thread 1-2) XNIO NIO Implementation Version 3.1.0.CR3
> 17:47:51,389 INFO  [org.jboss.remoting] (MSC service thread 1-2) JBoss Remoting version 4.0.0.Beta1
> 17:47:51,484 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 43) JBAS011800: Activating Naming Subsystem
> 17:47:51,516 INFO  [org.jboss.as.jsf] (ServerService Thread Pool -- 40) JBAS012605: Activated the following JSF Implementations: [main]
> 17:47:51,560 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 51) JBAS017527: Creating file handler for path C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode\target\jbossas-with-remote-outbound-connection/welcome-content
> 17:47:52,492 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 33) JBAS010280: Activating Infinispan subsystem.
> 17:47:52,944 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 37) JBAS010260: Activating JGroups subsystem.
> 17:47:54,723 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 33) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> 17:47:54,733 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 33) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> 17:47:55,833 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) JBAS017502: Undertow 1.0.0.Alpha20 starting
> 17:47:55,919 INFO  [org.jboss.as.connector.logging] (MSC service thread 1-1) JBAS010408: Starting JCA Subsystem (IronJacamar 1.0.17.Final)
> 17:47:56,306 INFO  [org.jboss.as.naming] (MSC service thread 1-1) JBAS011802: Starting Naming Service
> 17:47:56,307 INFO  [org.jboss.as.security] (MSC service thread 1-1) JBAS013170: Current PicketBox version=4.0.17.Final
> 17:47:56,315 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) JBAS017525: Started http handler io.undertow.server.handlers.resource.ResourceHandler at 1f3bc38.
> 17:47:56,325 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) Starting server server service: service jboss.undertow.server.default-server
> 17:47:56,355 INFO  [org.jboss.ws.common.management] (MSC service thread 1-1) JBWS022052: Starting JBoss Web Services - Stack CXF Server 4.2.0.CR1
> 17:47:56,357 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) JBAS010417: Started Driver service with driver-name = h2
> 17:47:56,569 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-1) JBAS015012: Started FileSystemDeploymentService for directory C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode\target\jbossas-with-remote-outbound-connection\standalone\deployments
> 17:47:56,570 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-1) JBAS015400: Bound mail session [java:jboss/mail/Default]
> 17:47:56,571 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) Starting host default-host
> 17:47:56,573 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) JBAS017528: registering handler io.undertow.server.handlers.resource.ResourceHandler at 1f3bc38 under path '/'
> 17:47:56,594 INFO  [org.jboss.as.remoting] (MSC service thread 1-2) JBAS017100: Listening on 127.0.0.1:10099
> 17:47:56,610 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017519: Undertow HTTP listener default listening on /127.0.0.1:8180
> 17:47:56,612 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017519: Undertow AJP listener ajp-connector listening on /127.0.0.1:8109
> 17:47:56,612 INFO  [org.jboss.as.remoting] (MSC service thread 1-2) JBAS017100: Listening on 127.0.0.1:4547
> 17:47:57,479 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
> 17:47:57,484 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("add") failed - address: ([("subsystem" => "modcluster")]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.mod-cluster is missing [jboss.web.connector.ajp, jboss.web]"]}
> 17:47:57,529 INFO  [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.web (missing) dependents: [service jboss.mod-cluster] 
>       service jboss.web.connector.ajp (missing) dependents: [service jboss.mod-cluster] 
> 17:47:57,599 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:10090/management
> 17:47:57,599 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:10090
> 17:47:57,600 ERROR [org.jboss.as] (Controller Boot Thread) JBAS015875: WildFly 8.0.0.Alpha2-SNAPSHOT "WildFly" started (with errors) in 15948ms - Started 160 of 254 services (1 services failed or missing dependencies, 117 services are lazy, passive or on-demand)
> 17:48:01,241 INFO  [org.jboss.as.repository] (management-handler-thread - 2) JBAS014900: Content added at location C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode\target\jbossas-with-remote-outbound-connection\standalone\data\content\e0\8b25b6eed5c6f2df04ba76fd92ab3c469cfc0d\content
> 17:48:01,459 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015876: Starting deployment of "server-to-server-clustered-ejb-invocation.jar" (runtime-name: "server-to-server-clustered-ejb-invocation.jar")
> 17:48:01,693 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-2) JNDI bindings for session bean named ClusteredStatefulNodeNameEcho in deployment unit deployment "server-to-server-clustered-ejb-invocation.jar" are as follows:
>     java:global/server-to-server-clustered-ejb-invocation/ClusteredStatefulNodeNameEcho!org.jboss.as.test.manualmode.ejb.client.cluster.NodeNameEcho
>     java:app/server-to-server-clustered-ejb-invocation/ClusteredStatefulNodeNameEcho!org.jboss.as.test.manualmode.ejb.client.cluster.NodeNameEcho
>     java:module/ClusteredStatefulNodeNameEcho!org.jboss.as.test.manualmode.ejb.client.cluster.NodeNameEcho
>     java:jboss/exported/server-to-server-clustered-ejb-invocation/ClusteredStatefulNodeNameEcho!org.jboss.as.test.manualmode.ejb.client.cluster.NodeNameEcho
>     java:global/server-to-server-clustered-ejb-invocation/ClusteredStatefulNodeNameEcho
>     java:app/server-to-server-clustered-ejb-invocation/ClusteredStatefulNodeNameEcho
>     java:module/ClusteredStatefulNodeNameEcho
> 17:48:01,694 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-2) JNDI bindings for session bean named NonClusteredStatefulNodeNameEcho in deployment unit deployment "server-to-server-clustered-ejb-invocation.jar" are as follows:
>     java:global/server-to-server-clustered-ejb-invocation/NonClusteredStatefulNodeNameEcho!org.jboss.as.test.manualmode.ejb.client.cluster.NodeNameEcho
>     java:app/server-to-server-clustered-ejb-invocation/NonClusteredStatefulNodeNameEcho!org.jboss.as.test.manualmode.ejb.client.cluster.NodeNameEcho
>     java:module/NonClusteredStatefulNodeNameEcho!org.jboss.as.test.manualmode.ejb.client.cluster.NodeNameEcho
>     java:jboss/exported/server-to-server-clustered-ejb-invocation/NonClusteredStatefulNodeNameEcho!org.jboss.as.test.manualmode.ejb.client.cluster.NodeNameEcho
>     java:global/server-to-server-clustered-ejb-invocation/NonClusteredStatefulNodeNameEcho
>     java:app/server-to-server-clustered-ejb-invocation/NonClusteredStatefulNodeNameEcho
>     java:module/NonClusteredStatefulNodeNameEcho
> 17:48:02,356 INFO  [org.jboss.ejb.client.remoting] (Remoting "jbossas-with-remote-outbound-connection" task-6) EJBCLIENT000017: Received server version 2 and marshalling strategies [river]
> 17:48:02,368 INFO  [org.jboss.ejb.client.remoting] (MSC service thread 1-2) EJBCLIENT000013: Successful version handshake completed for receiver context EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext at 150eaef, receiver=Remoting connection EJB receiver [connection=Remoting connection <5b49a4>,channel=jboss.ejb,nodename=default-jbossas]} on channel Channel ID 8785ee03 (outbound) of Remoting connection 00a2e892 to 127.0.0.1/127.0.0.1:4447
> 17:48:04,511 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 12) ISPN000078: Starting JGroups Channel
> 17:48:04,525 INFO  [stdout] (ServerService Thread Pool -- 12) 
> 17:48:04,525 INFO  [stdout] (ServerService Thread Pool -- 12) -------------------------------------------------------------------
> 17:48:04,526 INFO  [stdout] (ServerService Thread Pool -- 12) GMS: address=jbossas-with-remote-outbound-connection/ejb, cluster=ejb, physical address=127.0.0.1:55300
> 17:48:04,526 INFO  [stdout] (ServerService Thread Pool -- 12) -------------------------------------------------------------------
> 17:48:05,038 INFO  [org.jboss.as.clustering] (Incoming-1,shared=udp) JBAS010225: New cluster view for partition ejb (id: 1, delta: 1, merge: false) : [default-jbossas/ejb, jbossas-with-remote-outbound-connection/ejb]
> 17:48:05,039 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-1,shared=udp) ISPN000094: Received new cluster view: [default-jbossas/ejb|1] [default-jbossas/ejb, jbossas-with-remote-outbound-connection/ejb]
> 17:48:05,052 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 12) ISPN000094: Received new cluster view: [default-jbossas/ejb|1] [default-jbossas/ejb, jbossas-with-remote-outbound-connection/ejb]
> 17:48:05,307 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 12) ISPN000079: Cache local address is jbossas-with-remote-outbound-connection/ejb, physical addresses are [127.0.0.1:55300]
> 17:48:05,311 INFO  [org.infinispan.factories.GlobalComponentRegistry] (ServerService Thread Pool -- 12) ISPN000128: Infinispan version: Infinispan 'Tactical Nuclear Penguin' 5.3.0.CR1
> 17:48:05,339 INFO  [org.infinispan.factories.TransactionManagerFactory] (ServerService Thread Pool -- 12) ISPN000161: Using a batchMode transaction manager
> 17:48:05,464 INFO  [org.infinispan.factories.TransactionManagerFactory] (ServerService Thread Pool -- 9) ISPN000161: Using a batchMode transaction manager
> 17:48:06,047 INFO  [org.infinispan.jmx.CacheJmxRegistration] (ServerService Thread Pool -- 12) ISPN000031: MBeans were successfully registered to the platform MBean server.
> 17:48:06,626 INFO  [org.infinispan.jmx.CacheJmxRegistration] (ServerService Thread Pool -- 9) ISPN000031: MBeans were successfully registered to the platform MBean server.
> 17:48:06,905 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 12) JBAS010281: Started remote-connector-client-mappings cache from ejb container
> 17:48:06,929 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 9) JBAS010281: Started repl cache from ejb container
> 17:48:06,937 INFO  [org.jboss.as.clustering] (MSC service thread 1-1) JBAS010238: Number of cluster members: 2
> 17:48:07,020 INFO  [org.infinispan.factories.TransactionManagerFactory] (MSC service thread 1-1) ISPN000161: Using a batchMode transaction manager
> 17:48:07,031 INFO  [org.infinispan.jmx.CacheJmxRegistration] (MSC service thread 1-1) ISPN000031: MBeans were successfully registered to the platform MBean server.
> 17:48:07,516 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-1) JBAS010281: Started org.jboss.as.test.manualmode.ejb.client.cluster.ClusteredStatefulNodeNameEcho cache from ejb container
> 17:48:07,638 INFO  [org.jboss.as.server] (management-handler-thread - 2) JBAS018559: Deployed "server-to-server-clustered-ejb-invocation.jar" (runtime-name : "server-to-server-clustered-ejb-invocation.jar")
> 17:48:09,577 INFO  [org.jboss.ejb.client] (main) JBoss EJB Client version 1.0.21.Final
> 17:48:09,606 INFO  [org.jboss.ejb.client.remoting] (Remoting "config-based-ejb-client-endpoint" task-5) EJBCLIENT000017: Received server version 2 and marshalling strategies [river]
> 17:48:09,657 INFO  [org.jboss.ejb.client.remoting] (ejb-client-context-tasks-2-thread-1) EJBCLIENT000013: Successful version handshake completed for receiver context EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext at 19699dd, receiver=Remoting connection EJB receiver [connection=org.jboss.ejb.client.remoting.ConnectionPool$PooledConnection at ae4d15,channel=jboss.ejb,nodename=jbossas-with-remote-outbound-connection]} on channel Channel ID ce12ca12 (outbound) of Remoting connection 0000cc80 to /127.0.0.1:4547
> 17:48:10,245 INFO  [org.jboss.ejb.client.remoting] (Remoting "config-based-ejb-client-endpoint" task-15) EJBCLIENT000017: Received server version 2 and marshalling strategies [river]
> 17:48:10,252 INFO  [org.jboss.ejb.client.remoting] (ejb-client-cluster-node-connection-creation-3-thread-2) EJBCLIENT000013: Successful version handshake completed for receiver context EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext at 19699dd, receiver=Remoting connection EJB receiver [connection=org.jboss.ejb.client.remoting.ConnectionPool$PooledConnection at 2bee08,channel=jboss.ejb,nodename=default-jbossas]} on channel Channel ID bbe7440a (outbound) of Remoting connection 000f67e9 to /127.0.0.1:4447
> 17:48:10,547 INFO  [org.jboss.ejb.client] (EJB default - 2) JBoss EJB Client version 1.0.21.Final
> 17:48:10,945 INFO  [org.jboss.ejb.client] (EJB default - 1) JBoss EJB Client version 1.0.21.Final
> 17:48:11,181 INFO  [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual stopping of a server instance
> 17:48:11,240 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017521: Undertow AJP listener ajp-connector suspending
> 17:48:11,241 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017520: Undertow AJP listener ajp-connector stopped, was bound to /127.0.0.1:8009
> 17:48:11,305 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017521: Undertow HTTP listener default suspending
> 17:48:11,311 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017520: Undertow HTTP listener default stopped, was bound to /127.0.0.1:8080
> 17:48:11,312 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) JBAS010409: Unbound data source [java:jboss/datasources/ExampleDS]
> 17:48:11,318 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) Stopping host default-host
> 17:48:11,333 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) JBAS010418: Stopped Driver service with driver-name = h2
> 17:48:11,333 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017506: Undertow 1.0.0.Alpha20 stopping
> 17:48:11,349 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 55) ISPN000029: Passivating all entries to disk
> 17:48:11,353 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 55) ISPN000030: Passivated 1 entries in 4 milliseconds
> 17:48:11,390 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 55) JBAS010282: Stopped org.jboss.as.test.manualmode.ejb.client.cluster.ClusteredStatefulNodeNameEcho cache from ejb container
> 17:48:11,796 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-1) ISPN000029: Passivating all entries to disk
> 17:48:11,796 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-1) ISPN000030: Passivated 0 entries in 0 milliseconds
> 17:48:11,826 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-1) JBAS010282: Stopped repl cache from ejb container
> 17:48:11,829 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015877: Stopped deployment server-to-server-clustered-ejb-invocation.jar (runtime-name: server-to-server-clustered-ejb-invocation.jar) in 623ms
> 17:48:11,959 INFO  [org.jboss.ejb.client.remoting] (Remoting "config-based-ejb-client-endpoint" task-5) EJBCLIENT000016: Channel Channel ID bbe7440a (outbound) of Remoting connection 000f67e9 to null can no longer process messages
> 17:48:11,977 INFO  [org.jboss.ejb.client.remoting] (Remoting "jbossas-with-remote-outbound-connection" task-9) EJBCLIENT000016: Channel Channel ID 8785ee03 (outbound) of Remoting connection 00a2e892 to null can no longer process messages
> 17:48:12,099 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-2) JBAS010282: Stopped remote-connector-client-mappings cache from ejb container
> 17:48:12,100 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000080: Disconnecting and closing JGroups Channel
> 17:48:12,493 INFO  [org.jboss.as.clustering] (Incoming-7,shared=udp) JBAS010225: New cluster view for partition ejb (id: 2, delta: -1, merge: false) : [jbossas-with-remote-outbound-connection/ejb]
> 17:48:12,495 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-7,shared=udp) ISPN000094: Received new cluster view: [jbossas-with-remote-outbound-connection/ejb|2] [jbossas-with-remote-outbound-connection/ejb]
> 17:48:12,504 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000082: Stopping the RpcDispatcher
> 17:48:12,513 INFO  [org.jboss.as] (MSC service thread 1-1) JBAS015950: WildFly 8.0.0.Alpha2-SNAPSHOT "WildFly" stopped in 1301ms
> 17:48:37,707 INFO  [org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager] (EJB default - 3) Could not create a connection for cluster node ClusterNode{clusterName='ejb', nodeName='default-jbossas', clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0, sourceNetworkMaskBits=0, destinationAddress='127.0.0.1', destinationPort=4447}], resolvedDestination=[Destination address=127.0.0.1, destination port=4447]} in cluster ejb: java.lang.RuntimeException: Operation failed with status WAITING
>     at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:93) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:75) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.remoting.RemotingConnectionManager.getConnection(RemotingConnectionManager.java:51) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:77) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.ClusterContext.getEJBReceiverContext(ClusterContext.java:167) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.ClusterContext.getEJBReceiverContext(ClusterContext.java:93) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.EJBClientContext.getClusterEJBReceiverContext(EJBClientContext.java:930) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.EJBClientContext.getClusterEJBReceiverContext(EJBClientContext.java:915) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.EJBClientContext.requireClusterEJBReceiverContext(EJBClientContext.java:981) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:84) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:253) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:198) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at sun.proxy.$Proxy30.getNodeName(Unknown Source)
>     at org.jboss.as.test.manualmode.ejb.client.cluster.NonClusteredStatefulNodeNameEcho.getNodeName(NonClusteredStatefulNodeNameEcho.java:47) [server-to-server-clustered-ejb-invocation.jar:]
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_13]
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_13]
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_13]
>     at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_13]
>     at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>     at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>     at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:58)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:156) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>     at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:66) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:273) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:90) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:55)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:305)
>     at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:428)
>     at org.wildfly.security.manager.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:63)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:305)
>     at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_13]
>     at org.jboss.invocation.PrivilegedInterceptor.processInvocation(PrivilegedInterceptor.java:65)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>     at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
>     at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:329) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:70) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:203) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_13]
>     at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_13]
>     at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_13]
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_13]
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_13]
>     at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_13]
>     at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> 17:49:02,887 INFO  [org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager] (EJB default - 3) Could not create a connection for cluster node ClusterNode{clusterName='ejb', nodeName='default-jbossas', clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0, sourceNetworkMaskBits=0, destinationAddress='127.0.0.1', destinationPort=4447}], resolvedDestination=[Destination address=127.0.0.1, destination port=4447]} in cluster ejb: java.lang.RuntimeException: Operation failed with status WAITING
>     at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:93) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:75) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.remoting.RemotingConnectionManager.getConnection(RemotingConnectionManager.java:51) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:77) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.ClusterContext.getEJBReceiverContext(ClusterContext.java:167) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.ClusterContext.getEJBReceiverContext(ClusterContext.java:93) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.EJBClientContext.getClusterEJBReceiverContext(EJBClientContext.java:930) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.EJBClientContext.getClusterEJBReceiverContext(EJBClientContext.java:937) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.EJBClientContext.getClusterEJBReceiverContext(EJBClientContext.java:915) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.EJBClientContext.requireClusterEJBReceiverContext(EJBClientContext.java:981) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:84) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:253) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:198) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at sun.proxy.$Proxy30.getNodeName(Unknown Source)
>     at org.jboss.as.test.manualmode.ejb.client.cluster.NonClusteredStatefulNodeNameEcho.getNodeName(NonClusteredStatefulNodeNameEcho.java:47) [server-to-server-clustered-ejb-invocation.jar:]
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_13]
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_13]
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_13]
>     at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_13]
>     at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>     at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>     at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:58)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:156) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>     at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:66) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:273) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:90) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:55)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:305)
>     at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:428)
>     at org.wildfly.security.manager.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:63)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:305)
>     at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_13]
>     at org.jboss.invocation.PrivilegedInterceptor.processInvocation(PrivilegedInterceptor.java:65)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>     at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
>     at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:329) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:70) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:203) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_13]
>     at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_13]
>     at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_13]
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_13]
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_13]
>     at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_13]
>     at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> 17:49:02,921 ERROR [org.jboss.as.ejb3.invocation] (EJB default - 3) JBAS014134: EJB Invocation failed on component NonClusteredStatefulNodeNameEcho for method public abstract java.lang.String org.jboss.as.test.manualmode.ejb.client.cluster.NodeNameEcho.getNodeName(boolean): javax.ejb.EJBException: java.lang.IllegalStateException: EJBCLIENT000028: No EJB receiver contexts available in cluster ejb
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:190) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:90) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:55)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:305)
>     at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:428)
>     at org.wildfly.security.manager.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:63)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:305)
>     at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_13]
>     at org.jboss.invocation.PrivilegedInterceptor.processInvocation(PrivilegedInterceptor.java:65)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>     at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
>     at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:329) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:70) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:203) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_13]
>     at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_13]
>     at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_13]
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_13]
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_13]
>     at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_13]
>     at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> Caused by: java.lang.IllegalStateException: EJBCLIENT000028: No EJB receiver contexts available in cluster ejb
>     at org.jboss.ejb.client.EJBClientContext.requireClusterEJBReceiverContext(EJBClientContext.java:983) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:84) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:253) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:198) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at sun.proxy.$Proxy30.getNodeName(Unknown Source)
>     at org.jboss.as.test.manualmode.ejb.client.cluster.NonClusteredStatefulNodeNameEcho.getNodeName(NonClusteredStatefulNodeNameEcho.java:47) [server-to-server-clustered-ejb-invocation.jar:]
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_13]
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_13]
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_13]
>     at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_13]
>     at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>     at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>     at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:58)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:156) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>     at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:66) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:273) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     ... 41 more
> 17:49:02,974 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 54) ISPN000029: Passivating all entries to disk
> 17:49:02,977 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 54) ISPN000030: Passivated 1 entries in 2 milliseconds
> 17:49:02,979 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 54) JBAS010282: Stopped org.jboss.as.test.manualmode.ejb.client.cluster.ClusteredStatefulNodeNameEcho cache from ejb container
> 17:49:02,992 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-2) JBAS010282: Stopped remote-connector-client-mappings cache from ejb container
> 17:49:02,996 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015877: Stopped deployment server-to-server-clustered-ejb-invocation.jar (runtime-name: server-to-server-clustered-ejb-invocation.jar) in 26ms
> 17:49:02,999 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-1) ISPN000029: Passivating all entries to disk
> 17:49:02,999 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-1) ISPN000030: Passivated 0 entries in 0 milliseconds
> 17:49:03,056 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-1) JBAS010282: Stopped repl cache from ejb container
> 17:49:03,058 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000080: Disconnecting and closing JGroups Channel
> 17:49:03,072 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000082: Stopping the RpcDispatcher
> 17:49:03,093 INFO  [org.jboss.as.repository] (management-handler-thread - 2) JBAS014901: Content removed from location C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode\target\jbossas-with-remote-outbound-connection\standalone\data\content\e0\8b25b6eed5c6f2df04ba76fd92ab3c469cfc0d\content
> 17:49:03,094 INFO  [org.jboss.as.server] (management-handler-thread - 2) JBAS018558: Undeployed "server-to-server-clustered-ejb-invocation.jar" (runtime-name: "server-to-server-clustered-ejb-invocation.jar")
> 17:49:03,096 INFO  [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual stopping of a server instance
> 17:49:03,147 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) JBAS017521: Undertow AJP listener ajp-connector suspending
> 17:49:03,148 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) JBAS017520: Undertow AJP listener ajp-connector stopped, was bound to /127.0.0.1:8109
> 17:49:03,153 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) JBAS017521: Undertow HTTP listener default suspending
> 17:49:03,153 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) JBAS017520: Undertow HTTP listener default stopped, was bound to /127.0.0.1:8180
> 17:49:03,155 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) JBAS010409: Unbound data source [java:jboss/datasources/ExampleDS]
> 17:49:03,160 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) Stopping host default-host
> 17:49:03,173 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) JBAS010418: Stopped Driver service with driver-name = h2
> 17:49:03,174 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) JBAS017506: Undertow 1.0.0.Alpha20 stopping
> 17:49:03,205 INFO  [org.jboss.ejb.client.remoting] (Remoting "config-based-ejb-client-endpoint" task-11) EJBCLIENT000016: Channel Channel ID ce12ca12 (outbound) of Remoting connection 0000cc80 to null can no longer process messages
> 17:49:03,217 INFO  [org.jboss.as] (MSC service thread 1-2) JBAS015950: WildFly 8.0.0.Alpha2-SNAPSHOT "WildFly" stopped in 84ms
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Thu Oct 31 10:54:04 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 10:54:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1716) NoClassDefFoundError:
 org/jboss/el/cache/FactoryFinderCache deploying ear with war inside
In-Reply-To: <JIRA.12496755.1374137088000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496755.1374137088000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496755.1374137088000.26292.1383231244037@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas updated WFLY-1716:
---------------------------------

    Assignee: Stuart Douglas  (was: jaikiran pai)

    
> NoClassDefFoundError: org/jboss/el/cache/FactoryFinderCache deploying ear with war inside
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-1716
>                 URL: https://issues.jboss.org/browse/WFLY-1716
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EE
>    Affects Versions: 8.0.0.Alpha3
>         Environment: Win 7, JEE 6, JDK 7
>            Reporter: Oliver Pfau
>            Assignee: Stuart Douglas
>              Labels: Deploy, classnotfound, war
>
> I tried to deploy my ear which works in JBoss 7 in wildfly and got the following error on deploy:
> 09:59:55,060 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.subunit."my.ear"."mywar.war".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."my.ear"."mywar.war".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of subdeployment "mywar.war" of deployment "my.ear"
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Alpha3.jar:8.0.0.Alpha3]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: java.lang.NoClassDefFoundError: org/jboss/el/cache/FactoryFinderCache
> 	at org.wildfly.extension.undertow.deployment.ELExpressionFactoryProcessor.deploy(ELExpressionFactoryProcessor.java:78)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Alpha3.jar:8.0.0.Alpha3]
> 	... 5 more
> 09:59:55,100 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "my.ear")]) - failure description: {
>     "JBAS014671: Failed services" => {"jboss.deployment.subunit.\"my.ear\".\"mywar.war\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.subunit.\"my.ear\".\"mywar.war\".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of subdeployment \"mywar.war\" of deployment \"my.ear\"
>     Caused by: java.lang.NoClassDefFoundError: org/jboss/el/cache/FactoryFinderCache"},
>     "JBAS014771: Services with missing/unavailable dependencies" => [
>         "jboss.naming.context.java.comp.my-service-ejb-x-SNAPSHOT.MyServiceName.ValidatorFactory is missing [jboss.naming.context.java.comp.my-service-ejb-x-SNAPSHOT.MyServiceName]",
>         "jboss.naming.context.java.comp.my-service-ejb-x-SNAPSHOT.MyServiceName.InstanceName is missing [jboss.naming.context.java.comp.my-service-ejb-x-SNAPSHOT.MyServiceName]",
>         "jboss.naming.context.java.comp.my-service-ejb-x-SNAPSHOT.MyServiceName.Validator is missing [jboss.naming.context.java.comp.my-service-ejb-x-SNAPSHOT.MyServiceName]",
>         
> 		<all other services>
>     ]
> }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 10:54:03 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 10:54:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-312) LocalEJBClientFailoverTestCase
 fails intermittently
In-Reply-To: <JIRA.12471899.1344331208000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12471899.1344331208000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12471899.1344331208000.26288.1383231243800@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas updated WFLY-312:
--------------------------------

    Assignee: Stuart Douglas  (was: jaikiran pai)

    
> LocalEJBClientFailoverTestCase fails intermittently
> ---------------------------------------------------
>
>                 Key: WFLY-312
>                 URL: https://issues.jboss.org/browse/WFLY-312
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Kabir Khan
>            Assignee: Stuart Douglas
>            Priority: Critical
>             Fix For: 8.0.0.CR1
>
>
> org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.LocalEJBClientFailoverTestCase(UDP).testFailoverWhenLocalTargetApplicationIsUndeployed
> Failing for the past 1 build (Since #4607 )
> Took 2 min 24 sec.
> add description
> Error Message
> java.lang.IllegalArgumentException: JBAS014155: Unknown deployment - app name:  module name: node-name-app distinct name: 
> Stacktrace
> javax.ejb.EJBException: java.lang.IllegalArgumentException: JBAS014155: Unknown deployment - app name:  module name: node-name-app distinct name: 
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:165)
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:229)
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:303)
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:189)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:42)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:43)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
>         at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:327)
>         at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:70)
>         at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:205)
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:662)
>         at org.jboss.threads.JBossThread.run(JBossThread.java:122)
>         at ...asynchronous invocation...(Unknown Source)
>         at org.jboss.ejb.client.remoting.InvocationExceptionResponseHandler$MethodInvocationExceptionResultProducer.getResult(InvocationExceptionResponseHandler.java:99)
>         at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:272)
>         at org.jboss.ejb.client.TransactionInterceptor.handleInvocationResult(TransactionInterceptor.java:46)
>         at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:274)
>         at org.jboss.ejb.client.ReceiverInterceptor.handleInvocationResult(ReceiverInterceptor.java:129)
>         at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:262)
>         at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:437)
>         at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:140)
>         at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:121)
>         at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:104)
>         at $Proxy29.invokeAndFetchNodeNameFromClusteredSFSBRemoteBean(Unknown Source)
>         at org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.LocalEJBClientFailoverTestCase.testFailoverWhenLocalTargetApplicationIsUndeployed(LocalEJBClientFailoverTestCase.java:207)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
>         at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
>         at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
>         at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:270)
>         at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
>         at sun.reflect.GeneratedMethodAccessor12.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>         at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
>         at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
>         at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
>         at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
>         at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
>         at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:53)
>         at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>         at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
>         at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
>         at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
>         at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129)
>         at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>         at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
>         at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89)
>         at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>         at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
>         at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
>         at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>         at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
>         at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
>         at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>         at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
>         at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
>         at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111)
>         at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263)
>         at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226)
>         at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
>         at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
>         at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240)
>         at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
>         at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
>         at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
>         at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
>         at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
>         at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
>         at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
>         at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
>         at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185)
>         at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
>         at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
>         at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
>         at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
>         at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188)
>         at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166)
>         at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
>         at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101)
>         at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
> Caused by: java.lang.IllegalArgumentException: JBAS014155: Unknown deployment - app name:  module name: node-name-app distinct name: 
>         at org.jboss.as.ejb3.remote.LocalEjbReceiver.findBean(LocalEjbReceiver.java:317)
>         at org.jboss.as.ejb3.remote.LocalEjbReceiver.processInvocation(LocalEjbReceiver.java:142)
>         at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:181)
>         at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:42)
>         at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183)
>         at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:125)
>         at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183)
>         at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:136)
>         at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:121)
>         at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:104)
>         at $Proxy30.getNodeName(Unknown Source)
>         at org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.ClientSFSB.invokeAndFetchNodeNameFromClusteredSFSBRemoteBean(ClientSFSB.java:53)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:36)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:58)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:156)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:67)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:227)
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:303)
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:189)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:42)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:43)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
>         at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:327)
>         at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:70)
>         at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:205)
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:662)
>         at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> Standard Output
> 05:46:07,738 INFO  [org.jboss.ejb.client.remoting] (Remoting "config-based-ejb-client-endpoint" task-4) EJBCLIENT000016: Channel Channel ID aa79198c (outbound) of Remoting connection 0ab612f8 to /127.0.0.1:4447 can no longer process messages
> 05:46:07,958 INFO  [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual starting of a server instance
> 05:46:07,971 INFO  [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Starting container with: [/opt/jdk1.6.0_29/bin/java, -Xmx512m, -XX:MaxPermSize=256m, -Djboss.dist=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/../../../build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT, -Djava.net.preferIPv4Stack=true, -Djava.net.preferIPv6Addresses=false, -Dts.timeout.factor=100, -Dnode0=127.0.0.1, -Dnode1=127.0.0.1, -Dmcast=230.0.0.4, -Djbossas.ts.submodule.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust, -Djbossas.ts.integ.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/.., -Djbossas.ts.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/../.., -Djbossas.project.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/../../.., -Djboss.dist=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/../../../build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT, -Djboss.inst=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-0, -Djboss.node.name=node-0, -ea, -Djboss.home.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-0, -Dorg.jboss.boot.log.file=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-0/standalone/log/boot.log, -Dlogging.configuration=file:/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-0/standalone/configuration/logging.properties, -Djboss.bundles.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/../../../build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT/bundles, -jar, /home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-0/jboss-modules.jar, -mp, /home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/../../../build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT/modules, -jaxpmodule, javax.xml.jaxp-provider, org.jboss.as.standalone, -server-config, standalone-ha.xml]
> 05:46:08,724 INFO  [org.jboss.modules] JBoss Modules version 1.1.2.GA
> 05:46:08,967 INFO  [org.jboss.msc] JBoss MSC version 1.0.2.GA
> 05:46:09,049 INFO  [org.jboss.as] JBAS015899: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" starting
> 05:46:10,984 INFO  [org.xnio] XNIO Version 3.0.5.GA
> 05:46:10,985 INFO  [org.jboss.as.server] JBAS015888: Creating http management service using socket-binding (management-http)
> 05:46:11,001 INFO  [org.xnio.nio] XNIO NIO Implementation Version 3.0.5.GA
> 05:46:11,023 INFO  [org.jboss.remoting] JBoss Remoting version 3.2.8.GA
> 05:46:11,036 INFO  [org.jboss.as.logging] JBAS011502: Removing bootstrap log handlers
> &#27;[0m05:46:11,041 INFO  [org.jboss.as.configadmin] (ServerService Thread Pool -- 29) JBAS016200: Activating ConfigAdmin Subsystem
> &#27;[0m&#27;[0m05:46:11,073 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 34) JBAS010280: Activating Infinispan subsystem.
> &#27;[0m&#27;[0m05:46:11,115 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 38) JBAS010260: Activating JGroups subsystem.
> &#27;[0m&#27;[0m05:46:11,224 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 50) JBAS013171: Activating Security Subsystem
> &#27;[0m&#27;[0m05:46:11,225 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 44) JBAS011800: Activating Naming Subsystem
> &#27;[0m&#27;[0m05:46:11,300 INFO  [org.jboss.as.connector.logging] (MSC service thread 1-5) JBAS010408: Starting JCA Subsystem (JBoss IronJacamar 1.0.12.Final)
> &#27;[0m&#27;[0m05:46:11,319 INFO  [org.jboss.as.osgi] (ServerService Thread Pool -- 45) JBAS011906: Activating OSGi Subsystem
> &#27;[0m&#27;[0m05:46:11,336 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 54) JBAS015537: Activating WebServices Extension
> &#27;[0m&#27;[0m05:46:11,391 INFO  [org.jboss.as.security] (MSC service thread 1-3) JBAS013170: Current PicketBox version=4.0.9.Final
> &#27;[0m&#27;[0m05:46:11,516 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 30) JBAS010403: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> &#27;[0m&#27;[0m05:46:11,533 INFO  [org.jboss.as.naming] (MSC service thread 1-5) JBAS011802: Starting Naming Service
> &#27;[0m&#27;[0m05:46:11,571 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-6) JBAS015400: Bound mail session [java:jboss/mail/Default]
> &#27;[0m&#27;[0m05:46:11,885 INFO  [org.jboss.ws.common.management.AbstractServerConfig] (MSC service thread 1-6) JBoss Web Services - Stack CXF Server 4.1.0.Beta1
> &#27;[0m&#27;[0m05:46:11,995 INFO  [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-1) Starting Coyote HTTP/1.1 on http-/127.0.0.1:8080
> &#27;[0m&#27;[0m05:46:11,998 INFO  [org.apache.coyote.ajp.AjpProtocol] (MSC service thread 1-2) Starting Coyote AJP/1.3 on ajp-/127.0.0.1:8009
> &#27;[0m&#27;[0m05:46:12,166 INFO  [org.jboss.modcluster.ModClusterService] (ServerService Thread Pool -- 56) Initializing mod_cluster 1.2.1.Final
> &#27;[0m&#27;[0m05:46:12,229 INFO  [org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl] (ServerService Thread Pool -- 56) Listening to proxy advertisements on 224.0.1.105:23,364
> &#27;[0m&#27;[0m05:46:12,338 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 34) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> &#27;[0m&#27;[0m05:46:12,358 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 34) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> &#27;[0m&#27;[0m05:46:12,520 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-6) JBAS015012: Started FileSystemDeploymentService for directory /home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-0/standalone/deployments
> &#27;[0m&#27;[0m05:46:12,522 INFO  [org.jboss.as.remoting] (MSC service thread 1-5) JBAS017100: Listening on 127.0.0.1:4447
> &#27;[0m&#27;[0m05:46:12,526 INFO  [org.jboss.as.remoting] (MSC service thread 1-2) JBAS017100: Listening on 127.0.0.1:9999
> &#27;[0m&#27;[0m05:46:12,561 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
> &#27;[0m&#27;[0m05:46:12,681 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:9990/management
> &#27;[0m&#27;[0m05:46:12,682 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990
> &#27;[0m&#27;[0m05:46:12,683 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" started in 4449ms - Started 137 of 280 services (142 services are passive or on-demand)
> &#27;[0m05:46:14,559 INFO  [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual starting of a server instance
> 05:46:14,565 INFO  [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Starting container with: [/opt/jdk1.6.0_29/bin/java, -Xmx512m, -XX:MaxPermSize=256m, -Djboss.dist=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/../../../build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT, -Djava.net.preferIPv4Stack=true, -Djava.net.preferIPv6Addresses=false, -Dts.timeout.factor=100, -Dnode0=127.0.0.1, -Dnode1=127.0.0.1, -Dmcast=230.0.0.4, -Djbossas.ts.submodule.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust, -Djbossas.ts.integ.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/.., -Djbossas.ts.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/../.., -Djbossas.project.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/../../.., -Djboss.dist=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/../../../build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT, -Djboss.inst=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-1, -Djboss.node.name=node-1, -Djboss.port.offset=100, -ea, -Djboss.home.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-1, -Dorg.jboss.boot.log.file=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-1/standalone/log/boot.log, -Dlogging.configuration=file:/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-1/standalone/configuration/logging.properties, -Djboss.bundles.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/../../../build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT/bundles, -jar, /home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-1/jboss-modules.jar, -mp, /home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/../../../build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT/modules, -jaxpmodule, javax.xml.jaxp-provider, org.jboss.as.standalone, -server-config, standalone-ha.xml]
> 05:46:15,100 INFO  [org.jboss.modules] JBoss Modules version 1.1.2.GA
> 05:46:15,351 INFO  [org.jboss.msc] JBoss MSC version 1.0.2.GA
> 05:46:15,440 INFO  [org.jboss.as] JBAS015899: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" starting
> 05:46:17,345 INFO  [org.xnio] XNIO Version 3.0.5.GA
> 05:46:17,355 INFO  [org.xnio.nio] XNIO NIO Implementation Version 3.0.5.GA
> 05:46:17,359 INFO  [org.jboss.as.server] JBAS015888: Creating http management service using socket-binding (management-http)
> 05:46:17,378 INFO  [org.jboss.remoting] JBoss Remoting version 3.2.8.GA
> 05:46:17,424 INFO  [org.jboss.as.logging] JBAS011502: Removing bootstrap log handlers
> &#27;[0m05:46:17,429 INFO  [org.jboss.as.configadmin] (ServerService Thread Pool -- 29) JBAS016200: Activating ConfigAdmin Subsystem
> &#27;[0m&#27;[0m05:46:17,472 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 34) JBAS010280: Activating Infinispan subsystem.
> &#27;[0m&#27;[0m05:46:17,514 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 38) JBAS010260: Activating JGroups subsystem.
> &#27;[0m&#27;[0m05:46:17,549 INFO  [org.jboss.as.osgi] (ServerService Thread Pool -- 45) JBAS011906: Activating OSGi Subsystem
> &#27;[0m&#27;[0m05:46:17,562 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 50) JBAS013171: Activating Security Subsystem
> &#27;[0m&#27;[0m05:46:17,622 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 54) JBAS015537: Activating WebServices Extension
> &#27;[0m&#27;[0m05:46:17,628 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 44) JBAS011800: Activating Naming Subsystem
> &#27;[0m&#27;[0m05:46:17,625 INFO  [org.jboss.as.connector.logging] (MSC service thread 1-6) JBAS010408: Starting JCA Subsystem (JBoss IronJacamar 1.0.12.Final)
> &#27;[0m&#27;[0m05:46:17,622 INFO  [org.jboss.as.security] (MSC service thread 1-1) JBAS013170: Current PicketBox version=4.0.9.Final
> &#27;[0m&#27;[0m05:46:17,691 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 30) JBAS010403: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> &#27;[0m&#27;[0m05:46:17,761 INFO  [org.jboss.as.naming] (MSC service thread 1-2) JBAS011802: Starting Naming Service
> &#27;[0m&#27;[0m05:46:17,847 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-4) JBAS015400: Bound mail session [java:jboss/mail/Default]
> &#27;[0m&#27;[0m05:46:18,096 INFO  [org.jboss.ws.common.management.AbstractServerConfig] (MSC service thread 1-3) JBoss Web Services - Stack CXF Server 4.1.0.Beta1
> &#27;[0m&#27;[0m05:46:18,233 INFO  [org.apache.coyote.ajp.AjpProtocol] (MSC service thread 1-5) Starting Coyote AJP/1.3 on ajp-/127.0.0.1:8109
> &#27;[0m&#27;[0m05:46:18,236 INFO  [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-3) Starting Coyote HTTP/1.1 on http-/127.0.0.1:8180
> &#27;[0m&#27;[0m05:46:18,374 INFO  [org.jboss.modcluster.ModClusterService] (ServerService Thread Pool -- 56) Initializing mod_cluster 1.2.1.Final
> &#27;[0m&#27;[0m05:46:18,486 INFO  [org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl] (ServerService Thread Pool -- 56) Listening to proxy advertisements on 224.0.1.105:23,364
> &#27;[0m&#27;[0m05:46:18,571 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 34) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> &#27;[0m&#27;[0m05:46:18,593 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 34) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> &#27;[0m&#27;[0m05:46:18,753 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
> &#27;[0m&#27;[0m05:46:18,778 INFO  [org.jboss.as.remoting] (MSC service thread 1-6) JBAS017100: Listening on 127.0.0.1:10099
> &#27;[0m&#27;[0m05:46:18,778 INFO  [org.jboss.as.remoting] (MSC service thread 1-3) JBAS017100: Listening on 127.0.0.1:4547
> &#27;[0m&#27;[0m05:46:18,783 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-1) JBAS015012: Started FileSystemDeploymentService for directory /home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-1/standalone/deployments
> &#27;[0m&#27;[0m05:46:18,936 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:10090/management
> &#27;[0m&#27;[0m05:46:18,937 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:10090
> &#27;[0m&#27;[0m05:46:18,938 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" started in 4137ms - Started 137 of 280 services (142 services are passive or on-demand)
> &#27;[0m&#27;[0m05:46:21,241 INFO  [org.jboss.as.repository] (management-handler-thread - 2) JBAS014900: Content added at location /home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-1/standalone/data/content/e2/09ce1c0485164619e2ea871a0013f2781ab162/content
> &#27;[0m&#27;[0m05:46:21,299 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015876: Starting deployment of "client-app.jar"
> &#27;[0m&#27;[0m05:46:21,894 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-1) JNDI bindings for session bean named ClientSFSB in deployment unit deployment "client-app.jar" are as follows:
>         java:global/client-app/ClientSFSB!org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.ClientSFSBRemote
>         java:app/client-app/ClientSFSB!org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.ClientSFSBRemote
>         java:module/ClientSFSB!org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.ClientSFSBRemote
>         java:jboss/exported/client-app/ClientSFSB!org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.ClientSFSBRemote
>         java:global/client-app/ClientSFSB
>         java:app/client-app/ClientSFSB
>         java:module/ClientSFSB
> &#27;[0m&#27;[0m05:46:22,409 INFO  [org.jboss.as.server] (management-handler-thread - 2) JBAS018559: Deployed "client-app.jar"
> &#27;[0m&#27;[0m05:46:22,882 INFO  [org.jboss.as.repository] (management-handler-thread - 2) JBAS014900: Content added at location /home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-0/standalone/data/content/dc/274297a56acebcb3414b7407fa05d097f6691b/content
> &#27;[0m&#27;[0m05:46:22,903 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015876: Starting deployment of "node-name-app.jar"
> &#27;[0m&#27;[0m05:46:23,113 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-2) JNDI bindings for session bean named NodeNameSFSB in deployment unit deployment "node-name-app.jar" are as follows:
>         java:global/node-name-app/NodeNameSFSB!org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.NodeNameRetriever
>         java:app/node-name-app/NodeNameSFSB!org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.NodeNameRetriever
>         java:module/NodeNameSFSB!org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.NodeNameRetriever
>         java:jboss/exported/node-name-app/NodeNameSFSB!org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.NodeNameRetriever
>         java:global/node-name-app/NodeNameSFSB
>         java:app/node-name-app/NodeNameSFSB
>         java:module/NodeNameSFSB
> &#27;[0m&#27;[33m05:46:24,128 WARN  [org.jgroups.protocols.UDP] (ServerService Thread Pool -- 1) send buffer of socket java.net.DatagramSocket at 3b5789a5 was set to 640KB, but the OS only allocated 131.07KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> &#27;[0m&#27;[33m05:46:24,132 WARN  [org.jgroups.protocols.UDP] (ServerService Thread Pool -- 1) receive buffer of socket java.net.DatagramSocket at 3b5789a5 was set to 20MB, but the OS only allocated 131.07KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> &#27;[0m&#27;[33m05:46:24,134 WARN  [org.jgroups.protocols.UDP] (ServerService Thread Pool -- 1) send buffer of socket java.net.MulticastSocket at 1a543937 was set to 640KB, but the OS only allocated 131.07KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> &#27;[0m&#27;[33m05:46:24,136 WARN  [org.jgroups.protocols.UDP] (ServerService Thread Pool -- 1) receive buffer of socket java.net.MulticastSocket at 1a543937 was set to 25MB, but the OS only allocated 131.07KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> &#27;[0m&#27;[0m05:46:24,154 INFO  [stdout] (ServerService Thread Pool -- 1) 
> &#27;[0m&#27;[0m05:46:24,155 INFO  [stdout] (ServerService Thread Pool -- 1) -------------------------------------------------------------------
> &#27;[0m&#27;[0m05:46:24,156 INFO  [stdout] (ServerService Thread Pool -- 1) GMS: address=node-0/ejb, cluster=ejb, physical address=127.0.0.1:55200
> &#27;[0m&#27;[0m05:46:24,157 INFO  [stdout] (ServerService Thread Pool -- 1) -------------------------------------------------------------------
> &#27;[0m&#27;[0m05:46:26,383 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 1) ISPN000078: Starting JGroups Channel
> &#27;[0m&#27;[0m05:46:26,408 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 1) ISPN000094: Received new cluster view: [node-0/ejb|0] [node-0/ejb]
> &#27;[0m&#27;[0m05:46:26,411 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 1) ISPN000079: Cache local address is node-0/ejb, physical addresses are [127.0.0.1:55200]
> &#27;[0m&#27;[0m05:46:26,428 INFO  [org.infinispan.factories.GlobalComponentRegistry] (ServerService Thread Pool -- 1) ISPN000128: Infinispan version: Infinispan 'Brahma' 5.1.5.FINAL
> &#27;[0m&#27;[0m05:46:26,648 INFO  [org.infinispan.jmx.CacheJmxRegistration] (ServerService Thread Pool -- 1) ISPN000031: MBeans were successfully registered to the platform mbean server.
> &#27;[0m&#27;[0m05:46:26,832 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 1) JBAS010281: Started remote-connector-client-mappings cache from ejb container
> &#27;[0m&#27;[0m05:46:26,850 INFO  [org.infinispan.jmx.CacheJmxRegistration] (ServerService Thread Pool -- 3) ISPN000031: MBeans were successfully registered to the platform mbean server.
> &#27;[0m&#27;[0m05:46:26,871 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 3) JBAS010281: Started repl cache from ejb container
> &#27;[0m&#27;[0m05:46:26,902 INFO  [org.jboss.as.clustering] (MSC service thread 1-1) JBAS010238: Number of cluster members: 1
> &#27;[0m&#27;[0m05:46:27,058 INFO  [org.infinispan.jmx.CacheJmxRegistration] (MSC service thread 1-4) ISPN000031: MBeans were successfully registered to the platform mbean server.
> &#27;[0m&#27;[0m05:46:27,063 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-4) JBAS010281: Started org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.NodeNameSFSB cache from ejb container
> &#27;[0m&#27;[0m05:46:27,151 INFO  [org.jboss.as.server] (management-handler-thread - 2) JBAS018559: Deployed "node-name-app.jar"
> &#27;[0m&#27;[0m05:46:28,007 INFO  [org.jboss.as.repository] (management-handler-thread - 3) JBAS014900: Content added at location /home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-1/standalone/data/content/e7/e8aacd434237d96e19be07831cf2a158b389fd/content
> &#27;[0m&#27;[0m05:46:28,024 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015876: Starting deployment of "node-name-app.jar"
> &#27;[0m&#27;[0m05:46:28,106 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-5) JNDI bindings for session bean named NodeNameSFSB in deployment unit deployment "node-name-app.jar" are as follows:
>         java:global/node-name-app/NodeNameSFSB!org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.NodeNameRetriever
>         java:app/node-name-app/NodeNameSFSB!org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.NodeNameRetriever
>         java:module/NodeNameSFSB!org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.NodeNameRetriever
>         java:jboss/exported/node-name-app/NodeNameSFSB!org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.NodeNameRetriever
>         java:global/node-name-app/NodeNameSFSB
>         java:app/node-name-app/NodeNameSFSB
>         java:module/NodeNameSFSB
> &#27;[0m&#27;[33m05:46:28,883 WARN  [org.jgroups.protocols.UDP] (ServerService Thread Pool -- 26) send buffer of socket java.net.DatagramSocket at 67310bf was set to 640KB, but the OS only allocated 131.07KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> &#27;[0m&#27;[33m05:46:28,884 WARN  [org.jgroups.protocols.UDP] (ServerService Thread Pool -- 26) receive buffer of socket java.net.DatagramSocket at 67310bf was set to 20MB, but the OS only allocated 131.07KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> &#27;[0m&#27;[33m05:46:28,885 WARN  [org.jgroups.protocols.UDP] (ServerService Thread Pool -- 26) send buffer of socket java.net.MulticastSocket at 14a1373f was set to 640KB, but the OS only allocated 131.07KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> &#27;[0m&#27;[33m05:46:28,885 WARN  [org.jgroups.protocols.UDP] (ServerService Thread Pool -- 26) receive buffer of socket java.net.MulticastSocket at 14a1373f was set to 25MB, but the OS only allocated 131.07KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> &#27;[0m&#27;[0m05:46:28,891 INFO  [stdout] (ServerService Thread Pool -- 26) 
> &#27;[0m&#27;[0m05:46:28,891 INFO  [stdout] (ServerService Thread Pool -- 26) -------------------------------------------------------------------
> &#27;[0m&#27;[0m05:46:28,891 INFO  [stdout] (ServerService Thread Pool -- 26) GMS: address=node-1/ejb, cluster=ejb, physical address=127.0.0.1:55300
> &#27;[0m&#27;[0m05:46:28,892 INFO  [stdout] (ServerService Thread Pool -- 26) -------------------------------------------------------------------
> &#27;[0m&#27;[0m05:46:28,993 INFO  [org.jboss.as.clustering] (ViewHandler,ejb,node-0/ejb) JBAS010225: New cluster view for partition ejb (id: 1, delta: 1, merge: false) : [node-0/ejb, node-1/ejb]
> &#27;[0m&#27;[0m05:46:28,999 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ViewHandler,ejb,node-0/ejb) ISPN000094: Received new cluster view: [node-0/ejb|1] [node-0/ejb, node-1/ejb]
> &#27;[0m&#27;[0m05:46:29,216 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 28) ISPN000078: Starting JGroups Channel
> &#27;[0m&#27;[0m05:46:29,240 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 28) ISPN000094: Received new cluster view: [node-0/ejb|1] [node-0/ejb, node-1/ejb]
> &#27;[0m&#27;[0m05:46:29,243 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 28) ISPN000079: Cache local address is node-1/ejb, physical addresses are [127.0.0.1:55300]
> &#27;[0m&#27;[0m05:46:29,261 INFO  [org.infinispan.factories.GlobalComponentRegistry] (ServerService Thread Pool -- 28) ISPN000128: Infinispan version: Infinispan 'Brahma' 5.1.5.FINAL
> &#27;[0m&#27;[0m05:46:29,479 INFO  [org.infinispan.jmx.CacheJmxRegistration] (ServerService Thread Pool -- 13) ISPN000031: MBeans were successfully registered to the platform mbean server.
> &#27;[0m&#27;[0m05:46:29,517 INFO  [org.infinispan.jmx.CacheJmxRegistration] (ServerService Thread Pool -- 28) ISPN000031: MBeans were successfully registered to the platform mbean server.
> &#27;[0m&#27;[0m05:46:29,879 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 28) JBAS010281: Started repl cache from ejb container
> &#27;[0m&#27;[0m05:46:29,924 INFO  [org.jboss.as.clustering] (MSC service thread 1-5) JBAS010238: Number of cluster members: 2
> &#27;[0m&#27;[0m05:46:30,001 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 13) JBAS010281: Started remote-connector-client-mappings cache from ejb container
> &#27;[0m&#27;[0m05:46:30,395 INFO  [org.jboss.ejb.client.remoting] (Remoting "node-1" task-1) EJBCLIENT000017: Received server version 1 and marshalling strategies [river]
> &#27;[0m&#27;[0m05:46:30,429 INFO  [org.jboss.ejb.client.remoting] (ejb-client-cluster-node-connection-creation-4-thread-1) EJBCLIENT000013: Successful version handshake completed for receiver context EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext at 608d116e, receiver=Remoting connection EJB receiver [connection=Remoting connection <70dbdc4b>,channel=jboss.ejb,nodename=node-0]} on channel Channel ID a99830e9 (outbound) of Remoting connection 6e843edc to /127.0.0.1:4447
> &#27;[0m&#27;[0m05:46:30,571 INFO  [org.infinispan.jmx.CacheJmxRegistration] (MSC service thread 1-4) ISPN000031: MBeans were successfully registered to the platform mbean server.
> &#27;[0m&#27;[0m05:46:30,625 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-4) JBAS010281: Started org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.NodeNameSFSB cache from ejb container
> &#27;[0m&#27;[0m05:46:30,698 INFO  [org.jboss.as.server] (management-handler-thread - 3) JBAS018559: Deployed "node-name-app.jar"
> &#27;[0m05:46:30,874 INFO  [org.jboss.ejb.client.remoting] (Remoting "config-based-ejb-client-endpoint" task-1) EJBCLIENT000017: Received server version 1 and marshalling strategies [river]
> 05:46:30,880 INFO  [org.jboss.ejb.client.remoting] (main) EJBCLIENT000013: Successful version handshake completed for receiver context EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext at 5c4e9b7d, receiver=Remoting connection EJB receiver [connection=Remoting connection <53ddcd5f>,channel=jboss.ejb,nodename=node-1]} on channel Channel ID bd97f0d8 (outbound) of Remoting connection 392bed82 to /127.0.0.1:4547
> 05:46:30,990 INFO  [org.jboss.ejb.client.remoting] (Remoting "config-based-ejb-client-endpoint" task-1) EJBCLIENT000017: Received server version 1 and marshalling strategies [river]
> 05:46:30,992 INFO  [org.jboss.ejb.client.remoting] (ejb-client-cluster-node-connection-creation-3-thread-6) EJBCLIENT000013: Successful version handshake completed for receiver context EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext at 5c4e9b7d, receiver=Remoting connection EJB receiver [connection=Remoting connection <68634baf>,channel=jboss.ejb,nodename=node-0]} on channel Channel ID e21e278d (outbound) of Remoting connection 41171d93 to /127.0.0.1:4447
> &#27;[0m05:46:31,031 INFO  [org.jboss.ejb.client] (EJB default - 1) JBoss EJB Client version 1.0.11.Final
> &#27;[0m&#27;[0m05:46:31,275 INFO  [org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.ClientSFSB] (EJB default - 2) ClientSFSB invoked on node-1
> &#27;[0m&#27;[0m05:46:31,327 INFO  [org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.NodeNameSFSB] (EJB default - 2) NodeNameSFSB invoked on node-1
> &#27;[0m&#27;[0m05:46:31,407 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 13) ISPN000029: Passivating all entries to disk
> &#27;[0m&#27;[0m05:46:31,435 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 13) ISPN000030: Passivated 1 entries in 27 milliseconds
> &#27;[0m&#27;[0m05:46:31,454 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 13) JBAS010282: Stopped org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.NodeNameSFSB cache from ejb container
> &#27;[0m&#27;[0m05:46:31,506 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-5) ISPN000029: Passivating all entries to disk
> &#27;[0m&#27;[0m05:46:31,512 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-5) ISPN000030: Passivated 0 entries in 5 milliseconds
> &#27;[0m&#27;[0m05:46:31,544 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-5) JBAS010282: Stopped repl cache from ejb container
> &#27;[0m&#27;[0m05:46:31,544 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-3) JBAS010282: Stopped remote-connector-client-mappings cache from ejb container
> &#27;[0m&#27;[0m05:46:31,553 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015877: Stopped deployment node-name-app.jar in 168ms
> &#27;[0m&#27;[0m05:46:31,598 INFO  [org.infinispan.cacheviews.CacheViewsManagerImpl] (OOB-15,null) ISPN000170: Our last committed view (CacheView{viewId=2, members=[node-0/ejb, node-1/ejb]}) is not the same as the coordinator's last committed view (CacheView{viewId=3, members=[node-0/ejb]}). This is normal during a merge
> &#27;[0m&#27;[0m05:46:31,631 INFO  [org.infinispan.cacheviews.CacheViewsManagerImpl] (OOB-17,null) ISPN000170: Our last committed view (CacheView{viewId=2, members=[node-0/ejb, node-1/ejb]}) is not the same as the coordinator's last committed view (CacheView{viewId=3, members=[node-0/ejb]}). This is normal during a merge
> &#27;[0m&#27;[33m05:46:31,602 WARN  [org.infinispan.commands.control.CacheViewControlCommand] (OOB-15,null) ISPN000071: Caught exception when handling command CacheViewControlCommand{cache=remote-connector-client-mappings, type=PREPARE_VIEW, sender=node-0/ejb, newViewId=4, newMembers=[node-0/ejb, node-1/ejb], oldViewId=3, oldMembers=[node-0/ejb]}: java.lang.IllegalStateException: remote-connector-client-mappings: Received cache view prepare request after the local node has already shut down
>         at org.infinispan.cacheviews.CacheViewsManagerImpl.handlePrepareView(CacheViewsManagerImpl.java:487)
>         at org.infinispan.commands.control.CacheViewControlCommand.perform(CacheViewControlCommand.java:126)
>         at org.infinispan.remoting.InboundInvocationHandlerImpl.handle(InboundInvocationHandlerImpl.java:95)
>         at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommand(CommandAwareRpcDispatcher.java:226)
>         at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:203)
>         at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:465)
>         at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:372)
>         at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:247)
>         at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:601)
>         at org.jgroups.blocks.mux.MuxUpHandler.up(MuxUpHandler.java:130)
>         at org.jgroups.JChannel.up(JChannel.java:715)
>         at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1020)
>         at org.jgroups.protocols.RSVP.up(RSVP.java:179)
>         at org.jgroups.protocols.FRAG2.up(FRAG2.java:181)
>         at org.jgroups.protocols.FlowControl.up(FlowControl.java:418)
>         at org.jgroups.protocols.FlowControl.up(FlowControl.java:400)
>         at org.jgroups.protocols.pbcast.GMS.up(GMS.java:899)
>         at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244)
>         at org.jgroups.protocols.UNICAST2.handleDataReceived(UNICAST2.java:744)
>         at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:414)
>         at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:572)
>         at org.jgroups.protocols.BARRIER.up(BARRIER.java:102)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143)
>         at org.jgroups.protocols.FD.up(FD.java:273)
>         at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288)
>         at org.jgroups.protocols.MERGE2.up(MERGE2.java:205)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:359)
>         at org.jgroups.protocols.TP$ProtocolAdapter.up(TP.java:2568)
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:1211)
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1775)
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1748)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
>         at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> &#27;[0m&#27;[33m05:46:31,596 WARN  [org.infinispan.commands.control.CacheViewControlCommand] (OOB-20,null) ISPN000071: Caught exception when handling command CacheViewControlCommand{cache=repl, type=PREPARE_VIEW, sender=node-0/ejb, newViewId=3, newMembers=[node-0/ejb, node-1/ejb, node-1/ejb], oldViewId=2, oldMembers=[node-0/ejb, node-1/ejb]}: java.lang.IllegalStateException: repl: Received cache view prepare request after the local node has already shut down
>         at org.infinispan.cacheviews.CacheViewsManagerImpl.handlePrepareView(CacheViewsManagerImpl.java:487)
>         at org.infinispan.commands.control.CacheViewControlCommand.perform(CacheViewControlCommand.java:126)
>         at org.infinispan.remoting.InboundInvocationHandlerImpl.handle(InboundInvocationHandlerImpl.java:95)
>         at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommand(CommandAwareRpcDispatcher.java:226)
>         at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:203)
>         at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:465)
>         at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:372)
>         at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:247)
>         at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:601)
>         at org.jgroups.blocks.mux.MuxUpHandler.up(MuxUpHandler.java:130)
>         at org.jgroups.JChannel.up(JChannel.java:715)
>         at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1020)
>         at org.jgroups.protocols.RSVP.up(RSVP.java:179)
>         at org.jgroups.protocols.FRAG2.up(FRAG2.java:181)
>         at org.jgroups.protocols.FlowControl.up(FlowControl.java:418)
>         at org.jgroups.protocols.FlowControl.up(FlowControl.java:400)
>         at org.jgroups.protocols.pbcast.GMS.up(GMS.java:899)
>         at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244)
>         at org.jgroups.protocols.UNICAST2.handleDataReceived(UNICAST2.java:744)
>         at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:414)
>         at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:572)
>         at org.jgroups.protocols.BARRIER.up(BARRIER.java:102)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143)
>         at org.jgroups.protocols.FD.up(FD.java:273)
>         at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288)
>         at org.jgroups.protocols.MERGE2.up(MERGE2.java:205)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:359)
>         at org.jgroups.protocols.TP$ProtocolAdapter.up(TP.java:2568)
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:1211)
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1775)
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1748)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
>         at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> &#27;[0m&#27;[33m05:46:31,631 WARN  [org.infinispan.commands.control.CacheViewControlCommand] (OOB-16,null) ISPN000071: Caught exception when handling command CacheViewControlCommand{cache=repl, type=PREPARE_VIEW, sender=node-0/ejb, newViewId=3, newMembers=[node-0/ejb, node-1/ejb, node-1/ejb], oldViewId=2, oldMembers=[node-0/ejb, node-1/ejb]}: java.lang.IllegalStateException: Cannot prepare new view CacheView{viewId=3, members=[node-0/ejb, node-1/ejb, node-1/ejb]} on cache repl, we are currently preparing view CacheView{viewId=3, members=[node-0/ejb, node-1/ejb, node-1/ejb]}
>         at org.infinispan.cacheviews.CacheViewInfo.prepareView(CacheViewInfo.java:102)
>         at org.infinispan.cacheviews.CacheViewsManagerImpl.handlePrepareView(CacheViewsManagerImpl.java:481)
>         at org.infinispan.commands.control.CacheViewControlCommand.perform(CacheViewControlCommand.java:126)
>         at org.infinispan.remoting.InboundInvocationHandlerImpl.handle(InboundInvocationHandlerImpl.java:95)
>         at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommand(CommandAwareRpcDispatcher.java:226)
>         at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:203)
>         at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:465)
>         at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:372)
>         at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:247)
>         at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:601)
>         at org.jgroups.blocks.mux.MuxUpHandler.up(MuxUpHandler.java:130)
>         at org.jgroups.JChannel.up(JChannel.java:715)
>         at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1020)
>         at org.jgroups.protocols.RSVP.up(RSVP.java:179)
>         at org.jgroups.protocols.FRAG2.up(FRAG2.java:181)
>         at org.jgroups.protocols.FlowControl.up(FlowControl.java:418)
>         at org.jgroups.protocols.FlowControl.up(FlowControl.java:400)
>         at org.jgroups.protocols.pbcast.GMS.up(GMS.java:899)
>         at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244)
>         at org.jgroups.protocols.UNICAST2.handleDataReceived(UNICAST2.java:744)
>         at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:414)
>         at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:572)
>         at org.jgroups.protocols.BARRIER.up(BARRIER.java:102)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143)
>         at org.jgroups.protocols.FD.up(FD.java:273)
>         at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288)
>         at org.jgroups.protocols.MERGE2.up(MERGE2.java:205)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:359)
>         at org.jgroups.protocols.TP$ProtocolAdapter.up(TP.java:2568)
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:1211)
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1775)
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1748)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
>         at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> &#27;[0m&#27;[33m05:46:31,637 WARN  [org.infinispan.commands.control.CacheViewControlCommand] (OOB-17,null) ISPN000071: Caught exception when handling command CacheViewControlCommand{cache=org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.NodeNameSFSB, type=PREPARE_VIEW, sender=node-0/ejb, newViewId=4, newMembers=[node-0/ejb, node-1/ejb], oldViewId=3, oldMembers=[node-0/ejb]}: java.lang.IllegalStateException: org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.NodeNameSFSB: Received cache view prepare request after the local node has already shut down
>         at org.infinispan.cacheviews.CacheViewsManagerImpl.handlePrepareView(CacheViewsManagerImpl.java:487)
>         at org.infinispan.commands.control.CacheViewControlCommand.perform(CacheViewControlCommand.java:126)
>         at org.infinispan.remoting.InboundInvocationHandlerImpl.handle(InboundInvocationHandlerImpl.java:95)
>         at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommand(CommandAwareRpcDispatcher.java:226)
>         at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:203)
>         at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:465)
>         at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:372)
>         at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:247)
>         at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:601)
>         at org.jgroups.blocks.mux.MuxUpHandler.up(MuxUpHandler.java:130)
>         at org.jgroups.JChannel.up(JChannel.java:715)
>         at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1020)
>         at org.jgroups.protocols.RSVP.up(RSVP.java:179)
>         at org.jgroups.protocols.FRAG2.up(FRAG2.java:181)
>         at org.jgroups.protocols.FlowControl.up(FlowControl.java:418)
>         at org.jgroups.protocols.FlowControl.up(FlowControl.java:400)
>         at org.jgroups.protocols.pbcast.GMS.up(GMS.java:899)
>         at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244)
>         at org.jgroups.protocols.UNICAST2.handleDataReceived(UNICAST2.java:744)
>         at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:414)
>         at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:572)
>         at org.jgroups.protocols.BARRIER.up(BARRIER.java:102)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143)
>         at org.jgroups.protocols.FD.up(FD.java:273)
>         at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288)
>         at org.jgroups.protocols.MERGE2.up(MERGE2.java:205)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:359)
>         at org.jgroups.protocols.TP$ProtocolAdapter.up(TP.java:2568)
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:1211)
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1775)
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1748)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
>         at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> &#27;[0m&#27;[0m05:46:31,865 INFO  [org.jboss.as.clustering] (ViewHandler,ejb,node-0/ejb) JBAS010225: New cluster view for partition ejb (id: 2, delta: -1, merge: false) : [node-0/ejb]
> &#27;[0m&#27;[0m05:46:31,869 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ViewHandler,ejb,node-0/ejb) ISPN000094: Received new cluster view: [node-0/ejb|2] [node-0/ejb]
> &#27;[0m&#27;[31m05:46:31,866 ERROR [org.infinispan.cacheviews.CacheViewsManagerImpl] (CacheViewInstaller-3,node-0/ejb) ISPN000172: Failed to prepare view CacheView{viewId=4, members=[node-0/ejb, node-1/ejb]} for cache  org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.NodeNameSFSB, rolling back to view CacheView{viewId=3, members=[node-0/ejb]}: java.util.concurrent.ExecutionException: org.infinispan.remoting.transport.jgroups.SuspectException: Node node-1/ejb was suspected
>         at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:232) [rt.jar:1.6.0_29]
>         at java.util.concurrent.FutureTask.get(FutureTask.java:91) [rt.jar:1.6.0_29]
>         at org.infinispan.cacheviews.CacheViewsManagerImpl.clusterPrepareView(CacheViewsManagerImpl.java:318) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.cacheviews.CacheViewsManagerImpl.clusterInstallView(CacheViewsManagerImpl.java:249) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.cacheviews.CacheViewsManagerImpl$ViewInstallationTask.call(CacheViewsManagerImpl.java:875) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [rt.jar:1.6.0_29]
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138) [rt.jar:1.6.0_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
>         at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> Caused by: org.infinispan.remoting.transport.jgroups.SuspectException: Node node-1/ejb was suspected
>         at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:170) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:489) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.cacheviews.CacheViewsManagerImpl$2.call(CacheViewsManagerImpl.java:302) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.cacheviews.CacheViewsManagerImpl$2.call(CacheViewsManagerImpl.java:299) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         ... 5 more
> Caused by: SuspectedException
>         at org.jgroups.blocks.MessageDispatcher.sendMessage(MessageDispatcher.java:373) [jgroups-3.1.0.Final.jar:3.1.0.Final]
>         at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:275) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:165) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         ... 8 more
> &#27;[0m&#27;[31m05:46:31,866 ERROR [org.infinispan.cacheviews.CacheViewsManagerImpl] (CacheViewInstaller-1,node-0/ejb) ISPN000172: Failed to prepare view CacheView{viewId=4, members=[node-0/ejb, node-1/ejb]} for cache  remote-connector-client-mappings, rolling back to view CacheView{viewId=3, members=[node-0/ejb]}: java.util.concurrent.ExecutionException: org.infinispan.remoting.transport.jgroups.SuspectException: Node node-1/ejb was suspected
>         at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:232) [rt.jar:1.6.0_29]
>         at java.util.concurrent.FutureTask.get(FutureTask.java:91) [rt.jar:1.6.0_29]
>         at org.infinispan.cacheviews.CacheViewsManagerImpl.clusterPrepareView(CacheViewsManagerImpl.java:318) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.cacheviews.CacheViewsManagerImpl.clusterInstallView(CacheViewsManagerImpl.java:249) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.cacheviews.CacheViewsManagerImpl$ViewInstallationTask.call(CacheViewsManagerImpl.java:875) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [rt.jar:1.6.0_29]
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138) [rt.jar:1.6.0_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
>         at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> Caused by: org.infinispan.remoting.transport.jgroups.SuspectException: Node node-1/ejb was suspected
>         at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:170) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:489) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.cacheviews.CacheViewsManagerImpl$2.call(CacheViewsManagerImpl.java:302) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.cacheviews.CacheViewsManagerImpl$2.call(CacheViewsManagerImpl.java:299) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         ... 5 more
> Caused by: SuspectedException
>         at org.jgroups.blocks.MessageDispatcher.sendMessage(MessageDispatcher.java:373) [jgroups-3.1.0.Final.jar:3.1.0.Final]
>         at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:275) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:165) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         ... 8 more
> &#27;[0m&#27;[0m05:46:31,968 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000082: Stopping the RpcDispatcher
> &#27;[0m&#27;[0m05:46:32,008 INFO  [org.jboss.as.repository] (management-handler-thread - 1) JBAS014901: Content removed from location /home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-1/standalone/data/content/e7/e8aacd434237d96e19be07831cf2a158b389fd/content
> &#27;[0m&#27;[0m05:46:32,010 INFO  [org.jboss.as.server] (management-handler-thread - 1) JBAS018558: Undeployed "node-name-app.jar"
> &#27;[0m&#27;[0m05:46:32,023 INFO  [org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.ClientSFSB] (EJB default - 3) ClientSFSB invoked on node-1
> &#27;[0m&#27;[0m05:46:32,030 INFO  [org.jboss.as.ejb3] (EJB default - 3) JBAS014101: Failed to find SFSB instance with session ID {[-104, 47, 35, -120, 125, 36, 71, 13, -117, 111, -46, -34, -73, -51, 56, 28]} in cache
> &#27;[0m&#27;[31m05:46:32,032 ERROR [org.jboss.as.ejb3.invocation] (EJB default - 3) JBAS014134: EJB Invocation failed on component ClientSFSB for method public abstract java.lang.String org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.ClientSFSBRemote.invokeAndFetchNodeNameFromClusteredSFSBRemoteBean(): javax.ejb.EJBException: java.lang.IllegalArgumentException: JBAS014155: Unknown deployment - app name:  module name: node-name-app distinct name: 
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:165) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:229) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:303) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:189) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:42) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:43) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:327) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:70) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:205) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [rt.jar:1.6.0_29]
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [rt.jar:1.6.0_29]
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138) [rt.jar:1.6.0_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
>         at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
>         at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> Caused by: java.lang.IllegalArgumentException: JBAS014155: Unknown deployment - app name:  module name: node-name-app distinct name: 
>         at org.jboss.as.ejb3.remote.LocalEjbReceiver.findBean(LocalEjbReceiver.java:317) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.as.ejb3.remote.LocalEjbReceiver.processInvocation(LocalEjbReceiver.java:142) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:181) [jboss-ejb-client-1.0.11.Final.jar:1.0.11.Final]
>         at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:42) [jboss-ejb-client-1.0.11.Final.jar:1.0.11.Final]
>         at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183) [jboss-ejb-client-1.0.11.Final.jar:1.0.11.Final]
>         at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:125) [jboss-ejb-client-1.0.11.Final.jar:1.0.11.Final]
>         at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183) [jboss-ejb-client-1.0.11.Final.jar:1.0.11.Final]
>         at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:136) [jboss-ejb-client-1.0.11.Final.jar:1.0.11.Final]
>         at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:121) [jboss-ejb-client-1.0.11.Final.jar:1.0.11.Final]
>         at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:104) [jboss-ejb-client-1.0.11.Final.jar:1.0.11.Final]
>         at $Proxy30.getNodeName(Unknown Source) at org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.ClientSFSB.invokeAndFetchNodeNameFromClusteredSFSBRemoteBean(ClientSFSB.java:53) [client-app.jar:]
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_29]
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_29]
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_29]
>         at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_29]
>         at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:36) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:58)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:156) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:67) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:227) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         ... 29 more
> &#27;[0m05:46:32,102 INFO  [org.jboss.ejb.client.remoting] (Remoting "config-based-ejb-client-endpoint" task-3) EJBCLIENT000011: Discarding result for invocation id 2 since no waiting context found
> &#27;[0m05:46:32,228 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015877: Stopped deployment client-app.jar in 54ms
> &#27;[0m&#27;[0m05:46:32,272 INFO  [org.jboss.as.repository] (management-handler-thread - 2) JBAS014901: Content removed from location /home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-1/standalone/data/content/e2/09ce1c0485164619e2ea871a0013f2781ab162/content
> &#27;[0m&#27;[0m05:46:32,274 INFO  [org.jboss.as.server] (management-handler-thread - 2) JBAS018558: Undeployed "client-app.jar"
> &#27;[0m&#27;[0m05:46:32,328 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 3) ISPN000029: Passivating all entries to disk
> &#27;[0m&#27;[0m05:46:32,350 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 3) ISPN000030: Passivated 1 entries in 22 milliseconds
> &#27;[0m&#27;[0m05:47:31,693 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 3) JBAS010282: Stopped org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.NodeNameSFSB cache from ejb container
> &#27;[0m&#27;[0m05:47:31,740 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-6) ISPN000029: Passivating all entries to disk
> &#27;[0m&#27;[0m05:47:31,746 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-6) ISPN000030: Passivated 0 entries in 5 milliseconds
> &#27;[0m&#27;[0m05:47:31,764 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-6) JBAS010282: Stopped repl cache from ejb container
> &#27;[0m&#27;[0m05:47:31,768 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015877: Stopped deployment node-name-app.jar in 59465ms
> &#27;[0m&#27;[31m05:47:31,882 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (notification-thread-6) ISPN000136: Execution error: org.infinispan.statetransfer.StateTransferInProgressException: Timed out waiting for the state transfer lock, state transfer in progress for view 4
>         at org.infinispan.interceptors.StateTransferLockInterceptor.signalStateTransferInProgress(StateTransferLockInterceptor.java:201)
>         at org.infinispan.interceptors.StateTransferLockInterceptor.visitPrepareCommand(StateTransferLockInterceptor.java:81)
>         at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
>         at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130)
>         at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
>         at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
>         at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:132)
>         at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:91)
>         at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
>         at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
>         at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:86)
>         at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
>         at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
>         at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:345)
>         at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:140)
>         at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:122)
>         at org.infinispan.transaction.synchronization.SynchronizationAdapter.beforeCompletion(SynchronizationAdapter.java:68)
>         at org.infinispan.transaction.tm.DummyTransaction.notifyBeforeCompletion(DummyTransaction.java:230)
>         at org.infinispan.transaction.tm.DummyTransaction.runPrepare(DummyTransaction.java:242)
>         at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:86)
>         at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:102)
>         at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:123)
>         at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:105)
>         at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:86)
>         at org.infinispan.CacheImpl.endBatch(CacheImpl.java:615)
>         at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:80)
>         at org.jboss.as.clustering.registry.RegistryService.invoke(RegistryService.java:260)
>         at org.jboss.as.clustering.registry.RegistryService.viewChanged(RegistryService.java:195)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_29]
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_29]
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_29]
>         at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_29]
>         at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation$1.run(AbstractListenerImpl.java:200)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
>         at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> &#27;[0m&#27;[31m05:47:31,905 ERROR [org.infinispan.transaction.TransactionCoordinator] (notification-thread-6) Error while processing prepare: org.infinispan.statetransfer.StateTransferInProgressException: Timed out waiting for the state transfer lock, state transfer in progress for view 4
>         at org.infinispan.interceptors.StateTransferLockInterceptor.signalStateTransferInProgress(StateTransferLockInterceptor.java:201)
>         at org.infinispan.interceptors.StateTransferLockInterceptor.visitPrepareCommand(StateTransferLockInterceptor.java:81)
>         at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
>         at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130)
>         at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
>         at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
>         at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:132)
>         at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:91)
>         at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
>         at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
>         at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:86)
>         at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
>         at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
>         at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:345)
>         at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:140)
>         at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:122)
>         at org.infinispan.transaction.synchronization.SynchronizationAdapter.beforeCompletion(SynchronizationAdapter.java:68)
>         at org.infinispan.transaction.tm.DummyTransaction.notifyBeforeCompletion(DummyTransaction.java:230)
>         at org.infinispan.transaction.tm.DummyTransaction.runPrepare(DummyTransaction.java:242)
>         at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:86)
>         at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:102)
>         at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:123)
>         at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:105)
>         at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:86)
>         at org.infinispan.CacheImpl.endBatch(CacheImpl.java:615)
>         at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:80)
>         at org.jboss.as.clustering.registry.RegistryService.invoke(RegistryService.java:260)
>         at org.jboss.as.clustering.registry.RegistryService.viewChanged(RegistryService.java:195)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_29]
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_29]
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_29]
>         at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_29]
>         at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation$1.run(AbstractListenerImpl.java:200)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
>         at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> &#27;[0m&#27;[31m05:47:31,924 ERROR [org.infinispan.transaction.tm.DummyTransaction] (notification-thread-6) ISPN000109: beforeCompletion() failed for SynchronizationAdapter{localTransaction=LocalTransaction{remoteLockedNodes=null, isMarkedForRollback=false, transaction=DummyTransaction{xid=DummyXid{id=3}, status=1}, lockedKeys=null, backupKeyLocks=null, viewId=2} org.infinispan.transaction.synchronization.SyncLocalTransaction at 2} org.infinispan.transaction.synchronization.SynchronizationAdapter at 21: org.infinispan.CacheException: Could not prepare. 
>         at org.infinispan.transaction.synchronization.SynchronizationAdapter.beforeCompletion(SynchronizationAdapter.java:70)
>         at org.infinispan.transaction.tm.DummyTransaction.notifyBeforeCompletion(DummyTransaction.java:230)
>         at org.infinispan.transaction.tm.DummyTransaction.runPrepare(DummyTransaction.java:242)
>         at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:86)
>         at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:102)
>         at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:123)
>         at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:105)
>         at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:86)
>         at org.infinispan.CacheImpl.endBatch(CacheImpl.java:615)
>         at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:80)
>         at org.jboss.as.clustering.registry.RegistryService.invoke(RegistryService.java:260)
>         at org.jboss.as.clustering.registry.RegistryService.viewChanged(RegistryService.java:195)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_29]
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_29]
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_29]
>         at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_29]
>         at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation$1.run(AbstractListenerImpl.java:200)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
>         at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> Caused by: javax.transaction.xa.XAException
>         at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:160)
>         at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:122)
>         at org.infinispan.transaction.synchronization.SynchronizationAdapter.beforeCompletion(SynchronizationAdapter.java:68)
>         ... 19 more
> &#27;[0m&#27;[33m05:47:31,936 WARN  [org.infinispan.notifications.cachemanagerlistener.CacheManagerNotifierImpl] (notification-thread-6) ISPN000134: Unable to invoke method public void org.jboss.as.clustering.registry.RegistryService.viewChanged(org.infinispan.notifications.cachemanagerlistener.event.ViewChangedEvent) on Object instance org.jboss.as.clustering.registry.RegistryService at d07ffdf - removing this target object from list of listeners!: org.infinispan.CacheException: Unable to end batch
>         at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:107)
>         at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:86)
>         at org.infinispan.CacheImpl.endBatch(CacheImpl.java:615)
>         at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:80)
>         at org.jboss.as.clustering.registry.RegistryService.invoke(RegistryService.java:260)
>         at org.jboss.as.clustering.registry.RegistryService.viewChanged(RegistryService.java:195)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_29]
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_29]
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_29]
>         at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_29]
>         at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation$1.run(AbstractListenerImpl.java:200)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
>         at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> Caused by: javax.transaction.RollbackException: Exception rolled back, status is: 9
>         at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:89)
>         at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:102)
>         at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:123)
>         at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:105)
>         ... 13 more
> &#27;[0m&#27;[31m05:48:31,737 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (MSC service thread 1-3) ISPN000136: Execution error: org.infinispan.statetransfer.StateTransferInProgressException: Timed out waiting for the state transfer lock, state transfer in progress for view 4
>         at org.infinispan.interceptors.StateTransferLockInterceptor.signalStateTransferInProgress(StateTransferLockInterceptor.java:201) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.interceptors.StateTransferLockInterceptor.visitPrepareCommand(StateTransferLockInterceptor.java:81) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:132) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:91) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:86) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:345) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:140) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:122) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.synchronization.SynchronizationAdapter.beforeCompletion(SynchronizationAdapter.java:68) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.tm.DummyTransaction.notifyBeforeCompletion(DummyTransaction.java:230) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.tm.DummyTransaction.runPrepare(DummyTransaction.java:242) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:86) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:102) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:123) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:105) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:86) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.CacheImpl.endBatch(CacheImpl.java:615) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:80) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.jboss.as.clustering.registry.RegistryService.invoke(RegistryService.java:260) [jboss-as-clustering-registry-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.as.clustering.registry.RegistryService.stop(RegistryService.java:162) [jboss-as-clustering-registry-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:1911) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>         at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:1874) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
>         at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> &#27;[0m&#27;[31m05:48:31,745 ERROR [org.infinispan.transaction.TransactionCoordinator] (MSC service thread 1-3) Error while processing prepare: org.infinispan.statetransfer.StateTransferInProgressException: Timed out waiting for the state transfer lock, state transfer in progress for view 4
>         at org.infinispan.interceptors.StateTransferLockInterceptor.signalStateTransferInProgress(StateTransferLockInterceptor.java:201) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.interceptors.StateTransferLockInterceptor.visitPrepareCommand(StateTransferLockInterceptor.java:81) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:132) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:91) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:86) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:345) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:140) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:122) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.synchronization.SynchronizationAdapter.beforeCompletion(SynchronizationAdapter.java:68) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.tm.DummyTransaction.notifyBeforeCompletion(DummyTransaction.java:230) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.tm.DummyTransaction.runPrepare(DummyTransaction.java:242) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:86) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:102) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:123) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:105) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:86) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.CacheImpl.endBatch(CacheImpl.java:615) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:80) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.jboss.as.clustering.registry.RegistryService.invoke(RegistryService.java:260) [jboss-as-clustering-registry-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.as.clustering.registry.RegistryService.stop(RegistryService.java:162) [jboss-as-clustering-registry-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:1911) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>         at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:1874) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
>         at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> &#27;[0m&#27;[31m05:48:31,754 ERROR [org.infinispan.transaction.tm.DummyTransaction] (MSC service thread 1-3) ISPN000109: beforeCompletion() failed for SynchronizationAdapter{localTransaction=LocalTransaction{remoteLockedNodes=null, isMarkedForRollback=false, transaction=DummyTransaction{xid=DummyXid{id=4}, status=1}, lockedKeys=null, backupKeyLocks=null, viewId=2} org.infinispan.transaction.synchronization.SyncLocalTransaction at 3} org.infinispan.transaction.synchronization.SynchronizationAdapter at 22: org.infinispan.CacheException: Could not prepare. 
>         at org.infinispan.transaction.synchronization.SynchronizationAdapter.beforeCompletion(SynchronizationAdapter.java:70) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.tm.DummyTransaction.notifyBeforeCompletion(DummyTransaction.java:230) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.tm.DummyTransaction.runPrepare(DummyTransaction.java:242) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:86) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:102) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:123) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:105) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:86) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.CacheImpl.endBatch(CacheImpl.java:615) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:80) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.jboss.as.clustering.registry.RegistryService.invoke(RegistryService.java:260) [jboss-as-clustering-registry-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.as.clustering.registry.RegistryService.stop(RegistryService.java:162) [jboss-as-clustering-registry-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:1911) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>         at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:1874) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
>         at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> Caused by: javax.transaction.xa.XAException
>         at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:160) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:122) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.synchronization.SynchronizationAdapter.beforeCompletion(SynchronizationAdapter.java:68) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         ... 16 more
> &#27;[0m&#27;[33m05:48:31,763 WARN  [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC00004: Failure during stop of service jboss.ejb.remoting.connector.client-mappings.registry.ejb: org.infinispan.CacheException: Unable to end batch
>         at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:107)
>         at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:86)
>         at org.infinispan.CacheImpl.endBatch(CacheImpl.java:615)
>         at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:80)
>         at org.jboss.as.clustering.registry.RegistryService.invoke(RegistryService.java:260)
>         at org.jboss.as.clustering.registry.RegistryService.stop(RegistryService.java:162)
>         at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:1911) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>         at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:1874) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
>         at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> Caused by: javax.transaction.RollbackException: Exception rolled back, status is: 9
>         at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:89)
>         at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:102)
>         at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:123)
>         at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:105)
>         ... 10 more
> &#27;[0m&#27;[0m05:48:31,791 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-2) JBAS010282: Stopped remote-connector-client-mappings cache from ejb container
> &#27;[0m&#27;[0m05:48:31,839 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000082: Stopping the RpcDispatcher
> &#27;[0m&#27;[0m05:48:31,899 INFO  [org.jboss.as.repository] (management-handler-thread - 3) JBAS014901: Content removed from location /home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-0/standalone/data/content/dc/274297a56acebcb3414b7407fa05d097f6691b/content
> &#27;[0m&#27;[0m05:48:31,902 INFO  [org.jboss.as.server] (management-handler-thread - 3) JBAS018558: Undeployed "node-name-app.jar"
> &#27;[0m05:48:31,906 INFO  [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual stopping of a server instance
> 05:48:32,069 INFO  [org.jboss.ejb.client.remoting] (Remoting "config-based-ejb-client-endpoint" task-2) EJBCLIENT000016: Channel Channel ID e21e278d (outbound) of Remoting connection 41171d93 to /127.0.0.1:4447 can no longer process messages
> &#27;[0m05:48:32,149 INFO  [org.jboss.ejb.client.remoting] (Remoting "node-1" task-3) EJBCLIENT000016: Channel Channel ID a99830e9 (outbound) of Remoting connection 6e843edc to /127.0.0.1:4447 can no longer process messages
> &#27;[0m05:48:32,256 INFO  [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual stopping of a server instance 
> 05:48:32,345 INFO  [org.jboss.ejb.client.remoting] (Remoting "config-based-ejb-client-endpoint" task-4) EJBCLIENT000016: Channel Channel ID bd97f0d8 (outbound) of Remoting connection 392bed82 to /127.0.0.1:4547 can no longer process messages

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Thu Oct 31 10:54:04 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 10:54:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1928) jboss-as-standalone.sh does
 not work on MacOS
In-Reply-To: <JIRA.12499212.1377185444000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499212.1377185444000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499212.1377185444000.26297.1383231244253@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas updated WFLY-1928:
---------------------------------

    Assignee: Stuart Douglas  (was: jaikiran pai)

    
> jboss-as-standalone.sh does not work on MacOS
> ---------------------------------------------
>
>                 Key: WFLY-1928
>                 URL: https://issues.jboss.org/browse/WFLY-1928
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Scripts
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Thomas Diesler
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.CR1
>
>
> {code}
> FuseFabric:karaf at root> process-start root 3
> bin/init.d/jboss-as-standalone.sh: line 12: /etc/init.d/functions: No such file or directory
> Error executing command: [bin/init.d/jboss-as-standalone.sh, start] exited with 1
> bin/init.d/jboss-as-standalone.sh: line 12: /etc/init.d/functions: No such file or directory
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 10:54:04 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 10:54:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-959) Allow more flexibility in the
 way EJB authentication is handled with regards to remoting and
 security-realms
In-Reply-To: <JIRA.12482951.1358783604000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12482951.1358783604000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12482951.1358783604000.26308.1383231244740@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas updated WFLY-959:
--------------------------------

    Assignee: Stuart Douglas  (was: jaikiran pai)

    
> Allow more flexibility in the way EJB authentication is handled with regards to remoting and security-realms
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-959
>                 URL: https://issues.jboss.org/browse/WFLY-959
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>            Reporter: Derek Horton
>            Assignee: Stuart Douglas
>
> My confusion is around the remoting/security-realm setup in the use case
> where multiple EJBs are deployed that use different security-domains and
> the EJBs will be invoked by remote standalone clients.  For example,
> ejbX needs to be in the sec-domain-X security-domain, while ejbY needs to
> be in the sec-domain-Y security-domain.
> In this situation, the authentication checks are going to be handled by
> the security-realm that is associated with the remote connector that is
> configured to be used by the EJB subsystem.
> It looks like the security-realm can either handle the authentication
> checks directly (properties file, ldap, etc) or it can defer to the
> jaas security-domain.  In both of those situations, it seems that the
> EJBs are limited to a single authentication point.  The EJB
> authentication is either going to be handled by a single security-realm
> or the security-realm will defer to a single security-domain.
> I could configure the security-domain to have multiple login modules.  I
> assume the same thing could be done with the security-realm.
> Basically the problem that I am trying to solve boils down to this:  the
> authentication checks for remote EJBs appear to be checked by either a
> single security-realm or a single security-domain.  Is there a way to
> change this?
> One idea I had was to add another remote connector to the EJB subsystem.
> Unfortunately, this does not appear to be possible.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 10:54:05 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 10:54:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-875) Singletons don't respect
 @TransactionAttribute/deployment descriptor in @PostConstruct.
In-Reply-To: <JIRA.12474183.1347347177000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12474183.1347347177000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12474183.1347347177000.26315.1383231245006@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas updated WFLY-875:
--------------------------------

    Assignee: Stuart Douglas  (was: jaikiran pai)

    
> Singletons don't respect @TransactionAttribute/deployment descriptor in @PostConstruct.
> ---------------------------------------------------------------------------------------
>
>                 Key: WFLY-875
>                 URL: https://issues.jboss.org/browse/WFLY-875
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>         Environment: JBoss 7.1.1
>            Reporter: S?awomir Wojtasiak
>            Assignee: Stuart Douglas
>              Labels: rhq
>         Attachments: jboss-as-helloworld-singleton.war
>
>
> Singletons don't respect any transaction attributes for their @PostConstruct methods and invokes them always with REQUIRED_NEW semantics. Following part of code is responsible for hardcoding these values for registered _SingletonLifecycleCMTTxInterceptor_ factories:
> {code:title=org.jboss.as.ejb3.component.singleton.SingletonComponentDescription.java|borderStyle=solid}
>  @Override
>                 public void configure(final DeploymentPhaseContext context, final ComponentDescription description, final ComponentConfiguration configuration) throws DeploymentUnitProcessingException {
>                     configuration.addPostConstructInterceptor(new SingletonLifecycleCMTTxInterceptor.Factory(TransactionAttributeType.REQUIRES_NEW), InterceptorOrder.ComponentPostConstruct.TRANSACTION_INTERCEPTOR);
>                     configuration.addPreDestroyInterceptor(new SingletonLifecycleCMTTxInterceptor.Factory(TransactionAttributeType.REQUIRES_NEW), InterceptorOrder.ComponentPreDestroy.TRANSACTION_INTERCEPTOR);
>                     if(description.isPassivationApplicable()) {
>                         configuration.addPrePassivateInterceptor(new SingletonLifecycleCMTTxInterceptor.Factory(TransactionAttributeType.REQUIRES_NEW), InterceptorOrder.ComponentPassivation.TRANSACTION_INTERCEPTOR);
>                         configuration.addPostActivateInterceptor(new SingletonLifecycleCMTTxInterceptor.Factory(TransactionAttributeType.REQUIRES_NEW), InterceptorOrder.ComponentPassivation.TRANSACTION_INTERCEPTOR);
>                     }
>                     configuration.addTimeoutViewInterceptor(TimerCMTTxInterceptor.FACTORY, InterceptorOrder.View.CMT_TRANSACTION_INTERCEPTOR);
>                 }
> {code}
> EJB 3.1 specification says, REQUIRED, REQUIRED_NEW and NOT_SUPPORTED attributes should be supported, where in case of REQUIRED a semantic of REQUIRED_NEW trancation attribute should be used:
> {panel:title=4.8.3 Transaction Semantics of Initialization and Destruction| borderStyle=dashed| borderColor=#ccc| titleBGColor=#F7D6C1| bgColor=#FFFFCE} 
> PostConstruct and PreDestroy methods of Singletons with container-managed transactions are transactional. From the bean developer?s view there is no client of a PostConstruct or PreDestroy method.
> A PostConstruct or PreDestroy method of a Singleton with container-managed transactions has transaction attribute REQUIRED, REQUIRES_NEW, or NOT_SUPPORTED (Required , RequiresNew, or NotSupported if the deployment descriptor is used to specify the transaction attribute).
> _Note that the container must start a new transaction if the REQUIRED (Required) transaction attribute is used. This guarantees, for example, that the transactional behavior of the PostConstruct method is the same regardless of whether it is initialized eagerly at container startup time or as a side effect of a first client invocation on the Singleton. The REQUIRED transaction attribute value is allowed so that specification of a transaction attribute for the Singleton PostConstruct/PreDestroy methods can be defaulted._
> {panel} 
> So there is not a problem with REQUIRED and REQUIRED_NEW transaction attributes, but NOT_SUPPORTED attribute is just not supported :)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Thu Oct 31 10:54:05 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 10:54:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1312) Restore EJB3 tests that
 deploy duplicate test deployment
In-Reply-To: <JIRA.12491023.1367572765000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12491023.1367572765000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12491023.1367572765000.26319.1383231245225@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas updated WFLY-1312:
---------------------------------

    Assignee: Stuart Douglas  (was: jaikiran pai)

    
> Restore EJB3 tests that deploy duplicate test deployment
> --------------------------------------------------------
>
>                 Key: WFLY-1312
>                 URL: https://issues.jboss.org/browse/WFLY-1312
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>            Reporter: Thomas Diesler
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.CR1
>
>
> There are a number of EJB3 tests that [have been disabled|https://github.com/wildfly/wildfly/commit/a22ea284c7a7761e4626e165cd79359ed3a9f62a] because they deploy a duplicate test deployment

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 10:54:05 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 10:54:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1383) Disable pooling of stateless
 EJBs by default
In-Reply-To: <JIRA.12492528.1369290890000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12492528.1369290890000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12492528.1369290890000.26322.1383231245346@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas updated WFLY-1383:
---------------------------------

    Assignee: Stuart Douglas  (was: jaikiran pai)

    
> Disable pooling of stateless EJBs by default
> --------------------------------------------
>
>                 Key: WFLY-1383
>                 URL: https://issues.jboss.org/browse/WFLY-1383
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: jaikiran pai
>            Assignee: Stuart Douglas
>
> A certain use case has shown that it's perhaps better to disable pooling of EJB stateless bean, by default. In AS7 we have always allowed disabling the pooling but we hadn't made it the default since we thought it might affect applications which have SLSBs with heavy @PostConstruct.
> A recent discussion has suggested that we disable the pooling by default and individual applications can enable it and set the relevant pool size themselves. The reasoning has been that, the default pool size that we ship with, anyway will have to be tweaked by the users since we can't really guess what an ideal pool size is. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 10:54:05 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 10:54:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1183) Configure EJB3/MDB with an
 individual thread pool for each EJB.
In-Reply-To: <JIRA.12487807.1363965045000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12487807.1363965045000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487807.1363965045000.26329.1383231245674@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas updated WFLY-1183:
---------------------------------

    Assignee: Stuart Douglas  (was: jaikiran pai)

    
> Configure EJB3/MDB with an individual thread pool for each EJB.
> ---------------------------------------------------------------
>
>                 Key: WFLY-1183
>                 URL: https://issues.jboss.org/browse/WFLY-1183
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>            Reporter: Jeremy Whiting
>            Assignee: Stuart Douglas
>
> For performance of an application to be scalable I need to configure sometimes a thread pool to an EJB. The pool is not shared with other EJB in the deployed application.
>  For example 
> PoolA - EJB Dog
> PoolB - EJB Cat
>  To configure this the ability no define the thread pool name for an EJB. Rather than an EJB to the shared thread pool as it currently works.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 10:54:05 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 10:54:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2161) JBAS014356 exception not
 thrown for @Asyncronous EJB methods
In-Reply-To: <JIRA.12501557.1380149806000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501557.1380149806000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501557.1380149806000.26333.1383231245820@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas updated WFLY-2161:
---------------------------------

    Assignee: Stuart Douglas  (was: jaikiran pai)

    
> JBAS014356 exception not thrown for @Asyncronous EJB methods
> ------------------------------------------------------------
>
>                 Key: WFLY-2161
>                 URL: https://issues.jboss.org/browse/WFLY-2161
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: James Livingston
>            Assignee: Stuart Douglas
>
> If you call an ejb method with default visibility (e.g. from a servlet in the same package), an EJBException with code JBAS014356 is thrown because the method is not public.
> If the method is annotated with @Asynchronous and returns void, the exception is not seen because the interceptor from AsyncFutureInterceptorFactory is used before NotBusinessMethodInterceptor, the exception is thrown in the worker thread instead.
> With a void return, the exception is silently dropped. With a Future<?> return, it will be set as the failure exception on the future rather than being thrown from the call.
> As per the forum reference we need to check the spec, but the validity of the business method should probably be checked before the handoff to the worker thread.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 10:54:06 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 10:54:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-863) On failed secured connection
 during EJB invocations from a remote server instance an incorrect error
 message is shown
In-Reply-To: <JIRA.12460788.1330980583000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12460788.1330980583000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12460788.1330980583000.26340.1383231246122@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas updated WFLY-863:
--------------------------------

    Assignee: Stuart Douglas  (was: jaikiran pai)

    
> On failed secured connection during EJB invocations from a remote server instance an incorrect error message is shown
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-863
>                 URL: https://issues.jboss.org/browse/WFLY-863
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>            Reporter: Ond?ej Chaloupka
>            Assignee: Stuart Douglas
>            Priority: Minor
>
> When EJB invocations from a remote server instance is used and remoting connector of the remote server is secured and the attempt to connection fails an incorrect exception is thrown. 
> In case of version 7.1.0.Final when authentication si not correctly defined then during deployment following exception is thrown:
> {code}
> ERROR [org.jboss.remoting.remote.connection] (Remoting "clientnode" read-1) JBREM000200: Remote connection failed: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.ejb3.dd-based-ejb-client-context."client-ear.ear": org.jboss.msc.service.StartException in service jboss.ejb3.dd-based-ejb-client-context."client-ear.ear": Failed to start service
>             at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1767) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1]
>             at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_23]
>             at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_23]
>             at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_23]
>     Caused by: java.lang.RuntimeException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
>             at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:91)
>             at org.jboss.as.ejb3.remote.DescriptorBasedEJBClientContextService.createRemotingConnections(DescriptorBasedEJBClientContextService.java:124)
>             at org.jboss.as.ejb3.remote.DescriptorBasedEJBClientContextService.start(DescriptorBasedEJBClientContextService.java:86)
>             at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1]
>             at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1]
>             ... 3 more
>     Caused by: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
>             at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:315) [jboss-remoting-3.2.2.GA-redhat-1.jar:3.2.2.GA-redhat-1]
>             at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:214) [jboss-remoting-3.2.2.GA-redhat-1.jar:3.2.2.GA-redhat-1]
>             at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) [xnio-api-3.0.3.GA-redhat-1.jar:3.0.3.GA-redhat-1]
>             at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189) [xnio-api-3.0.3.GA-redhat-1.jar:3.0.3.GA-redhat-1]
>             at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103) [xnio-api-3.0.3.GA-redhat-1.jar:3.0.3.GA-redhat-1]
>             at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) [xnio-api-3.0.3.GA-redhat-1.jar:3.0.3.GA-redhat-1]
>             at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189) [xnio-api-3.0.3.GA-redhat-1.jar:3.0.3.GA-redhat-1]
>             at org.xnio.ssl.JsseConnectedSslStreamChannel.handleReadable(JsseConnectedSslStreamChannel.java:180) [xnio-api-3.0.3.GA-redhat-1.jar:3.0.3.GA-redhat-1]
>             at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103) [xnio-api-3.0.3.GA-redhat-1.jar:3.0.3.GA-redhat-1]
>             at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) [xnio-api-3.0.3.GA-redhat-1.jar:3.0.3.GA-redhat-1]
>             at org.xnio.nio.NioHandle.run(NioHandle.java:90)
>             at org.xnio.nio.WorkerThread.run(WorkerThread.java:184)
>             at ...asynchronous invocation...(Unknown Source)
>             at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:270) [jboss-remoting-3.2.2.GA-redhat-1.jar:3.2.2.GA-redhat-1]
>             at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:251) [jboss-remoting-3.2.2.GA-redhat-1.jar:3.2.2.GA-redhat-1]
>             at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:349) [jboss-remoting-3.2.2.GA-redhat-1.jar:3.2.2.GA-redhat-1]
>             at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:337) [jboss-remoting-3.2.2.GA-redhat-1.jar:3.2.2.GA-redhat-1]
>             at org.jboss.as.remoting.RemoteOutboundConnectionService.connect(RemoteOutboundConnectionService.java:130) [jboss-as-remoting-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> {code}
> which is correct. But in case that the remote server is shut down, configuration is changed to use security connection then incorrect and confusing exception is thrown:
> {code}
> ERROR [org.jboss.ejb3.invocation] (EJB default - 2) JBAS014134: EJB Invocation failed on component CallingBean for method public abstract java.lang.String serverclient.CallingBeanRemote.call(): javax.ejb.EJBException: java.lang.RuntimeException: java.lang.IllegalStateException: No EJB receiver available for handling [appName:,modulename:myejb,distinctname:] combination
>             at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:166) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
>             at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:230) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
>             at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:304) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
>             at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:190) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
>             at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
>             at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropogatingInterceptor.processInvocation(EJBRemoteTransactionPropogatingInterceptor.java:80) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
>             at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
>             at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
>             at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
>             at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
>             at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
>             at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) [jboss-as-ee-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
>             at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
>             at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:43) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
>             at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
>             at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45) [jboss-as-ee-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
>             at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
>             at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
>             at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165) [jboss-as-ee-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
>             at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:300) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
>             at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$200(MethodInvocationMessageHandler.java:64) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
>             at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:194) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
>             at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [rt.jar:1.6.0_23]
>             at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [rt.jar:1.6.0_23]
>             at java.util.concurrent.FutureTask.run(FutureTask.java:138) [rt.jar:1.6.0_23]
>             at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_23]
>             at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_23]
>             at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_23]
>             at org.jboss.threads.JBossThread.run(JBossThread.java:122)
>     Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: No EJB receiver available for handling [appName:,modulename:myejb,distinctname:] combination
>             at serverclient.CallingBean.call(CallingBean.java:39) [serverclient-ejb.jar:]
>             at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_23]
>             at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_23]
>             at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_23]
>             at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_23]
>             at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72) [jboss-as-ee-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
>             at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
>             at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
>             at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:36) [jboss-as-ee-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
>             at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
>             at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
>             at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
>             at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
>             at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
>             at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
>             at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53) [jboss-as-ee-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
>             at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
>             at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
>             at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
>             at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:228) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
>             ... 27 more
>     Caused by: java.lang.IllegalStateException: No EJB receiver available for handling [appName:,modulename:myejb,distinctname:] combination
>             at org.jboss.ejb.client.EJBClientContext.requireEJBReceiver(EJBClientContext.java:516) [jboss-ejb-client-1.0.4.Final.jar:1.0.4.Final]
>             at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:84) [jboss-ejb-client-1.0.4.Final.jar:1.0.4.Final]
>             at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:175) [jboss-ejb-client-1.0.4.Final.jar:1.0.4.Final]
>             at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:136) [jboss-ejb-client-1.0.4.Final.jar:1.0.4.Final]
>             at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:121) [jboss-ejb-client-1.0.4.Final.jar:1.0.4.Final]
>             at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:104) [jboss-ejb-client-1.0.4.Final.jar:1.0.4.Final]
>             at $Proxy15.sayHello(Unknown Source)    at serverclient.CallingBean.call(CallingBean.java:34) [serverclient-ejb.jar:]
>             ... 46 more  
> {code}
> The exception seems that everything was connected correctly only module does not exist in remote context.
> In case of the AS7 Final version is not so problematic but when you take source codes from git then after deploying of application to client server which would like to connect to a secured remote server then no exception is thrown during deployment. Everything looks fine but after execution of remote call the confusing exception is thrown and it's hard to understand that the problem is in not connected context because of security.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Thu Oct 31 10:54:06 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 10:54:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-671) Failure in
 CalendarUtilTestCase.testEveryMinuteEveryHourEveryDay
In-Reply-To: <JIRA.12446129.1314950572000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12446129.1314950572000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12446129.1314950572000.26345.1383231246332@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas updated WFLY-671:
--------------------------------

    Assignee: Stuart Douglas  (was: jaikiran pai)

    
> Failure in CalendarUtilTestCase.testEveryMinuteEveryHourEveryDay
> ----------------------------------------------------------------
>
>                 Key: WFLY-671
>                 URL: https://issues.jboss.org/browse/WFLY-671
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>            Reporter: Carlo de Wolf
>            Assignee: Stuart Douglas
>            Priority: Minor
>             Fix For: Awaiting Volunteers
>
>
> I'm unable to compile AS 7.
> {noformat}
> Failed tests:   testEveryMinuteEveryHourEveryDay[379](org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase): Unexpected timeout value: java.util.GregorianCalendar[time=1314918060000,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=sun.util.calendar.ZoneInfo[id="Asia/Gaza",offset=7200000,dstSavings=3600000,useDaylight=true,transitions=144,lastRule=java.util.SimpleTimeZone[id=Asia/Gaza,offset=7200000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=7,startTime=60000,startTimeMode=0,endMode=3,endMonth=8,endDay=1,endDayOfWeek=6,endTime=7200000,endTimeMode=0]],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=2011,MONTH=8,WEEK_OF_YEAR=36,WEEK_OF_MONTH=1,DAY_OF_MONTH=2,DAY_OF_YEAR=245,DAY_OF_WEEK=6,DAY_OF_WEEK_IN_MONTH=1,AM_PM=0,HOUR=1,HOUR_OF_DAY=1,MINUTE=1,SECOND=0,MILLISECOND=0,ZONE_OFFSET=7200000,DST_OFFSET=0] expected:<60000> but was:<3660000>
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 10:54:06 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 10:54:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1805) It should be possible to pass
 objects via invocation context from the server side EJB to the client and
 read with a via client side interceptor
In-Reply-To: <JIRA.12497139.1374586120000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497139.1374586120000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497139.1374586120000.26349.1383231246541@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas updated WFLY-1805:
---------------------------------

    Assignee: Stuart Douglas  (was: jaikiran pai)

    
> It should be possible to pass objects via invocation context from the server side EJB to the client and read with a via client side interceptor
> -----------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1805
>                 URL: https://issues.jboss.org/browse/WFLY-1805
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>            Reporter: Wolf-Dieter Fink
>            Assignee: Stuart Douglas
>              Labels: ejb
>
> With former JBoss versions it was possible to pass context beside the method invocation from the client to the server and back. This was done via (AOP) interceptors.
> Since AS7 and WildFly the only possibility is to pass such context from the client to the server.
> It should also possible to pass serializeable objects from the server side to the client if the invocation returns and have a client side interceptor to read that informations.
> This was used to return i.e. tracking or additional usefull informations.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 10:54:06 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 10:54:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1314) Add a management operation to
 let remote EJB clients know that a particular server is no longer capable
 of handling a EJB request
In-Reply-To: <JIRA.12491045.1367598318000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12491045.1367598318000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12491045.1367598318000.26353.1383231246702@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas updated WFLY-1314:
---------------------------------

    Assignee: Stuart Douglas  (was: jaikiran pai)

    
> Add a management operation to let remote EJB clients know that a particular server is no longer capable of handling a EJB request
> ---------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1314
>                 URL: https://issues.jboss.org/browse/WFLY-1314
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>            Reporter: jaikiran pai
>            Assignee: Stuart Douglas
>
> While looking into another issue WFLY-1313 we realized that it might be a good idea to allow admins to have some kind of management operation where they could say that a particular server will no longer accept EJB invocations (for all deployments or maybe just a specific deployment). This would then allow the admins to issue such a operation and the remote EJB clients (via the EJB client library) would then realize that, they should no longer send out requests to that server node. This way the admins can then even undeploy the deployment or shutdown the server without having to worry about EJB invocations coming in and failing in-flight due to deployment being currently undeployed.
> From a EJB client library point of view, this essentially is a explicit "module unavailable" notification that the server will trigger to its connected clients.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 10:54:07 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 10:54:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2016) Security context associated
 with EJB asynchronous invocations can potentially be corrupted over time by
 the caller thread
In-Reply-To: <JIRA.12500173.1378452142000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500173.1378452142000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500173.1378452142000.26362.1383231247149@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas updated WFLY-2016:
---------------------------------

    Assignee: Stuart Douglas  (was: jaikiran pai)

    
> Security context associated with EJB asynchronous invocations can potentially be corrupted over time by the caller thread
> -------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2016
>                 URL: https://issues.jboss.org/browse/WFLY-2016
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB, Security
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: jaikiran pai
>            Assignee: Stuart Douglas
>
> Consider a servlet "S" which invokes on a asynchronous EJB "A". Let's assume "S" runs with a "foo" run-as role. Now when S invokes on "A", the run-as "foo" role is correctly propagated to the asynchronous EJB invocation. However, when the "S" invocation completes and potentially clears the security context (of any run-as role), the invocation(s) within the asynchronous EJB "A" too lose the corresponding security context role association. This is because the 2 threads (the servlet invocation one and the async EJB invocation one) literally share the same object instance of the SecurityContext.
> The expected behaviour is that the original security context (attributes) are copied over to the async invocation and updates to that security context later on in a separate thread shouldn't affect the ongoing async EJB invocation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 10:54:06 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 10:54:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-16) Intermittent failure in
 RemoteOutboundConnectionReconnectTestCase
In-Reply-To: <JIRA.12473474.1346412534000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12473474.1346412534000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12473474.1346412534000.26358.1383231246956@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas updated WFLY-16:
-------------------------------

    Assignee: Stuart Douglas  (was: jaikiran pai)

    
> Intermittent failure in RemoteOutboundConnectionReconnectTestCase
> -----------------------------------------------------------------
>
>                 Key: WFLY-16
>                 URL: https://issues.jboss.org/browse/WFLY-16
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>            Reporter: Kabir Khan
>            Assignee: Stuart Douglas
>            Priority: Critical
>             Fix For: 8.0.0.CR1
>
>
> Assigning to Jaikiran since I think this is ejb client
> This happened for IPv6 but I don't know if that has any relevance.
> The test has not been disabled
> {code}
> org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteOutboundConnectionReconnectTestCase.testRemoteServerRestarts
> Failing for the past 1 build (Since #3674 )
> Took 8.7 sec.
> add description
> Error Message
> Cannot deploy: server-two-module.jar
> Stacktrace
> org.jboss.arquillian.container.spi.client.container.DeploymentException: Cannot deploy: server-two-module.jar
>      at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:83)
>      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:145)
>      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:39)
>      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>      at java.lang.reflect.Method.invoke(Method.java:597)
>      at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>      at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
>      at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
>      at org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50)
>      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>      at java.lang.reflect.Method.invoke(Method.java:597)
>      at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>      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:39)
>      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>      at java.lang.reflect.Method.invoke(Method.java:597)
>      at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>      at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
>      at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57)
>      at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
>      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>      at java.lang.reflect.Method.invoke(Method.java:597)
>      at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>      at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
>      at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
>      at org.jboss.arquillian.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.deployment.ClientDeployer.deploy(ClientDeployer.java:93)
>      at org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteOutboundConnectionReconnectTestCase.testRemoteServerRestarts(RemoteOutboundConnectionReconnectTestCase.java:199)
>      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>      at java.lang.reflect.Method.invoke(Method.java:597)
>      at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
>      at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
>      at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
>      at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:270)
>      at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
>      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>      at java.lang.reflect.Method.invoke(Method.java:597)
>      at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>      at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
>      at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
>      at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
>      at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
>      at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
>      at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:53)
>      at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
>      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>      at java.lang.reflect.Method.invoke(Method.java:597)
>      at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>      at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
>      at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
>      at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
>      at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129)
>      at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
>      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>      at java.lang.reflect.Method.invoke(Method.java:597)
>      at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>      at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
>      at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89)
>      at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
>      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>      at java.lang.reflect.Method.invoke(Method.java:597)
>      at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>      at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
>      at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
>      at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
>      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>      at java.lang.reflect.Method.invoke(Method.java:597)
>      at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>      at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
>      at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
>      at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
>      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>      at java.lang.reflect.Method.invoke(Method.java:597)
>      at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>      at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
>      at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
>      at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111)
>      at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263)
>      at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226)
>      at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
>      at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
>      at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240)
>      at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
>      at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
>      at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
>      at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
>      at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
>      at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
>      at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
>      at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
>      at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185)
>      at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
>      at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
>      at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
>      at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
>      at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
>      at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234)
>      at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133)
>      at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114)
>      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>      at java.lang.reflect.Method.invoke(Method.java:597)
>      at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188)
>      at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166)
>      at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
>      at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101)
>      at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
> Caused by: java.lang.Exception: {"JBAS014771: Services with missing/unavailable dependencies" => [
>     "jboss.naming.context.java.app.server-two-module.server-two-module.EchoOnServerTwo Missing[JBAS014861: <one or more transitive dependencies>]",
>     "jboss.naming.context.java.global.server-two-module.\"EchoOnServerTwo!org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteEcho\" Missing[JBAS014861: <one or more transitive dependencies>]",
>     "jboss.deployment.unit.\"server-two-module.jar\".component.EchoOnServerTwo.VIEW.\"org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteEcho\".REMOTE Missing[JBAS014861: <one or more transitive dependencies>]",
>     "jboss.deployment.unit.\"server-two-module.jar\".deploymentCompleteService Missing[JBAS014861: <one or more transitive dependencies>]",
>     "jboss.naming.context.java.module.server-two-module.server-two-module.\"EchoOnServerTwo!org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteEcho\" Missing[JBAS014861: <one or more transitive dependencies>]",
>     "jboss.deployment.unit.\"server-two-module.jar\".component.EchoOnServerTwo.START Missing[JBAS014861: <one or more transitive dependencies>]",
>     "jboss.deployment.unit.\"server-two-module.jar\".moduleDeploymentRuntimeInformation Missing[JBAS014861: <one or more transitive dependencies>]",
>     "jboss.naming.context.java.module.server-two-module.server-two-module.EchoOnServerTwo Missing[JBAS014861: <one or more transitive dependencies>]",
>     "jboss.naming.context.java.app.server-two-module.server-two-module.\"EchoOnServerTwo!org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteEcho\" Missing[JBAS014861: <one or more transitive dependencies>]",
>     "jboss.deployment.unit.\"server-two-module.jar\".jndiDependencyService Missing[JBAS014861: <one or more transitive dependencies>]",
>     "jboss.naming.context.java.global.server-two-module.EchoOnServerTwo Missing[JBAS014861: <one or more transitive dependencies>]"
> ]}
>      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:52)
>      at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:77)
>      ... 123 more
> Standard Output
> 02:31:11,030 INFO  [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual starting of a server instance
> 02:31:11,053 INFO  [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Starting container with: [/opt/jdk1.6.0_29/bin/java, -Xmx512m, -XX:MaxPermSize=256m, -Djboss.dist=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/../../../build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT, -Djava.net.preferIPv4Stack=false, -Djava.net.preferIPv6Addresses=true, -Dts.timeout.factor=100, -Dnode0=::1, -Dnode1=fccc::2, -Dmcast=ff01::1, -Djbossas.ts.submodule.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode, -Djbossas.ts.integ.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/.., -Djbossas.ts.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/../.., -Djbossas.project.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/../../.., -Djboss.dist=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/../../../build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT, -Djboss.inst=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/target/jbossas, -Djboss.node.name=default-jbossas, -ea, -Djboss.home.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/target/jbossas, -Dorg.jboss.boot.log.file=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/target/jbossas/standalone/log/boot.log, -Dlogging.configuration=file:/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/target/jbossas/standalone/configuration/logging.properties, -Djboss.bundles.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/../../../build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT/bundles, -jar, /home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/target/jbossas/jboss-modules.jar, -mp, /home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/../../../build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT/modules:/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/target/modules, -jaxpmodule, javax.xml.jaxp-provider, org.jboss.as.standalone, -server-config, standalone-ha.xml]
> 02:31:11,906 INFO  [org.jboss.modules] JBoss Modules version 1.1.3.GA
> 02:31:12,166 INFO  [org.jboss.msc] JBoss MSC version 1.0.2.GA
> 02:31:12,257 INFO  [org.jboss.as] JBAS015899: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" starting
> 02:31:14,791 INFO  [org.jboss.as.server] JBAS015888: Creating http management service using socket-binding (management-http)
> 02:31:14,798 INFO  [org.xnio] XNIO Version 3.0.5.GA
> 02:31:14,827 INFO  [org.xnio.nio] XNIO NIO Implementation Version 3.0.5.GA
> 02:31:14,848 INFO  [org.jboss.as.configadmin] JBAS016200: Activating ConfigAdmin Subsystem
> 02:31:14,849 INFO  [org.jboss.as.logging] JBAS011502: Removing bootstrap log handlers
> &#27;[0m02:31:14,889 INFO  [org.jboss.remoting] (MSC service thread 1-3) JBoss Remoting version 3.2.8.GA
> &#27;[0m&#27;[0m02:31:14,916 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 34) JBAS010280: Activating Infinispan subsystem.
> &#27;[0m&#27;[0m02:31:14,979 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 38) JBAS010260: Activating JGroups subsystem.
> &#27;[0m&#27;[0m02:31:14,991 INFO  [org.jboss.as.osgi] (ServerService Thread Pool -- 45) JBAS011906: Activating OSGi Subsystem
> &#27;[0m&#27;[0m02:31:15,009 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 44) JBAS011800: Activating Naming Subsystem
> &#27;[0m&#27;[0m02:31:15,015 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 50) JBAS013171: Activating Security Subsystem
> &#27;[0m&#27;[0m02:31:15,047 INFO  [org.jboss.as.security] (MSC service thread 1-1) JBAS013170: Current PicketBox version=4.0.13.Final
> &#27;[0m&#27;[0m02:31:15,161 INFO  [org.jboss.as.connector.logging] (MSC service thread 1-6) JBAS010408: Starting JCA Subsystem (JBoss IronJacamar 1.0.12.Final)
> &#27;[0m&#27;[0m02:31:15,164 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 54) JBAS015537: Activating WebServices Extension
> &#27;[0m&#27;[0m02:31:15,332 INFO  [org.jboss.as.naming] (MSC service thread 1-2) JBAS011802: Starting Naming Service
> &#27;[0m&#27;[0m02:31:15,371 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-6) JBAS015400: Bound mail session [java:jboss/mail/Default]
> &#27;[0m&#27;[31m02:31:15,331 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC00001: Failed to start service jboss.remoting.endpoint.subsystem: org.jboss.msc.service.StartException in service jboss.remoting.endpoint.subsystem: Failed to start service
>      at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1767) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>      at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
>      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
>      at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> Caused by: java.lang.NullPointerException
>      at sun.nio.ch.Util.atBugLevel(Util.java:448) [rt.jar:1.6.0_29]
>      at sun.nio.ch.SelectorImpl.<init>(SelectorImpl.java:40) [rt.jar:1.6.0_29]
>      at sun.nio.ch.EPollSelectorImpl.<init>(EPollSelectorImpl.java:47) [rt.jar:1.6.0_29]
>      at sun.nio.ch.EPollSelectorProvider.openSelector(EPollSelectorProvider.java:18) [rt.jar:1.6.0_29]
>      at java.nio.channels.Selector.open(Selector.java:209) [rt.jar:1.6.0_29]
>      at org.xnio.nio.NioXnioWorker.<init>(NioXnioWorker.java:112)
>      at org.xnio.nio.NioXnio.createWorker(NioXnio.java:126)
>      at org.jboss.remoting3.EndpointImpl.construct(EndpointImpl.java:137)
>      at org.jboss.remoting3.Remoting.createEndpoint(Remoting.java:60)
>      at org.jboss.remoting3.Remoting.createEndpoint(Remoting.java:73)
>      at org.jboss.as.remoting.EndpointService.start(EndpointService.java:71)
>      at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>      at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>      ... 3 more
> &#27;[0m&#27;[0m02:31:15,747 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 30) JBAS010403: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> &#27;[0m&#27;[0m02:31:16,070 INFO  [org.jboss.ws.common.management.AbstractServerConfig] (MSC service thread 1-3) JBoss Web Services - Stack CXF Server 4.1.0.Beta2
> &#27;[0m&#27;[0m02:31:16,117 INFO  [org.apache.coyote.ajp.AjpProtocol] (MSC service thread 1-4) Starting Coyote AJP/1.3 on ajp-/0:0:0:0:0:0:0:1%1:8009
> &#27;[0m&#27;[0m02:31:16,117 INFO  [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-5) Starting Coyote HTTP/1.1 on http-/0:0:0:0:0:0:0:1%1:8080
> &#27;[0m&#27;[0m02:31:16,357 INFO  [org.jboss.modcluster.ModClusterService] (ServerService Thread Pool -- 56) Initializing mod_cluster 1.2.1.Final
> &#27;[0m&#27;[0m02:31:16,437 INFO  [org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl] (ServerService Thread Pool -- 56) Listening to proxy advertisements on ff01:0:0:0:0:0:0:3:23,364
> &#27;[0m&#27;[0m02:31:16,718 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 34) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> &#27;[0m&#27;[0m02:31:16,742 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 34) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> &#27;[0m&#27;[0m02:31:16,908 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-3) JBAS015012: Started FileSystemDeploymentService for directory /home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/target/jbossas/standalone/deployments
> &#27;[0m&#27;[0m02:31:16,927 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015876: Starting deployment of "dep1.jar"
> &#27;[0m&#27;[0m02:31:16,960 INFO  [org.jboss.as.remoting] (MSC service thread 1-6) JBAS017100: Listening on [::1]:9999
> &#27;[0m&#27;[0m02:31:16,977 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
> &#27;[0m&#27;[0m02:31:17,615 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-2) JNDI bindings for session bean named ShutdownBean in deployment unit deployment "dep1.jar" are as follows:
>      java:global/dep1/ShutdownBean!org.jboss.as.test.manualmode.ejb.shutdown.RemoteEcho
>      java:app/dep1/ShutdownBean!org.jboss.as.test.manualmode.ejb.shutdown.RemoteEcho
>      java:module/ShutdownBean!org.jboss.as.test.manualmode.ejb.shutdown.RemoteEcho
>      java:jboss/exported/dep1/ShutdownBean!org.jboss.as.test.manualmode.ejb.shutdown.RemoteEcho
>      java:global/dep1/ShutdownBean
>      java:app/dep1/ShutdownBean
>      java:module/ShutdownBean
> &#27;[0m&#27;[0m02:31:17,617 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-2) JNDI bindings for session bean named LatchBean in deployment unit deployment "dep1.jar" are as follows:
>      java:global/dep1/LatchBean!org.jboss.as.test.manualmode.ejb.shutdown.RemoteLatch
>      java:app/dep1/LatchBean!org.jboss.as.test.manualmode.ejb.shutdown.RemoteLatch
>      java:module/LatchBean!org.jboss.as.test.manualmode.ejb.shutdown.RemoteLatch
>      java:jboss/exported/dep1/LatchBean!org.jboss.as.test.manualmode.ejb.shutdown.RemoteLatch
>      java:global/dep1/LatchBean
>      java:app/dep1/LatchBean
>      java:module/LatchBean
> &#27;[0m&#27;[0m02:31:17,619 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-2) JNDI bindings for session bean named RealEcho in deployment unit deployment "dep1.jar" are as follows:
>      java:global/dep1/RealEcho!org.jboss.as.test.manualmode.ejb.shutdown.RemoteEcho
>      java:app/dep1/RealEcho!org.jboss.as.test.manualmode.ejb.shutdown.RemoteEcho
>      java:module/RealEcho!org.jboss.as.test.manualmode.ejb.shutdown.RemoteEcho
>      java:jboss/exported/dep1/RealEcho!org.jboss.as.test.manualmode.ejb.shutdown.RemoteEcho
>      java:global/dep1/RealEcho
>      java:app/dep1/RealEcho
>      java:module/RealEcho
> &#27;[0m&#27;[0m02:31:18,940 INFO  [org.jboss.as.server] (Controller Boot Thread) JBAS018559: Deployed "dep1.jar"
> &#27;[0m&#27;[0m02:31:18,951 INFO  [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014777:   Services which failed to start:      service jboss.remoting.endpoint.subsystem: org.jboss.msc.service.StartException in service jboss.remoting.endpoint.subsystem: Failed to start service
> &#27;[0m&#27;[0m02:31:18,992 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://::1:9990/management
> &#27;[0m&#27;[0m02:31:18,994 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://::1:9990
> &#27;[0m&#27;[31m02:31:18,996 ERROR [org.jboss.as] (Controller Boot Thread) JBAS015875: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" started (with errors) in 7657ms - Started 185 of 364 services (34 services failed or missing dependencies, 144 services are passive or on-demand)
> &#27;[0m&#27;[0m02:31:19,141 INFO  [org.jboss.as.repository] (management-handler-thread - 1) JBAS014900: Content added at location /home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/target/jbossas/standalone/data/content/34/cf5c1cb3656c84a2615763b9f95b3a16536c40/content
> &#27;[0m&#27;[0m02:31:19,164 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015876: Starting deployment of "server-two-module.jar"
> &#27;[0m&#27;[0m02:31:19,227 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-1) JNDI bindings for session bean named EchoOnServerTwo in deployment unit deployment "server-two-module.jar" are as follows:
>      java:global/server-two-module/EchoOnServerTwo!org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteEcho
>      java:app/server-two-module/EchoOnServerTwo!org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteEcho
>      java:module/EchoOnServerTwo!org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteEcho
>      java:jboss/exported/server-two-module/EchoOnServerTwo!org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteEcho
>      java:global/server-two-module/EchoOnServerTwo
>      java:app/server-two-module/EchoOnServerTwo
>      java:module/EchoOnServerTwo
> &#27;[0m&#27;[0m02:31:19,578 INFO  [org.jboss.as.server] (management-handler-thread - 1) JBAS015870: Deploy of deployment "server-two-module.jar" was rolled back with failure message {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.naming.context.java.app.server-two-module.server-two-module.EchoOnServerTwo Missing[JBAS014861: <one or more transitive dependencies>]","jboss.naming.context.java.global.server-two-module.\"EchoOnServerTwo!org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteEcho\" Missing[JBAS014861: <one or more transitive dependencies>]","jboss.deployment.unit.\"server-two-module.jar\".component.EchoOnServerTwo.VIEW.\"org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteEcho\".REMOTE Missing[JBAS014861: <one or more transitive dependencies>]","jboss.deployment.unit.\"server-two-module.jar\".deploymentCompleteService Missing[JBAS014861: <one or more transitive dependencies>]","jboss.naming.context.java.module.server-two-module.server-two-module.\"EchoOnServerTwo!org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteEcho\" Missing[JBAS014861: <one or more transitive dependencies>]","jboss.deployment.unit.\"server-two-module.jar\".component.EchoOnServerTwo.START Missing[JBAS014861: <one or more transitive dependencies>]","jboss.deployment.unit.\"server-two-module.jar\".moduleDeploymentRuntimeInformation Missing[JBAS014861: <one or more transitive dependencies>]","jboss.naming.context.java.module.server-two-module.server-two-module.EchoOnServerTwo Missing[JBAS014861: <one or more transitive dependencies>]","jboss.naming.context.java.app.server-two-module.server-two-module.\"EchoOnServerTwo!org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteEcho\" Missing[JBAS014861: <one or more transitive dependencies>]","jboss.deployment.unit.\"server-two-module.jar\".jndiDependencyService Missing[JBAS014861: <one or more transitive dependencies>]","jboss.naming.context.java.global.server-two-module.EchoOnServerTwo Missing[JBAS014861: <one or more transitive dependencies>]"]}
> &#27;[0m&#27;[0m02:31:19,652 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015877: Stopped deployment server-two-module.jar in 97ms
> &#27;[0m
>  Help us localize this page Page generated: Aug 31, 2012 7:20:23 AMJenkins ver. 1.473
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Thu Oct 31 10:54:07 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 10:54:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-753) Enable the
	CalendarBasedTimeoutTestCase
In-Reply-To: <JIRA.12445932.1314788908000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12445932.1314788908000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12445932.1314788908000.26365.1383231247268@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas updated WFLY-753:
--------------------------------

    Assignee: Stuart Douglas  (was: jaikiran pai)

    
> Enable the CalendarBasedTimeoutTestCase
> ---------------------------------------
>
>                 Key: WFLY-753
>                 URL: https://issues.jboss.org/browse/WFLY-753
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>            Reporter: jaikiran pai
>            Assignee: Stuart Douglas
>             Fix For: Awaiting Volunteers
>
>
> org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase is currently disabled since it's a bit slow as it runs against all known timezones. This needs to be re-enabled and maybe moved to a different profile.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 10:54:07 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 10:54:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-835) @Resource UserTransaction
 error when file passivation store is selected
In-Reply-To: <JIRA.12486327.1362495445000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12486327.1362495445000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12486327.1362495445000.26371.1383231247511@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas updated WFLY-835:
--------------------------------

    Assignee: Stuart Douglas  (was: jaikiran pai)

    
> @Resource UserTransaction error when file passivation store is selected
> -----------------------------------------------------------------------
>
>                 Key: WFLY-835
>                 URL: https://issues.jboss.org/browse/WFLY-835
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>         Environment: Ubuntu 11.10, Intel? Core? i3-2120 CPU @ 3.30GHz ? 4 
>            Reporter: Abraham Cabanillas Piera
>            Assignee: Stuart Douglas
>            Priority: Critical
>              Labels: jboss
>
> The following exception is launched when the server tries to passivate into the file passivation storage a stateful EJB session with UserTransaction injected as a resource:
> {noformat}
> [org.jboss.as.ejb3.cache.spi.impl.PassivateTask] (pool-10-thread-1) JBAS014538: Failed to passivate {[-36, 0, 14, -43, 72, 10, 76, -28, -105, -108, 24, 45, -70, -58, -48, -107]}: java.lang.RuntimeException: JBAS014538: Failed to passivate {[-36, 0, 14, -43, 72, 10, 76, -28, -105, -108, 24, 45, -70, -58, -48, -107]}
> 	at org.jboss.as.ejb3.cache.spi.impl.FilePersistentObjectStore.store(FilePersistentObjectStore.java:248) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	at org.jboss.as.ejb3.cache.spi.impl.FilePersistentObjectStore.store(FilePersistentObjectStore.java:52) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	at org.jboss.as.ejb3.cache.impl.backing.SimpleBackingCacheEntryStore.passivate(SimpleBackingCacheEntryStore.java:155) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberContainer.passivate(SerializationGroupMemberContainer.java:288) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberContainer.passivate(SerializationGroupMemberContainer.java:50) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	at org.jboss.as.ejb3.cache.impl.backing.PassivatingBackingCacheImpl.passivate(PassivatingBackingCacheImpl.java:190) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	at org.jboss.as.ejb3.cache.impl.backing.PassivatingBackingCacheImpl.passivate(PassivatingBackingCacheImpl.java:60) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	at org.jboss.as.ejb3.cache.spi.impl.PassivateTask.run(PassivateTask.java:45) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_13]
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_13]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_13]
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) [rt.jar:1.7.0_13]
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) [rt.jar:1.7.0_13]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_13]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_13]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_13]
> Caused by: java.io.NotSerializableException: org.jboss.tm.usertx.client.ServerVMClientUserTransaction
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:891)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> 	at org.jboss.marshalling.river.BlockMarshaller.doWriteObject(BlockMarshaller.java:69)
> 	at org.jboss.marshalling.river.BlockMarshaller.writeObject(BlockMarshaller.java:60)
> 	at org.jboss.marshalling.MarshallerObjectOutputStream.writeObjectOverride(MarshallerObjectOutputStream.java:54)
> 	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:342) [rt.jar:1.7.0_13]
> 	at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberImpl.writeObject(SerializationGroupMemberImpl.java:368) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_13]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_13]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_13]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_13]
> 	at org.jboss.marshalling.reflect.SerializableClass.callWriteObject(SerializableClass.java:175)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1007)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> 	at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62)
> 	at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119)
> 	at org.jboss.as.ejb3.cache.spi.impl.FilePersistentObjectStore.store(FilePersistentObjectStore.java:239) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	... 15 more
> Caused by: an exception which occurred:
> 	in field userTransaction
> 	in field instance
> 	in field instance
> 	in object org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberImpl at 6a4de0c9
> {noformat}
> The EJB subsystem configuration is:
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:ejb3:1.2">
>             <session-bean>
>                 <stateless>
>                     <bean-instance-pool-ref pool-name="slsb-strict-max-pool"/>
>                 </stateless>
>                 <stateful default-access-timeout="10000" cache-ref="passivating"/>
>                 <singleton default-access-timeout="5000"/>
>             </session-bean>
>             <mdb>
>                 <resource-adapter-ref resource-adapter-name="hornetq-ra"/>
>                 <bean-instance-pool-ref pool-name="mdb-strict-max-pool"/>
>             </mdb>
>             <pools>
>                 <bean-instance-pools>
>                     <strict-max-pool name="slsb-strict-max-pool" max-pool-size="50" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
>                     <strict-max-pool name="mdb-strict-max-pool" max-pool-size="20" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
>                 </bean-instance-pools>
>             </pools>
>             <caches>
>                 <cache name="simple" aliases="NoPassivationCache"/>
>                 <cache name="passivating" passivation-store-ref="file" aliases="SimpleStatefulCache"/>
>             </caches>
>             <passivation-stores>
>                 <file-passivation-store name="file" idle-timeout="10" idle-timeout-unit="SECONDS"/>
>             </passivation-stores>
>             <async thread-pool-name="default"/>
>             <timer-service thread-pool-name="default">
>                 <data-store path="timer-service-data" relative-to="jboss.server.data.dir"/>
>             </timer-service>
>             <remote connector-ref="remoting-connector" thread-pool-name="default"/>
>             <thread-pools>
>                 <thread-pool name="default">
>                     <max-threads count="100"/>
>                     <keepalive-time time="100" unit="milliseconds"/>
>                 </thread-pool>
>             </thread-pools>
>             <iiop enable-by-default="false" use-qualified-name="false"/>
>         </subsystem>
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Thu Oct 31 10:54:07 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 10:54:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-823) NPE from EJB code when
 shutting down JBoss server
In-Reply-To: <JIRA.12488088.1364314697000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12488088.1364314697000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488088.1364314697000.26375.1383231247693@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas updated WFLY-823:
--------------------------------

    Assignee: Stuart Douglas  (was: jaikiran pai)

    
> NPE from EJB code when shutting down JBoss server
> -------------------------------------------------
>
>                 Key: WFLY-823
>                 URL: https://issues.jboss.org/browse/WFLY-823
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>         Environment: 64 bit Linux 
>            Reporter: John Leinaweaver
>            Assignee: Stuart Douglas
>            Priority: Minor
>              Labels: jboss
>
> (apologies if I have the wrong version in this bug report)
> This is a followup from discussion
> https://community.jboss.org/message/804610#804610   (message 33).
> Using build #1498 from the nightly snapshot
> jboss-as-7.x-nightly.zip
> When the JBoss server is shut down with cntl-c, a NPE in the EJB stack was exposed.   I've seen this once, hopefully the stack trace provides enough.
> Get the server log here, and search for "NullPointerEx"
> https://community.jboss.org/servlet/JiveServlet/download/804402-80854/server.log.zip

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 10:54:08 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 10:54:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1763) Escaped transactions stay
 associated with a HTTP request thread after they timeout
In-Reply-To: <JIRA.12497398.1374837857000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497398.1374837857000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497398.1374837857000.26388.1383231248308@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas updated WFLY-1763:
---------------------------------

    Assignee: Stuart Douglas  (was: jaikiran pai)

    
> Escaped transactions stay associated with a HTTP request thread after they timeout
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-1763
>                 URL: https://issues.jboss.org/browse/WFLY-1763
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Transactions
>         Environment: JBoss EAP 6.1
>            Reporter: Tom Ross
>            Assignee: Stuart Douglas
>
> When a transaction times out during execution of HTTP request and an inadequate error handling lets it escape the next HTTP request gets exception:
> {noformat}
> 20130528,17:20:05,561 ERROR [CheckupAction] DB-HIBERNATE: ERROR: xx.yyy.zzz.utils.TransactionAdapterSDB$TransactionSDBException: java.lang.RuntimeException: javax.transaction.NotSupportedException: BaseTransaction.checkTransactionState - ARJUNA016051: 
> thread is already associated with a transaction!
>         at xx.yyy.zzz.utils.TransactionAdapterSDB.begin(TransactionAdapterSDB.java:85) [WebPortalCore.jar:]
>         at xx.yyy.apps.crmtrk.web.component.HibernateSessionHandler.getHBS(HibernateSessionHandler.java:30) [WebPortalCore.jar:]
>         at xx.yyy.apps.crmtrk.web.action.HibernateAction.getHBS(HibernateAction.java:91) [WebPortalCore.jar:]
>         at xx.yyy.apps.crmtrk.web.action.CheckupAction.execute(CheckupAction.java:643) [classes:]
>         at com.opensymphony.xwork.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:283) [xwork-1.0.5.jar:]
>         at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:166) [xwork-1.0.5.jar:]
>         at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:35) [xwork-1.0.5.jar:]
>         at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:164) [xwork-1.0.5.jar:]
>         at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:35) [xwork-1.0.5.jar:]
>         at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:164) [xwork-1.0.5.jar:]
>         at xx.yyy.apps.crmtrk.web.interceptor.FileUploadInterceptor.intercept(FileUploadInterceptor.java:80) 
> {noformat}
> This does not happen to transactions that did not timed out. They seemed to be cleaned up.
> This is due to the TransactionRollbackSetupAction class that supposed to make sure that there are not transaction leaks in EE request. There is a method checkTransactionStatus() that performs a check on an escaped transaction and does a rollback() if it finds a transaction with following status: 
> {noformat}
> 	switch (status) {
>                 case Status.STATUS_ACTIVE:
>                 case Status.STATUS_COMMITTING:
>                 case Status.STATUS_MARKED_ROLLBACK:
>                 case Status.STATUS_PREPARING:
>                 case Status.STATUS_ROLLING_BACK:
>                 case Status.STATUS_PREPARED:
>                     try {
>                         TransactionLogger.ROOT_LOGGER.transactionStillOpen(status);
>                         tm.rollback();
>                     } catch (Exception ex) {
>                         TransactionLogger.ROOT_LOGGER.unableToRollBack(ex);
>                     }
>             }
> {noformat}
> The status of a timed out transaction is STATUS_ROLLEDBACK which explains why it escapes this cleanup attempt.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 10:54:07 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 10:54:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1766) The @Local annotation on a
 session bean "overrides" information about @Local interfaces implemented
 through keyword "implements"
In-Reply-To: <JIRA.12497425.1374855457000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497425.1374855457000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497425.1374855457000.26378.1383231247883@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas updated WFLY-1766:
---------------------------------

    Assignee: Stuart Douglas  (was: jaikiran pai)

    
> The @Local annotation on a session bean "overrides" information about @Local interfaces implemented through keyword "implements"
> --------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1766
>                 URL: https://issues.jboss.org/browse/WFLY-1766
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Matus Abaffy
>            Assignee: Stuart Douglas
>
> I have the following interfaces
> {code}
> public interface Bar { }
> {code}
> {code}
> @Local
> public interface Foo { }
> {code}
> and a session bean
> {code}
> @Local(Bar.class)
> @Stateful
> public class SessionBean implements Foo { }
> {code}
> EJB 3.2 specification (4.9.7 Session Bean?s Business Interface) states:
> "any interface of the bean class is explicitly designated as a business interface of the bean by either of the following means:
> ? using the Local or Remote annotation with a non-empty value on the bean class
> ? using the Local or Remote annotation on the interface
> ? in the deployment descriptor"
> Therefore, I assume SessionBean should expose both Bar and Foo as local business interfaces. However, only Bar is exposed:
> {noformat}
> ...
> INFO [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-7) JNDI bindings for session bean named SessionBean in deployment unit deployment "pckg.war" are as follows:
> 	java:global/pckg/SessionBean!org.jboss. ... .Bar
> 	java:app/pckg/SessionBean!org.jboss. ... .Bar
> 	java:module/SessionBean!org.jboss. ... .Bar
> 	java:global/pckg/SessionBean
> 	java:app/pckg/SessionBean
> 	java:module/SessionBean
> {noformat}
> It seems that the @Local annotation on a session bean class "overrides" all information about @Local interfaces implemented using the keyword "implements". (It does not ignore @Remote interfaces implemented using the keyword "implements".)
> The @Remote annotation on a session bean class works analogically - it causes @Remote interfaces implemented using the keyword "implements" not to be contained in the set of remote business interfaces.
> I haven't tried yet what happens if I declare another interface(s) for certain session beans as local/remote in the deployment descriptor - whether those defined in the java classes become "overriden". But I'd like to know what SHOULD happen. If it is not clear from the EJB spec., the exact behaviour in such case should be stated specifically for Wildfly - I'd be grateful for any links to such information.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Thu Oct 31 10:54:04 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 10:54:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1535) SSLEJBRemoteClientTestCase
 runs into intermittent failures
In-Reply-To: <JIRA.12494315.1371223824000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494315.1371223824000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494315.1371223824000.26300.1383231244364@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas updated WFLY-1535:
---------------------------------

    Assignee: Stuart Douglas  (was: jaikiran pai)

    
> SSLEJBRemoteClientTestCase runs into intermittent failures
> ----------------------------------------------------------
>
>                 Key: WFLY-1535
>                 URL: https://issues.jboss.org/browse/WFLY-1535
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: jaikiran pai
>            Assignee: Stuart Douglas
>            Priority: Critical
>             Fix For: 8.0.0.CR1
>
>
> SSLEJBRemoteClientTestCase runs into intermittent failures on TeamCity. To make matters worse, a failure in one test method can have a side effect on other test methods in that testcase, given the way it's written. The entire run is here http://teamcity.cafe-babe.org/viewLog.html?buildId=5251&tab=buildResultsDiv&buildTypeId=bt27.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 10:54:08 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 10:54:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1554) Service changes due to
 rollback should be completed before operation completes
In-Reply-To: <JIRA.12494592.1371596537000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494592.1371596537000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494592.1371596537000.26382.1383231248065@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas updated WFLY-1554:
---------------------------------

    Assignee: Stuart Douglas  (was: jaikiran pai)

    
> Service changes due to rollback should be completed before operation completes
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-1554
>                 URL: https://issues.jboss.org/browse/WFLY-1554
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Tomaz Cerar
>            Assignee: Stuart Douglas
>
> "As executeAndRollbackOperation() result is retrieved but actual rollback of deployment is is not complete."
> That's a bug then. Service changes due to rollback should be completed before the operation returns. 
> for more details see https://github.com/wildfly/wildfly/pull/4664
> and DeploymentScannerTestCase

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 10:54:08 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 10:54:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-803) "NullPointerException" in
 RemotingConnectionEJBReceiver constructor if misconfigured
In-Reply-To: <JIRA.12484178.1360101353000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12484178.1360101353000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12484178.1360101353000.26392.1383231248487@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas updated WFLY-803:
--------------------------------

    Assignee: Stuart Douglas  (was: jaikiran pai)

    
> "NullPointerException" in RemotingConnectionEJBReceiver constructor if misconfigured
> ------------------------------------------------------------------------------------
>
>                 Key: WFLY-803
>                 URL: https://issues.jboss.org/browse/WFLY-803
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Tested with 7.2.0 Alpha snapshot of 2013-02-05
> Sample project is build with Java 1.7
>            Reporter: Wolfgang Knauf
>            Assignee: Stuart Douglas
>            Priority: Minor
>         Attachments: StatelessStandaloneClient.zip
>
>
> While experimenting with EJB remote access, I got confused with the proper configuration ;-). This resulted in a NullPointerException in one of your EJB client classes, and I think this should be handled by a meaningful error message.
> I performed a lookup for "ejb:Stateless/StatelessEJB//GeometricModelBean!de.fhw.komponentenarchitekturen.knauf.stateless.GeometricModelRemote" => this means I want to use the JNDI lookup.
> But in "jndi.properties", I used this: "jboss.naming.client.ejb.context=true" => This should probably activate "jboss-remote naming", and the lookup should be done for "Stateless/StatelessEJB//GeometricModelBean...". (no "ejb:" prefix).
> Instead of an error message, this resulted in this console output, followed by an exception:
> Feb 05, 2013 10:43:57 PM org.xnio.Xnio <clinit>
> INFO: XNIO Version 3.0.7.GA
> Feb 05, 2013 10:43:57 PM org.xnio.nio.NioXnio <clinit>
> INFO: XNIO NIO Implementation Version 3.0.7.GA
> Feb 05, 2013 10:43:57 PM org.jboss.remoting3.EndpointImpl <clinit>
> INFO: JBoss Remoting version 3.2.14.GA
> Feb 05, 2013 10:43:58 PM org.jboss.ejb.client.remoting.VersionReceiver handleMessage
> INFO: EJBCLIENT000017: Received server version 1 and marshalling strategies [river]
> Feb 05, 2013 10:43:58 PM org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver associate
> INFO: EJBCLIENT000013: Successful version handshake completed for receiver context EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext at 28ad5a, receiver=Remoting connection EJB receiver [connection=Remoting connection <c751fd>,channel=jboss.ejb,nodename=turbotante]} on channel Channel ID b93e696f (outbound) of Remoting connection 00411379 to localhost/127.0.0.1:4447
> Feb 05, 2013 10:44:03 PM org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver associate
> INFO: EJBCLIENT000015: Initial module availability report for Remoting connection EJB receiver [connection=Remoting connection <c751fd>,channel=jboss.ejb,nodename=turbotante] wasn't received during the receiver context association
> Feb 05, 2013 10:44:03 PM org.jboss.ejb.client.EJBClient <clinit>
> INFO: JBoss EJB Client version 1.0.16.Final
> java.lang.NullPointerException
> 	at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.<init>(RemotingConnectionEJBReceiver.java:102)
> 	at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.<init>(RemotingConnectionEJBReceiver.java:90)
> 	at org.jboss.ejb.client.EJBClientContext.registerConnection(EJBClientContext.java:420)
> 	at org.jboss.naming.remote.client.ejb.RemoteNamingEjbClientContextSelector.getContext(RemoteNamingEjbClientContextSelector.java:60)
> 	at org.jboss.naming.remote.client.ejb.RemoteNamingEjbClientContextSelector.getCurrent(RemoteNamingEjbClientContextSelector.java:46)
> 	at org.jboss.naming.remote.client.ejb.RemoteNamingEjbClientContextSelector.getCurrent(RemoteNamingEjbClientContextSelector.java:15)
> 	at org.jboss.ejb.client.EJBClientContext.getCurrent(EJBClientContext.java:271)
> 	at org.jboss.ejb.client.EJBClientContext.requireCurrent(EJBClientContext.java:281)
> 	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:156)
> 	at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:124)
> 	at sun.proxy.$Proxy0.computeCuboidVolume(Unknown Source)
> 	at de.fhw.komponentenarchitekturen.knauf.stateless.standaloneclient.GeometricModelApplicationClient.main(GeometricModelApplicationClient.java:38)
> I will attach a sample. This is an Eclipse project. But i can also be run standalone: just modify "StatelessStandaloneClient\startclient.bat" to match your path to "jboss-client.jar" and start it (you need Java 1.7 for this). You don't even have to deploy the EAR app on the server to see the error. But if you want to do so: it is also part of the attachment: "Stateless.ear".

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 10:54:08 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 10:54:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-972) EJB calendar timer Sunday
 calculation problem in certain locales
In-Reply-To: <JIRA.12477270.1350507760000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12477270.1350507760000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12477270.1350507760000.26395.1383231248603@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas updated WFLY-972:
--------------------------------

    Assignee: Stuart Douglas  (was: jaikiran pai)

    
> EJB calendar timer Sunday calculation problem in certain locales
> ----------------------------------------------------------------
>
>                 Key: WFLY-972
>                 URL: https://issues.jboss.org/browse/WFLY-972
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>         Environment: JDK 6 & 7
>            Reporter: Cheng Fang
>            Assignee: Stuart Douglas
>
> My ejb class contains this timeout method:
> {code:java}
>     @Schedule(dayOfWeek="Sun", persistent=false)
>     private void sunday(Timer t) {
>     }
> {code}
> When calling this timer.getNextTimeout(), it returned the Sunday after next Sunday (expecting next Sunday) when running on certain locales (it_IT, es_PE, etc).  It works as expected on other locales like en_US.  
> I added -Duser.language=it -Duser.country=IT to JAVA_OPTS when starting standalone server to use that locale.
> Seems to be a JDK bug.  There could be some differences how dates are calculated in different locales, but shouldn't be that big like skip one Sunday.  Today is Wed.
> One workaround is "to use locale.English when instantiating GregorianCalendar in the following classes."  I tried it on 7.2 with it_IT, and got the expected Sunday.
> {noformat}
> ejb3/src/main/java/org/jboss/as/ejb3/timerservice/schedule/CalendarBasedTimeout.java
> ejb3/src/main/java/org/jboss/as/ejb3/timerservice/schedule/util/CalendarUtil.java
> ejb3/src/main/java/org/jboss/as/ejb3/timerservice/task/CalendarTimerTask.java
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 10:54:08 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 10:54:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2011) jboss-ejb3.xml deployment
 descriptor is not parsed correct for the clustering element
In-Reply-To: <JIRA.12500087.1378394515000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500087.1378394515000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500087.1378394515000.26400.1383231248820@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas updated WFLY-2011:
---------------------------------

    Assignee: Stuart Douglas  (was: jaikiran pai)

    
> jboss-ejb3.xml deployment descriptor is not parsed correct for the clustering element
> -------------------------------------------------------------------------------------
>
>                 Key: WFLY-2011
>                 URL: https://issues.jboss.org/browse/WFLY-2011
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Wolf-Dieter Fink
>            Assignee: Stuart Douglas
>              Labels: ejb-jar.xml
>
> If beans of an application are marked as clustered by using the jboss-ejb3.xml DD the behaviour is not consistent.
> From the XSD the <ejb-name> element can not be added multiple times.
> And the following configuration will be not valid:
>   <assembly-descriptor>
>     <c:clustering>
>       <ejb-name>Bean1</ejb-name>
>       <ejb-name>Bean2</ejb-name>
>       <c:clustered>true</c:clustered>
>     </c:clustering>
>   </assembly-descriptor>
> The parser should throw an Exception and the application should not be deployed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 10:58:01 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 31 Oct 2013 10:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2370) NPE in
	DelegatingServerInventory
In-Reply-To: <JIRA.12508635.1382579451000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508635.1382579451000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508635.1382579451000.26404.1383231481949@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2370:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1024109

    
> NPE in DelegatingServerInventory
> --------------------------------
>
>                 Key: WFLY-2370
>                 URL: https://issues.jboss.org/browse/WFLY-2370
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=4738&tab=buildResultsDiv&buildTypeId=WF_MasterIgnoreWindowsDomainOnly
> Test failure:
> java.lang.AssertionError
>     at org.junit.Assert.fail(Assert.java:86)
>     at org.junit.Assert.assertTrue(Assert.java:41)
>     at org.junit.Assert.assertTrue(Assert.java:52)
>     at org.jboss.as.test.integration.domain.DomainControllerMigrationTestCase.testDCFailover(DomainControllerMigrationTestCase.java:223)
> This appears in the log:
> [Host Controller] 03:26:38,028 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014612: Operation ("read-attribute") failed - address: ([
> [Host Controller]     ("host" => "failover-h1"),
> [Host Controller]     ("server-config" => "failover-one")
> [Host Controller] ]): java.lang.NullPointerException
> [Host Controller]     at org.jboss.as.host.controller.DomainModelControllerService$DelegatingServerInventory.determineServerStatus(DomainModelControllerService.java:788)
> [Host Controller]     at org.jboss.as.host.controller.operations.ServerStatusHandler.execute(ServerStatusHandler.java:66)
> [Host Controller]     at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecuteInternal(ReadAttributeHandler.java:177) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller]     at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecute(ReadAttributeHandler.java:97) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> [Host Controller]     at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractMultiTargetHandler.execute(GlobalOperationHandlers.java:151) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 11:08:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 11:08:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-16) Intermittent failure in
 RemoteOutboundConnectionReconnectTestCase
In-Reply-To: <JIRA.12473474.1346412534000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12473474.1346412534000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12473474.1346412534000.26429.1383232082130@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-16.
--------------------------------

    Resolution: Out of Date

    
> Intermittent failure in RemoteOutboundConnectionReconnectTestCase
> -----------------------------------------------------------------
>
>                 Key: WFLY-16
>                 URL: https://issues.jboss.org/browse/WFLY-16
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>            Reporter: Kabir Khan
>            Assignee: Stuart Douglas
>            Priority: Critical
>             Fix For: 8.0.0.CR1
>
>
> Assigning to Jaikiran since I think this is ejb client
> This happened for IPv6 but I don't know if that has any relevance.
> The test has not been disabled
> {code}
> org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteOutboundConnectionReconnectTestCase.testRemoteServerRestarts
> Failing for the past 1 build (Since #3674 )
> Took 8.7 sec.
> add description
> Error Message
> Cannot deploy: server-two-module.jar
> Stacktrace
> org.jboss.arquillian.container.spi.client.container.DeploymentException: Cannot deploy: server-two-module.jar
>      at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:83)
>      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:145)
>      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:39)
>      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>      at java.lang.reflect.Method.invoke(Method.java:597)
>      at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>      at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
>      at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
>      at org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50)
>      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>      at java.lang.reflect.Method.invoke(Method.java:597)
>      at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>      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:39)
>      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>      at java.lang.reflect.Method.invoke(Method.java:597)
>      at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>      at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
>      at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57)
>      at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
>      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>      at java.lang.reflect.Method.invoke(Method.java:597)
>      at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>      at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
>      at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
>      at org.jboss.arquillian.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.deployment.ClientDeployer.deploy(ClientDeployer.java:93)
>      at org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteOutboundConnectionReconnectTestCase.testRemoteServerRestarts(RemoteOutboundConnectionReconnectTestCase.java:199)
>      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>      at java.lang.reflect.Method.invoke(Method.java:597)
>      at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
>      at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
>      at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
>      at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:270)
>      at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
>      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>      at java.lang.reflect.Method.invoke(Method.java:597)
>      at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>      at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
>      at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
>      at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
>      at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
>      at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
>      at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:53)
>      at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
>      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>      at java.lang.reflect.Method.invoke(Method.java:597)
>      at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>      at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
>      at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
>      at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
>      at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129)
>      at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
>      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>      at java.lang.reflect.Method.invoke(Method.java:597)
>      at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>      at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
>      at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89)
>      at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
>      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>      at java.lang.reflect.Method.invoke(Method.java:597)
>      at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>      at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
>      at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
>      at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
>      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>      at java.lang.reflect.Method.invoke(Method.java:597)
>      at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>      at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
>      at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
>      at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
>      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>      at java.lang.reflect.Method.invoke(Method.java:597)
>      at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>      at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
>      at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
>      at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111)
>      at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263)
>      at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226)
>      at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
>      at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
>      at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240)
>      at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
>      at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
>      at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
>      at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
>      at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
>      at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
>      at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
>      at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
>      at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185)
>      at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
>      at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
>      at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
>      at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
>      at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
>      at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234)
>      at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133)
>      at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114)
>      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>      at java.lang.reflect.Method.invoke(Method.java:597)
>      at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188)
>      at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166)
>      at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
>      at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101)
>      at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
> Caused by: java.lang.Exception: {"JBAS014771: Services with missing/unavailable dependencies" => [
>     "jboss.naming.context.java.app.server-two-module.server-two-module.EchoOnServerTwo Missing[JBAS014861: <one or more transitive dependencies>]",
>     "jboss.naming.context.java.global.server-two-module.\"EchoOnServerTwo!org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteEcho\" Missing[JBAS014861: <one or more transitive dependencies>]",
>     "jboss.deployment.unit.\"server-two-module.jar\".component.EchoOnServerTwo.VIEW.\"org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteEcho\".REMOTE Missing[JBAS014861: <one or more transitive dependencies>]",
>     "jboss.deployment.unit.\"server-two-module.jar\".deploymentCompleteService Missing[JBAS014861: <one or more transitive dependencies>]",
>     "jboss.naming.context.java.module.server-two-module.server-two-module.\"EchoOnServerTwo!org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteEcho\" Missing[JBAS014861: <one or more transitive dependencies>]",
>     "jboss.deployment.unit.\"server-two-module.jar\".component.EchoOnServerTwo.START Missing[JBAS014861: <one or more transitive dependencies>]",
>     "jboss.deployment.unit.\"server-two-module.jar\".moduleDeploymentRuntimeInformation Missing[JBAS014861: <one or more transitive dependencies>]",
>     "jboss.naming.context.java.module.server-two-module.server-two-module.EchoOnServerTwo Missing[JBAS014861: <one or more transitive dependencies>]",
>     "jboss.naming.context.java.app.server-two-module.server-two-module.\"EchoOnServerTwo!org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteEcho\" Missing[JBAS014861: <one or more transitive dependencies>]",
>     "jboss.deployment.unit.\"server-two-module.jar\".jndiDependencyService Missing[JBAS014861: <one or more transitive dependencies>]",
>     "jboss.naming.context.java.global.server-two-module.EchoOnServerTwo Missing[JBAS014861: <one or more transitive dependencies>]"
> ]}
>      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:52)
>      at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:77)
>      ... 123 more
> Standard Output
> 02:31:11,030 INFO  [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual starting of a server instance
> 02:31:11,053 INFO  [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Starting container with: [/opt/jdk1.6.0_29/bin/java, -Xmx512m, -XX:MaxPermSize=256m, -Djboss.dist=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/../../../build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT, -Djava.net.preferIPv4Stack=false, -Djava.net.preferIPv6Addresses=true, -Dts.timeout.factor=100, -Dnode0=::1, -Dnode1=fccc::2, -Dmcast=ff01::1, -Djbossas.ts.submodule.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode, -Djbossas.ts.integ.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/.., -Djbossas.ts.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/../.., -Djbossas.project.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/../../.., -Djboss.dist=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/../../../build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT, -Djboss.inst=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/target/jbossas, -Djboss.node.name=default-jbossas, -ea, -Djboss.home.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/target/jbossas, -Dorg.jboss.boot.log.file=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/target/jbossas/standalone/log/boot.log, -Dlogging.configuration=file:/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/target/jbossas/standalone/configuration/logging.properties, -Djboss.bundles.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/../../../build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT/bundles, -jar, /home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/target/jbossas/jboss-modules.jar, -mp, /home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/../../../build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT/modules:/home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/target/modules, -jaxpmodule, javax.xml.jaxp-provider, org.jboss.as.standalone, -server-config, standalone-ha.xml]
> 02:31:11,906 INFO  [org.jboss.modules] JBoss Modules version 1.1.3.GA
> 02:31:12,166 INFO  [org.jboss.msc] JBoss MSC version 1.0.2.GA
> 02:31:12,257 INFO  [org.jboss.as] JBAS015899: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" starting
> 02:31:14,791 INFO  [org.jboss.as.server] JBAS015888: Creating http management service using socket-binding (management-http)
> 02:31:14,798 INFO  [org.xnio] XNIO Version 3.0.5.GA
> 02:31:14,827 INFO  [org.xnio.nio] XNIO NIO Implementation Version 3.0.5.GA
> 02:31:14,848 INFO  [org.jboss.as.configadmin] JBAS016200: Activating ConfigAdmin Subsystem
> 02:31:14,849 INFO  [org.jboss.as.logging] JBAS011502: Removing bootstrap log handlers
> &#27;[0m02:31:14,889 INFO  [org.jboss.remoting] (MSC service thread 1-3) JBoss Remoting version 3.2.8.GA
> &#27;[0m&#27;[0m02:31:14,916 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 34) JBAS010280: Activating Infinispan subsystem.
> &#27;[0m&#27;[0m02:31:14,979 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 38) JBAS010260: Activating JGroups subsystem.
> &#27;[0m&#27;[0m02:31:14,991 INFO  [org.jboss.as.osgi] (ServerService Thread Pool -- 45) JBAS011906: Activating OSGi Subsystem
> &#27;[0m&#27;[0m02:31:15,009 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 44) JBAS011800: Activating Naming Subsystem
> &#27;[0m&#27;[0m02:31:15,015 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 50) JBAS013171: Activating Security Subsystem
> &#27;[0m&#27;[0m02:31:15,047 INFO  [org.jboss.as.security] (MSC service thread 1-1) JBAS013170: Current PicketBox version=4.0.13.Final
> &#27;[0m&#27;[0m02:31:15,161 INFO  [org.jboss.as.connector.logging] (MSC service thread 1-6) JBAS010408: Starting JCA Subsystem (JBoss IronJacamar 1.0.12.Final)
> &#27;[0m&#27;[0m02:31:15,164 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 54) JBAS015537: Activating WebServices Extension
> &#27;[0m&#27;[0m02:31:15,332 INFO  [org.jboss.as.naming] (MSC service thread 1-2) JBAS011802: Starting Naming Service
> &#27;[0m&#27;[0m02:31:15,371 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-6) JBAS015400: Bound mail session [java:jboss/mail/Default]
> &#27;[0m&#27;[31m02:31:15,331 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC00001: Failed to start service jboss.remoting.endpoint.subsystem: org.jboss.msc.service.StartException in service jboss.remoting.endpoint.subsystem: Failed to start service
>      at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1767) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>      at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
>      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
>      at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> Caused by: java.lang.NullPointerException
>      at sun.nio.ch.Util.atBugLevel(Util.java:448) [rt.jar:1.6.0_29]
>      at sun.nio.ch.SelectorImpl.<init>(SelectorImpl.java:40) [rt.jar:1.6.0_29]
>      at sun.nio.ch.EPollSelectorImpl.<init>(EPollSelectorImpl.java:47) [rt.jar:1.6.0_29]
>      at sun.nio.ch.EPollSelectorProvider.openSelector(EPollSelectorProvider.java:18) [rt.jar:1.6.0_29]
>      at java.nio.channels.Selector.open(Selector.java:209) [rt.jar:1.6.0_29]
>      at org.xnio.nio.NioXnioWorker.<init>(NioXnioWorker.java:112)
>      at org.xnio.nio.NioXnio.createWorker(NioXnio.java:126)
>      at org.jboss.remoting3.EndpointImpl.construct(EndpointImpl.java:137)
>      at org.jboss.remoting3.Remoting.createEndpoint(Remoting.java:60)
>      at org.jboss.remoting3.Remoting.createEndpoint(Remoting.java:73)
>      at org.jboss.as.remoting.EndpointService.start(EndpointService.java:71)
>      at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>      at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>      ... 3 more
> &#27;[0m&#27;[0m02:31:15,747 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 30) JBAS010403: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> &#27;[0m&#27;[0m02:31:16,070 INFO  [org.jboss.ws.common.management.AbstractServerConfig] (MSC service thread 1-3) JBoss Web Services - Stack CXF Server 4.1.0.Beta2
> &#27;[0m&#27;[0m02:31:16,117 INFO  [org.apache.coyote.ajp.AjpProtocol] (MSC service thread 1-4) Starting Coyote AJP/1.3 on ajp-/0:0:0:0:0:0:0:1%1:8009
> &#27;[0m&#27;[0m02:31:16,117 INFO  [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-5) Starting Coyote HTTP/1.1 on http-/0:0:0:0:0:0:0:1%1:8080
> &#27;[0m&#27;[0m02:31:16,357 INFO  [org.jboss.modcluster.ModClusterService] (ServerService Thread Pool -- 56) Initializing mod_cluster 1.2.1.Final
> &#27;[0m&#27;[0m02:31:16,437 INFO  [org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl] (ServerService Thread Pool -- 56) Listening to proxy advertisements on ff01:0:0:0:0:0:0:3:23,364
> &#27;[0m&#27;[0m02:31:16,718 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 34) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> &#27;[0m&#27;[0m02:31:16,742 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 34) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> &#27;[0m&#27;[0m02:31:16,908 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-3) JBAS015012: Started FileSystemDeploymentService for directory /home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/target/jbossas/standalone/deployments
> &#27;[0m&#27;[0m02:31:16,927 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015876: Starting deployment of "dep1.jar"
> &#27;[0m&#27;[0m02:31:16,960 INFO  [org.jboss.as.remoting] (MSC service thread 1-6) JBAS017100: Listening on [::1]:9999
> &#27;[0m&#27;[0m02:31:16,977 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
> &#27;[0m&#27;[0m02:31:17,615 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-2) JNDI bindings for session bean named ShutdownBean in deployment unit deployment "dep1.jar" are as follows:
>      java:global/dep1/ShutdownBean!org.jboss.as.test.manualmode.ejb.shutdown.RemoteEcho
>      java:app/dep1/ShutdownBean!org.jboss.as.test.manualmode.ejb.shutdown.RemoteEcho
>      java:module/ShutdownBean!org.jboss.as.test.manualmode.ejb.shutdown.RemoteEcho
>      java:jboss/exported/dep1/ShutdownBean!org.jboss.as.test.manualmode.ejb.shutdown.RemoteEcho
>      java:global/dep1/ShutdownBean
>      java:app/dep1/ShutdownBean
>      java:module/ShutdownBean
> &#27;[0m&#27;[0m02:31:17,617 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-2) JNDI bindings for session bean named LatchBean in deployment unit deployment "dep1.jar" are as follows:
>      java:global/dep1/LatchBean!org.jboss.as.test.manualmode.ejb.shutdown.RemoteLatch
>      java:app/dep1/LatchBean!org.jboss.as.test.manualmode.ejb.shutdown.RemoteLatch
>      java:module/LatchBean!org.jboss.as.test.manualmode.ejb.shutdown.RemoteLatch
>      java:jboss/exported/dep1/LatchBean!org.jboss.as.test.manualmode.ejb.shutdown.RemoteLatch
>      java:global/dep1/LatchBean
>      java:app/dep1/LatchBean
>      java:module/LatchBean
> &#27;[0m&#27;[0m02:31:17,619 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-2) JNDI bindings for session bean named RealEcho in deployment unit deployment "dep1.jar" are as follows:
>      java:global/dep1/RealEcho!org.jboss.as.test.manualmode.ejb.shutdown.RemoteEcho
>      java:app/dep1/RealEcho!org.jboss.as.test.manualmode.ejb.shutdown.RemoteEcho
>      java:module/RealEcho!org.jboss.as.test.manualmode.ejb.shutdown.RemoteEcho
>      java:jboss/exported/dep1/RealEcho!org.jboss.as.test.manualmode.ejb.shutdown.RemoteEcho
>      java:global/dep1/RealEcho
>      java:app/dep1/RealEcho
>      java:module/RealEcho
> &#27;[0m&#27;[0m02:31:18,940 INFO  [org.jboss.as.server] (Controller Boot Thread) JBAS018559: Deployed "dep1.jar"
> &#27;[0m&#27;[0m02:31:18,951 INFO  [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014777:   Services which failed to start:      service jboss.remoting.endpoint.subsystem: org.jboss.msc.service.StartException in service jboss.remoting.endpoint.subsystem: Failed to start service
> &#27;[0m&#27;[0m02:31:18,992 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://::1:9990/management
> &#27;[0m&#27;[0m02:31:18,994 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://::1:9990
> &#27;[0m&#27;[31m02:31:18,996 ERROR [org.jboss.as] (Controller Boot Thread) JBAS015875: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" started (with errors) in 7657ms - Started 185 of 364 services (34 services failed or missing dependencies, 144 services are passive or on-demand)
> &#27;[0m&#27;[0m02:31:19,141 INFO  [org.jboss.as.repository] (management-handler-thread - 1) JBAS014900: Content added at location /home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/manualmode/target/jbossas/standalone/data/content/34/cf5c1cb3656c84a2615763b9f95b3a16536c40/content
> &#27;[0m&#27;[0m02:31:19,164 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015876: Starting deployment of "server-two-module.jar"
> &#27;[0m&#27;[0m02:31:19,227 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-1) JNDI bindings for session bean named EchoOnServerTwo in deployment unit deployment "server-two-module.jar" are as follows:
>      java:global/server-two-module/EchoOnServerTwo!org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteEcho
>      java:app/server-two-module/EchoOnServerTwo!org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteEcho
>      java:module/EchoOnServerTwo!org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteEcho
>      java:jboss/exported/server-two-module/EchoOnServerTwo!org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteEcho
>      java:global/server-two-module/EchoOnServerTwo
>      java:app/server-two-module/EchoOnServerTwo
>      java:module/EchoOnServerTwo
> &#27;[0m&#27;[0m02:31:19,578 INFO  [org.jboss.as.server] (management-handler-thread - 1) JBAS015870: Deploy of deployment "server-two-module.jar" was rolled back with failure message {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.naming.context.java.app.server-two-module.server-two-module.EchoOnServerTwo Missing[JBAS014861: <one or more transitive dependencies>]","jboss.naming.context.java.global.server-two-module.\"EchoOnServerTwo!org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteEcho\" Missing[JBAS014861: <one or more transitive dependencies>]","jboss.deployment.unit.\"server-two-module.jar\".component.EchoOnServerTwo.VIEW.\"org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteEcho\".REMOTE Missing[JBAS014861: <one or more transitive dependencies>]","jboss.deployment.unit.\"server-two-module.jar\".deploymentCompleteService Missing[JBAS014861: <one or more transitive dependencies>]","jboss.naming.context.java.module.server-two-module.server-two-module.\"EchoOnServerTwo!org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteEcho\" Missing[JBAS014861: <one or more transitive dependencies>]","jboss.deployment.unit.\"server-two-module.jar\".component.EchoOnServerTwo.START Missing[JBAS014861: <one or more transitive dependencies>]","jboss.deployment.unit.\"server-two-module.jar\".moduleDeploymentRuntimeInformation Missing[JBAS014861: <one or more transitive dependencies>]","jboss.naming.context.java.module.server-two-module.server-two-module.EchoOnServerTwo Missing[JBAS014861: <one or more transitive dependencies>]","jboss.naming.context.java.app.server-two-module.server-two-module.\"EchoOnServerTwo!org.jboss.as.test.manualmode.ejb.client.outbound.connection.RemoteEcho\" Missing[JBAS014861: <one or more transitive dependencies>]","jboss.deployment.unit.\"server-two-module.jar\".jndiDependencyService Missing[JBAS014861: <one or more transitive dependencies>]","jboss.naming.context.java.global.server-two-module.EchoOnServerTwo Missing[JBAS014861: <one or more transitive dependencies>]"]}
> &#27;[0m&#27;[0m02:31:19,652 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015877: Stopped deployment server-two-module.jar in 97ms
> &#27;[0m
>  Help us localize this page Page generated: Aug 31, 2012 7:20:23 AMJenkins ver. 1.473
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Thu Oct 31 11:08:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 11:08:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-312) LocalEJBClientFailoverTestCase
 fails intermittently
In-Reply-To: <JIRA.12471899.1344331208000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12471899.1344331208000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12471899.1344331208000.26432.1383232082319@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-312.
---------------------------------

    Resolution: Out of Date


Given how often all the clustering tests fail I don't think this is relevant any more. 
                
> LocalEJBClientFailoverTestCase fails intermittently
> ---------------------------------------------------
>
>                 Key: WFLY-312
>                 URL: https://issues.jboss.org/browse/WFLY-312
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Kabir Khan
>            Assignee: Stuart Douglas
>            Priority: Critical
>             Fix For: 8.0.0.CR1
>
>
> org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.LocalEJBClientFailoverTestCase(UDP).testFailoverWhenLocalTargetApplicationIsUndeployed
> Failing for the past 1 build (Since #4607 )
> Took 2 min 24 sec.
> add description
> Error Message
> java.lang.IllegalArgumentException: JBAS014155: Unknown deployment - app name:  module name: node-name-app distinct name: 
> Stacktrace
> javax.ejb.EJBException: java.lang.IllegalArgumentException: JBAS014155: Unknown deployment - app name:  module name: node-name-app distinct name: 
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:165)
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:229)
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:303)
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:189)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:42)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:43)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
>         at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:327)
>         at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:70)
>         at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:205)
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:662)
>         at org.jboss.threads.JBossThread.run(JBossThread.java:122)
>         at ...asynchronous invocation...(Unknown Source)
>         at org.jboss.ejb.client.remoting.InvocationExceptionResponseHandler$MethodInvocationExceptionResultProducer.getResult(InvocationExceptionResponseHandler.java:99)
>         at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:272)
>         at org.jboss.ejb.client.TransactionInterceptor.handleInvocationResult(TransactionInterceptor.java:46)
>         at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:274)
>         at org.jboss.ejb.client.ReceiverInterceptor.handleInvocationResult(ReceiverInterceptor.java:129)
>         at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:262)
>         at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:437)
>         at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:140)
>         at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:121)
>         at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:104)
>         at $Proxy29.invokeAndFetchNodeNameFromClusteredSFSBRemoteBean(Unknown Source)
>         at org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.LocalEJBClientFailoverTestCase.testFailoverWhenLocalTargetApplicationIsUndeployed(LocalEJBClientFailoverTestCase.java:207)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
>         at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
>         at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
>         at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:270)
>         at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
>         at sun.reflect.GeneratedMethodAccessor12.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>         at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
>         at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
>         at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
>         at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
>         at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
>         at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:53)
>         at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>         at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
>         at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
>         at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
>         at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129)
>         at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>         at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
>         at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89)
>         at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>         at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
>         at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
>         at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>         at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
>         at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
>         at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>         at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
>         at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
>         at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111)
>         at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263)
>         at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226)
>         at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
>         at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
>         at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240)
>         at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
>         at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
>         at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
>         at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
>         at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
>         at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
>         at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
>         at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
>         at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185)
>         at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
>         at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
>         at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
>         at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
>         at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188)
>         at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166)
>         at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
>         at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101)
>         at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
> Caused by: java.lang.IllegalArgumentException: JBAS014155: Unknown deployment - app name:  module name: node-name-app distinct name: 
>         at org.jboss.as.ejb3.remote.LocalEjbReceiver.findBean(LocalEjbReceiver.java:317)
>         at org.jboss.as.ejb3.remote.LocalEjbReceiver.processInvocation(LocalEjbReceiver.java:142)
>         at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:181)
>         at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:42)
>         at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183)
>         at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:125)
>         at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183)
>         at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:136)
>         at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:121)
>         at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:104)
>         at $Proxy30.getNodeName(Unknown Source)
>         at org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.ClientSFSB.invokeAndFetchNodeNameFromClusteredSFSBRemoteBean(ClientSFSB.java:53)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:36)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:58)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:156)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:67)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:227)
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:303)
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:189)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:42)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:43)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>         at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
>         at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:327)
>         at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:70)
>         at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:205)
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:662)
>         at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> Standard Output
> 05:46:07,738 INFO  [org.jboss.ejb.client.remoting] (Remoting "config-based-ejb-client-endpoint" task-4) EJBCLIENT000016: Channel Channel ID aa79198c (outbound) of Remoting connection 0ab612f8 to /127.0.0.1:4447 can no longer process messages
> 05:46:07,958 INFO  [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual starting of a server instance
> 05:46:07,971 INFO  [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Starting container with: [/opt/jdk1.6.0_29/bin/java, -Xmx512m, -XX:MaxPermSize=256m, -Djboss.dist=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/../../../build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT, -Djava.net.preferIPv4Stack=true, -Djava.net.preferIPv6Addresses=false, -Dts.timeout.factor=100, -Dnode0=127.0.0.1, -Dnode1=127.0.0.1, -Dmcast=230.0.0.4, -Djbossas.ts.submodule.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust, -Djbossas.ts.integ.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/.., -Djbossas.ts.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/../.., -Djbossas.project.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/../../.., -Djboss.dist=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/../../../build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT, -Djboss.inst=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-0, -Djboss.node.name=node-0, -ea, -Djboss.home.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-0, -Dorg.jboss.boot.log.file=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-0/standalone/log/boot.log, -Dlogging.configuration=file:/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-0/standalone/configuration/logging.properties, -Djboss.bundles.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/../../../build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT/bundles, -jar, /home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-0/jboss-modules.jar, -mp, /home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/../../../build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT/modules, -jaxpmodule, javax.xml.jaxp-provider, org.jboss.as.standalone, -server-config, standalone-ha.xml]
> 05:46:08,724 INFO  [org.jboss.modules] JBoss Modules version 1.1.2.GA
> 05:46:08,967 INFO  [org.jboss.msc] JBoss MSC version 1.0.2.GA
> 05:46:09,049 INFO  [org.jboss.as] JBAS015899: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" starting
> 05:46:10,984 INFO  [org.xnio] XNIO Version 3.0.5.GA
> 05:46:10,985 INFO  [org.jboss.as.server] JBAS015888: Creating http management service using socket-binding (management-http)
> 05:46:11,001 INFO  [org.xnio.nio] XNIO NIO Implementation Version 3.0.5.GA
> 05:46:11,023 INFO  [org.jboss.remoting] JBoss Remoting version 3.2.8.GA
> 05:46:11,036 INFO  [org.jboss.as.logging] JBAS011502: Removing bootstrap log handlers
> &#27;[0m05:46:11,041 INFO  [org.jboss.as.configadmin] (ServerService Thread Pool -- 29) JBAS016200: Activating ConfigAdmin Subsystem
> &#27;[0m&#27;[0m05:46:11,073 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 34) JBAS010280: Activating Infinispan subsystem.
> &#27;[0m&#27;[0m05:46:11,115 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 38) JBAS010260: Activating JGroups subsystem.
> &#27;[0m&#27;[0m05:46:11,224 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 50) JBAS013171: Activating Security Subsystem
> &#27;[0m&#27;[0m05:46:11,225 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 44) JBAS011800: Activating Naming Subsystem
> &#27;[0m&#27;[0m05:46:11,300 INFO  [org.jboss.as.connector.logging] (MSC service thread 1-5) JBAS010408: Starting JCA Subsystem (JBoss IronJacamar 1.0.12.Final)
> &#27;[0m&#27;[0m05:46:11,319 INFO  [org.jboss.as.osgi] (ServerService Thread Pool -- 45) JBAS011906: Activating OSGi Subsystem
> &#27;[0m&#27;[0m05:46:11,336 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 54) JBAS015537: Activating WebServices Extension
> &#27;[0m&#27;[0m05:46:11,391 INFO  [org.jboss.as.security] (MSC service thread 1-3) JBAS013170: Current PicketBox version=4.0.9.Final
> &#27;[0m&#27;[0m05:46:11,516 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 30) JBAS010403: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> &#27;[0m&#27;[0m05:46:11,533 INFO  [org.jboss.as.naming] (MSC service thread 1-5) JBAS011802: Starting Naming Service
> &#27;[0m&#27;[0m05:46:11,571 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-6) JBAS015400: Bound mail session [java:jboss/mail/Default]
> &#27;[0m&#27;[0m05:46:11,885 INFO  [org.jboss.ws.common.management.AbstractServerConfig] (MSC service thread 1-6) JBoss Web Services - Stack CXF Server 4.1.0.Beta1
> &#27;[0m&#27;[0m05:46:11,995 INFO  [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-1) Starting Coyote HTTP/1.1 on http-/127.0.0.1:8080
> &#27;[0m&#27;[0m05:46:11,998 INFO  [org.apache.coyote.ajp.AjpProtocol] (MSC service thread 1-2) Starting Coyote AJP/1.3 on ajp-/127.0.0.1:8009
> &#27;[0m&#27;[0m05:46:12,166 INFO  [org.jboss.modcluster.ModClusterService] (ServerService Thread Pool -- 56) Initializing mod_cluster 1.2.1.Final
> &#27;[0m&#27;[0m05:46:12,229 INFO  [org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl] (ServerService Thread Pool -- 56) Listening to proxy advertisements on 224.0.1.105:23,364
> &#27;[0m&#27;[0m05:46:12,338 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 34) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> &#27;[0m&#27;[0m05:46:12,358 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 34) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> &#27;[0m&#27;[0m05:46:12,520 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-6) JBAS015012: Started FileSystemDeploymentService for directory /home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-0/standalone/deployments
> &#27;[0m&#27;[0m05:46:12,522 INFO  [org.jboss.as.remoting] (MSC service thread 1-5) JBAS017100: Listening on 127.0.0.1:4447
> &#27;[0m&#27;[0m05:46:12,526 INFO  [org.jboss.as.remoting] (MSC service thread 1-2) JBAS017100: Listening on 127.0.0.1:9999
> &#27;[0m&#27;[0m05:46:12,561 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
> &#27;[0m&#27;[0m05:46:12,681 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:9990/management
> &#27;[0m&#27;[0m05:46:12,682 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990
> &#27;[0m&#27;[0m05:46:12,683 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" started in 4449ms - Started 137 of 280 services (142 services are passive or on-demand)
> &#27;[0m05:46:14,559 INFO  [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual starting of a server instance
> 05:46:14,565 INFO  [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Starting container with: [/opt/jdk1.6.0_29/bin/java, -Xmx512m, -XX:MaxPermSize=256m, -Djboss.dist=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/../../../build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT, -Djava.net.preferIPv4Stack=true, -Djava.net.preferIPv6Addresses=false, -Dts.timeout.factor=100, -Dnode0=127.0.0.1, -Dnode1=127.0.0.1, -Dmcast=230.0.0.4, -Djbossas.ts.submodule.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust, -Djbossas.ts.integ.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/.., -Djbossas.ts.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/../.., -Djbossas.project.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/../../.., -Djboss.dist=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/../../../build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT, -Djboss.inst=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-1, -Djboss.node.name=node-1, -Djboss.port.offset=100, -ea, -Djboss.home.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-1, -Dorg.jboss.boot.log.file=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-1/standalone/log/boot.log, -Dlogging.configuration=file:/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-1/standalone/configuration/logging.properties, -Djboss.bundles.dir=/home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/../../../build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT/bundles, -jar, /home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-1/jboss-modules.jar, -mp, /home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/../../../build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT/modules, -jaxpmodule, javax.xml.jaxp-provider, org.jboss.as.standalone, -server-config, standalone-ha.xml]
> 05:46:15,100 INFO  [org.jboss.modules] JBoss Modules version 1.1.2.GA
> 05:46:15,351 INFO  [org.jboss.msc] JBoss MSC version 1.0.2.GA
> 05:46:15,440 INFO  [org.jboss.as] JBAS015899: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" starting
> 05:46:17,345 INFO  [org.xnio] XNIO Version 3.0.5.GA
> 05:46:17,355 INFO  [org.xnio.nio] XNIO NIO Implementation Version 3.0.5.GA
> 05:46:17,359 INFO  [org.jboss.as.server] JBAS015888: Creating http management service using socket-binding (management-http)
> 05:46:17,378 INFO  [org.jboss.remoting] JBoss Remoting version 3.2.8.GA
> 05:46:17,424 INFO  [org.jboss.as.logging] JBAS011502: Removing bootstrap log handlers
> &#27;[0m05:46:17,429 INFO  [org.jboss.as.configadmin] (ServerService Thread Pool -- 29) JBAS016200: Activating ConfigAdmin Subsystem
> &#27;[0m&#27;[0m05:46:17,472 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 34) JBAS010280: Activating Infinispan subsystem.
> &#27;[0m&#27;[0m05:46:17,514 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 38) JBAS010260: Activating JGroups subsystem.
> &#27;[0m&#27;[0m05:46:17,549 INFO  [org.jboss.as.osgi] (ServerService Thread Pool -- 45) JBAS011906: Activating OSGi Subsystem
> &#27;[0m&#27;[0m05:46:17,562 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 50) JBAS013171: Activating Security Subsystem
> &#27;[0m&#27;[0m05:46:17,622 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 54) JBAS015537: Activating WebServices Extension
> &#27;[0m&#27;[0m05:46:17,628 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 44) JBAS011800: Activating Naming Subsystem
> &#27;[0m&#27;[0m05:46:17,625 INFO  [org.jboss.as.connector.logging] (MSC service thread 1-6) JBAS010408: Starting JCA Subsystem (JBoss IronJacamar 1.0.12.Final)
> &#27;[0m&#27;[0m05:46:17,622 INFO  [org.jboss.as.security] (MSC service thread 1-1) JBAS013170: Current PicketBox version=4.0.9.Final
> &#27;[0m&#27;[0m05:46:17,691 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 30) JBAS010403: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> &#27;[0m&#27;[0m05:46:17,761 INFO  [org.jboss.as.naming] (MSC service thread 1-2) JBAS011802: Starting Naming Service
> &#27;[0m&#27;[0m05:46:17,847 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-4) JBAS015400: Bound mail session [java:jboss/mail/Default]
> &#27;[0m&#27;[0m05:46:18,096 INFO  [org.jboss.ws.common.management.AbstractServerConfig] (MSC service thread 1-3) JBoss Web Services - Stack CXF Server 4.1.0.Beta1
> &#27;[0m&#27;[0m05:46:18,233 INFO  [org.apache.coyote.ajp.AjpProtocol] (MSC service thread 1-5) Starting Coyote AJP/1.3 on ajp-/127.0.0.1:8109
> &#27;[0m&#27;[0m05:46:18,236 INFO  [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-3) Starting Coyote HTTP/1.1 on http-/127.0.0.1:8180
> &#27;[0m&#27;[0m05:46:18,374 INFO  [org.jboss.modcluster.ModClusterService] (ServerService Thread Pool -- 56) Initializing mod_cluster 1.2.1.Final
> &#27;[0m&#27;[0m05:46:18,486 INFO  [org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl] (ServerService Thread Pool -- 56) Listening to proxy advertisements on 224.0.1.105:23,364
> &#27;[0m&#27;[0m05:46:18,571 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 34) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> &#27;[0m&#27;[0m05:46:18,593 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 34) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> &#27;[0m&#27;[0m05:46:18,753 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
> &#27;[0m&#27;[0m05:46:18,778 INFO  [org.jboss.as.remoting] (MSC service thread 1-6) JBAS017100: Listening on 127.0.0.1:10099
> &#27;[0m&#27;[0m05:46:18,778 INFO  [org.jboss.as.remoting] (MSC service thread 1-3) JBAS017100: Listening on 127.0.0.1:4547
> &#27;[0m&#27;[0m05:46:18,783 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-1) JBAS015012: Started FileSystemDeploymentService for directory /home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-1/standalone/deployments
> &#27;[0m&#27;[0m05:46:18,936 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:10090/management
> &#27;[0m&#27;[0m05:46:18,937 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:10090
> &#27;[0m&#27;[0m05:46:18,938 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" started in 4137ms - Started 137 of 280 services (142 services are passive or on-demand)
> &#27;[0m&#27;[0m05:46:21,241 INFO  [org.jboss.as.repository] (management-handler-thread - 2) JBAS014900: Content added at location /home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-1/standalone/data/content/e2/09ce1c0485164619e2ea871a0013f2781ab162/content
> &#27;[0m&#27;[0m05:46:21,299 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015876: Starting deployment of "client-app.jar"
> &#27;[0m&#27;[0m05:46:21,894 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-1) JNDI bindings for session bean named ClientSFSB in deployment unit deployment "client-app.jar" are as follows:
>         java:global/client-app/ClientSFSB!org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.ClientSFSBRemote
>         java:app/client-app/ClientSFSB!org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.ClientSFSBRemote
>         java:module/ClientSFSB!org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.ClientSFSBRemote
>         java:jboss/exported/client-app/ClientSFSB!org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.ClientSFSBRemote
>         java:global/client-app/ClientSFSB
>         java:app/client-app/ClientSFSB
>         java:module/ClientSFSB
> &#27;[0m&#27;[0m05:46:22,409 INFO  [org.jboss.as.server] (management-handler-thread - 2) JBAS018559: Deployed "client-app.jar"
> &#27;[0m&#27;[0m05:46:22,882 INFO  [org.jboss.as.repository] (management-handler-thread - 2) JBAS014900: Content added at location /home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-0/standalone/data/content/dc/274297a56acebcb3414b7407fa05d097f6691b/content
> &#27;[0m&#27;[0m05:46:22,903 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015876: Starting deployment of "node-name-app.jar"
> &#27;[0m&#27;[0m05:46:23,113 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-2) JNDI bindings for session bean named NodeNameSFSB in deployment unit deployment "node-name-app.jar" are as follows:
>         java:global/node-name-app/NodeNameSFSB!org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.NodeNameRetriever
>         java:app/node-name-app/NodeNameSFSB!org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.NodeNameRetriever
>         java:module/NodeNameSFSB!org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.NodeNameRetriever
>         java:jboss/exported/node-name-app/NodeNameSFSB!org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.NodeNameRetriever
>         java:global/node-name-app/NodeNameSFSB
>         java:app/node-name-app/NodeNameSFSB
>         java:module/NodeNameSFSB
> &#27;[0m&#27;[33m05:46:24,128 WARN  [org.jgroups.protocols.UDP] (ServerService Thread Pool -- 1) send buffer of socket java.net.DatagramSocket at 3b5789a5 was set to 640KB, but the OS only allocated 131.07KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> &#27;[0m&#27;[33m05:46:24,132 WARN  [org.jgroups.protocols.UDP] (ServerService Thread Pool -- 1) receive buffer of socket java.net.DatagramSocket at 3b5789a5 was set to 20MB, but the OS only allocated 131.07KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> &#27;[0m&#27;[33m05:46:24,134 WARN  [org.jgroups.protocols.UDP] (ServerService Thread Pool -- 1) send buffer of socket java.net.MulticastSocket at 1a543937 was set to 640KB, but the OS only allocated 131.07KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> &#27;[0m&#27;[33m05:46:24,136 WARN  [org.jgroups.protocols.UDP] (ServerService Thread Pool -- 1) receive buffer of socket java.net.MulticastSocket at 1a543937 was set to 25MB, but the OS only allocated 131.07KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> &#27;[0m&#27;[0m05:46:24,154 INFO  [stdout] (ServerService Thread Pool -- 1) 
> &#27;[0m&#27;[0m05:46:24,155 INFO  [stdout] (ServerService Thread Pool -- 1) -------------------------------------------------------------------
> &#27;[0m&#27;[0m05:46:24,156 INFO  [stdout] (ServerService Thread Pool -- 1) GMS: address=node-0/ejb, cluster=ejb, physical address=127.0.0.1:55200
> &#27;[0m&#27;[0m05:46:24,157 INFO  [stdout] (ServerService Thread Pool -- 1) -------------------------------------------------------------------
> &#27;[0m&#27;[0m05:46:26,383 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 1) ISPN000078: Starting JGroups Channel
> &#27;[0m&#27;[0m05:46:26,408 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 1) ISPN000094: Received new cluster view: [node-0/ejb|0] [node-0/ejb]
> &#27;[0m&#27;[0m05:46:26,411 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 1) ISPN000079: Cache local address is node-0/ejb, physical addresses are [127.0.0.1:55200]
> &#27;[0m&#27;[0m05:46:26,428 INFO  [org.infinispan.factories.GlobalComponentRegistry] (ServerService Thread Pool -- 1) ISPN000128: Infinispan version: Infinispan 'Brahma' 5.1.5.FINAL
> &#27;[0m&#27;[0m05:46:26,648 INFO  [org.infinispan.jmx.CacheJmxRegistration] (ServerService Thread Pool -- 1) ISPN000031: MBeans were successfully registered to the platform mbean server.
> &#27;[0m&#27;[0m05:46:26,832 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 1) JBAS010281: Started remote-connector-client-mappings cache from ejb container
> &#27;[0m&#27;[0m05:46:26,850 INFO  [org.infinispan.jmx.CacheJmxRegistration] (ServerService Thread Pool -- 3) ISPN000031: MBeans were successfully registered to the platform mbean server.
> &#27;[0m&#27;[0m05:46:26,871 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 3) JBAS010281: Started repl cache from ejb container
> &#27;[0m&#27;[0m05:46:26,902 INFO  [org.jboss.as.clustering] (MSC service thread 1-1) JBAS010238: Number of cluster members: 1
> &#27;[0m&#27;[0m05:46:27,058 INFO  [org.infinispan.jmx.CacheJmxRegistration] (MSC service thread 1-4) ISPN000031: MBeans were successfully registered to the platform mbean server.
> &#27;[0m&#27;[0m05:46:27,063 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-4) JBAS010281: Started org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.NodeNameSFSB cache from ejb container
> &#27;[0m&#27;[0m05:46:27,151 INFO  [org.jboss.as.server] (management-handler-thread - 2) JBAS018559: Deployed "node-name-app.jar"
> &#27;[0m&#27;[0m05:46:28,007 INFO  [org.jboss.as.repository] (management-handler-thread - 3) JBAS014900: Content added at location /home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-1/standalone/data/content/e7/e8aacd434237d96e19be07831cf2a158b389fd/content
> &#27;[0m&#27;[0m05:46:28,024 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015876: Starting deployment of "node-name-app.jar"
> &#27;[0m&#27;[0m05:46:28,106 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-5) JNDI bindings for session bean named NodeNameSFSB in deployment unit deployment "node-name-app.jar" are as follows:
>         java:global/node-name-app/NodeNameSFSB!org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.NodeNameRetriever
>         java:app/node-name-app/NodeNameSFSB!org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.NodeNameRetriever
>         java:module/NodeNameSFSB!org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.NodeNameRetriever
>         java:jboss/exported/node-name-app/NodeNameSFSB!org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.NodeNameRetriever
>         java:global/node-name-app/NodeNameSFSB
>         java:app/node-name-app/NodeNameSFSB
>         java:module/NodeNameSFSB
> &#27;[0m&#27;[33m05:46:28,883 WARN  [org.jgroups.protocols.UDP] (ServerService Thread Pool -- 26) send buffer of socket java.net.DatagramSocket at 67310bf was set to 640KB, but the OS only allocated 131.07KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> &#27;[0m&#27;[33m05:46:28,884 WARN  [org.jgroups.protocols.UDP] (ServerService Thread Pool -- 26) receive buffer of socket java.net.DatagramSocket at 67310bf was set to 20MB, but the OS only allocated 131.07KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> &#27;[0m&#27;[33m05:46:28,885 WARN  [org.jgroups.protocols.UDP] (ServerService Thread Pool -- 26) send buffer of socket java.net.MulticastSocket at 14a1373f was set to 640KB, but the OS only allocated 131.07KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
> &#27;[0m&#27;[33m05:46:28,885 WARN  [org.jgroups.protocols.UDP] (ServerService Thread Pool -- 26) receive buffer of socket java.net.MulticastSocket at 14a1373f was set to 25MB, but the OS only allocated 131.07KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> &#27;[0m&#27;[0m05:46:28,891 INFO  [stdout] (ServerService Thread Pool -- 26) 
> &#27;[0m&#27;[0m05:46:28,891 INFO  [stdout] (ServerService Thread Pool -- 26) -------------------------------------------------------------------
> &#27;[0m&#27;[0m05:46:28,891 INFO  [stdout] (ServerService Thread Pool -- 26) GMS: address=node-1/ejb, cluster=ejb, physical address=127.0.0.1:55300
> &#27;[0m&#27;[0m05:46:28,892 INFO  [stdout] (ServerService Thread Pool -- 26) -------------------------------------------------------------------
> &#27;[0m&#27;[0m05:46:28,993 INFO  [org.jboss.as.clustering] (ViewHandler,ejb,node-0/ejb) JBAS010225: New cluster view for partition ejb (id: 1, delta: 1, merge: false) : [node-0/ejb, node-1/ejb]
> &#27;[0m&#27;[0m05:46:28,999 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ViewHandler,ejb,node-0/ejb) ISPN000094: Received new cluster view: [node-0/ejb|1] [node-0/ejb, node-1/ejb]
> &#27;[0m&#27;[0m05:46:29,216 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 28) ISPN000078: Starting JGroups Channel
> &#27;[0m&#27;[0m05:46:29,240 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 28) ISPN000094: Received new cluster view: [node-0/ejb|1] [node-0/ejb, node-1/ejb]
> &#27;[0m&#27;[0m05:46:29,243 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 28) ISPN000079: Cache local address is node-1/ejb, physical addresses are [127.0.0.1:55300]
> &#27;[0m&#27;[0m05:46:29,261 INFO  [org.infinispan.factories.GlobalComponentRegistry] (ServerService Thread Pool -- 28) ISPN000128: Infinispan version: Infinispan 'Brahma' 5.1.5.FINAL
> &#27;[0m&#27;[0m05:46:29,479 INFO  [org.infinispan.jmx.CacheJmxRegistration] (ServerService Thread Pool -- 13) ISPN000031: MBeans were successfully registered to the platform mbean server.
> &#27;[0m&#27;[0m05:46:29,517 INFO  [org.infinispan.jmx.CacheJmxRegistration] (ServerService Thread Pool -- 28) ISPN000031: MBeans were successfully registered to the platform mbean server.
> &#27;[0m&#27;[0m05:46:29,879 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 28) JBAS010281: Started repl cache from ejb container
> &#27;[0m&#27;[0m05:46:29,924 INFO  [org.jboss.as.clustering] (MSC service thread 1-5) JBAS010238: Number of cluster members: 2
> &#27;[0m&#27;[0m05:46:30,001 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 13) JBAS010281: Started remote-connector-client-mappings cache from ejb container
> &#27;[0m&#27;[0m05:46:30,395 INFO  [org.jboss.ejb.client.remoting] (Remoting "node-1" task-1) EJBCLIENT000017: Received server version 1 and marshalling strategies [river]
> &#27;[0m&#27;[0m05:46:30,429 INFO  [org.jboss.ejb.client.remoting] (ejb-client-cluster-node-connection-creation-4-thread-1) EJBCLIENT000013: Successful version handshake completed for receiver context EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext at 608d116e, receiver=Remoting connection EJB receiver [connection=Remoting connection <70dbdc4b>,channel=jboss.ejb,nodename=node-0]} on channel Channel ID a99830e9 (outbound) of Remoting connection 6e843edc to /127.0.0.1:4447
> &#27;[0m&#27;[0m05:46:30,571 INFO  [org.infinispan.jmx.CacheJmxRegistration] (MSC service thread 1-4) ISPN000031: MBeans were successfully registered to the platform mbean server.
> &#27;[0m&#27;[0m05:46:30,625 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-4) JBAS010281: Started org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.NodeNameSFSB cache from ejb container
> &#27;[0m&#27;[0m05:46:30,698 INFO  [org.jboss.as.server] (management-handler-thread - 3) JBAS018559: Deployed "node-name-app.jar"
> &#27;[0m05:46:30,874 INFO  [org.jboss.ejb.client.remoting] (Remoting "config-based-ejb-client-endpoint" task-1) EJBCLIENT000017: Received server version 1 and marshalling strategies [river]
> 05:46:30,880 INFO  [org.jboss.ejb.client.remoting] (main) EJBCLIENT000013: Successful version handshake completed for receiver context EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext at 5c4e9b7d, receiver=Remoting connection EJB receiver [connection=Remoting connection <53ddcd5f>,channel=jboss.ejb,nodename=node-1]} on channel Channel ID bd97f0d8 (outbound) of Remoting connection 392bed82 to /127.0.0.1:4547
> 05:46:30,990 INFO  [org.jboss.ejb.client.remoting] (Remoting "config-based-ejb-client-endpoint" task-1) EJBCLIENT000017: Received server version 1 and marshalling strategies [river]
> 05:46:30,992 INFO  [org.jboss.ejb.client.remoting] (ejb-client-cluster-node-connection-creation-3-thread-6) EJBCLIENT000013: Successful version handshake completed for receiver context EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext at 5c4e9b7d, receiver=Remoting connection EJB receiver [connection=Remoting connection <68634baf>,channel=jboss.ejb,nodename=node-0]} on channel Channel ID e21e278d (outbound) of Remoting connection 41171d93 to /127.0.0.1:4447
> &#27;[0m05:46:31,031 INFO  [org.jboss.ejb.client] (EJB default - 1) JBoss EJB Client version 1.0.11.Final
> &#27;[0m&#27;[0m05:46:31,275 INFO  [org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.ClientSFSB] (EJB default - 2) ClientSFSB invoked on node-1
> &#27;[0m&#27;[0m05:46:31,327 INFO  [org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.NodeNameSFSB] (EJB default - 2) NodeNameSFSB invoked on node-1
> &#27;[0m&#27;[0m05:46:31,407 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 13) ISPN000029: Passivating all entries to disk
> &#27;[0m&#27;[0m05:46:31,435 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 13) ISPN000030: Passivated 1 entries in 27 milliseconds
> &#27;[0m&#27;[0m05:46:31,454 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 13) JBAS010282: Stopped org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.NodeNameSFSB cache from ejb container
> &#27;[0m&#27;[0m05:46:31,506 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-5) ISPN000029: Passivating all entries to disk
> &#27;[0m&#27;[0m05:46:31,512 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-5) ISPN000030: Passivated 0 entries in 5 milliseconds
> &#27;[0m&#27;[0m05:46:31,544 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-5) JBAS010282: Stopped repl cache from ejb container
> &#27;[0m&#27;[0m05:46:31,544 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-3) JBAS010282: Stopped remote-connector-client-mappings cache from ejb container
> &#27;[0m&#27;[0m05:46:31,553 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015877: Stopped deployment node-name-app.jar in 168ms
> &#27;[0m&#27;[0m05:46:31,598 INFO  [org.infinispan.cacheviews.CacheViewsManagerImpl] (OOB-15,null) ISPN000170: Our last committed view (CacheView{viewId=2, members=[node-0/ejb, node-1/ejb]}) is not the same as the coordinator's last committed view (CacheView{viewId=3, members=[node-0/ejb]}). This is normal during a merge
> &#27;[0m&#27;[0m05:46:31,631 INFO  [org.infinispan.cacheviews.CacheViewsManagerImpl] (OOB-17,null) ISPN000170: Our last committed view (CacheView{viewId=2, members=[node-0/ejb, node-1/ejb]}) is not the same as the coordinator's last committed view (CacheView{viewId=3, members=[node-0/ejb]}). This is normal during a merge
> &#27;[0m&#27;[33m05:46:31,602 WARN  [org.infinispan.commands.control.CacheViewControlCommand] (OOB-15,null) ISPN000071: Caught exception when handling command CacheViewControlCommand{cache=remote-connector-client-mappings, type=PREPARE_VIEW, sender=node-0/ejb, newViewId=4, newMembers=[node-0/ejb, node-1/ejb], oldViewId=3, oldMembers=[node-0/ejb]}: java.lang.IllegalStateException: remote-connector-client-mappings: Received cache view prepare request after the local node has already shut down
>         at org.infinispan.cacheviews.CacheViewsManagerImpl.handlePrepareView(CacheViewsManagerImpl.java:487)
>         at org.infinispan.commands.control.CacheViewControlCommand.perform(CacheViewControlCommand.java:126)
>         at org.infinispan.remoting.InboundInvocationHandlerImpl.handle(InboundInvocationHandlerImpl.java:95)
>         at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommand(CommandAwareRpcDispatcher.java:226)
>         at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:203)
>         at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:465)
>         at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:372)
>         at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:247)
>         at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:601)
>         at org.jgroups.blocks.mux.MuxUpHandler.up(MuxUpHandler.java:130)
>         at org.jgroups.JChannel.up(JChannel.java:715)
>         at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1020)
>         at org.jgroups.protocols.RSVP.up(RSVP.java:179)
>         at org.jgroups.protocols.FRAG2.up(FRAG2.java:181)
>         at org.jgroups.protocols.FlowControl.up(FlowControl.java:418)
>         at org.jgroups.protocols.FlowControl.up(FlowControl.java:400)
>         at org.jgroups.protocols.pbcast.GMS.up(GMS.java:899)
>         at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244)
>         at org.jgroups.protocols.UNICAST2.handleDataReceived(UNICAST2.java:744)
>         at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:414)
>         at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:572)
>         at org.jgroups.protocols.BARRIER.up(BARRIER.java:102)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143)
>         at org.jgroups.protocols.FD.up(FD.java:273)
>         at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288)
>         at org.jgroups.protocols.MERGE2.up(MERGE2.java:205)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:359)
>         at org.jgroups.protocols.TP$ProtocolAdapter.up(TP.java:2568)
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:1211)
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1775)
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1748)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
>         at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> &#27;[0m&#27;[33m05:46:31,596 WARN  [org.infinispan.commands.control.CacheViewControlCommand] (OOB-20,null) ISPN000071: Caught exception when handling command CacheViewControlCommand{cache=repl, type=PREPARE_VIEW, sender=node-0/ejb, newViewId=3, newMembers=[node-0/ejb, node-1/ejb, node-1/ejb], oldViewId=2, oldMembers=[node-0/ejb, node-1/ejb]}: java.lang.IllegalStateException: repl: Received cache view prepare request after the local node has already shut down
>         at org.infinispan.cacheviews.CacheViewsManagerImpl.handlePrepareView(CacheViewsManagerImpl.java:487)
>         at org.infinispan.commands.control.CacheViewControlCommand.perform(CacheViewControlCommand.java:126)
>         at org.infinispan.remoting.InboundInvocationHandlerImpl.handle(InboundInvocationHandlerImpl.java:95)
>         at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommand(CommandAwareRpcDispatcher.java:226)
>         at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:203)
>         at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:465)
>         at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:372)
>         at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:247)
>         at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:601)
>         at org.jgroups.blocks.mux.MuxUpHandler.up(MuxUpHandler.java:130)
>         at org.jgroups.JChannel.up(JChannel.java:715)
>         at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1020)
>         at org.jgroups.protocols.RSVP.up(RSVP.java:179)
>         at org.jgroups.protocols.FRAG2.up(FRAG2.java:181)
>         at org.jgroups.protocols.FlowControl.up(FlowControl.java:418)
>         at org.jgroups.protocols.FlowControl.up(FlowControl.java:400)
>         at org.jgroups.protocols.pbcast.GMS.up(GMS.java:899)
>         at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244)
>         at org.jgroups.protocols.UNICAST2.handleDataReceived(UNICAST2.java:744)
>         at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:414)
>         at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:572)
>         at org.jgroups.protocols.BARRIER.up(BARRIER.java:102)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143)
>         at org.jgroups.protocols.FD.up(FD.java:273)
>         at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288)
>         at org.jgroups.protocols.MERGE2.up(MERGE2.java:205)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:359)
>         at org.jgroups.protocols.TP$ProtocolAdapter.up(TP.java:2568)
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:1211)
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1775)
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1748)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
>         at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> &#27;[0m&#27;[33m05:46:31,631 WARN  [org.infinispan.commands.control.CacheViewControlCommand] (OOB-16,null) ISPN000071: Caught exception when handling command CacheViewControlCommand{cache=repl, type=PREPARE_VIEW, sender=node-0/ejb, newViewId=3, newMembers=[node-0/ejb, node-1/ejb, node-1/ejb], oldViewId=2, oldMembers=[node-0/ejb, node-1/ejb]}: java.lang.IllegalStateException: Cannot prepare new view CacheView{viewId=3, members=[node-0/ejb, node-1/ejb, node-1/ejb]} on cache repl, we are currently preparing view CacheView{viewId=3, members=[node-0/ejb, node-1/ejb, node-1/ejb]}
>         at org.infinispan.cacheviews.CacheViewInfo.prepareView(CacheViewInfo.java:102)
>         at org.infinispan.cacheviews.CacheViewsManagerImpl.handlePrepareView(CacheViewsManagerImpl.java:481)
>         at org.infinispan.commands.control.CacheViewControlCommand.perform(CacheViewControlCommand.java:126)
>         at org.infinispan.remoting.InboundInvocationHandlerImpl.handle(InboundInvocationHandlerImpl.java:95)
>         at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommand(CommandAwareRpcDispatcher.java:226)
>         at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:203)
>         at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:465)
>         at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:372)
>         at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:247)
>         at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:601)
>         at org.jgroups.blocks.mux.MuxUpHandler.up(MuxUpHandler.java:130)
>         at org.jgroups.JChannel.up(JChannel.java:715)
>         at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1020)
>         at org.jgroups.protocols.RSVP.up(RSVP.java:179)
>         at org.jgroups.protocols.FRAG2.up(FRAG2.java:181)
>         at org.jgroups.protocols.FlowControl.up(FlowControl.java:418)
>         at org.jgroups.protocols.FlowControl.up(FlowControl.java:400)
>         at org.jgroups.protocols.pbcast.GMS.up(GMS.java:899)
>         at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244)
>         at org.jgroups.protocols.UNICAST2.handleDataReceived(UNICAST2.java:744)
>         at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:414)
>         at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:572)
>         at org.jgroups.protocols.BARRIER.up(BARRIER.java:102)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143)
>         at org.jgroups.protocols.FD.up(FD.java:273)
>         at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288)
>         at org.jgroups.protocols.MERGE2.up(MERGE2.java:205)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:359)
>         at org.jgroups.protocols.TP$ProtocolAdapter.up(TP.java:2568)
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:1211)
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1775)
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1748)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
>         at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> &#27;[0m&#27;[33m05:46:31,637 WARN  [org.infinispan.commands.control.CacheViewControlCommand] (OOB-17,null) ISPN000071: Caught exception when handling command CacheViewControlCommand{cache=org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.NodeNameSFSB, type=PREPARE_VIEW, sender=node-0/ejb, newViewId=4, newMembers=[node-0/ejb, node-1/ejb], oldViewId=3, oldMembers=[node-0/ejb]}: java.lang.IllegalStateException: org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.NodeNameSFSB: Received cache view prepare request after the local node has already shut down
>         at org.infinispan.cacheviews.CacheViewsManagerImpl.handlePrepareView(CacheViewsManagerImpl.java:487)
>         at org.infinispan.commands.control.CacheViewControlCommand.perform(CacheViewControlCommand.java:126)
>         at org.infinispan.remoting.InboundInvocationHandlerImpl.handle(InboundInvocationHandlerImpl.java:95)
>         at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommand(CommandAwareRpcDispatcher.java:226)
>         at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:203)
>         at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:465)
>         at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:372)
>         at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:247)
>         at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:601)
>         at org.jgroups.blocks.mux.MuxUpHandler.up(MuxUpHandler.java:130)
>         at org.jgroups.JChannel.up(JChannel.java:715)
>         at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1020)
>         at org.jgroups.protocols.RSVP.up(RSVP.java:179)
>         at org.jgroups.protocols.FRAG2.up(FRAG2.java:181)
>         at org.jgroups.protocols.FlowControl.up(FlowControl.java:418)
>         at org.jgroups.protocols.FlowControl.up(FlowControl.java:400)
>         at org.jgroups.protocols.pbcast.GMS.up(GMS.java:899)
>         at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244)
>         at org.jgroups.protocols.UNICAST2.handleDataReceived(UNICAST2.java:744)
>         at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:414)
>         at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:572)
>         at org.jgroups.protocols.BARRIER.up(BARRIER.java:102)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143)
>         at org.jgroups.protocols.FD.up(FD.java:273)
>         at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288)
>         at org.jgroups.protocols.MERGE2.up(MERGE2.java:205)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:359)
>         at org.jgroups.protocols.TP$ProtocolAdapter.up(TP.java:2568)
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:1211)
>         at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1775)
>         at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1748)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
>         at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> &#27;[0m&#27;[0m05:46:31,865 INFO  [org.jboss.as.clustering] (ViewHandler,ejb,node-0/ejb) JBAS010225: New cluster view for partition ejb (id: 2, delta: -1, merge: false) : [node-0/ejb]
> &#27;[0m&#27;[0m05:46:31,869 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ViewHandler,ejb,node-0/ejb) ISPN000094: Received new cluster view: [node-0/ejb|2] [node-0/ejb]
> &#27;[0m&#27;[31m05:46:31,866 ERROR [org.infinispan.cacheviews.CacheViewsManagerImpl] (CacheViewInstaller-3,node-0/ejb) ISPN000172: Failed to prepare view CacheView{viewId=4, members=[node-0/ejb, node-1/ejb]} for cache  org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.NodeNameSFSB, rolling back to view CacheView{viewId=3, members=[node-0/ejb]}: java.util.concurrent.ExecutionException: org.infinispan.remoting.transport.jgroups.SuspectException: Node node-1/ejb was suspected
>         at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:232) [rt.jar:1.6.0_29]
>         at java.util.concurrent.FutureTask.get(FutureTask.java:91) [rt.jar:1.6.0_29]
>         at org.infinispan.cacheviews.CacheViewsManagerImpl.clusterPrepareView(CacheViewsManagerImpl.java:318) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.cacheviews.CacheViewsManagerImpl.clusterInstallView(CacheViewsManagerImpl.java:249) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.cacheviews.CacheViewsManagerImpl$ViewInstallationTask.call(CacheViewsManagerImpl.java:875) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [rt.jar:1.6.0_29]
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138) [rt.jar:1.6.0_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
>         at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> Caused by: org.infinispan.remoting.transport.jgroups.SuspectException: Node node-1/ejb was suspected
>         at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:170) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:489) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.cacheviews.CacheViewsManagerImpl$2.call(CacheViewsManagerImpl.java:302) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.cacheviews.CacheViewsManagerImpl$2.call(CacheViewsManagerImpl.java:299) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         ... 5 more
> Caused by: SuspectedException
>         at org.jgroups.blocks.MessageDispatcher.sendMessage(MessageDispatcher.java:373) [jgroups-3.1.0.Final.jar:3.1.0.Final]
>         at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:275) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:165) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         ... 8 more
> &#27;[0m&#27;[31m05:46:31,866 ERROR [org.infinispan.cacheviews.CacheViewsManagerImpl] (CacheViewInstaller-1,node-0/ejb) ISPN000172: Failed to prepare view CacheView{viewId=4, members=[node-0/ejb, node-1/ejb]} for cache  remote-connector-client-mappings, rolling back to view CacheView{viewId=3, members=[node-0/ejb]}: java.util.concurrent.ExecutionException: org.infinispan.remoting.transport.jgroups.SuspectException: Node node-1/ejb was suspected
>         at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:232) [rt.jar:1.6.0_29]
>         at java.util.concurrent.FutureTask.get(FutureTask.java:91) [rt.jar:1.6.0_29]
>         at org.infinispan.cacheviews.CacheViewsManagerImpl.clusterPrepareView(CacheViewsManagerImpl.java:318) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.cacheviews.CacheViewsManagerImpl.clusterInstallView(CacheViewsManagerImpl.java:249) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.cacheviews.CacheViewsManagerImpl$ViewInstallationTask.call(CacheViewsManagerImpl.java:875) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [rt.jar:1.6.0_29]
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138) [rt.jar:1.6.0_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
>         at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> Caused by: org.infinispan.remoting.transport.jgroups.SuspectException: Node node-1/ejb was suspected
>         at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:170) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:489) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.cacheviews.CacheViewsManagerImpl$2.call(CacheViewsManagerImpl.java:302) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.cacheviews.CacheViewsManagerImpl$2.call(CacheViewsManagerImpl.java:299) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         ... 5 more
> Caused by: SuspectedException
>         at org.jgroups.blocks.MessageDispatcher.sendMessage(MessageDispatcher.java:373) [jgroups-3.1.0.Final.jar:3.1.0.Final]
>         at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:275) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:165) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         ... 8 more
> &#27;[0m&#27;[0m05:46:31,968 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000082: Stopping the RpcDispatcher
> &#27;[0m&#27;[0m05:46:32,008 INFO  [org.jboss.as.repository] (management-handler-thread - 1) JBAS014901: Content removed from location /home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-1/standalone/data/content/e7/e8aacd434237d96e19be07831cf2a158b389fd/content
> &#27;[0m&#27;[0m05:46:32,010 INFO  [org.jboss.as.server] (management-handler-thread - 1) JBAS018558: Undeployed "node-name-app.jar"
> &#27;[0m&#27;[0m05:46:32,023 INFO  [org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.ClientSFSB] (EJB default - 3) ClientSFSB invoked on node-1
> &#27;[0m&#27;[0m05:46:32,030 INFO  [org.jboss.as.ejb3] (EJB default - 3) JBAS014101: Failed to find SFSB instance with session ID {[-104, 47, 35, -120, 125, 36, 71, 13, -117, 111, -46, -34, -73, -51, 56, 28]} in cache
> &#27;[0m&#27;[31m05:46:32,032 ERROR [org.jboss.as.ejb3.invocation] (EJB default - 3) JBAS014134: EJB Invocation failed on component ClientSFSB for method public abstract java.lang.String org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.ClientSFSBRemote.invokeAndFetchNodeNameFromClusteredSFSBRemoteBean(): javax.ejb.EJBException: java.lang.IllegalArgumentException: JBAS014155: Unknown deployment - app name:  module name: node-name-app distinct name: 
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:165) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:229) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:303) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:189) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:42) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:43) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:327) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:70) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:205) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [rt.jar:1.6.0_29]
>         at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [rt.jar:1.6.0_29]
>         at java.util.concurrent.FutureTask.run(FutureTask.java:138) [rt.jar:1.6.0_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
>         at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
>         at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> Caused by: java.lang.IllegalArgumentException: JBAS014155: Unknown deployment - app name:  module name: node-name-app distinct name: 
>         at org.jboss.as.ejb3.remote.LocalEjbReceiver.findBean(LocalEjbReceiver.java:317) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.as.ejb3.remote.LocalEjbReceiver.processInvocation(LocalEjbReceiver.java:142) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:181) [jboss-ejb-client-1.0.11.Final.jar:1.0.11.Final]
>         at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:42) [jboss-ejb-client-1.0.11.Final.jar:1.0.11.Final]
>         at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183) [jboss-ejb-client-1.0.11.Final.jar:1.0.11.Final]
>         at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:125) [jboss-ejb-client-1.0.11.Final.jar:1.0.11.Final]
>         at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183) [jboss-ejb-client-1.0.11.Final.jar:1.0.11.Final]
>         at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:136) [jboss-ejb-client-1.0.11.Final.jar:1.0.11.Final]
>         at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:121) [jboss-ejb-client-1.0.11.Final.jar:1.0.11.Final]
>         at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:104) [jboss-ejb-client-1.0.11.Final.jar:1.0.11.Final]
>         at $Proxy30.getNodeName(Unknown Source) at org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.ClientSFSB.invokeAndFetchNodeNameFromClusteredSFSBRemoteBean(ClientSFSB.java:53) [client-app.jar:]
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_29]
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_29]
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_29]
>         at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_29]
>         at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:36) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:58)
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:156) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:67) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
>         at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:227) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         ... 29 more
> &#27;[0m05:46:32,102 INFO  [org.jboss.ejb.client.remoting] (Remoting "config-based-ejb-client-endpoint" task-3) EJBCLIENT000011: Discarding result for invocation id 2 since no waiting context found
> &#27;[0m05:46:32,228 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015877: Stopped deployment client-app.jar in 54ms
> &#27;[0m&#27;[0m05:46:32,272 INFO  [org.jboss.as.repository] (management-handler-thread - 2) JBAS014901: Content removed from location /home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-1/standalone/data/content/e2/09ce1c0485164619e2ea871a0013f2781ab162/content
> &#27;[0m&#27;[0m05:46:32,274 INFO  [org.jboss.as.server] (management-handler-thread - 2) JBAS018558: Undeployed "client-app.jar"
> &#27;[0m&#27;[0m05:46:32,328 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 3) ISPN000029: Passivating all entries to disk
> &#27;[0m&#27;[0m05:46:32,350 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 3) ISPN000030: Passivated 1 entries in 22 milliseconds
> &#27;[0m&#27;[0m05:47:31,693 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 3) JBAS010282: Stopped org.jboss.as.test.clustering.cluster.ejb3.stateful.remote.failover.NodeNameSFSB cache from ejb container
> &#27;[0m&#27;[0m05:47:31,740 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-6) ISPN000029: Passivating all entries to disk
> &#27;[0m&#27;[0m05:47:31,746 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-6) ISPN000030: Passivated 0 entries in 5 milliseconds
> &#27;[0m&#27;[0m05:47:31,764 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-6) JBAS010282: Stopped repl cache from ejb container
> &#27;[0m&#27;[0m05:47:31,768 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015877: Stopped deployment node-name-app.jar in 59465ms
> &#27;[0m&#27;[31m05:47:31,882 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (notification-thread-6) ISPN000136: Execution error: org.infinispan.statetransfer.StateTransferInProgressException: Timed out waiting for the state transfer lock, state transfer in progress for view 4
>         at org.infinispan.interceptors.StateTransferLockInterceptor.signalStateTransferInProgress(StateTransferLockInterceptor.java:201)
>         at org.infinispan.interceptors.StateTransferLockInterceptor.visitPrepareCommand(StateTransferLockInterceptor.java:81)
>         at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
>         at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130)
>         at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
>         at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
>         at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:132)
>         at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:91)
>         at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
>         at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
>         at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:86)
>         at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
>         at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
>         at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:345)
>         at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:140)
>         at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:122)
>         at org.infinispan.transaction.synchronization.SynchronizationAdapter.beforeCompletion(SynchronizationAdapter.java:68)
>         at org.infinispan.transaction.tm.DummyTransaction.notifyBeforeCompletion(DummyTransaction.java:230)
>         at org.infinispan.transaction.tm.DummyTransaction.runPrepare(DummyTransaction.java:242)
>         at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:86)
>         at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:102)
>         at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:123)
>         at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:105)
>         at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:86)
>         at org.infinispan.CacheImpl.endBatch(CacheImpl.java:615)
>         at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:80)
>         at org.jboss.as.clustering.registry.RegistryService.invoke(RegistryService.java:260)
>         at org.jboss.as.clustering.registry.RegistryService.viewChanged(RegistryService.java:195)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_29]
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_29]
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_29]
>         at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_29]
>         at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation$1.run(AbstractListenerImpl.java:200)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
>         at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> &#27;[0m&#27;[31m05:47:31,905 ERROR [org.infinispan.transaction.TransactionCoordinator] (notification-thread-6) Error while processing prepare: org.infinispan.statetransfer.StateTransferInProgressException: Timed out waiting for the state transfer lock, state transfer in progress for view 4
>         at org.infinispan.interceptors.StateTransferLockInterceptor.signalStateTransferInProgress(StateTransferLockInterceptor.java:201)
>         at org.infinispan.interceptors.StateTransferLockInterceptor.visitPrepareCommand(StateTransferLockInterceptor.java:81)
>         at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
>         at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130)
>         at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
>         at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
>         at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:132)
>         at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:91)
>         at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
>         at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
>         at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:86)
>         at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
>         at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
>         at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:345)
>         at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:140)
>         at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:122)
>         at org.infinispan.transaction.synchronization.SynchronizationAdapter.beforeCompletion(SynchronizationAdapter.java:68)
>         at org.infinispan.transaction.tm.DummyTransaction.notifyBeforeCompletion(DummyTransaction.java:230)
>         at org.infinispan.transaction.tm.DummyTransaction.runPrepare(DummyTransaction.java:242)
>         at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:86)
>         at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:102)
>         at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:123)
>         at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:105)
>         at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:86)
>         at org.infinispan.CacheImpl.endBatch(CacheImpl.java:615)
>         at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:80)
>         at org.jboss.as.clustering.registry.RegistryService.invoke(RegistryService.java:260)
>         at org.jboss.as.clustering.registry.RegistryService.viewChanged(RegistryService.java:195)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_29]
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_29]
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_29]
>         at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_29]
>         at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation$1.run(AbstractListenerImpl.java:200)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
>         at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> &#27;[0m&#27;[31m05:47:31,924 ERROR [org.infinispan.transaction.tm.DummyTransaction] (notification-thread-6) ISPN000109: beforeCompletion() failed for SynchronizationAdapter{localTransaction=LocalTransaction{remoteLockedNodes=null, isMarkedForRollback=false, transaction=DummyTransaction{xid=DummyXid{id=3}, status=1}, lockedKeys=null, backupKeyLocks=null, viewId=2} org.infinispan.transaction.synchronization.SyncLocalTransaction at 2} org.infinispan.transaction.synchronization.SynchronizationAdapter at 21: org.infinispan.CacheException: Could not prepare. 
>         at org.infinispan.transaction.synchronization.SynchronizationAdapter.beforeCompletion(SynchronizationAdapter.java:70)
>         at org.infinispan.transaction.tm.DummyTransaction.notifyBeforeCompletion(DummyTransaction.java:230)
>         at org.infinispan.transaction.tm.DummyTransaction.runPrepare(DummyTransaction.java:242)
>         at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:86)
>         at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:102)
>         at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:123)
>         at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:105)
>         at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:86)
>         at org.infinispan.CacheImpl.endBatch(CacheImpl.java:615)
>         at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:80)
>         at org.jboss.as.clustering.registry.RegistryService.invoke(RegistryService.java:260)
>         at org.jboss.as.clustering.registry.RegistryService.viewChanged(RegistryService.java:195)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_29]
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_29]
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_29]
>         at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_29]
>         at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation$1.run(AbstractListenerImpl.java:200)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
>         at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> Caused by: javax.transaction.xa.XAException
>         at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:160)
>         at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:122)
>         at org.infinispan.transaction.synchronization.SynchronizationAdapter.beforeCompletion(SynchronizationAdapter.java:68)
>         ... 19 more
> &#27;[0m&#27;[33m05:47:31,936 WARN  [org.infinispan.notifications.cachemanagerlistener.CacheManagerNotifierImpl] (notification-thread-6) ISPN000134: Unable to invoke method public void org.jboss.as.clustering.registry.RegistryService.viewChanged(org.infinispan.notifications.cachemanagerlistener.event.ViewChangedEvent) on Object instance org.jboss.as.clustering.registry.RegistryService at d07ffdf - removing this target object from list of listeners!: org.infinispan.CacheException: Unable to end batch
>         at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:107)
>         at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:86)
>         at org.infinispan.CacheImpl.endBatch(CacheImpl.java:615)
>         at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:80)
>         at org.jboss.as.clustering.registry.RegistryService.invoke(RegistryService.java:260)
>         at org.jboss.as.clustering.registry.RegistryService.viewChanged(RegistryService.java:195)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_29]
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_29]
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_29]
>         at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_29]
>         at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation$1.run(AbstractListenerImpl.java:200)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
>         at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> Caused by: javax.transaction.RollbackException: Exception rolled back, status is: 9
>         at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:89)
>         at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:102)
>         at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:123)
>         at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:105)
>         ... 13 more
> &#27;[0m&#27;[31m05:48:31,737 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (MSC service thread 1-3) ISPN000136: Execution error: org.infinispan.statetransfer.StateTransferInProgressException: Timed out waiting for the state transfer lock, state transfer in progress for view 4
>         at org.infinispan.interceptors.StateTransferLockInterceptor.signalStateTransferInProgress(StateTransferLockInterceptor.java:201) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.interceptors.StateTransferLockInterceptor.visitPrepareCommand(StateTransferLockInterceptor.java:81) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:132) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:91) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:86) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:345) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:140) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:122) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.synchronization.SynchronizationAdapter.beforeCompletion(SynchronizationAdapter.java:68) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.tm.DummyTransaction.notifyBeforeCompletion(DummyTransaction.java:230) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.tm.DummyTransaction.runPrepare(DummyTransaction.java:242) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:86) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:102) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:123) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:105) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:86) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.CacheImpl.endBatch(CacheImpl.java:615) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:80) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.jboss.as.clustering.registry.RegistryService.invoke(RegistryService.java:260) [jboss-as-clustering-registry-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.as.clustering.registry.RegistryService.stop(RegistryService.java:162) [jboss-as-clustering-registry-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:1911) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>         at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:1874) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
>         at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> &#27;[0m&#27;[31m05:48:31,745 ERROR [org.infinispan.transaction.TransactionCoordinator] (MSC service thread 1-3) Error while processing prepare: org.infinispan.statetransfer.StateTransferInProgressException: Timed out waiting for the state transfer lock, state transfer in progress for view 4
>         at org.infinispan.interceptors.StateTransferLockInterceptor.signalStateTransferInProgress(StateTransferLockInterceptor.java:201) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.interceptors.StateTransferLockInterceptor.visitPrepareCommand(StateTransferLockInterceptor.java:81) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:132) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:91) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:86) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:345) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:140) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:122) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.synchronization.SynchronizationAdapter.beforeCompletion(SynchronizationAdapter.java:68) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.tm.DummyTransaction.notifyBeforeCompletion(DummyTransaction.java:230) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.tm.DummyTransaction.runPrepare(DummyTransaction.java:242) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:86) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:102) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:123) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:105) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:86) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.CacheImpl.endBatch(CacheImpl.java:615) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:80) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.jboss.as.clustering.registry.RegistryService.invoke(RegistryService.java:260) [jboss-as-clustering-registry-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.as.clustering.registry.RegistryService.stop(RegistryService.java:162) [jboss-as-clustering-registry-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:1911) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>         at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:1874) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
>         at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> &#27;[0m&#27;[31m05:48:31,754 ERROR [org.infinispan.transaction.tm.DummyTransaction] (MSC service thread 1-3) ISPN000109: beforeCompletion() failed for SynchronizationAdapter{localTransaction=LocalTransaction{remoteLockedNodes=null, isMarkedForRollback=false, transaction=DummyTransaction{xid=DummyXid{id=4}, status=1}, lockedKeys=null, backupKeyLocks=null, viewId=2} org.infinispan.transaction.synchronization.SyncLocalTransaction at 3} org.infinispan.transaction.synchronization.SynchronizationAdapter at 22: org.infinispan.CacheException: Could not prepare. 
>         at org.infinispan.transaction.synchronization.SynchronizationAdapter.beforeCompletion(SynchronizationAdapter.java:70) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.tm.DummyTransaction.notifyBeforeCompletion(DummyTransaction.java:230) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.tm.DummyTransaction.runPrepare(DummyTransaction.java:242) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:86) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:102) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:123) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:105) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:86) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.CacheImpl.endBatch(CacheImpl.java:615) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:80) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.jboss.as.clustering.registry.RegistryService.invoke(RegistryService.java:260) [jboss-as-clustering-registry-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.as.clustering.registry.RegistryService.stop(RegistryService.java:162) [jboss-as-clustering-registry-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
>         at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:1911) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>         at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:1874) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
>         at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> Caused by: javax.transaction.xa.XAException
>         at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:160) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:122) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         at org.infinispan.transaction.synchronization.SynchronizationAdapter.beforeCompletion(SynchronizationAdapter.java:68) [infinispan-core-5.1.5.FINAL.jar:5.1.5.FINAL]
>         ... 16 more
> &#27;[0m&#27;[33m05:48:31,763 WARN  [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC00004: Failure during stop of service jboss.ejb.remoting.connector.client-mappings.registry.ejb: org.infinispan.CacheException: Unable to end batch
>         at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:107)
>         at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:86)
>         at org.infinispan.CacheImpl.endBatch(CacheImpl.java:615)
>         at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:80)
>         at org.jboss.as.clustering.registry.RegistryService.invoke(RegistryService.java:260)
>         at org.jboss.as.clustering.registry.RegistryService.stop(RegistryService.java:162)
>         at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:1911) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>         at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:1874) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
>         at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
> Caused by: javax.transaction.RollbackException: Exception rolled back, status is: 9
>         at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:89)
>         at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:102)
>         at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:123)
>         at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:105)
>         ... 10 more
> &#27;[0m&#27;[0m05:48:31,791 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-2) JBAS010282: Stopped remote-connector-client-mappings cache from ejb container
> &#27;[0m&#27;[0m05:48:31,839 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000082: Stopping the RpcDispatcher
> &#27;[0m&#27;[0m05:48:31,899 INFO  [org.jboss.as.repository] (management-handler-thread - 3) JBAS014901: Content removed from location /home/jenkins/jenkins-work/workspace/as7-master-testsuite/testsuite/integration/clust/target/jbossas-clustering-udp-0/standalone/data/content/dc/274297a56acebcb3414b7407fa05d097f6691b/content
> &#27;[0m&#27;[0m05:48:31,902 INFO  [org.jboss.as.server] (management-handler-thread - 3) JBAS018558: Undeployed "node-name-app.jar"
> &#27;[0m05:48:31,906 INFO  [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual stopping of a server instance
> 05:48:32,069 INFO  [org.jboss.ejb.client.remoting] (Remoting "config-based-ejb-client-endpoint" task-2) EJBCLIENT000016: Channel Channel ID e21e278d (outbound) of Remoting connection 41171d93 to /127.0.0.1:4447 can no longer process messages
> &#27;[0m05:48:32,149 INFO  [org.jboss.ejb.client.remoting] (Remoting "node-1" task-3) EJBCLIENT000016: Channel Channel ID a99830e9 (outbound) of Remoting connection 6e843edc to /127.0.0.1:4447 can no longer process messages
> &#27;[0m05:48:32,256 INFO  [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual stopping of a server instance 
> 05:48:32,345 INFO  [org.jboss.ejb.client.remoting] (Remoting "config-based-ejb-client-endpoint" task-4) EJBCLIENT000016: Channel Channel ID bd97f0d8 (outbound) of Remoting connection 392bed82 to /127.0.0.1:4547 can no longer process messages

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Thu Oct 31 11:08:02 2013
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Thu, 31 Oct 2013 11:08:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1725) JGroups testsuite output not
 processed correctly on Windows
In-Reply-To: <JIRA.12509140.1383170133000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509140.1383170133000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509140.1383170133000.26435.1383232082544@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12826210#comment-12826210 ] 

Richard Achmatowicz commented on JGRP-1725:
-------------------------------------------

Tested on LInux (Fedora) and Windows (Windows 7 Professional) and the output is now correctly being collected into the test case files.
 
                
> JGroups testsuite output not processed correctly on Windows
> -----------------------------------------------------------
>
>                 Key: JGRP-1725
>                 URL: https://issues.jboss.org/browse/JGRP-1725
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.5
>         Environment: Windows
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>            Priority: Optional
>             Fix For: 3.5
>
>
> When running the testsuite on Windows, testsuite output ends up on the console and not in the test case reports.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 11:08:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 11:08:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-753) Enable the
	CalendarBasedTimeoutTestCase
In-Reply-To: <JIRA.12445932.1314788908000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12445932.1314788908000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12445932.1314788908000.26438.1383232082659@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFLY-753:
-----------------------------------

    Assignee: David Lloyd  (was: Stuart Douglas)

    
> Enable the CalendarBasedTimeoutTestCase
> ---------------------------------------
>
>                 Key: WFLY-753
>                 URL: https://issues.jboss.org/browse/WFLY-753
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>            Reporter: jaikiran pai
>            Assignee: David Lloyd
>             Fix For: Awaiting Volunteers
>
>
> org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase is currently disabled since it's a bit slow as it runs against all known timezones. This needs to be re-enabled and maybe moved to a different profile.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 11:10:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 11:10:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-753) Enable the
	CalendarBasedTimeoutTestCase
In-Reply-To: <JIRA.12445932.1314788908000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12445932.1314788908000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12445932.1314788908000.26442.1383232202107@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFLY-753:
-----------------------------------

    Assignee:     (was: David Lloyd)

    
> Enable the CalendarBasedTimeoutTestCase
> ---------------------------------------
>
>                 Key: WFLY-753
>                 URL: https://issues.jboss.org/browse/WFLY-753
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>            Reporter: jaikiran pai
>             Fix For: Awaiting Volunteers
>
>
> org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase is currently disabled since it's a bit slow as it runs against all known timezones. This needs to be re-enabled and maybe moved to a different profile.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 11:10:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 11:10:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-671) Failure in
 CalendarUtilTestCase.testEveryMinuteEveryHourEveryDay
In-Reply-To: <JIRA.12446129.1314950572000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12446129.1314950572000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12446129.1314950572000.26448.1383232202451@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFLY-671:
-----------------------------------

    Assignee:     (was: Stuart Douglas)

    
> Failure in CalendarUtilTestCase.testEveryMinuteEveryHourEveryDay
> ----------------------------------------------------------------
>
>                 Key: WFLY-671
>                 URL: https://issues.jboss.org/browse/WFLY-671
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>            Reporter: Carlo de Wolf
>            Priority: Minor
>             Fix For: Awaiting Volunteers
>
>
> I'm unable to compile AS 7.
> {noformat}
> Failed tests:   testEveryMinuteEveryHourEveryDay[379](org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase): Unexpected timeout value: java.util.GregorianCalendar[time=1314918060000,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=sun.util.calendar.ZoneInfo[id="Asia/Gaza",offset=7200000,dstSavings=3600000,useDaylight=true,transitions=144,lastRule=java.util.SimpleTimeZone[id=Asia/Gaza,offset=7200000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=7,startTime=60000,startTimeMode=0,endMode=3,endMonth=8,endDay=1,endDayOfWeek=6,endTime=7200000,endTimeMode=0]],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=2011,MONTH=8,WEEK_OF_YEAR=36,WEEK_OF_MONTH=1,DAY_OF_MONTH=2,DAY_OF_YEAR=245,DAY_OF_WEEK=6,DAY_OF_WEEK_IN_MONTH=1,AM_PM=0,HOUR=1,HOUR_OF_DAY=1,MINUTE=1,SECOND=0,MILLISECOND=0,ZONE_OFFSET=7200000,DST_OFFSET=0] expected:<60000> but was:<3660000>
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 11:10:02 2013
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Thu, 31 Oct 2013 11:10:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1725) JGroups testsuite output not
 processed correctly on Windows
In-Reply-To: <JIRA.12509140.1383170133000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509140.1383170133000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509140.1383170133000.26446.1383232202353@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Achmatowicz closed JGRP-1725.
-------------------------------------

    Resolution: Done

    
> JGroups testsuite output not processed correctly on Windows
> -----------------------------------------------------------
>
>                 Key: JGRP-1725
>                 URL: https://issues.jboss.org/browse/JGRP-1725
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.5
>         Environment: Windows
>            Reporter: Richard Achmatowicz
>            Assignee: Bela Ban
>            Priority: Optional
>             Fix For: 3.5
>
>
> When running the testsuite on Windows, testsuite output ends up on the console and not in the test case reports.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 11:16:03 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Thu, 31 Oct 2013 11:16:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2422) Simplify the remote-outbound
	connections
In-Reply-To: <JIRA.12509159.1383210125000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509159.1383210125000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509159.1383210125000.26483.1383232563666@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12826216#comment-12826216 ] 

David Lloyd commented on WFLY-2422:
-----------------------------------

Agreed.
                
> Simplify the remote-outbound connections
> ----------------------------------------
>
>                 Key: WFLY-2422
>                 URL: https://issues.jboss.org/browse/WFLY-2422
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: EJB, Remoting
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Wolf-Dieter Fink
>            Assignee: David Lloyd
>
> At the moment the application need to reference each outbound connection with a remote-ejb-receiver element in the jboss-ejb-client.xml.
> But from an application perspective it is not relevant whether the server environment provide one or many receivers or whether the ejb-receiver is a cluster.
> It should be possible to add many outbound-socket-binding-ref elements and related properties to the remote-outbound-connection element of the server configuration.
> In this case it is possible to keep the application deployment independent from the server environment.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 11:30:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 11:30:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1383) Disable pooling of stateless
 EJBs by default
In-Reply-To: <JIRA.12492528.1369290890000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12492528.1369290890000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12492528.1369290890000.26504.1383233402311@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFLY-1383:
------------------------------------

    Assignee: Cheng Fang  (was: Stuart Douglas)

    
> Disable pooling of stateless EJBs by default
> --------------------------------------------
>
>                 Key: WFLY-1383
>                 URL: https://issues.jboss.org/browse/WFLY-1383
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: jaikiran pai
>            Assignee: Cheng Fang
>
> A certain use case has shown that it's perhaps better to disable pooling of EJB stateless bean, by default. In AS7 we have always allowed disabling the pooling but we hadn't made it the default since we thought it might affect applications which have SLSBs with heavy @PostConstruct.
> A recent discussion has suggested that we disable the pooling by default and individual applications can enable it and set the relevant pool size themselves. The reasoning has been that, the default pool size that we ship with, anyway will have to be tweaked by the users since we can't really guess what an ideal pool size is. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 11:34:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 11:34:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-835) @Resource UserTransaction
 error when file passivation store is selected
In-Reply-To: <JIRA.12486327.1362495445000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12486327.1362495445000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12486327.1362495445000.26510.1383233642071@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFLY-835:
-----------------------------------

    Assignee: David Lloyd  (was: Stuart Douglas)


Assigning to David, as he has already looked into this. 

The simplest fix is probably to just inject a serializable proxy for UserTransaction rather than the UT itself. 
                
> @Resource UserTransaction error when file passivation store is selected
> -----------------------------------------------------------------------
>
>                 Key: WFLY-835
>                 URL: https://issues.jboss.org/browse/WFLY-835
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>         Environment: Ubuntu 11.10, Intel? Core? i3-2120 CPU @ 3.30GHz ? 4 
>            Reporter: Abraham Cabanillas Piera
>            Assignee: David Lloyd
>            Priority: Critical
>              Labels: jboss
>
> The following exception is launched when the server tries to passivate into the file passivation storage a stateful EJB session with UserTransaction injected as a resource:
> {noformat}
> [org.jboss.as.ejb3.cache.spi.impl.PassivateTask] (pool-10-thread-1) JBAS014538: Failed to passivate {[-36, 0, 14, -43, 72, 10, 76, -28, -105, -108, 24, 45, -70, -58, -48, -107]}: java.lang.RuntimeException: JBAS014538: Failed to passivate {[-36, 0, 14, -43, 72, 10, 76, -28, -105, -108, 24, 45, -70, -58, -48, -107]}
> 	at org.jboss.as.ejb3.cache.spi.impl.FilePersistentObjectStore.store(FilePersistentObjectStore.java:248) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	at org.jboss.as.ejb3.cache.spi.impl.FilePersistentObjectStore.store(FilePersistentObjectStore.java:52) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	at org.jboss.as.ejb3.cache.impl.backing.SimpleBackingCacheEntryStore.passivate(SimpleBackingCacheEntryStore.java:155) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberContainer.passivate(SerializationGroupMemberContainer.java:288) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberContainer.passivate(SerializationGroupMemberContainer.java:50) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	at org.jboss.as.ejb3.cache.impl.backing.PassivatingBackingCacheImpl.passivate(PassivatingBackingCacheImpl.java:190) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	at org.jboss.as.ejb3.cache.impl.backing.PassivatingBackingCacheImpl.passivate(PassivatingBackingCacheImpl.java:60) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	at org.jboss.as.ejb3.cache.spi.impl.PassivateTask.run(PassivateTask.java:45) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_13]
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_13]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_13]
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) [rt.jar:1.7.0_13]
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) [rt.jar:1.7.0_13]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_13]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_13]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_13]
> Caused by: java.io.NotSerializableException: org.jboss.tm.usertx.client.ServerVMClientUserTransaction
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:891)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> 	at org.jboss.marshalling.river.BlockMarshaller.doWriteObject(BlockMarshaller.java:69)
> 	at org.jboss.marshalling.river.BlockMarshaller.writeObject(BlockMarshaller.java:60)
> 	at org.jboss.marshalling.MarshallerObjectOutputStream.writeObjectOverride(MarshallerObjectOutputStream.java:54)
> 	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:342) [rt.jar:1.7.0_13]
> 	at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberImpl.writeObject(SerializationGroupMemberImpl.java:368) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_13]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_13]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_13]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_13]
> 	at org.jboss.marshalling.reflect.SerializableClass.callWriteObject(SerializableClass.java:175)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1007)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> 	at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62)
> 	at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119)
> 	at org.jboss.as.ejb3.cache.spi.impl.FilePersistentObjectStore.store(FilePersistentObjectStore.java:239) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	... 15 more
> Caused by: an exception which occurred:
> 	in field userTransaction
> 	in field instance
> 	in field instance
> 	in object org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberImpl at 6a4de0c9
> {noformat}
> The EJB subsystem configuration is:
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:ejb3:1.2">
>             <session-bean>
>                 <stateless>
>                     <bean-instance-pool-ref pool-name="slsb-strict-max-pool"/>
>                 </stateless>
>                 <stateful default-access-timeout="10000" cache-ref="passivating"/>
>                 <singleton default-access-timeout="5000"/>
>             </session-bean>
>             <mdb>
>                 <resource-adapter-ref resource-adapter-name="hornetq-ra"/>
>                 <bean-instance-pool-ref pool-name="mdb-strict-max-pool"/>
>             </mdb>
>             <pools>
>                 <bean-instance-pools>
>                     <strict-max-pool name="slsb-strict-max-pool" max-pool-size="50" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
>                     <strict-max-pool name="mdb-strict-max-pool" max-pool-size="20" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
>                 </bean-instance-pools>
>             </pools>
>             <caches>
>                 <cache name="simple" aliases="NoPassivationCache"/>
>                 <cache name="passivating" passivation-store-ref="file" aliases="SimpleStatefulCache"/>
>             </caches>
>             <passivation-stores>
>                 <file-passivation-store name="file" idle-timeout="10" idle-timeout-unit="SECONDS"/>
>             </passivation-stores>
>             <async thread-pool-name="default"/>
>             <timer-service thread-pool-name="default">
>                 <data-store path="timer-service-data" relative-to="jboss.server.data.dir"/>
>             </timer-service>
>             <remote connector-ref="remoting-connector" thread-pool-name="default"/>
>             <thread-pools>
>                 <thread-pool name="default">
>                     <max-threads count="100"/>
>                     <keepalive-time time="100" unit="milliseconds"/>
>                 </thread-pool>
>             </thread-pools>
>             <iiop enable-by-default="false" use-qualified-name="false"/>
>         </subsystem>
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Thu Oct 31 11:41:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 11:41:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1928) jboss-as-standalone.sh does
 not work on MacOS
In-Reply-To: <JIRA.12499212.1377185444000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499212.1377185444000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499212.1377185444000.26524.1383234062106@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas updated WFLY-1928:
---------------------------------

    Fix Version/s: Awaiting Volunteers
                       (was: 8.0.0.CR1)
         Assignee:     (was: Stuart Douglas)

    
> jboss-as-standalone.sh does not work on MacOS
> ---------------------------------------------
>
>                 Key: WFLY-1928
>                 URL: https://issues.jboss.org/browse/WFLY-1928
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Scripts
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Thomas Diesler
>             Fix For: Awaiting Volunteers
>
>
> {code}
> FuseFabric:karaf at root> process-start root 3
> bin/init.d/jboss-as-standalone.sh: line 12: /etc/init.d/functions: No such file or directory
> Error executing command: [bin/init.d/jboss-as-standalone.sh, start] exited with 1
> bin/init.d/jboss-as-standalone.sh: line 12: /etc/init.d/functions: No such file or directory
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 11:41:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 11:41:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1805) It should be possible to pass
 objects via invocation context from the server side EJB to the client and
 read with a via client side interceptor
In-Reply-To: <JIRA.12497139.1374586120000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497139.1374586120000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497139.1374586120000.26533.1383234062522@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFLY-1805:
------------------------------------

    Assignee: David Lloyd  (was: Stuart Douglas)

    
> It should be possible to pass objects via invocation context from the server side EJB to the client and read with a via client side interceptor
> -----------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1805
>                 URL: https://issues.jboss.org/browse/WFLY-1805
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>            Reporter: Wolf-Dieter Fink
>            Assignee: David Lloyd
>              Labels: ejb
>
> With former JBoss versions it was possible to pass context beside the method invocation from the client to the server and back. This was done via (AOP) interceptors.
> Since AS7 and WildFly the only possibility is to pass such context from the client to the server.
> It should also possible to pass serializeable objects from the server side to the client if the invocation returns and have a client side interceptor to read that informations.
> This was used to return i.e. tracking or additional usefull informations.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 11:51:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 11:51:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1716) NoClassDefFoundError:
 org/jboss/el/cache/FactoryFinderCache deploying ear with war inside
In-Reply-To: <JIRA.12496755.1374137088000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496755.1374137088000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496755.1374137088000.26559.1383234662074@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-1716.
----------------------------------

    Resolution: Out of Date

    
> NoClassDefFoundError: org/jboss/el/cache/FactoryFinderCache deploying ear with war inside
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-1716
>                 URL: https://issues.jboss.org/browse/WFLY-1716
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EE
>    Affects Versions: 8.0.0.Alpha3
>         Environment: Win 7, JEE 6, JDK 7
>            Reporter: Oliver Pfau
>            Assignee: Stuart Douglas
>              Labels: Deploy, classnotfound, war
>
> I tried to deploy my ear which works in JBoss 7 in wildfly and got the following error on deploy:
> 09:59:55,060 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.subunit."my.ear"."mywar.war".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."my.ear"."mywar.war".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of subdeployment "mywar.war" of deployment "my.ear"
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Alpha3.jar:8.0.0.Alpha3]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: java.lang.NoClassDefFoundError: org/jboss/el/cache/FactoryFinderCache
> 	at org.wildfly.extension.undertow.deployment.ELExpressionFactoryProcessor.deploy(ELExpressionFactoryProcessor.java:78)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Alpha3.jar:8.0.0.Alpha3]
> 	... 5 more
> 09:59:55,100 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "my.ear")]) - failure description: {
>     "JBAS014671: Failed services" => {"jboss.deployment.subunit.\"my.ear\".\"mywar.war\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.subunit.\"my.ear\".\"mywar.war\".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of subdeployment \"mywar.war\" of deployment \"my.ear\"
>     Caused by: java.lang.NoClassDefFoundError: org/jboss/el/cache/FactoryFinderCache"},
>     "JBAS014771: Services with missing/unavailable dependencies" => [
>         "jboss.naming.context.java.comp.my-service-ejb-x-SNAPSHOT.MyServiceName.ValidatorFactory is missing [jboss.naming.context.java.comp.my-service-ejb-x-SNAPSHOT.MyServiceName]",
>         "jboss.naming.context.java.comp.my-service-ejb-x-SNAPSHOT.MyServiceName.InstanceName is missing [jboss.naming.context.java.comp.my-service-ejb-x-SNAPSHOT.MyServiceName]",
>         "jboss.naming.context.java.comp.my-service-ejb-x-SNAPSHOT.MyServiceName.Validator is missing [jboss.naming.context.java.comp.my-service-ejb-x-SNAPSHOT.MyServiceName]",
>         
> 		<all other services>
>     ]
> }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 11:51:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 11:51:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1565) Test failure observed in
 EJBClientClusterConfigurationTestCase
In-Reply-To: <JIRA.12494793.1371750050000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494793.1371750050000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494793.1371750050000.26569.1383234662556@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFLY-1565:
------------------------------------

    Assignee: David Lloyd  (was: Stuart Douglas)

    
> Test failure observed in EJBClientClusterConfigurationTestCase
> --------------------------------------------------------------
>
>                 Key: WFLY-1565
>                 URL: https://issues.jboss.org/browse/WFLY-1565
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>         Environment: Operating system:  Windows Server 2008 R2, version 6.1
> 3072 MB RAM
> 1 x 1842MHz CPU
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>
> The failed test was {{EJBClientClusterConfigurationTestCase.testServerToServerClusterFormation}} with this log:
> {noformat}
> javax.ejb.EJBException: java.lang.IllegalStateException: EJBCLIENT000028: No EJB receiver contexts available in cluster ejb
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:190)
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340)
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:90)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:55)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:305)
>     at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:428)
>     at org.wildfly.security.manager.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:63)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:305)
>     at java.security.AccessController.doPrivileged(Native Method)
>     at org.jboss.invocation.PrivilegedInterceptor.processInvocation(PrivilegedInterceptor.java:65)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>     at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
>     at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:329)
>     at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:70)
>     at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:203)
>     at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
>     at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
>     at java.util.concurrent.FutureTask.run(FutureTask.java:166)
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>     at java.lang.Thread.run(Thread.java:722)
>     at org.jboss.threads.JBossThread.run(JBossThread.java:122)
>     at ...asynchronous invocation...(Unknown Source)
>     at org.jboss.ejb.client.remoting.InvocationExceptionResponseHandler$MethodInvocationExceptionResultProducer.getResult(InvocationExceptionResponseHandler.java:99)
>     at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:272)
>     at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocationResult(EJBObjectInterceptor.java:64)
>     at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:274)
>     at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocationResult(EJBHomeInterceptor.java:88)
>     at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:274)
>     at org.jboss.ejb.client.TransactionInterceptor.handleInvocationResult(TransactionInterceptor.java:46)
>     at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:274)
>     at org.jboss.ejb.client.ReceiverInterceptor.handleInvocationResult(ReceiverInterceptor.java:129)
>     at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:262)
>     at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:437)
>     at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:202)
>     at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181)
>     at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144)
>     at sun.proxy.$Proxy21.getNodeName(Unknown Source)
>     at org.jboss.as.test.manualmode.ejb.client.cluster.EJBClientClusterConfigurationTestCase.testServerToServerClusterFormation(EJBClientClusterConfigurationTestCase.java:160)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(Method.java:601)
>     at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>     at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>     at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>     at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:270)
>     at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(Method.java:601)
>     at org.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.execution.ClientTestExecuter.execute(ClientTestExecuter.java:53)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(Method.java:601)
>     at org.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.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
>     at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(Method.java:601)
>     at org.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.createTestContext(TestContextHandler.java:89)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(Method.java:601)
>     at org.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.createClassContext(TestContextHandler.java:75)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(Method.java:601)
>     at org.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:60)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(Method.java:601)
>     at org.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.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111)
>     at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263)
>     at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226)
>     at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
>     at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
>     at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240)
>     at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>     at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>     at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>     at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>     at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>     at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>     at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>     at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>     at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185)
>     at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
>     at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
>     at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
>     at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>     at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
>     at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234)
>     at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133)
>     at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(Method.java:601)
>     at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188)
>     at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166)
>     at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
>     at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101)
>     at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
> Caused by: java.lang.IllegalStateException: EJBCLIENT000028: No EJB receiver contexts available in cluster ejb
>     at org.jboss.ejb.client.EJBClientContext.requireClusterEJBReceiverContext(EJBClientContext.java:983)
>     at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:84)
>     at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183)
>     at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:253)
>     at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:198)
>     at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181)
>     at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144)
>     at sun.proxy.$Proxy30.getNodeName(Unknown Source)
>     at org.jboss.as.test.manualmode.ejb.client.cluster.NonClusteredStatefulNodeNameEcho.getNodeName(NonClusteredStatefulNodeNameEcho.java:47)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(Method.java:601)
>     at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>     at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>     at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:58)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:156)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>     at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:66)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:273)
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340)
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:90)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:55)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:305)
>     at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:428)
>     at org.wildfly.security.manager.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:63)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:305)
>     at java.security.AccessController.doPrivileged(Native Method)
>     at org.jboss.invocation.PrivilegedInterceptor.processInvocation(PrivilegedInterceptor.java:65)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>     at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
>     at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:329)
>     at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:70)
>     at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:203)
>     at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
>     at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
>     at java.util.concurrent.FutureTask.run(FutureTask.java:166)
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>     at java.lang.Thread.run(Thread.java:722)
>     at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> ------- Stdout: -------
> 17:47:04,420 INFO  [org.xnio] (main) XNIO Version 3.1.0.CR3
> 17:47:04,428 INFO  [org.xnio.nio] (main) XNIO NIO Implementation Version 3.1.0.CR3
> 17:47:05,105 INFO  [org.jboss.remoting] (main) JBoss Remoting version 4.0.0.Beta1
> 17:47:10,668 WARN  [org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector] (main) Could not register a EJB receiver for connection to 127.0.0.1:4447: java.lang.RuntimeException: Operation failed with status WAITING
>     at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:93)
>     at org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:75)
>     at org.jboss.ejb.client.remoting.RemotingConnectionManager.getConnection(RemotingConnectionManager.java:51)
>     at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.setupEJBReceivers(ConfigBasedEJBClientContextSelector.java:130)
>     at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.<init>(ConfigBasedEJBClientContextSelector.java:100)
>     at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.<init>(ConfigBasedEJBClientContextSelector.java:68)
>     at org.jboss.ejb.client.EJBClientContext.<clinit>(EJBClientContext.java:81)
>     at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.<init>(ConfigBasedEJBClientContextSelector.java:85)
>     at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.<init>(ConfigBasedEJBClientContextSelector.java:68)
>     at org.jboss.as.test.manualmode.ejb.client.cluster.EJBClientClusterConfigurationTestCase.setupEJBClientContextSelector(EJBClientClusterConfigurationTestCase.java:197)
>     at org.jboss.as.test.manualmode.ejb.client.cluster.EJBClientClusterConfigurationTestCase.beforeClass(EJBClientClusterConfigurationTestCase.java:95)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(Method.java:601)
>     at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>     at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>     at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>     at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
>     at org.jboss.arquillian.junit.Arquillian$StatementLifecycleExecutor.invoke(Arquillian.java:351)
>     at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.execute(ClientBeforeAfterLifecycleEventExecuter.java:99)
>     at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.on(ClientBeforeAfterLifecycleEventExecuter.java:60)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(Method.java:601)
>     at org.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:75)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(Method.java:601)
>     at org.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:60)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(Method.java:601)
>     at org.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:234)
>     at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133)
>     at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(Method.java:601)
>     at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188)
>     at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166)
>     at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
>     at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101)
>     at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
> 17:47:15,866 WARN  [org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector] (main) Could not register a EJB receiver for connection to 127.0.0.1:4547: java.lang.RuntimeException: Operation failed with status WAITING
>     at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:93)
>     at org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:75)
>     at org.jboss.ejb.client.remoting.RemotingConnectionManager.getConnection(RemotingConnectionManager.java:51)
>     at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.setupEJBReceivers(ConfigBasedEJBClientContextSelector.java:130)
>     at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.<init>(ConfigBasedEJBClientContextSelector.java:100)
>     at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.<init>(ConfigBasedEJBClientContextSelector.java:68)
>     at org.jboss.as.test.manualmode.ejb.client.cluster.EJBClientClusterConfigurationTestCase.setupEJBClientContextSelector(EJBClientClusterConfigurationTestCase.java:197)
>     at org.jboss.as.test.manualmode.ejb.client.cluster.EJBClientClusterConfigurationTestCase.beforeClass(EJBClientClusterConfigurationTestCase.java:95)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(Method.java:601)
>     at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>     at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>     at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>     at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
>     at org.jboss.arquillian.junit.Arquillian$StatementLifecycleExecutor.invoke(Arquillian.java:351)
>     at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.execute(ClientBeforeAfterLifecycleEventExecuter.java:99)
>     at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.on(ClientBeforeAfterLifecycleEventExecuter.java:60)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(Method.java:601)
>     at org.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:75)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(Method.java:601)
>     at org.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:60)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(Method.java:601)
>     at org.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:234)
>     at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133)
>     at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(Method.java:601)
>     at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188)
>     at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166)
>     at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
>     at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101)
>     at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
> 17:47:16,285 INFO  [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual starting of a server instance
> 17:47:17,499 INFO  [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Starting container with: [C:\workspace\Java\jdk1.7.0_13\bin\java, -Xmx512m, -XX:MaxPermSize=256m, -Djboss.dist=C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode/../../../build/target/wildfly-8.0.0.Alpha2-SNAPSHOT, -Djava.net.preferIPv4Stack=true, -Djava.net.preferIPv6Addresses=false, -server, -Dts.timeout.factor=100, -Dnode0=127.0.0.1, -Dnode1=127.0.0.1, -Dmcast=230.0.0.4, -Djbossas.ts.submodule.dir=C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode, -Djbossas.ts.integ.dir=C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode/.., -Djbossas.ts.dir=C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode/../.., -Djbossas.project.dir=C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode/../../.., -Djboss.dist=C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode/../../../build/target/wildfly-8.0.0.Alpha2-SNAPSHOT, -Djboss.inst=C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode/target/jbossas, -Djboss.node.name=default-jbossas, -ea, -Djboss.home.dir=C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode/target/jbossas, -Dorg.jboss.boot.log.file=C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode\target\jbossas\standalone\log\boot.log, -Dlogging.configuration=file:/C:/BuildAgent/work/1943cb9aa6e69362/testsuite/integration/manualmode/target/jbossas/standalone/configuration/logging.properties, -Djboss.bundles.dir=C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode/../../../build/target/wildfly-8.0.0.Alpha2-SNAPSHOT/bundles, -jar, C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode\target\jbossas\jboss-modules.jar, -mp, C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode/../../../build/target/wildfly-8.0.0.Alpha2-SNAPSHOT/modules;C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode/target/modules, org.jboss.as.standalone, -server-config, standalone-ha.xml]
> 17:47:18,354 INFO  [org.jboss.modules] (main) JBoss Modules version 1.2.2.Final
> 17:47:19,196 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.0.Beta1
> 17:47:19,281 INFO  [org.jboss.as] (MSC service thread 1-2) JBAS015899: WildFly 8.0.0.Alpha2-SNAPSHOT "WildFly" starting
> 17:47:23,556 INFO  [org.jboss.as.server] (Controller Boot Thread) JBAS015888: Creating http management service using socket-binding (management-http)
> 17:47:24,017 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 52) JBAS015537: Activating WebServices Extension
> 17:47:24,023 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 51) JBAS017502: Undertow 1.0.0.Alpha20 starting
> 17:47:24,170 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 48) JBAS013171: Activating Security Subsystem
> 17:47:24,195 INFO  [org.xnio] (MSC service thread 1-1) XNIO Version 3.1.0.CR3
> 17:47:24,215 INFO  [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.1.0.CR3
> 17:47:24,240 INFO  [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 4.0.0.Beta1
> 17:47:24,257 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 43) JBAS011800: Activating Naming Subsystem
> 17:47:24,878 INFO  [org.jboss.as.jsf] (ServerService Thread Pool -- 40) JBAS012605: Activated the following JSF Implementations: [main]
> 17:47:24,973 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 37) JBAS010260: Activating JGroups subsystem.
> 17:47:25,012 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 33) JBAS010280: Activating Infinispan subsystem.
> 17:47:25,302 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 51) JBAS017527: Creating file handler for path C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode\target\jbossas/welcome-content
> 17:47:27,063 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 28) JBAS010403: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 17:47:27,623 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 33) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> 17:47:27,629 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 33) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> 17:47:28,617 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017502: Undertow 1.0.0.Alpha20 starting
> 17:47:28,633 INFO  [org.jboss.as.security] (MSC service thread 1-2) JBAS013170: Current PicketBox version=4.0.17.Final
> 17:47:28,643 INFO  [org.jboss.as.naming] (MSC service thread 1-2) JBAS011802: Starting Naming Service
> 17:47:28,650 INFO  [org.jboss.as.connector.logging] (MSC service thread 1-2) JBAS010408: Starting JCA Subsystem (IronJacamar 1.0.17.Final)
> 17:47:28,688 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017525: Started http handler io.undertow.server.handlers.resource.ResourceHandler at 10e6e5f.
> 17:47:29,263 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) JBAS010417: Started Driver service with driver-name = h2
> 17:47:29,296 INFO  [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBoss Web Services - Stack CXF Server 4.2.0.CR1
> 17:47:29,310 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-2) JBAS015012: Started FileSystemDeploymentService for directory C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode\target\jbossas\standalone\deployments
> 17:47:29,310 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-2) JBAS015400: Bound mail session [java:jboss/mail/Default]
> 17:47:29,311 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) Starting server server service: service jboss.undertow.server.default-server
> 17:47:29,314 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) Starting host default-host
> 17:47:29,319 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017528: registering handler io.undertow.server.handlers.resource.ResourceHandler at 10e6e5f under path '/'
> 17:47:29,378 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) JBAS017519: Undertow HTTP listener default listening on /127.0.0.1:8080
> 17:47:29,599 INFO  [org.jboss.as.remoting] (MSC service thread 1-2) JBAS017100: Listening on 127.0.0.1:9999
> 17:47:29,637 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017519: Undertow AJP listener ajp-connector listening on /127.0.0.1:8009
> 17:47:29,654 INFO  [org.jboss.as.remoting] (MSC service thread 1-1) JBAS017100: Listening on 127.0.0.1:4447
> 17:47:30,243 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
> 17:47:30,249 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("add") failed - address: ([("subsystem" => "modcluster")]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.mod-cluster is missing [jboss.web.connector.ajp, jboss.web]"]}
> 17:47:30,369 INFO  [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.web (missing) dependents: [service jboss.mod-cluster] 
>       service jboss.web.connector.ajp (missing) dependents: [service jboss.mod-cluster] 
> 17:47:30,432 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:9990/management
> 17:47:30,439 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990
> 17:47:30,440 ERROR [org.jboss.as] (Controller Boot Thread) JBAS015875: WildFly 8.0.0.Alpha2-SNAPSHOT "WildFly" started (with errors) in 12756ms - Started 156 of 250 services (1 services failed or missing dependencies, 115 services are lazy, passive or on-demand)
> 17:47:32,577 INFO  [org.jboss.as.repository] (management-handler-thread - 2) JBAS014900: Content added at location C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode\target\jbossas\standalone\data\content\57\ef1f6cb625fb992628a0511dee1d1967e804f0\content
> 17:47:32,592 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015876: Starting deployment of "server-to-server-clustered-ejb-invocation.jar" (runtime-name: "server-to-server-clustered-ejb-invocation.jar")
> 17:47:33,035 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-1) JNDI bindings for session bean named ClusteredStatefulNodeNameEcho in deployment unit deployment "server-to-server-clustered-ejb-invocation.jar" are as follows:
>     java:global/server-to-server-clustered-ejb-invocation/ClusteredStatefulNodeNameEcho!org.jboss.as.test.manualmode.ejb.client.cluster.NodeNameEcho
>     java:app/server-to-server-clustered-ejb-invocation/ClusteredStatefulNodeNameEcho!org.jboss.as.test.manualmode.ejb.client.cluster.NodeNameEcho
>     java:module/ClusteredStatefulNodeNameEcho!org.jboss.as.test.manualmode.ejb.client.cluster.NodeNameEcho
>     java:jboss/exported/server-to-server-clustered-ejb-invocation/ClusteredStatefulNodeNameEcho!org.jboss.as.test.manualmode.ejb.client.cluster.NodeNameEcho
>     java:global/server-to-server-clustered-ejb-invocation/ClusteredStatefulNodeNameEcho
>     java:app/server-to-server-clustered-ejb-invocation/ClusteredStatefulNodeNameEcho
>     java:module/ClusteredStatefulNodeNameEcho
> 17:47:35,597 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 3) ISPN000078: Starting JGroups Channel
> 17:47:35,612 INFO  [stdout] (ServerService Thread Pool -- 3) 
> 17:47:35,612 INFO  [stdout] (ServerService Thread Pool -- 3) -------------------------------------------------------------------
> 17:47:35,612 INFO  [stdout] (ServerService Thread Pool -- 3) GMS: address=default-jbossas/ejb, cluster=ejb, physical address=127.0.0.1:55200
> 17:47:35,613 INFO  [stdout] (ServerService Thread Pool -- 3) -------------------------------------------------------------------
> 17:47:37,637 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 3) ISPN000094: Received new cluster view: [default-jbossas/ejb|0] [default-jbossas/ejb]
> 17:47:37,798 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 3) ISPN000079: Cache local address is default-jbossas/ejb, physical addresses are [127.0.0.1:55200]
> 17:47:37,805 INFO  [org.infinispan.factories.GlobalComponentRegistry] (ServerService Thread Pool -- 3) ISPN000128: Infinispan version: Infinispan 'Tactical Nuclear Penguin' 5.3.0.CR1
> 17:47:37,835 INFO  [org.infinispan.factories.TransactionManagerFactory] (ServerService Thread Pool -- 2) ISPN000161: Using a batchMode transaction manager
> 17:47:38,053 INFO  [org.infinispan.jmx.CacheJmxRegistration] (ServerService Thread Pool -- 2) ISPN000031: MBeans were successfully registered to the platform MBean server.
> 17:47:38,062 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 2) JBAS010281: Started remote-connector-client-mappings cache from ejb container
> 17:47:38,087 INFO  [org.infinispan.factories.TransactionManagerFactory] (ServerService Thread Pool -- 3) ISPN000161: Using a batchMode transaction manager
> 17:47:38,340 INFO  [org.infinispan.jmx.CacheJmxRegistration] (ServerService Thread Pool -- 3) ISPN000031: MBeans were successfully registered to the platform MBean server.
> 17:47:38,342 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 3) JBAS010281: Started repl cache from ejb container
> 17:47:38,350 INFO  [org.jboss.as.clustering] (MSC service thread 1-2) JBAS010238: Number of cluster members: 1
> 17:47:38,378 INFO  [org.infinispan.factories.TransactionManagerFactory] (MSC service thread 1-2) ISPN000161: Using a batchMode transaction manager
> 17:47:38,390 INFO  [org.infinispan.jmx.CacheJmxRegistration] (MSC service thread 1-2) ISPN000031: MBeans were successfully registered to the platform MBean server.
> 17:47:38,392 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-2) JBAS010281: Started org.jboss.as.test.manualmode.ejb.client.cluster.ClusteredStatefulNodeNameEcho cache from ejb container
> 17:47:38,459 INFO  [org.jboss.as.server] (management-handler-thread - 2) JBAS018559: Deployed "server-to-server-clustered-ejb-invocation.jar" (runtime-name : "server-to-server-clustered-ejb-invocation.jar")
> 17:47:40,405 INFO  [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual starting of a server instance
> 17:47:41,533 INFO  [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Starting container with: [C:\workspace\Java\jdk1.7.0_13\bin\java, -Xmx512m, -XX:MaxPermSize=256m, -Djboss.dist=C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode/../../../build/target/wildfly-8.0.0.Alpha2-SNAPSHOT, -Djava.net.preferIPv4Stack=true, -Djava.net.preferIPv6Addresses=false, -server, -Dts.timeout.factor=100, -Dnode0=127.0.0.1, -Dnode1=127.0.0.1, -Dmcast=230.0.0.4, -Djbossas.ts.submodule.dir=C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode, -Djbossas.ts.integ.dir=C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode/.., -Djbossas.ts.dir=C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode/../.., -Djbossas.project.dir=C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode/../../.., -Djboss.dist=C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode/../../../build/target/wildfly-8.0.0.Alpha2-SNAPSHOT, -Djboss.inst=C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode/target/jbossas-with-remote-outbound-connection, -Djboss.node.name=jbossas-with-remote-outbound-connection, -ea, -Djboss.home.dir=C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode/target/jbossas-with-remote-outbound-connection, -Dorg.jboss.boot.log.file=C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode\target\jbossas-with-remote-outbound-connection\standalone\log\boot.log, -Dlogging.configuration=file:/C:/BuildAgent/work/1943cb9aa6e69362/testsuite/integration/manualmode/target/jbossas-with-remote-outbound-connection/standalone/configuration/logging.properties, -Djboss.bundles.dir=C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode/../../../build/target/wildfly-8.0.0.Alpha2-SNAPSHOT/bundles, -jar, C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode\target\jbossas-with-remote-outbound-connection\jboss-modules.jar, -mp, C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode/../../../build/target/wildfly-8.0.0.Alpha2-SNAPSHOT/modules;C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode/target/modules, org.jboss.as.standalone, -server-config, standalone-ha.xml]
> 17:47:42,791 INFO  [org.jboss.modules] (main) JBoss Modules version 1.2.2.Final
> 17:47:44,437 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.0.Beta1
> 17:47:44,582 INFO  [org.jboss.as] (MSC service thread 1-2) JBAS015899: WildFly 8.0.0.Alpha2-SNAPSHOT "WildFly" starting
> 17:47:50,729 INFO  [org.jboss.as.server] (Controller Boot Thread) JBAS015888: Creating http management service using socket-binding (management-http)
> 17:47:50,803 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 2) JBAS010403: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
> 17:47:51,246 INFO  [org.xnio] (MSC service thread 1-2) XNIO Version 3.1.0.CR3
> 17:47:51,261 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 52) JBAS015537: Activating WebServices Extension
> 17:47:51,277 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 51) JBAS017502: Undertow 1.0.0.Alpha20 starting
> 17:47:51,309 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 48) JBAS013171: Activating Security Subsystem
> 17:47:51,380 INFO  [org.xnio.nio] (MSC service thread 1-2) XNIO NIO Implementation Version 3.1.0.CR3
> 17:47:51,389 INFO  [org.jboss.remoting] (MSC service thread 1-2) JBoss Remoting version 4.0.0.Beta1
> 17:47:51,484 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 43) JBAS011800: Activating Naming Subsystem
> 17:47:51,516 INFO  [org.jboss.as.jsf] (ServerService Thread Pool -- 40) JBAS012605: Activated the following JSF Implementations: [main]
> 17:47:51,560 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 51) JBAS017527: Creating file handler for path C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode\target\jbossas-with-remote-outbound-connection/welcome-content
> 17:47:52,492 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 33) JBAS010280: Activating Infinispan subsystem.
> 17:47:52,944 INFO  [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 37) JBAS010260: Activating JGroups subsystem.
> 17:47:54,723 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 33) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> 17:47:54,733 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 33) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> 17:47:55,833 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) JBAS017502: Undertow 1.0.0.Alpha20 starting
> 17:47:55,919 INFO  [org.jboss.as.connector.logging] (MSC service thread 1-1) JBAS010408: Starting JCA Subsystem (IronJacamar 1.0.17.Final)
> 17:47:56,306 INFO  [org.jboss.as.naming] (MSC service thread 1-1) JBAS011802: Starting Naming Service
> 17:47:56,307 INFO  [org.jboss.as.security] (MSC service thread 1-1) JBAS013170: Current PicketBox version=4.0.17.Final
> 17:47:56,315 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) JBAS017525: Started http handler io.undertow.server.handlers.resource.ResourceHandler at 1f3bc38.
> 17:47:56,325 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) Starting server server service: service jboss.undertow.server.default-server
> 17:47:56,355 INFO  [org.jboss.ws.common.management] (MSC service thread 1-1) JBWS022052: Starting JBoss Web Services - Stack CXF Server 4.2.0.CR1
> 17:47:56,357 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) JBAS010417: Started Driver service with driver-name = h2
> 17:47:56,569 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-1) JBAS015012: Started FileSystemDeploymentService for directory C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode\target\jbossas-with-remote-outbound-connection\standalone\deployments
> 17:47:56,570 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-1) JBAS015400: Bound mail session [java:jboss/mail/Default]
> 17:47:56,571 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) Starting host default-host
> 17:47:56,573 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) JBAS017528: registering handler io.undertow.server.handlers.resource.ResourceHandler at 1f3bc38 under path '/'
> 17:47:56,594 INFO  [org.jboss.as.remoting] (MSC service thread 1-2) JBAS017100: Listening on 127.0.0.1:10099
> 17:47:56,610 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017519: Undertow HTTP listener default listening on /127.0.0.1:8180
> 17:47:56,612 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017519: Undertow AJP listener ajp-connector listening on /127.0.0.1:8109
> 17:47:56,612 INFO  [org.jboss.as.remoting] (MSC service thread 1-2) JBAS017100: Listening on 127.0.0.1:4547
> 17:47:57,479 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
> 17:47:57,484 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("add") failed - address: ([("subsystem" => "modcluster")]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.mod-cluster is missing [jboss.web.connector.ajp, jboss.web]"]}
> 17:47:57,529 INFO  [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.web (missing) dependents: [service jboss.mod-cluster] 
>       service jboss.web.connector.ajp (missing) dependents: [service jboss.mod-cluster] 
> 17:47:57,599 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:10090/management
> 17:47:57,599 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:10090
> 17:47:57,600 ERROR [org.jboss.as] (Controller Boot Thread) JBAS015875: WildFly 8.0.0.Alpha2-SNAPSHOT "WildFly" started (with errors) in 15948ms - Started 160 of 254 services (1 services failed or missing dependencies, 117 services are lazy, passive or on-demand)
> 17:48:01,241 INFO  [org.jboss.as.repository] (management-handler-thread - 2) JBAS014900: Content added at location C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode\target\jbossas-with-remote-outbound-connection\standalone\data\content\e0\8b25b6eed5c6f2df04ba76fd92ab3c469cfc0d\content
> 17:48:01,459 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015876: Starting deployment of "server-to-server-clustered-ejb-invocation.jar" (runtime-name: "server-to-server-clustered-ejb-invocation.jar")
> 17:48:01,693 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-2) JNDI bindings for session bean named ClusteredStatefulNodeNameEcho in deployment unit deployment "server-to-server-clustered-ejb-invocation.jar" are as follows:
>     java:global/server-to-server-clustered-ejb-invocation/ClusteredStatefulNodeNameEcho!org.jboss.as.test.manualmode.ejb.client.cluster.NodeNameEcho
>     java:app/server-to-server-clustered-ejb-invocation/ClusteredStatefulNodeNameEcho!org.jboss.as.test.manualmode.ejb.client.cluster.NodeNameEcho
>     java:module/ClusteredStatefulNodeNameEcho!org.jboss.as.test.manualmode.ejb.client.cluster.NodeNameEcho
>     java:jboss/exported/server-to-server-clustered-ejb-invocation/ClusteredStatefulNodeNameEcho!org.jboss.as.test.manualmode.ejb.client.cluster.NodeNameEcho
>     java:global/server-to-server-clustered-ejb-invocation/ClusteredStatefulNodeNameEcho
>     java:app/server-to-server-clustered-ejb-invocation/ClusteredStatefulNodeNameEcho
>     java:module/ClusteredStatefulNodeNameEcho
> 17:48:01,694 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-2) JNDI bindings for session bean named NonClusteredStatefulNodeNameEcho in deployment unit deployment "server-to-server-clustered-ejb-invocation.jar" are as follows:
>     java:global/server-to-server-clustered-ejb-invocation/NonClusteredStatefulNodeNameEcho!org.jboss.as.test.manualmode.ejb.client.cluster.NodeNameEcho
>     java:app/server-to-server-clustered-ejb-invocation/NonClusteredStatefulNodeNameEcho!org.jboss.as.test.manualmode.ejb.client.cluster.NodeNameEcho
>     java:module/NonClusteredStatefulNodeNameEcho!org.jboss.as.test.manualmode.ejb.client.cluster.NodeNameEcho
>     java:jboss/exported/server-to-server-clustered-ejb-invocation/NonClusteredStatefulNodeNameEcho!org.jboss.as.test.manualmode.ejb.client.cluster.NodeNameEcho
>     java:global/server-to-server-clustered-ejb-invocation/NonClusteredStatefulNodeNameEcho
>     java:app/server-to-server-clustered-ejb-invocation/NonClusteredStatefulNodeNameEcho
>     java:module/NonClusteredStatefulNodeNameEcho
> 17:48:02,356 INFO  [org.jboss.ejb.client.remoting] (Remoting "jbossas-with-remote-outbound-connection" task-6) EJBCLIENT000017: Received server version 2 and marshalling strategies [river]
> 17:48:02,368 INFO  [org.jboss.ejb.client.remoting] (MSC service thread 1-2) EJBCLIENT000013: Successful version handshake completed for receiver context EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext at 150eaef, receiver=Remoting connection EJB receiver [connection=Remoting connection <5b49a4>,channel=jboss.ejb,nodename=default-jbossas]} on channel Channel ID 8785ee03 (outbound) of Remoting connection 00a2e892 to 127.0.0.1/127.0.0.1:4447
> 17:48:04,511 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 12) ISPN000078: Starting JGroups Channel
> 17:48:04,525 INFO  [stdout] (ServerService Thread Pool -- 12) 
> 17:48:04,525 INFO  [stdout] (ServerService Thread Pool -- 12) -------------------------------------------------------------------
> 17:48:04,526 INFO  [stdout] (ServerService Thread Pool -- 12) GMS: address=jbossas-with-remote-outbound-connection/ejb, cluster=ejb, physical address=127.0.0.1:55300
> 17:48:04,526 INFO  [stdout] (ServerService Thread Pool -- 12) -------------------------------------------------------------------
> 17:48:05,038 INFO  [org.jboss.as.clustering] (Incoming-1,shared=udp) JBAS010225: New cluster view for partition ejb (id: 1, delta: 1, merge: false) : [default-jbossas/ejb, jbossas-with-remote-outbound-connection/ejb]
> 17:48:05,039 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-1,shared=udp) ISPN000094: Received new cluster view: [default-jbossas/ejb|1] [default-jbossas/ejb, jbossas-with-remote-outbound-connection/ejb]
> 17:48:05,052 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 12) ISPN000094: Received new cluster view: [default-jbossas/ejb|1] [default-jbossas/ejb, jbossas-with-remote-outbound-connection/ejb]
> 17:48:05,307 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 12) ISPN000079: Cache local address is jbossas-with-remote-outbound-connection/ejb, physical addresses are [127.0.0.1:55300]
> 17:48:05,311 INFO  [org.infinispan.factories.GlobalComponentRegistry] (ServerService Thread Pool -- 12) ISPN000128: Infinispan version: Infinispan 'Tactical Nuclear Penguin' 5.3.0.CR1
> 17:48:05,339 INFO  [org.infinispan.factories.TransactionManagerFactory] (ServerService Thread Pool -- 12) ISPN000161: Using a batchMode transaction manager
> 17:48:05,464 INFO  [org.infinispan.factories.TransactionManagerFactory] (ServerService Thread Pool -- 9) ISPN000161: Using a batchMode transaction manager
> 17:48:06,047 INFO  [org.infinispan.jmx.CacheJmxRegistration] (ServerService Thread Pool -- 12) ISPN000031: MBeans were successfully registered to the platform MBean server.
> 17:48:06,626 INFO  [org.infinispan.jmx.CacheJmxRegistration] (ServerService Thread Pool -- 9) ISPN000031: MBeans were successfully registered to the platform MBean server.
> 17:48:06,905 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 12) JBAS010281: Started remote-connector-client-mappings cache from ejb container
> 17:48:06,929 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 9) JBAS010281: Started repl cache from ejb container
> 17:48:06,937 INFO  [org.jboss.as.clustering] (MSC service thread 1-1) JBAS010238: Number of cluster members: 2
> 17:48:07,020 INFO  [org.infinispan.factories.TransactionManagerFactory] (MSC service thread 1-1) ISPN000161: Using a batchMode transaction manager
> 17:48:07,031 INFO  [org.infinispan.jmx.CacheJmxRegistration] (MSC service thread 1-1) ISPN000031: MBeans were successfully registered to the platform MBean server.
> 17:48:07,516 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-1) JBAS010281: Started org.jboss.as.test.manualmode.ejb.client.cluster.ClusteredStatefulNodeNameEcho cache from ejb container
> 17:48:07,638 INFO  [org.jboss.as.server] (management-handler-thread - 2) JBAS018559: Deployed "server-to-server-clustered-ejb-invocation.jar" (runtime-name : "server-to-server-clustered-ejb-invocation.jar")
> 17:48:09,577 INFO  [org.jboss.ejb.client] (main) JBoss EJB Client version 1.0.21.Final
> 17:48:09,606 INFO  [org.jboss.ejb.client.remoting] (Remoting "config-based-ejb-client-endpoint" task-5) EJBCLIENT000017: Received server version 2 and marshalling strategies [river]
> 17:48:09,657 INFO  [org.jboss.ejb.client.remoting] (ejb-client-context-tasks-2-thread-1) EJBCLIENT000013: Successful version handshake completed for receiver context EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext at 19699dd, receiver=Remoting connection EJB receiver [connection=org.jboss.ejb.client.remoting.ConnectionPool$PooledConnection at ae4d15,channel=jboss.ejb,nodename=jbossas-with-remote-outbound-connection]} on channel Channel ID ce12ca12 (outbound) of Remoting connection 0000cc80 to /127.0.0.1:4547
> 17:48:10,245 INFO  [org.jboss.ejb.client.remoting] (Remoting "config-based-ejb-client-endpoint" task-15) EJBCLIENT000017: Received server version 2 and marshalling strategies [river]
> 17:48:10,252 INFO  [org.jboss.ejb.client.remoting] (ejb-client-cluster-node-connection-creation-3-thread-2) EJBCLIENT000013: Successful version handshake completed for receiver context EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext at 19699dd, receiver=Remoting connection EJB receiver [connection=org.jboss.ejb.client.remoting.ConnectionPool$PooledConnection at 2bee08,channel=jboss.ejb,nodename=default-jbossas]} on channel Channel ID bbe7440a (outbound) of Remoting connection 000f67e9 to /127.0.0.1:4447
> 17:48:10,547 INFO  [org.jboss.ejb.client] (EJB default - 2) JBoss EJB Client version 1.0.21.Final
> 17:48:10,945 INFO  [org.jboss.ejb.client] (EJB default - 1) JBoss EJB Client version 1.0.21.Final
> 17:48:11,181 INFO  [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual stopping of a server instance
> 17:48:11,240 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017521: Undertow AJP listener ajp-connector suspending
> 17:48:11,241 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017520: Undertow AJP listener ajp-connector stopped, was bound to /127.0.0.1:8009
> 17:48:11,305 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017521: Undertow HTTP listener default suspending
> 17:48:11,311 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017520: Undertow HTTP listener default stopped, was bound to /127.0.0.1:8080
> 17:48:11,312 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) JBAS010409: Unbound data source [java:jboss/datasources/ExampleDS]
> 17:48:11,318 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) Stopping host default-host
> 17:48:11,333 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) JBAS010418: Stopped Driver service with driver-name = h2
> 17:48:11,333 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017506: Undertow 1.0.0.Alpha20 stopping
> 17:48:11,349 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 55) ISPN000029: Passivating all entries to disk
> 17:48:11,353 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 55) ISPN000030: Passivated 1 entries in 4 milliseconds
> 17:48:11,390 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 55) JBAS010282: Stopped org.jboss.as.test.manualmode.ejb.client.cluster.ClusteredStatefulNodeNameEcho cache from ejb container
> 17:48:11,796 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-1) ISPN000029: Passivating all entries to disk
> 17:48:11,796 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-1) ISPN000030: Passivated 0 entries in 0 milliseconds
> 17:48:11,826 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-1) JBAS010282: Stopped repl cache from ejb container
> 17:48:11,829 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015877: Stopped deployment server-to-server-clustered-ejb-invocation.jar (runtime-name: server-to-server-clustered-ejb-invocation.jar) in 623ms
> 17:48:11,959 INFO  [org.jboss.ejb.client.remoting] (Remoting "config-based-ejb-client-endpoint" task-5) EJBCLIENT000016: Channel Channel ID bbe7440a (outbound) of Remoting connection 000f67e9 to null can no longer process messages
> 17:48:11,977 INFO  [org.jboss.ejb.client.remoting] (Remoting "jbossas-with-remote-outbound-connection" task-9) EJBCLIENT000016: Channel Channel ID 8785ee03 (outbound) of Remoting connection 00a2e892 to null can no longer process messages
> 17:48:12,099 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-2) JBAS010282: Stopped remote-connector-client-mappings cache from ejb container
> 17:48:12,100 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000080: Disconnecting and closing JGroups Channel
> 17:48:12,493 INFO  [org.jboss.as.clustering] (Incoming-7,shared=udp) JBAS010225: New cluster view for partition ejb (id: 2, delta: -1, merge: false) : [jbossas-with-remote-outbound-connection/ejb]
> 17:48:12,495 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-7,shared=udp) ISPN000094: Received new cluster view: [jbossas-with-remote-outbound-connection/ejb|2] [jbossas-with-remote-outbound-connection/ejb]
> 17:48:12,504 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000082: Stopping the RpcDispatcher
> 17:48:12,513 INFO  [org.jboss.as] (MSC service thread 1-1) JBAS015950: WildFly 8.0.0.Alpha2-SNAPSHOT "WildFly" stopped in 1301ms
> 17:48:37,707 INFO  [org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager] (EJB default - 3) Could not create a connection for cluster node ClusterNode{clusterName='ejb', nodeName='default-jbossas', clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0, sourceNetworkMaskBits=0, destinationAddress='127.0.0.1', destinationPort=4447}], resolvedDestination=[Destination address=127.0.0.1, destination port=4447]} in cluster ejb: java.lang.RuntimeException: Operation failed with status WAITING
>     at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:93) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:75) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.remoting.RemotingConnectionManager.getConnection(RemotingConnectionManager.java:51) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:77) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.ClusterContext.getEJBReceiverContext(ClusterContext.java:167) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.ClusterContext.getEJBReceiverContext(ClusterContext.java:93) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.EJBClientContext.getClusterEJBReceiverContext(EJBClientContext.java:930) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.EJBClientContext.getClusterEJBReceiverContext(EJBClientContext.java:915) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.EJBClientContext.requireClusterEJBReceiverContext(EJBClientContext.java:981) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:84) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:253) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:198) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at sun.proxy.$Proxy30.getNodeName(Unknown Source)
>     at org.jboss.as.test.manualmode.ejb.client.cluster.NonClusteredStatefulNodeNameEcho.getNodeName(NonClusteredStatefulNodeNameEcho.java:47) [server-to-server-clustered-ejb-invocation.jar:]
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_13]
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_13]
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_13]
>     at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_13]
>     at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>     at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>     at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:58)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:156) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>     at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:66) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:273) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:90) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:55)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:305)
>     at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:428)
>     at org.wildfly.security.manager.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:63)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:305)
>     at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_13]
>     at org.jboss.invocation.PrivilegedInterceptor.processInvocation(PrivilegedInterceptor.java:65)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>     at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
>     at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:329) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:70) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:203) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_13]
>     at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_13]
>     at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_13]
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_13]
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_13]
>     at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_13]
>     at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> 17:49:02,887 INFO  [org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager] (EJB default - 3) Could not create a connection for cluster node ClusterNode{clusterName='ejb', nodeName='default-jbossas', clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0, sourceNetworkMaskBits=0, destinationAddress='127.0.0.1', destinationPort=4447}], resolvedDestination=[Destination address=127.0.0.1, destination port=4447]} in cluster ejb: java.lang.RuntimeException: Operation failed with status WAITING
>     at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:93) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:75) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.remoting.RemotingConnectionManager.getConnection(RemotingConnectionManager.java:51) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:77) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.ClusterContext.getEJBReceiverContext(ClusterContext.java:167) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.ClusterContext.getEJBReceiverContext(ClusterContext.java:93) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.EJBClientContext.getClusterEJBReceiverContext(EJBClientContext.java:930) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.EJBClientContext.getClusterEJBReceiverContext(EJBClientContext.java:937) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.EJBClientContext.getClusterEJBReceiverContext(EJBClientContext.java:915) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.EJBClientContext.requireClusterEJBReceiverContext(EJBClientContext.java:981) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:84) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:253) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:198) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at sun.proxy.$Proxy30.getNodeName(Unknown Source)
>     at org.jboss.as.test.manualmode.ejb.client.cluster.NonClusteredStatefulNodeNameEcho.getNodeName(NonClusteredStatefulNodeNameEcho.java:47) [server-to-server-clustered-ejb-invocation.jar:]
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_13]
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_13]
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_13]
>     at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_13]
>     at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>     at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>     at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:58)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:156) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>     at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:66) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:273) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:90) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:55)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:305)
>     at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:428)
>     at org.wildfly.security.manager.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:63)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:305)
>     at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_13]
>     at org.jboss.invocation.PrivilegedInterceptor.processInvocation(PrivilegedInterceptor.java:65)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>     at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
>     at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:329) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:70) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:203) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_13]
>     at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_13]
>     at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_13]
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_13]
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_13]
>     at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_13]
>     at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> 17:49:02,921 ERROR [org.jboss.as.ejb3.invocation] (EJB default - 3) JBAS014134: EJB Invocation failed on component NonClusteredStatefulNodeNameEcho for method public abstract java.lang.String org.jboss.as.test.manualmode.ejb.client.cluster.NodeNameEcho.getNodeName(boolean): javax.ejb.EJBException: java.lang.IllegalStateException: EJBCLIENT000028: No EJB receiver contexts available in cluster ejb
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:190) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:90) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:55)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:305)
>     at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:428)
>     at org.wildfly.security.manager.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:63)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:305)
>     at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_13]
>     at org.jboss.invocation.PrivilegedInterceptor.processInvocation(PrivilegedInterceptor.java:65)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>     at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
>     at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:329) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:70) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:203) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_13]
>     at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_13]
>     at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_13]
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_13]
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_13]
>     at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_13]
>     at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> Caused by: java.lang.IllegalStateException: EJBCLIENT000028: No EJB receiver contexts available in cluster ejb
>     at org.jboss.ejb.client.EJBClientContext.requireClusterEJBReceiverContext(EJBClientContext.java:983) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:84) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:253) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:198) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144) [jboss-ejb-client-1.0.21.Final.jar:1.0.21.Final]
>     at sun.proxy.$Proxy30.getNodeName(Unknown Source)
>     at org.jboss.as.test.manualmode.ejb.client.cluster.NonClusteredStatefulNodeNameEcho.getNodeName(NonClusteredStatefulNodeNameEcho.java:47) [server-to-server-clustered-ejb-invocation.jar:]
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_13]
>     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_13]
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_13]
>     at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_13]
>     at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>     at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
>     at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:58)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:156) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>     at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:66) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289)
>     at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:273) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
>     ... 41 more
> 17:49:02,974 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 54) ISPN000029: Passivating all entries to disk
> 17:49:02,977 INFO  [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 54) ISPN000030: Passivated 1 entries in 2 milliseconds
> 17:49:02,979 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 54) JBAS010282: Stopped org.jboss.as.test.manualmode.ejb.client.cluster.ClusteredStatefulNodeNameEcho cache from ejb container
> 17:49:02,992 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-2) JBAS010282: Stopped remote-connector-client-mappings cache from ejb container
> 17:49:02,996 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015877: Stopped deployment server-to-server-clustered-ejb-invocation.jar (runtime-name: server-to-server-clustered-ejb-invocation.jar) in 26ms
> 17:49:02,999 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-1) ISPN000029: Passivating all entries to disk
> 17:49:02,999 INFO  [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-1) ISPN000030: Passivated 0 entries in 0 milliseconds
> 17:49:03,056 INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-1) JBAS010282: Stopped repl cache from ejb container
> 17:49:03,058 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000080: Disconnecting and closing JGroups Channel
> 17:49:03,072 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000082: Stopping the RpcDispatcher
> 17:49:03,093 INFO  [org.jboss.as.repository] (management-handler-thread - 2) JBAS014901: Content removed from location C:\BuildAgent\work\1943cb9aa6e69362\testsuite\integration\manualmode\target\jbossas-with-remote-outbound-connection\standalone\data\content\e0\8b25b6eed5c6f2df04ba76fd92ab3c469cfc0d\content
> 17:49:03,094 INFO  [org.jboss.as.server] (management-handler-thread - 2) JBAS018558: Undeployed "server-to-server-clustered-ejb-invocation.jar" (runtime-name: "server-to-server-clustered-ejb-invocation.jar")
> 17:49:03,096 INFO  [org.jboss.arquillian.container.test.impl.client.container.ClientContainerController] (main) Manual stopping of a server instance
> 17:49:03,147 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) JBAS017521: Undertow AJP listener ajp-connector suspending
> 17:49:03,148 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) JBAS017520: Undertow AJP listener ajp-connector stopped, was bound to /127.0.0.1:8109
> 17:49:03,153 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) JBAS017521: Undertow HTTP listener default suspending
> 17:49:03,153 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) JBAS017520: Undertow HTTP listener default stopped, was bound to /127.0.0.1:8180
> 17:49:03,155 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) JBAS010409: Unbound data source [java:jboss/datasources/ExampleDS]
> 17:49:03,160 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) Stopping host default-host
> 17:49:03,173 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) JBAS010418: Stopped Driver service with driver-name = h2
> 17:49:03,174 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) JBAS017506: Undertow 1.0.0.Alpha20 stopping
> 17:49:03,205 INFO  [org.jboss.ejb.client.remoting] (Remoting "config-based-ejb-client-endpoint" task-11) EJBCLIENT000016: Channel Channel ID ce12ca12 (outbound) of Remoting connection 0000cc80 to null can no longer process messages
> 17:49:03,217 INFO  [org.jboss.as] (MSC service thread 1-2) JBAS015950: WildFly 8.0.0.Alpha2-SNAPSHOT "WildFly" stopped in 84ms
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Thu Oct 31 11:55:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 11:55:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1554) Service changes due to
 rollback should be completed before operation completes
In-Reply-To: <JIRA.12494592.1371596537000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494592.1371596537000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494592.1371596537000.26583.1383234902095@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFLY-1554:
------------------------------------

    Assignee: Tomaz Cerar  (was: Stuart Douglas)

    
> Service changes due to rollback should be completed before operation completes
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-1554
>                 URL: https://issues.jboss.org/browse/WFLY-1554
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Tomaz Cerar
>            Assignee: Tomaz Cerar
>
> "As executeAndRollbackOperation() result is retrieved but actual rollback of deployment is is not complete."
> That's a bug then. Service changes due to rollback should be completed before the operation returns. 
> for more details see https://github.com/wildfly/wildfly/pull/4664
> and DeploymentScannerTestCase

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 11:57:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 11:57:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1445) Jawr servlet with name
 JavascriptServlet failed to initialize properly.
In-Reply-To: <JIRA.12493458.1370278846000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493458.1370278846000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493458.1370278846000.26590.1383235022012@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-1445.
----------------------------------

    Resolution: Out of Date


OSGi support has been removed from WF.
                
> Jawr servlet with name JavascriptServlet failed to initialize properly. 
> ------------------------------------------------------------------------
>
>                 Key: WFLY-1445
>                 URL: https://issues.jboss.org/browse/WFLY-1445
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Alpha2
>            Reporter: Igor Shulika
>            Assignee: Stuart Douglas
>
> I'm deploying a OSGi WAB file on the latest WildFly 8.0.0.Alpha2-SNAPSHOT server. Can not initialize the JavascriptServlet from JAWR Bundle. Note: When I used the <extension module="org.jboss.as.web"/> insted of <extension module="org.wildfly.extension.undertow"/> it works.
> Please see error trace below.
> 16:39:44,476 FATAL [net.jawr.web.servlet.JawrServlet] (MSC service thread 1-3) Jawr servlet with name JavascriptServlet failed to initialize properly.
> 16:39:44,476 FATAL [net.jawr.web.servlet.JawrServlet] (MSC service thread 1-3) Cause:
> 16:39:44,476 FATAL [net.jawr.web.servlet.JawrServlet] (MSC service thread 1-3) null: java.lang.reflect.UndeclaredThrowableException
> at com.sun.proxy.$Proxy22.getResource(Unknown Source)
> at net.jawr.web.resource.handler.reader.ServletContextResourceReaderHandler.getResource(ServletContextResourceReaderHandler.java:192) [ServletContextResourceReaderHandler.class:]
> at net.jawr.web.resource.bundle.handler.ResourceBundlesHandlerImpl.joinAndPostprocessBundle(ResourceBundlesHandlerImpl.java:892) [ResourceBundlesHandlerImpl.class:]
> at net.jawr.web.resource.bundle.handler.ResourceBundlesHandlerImpl.joinAndPostProcessBundle(ResourceBundlesHandlerImpl.java:835) [ResourceBundlesHandlerImpl.class:]
> at net.jawr.web.resource.bundle.handler.ResourceBundlesHandlerImpl.joinAndStoreBundle(ResourceBundlesHandlerImpl.java:766) [ResourceBundlesHandlerImpl.class:]
> at net.jawr.web.resource.bundle.handler.ResourceBundlesHandlerImpl.initAllBundles(ResourceBundlesHandlerImpl.java:542) [ResourceBundlesHandlerImpl.class:]
> at net.jawr.web.resource.bundle.handler.CachedResourceBundlesHandler.initAllBundles(CachedResourceBundlesHandler.java:126) [CachedResourceBundlesHandler.class:]
> at net.jawr.web.resource.bundle.factory.BundlesHandlerFactory.buildResourceBundlesHandler(BundlesHandlerFactory.java:233) [BundlesHandlerFactory.class:]
> at net.jawr.web.resource.bundle.factory.PropertiesBasedBundlesHandlerFactory.buildResourceBundlesHandler(PropertiesBasedBundlesHandlerFactory.java:204) [PropertiesBasedBundlesHandlerFactory.class:]
> at net.jawr.web.servlet.JawrRequestHandler.initializeJawrConfig(JawrRequestHandler.java:349) [JawrRequestHandler.class:]
> at net.jawr.web.servlet.JawrRequestHandler.initRequestHandler(JawrRequestHandler.java:262) [JawrRequestHandler.class:]
> at net.jawr.web.servlet.JawrRequestHandler.<init>(JawrRequestHandler.java:184) [JawrRequestHandler.class:]
> at net.jawr.web.servlet.JawrServlet.init(JawrServlet.java:56) [JawrServlet.class:]
> at javax.servlet.GenericServlet.init(GenericServlet.java:244) [jboss-servlet-api_3.1_spec-1.0.0.Alpha1.jar:1.0.0.Alpha1]
> at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:145) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.core.ManagedServlet.start(ManagedServlet.java:62) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:599) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:77)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1974) [jboss-msc-1.1.2.Final.jar:1.1.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1907) [jboss-msc-1.1.2.Final.jar:1.1.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_21]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_21]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_21]
> at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_21]
> at net.jawr.web.resource.bundle.generator.ResourceGeneratorReaderProxyFactory$ResourceGeneratorReaderWrapperInvocationHandler.invoke(ResourceGeneratorReaderProxyFactory.java:167) [ResourceGeneratorReaderProxyFactory$ResourceGeneratorReaderWrapperInvocationHandler.class:]
> ... 23 more
> Caused by: java.lang.IllegalArgumentException: The DWR bean named 'TransactionService' was not found in any DWR configuration instance.
> at net.jawr.web.resource.bundle.generator.dwr.DWRBeanGenerator.getInterfaceScript(DWRBeanGenerator.java:265) [DWRBeanGenerator.class:]
> at net.jawr.web.resource.bundle.generator.dwr.DWRBeanGenerator.createResource(DWRBeanGenerator.java:134) [DWRBeanGenerator.class:]
> at net.jawr.web.resource.bundle.generator.ResourceGeneratorReaderWrapper.getResource(ResourceGeneratorReaderWrapper.java:135) [ResourceGeneratorReaderWrapper.class:]
> ... 28 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 11:57:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 11:57:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1314) Add a management operation to
 let remote EJB clients know that a particular server is no longer capable
 of handling a EJB request
In-Reply-To: <JIRA.12491045.1367598318000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12491045.1367598318000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12491045.1367598318000.26593.1383235022166@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFLY-1314:
------------------------------------

    Assignee: David Lloyd  (was: Stuart Douglas)

    
> Add a management operation to let remote EJB clients know that a particular server is no longer capable of handling a EJB request
> ---------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1314
>                 URL: https://issues.jboss.org/browse/WFLY-1314
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>            Reporter: jaikiran pai
>            Assignee: David Lloyd
>
> While looking into another issue WFLY-1313 we realized that it might be a good idea to allow admins to have some kind of management operation where they could say that a particular server will no longer accept EJB invocations (for all deployments or maybe just a specific deployment). This would then allow the admins to issue such a operation and the remote EJB clients (via the EJB client library) would then realize that, they should no longer send out requests to that server node. This way the admins can then even undeploy the deployment or shutdown the server without having to worry about EJB invocations coming in and failing in-flight due to deployment being currently undeployed.
> From a EJB client library point of view, this essentially is a explicit "module unavailable" notification that the server will trigger to its connected clients.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 12:03:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 12:03:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-823) NPE from EJB code when
 shutting down JBoss server
In-Reply-To: <JIRA.12488088.1364314697000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12488088.1364314697000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488088.1364314697000.26628.1383235382239@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-823.
---------------------------------

    Resolution: Out of Date


Looks like this should have been fixed as part of a different bug, by removing the use of EJBUtils .
                
> NPE from EJB code when shutting down JBoss server
> -------------------------------------------------
>
>                 Key: WFLY-823
>                 URL: https://issues.jboss.org/browse/WFLY-823
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>         Environment: 64 bit Linux 
>            Reporter: John Leinaweaver
>            Assignee: Stuart Douglas
>            Priority: Minor
>              Labels: jboss
>
> (apologies if I have the wrong version in this bug report)
> This is a followup from discussion
> https://community.jboss.org/message/804610#804610   (message 33).
> Using build #1498 from the nightly snapshot
> jboss-as-7.x-nightly.zip
> When the JBoss server is shut down with cntl-c, a NPE in the EJB stack was exposed.   I've seen this once, hopefully the stack trace provides enough.
> Get the server log here, and search for "NullPointerEx"
> https://community.jboss.org/servlet/JiveServlet/download/804402-80854/server.log.zip

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 12:10:01 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 12:10:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1766) The @Local annotation on a
 session bean "overrides" information about @Local interfaces implemented
 through keyword "implements"
In-Reply-To: <JIRA.12497425.1374855457000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497425.1374855457000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497425.1374855457000.26660.1383235801902@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-1766.
----------------------------------

    Resolution: Rejected


I think the current behaviour is correct, even though the spec is not super clear in this case I am pretty sure the intention is that @Local on the bean class overrides @Local specified on an interface.

This gives developers more flexibility, as otherwise there is no way to exclude an annotated interface from being considered a business interface.

If the spec is ever clarified in such a way that it makes it clear that this is not the desired behaviour then we will revisit. 
                
> The @Local annotation on a session bean "overrides" information about @Local interfaces implemented through keyword "implements"
> --------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1766
>                 URL: https://issues.jboss.org/browse/WFLY-1766
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Matus Abaffy
>            Assignee: Stuart Douglas
>
> I have the following interfaces
> {code}
> public interface Bar { }
> {code}
> {code}
> @Local
> public interface Foo { }
> {code}
> and a session bean
> {code}
> @Local(Bar.class)
> @Stateful
> public class SessionBean implements Foo { }
> {code}
> EJB 3.2 specification (4.9.7 Session Bean?s Business Interface) states:
> "any interface of the bean class is explicitly designated as a business interface of the bean by either of the following means:
> ? using the Local or Remote annotation with a non-empty value on the bean class
> ? using the Local or Remote annotation on the interface
> ? in the deployment descriptor"
> Therefore, I assume SessionBean should expose both Bar and Foo as local business interfaces. However, only Bar is exposed:
> {noformat}
> ...
> INFO [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-7) JNDI bindings for session bean named SessionBean in deployment unit deployment "pckg.war" are as follows:
> 	java:global/pckg/SessionBean!org.jboss. ... .Bar
> 	java:app/pckg/SessionBean!org.jboss. ... .Bar
> 	java:module/SessionBean!org.jboss. ... .Bar
> 	java:global/pckg/SessionBean
> 	java:app/pckg/SessionBean
> 	java:module/SessionBean
> {noformat}
> It seems that the @Local annotation on a session bean class "overrides" all information about @Local interfaces implemented using the keyword "implements". (It does not ignore @Remote interfaces implemented using the keyword "implements".)
> The @Remote annotation on a session bean class works analogically - it causes @Remote interfaces implemented using the keyword "implements" not to be contained in the set of remote business interfaces.
> I haven't tried yet what happens if I declare another interface(s) for certain session beans as local/remote in the deployment descriptor - whether those defined in the java classes become "overriden". But I'd like to know what SHOULD happen. If it is not clear from the EJB spec., the exact behaviour in such case should be stated specifically for Wildfly - I'd be grateful for any links to such information.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Thu Oct 31 12:16:03 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 12:16:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1535) SSLEJBRemoteClientTestCase
 runs into intermittent failures
In-Reply-To: <JIRA.12494315.1371223824000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494315.1371223824000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494315.1371223824000.26679.1383236163286@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFLY-1535:
------------------------------------

    Assignee: Paul Ferraro  (was: Stuart Douglas)


Assigning to Paul to either close or fix as appropriate
                
> SSLEJBRemoteClientTestCase runs into intermittent failures
> ----------------------------------------------------------
>
>                 Key: WFLY-1535
>                 URL: https://issues.jboss.org/browse/WFLY-1535
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: jaikiran pai
>            Assignee: Paul Ferraro
>            Priority: Critical
>             Fix For: 8.0.0.CR1
>
>
> SSLEJBRemoteClientTestCase runs into intermittent failures on TeamCity. To make matters worse, a failure in one test method can have a side effect on other test methods in that testcase, given the way it's written. The entire run is here http://teamcity.cafe-babe.org/viewLog.html?buildId=5251&tab=buildResultsDiv&buildTypeId=bt27.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 12:18:01 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 12:18:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2011) jboss-ejb3.xml deployment
 descriptor is not parsed correct for the clustering element
In-Reply-To: <JIRA.12500087.1378394515000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500087.1378394515000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500087.1378394515000.26681.1383236281872@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12826257#comment-12826257 ] 

Stuart Douglas commented on WFLY-2011:
--------------------------------------

I have pushed a fix for this into the metadata repository, this will be resolved by the next metadata release.
                
> jboss-ejb3.xml deployment descriptor is not parsed correct for the clustering element
> -------------------------------------------------------------------------------------
>
>                 Key: WFLY-2011
>                 URL: https://issues.jboss.org/browse/WFLY-2011
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Wolf-Dieter Fink
>            Assignee: Stuart Douglas
>              Labels: ejb-jar.xml
>
> If beans of an application are marked as clustered by using the jboss-ejb3.xml DD the behaviour is not consistent.
> From the XSD the <ejb-name> element can not be added multiple times.
> And the following configuration will be not valid:
>   <assembly-descriptor>
>     <c:clustering>
>       <ejb-name>Bean1</ejb-name>
>       <ejb-name>Bean2</ejb-name>
>       <c:clustered>true</c:clustered>
>     </c:clustering>
>   </assembly-descriptor>
> The parser should throw an Exception and the application should not be deployed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 12:20:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 12:20:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1183) Configure EJB3/MDB with an
 individual thread pool for each EJB.
In-Reply-To: <JIRA.12487807.1363965045000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12487807.1363965045000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487807.1363965045000.26692.1383236402318@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-1183.
----------------------------------

    Resolution: Rejected


Rejecting as per David comments.
                
> Configure EJB3/MDB with an individual thread pool for each EJB.
> ---------------------------------------------------------------
>
>                 Key: WFLY-1183
>                 URL: https://issues.jboss.org/browse/WFLY-1183
>             Project: WildFly
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>            Reporter: Jeremy Whiting
>            Assignee: Stuart Douglas
>
> For performance of an application to be scalable I need to configure sometimes a thread pool to an EJB. The pool is not shared with other EJB in the deployed application.
>  For example 
> PoolA - EJB Dog
> PoolB - EJB Cat
>  To configure this the ability no define the thread pool name for an EJB. Rather than an EJB to the shared thread pool as it currently works.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 12:20:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 12:20:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1312) Restore EJB3 tests that
 deploy duplicate test deployment
In-Reply-To: <JIRA.12491023.1367572765000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12491023.1367572765000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12491023.1367572765000.26696.1383236402475@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-1312.
----------------------------------

    Resolution: Out of Date


These tests appear to have already been restored
                
> Restore EJB3 tests that deploy duplicate test deployment
> --------------------------------------------------------
>
>                 Key: WFLY-1312
>                 URL: https://issues.jboss.org/browse/WFLY-1312
>             Project: WildFly
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>            Reporter: Thomas Diesler
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.CR1
>
>
> There are a number of EJB3 tests that [have been disabled|https://github.com/wildfly/wildfly/commit/a22ea284c7a7761e4626e165cd79359ed3a9f62a] because they deploy a duplicate test deployment

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 12:24:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 12:24:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-972) EJB calendar timer Sunday
 calculation problem in certain locales
In-Reply-To: <JIRA.12477270.1350507760000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12477270.1350507760000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12477270.1350507760000.26699.1383236642005@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFLY-972:
-----------------------------------

    Assignee: Cheng Fang  (was: Stuart Douglas)

    
> EJB calendar timer Sunday calculation problem in certain locales
> ----------------------------------------------------------------
>
>                 Key: WFLY-972
>                 URL: https://issues.jboss.org/browse/WFLY-972
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>         Environment: JDK 6 & 7
>            Reporter: Cheng Fang
>            Assignee: Cheng Fang
>
> My ejb class contains this timeout method:
> {code:java}
>     @Schedule(dayOfWeek="Sun", persistent=false)
>     private void sunday(Timer t) {
>     }
> {code}
> When calling this timer.getNextTimeout(), it returned the Sunday after next Sunday (expecting next Sunday) when running on certain locales (it_IT, es_PE, etc).  It works as expected on other locales like en_US.  
> I added -Duser.language=it -Duser.country=IT to JAVA_OPTS when starting standalone server to use that locale.
> Seems to be a JDK bug.  There could be some differences how dates are calculated in different locales, but shouldn't be that big like skip one Sunday.  Today is Wed.
> One workaround is "to use locale.English when instantiating GregorianCalendar in the following classes."  I tried it on 7.2 with it_IT, and got the expected Sunday.
> {noformat}
> ejb3/src/main/java/org/jboss/as/ejb3/timerservice/schedule/CalendarBasedTimeout.java
> ejb3/src/main/java/org/jboss/as/ejb3/timerservice/schedule/util/CalendarUtil.java
> ejb3/src/main/java/org/jboss/as/ejb3/timerservice/task/CalendarTimerTask.java
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 12:24:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 12:24:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-959) Allow more flexibility in the
 way EJB authentication is handled with regards to remoting and
 security-realms
In-Reply-To: <JIRA.12482951.1358783604000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12482951.1358783604000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12482951.1358783604000.26702.1383236642156@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFLY-959:
-----------------------------------

    Assignee: David Lloyd  (was: Stuart Douglas)

    
> Allow more flexibility in the way EJB authentication is handled with regards to remoting and security-realms
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-959
>                 URL: https://issues.jboss.org/browse/WFLY-959
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>            Reporter: Derek Horton
>            Assignee: David Lloyd
>
> My confusion is around the remoting/security-realm setup in the use case
> where multiple EJBs are deployed that use different security-domains and
> the EJBs will be invoked by remote standalone clients.  For example,
> ejbX needs to be in the sec-domain-X security-domain, while ejbY needs to
> be in the sec-domain-Y security-domain.
> In this situation, the authentication checks are going to be handled by
> the security-realm that is associated with the remote connector that is
> configured to be used by the EJB subsystem.
> It looks like the security-realm can either handle the authentication
> checks directly (properties file, ldap, etc) or it can defer to the
> jaas security-domain.  In both of those situations, it seems that the
> EJBs are limited to a single authentication point.  The EJB
> authentication is either going to be handled by a single security-realm
> or the security-realm will defer to a single security-domain.
> I could configure the security-domain to have multiple login modules.  I
> assume the same thing could be done with the security-realm.
> Basically the problem that I am trying to solve boils down to this:  the
> authentication checks for remote EJBs appear to be checked by either a
> single security-realm or a single security-domain.  Is there a way to
> change this?
> One idea I had was to add another remote connector to the EJB subsystem.
> Unfortunately, this does not appear to be possible.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 12:26:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 12:26:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-948) Increase log level when
 informing about missing security domain configuration in
 EJBSecurityViewConfigurator
In-Reply-To: <JIRA.12488299.1364554963000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12488299.1364554963000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488299.1364554963000.26718.1383236762276@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-948.
---------------------------------

    Resolution: Rejected


I don't think we should do this. The only way to get this message is to remove the default security domain element, which signifies intent. 
                
> Increase log level when informing about missing security domain configuration in EJBSecurityViewConfigurator
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-948
>                 URL: https://issues.jboss.org/browse/WFLY-948
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>            Reporter: Josef Cacek
>            Assignee: Stuart Douglas
>
> Use WARN log-level for the message about missing security domain for EJBs introduced in https://github.com/jbossas/jboss-as/pull/3164/files (c.f. AS7-5581)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 12:28:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 12:28:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-875) Singletons don't respect
 @TransactionAttribute/deployment descriptor in @PostConstruct.
In-Reply-To: <JIRA.12474183.1347347177000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12474183.1347347177000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12474183.1347347177000.26725.1383236882291@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-875.
---------------------------------

    Resolution: Out of Date


I fixed this a while ago.
                
> Singletons don't respect @TransactionAttribute/deployment descriptor in @PostConstruct.
> ---------------------------------------------------------------------------------------
>
>                 Key: WFLY-875
>                 URL: https://issues.jboss.org/browse/WFLY-875
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>         Environment: JBoss 7.1.1
>            Reporter: S?awomir Wojtasiak
>            Assignee: Stuart Douglas
>              Labels: rhq
>         Attachments: jboss-as-helloworld-singleton.war
>
>
> Singletons don't respect any transaction attributes for their @PostConstruct methods and invokes them always with REQUIRED_NEW semantics. Following part of code is responsible for hardcoding these values for registered _SingletonLifecycleCMTTxInterceptor_ factories:
> {code:title=org.jboss.as.ejb3.component.singleton.SingletonComponentDescription.java|borderStyle=solid}
>  @Override
>                 public void configure(final DeploymentPhaseContext context, final ComponentDescription description, final ComponentConfiguration configuration) throws DeploymentUnitProcessingException {
>                     configuration.addPostConstructInterceptor(new SingletonLifecycleCMTTxInterceptor.Factory(TransactionAttributeType.REQUIRES_NEW), InterceptorOrder.ComponentPostConstruct.TRANSACTION_INTERCEPTOR);
>                     configuration.addPreDestroyInterceptor(new SingletonLifecycleCMTTxInterceptor.Factory(TransactionAttributeType.REQUIRES_NEW), InterceptorOrder.ComponentPreDestroy.TRANSACTION_INTERCEPTOR);
>                     if(description.isPassivationApplicable()) {
>                         configuration.addPrePassivateInterceptor(new SingletonLifecycleCMTTxInterceptor.Factory(TransactionAttributeType.REQUIRES_NEW), InterceptorOrder.ComponentPassivation.TRANSACTION_INTERCEPTOR);
>                         configuration.addPostActivateInterceptor(new SingletonLifecycleCMTTxInterceptor.Factory(TransactionAttributeType.REQUIRES_NEW), InterceptorOrder.ComponentPassivation.TRANSACTION_INTERCEPTOR);
>                     }
>                     configuration.addTimeoutViewInterceptor(TimerCMTTxInterceptor.FACTORY, InterceptorOrder.View.CMT_TRANSACTION_INTERCEPTOR);
>                 }
> {code}
> EJB 3.1 specification says, REQUIRED, REQUIRED_NEW and NOT_SUPPORTED attributes should be supported, where in case of REQUIRED a semantic of REQUIRED_NEW trancation attribute should be used:
> {panel:title=4.8.3 Transaction Semantics of Initialization and Destruction| borderStyle=dashed| borderColor=#ccc| titleBGColor=#F7D6C1| bgColor=#FFFFCE} 
> PostConstruct and PreDestroy methods of Singletons with container-managed transactions are transactional. From the bean developer?s view there is no client of a PostConstruct or PreDestroy method.
> A PostConstruct or PreDestroy method of a Singleton with container-managed transactions has transaction attribute REQUIRED, REQUIRES_NEW, or NOT_SUPPORTED (Required , RequiresNew, or NotSupported if the deployment descriptor is used to specify the transaction attribute).
> _Note that the container must start a new transaction if the REQUIRED (Required) transaction attribute is used. This guarantees, for example, that the transactional behavior of the PostConstruct method is the same regardless of whether it is initialized eagerly at container startup time or as a side effect of a first client invocation on the Singleton. The REQUIRED transaction attribute value is allowed so that specification of a transaction attribute for the Singleton PostConstruct/PreDestroy methods can be defaulted._
> {panel} 
> So there is not a problem with REQUIRED and REQUIRED_NEW transaction attributes, but NOT_SUPPORTED attribute is just not supported :)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Thu Oct 31 12:28:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 12:28:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-863) On failed secured connection
 during EJB invocations from a remote server instance an incorrect error
 message is shown
In-Reply-To: <JIRA.12460788.1330980583000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12460788.1330980583000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12460788.1330980583000.26730.1383236882715@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFLY-863:
-----------------------------------

    Assignee: David Lloyd  (was: Stuart Douglas)

    
> On failed secured connection during EJB invocations from a remote server instance an incorrect error message is shown
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-863
>                 URL: https://issues.jboss.org/browse/WFLY-863
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>            Reporter: Ond?ej Chaloupka
>            Assignee: David Lloyd
>            Priority: Minor
>
> When EJB invocations from a remote server instance is used and remoting connector of the remote server is secured and the attempt to connection fails an incorrect exception is thrown. 
> In case of version 7.1.0.Final when authentication si not correctly defined then during deployment following exception is thrown:
> {code}
> ERROR [org.jboss.remoting.remote.connection] (Remoting "clientnode" read-1) JBREM000200: Remote connection failed: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.ejb3.dd-based-ejb-client-context."client-ear.ear": org.jboss.msc.service.StartException in service jboss.ejb3.dd-based-ejb-client-context."client-ear.ear": Failed to start service
>             at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1767) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1]
>             at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_23]
>             at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_23]
>             at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_23]
>     Caused by: java.lang.RuntimeException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
>             at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:91)
>             at org.jboss.as.ejb3.remote.DescriptorBasedEJBClientContextService.createRemotingConnections(DescriptorBasedEJBClientContextService.java:124)
>             at org.jboss.as.ejb3.remote.DescriptorBasedEJBClientContextService.start(DescriptorBasedEJBClientContextService.java:86)
>             at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1]
>             at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1]
>             ... 3 more
>     Caused by: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
>             at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:315) [jboss-remoting-3.2.2.GA-redhat-1.jar:3.2.2.GA-redhat-1]
>             at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:214) [jboss-remoting-3.2.2.GA-redhat-1.jar:3.2.2.GA-redhat-1]
>             at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) [xnio-api-3.0.3.GA-redhat-1.jar:3.0.3.GA-redhat-1]
>             at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189) [xnio-api-3.0.3.GA-redhat-1.jar:3.0.3.GA-redhat-1]
>             at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103) [xnio-api-3.0.3.GA-redhat-1.jar:3.0.3.GA-redhat-1]
>             at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) [xnio-api-3.0.3.GA-redhat-1.jar:3.0.3.GA-redhat-1]
>             at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189) [xnio-api-3.0.3.GA-redhat-1.jar:3.0.3.GA-redhat-1]
>             at org.xnio.ssl.JsseConnectedSslStreamChannel.handleReadable(JsseConnectedSslStreamChannel.java:180) [xnio-api-3.0.3.GA-redhat-1.jar:3.0.3.GA-redhat-1]
>             at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103) [xnio-api-3.0.3.GA-redhat-1.jar:3.0.3.GA-redhat-1]
>             at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) [xnio-api-3.0.3.GA-redhat-1.jar:3.0.3.GA-redhat-1]
>             at org.xnio.nio.NioHandle.run(NioHandle.java:90)
>             at org.xnio.nio.WorkerThread.run(WorkerThread.java:184)
>             at ...asynchronous invocation...(Unknown Source)
>             at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:270) [jboss-remoting-3.2.2.GA-redhat-1.jar:3.2.2.GA-redhat-1]
>             at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:251) [jboss-remoting-3.2.2.GA-redhat-1.jar:3.2.2.GA-redhat-1]
>             at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:349) [jboss-remoting-3.2.2.GA-redhat-1.jar:3.2.2.GA-redhat-1]
>             at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:337) [jboss-remoting-3.2.2.GA-redhat-1.jar:3.2.2.GA-redhat-1]
>             at org.jboss.as.remoting.RemoteOutboundConnectionService.connect(RemoteOutboundConnectionService.java:130) [jboss-as-remoting-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
> {code}
> which is correct. But in case that the remote server is shut down, configuration is changed to use security connection then incorrect and confusing exception is thrown:
> {code}
> ERROR [org.jboss.ejb3.invocation] (EJB default - 2) JBAS014134: EJB Invocation failed on component CallingBean for method public abstract java.lang.String serverclient.CallingBeanRemote.call(): javax.ejb.EJBException: java.lang.RuntimeException: java.lang.IllegalStateException: No EJB receiver available for handling [appName:,modulename:myejb,distinctname:] combination
>             at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:166) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
>             at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:230) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
>             at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:304) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
>             at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:190) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
>             at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
>             at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropogatingInterceptor.processInvocation(EJBRemoteTransactionPropogatingInterceptor.java:80) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
>             at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
>             at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
>             at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
>             at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
>             at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
>             at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) [jboss-as-ee-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
>             at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
>             at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:43) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
>             at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
>             at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45) [jboss-as-ee-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
>             at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
>             at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
>             at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165) [jboss-as-ee-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
>             at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:300) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
>             at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$200(MethodInvocationMessageHandler.java:64) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
>             at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:194) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
>             at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [rt.jar:1.6.0_23]
>             at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [rt.jar:1.6.0_23]
>             at java.util.concurrent.FutureTask.run(FutureTask.java:138) [rt.jar:1.6.0_23]
>             at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_23]
>             at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_23]
>             at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_23]
>             at org.jboss.threads.JBossThread.run(JBossThread.java:122)
>     Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: No EJB receiver available for handling [appName:,modulename:myejb,distinctname:] combination
>             at serverclient.CallingBean.call(CallingBean.java:39) [serverclient-ejb.jar:]
>             at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_23]
>             at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_23]
>             at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_23]
>             at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_23]
>             at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72) [jboss-as-ee-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
>             at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
>             at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
>             at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:36) [jboss-as-ee-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
>             at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
>             at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
>             at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
>             at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
>             at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
>             at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
>             at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53) [jboss-as-ee-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
>             at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
>             at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
>             at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1]
>             at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:228) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
>             ... 27 more
>     Caused by: java.lang.IllegalStateException: No EJB receiver available for handling [appName:,modulename:myejb,distinctname:] combination
>             at org.jboss.ejb.client.EJBClientContext.requireEJBReceiver(EJBClientContext.java:516) [jboss-ejb-client-1.0.4.Final.jar:1.0.4.Final]
>             at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:84) [jboss-ejb-client-1.0.4.Final.jar:1.0.4.Final]
>             at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:175) [jboss-ejb-client-1.0.4.Final.jar:1.0.4.Final]
>             at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:136) [jboss-ejb-client-1.0.4.Final.jar:1.0.4.Final]
>             at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:121) [jboss-ejb-client-1.0.4.Final.jar:1.0.4.Final]
>             at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:104) [jboss-ejb-client-1.0.4.Final.jar:1.0.4.Final]
>             at $Proxy15.sayHello(Unknown Source)    at serverclient.CallingBean.call(CallingBean.java:34) [serverclient-ejb.jar:]
>             ... 46 more  
> {code}
> The exception seems that everything was connected correctly only module does not exist in remote context.
> In case of the AS7 Final version is not so problematic but when you take source codes from git then after deploying of application to client server which would like to connect to a secured remote server then no exception is thrown during deployment. Everything looks fine but after execution of remote call the confusing exception is thrown and it's hard to understand that the problem is in not connected context because of security.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Thu Oct 31 12:30:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 12:30:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-803) "NullPointerException" in
 RemotingConnectionEJBReceiver constructor if misconfigured
In-Reply-To: <JIRA.12484178.1360101353000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12484178.1360101353000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12484178.1360101353000.26742.1383237002406@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFLY-803:
-----------------------------------

    Assignee: David Lloyd  (was: Stuart Douglas)

    
> "NullPointerException" in RemotingConnectionEJBReceiver constructor if misconfigured
> ------------------------------------------------------------------------------------
>
>                 Key: WFLY-803
>                 URL: https://issues.jboss.org/browse/WFLY-803
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Tested with 7.2.0 Alpha snapshot of 2013-02-05
> Sample project is build with Java 1.7
>            Reporter: Wolfgang Knauf
>            Assignee: David Lloyd
>            Priority: Minor
>         Attachments: StatelessStandaloneClient.zip
>
>
> While experimenting with EJB remote access, I got confused with the proper configuration ;-). This resulted in a NullPointerException in one of your EJB client classes, and I think this should be handled by a meaningful error message.
> I performed a lookup for "ejb:Stateless/StatelessEJB//GeometricModelBean!de.fhw.komponentenarchitekturen.knauf.stateless.GeometricModelRemote" => this means I want to use the JNDI lookup.
> But in "jndi.properties", I used this: "jboss.naming.client.ejb.context=true" => This should probably activate "jboss-remote naming", and the lookup should be done for "Stateless/StatelessEJB//GeometricModelBean...". (no "ejb:" prefix).
> Instead of an error message, this resulted in this console output, followed by an exception:
> Feb 05, 2013 10:43:57 PM org.xnio.Xnio <clinit>
> INFO: XNIO Version 3.0.7.GA
> Feb 05, 2013 10:43:57 PM org.xnio.nio.NioXnio <clinit>
> INFO: XNIO NIO Implementation Version 3.0.7.GA
> Feb 05, 2013 10:43:57 PM org.jboss.remoting3.EndpointImpl <clinit>
> INFO: JBoss Remoting version 3.2.14.GA
> Feb 05, 2013 10:43:58 PM org.jboss.ejb.client.remoting.VersionReceiver handleMessage
> INFO: EJBCLIENT000017: Received server version 1 and marshalling strategies [river]
> Feb 05, 2013 10:43:58 PM org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver associate
> INFO: EJBCLIENT000013: Successful version handshake completed for receiver context EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext at 28ad5a, receiver=Remoting connection EJB receiver [connection=Remoting connection <c751fd>,channel=jboss.ejb,nodename=turbotante]} on channel Channel ID b93e696f (outbound) of Remoting connection 00411379 to localhost/127.0.0.1:4447
> Feb 05, 2013 10:44:03 PM org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver associate
> INFO: EJBCLIENT000015: Initial module availability report for Remoting connection EJB receiver [connection=Remoting connection <c751fd>,channel=jboss.ejb,nodename=turbotante] wasn't received during the receiver context association
> Feb 05, 2013 10:44:03 PM org.jboss.ejb.client.EJBClient <clinit>
> INFO: JBoss EJB Client version 1.0.16.Final
> java.lang.NullPointerException
> 	at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.<init>(RemotingConnectionEJBReceiver.java:102)
> 	at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.<init>(RemotingConnectionEJBReceiver.java:90)
> 	at org.jboss.ejb.client.EJBClientContext.registerConnection(EJBClientContext.java:420)
> 	at org.jboss.naming.remote.client.ejb.RemoteNamingEjbClientContextSelector.getContext(RemoteNamingEjbClientContextSelector.java:60)
> 	at org.jboss.naming.remote.client.ejb.RemoteNamingEjbClientContextSelector.getCurrent(RemoteNamingEjbClientContextSelector.java:46)
> 	at org.jboss.naming.remote.client.ejb.RemoteNamingEjbClientContextSelector.getCurrent(RemoteNamingEjbClientContextSelector.java:15)
> 	at org.jboss.ejb.client.EJBClientContext.getCurrent(EJBClientContext.java:271)
> 	at org.jboss.ejb.client.EJBClientContext.requireCurrent(EJBClientContext.java:281)
> 	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:156)
> 	at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:124)
> 	at sun.proxy.$Proxy0.computeCuboidVolume(Unknown Source)
> 	at de.fhw.komponentenarchitekturen.knauf.stateless.standaloneclient.GeometricModelApplicationClient.main(GeometricModelApplicationClient.java:38)
> I will attach a sample. This is an Eclipse project. But i can also be run standalone: just modify "StatelessStandaloneClient\startclient.bat" to match your path to "jboss-client.jar" and start it (you need Java 1.7 for this). You don't even have to deploy the EAR app on the server to see the error. But if you want to do so: it is also part of the attachment: "Stateless.ear".

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 12:40:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 31 Oct 2013 12:40:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2368) env-entry is not injected
 with @Resource annotation into CDI beans and JAX-RS resources
In-Reply-To: <JIRA.12508628.1382566566000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508628.1382566566000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508628.1382566566000.26780.1383237602435@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12826270#comment-12826270 ] 

Stuart Douglas commented on WFLY-2368:
--------------------------------------

I think this should be resolved, can you re-test against upstream?
                
> env-entry is not injected with @Resource annotation into CDI beans and JAX-RS resources
> ---------------------------------------------------------------------------------------
>
>                 Key: WFLY-2368
>                 URL: https://issues.jboss.org/browse/WFLY-2368
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CDI / Weld, REST
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Dmytro Zemnytskiy
>            Assignee: Stuart Douglas
>
> I built simple web application to narrow down problem, consisting of war packaged in ear. It attempts to inject env-entry declared in web.xml using @Resource annotation into servlet, jax-rs resource and cdi managed bean.
> For now only servlet is injected with env-entry properly. JAX-RS resource requires @ManagedBean annotation in order to work, but still does not work if it is listed explicitly in its Application, rather than autoscanned. CDI bean does not work yet. Same app without modifications work properly in Jboss AS 7.1
> Below is example of CDI bean :
> @Named
> public class EnvEntryProducer {
> 	@Resource(name="demo") String env;
> 	
> 	@PostConstruct void logMe() {
> 		System.out.print("Env: " + env);
> 	}
> 	
> 	@Produces @Named("enventry") String getEnv() {
> 		return env;
> 	}
> }
> PostConstruct is not called yet as well

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 13:02:01 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 31 Oct 2013 13:02:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1726) Bundler: send message batch
 of 1 as single message
In-Reply-To: <JIRA.12509209.1383230042000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509209.1383230042000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509209.1383230042000.26824.1383238921927@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1726.
----------------------------

    Resolution: Done

    
> Bundler: send message batch of 1 as single message
> --------------------------------------------------
>
>                 Key: JGRP-1726
>                 URL: https://issues.jboss.org/browse/JGRP-1726
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> When the TransferQueueBundler ("new" / default) sends bundled messages, if there is only a single message in the list, the message is still sent as a *batch* (of 1).
> Currently, parsing of single messages is done in a separate thread (JGRP-1716) whereas parsing of message batches is done in the thread which received the messages from the socket.
> If we therefore send a batch of 1 as a single message, we might get better perf (to be verified).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 14:15:03 2013
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Thu, 31 Oct 2013 14:15:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2425) Use forked version of slf4j
 to fix concurrency issue with static binding
In-Reply-To: <JIRA.12509230.1383243255072@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509230.1383243255072@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509230.1383243255072.26955.1383243303748@jira02.app.mwc.hst.phx2.redhat.com>

James Perkins created WFLY-2425:
-----------------------------------

             Summary: Use forked version of slf4j to fix concurrency issue with static binding
                 Key: WFLY-2425
                 URL: https://issues.jboss.org/browse/WFLY-2425
             Project: WildFly
          Issue Type: Component  Upgrade
      Security Level: Public (Everyone can see)
          Components: Logging
            Reporter: James Perkins
            Assignee: James Perkins
            Priority: Minor


The slf4j-api static binding is not thread safe. A fork of slf4j-api was needed for EAP so we might as well patch WildFly too. The slf4j bugzilla is http://bugzilla.slf4j.org/show_bug.cgi?id=176. The patch used in the fork is attached to the bz.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 14:17:01 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 31 Oct 2013 14:17:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2425) Use forked version of slf4j
 to fix concurrency issue with static binding
In-Reply-To: <JIRA.12509230.1383243255000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509230.1383243255000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509230.1383243255000.26957.1383243421915@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2425:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1011821

    
> Use forked version of slf4j to fix concurrency issue with static binding
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2425
>                 URL: https://issues.jboss.org/browse/WFLY-2425
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Minor
>
> The slf4j-api static binding is not thread safe. A fork of slf4j-api was needed for EAP so we might as well patch WildFly too. The slf4j bugzilla is http://bugzilla.slf4j.org/show_bug.cgi?id=176. The patch used in the fork is attached to the bz.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 14:19:01 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 31 Oct 2013 14:19:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2425) Use forked version of slf4j
 to fix concurrency issue with static binding
In-Reply-To: <JIRA.12509230.1383243255000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509230.1383243255000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509230.1383243255000.26961.1383243541975@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12826298#comment-12826298 ] 

RH Bugzilla Integration commented on WFLY-2425:
-----------------------------------------------

James Perkins <jperkins at redhat.com> changed the Status of [bug 1011821|https://bugzilla.redhat.com/show_bug.cgi?id=1011821] from ASSIGNED to POST
                
> Use forked version of slf4j to fix concurrency issue with static binding
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2425
>                 URL: https://issues.jboss.org/browse/WFLY-2425
>             Project: WildFly
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Minor
>
> The slf4j-api static binding is not thread safe. A fork of slf4j-api was needed for EAP so we might as well patch WildFly too. The slf4j bugzilla is http://bugzilla.slf4j.org/show_bug.cgi?id=176. The patch used in the fork is attached to the bz.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 14:27:02 2013
From: jira-events at lists.jboss.org (Wolf-Dieter Fink (JIRA))
Date: Thu, 31 Oct 2013 14:27:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMETA-368) It is not possible to set a
 timeout method for a SingletonBean with the ejb-jar.xml descriptor
In-Reply-To: <JIRA.12509231.1383243922070@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509231.1383243922070@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509231.1383243922070.26972.1383244022082@jira02.app.mwc.hst.phx2.redhat.com>

Wolf-Dieter Fink created JBMETA-368:
---------------------------------------

             Summary: It is not possible to set a timeout method for a SingletonBean with the ejb-jar.xml descriptor
                 Key: JBMETA-368
                 URL: https://issues.jboss.org/browse/JBMETA-368
             Project: JBoss Metadata
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: ejb
            Reporter: Wolf-Dieter Fink
            Assignee: Wolf-Dieter Fink


Regarding to the EJB3.1 specification chapter 4.3.8 it is possible to have a timeout method for a SingletonBean. This can be done by annotation but not with the deployment descriptor.
Also the IllegalStateException contain the wrong message

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 14:31:02 2013
From: jira-events at lists.jboss.org (Wolf-Dieter Fink (JIRA))
Date: Thu, 31 Oct 2013 14:31:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMETA-368) It is not possible to set a
 timeout method for a SingletonBean with the ejb-jar.xml descriptor
In-Reply-To: <JIRA.12509231.1383243922000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509231.1383243922000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509231.1383243922000.26980.1383244262156@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMETA-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Wolf-Dieter Fink updated JBMETA-368:
------------------------------------

    Forum Reference: https://community.jboss.org/thread/234051

    
> It is not possible to set a timeout method for a SingletonBean with the ejb-jar.xml descriptor
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBMETA-368
>                 URL: https://issues.jboss.org/browse/JBMETA-368
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ejb
>            Reporter: Wolf-Dieter Fink
>            Assignee: Wolf-Dieter Fink
>
> Regarding to the EJB3.1 specification chapter 4.3.8 it is possible to have a timeout method for a SingletonBean. This can be done by annotation but not with the deployment descriptor.
> Also the IllegalStateException contain the wrong message

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 15:01:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 31 Oct 2013 15:01:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2410) composite operation
 containing a host op does not get rolled out to all hosts
In-Reply-To: <JIRA.12509099.1383140990000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509099.1383140990000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509099.1383140990000.27027.1383246062292@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12826310#comment-12826310 ] 

RH Bugzilla Integration commented on WFLY-2410:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1015098|https://bugzilla.redhat.com/show_bug.cgi?id=1015098] from ASSIGNED to POST
                
> composite operation containing a host op does not get rolled out to all hosts
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-2410
>                 URL: https://issues.jboss.org/browse/WFLY-2410
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Emanuel Muckenhuber
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.CR1
>
>
> If a composite operation contains an operation targeting the domain as well as a single host, it will only get rolled out to the host specified rather than to the complete domain.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 15:11:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 31 Oct 2013 15:11:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1982) NPE in ModelControllerLock
In-Reply-To: <JIRA.12499783.1378179088000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499783.1378179088000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499783.1378179088000.27034.1383246662308@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12826313#comment-12826313 ] 

RH Bugzilla Integration commented on WFLY-1982:
-----------------------------------------------

Emanuel Muckenhuber <emuckenh at redhat.com> changed the Status of [bug 1024862|https://bugzilla.redhat.com/show_bug.cgi?id=1024862] from NEW to POST
                
> NPE in ModelControllerLock
> --------------------------
>
>                 Key: WFLY-1982
>                 URL: https://issues.jboss.org/browse/WFLY-1982
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.CR1
>
>
> Just noticed this in the host-controller.log while looking into a non-progressing RespawnTestCase:
> 22:23:50,552 ERROR [org.jboss.as.controller.management-operation] (proxy-threads - 1) JBAS014612: Operation ("register-server") failed - address: ([]): java.lang.NullPointerException
> 	at org.jboss.as.controller.ModelControllerLock$Sync.tryAcquire(ModelControllerLock.java:75) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireInterruptibly(AbstractQueuedSynchronizer.java:1220) [rt.jar:1.7.0_15]
> 	at org.jboss.as.controller.ModelControllerLock.lockInterruptibly(ModelControllerLock.java:48) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.acquireLock(ModelControllerImpl.java:582) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.OperationContextImpl.takeWriteLock(OperationContextImpl.java:403) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.OperationContextImpl.acquireControllerLock(OperationContextImpl.java:700) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.host.controller.mgmt.ServerToHostProtocolHandler$ServerReconnectRequestHandler$1$1.execute(ServerToHostProtocolHandler.java:268)
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:610) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:488) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:257) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractControllerService.internalExecute(AbstractControllerService.java:292) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.host.controller.DomainModelControllerService.access$600(DomainModelControllerService.java:148)
> 	at org.jboss.as.host.controller.DomainModelControllerService$InternalExecutor.execute(DomainModelControllerService.java:899)
> 	at org.jboss.as.host.controller.mgmt.ServerToHostProtocolHandler$ServerReconnectRequestHandler$1.execute(ServerToHostProtocolHandler.java:282)
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [wildfly-protocol-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [wildfly-protocol-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_15]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_15]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_15]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 16:12:01 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 31 Oct 2013 16:12:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2426) Easily accessible static
 information describing the release
In-Reply-To: <JIRA.12509239.1383250273667@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509239.1383250273667@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509239.1383250273667.27126.1383250321897@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-2426:
--------------------------------------

             Summary: Easily accessible static information describing the release
                 Key: WFLY-2426
                 URL: https://issues.jboss.org/browse/WFLY-2426
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Server
            Reporter: Brian Stansberry


Tools that work with a WF installation need to identify what they are working with before they can launch or interact with the server. Specifically, they need to know the version. They likely need to know other information as well, such as the name of the software; e.g. whether it is WildFly itself or some other project based on WildFly.

This information should be provided in standard format in a text file in a standard location in the distribution (probably in bin). The text file should be generated as part of the build.

The solution to this issue should consider the requirements of other "identities" that may be based on WildFly. See [1] for the definition of an identity.

The solution to this issue should consider the needs of products based on WildFly and other non-product identities. For example, can the existing product.conf contain the necessary information for a product, with some differently named but largely equivalent file being used in a non-product distribution?

The solution to this issue should consider the implications for the patching tool.

[1] https://community.jboss.org/wiki/LayeredDistributionsAndModulePathOrganization for

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 16:24:01 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 31 Oct 2013 16:24:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2427) Launcher API
In-Reply-To: <JIRA.12509240.1383251005433@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509240.1383251005433@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509240.1383251005433.27138.1383251041917@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-2427:
--------------------------------------

             Summary: Launcher API
                 Key: WFLY-2427
                 URL: https://issues.jboss.org/browse/WFLY-2427
             Project: WildFly
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Server
            Reporter: Brian Stansberry


1) The AS should have some sort of API for launching our processes so tools that want a process have a clear contract instead of having to guess at what's relevant in our ever-changing scripts.

2) We want the main class in our process launch to be what's invoked by java -jar jboss-modules.jar. We don't want java -jar jboss-as-launcher.jar which does some stuff and then calls org.jboss.modules.Main.

3) JBoss Modules itself shouldn't have a lot of the stuff in it that's relevant to an AS launcher API, because many of those things are not relevant to JBoss Modules in a generic sense.

What we could do though is provide a launcher lib that isn't involved at all in our normal boot. Something that would only be used by tools that want to launch a separate, i.e. non-embedded, AS process.

So, some sort of stable configuration API and then a simple

java.lang.Process launch()

Basically, a utility that does the ProcessBuilder stuff that everybody is doing themselves now. 


HOWEVER...

Eclipse-based tools like JBDS use Eclipse APIs for launch and would not use the above launch() method.

So, besides that launch method, look into adding some methods to give the necessary inputs to the Eclipse API be useful. So Eclipse-based tools don't ask it for the process but can still get a standard launch configuration.

I'd only want to do that if those methods would return something generally understandable, but a String or List<String> for classpath, List<String>s for vm/program args, some representation that "-jar jboss-modules.jar" is the way to get the main class -- those all seem generic enough.

Any "which VM" stuff is consider out of scope; choosing the VM is the responsibility of the tool. Options that are not universally supported across VMs and are those a function of VM choice, like whether to use -server, are also out of scope. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 17:16:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 31 Oct 2013 17:16:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1924) An EJB on a WildFly server
 can't call another bean on a second server with remoting and SSL
In-Reply-To: <JIRA.12499177.1377173596000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499177.1377173596000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499177.1377173596000.27171.1383254163481@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12826343#comment-12826343 ] 

RH Bugzilla Integration commented on WFLY-1924:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1025319|https://bugzilla.redhat.com/show_bug.cgi?id=1025319] from NEW to POST
                
> An EJB on a WildFly server can't call another bean on a second server with remoting and SSL
> -------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1924
>                 URL: https://issues.jboss.org/browse/WFLY-1924
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB, Remoting, Security
>    Affects Versions: 8.0.0.Alpha4
>         Environment: WildFly 8.0.0.Beta1-SNAPSHOT from Do 22. Aug 2013, 07:48 UTC
> on Linux with Java 1.7.0_25-b15
>            Reporter: Bernd Koecke
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Beta1
>
>
> I configured two WildFly server, one is the service provider (server), the other one the consumer (client). An EJB on the consumer server tries to call an EJB on the provider server and the remoting connection is secured by SSL. But it doesn't work. I can see the negotiation of the cipher suites and then the communication stops. I get a
> {{javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?}}
> on the provider side. A JavaSE client can call the service provider, but only when SSL_SARTTLS is not set. My current setup is:
> subsystem undertow, default-server:
> {code:xml}
> <https-listener name="defaults" socket-binding="https" security-realm="HttpsRealm"/>
> {code}
> subsystem ejb3:
> {code:xml}
> <remote connector-ref="https-remoting-connector" thread-pool-name="default"/>
> {code}
> Output on the service provider side when the communication stops:
> {noformat}
> [stdout] (default I/O-3) Using SSLEngineImpl.
> [stdout] (default I/O-3) Ignoring unavailable cipher suite: ...
> *** 13 lines more ***
> [stdout] (default I/O-3) Allow unsafe renegotiation: false
> [stdout] (default I/O-3) Allow legacy hello messages: true
> [stdout] (default I/O-3) Is initial handshake: true
> [stdout] (default I/O-3) Is secure renegotiation: false
> [stdout] (default I/O-3) default I/O-3, fatal error: 80: problem unwrapping net record
> [stdout] (default I/O-3) javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
> [stdout] (default I/O-3) default I/O-3, SEND TLSv1 ALERT:  fatal, description = internal_error
> [stdout] (default I/O-3) default I/O-3, WRITE: TLSv1 Alert, length = 2
> [stdout] (default I/O-3) default I/O-3, called closeOutbound()
> [stdout] (default I/O-3) default I/O-3, closeOutboundInternal()
> [stdout] (default I/O-3) [Raw write]: length = 7
> [stdout] (default I/O-3) 0000: 15 03 01 00 02 02 50                               ......P
> {noformat}
> WildFly consumer config
> subsystem remoting, outbound connections:
> {code:xml}
> <remote-outbound-connection name="provider-one-connection" outbound-socket-binding-ref="provider-ejb" security-realm="ProviderOneRealm" protocol="https-remoting">
>   <properties>
>     <property name="SASL_POLICY_NOANONYMOUS" value="false"/>
>   </properties>
> </remote-outbound-connection>
> {code}
> The realms contain the key- and truststores and all passwords are configured.
> The reason for the communication problem comes from the following code.
> The service consumer (or client) WildFly has a remote-outbound-connection in the remoting subsystem config which results in an {{org.jboss.as.remoting.RemoteOutboundConnectionService}}. There is a {{connect()}} method which contains the lines:
> {code:java}
> OptionMap.Builder builder = OptionMap.builder();
> builder.addAll(this.connectionCreationOptions);
> builder.set(SASL_POLICY_NOANONYMOUS, Boolean.FALSE);
> builder.set(SASL_POLICY_NOPLAINTEXT, Boolean.FALSE);
> builder.set(Options.SASL_DISALLOWED_MECHANISMS, Sequence.of(JBOSS_LOCAL_USER));
> builder.set(Options.SSL_ENABLED, true);
> builder.set(Options.SSL_STARTTLS, true);
> return endpoint.connect(uri, builder.getMap(), callbackHandler, sslContext);
> {code}
> My configuration comes from {{this.connectionOptions}} and is overwritten by the defaults. The service consumer will open the connection with {{SSL_STARTTLS==true}}.
> The service provider (or server) WildFly uses an https-listener from the undertow subsystem. Which generates an {{org.wildfly.extension.undertow.HttpsListenerService}}. Method {{startListening(XnioWorker worker,...)}} has the following code:
> {code:java}
> protected void startListening(XnioWorker worker, InetSocketAddress socketAddress, ChannelListener<AcceptingChannel<StreamConnection>> acceptListener) throws IOException {
>     SSLContext sslContext = securityRealm.getValue().getSSLContext();
>     Builder builder = OptionMap.builder().addAll(SERVER_OPTIONS);
>     builder.set(UndertowOptions.MAX_ENTITY_SIZE, maxUploadSize);
>     if (securityRealm.getValue().getSupportedAuthenticationMechanisms().contains(AuthMechanism.CLIENT_CERT)) {
>         builder.set(SSL_CLIENT_AUTH_MODE, REQUESTED);
>     }
>     builder.set(Options.USE_DIRECT_BUFFERS,true);
>     OptionMap combined = builder.getMap();
>     XnioSsl xnioSsl = new JsseXnioSsl(worker.getXnio(), combined, sslContext);
>     sslServer = xnioSsl.createSslConnectionServer(worker, socketAddress, (ChannelListener) acceptListener, combined);
>     sslServer.resumeAccepts();
>     UndertowLogger.ROOT_LOGGER.listenerStarted("HTTPS", getName(), socketAddress);
> }
> {code}
> The OptionMap {{combined}} is used for the {{JsseXnioSsl}} and I can't see a way how to add my own configuration options. The result is that {{SSL_STARTTLS}} is undefined and in {{JsseXnioSsl}} has a method {{connectSsl}} which calls {{openSslConnection}}. There is an event handler build which calls:
> {code:java}
> new JsseSslStreamConnection(connection, JsseSslUtils.createSSLEngine(sslContext, optionMap, destination), socketBufferPool, applicationBufferPool, optionMap.get(Options.SSL_STARTTLS, false));
> {code}
> This sets the flag {{startTls}} of the constructor to false and the member variable {{tls}} in {{org.xnio.ssl.JsseSslStreamConnection}} to true. And when I understand it right, will then the consumer start unencrypted and will only switch to TLS when it is told todo so. But the service provider expectes, because of {{tls==true}}, an encrypted connection right from the beginning. And this generates the above error message/exception. I can reproduce this by using a JavaSE client to call the service provider. This works well when I don't set {{SSL_STARTTLS}} on the client side. But when I set it to {{true}} I get the same behavior like when the client is another WildFly instance.
> [~ctomc] said that on the consumer side in the {{connect()}} method the {{builder.addAll(...)}} should be moved to the end after setting the defaults. Thats the reason for this issue.
> With this solution I can switch off {{SSL_STARTTLS}} on the consumer(client) side.
> Another additional possibility could be to make the provider (server) side configurable that the hard coded options can be overwritten. But I don't know if this fits in the original design.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 19:09:36 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 31 Oct 2013 19:09:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2403) Cannot disable Datasource or
 XADatasource in standalone and domain modes
In-Reply-To: <JIRA.12508938.1383041378000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508938.1383041378000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508938.1383041378000.27210.1383260976145@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12826355#comment-12826355 ] 

RH Bugzilla Integration commented on WFLY-2403:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 970679|https://bugzilla.redhat.com/show_bug.cgi?id=970679] from POST to MODIFIED
                
> Cannot disable Datasource or XADatasource in standalone and domain modes
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2403
>                 URL: https://issues.jboss.org/browse/WFLY-2403
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Stefano Maestri
>            Assignee: Stefano Maestri
>
> Description of problem:
> Cannot disable a Datasource or XADatasource in standalone mode. It's back to enabled state after server reload.
> Version-Release number of selected component (if applicable):
> 6.1
> How reproducible:
> Always
> Steps to Reproduce:
> Use the http management interface or the CLI
> 1.Create a Datasource of XADatasource
> 2.Disable it
> 3.The response indicates a server reload is required
> 4.Execute the reload operation
> Actual results:
> The datasource is back to enabled state
> Expected results:
> The datasource should be in disabled state

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 19:11:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 31 Oct 2013 19:11:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2412) Security Realm and LDAP
 Connection incorrectly available as resourced under
 core-services=management in domain mode.
In-Reply-To: <JIRA.12509108.1383145401000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509108.1383145401000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509108.1383145401000.27221.1383261062301@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12826359#comment-12826359 ] 

RH Bugzilla Integration commented on WFLY-2412:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1024930|https://bugzilla.redhat.com/show_bug.cgi?id=1024930] from POST to MODIFIED
                
> Security Realm and LDAP Connection incorrectly available as resourced under core-services=management in domain mode.
> --------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2412
>                 URL: https://issues.jboss.org/browse/WFLY-2412
>             Project: WildFly
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Security realms and LDAP connections should only be definable under specific hosts in domain mode - the resources for these are currently available in the domain wide code-services=management resource.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 20:35:06 2013
From: jira-events at lists.jboss.org (Divya Mehra (JIRA))
Date: Thu, 31 Oct 2013 20:35:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1721) AUTH and ENCRYPT protocols
 configured with plain text passwords
In-Reply-To: <JIRA.12508425.1382426440000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508425.1382426440000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508425.1382426440000.27352.1383266106873@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Divya Mehra updated JGRP-1721:
------------------------------

    Labels: 620  (was: jdg620_dm jdg62GAblocker)

    
> AUTH and ENCRYPT protocols configured with plain text passwords
> ---------------------------------------------------------------
>
>                 Key: JGRP-1721
>                 URL: https://issues.jboss.org/browse/JGRP-1721
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Martin Gencur
>            Assignee: Bela Ban
>              Labels: 620
>             Fix For: 3.5
>
>
> The following parameters of AUTH protocol are stored as plain text:
> * keystore_password
> The following parameters of ENCRYPT protocol are stored as plain text:
> * store_password
> * key_password
> Example:
> {code}
> <ENCRYPT key_store_name="defaultStore.keystore" store_password="changeit" alias="myKey"/>
> {code}
> Requirements for storing passwords: https://docspace.corp.redhat.com/docs/DOC-131628

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 20:35:07 2013
From: jira-events at lists.jboss.org (Divya Mehra (JIRA))
Date: Thu, 31 Oct 2013 20:35:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1487) AUTH: X509Token
 Authentication is vulnerable to replay attacks
In-Reply-To: <JIRA.12469666.1340962910000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12469666.1340962910000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12469666.1340962910000.27359.1383266107168@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Divya Mehra updated JGRP-1487:
------------------------------

    Labels: 620  (was: jdg620_dm jdg62GAblocker)

    
> AUTH: X509Token Authentication is vulnerable to replay attacks
> --------------------------------------------------------------
>
>                 Key: JGRP-1487
>                 URL: https://issues.jboss.org/browse/JGRP-1487
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.0.9
>            Reporter: sreenivas chinimilli
>            Assignee: Bela Ban
>              Labels: 620
>             Fix For: 3.5
>
>
> In the implementation of X509Token Authentication
> The auth_value is enrypted with the certificate within the keystore and
> during verification encrypted auth value is decrypted with the private key
> compared against the orignial auth value.
> This implementation is prone to replay attacks, that is
> any user with out having any knowledge of the auth value can join the group
> by replaying the enrypted auth value captured in earlier sessions.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 20:35:13 2013
From: jira-events at lists.jboss.org (Divya Mehra (JIRA))
Date: Thu, 31 Oct 2013 20:35:13 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1722) Improve performance of
	ENCRYPT protocol
In-Reply-To: <JIRA.12508426.1382426974000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12508426.1382426974000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508426.1382426974000.27466.1383266113904@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Divya Mehra updated JGRP-1722:
------------------------------

    Labels: 620  (was: jdg620_dm jdg62GAblocker)

    
> Improve performance of ENCRYPT protocol
> ---------------------------------------
>
>                 Key: JGRP-1722
>                 URL: https://issues.jboss.org/browse/JGRP-1722
>             Project: JGroups
>          Issue Type: Enhancement
>    Affects Versions: 3.4
>            Reporter: Martin Gencur
>            Assignee: Bela Ban
>              Labels: 620
>             Fix For: 3.5
>
>
> A stress tests with the following setup showed that performance (reads and writes/sec) is halved when ENCRYPT protocol is enabled:
> Infinispan had distributed sync cache with 2 owners on 4 nodes, no transactions. The stress test used 10 threads on each node accessing 1024 byte entries, no conflicts on keys, 20 % writes, 80 % reads. 
> It would be great if we could improve the performance of ENCRYPT protocol.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 20:39:03 2013
From: jira-events at lists.jboss.org (Divya Mehra (JIRA))
Date: Thu, 31 Oct 2013 20:39:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1716) Regression between 3.2.x and
 3.3.x/3.4.x in Infinispan read simulation
In-Reply-To: <JIRA.12503100.1381850347000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12503100.1381850347000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12503100.1381850347000.27533.1383266343215@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Divya Mehra updated JGRP-1716:
------------------------------

    Labels: dm  (was: jdg620_dm)

    
> Regression between 3.2.x and 3.3.x/3.4.x in Infinispan read simulation
> ----------------------------------------------------------------------
>
>                 Key: JGRP-1716
>                 URL: https://issues.jboss.org/browse/JGRP-1716
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.3, 3.4
>            Reporter: Dan Berindei
>            Assignee: Bela Ban
>              Labels: dm
>             Fix For: 3.4.1, 3.5
>
>         Attachments: benchmark-jgroups.xml, jgroups-udp.pdf, jgroups-udp.xml
>
>
> Comparing JGroups 3.2/3.3/3.4 performance with Radargun, the throughput of reads in scenario simulating Infinispan went down by ~10%. See the attached chart.
> * getall: the get request is sent to single node (randomly picked owner)
> * getfirst: the get requests are sent to 2 nodes with ResponseMode.GET_FIRST - the second response is discarded.
> .h5 Suspects:
> Erik Salter profiled his application and noticed that the message parsing in the UDP receiver thread seemed to slow things down. He wrote a patch that brought his throughput back to 3.2 levels: https://github.com/an1310/JGroups/compare/t_perfhack
> The UDP receiver thread may not tell the whole story, however: in the Radargun tests, performance with his patch was even lower.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 20:44:02 2013
From: jira-events at lists.jboss.org (Joshua Wilson (JIRA))
Date: Thu, 31 Oct 2013 20:44:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-943) XML schema;
 use of elementFormDefault='unqualified'; cannot validate some documents
In-Reply-To: <JIRA.12473954.1346995775000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12473954.1346995775000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12473954.1346995775000.27566.1383266642280@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12826367#comment-12826367 ] 

Joshua Wilson commented on WFLY-943:
------------------------------------

In the version that I use it does NOT have the "p" and I still get the errors.  For examples please refer to any of the Spring related [quickstarts|https://github.com/jboss-developer/jboss-wfk-quickstarts/tree/master/kitchensink-spring-basic] in the JBoss Web Framework Kit quickstarts. 

To be clear you need to Build with Eclipse to see the errors.

Does anyone know if this is being worked?
                
> XML schema; use of elementFormDefault='unqualified'; cannot validate some documents
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-943
>                 URL: https://issues.jboss.org/browse/WFLY-943
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Elias Ross
>             Fix For: 8.0.0.CR1
>
>         Attachments: jboss-deployment-structure.xml
>
>
> When attempting to write a (seemingly) valid jboss-deployment-structure.xml using the schema in ./docs, my document fails to validate.
> This is because of the settings used in the XSD. Have these XSDs been used to validate actual documents? By setting unqualified to 'qualified' then the documents will probably validate.
> $ git grep elementFormDefault..unqualified
> jboss-deployment-dependencies-1_0.xsd:            elementFormDefault="unqualified"
> jboss-deployment-structure-1_0.xsd:            elementFormDefault="unqualified"
> jboss-deployment-structure-1_1.xsd:            elementFormDefault="unqualified"
> jboss-deployment-structure-1_2.xsd:            elementFormDefault="unqualified"
> jboss-ejb-client_1_0.xsd:            elementFormDefault="unqualified"
> jboss-ejb-client_1_1.xsd:            elementFormDefault="unqualified"
> jboss-ejb-client_1_2.xsd:            elementFormDefault="unqualified"
> jboss-jpa_1_0.xsd:  elementFormDefault="unqualified" 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 20:48:02 2013
From: jira-events at lists.jboss.org (Joshua Wilson (JIRA))
Date: Thu, 31 Oct 2013 20:48:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-943) XML schema;
 use of elementFormDefault='unqualified'; cannot validate some documents
In-Reply-To: <JIRA.12473954.1346995775000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12473954.1346995775000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12473954.1346995775000.27573.1383266882215@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12826368#comment-12826368 ] 

Joshua Wilson commented on WFLY-943:
------------------------------------

I guess someone has worked it because I just found that if you use `<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:2.0">` it works. 

Thanks team! :)
                
> XML schema; use of elementFormDefault='unqualified'; cannot validate some documents
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-943
>                 URL: https://issues.jboss.org/browse/WFLY-943
>             Project: WildFly
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Elias Ross
>             Fix For: 8.0.0.CR1
>
>         Attachments: jboss-deployment-structure.xml
>
>
> When attempting to write a (seemingly) valid jboss-deployment-structure.xml using the schema in ./docs, my document fails to validate.
> This is because of the settings used in the XSD. Have these XSDs been used to validate actual documents? By setting unqualified to 'qualified' then the documents will probably validate.
> $ git grep elementFormDefault..unqualified
> jboss-deployment-dependencies-1_0.xsd:            elementFormDefault="unqualified"
> jboss-deployment-structure-1_0.xsd:            elementFormDefault="unqualified"
> jboss-deployment-structure-1_1.xsd:            elementFormDefault="unqualified"
> jboss-deployment-structure-1_2.xsd:            elementFormDefault="unqualified"
> jboss-ejb-client_1_0.xsd:            elementFormDefault="unqualified"
> jboss-ejb-client_1_1.xsd:            elementFormDefault="unqualified"
> jboss-ejb-client_1_2.xsd:            elementFormDefault="unqualified"
> jboss-jpa_1_0.xsd:  elementFormDefault="unqualified" 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 20:58:02 2013
From: jira-events at lists.jboss.org (Joshua Wilson (JIRA))
Date: Thu, 31 Oct 2013 20:58:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMETA-367) CLONE - XML schema;
 use of elementFormDefault='unqualified'; cannot validate some documents
In-Reply-To: <JIRA.12498845.1376905638000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498845.1376905638000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498845.1376905638000.27589.1383267482244@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBMETA-367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12826369#comment-12826369 ] 

Joshua Wilson commented on JBMETA-367:
--------------------------------------

I just found that if you use `<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:2.0">` it works. 
                
> CLONE - XML schema; use of elementFormDefault='unqualified'; cannot validate some documents
> -------------------------------------------------------------------------------------------
>
>                 Key: JBMETA-367
>                 URL: https://issues.jboss.org/browse/JBMETA-367
>             Project: JBoss Metadata
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Elias Ross
>
> When attempting to write a (seemingly) valid jboss-deployment-structure.xml using the schema in ./docs, my document fails to validate.
> This is because of the settings used in the XSD. Have these XSDs been used to validate actual documents? By setting unqualified to 'qualified' then the documents will probably validate.
> $ git grep elementFormDefault..unqualified
> jboss-deployment-dependencies-1_0.xsd:            elementFormDefault="unqualified"
> jboss-deployment-structure-1_0.xsd:            elementFormDefault="unqualified"
> jboss-deployment-structure-1_1.xsd:            elementFormDefault="unqualified"
> jboss-deployment-structure-1_2.xsd:            elementFormDefault="unqualified"
> jboss-ejb-client_1_0.xsd:            elementFormDefault="unqualified"
> jboss-ejb-client_1_1.xsd:            elementFormDefault="unqualified"
> jboss-ejb-client_1_2.xsd:            elementFormDefault="unqualified"
> jboss-jpa_1_0.xsd:  elementFormDefault="unqualified" 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Oct 31 23:25:02 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 31 Oct 2013 23:25:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2428) MDBs should use the full
 identifier of the resource adapter
In-Reply-To: <JIRA.12509250.1383276226476@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12509250.1383276226476@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509250.1383276226476.27626.1383276302019@jira02.app.mwc.hst.phx2.redhat.com>

Jesper Pedersen created WFLY-2428:
-------------------------------------

             Summary: MDBs should use the full identifier of the resource adapter
                 Key: WFLY-2428
                 URL: https://issues.jboss.org/browse/WFLY-2428
             Project: WildFly
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: EJB
    Affects Versions: 8.0.0.CR1
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 8.0.0.CR1


The .rar suffix shouldn't be stripped anymore, as the resource adapters are registered under their full name.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

