[JBoss JIRA] (WFLY-91) Impossible to use "reload" MDR operation in testsuite run
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-91?page=com.atlassian.jira.plugin.sy... ]
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
12 years, 9 months
[JBoss JIRA] (WFLY-84) Jasper using wrong ProtectionDomain for compiled JSP
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-84?page=com.atlassian.jira.plugin.sy... ]
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
12 years, 9 months
[JBoss JIRA] (WFLY-89) Spurious server dirs created when directory-grouping="by-type" is set
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-89?page=com.atlassian.jira.plugin.sy... ]
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
12 years, 9 months
[JBoss JIRA] (WFLY-118) JGroups diag failure "failed sending diag rsp to /10.16.88.172:47231: java.io.IOException: Message too long"
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-118?page=com.atlassian.jira.plugin.s... ]
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@2607} org.infinispan.transaction.synchronization.SynchronizationAdapter@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
12 years, 9 months
[JBoss JIRA] (WFLY-145) User insn't properly informed that APR is used
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-145?page=com.atlassian.jira.plugin.s... ]
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
12 years, 9 months
[JBoss JIRA] (WFLY-131) Seam2Processor will not have permissions to its added resource loader
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-131?page=com.atlassian.jira.plugin.s... ]
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
12 years, 9 months
[JBoss JIRA] (WFLY-143) Improve testing of Infinispan subsystem management features
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-143?page=com.atlassian.jira.plugin.s... ]
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
12 years, 9 months