[JBoss JIRA] (WFLY-6038) Can not deploy a @ConnectionFactoryDefinition if the RA has more <connection-definitions>
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-6038?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil reassigned WFLY-6038:
---------------------------------
Assignee: Lin Gao (was: Jesper Pedersen)
> Can not deploy a @ConnectionFactoryDefinition if the RA has more <connection-definitions>
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-6038
> URL: https://issues.jboss.org/browse/WFLY-6038
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 10.0.0.CR5
> Reporter: Jeff Mesnil
> Assignee: Lin Gao
>
> Steps to reproduce:
> * add a 2nd connection-defintion to testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jca/deployment/ra.xml:
> {noformat}
> <connection-definition>
> <managedconnectionfactory-class>org.jboss.as.test.integration.jca.rar.MultipleManagedConnectionFactory2</managedconnectionfactory-class>
> <connectionfactory-interface>org.jboss.as.test.integration.jca.rar.MultipleConnectionFactory2</connectionfactory-interface>
> <connectionfactory-impl-class>org.jboss.as.test.integration.jca.rar.MultipleConnectionFactory2Impl</connectionfactory-impl-class>
> <connection-interface>org.jboss.as.test.integration.jca.rar.MultipleConnection2</connection-interface>
> <connection-impl-class>org.jboss.as.test.integration.jca.rar.MultipleConnection2Impl</connection-impl-class>
> </connection-definition>
> {noformat}
> * Run the WarServletDeploymentTestCase test
> => it fails because the ConnectionFactoryDefinition objects are no longer deployed.
> After debugging, the test fails because the deployed connection definitions are not activated.
> The code at org/jboss/as/connector/services/resourceadapters/ResourceAdapterActivatorService.java:232 is preventing the activation and looks suspicious.
> It expects that all the MCF in the RA (raMcfClasses) must *all* be in the activation (ijMcfClasses).
> With a 2nd <connection-definition> in the RA, it is no longer the case (as the activation only contains a single MCF (MultipleManagedConnectionFactory1).
> If I change the code so that it checks that all the MCF in the activations are in the RA, the test passes again.
> This issue is preventing me to reuse the code handling the @ConnectionFactoryDefinition to support the @JMSConnectionFactoryDefinition (my JMS RA defines 3 MXF for generic/queue/topic CFs but my activation only defines a single MCF for a @JMSConnectionFactoryDefinition).
> I've not run it but the same issue is likely for admin objects too (the code in checkActivation is similar)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-6038) Can not deploy a @ConnectionFactoryDefinition if the RA has more <connection-definitions>
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-6038?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil updated WFLY-6038:
------------------------------
Description:
Steps to reproduce:
* add a 2nd connection-defintion to testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jca/deployment/ra.xml:
{noformat}
<connection-definition>
<managedconnectionfactory-class>org.jboss.as.test.integration.jca.rar.MultipleManagedConnectionFactory2</managedconnectionfactory-class>
<connectionfactory-interface>org.jboss.as.test.integration.jca.rar.MultipleConnectionFactory2</connectionfactory-interface>
<connectionfactory-impl-class>org.jboss.as.test.integration.jca.rar.MultipleConnectionFactory2Impl</connectionfactory-impl-class>
<connection-interface>org.jboss.as.test.integration.jca.rar.MultipleConnection2</connection-interface>
<connection-impl-class>org.jboss.as.test.integration.jca.rar.MultipleConnection2Impl</connection-impl-class>
</connection-definition>
{noformat}
* Run the WarServletDeploymentTestCase test
=> it fails because the ConnectionFactoryDefinition objects are no longer deployed.
After debugging, the test fails because the deployed connection definitions are not activated.
The code at org/jboss/as/connector/services/resourceadapters/ResourceAdapterActivatorService.java:232 is preventing the activation and looks suspicious.
It expects that all the MCF in the RA (raMcfClasses) must *all* be in the activation (ijMcfClasses).
With a 2nd <connection-definition> in the RA, it is no longer the case (as the activation only contains a single MCF (MultipleManagedConnectionFactory1).
If I change the code so that it checks that all the MCF in the activations are in the RA, the test passes again.
This issue is preventing me to reuse the code handling the @ConnectionFactoryDefinition to support the @JMSConnectionFactoryDefinition (my JMS RA defines 3 MCF for generic/queue/topic CFs but my activation only defines a single MCF for a @JMSConnectionFactoryDefinition).
I've not run it but the same issue is likely for admin objects too (the code in checkActivation is similar)
was:
Steps to reproduce:
* add a 2nd connection-defintion to testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jca/deployment/ra.xml:
{noformat}
<connection-definition>
<managedconnectionfactory-class>org.jboss.as.test.integration.jca.rar.MultipleManagedConnectionFactory2</managedconnectionfactory-class>
<connectionfactory-interface>org.jboss.as.test.integration.jca.rar.MultipleConnectionFactory2</connectionfactory-interface>
<connectionfactory-impl-class>org.jboss.as.test.integration.jca.rar.MultipleConnectionFactory2Impl</connectionfactory-impl-class>
<connection-interface>org.jboss.as.test.integration.jca.rar.MultipleConnection2</connection-interface>
<connection-impl-class>org.jboss.as.test.integration.jca.rar.MultipleConnection2Impl</connection-impl-class>
</connection-definition>
{noformat}
* Run the WarServletDeploymentTestCase test
=> it fails because the ConnectionFactoryDefinition objects are no longer deployed.
After debugging, the test fails because the deployed connection definitions are not activated.
The code at org/jboss/as/connector/services/resourceadapters/ResourceAdapterActivatorService.java:232 is preventing the activation and looks suspicious.
It expects that all the MCF in the RA (raMcfClasses) must *all* be in the activation (ijMcfClasses).
With a 2nd <connection-definition> in the RA, it is no longer the case (as the activation only contains a single MCF (MultipleManagedConnectionFactory1).
If I change the code so that it checks that all the MCF in the activations are in the RA, the test passes again.
This issue is preventing me to reuse the code handling the @ConnectionFactoryDefinition to support the @JMSConnectionFactoryDefinition (my JMS RA defines 3 MXF for generic/queue/topic CFs but my activation only defines a single MCF for a @JMSConnectionFactoryDefinition).
I've not run it but the same issue is likely for admin objects too (the code in checkActivation is similar)
> Can not deploy a @ConnectionFactoryDefinition if the RA has more <connection-definitions>
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-6038
> URL: https://issues.jboss.org/browse/WFLY-6038
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 10.0.0.CR5
> Reporter: Jeff Mesnil
> Assignee: Lin Gao
>
> Steps to reproduce:
> * add a 2nd connection-defintion to testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jca/deployment/ra.xml:
> {noformat}
> <connection-definition>
> <managedconnectionfactory-class>org.jboss.as.test.integration.jca.rar.MultipleManagedConnectionFactory2</managedconnectionfactory-class>
> <connectionfactory-interface>org.jboss.as.test.integration.jca.rar.MultipleConnectionFactory2</connectionfactory-interface>
> <connectionfactory-impl-class>org.jboss.as.test.integration.jca.rar.MultipleConnectionFactory2Impl</connectionfactory-impl-class>
> <connection-interface>org.jboss.as.test.integration.jca.rar.MultipleConnection2</connection-interface>
> <connection-impl-class>org.jboss.as.test.integration.jca.rar.MultipleConnection2Impl</connection-impl-class>
> </connection-definition>
> {noformat}
> * Run the WarServletDeploymentTestCase test
> => it fails because the ConnectionFactoryDefinition objects are no longer deployed.
> After debugging, the test fails because the deployed connection definitions are not activated.
> The code at org/jboss/as/connector/services/resourceadapters/ResourceAdapterActivatorService.java:232 is preventing the activation and looks suspicious.
> It expects that all the MCF in the RA (raMcfClasses) must *all* be in the activation (ijMcfClasses).
> With a 2nd <connection-definition> in the RA, it is no longer the case (as the activation only contains a single MCF (MultipleManagedConnectionFactory1).
> If I change the code so that it checks that all the MCF in the activations are in the RA, the test passes again.
> This issue is preventing me to reuse the code handling the @ConnectionFactoryDefinition to support the @JMSConnectionFactoryDefinition (my JMS RA defines 3 MCF for generic/queue/topic CFs but my activation only defines a single MCF for a @JMSConnectionFactoryDefinition).
> I've not run it but the same issue is likely for admin objects too (the code in checkActivation is similar)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-6038) Can not deploy a @ConnectionFactoryDefinition if the RA has more <connection-definitions>
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-6038?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil updated WFLY-6038:
------------------------------
Description:
Steps to reproduce:
* add a 2nd connection-defintion to testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jca/deployment/ra.xml:
{noformat}
<connection-definition>
<managedconnectionfactory-class>org.jboss.as.test.integration.jca.rar.MultipleManagedConnectionFactory2</managedconnectionfactory-class>
<connectionfactory-interface>org.jboss.as.test.integration.jca.rar.MultipleConnectionFactory2</connectionfactory-interface>
<connectionfactory-impl-class>org.jboss.as.test.integration.jca.rar.MultipleConnectionFactory2Impl</connectionfactory-impl-class>
<connection-interface>org.jboss.as.test.integration.jca.rar.MultipleConnection2</connection-interface>
<connection-impl-class>org.jboss.as.test.integration.jca.rar.MultipleConnection2Impl</connection-impl-class>
</connection-definition>
{noformat}
* Run the WarServletDeploymentTestCase test
=> it fails because the ConnectionFactoryDefinition objects are no longer deployed.
After debugging, the test fails because the deployed connection definitions are not activated.
The code at org/jboss/as/connector/services/resourceadapters/ResourceAdapterActivatorService.java:232 is preventing the activation and looks suspicious.
It expects that all the MCF in the RA (raMcfClasses) must *all* be in the activation (ijMcfClasses).
With a 2nd <connection-definition> in the RA, it is no longer the case (as the activation only contains a single MCF (MultipleManagedConnectionFactory1).
If I change the code so that it checks that all the MCF in the activations are in the RA, the test passes again.
This issue is preventing me to reuse the code handling the @ConnectionFactoryDefinition to support the @JMSConnectionFactoryDefinition (my JMS RA defines 3 MCF for generic/queue/topic CFs but my activation only defines a single MCF per @JMSConnectionFactoryDefinition).
I've not run it but the same issue is likely for admin objects too (the code in checkActivation is similar)
was:
Steps to reproduce:
* add a 2nd connection-defintion to testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jca/deployment/ra.xml:
{noformat}
<connection-definition>
<managedconnectionfactory-class>org.jboss.as.test.integration.jca.rar.MultipleManagedConnectionFactory2</managedconnectionfactory-class>
<connectionfactory-interface>org.jboss.as.test.integration.jca.rar.MultipleConnectionFactory2</connectionfactory-interface>
<connectionfactory-impl-class>org.jboss.as.test.integration.jca.rar.MultipleConnectionFactory2Impl</connectionfactory-impl-class>
<connection-interface>org.jboss.as.test.integration.jca.rar.MultipleConnection2</connection-interface>
<connection-impl-class>org.jboss.as.test.integration.jca.rar.MultipleConnection2Impl</connection-impl-class>
</connection-definition>
{noformat}
* Run the WarServletDeploymentTestCase test
=> it fails because the ConnectionFactoryDefinition objects are no longer deployed.
After debugging, the test fails because the deployed connection definitions are not activated.
The code at org/jboss/as/connector/services/resourceadapters/ResourceAdapterActivatorService.java:232 is preventing the activation and looks suspicious.
It expects that all the MCF in the RA (raMcfClasses) must *all* be in the activation (ijMcfClasses).
With a 2nd <connection-definition> in the RA, it is no longer the case (as the activation only contains a single MCF (MultipleManagedConnectionFactory1).
If I change the code so that it checks that all the MCF in the activations are in the RA, the test passes again.
This issue is preventing me to reuse the code handling the @ConnectionFactoryDefinition to support the @JMSConnectionFactoryDefinition (my JMS RA defines 3 MCF for generic/queue/topic CFs but my activation only defines a single MCF for a @JMSConnectionFactoryDefinition).
I've not run it but the same issue is likely for admin objects too (the code in checkActivation is similar)
> Can not deploy a @ConnectionFactoryDefinition if the RA has more <connection-definitions>
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-6038
> URL: https://issues.jboss.org/browse/WFLY-6038
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 10.0.0.CR5
> Reporter: Jeff Mesnil
> Assignee: Lin Gao
>
> Steps to reproduce:
> * add a 2nd connection-defintion to testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jca/deployment/ra.xml:
> {noformat}
> <connection-definition>
> <managedconnectionfactory-class>org.jboss.as.test.integration.jca.rar.MultipleManagedConnectionFactory2</managedconnectionfactory-class>
> <connectionfactory-interface>org.jboss.as.test.integration.jca.rar.MultipleConnectionFactory2</connectionfactory-interface>
> <connectionfactory-impl-class>org.jboss.as.test.integration.jca.rar.MultipleConnectionFactory2Impl</connectionfactory-impl-class>
> <connection-interface>org.jboss.as.test.integration.jca.rar.MultipleConnection2</connection-interface>
> <connection-impl-class>org.jboss.as.test.integration.jca.rar.MultipleConnection2Impl</connection-impl-class>
> </connection-definition>
> {noformat}
> * Run the WarServletDeploymentTestCase test
> => it fails because the ConnectionFactoryDefinition objects are no longer deployed.
> After debugging, the test fails because the deployed connection definitions are not activated.
> The code at org/jboss/as/connector/services/resourceadapters/ResourceAdapterActivatorService.java:232 is preventing the activation and looks suspicious.
> It expects that all the MCF in the RA (raMcfClasses) must *all* be in the activation (ijMcfClasses).
> With a 2nd <connection-definition> in the RA, it is no longer the case (as the activation only contains a single MCF (MultipleManagedConnectionFactory1).
> If I change the code so that it checks that all the MCF in the activations are in the RA, the test passes again.
> This issue is preventing me to reuse the code handling the @ConnectionFactoryDefinition to support the @JMSConnectionFactoryDefinition (my JMS RA defines 3 MCF for generic/queue/topic CFs but my activation only defines a single MCF per @JMSConnectionFactoryDefinition).
> I've not run it but the same issue is likely for admin objects too (the code in checkActivation is similar)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-6038) Can not deploy a @ConnectionFactoryDefinition if the RA has more <connection-definitions>
by Jeff Mesnil (JIRA)
Jeff Mesnil created WFLY-6038:
---------------------------------
Summary: Can not deploy a @ConnectionFactoryDefinition if the RA has more <connection-definitions>
Key: WFLY-6038
URL: https://issues.jboss.org/browse/WFLY-6038
Project: WildFly
Issue Type: Bug
Components: JCA
Affects Versions: 10.0.0.CR5
Reporter: Jeff Mesnil
Assignee: Jesper Pedersen
Steps to reproduce:
* add a 2nd connection-defintion to testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jca/deployment/ra.xml:
{noformat}
<connection-definition>
<managedconnectionfactory-class>org.jboss.as.test.integration.jca.rar.MultipleManagedConnectionFactory2</managedconnectionfactory-class>
<connectionfactory-interface>org.jboss.as.test.integration.jca.rar.MultipleConnectionFactory2</connectionfactory-interface>
<connectionfactory-impl-class>org.jboss.as.test.integration.jca.rar.MultipleConnectionFactory2Impl</connectionfactory-impl-class>
<connection-interface>org.jboss.as.test.integration.jca.rar.MultipleConnection2</connection-interface>
<connection-impl-class>org.jboss.as.test.integration.jca.rar.MultipleConnection2Impl</connection-impl-class>
</connection-definition>
{noformat}
* Run the WarServletDeploymentTestCase test
=> it fails because the ConnectionFactoryDefinition objects are no longer deployed.
After debugging, the test fails because the deployed connection definitions are not activated.
The code at org/jboss/as/connector/services/resourceadapters/ResourceAdapterActivatorService.java:232 is preventing the activation and looks suspicious.
It expects that all the MCF in the RA (raMcfClasses) must *all* be in the activation (ijMcfClasses).
With a 2nd <connection-definition> in the RA, it is no longer the case (as the activation only contains a single MCF (MultipleManagedConnectionFactory1).
If I change the code so that it checks that all the MCF in the activations are in the RA, the test passes again.
This issue is preventing me to reuse the code handling the @ConnectionFactoryDefinition to support the @JMSConnectionFactoryDefinition (my JMS RA defines 3 MXF for generic/queue/topic CFs but my activation only defines a single MCF for a @JMSConnectionFactoryDefinition).
I've not run it but the same issue is likely for admin objects too (the code in checkActivation is similar)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-5480) SPEC JMS 2007 benchmark fails with AMQ214013: Failed to decode packet
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-5480?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-5480:
-------------------------------
Fix Version/s: 10.0.0.Final
> SPEC JMS 2007 benchmark fails with AMQ214013: Failed to decode packet
> ---------------------------------------------------------------------
>
> Key: WFLY-5480
> URL: https://issues.jboss.org/browse/WFLY-5480
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Ondřej Kalman
> Assignee: Flavia Rainone
> Priority: Blocker
> Fix For: 10.0.0.Final
>
>
> But I have another problem, when I removed trace logs from config I'm not able to run benchmark on localhost to the end, because clients starts getting :
> AMQ214013: Failed to decode packet
> java.lang.IndexOutOfBoundsException: readerIndex: 2130706436 (expected: 0 <= readerIndex <= writerIndex(2943))
> at io.netty.buffer.AbstractByteBuf.readerIndex(AbstractByteBuf.java:73)
> at io.netty.buffer.WrappedByteBuf.readerIndex(WrappedByteBuf.java:99)
> at org.apache.activemq.artemis.core.buffers.impl.ChannelBufferWrapper.readerIndex(ChannelBufferWrapper.java:405)
> at org.apache.activemq.artemis.core.message.impl.MessageImpl.decode(MessageImpl.java:1052)
> at org.apache.activemq.artemis.core.message.impl.MessageImpl.decodeFromBuffer(MessageImpl.java:459)
> at org.apache.activemq.artemis.core.protocol.core.impl.wireformat.SessionReceiveMessage.decode(SessionReceiveMessage.java:94)
> at org.apache.activemq.artemis.core.protocol.ClientPacketDecoder.decode(ClientPacketDecoder.java:42)
> at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:371)
> at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$DelegatingBufferHandler.bufferReceived(ClientSessionFactoryImpl.java:1374)
> at org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:73)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:339)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:324)
> at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:242)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:339)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:324)
> at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:847)
> at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteCha
> nnel.java:131)
> at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:511)
> at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:468)
> at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:382)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:354)
> at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:111)
> at java.lang.Thread.run(Thread.java:745)
> and
> Thread-9 (ActiveMQ-client-global-threads-1266561810): Uncaught exception.
> java.lang.NumberFormatException: null
> at java.lang.Integer.parseInt(Integer.java:542)
> at java.lang.Integer.valueOf(Integer.java:766)
> at org.apache.activemq.artemis.utils.TypedProperties.getIntProperty(TypedProperties.java:280)
> at org.apache.activemq.artemis.core.message.impl.MessageImpl.getIntProperty(MessageImpl.java:811)
> at org.apache.activemq.artemis.jms.client.ActiveMQMessage.getIntProperty(ActiveMQMessage.java:578)
> at org.spec.jms.agents.SPECWorkerThread.receivedMessage(SPECWorkerThread.java:849)
> at org.spec.jms.agents.SPECWorkerThread.onMessage(SPECWorkerThread.java:820)
> at org.apache.activemq.artemis.jms.client.JMSMessageListenerWrapper.onMessage(JMSMessageListenerWrapper.java:100)
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1089)
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:47)
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1224)
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:105)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Thread-3 (ActiveMQ-client-global-threads-1266561810): Uncaught exception.
> javax.jms.IllegalStateException: AMQ119027: Could not find reference on consumer ID=0, messageId = 104,833 queue = 127\.0\.0\.1_VM1_SPAgent7_0.SP_CallForOffersEH_7_EHID_1PF0
> at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:410)
> at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.sendACK(ActiveMQSessionContext.java:461)
> at org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.acknowledge(ClientSessionImpl.java:765)
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.doAck(ClientConsumerImpl.java:1212)
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.flushAcks(ClientConsumerImpl.java:830)
> at org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.flushAcks(ClientSessionImpl.java:1852)
> at org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.commit(ClientSessionImpl.java:501)
> at org.apache.activemq.artemis.core.client.impl.DelegatingSession.commit(DelegatingSession.java:159)
> at org.apache.activemq.artemis.jms.client.ActiveMQSession.commit(ActiveMQSession.java:218)
> at org.spec.jms.eventhandler.sp.SP_CallForOffersEH.handleMessage(SP_CallForOffersEH.java:306)
> at org.spec.jms.agents.SPECWorkerThread.onMessage(SPECWorkerThread.java:821)
> at org.apache.activemq.artemis.jms.client.JMSMessageListenerWrapper.onMessage(JMSMessageListenerWrapper.java:100)
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1089)
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:47)
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1224)
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:105)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecut
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFCORE-1277) Embed-server from CLI launch shows twice prompt string
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1277?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1277:
------------------------------------------
Just an FYI: I observed this really minor thing with 0.66.3 in a kind of franken-build of EAP 7: WFCORE-1315
I regard this as largely OT to this JIRA; I just wanted to let you know. I suspect the issue, to the extent there is one, is in the CLI itself and not aesh.
The stuff discussed in this JIRA looked good.
> Embed-server from CLI launch shows twice prompt string
> ------------------------------------------------------
>
> Key: WFCORE-1277
> URL: https://issues.jboss.org/browse/WFCORE-1277
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.0.5.Final
> Reporter: Chao Wang
> Assignee: Ståle Pedersen
> Priority: Blocker
> Fix For: 2.0.8.Final
>
>
> {noformat}
> When I launch an embed-server from CLI, it displays twice [standalone@embedded /] [standalone@embedded /] for the first time.
> [wangc@dhcp-128-40 wildfly-10.0.0.Final-SNAPSHOT]$ sh 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 /] embed-server
> [standalone@embedded /] [standalone@embedded /] ls
> core-service launch-type=EMBEDDED product-version=undefined
> deployment management-major-version=4 profile-name=undefined
> deployment-overlay management-micro-version=0 release-codename=Kenny
> extension management-minor-version=0 release-version=2.0.5.Final
> interface name=dhcp-128-40 running-mode=ADMIN_ONLY
> path namespaces=[] schema-locations=[]
> socket-binding-group organization=undefined server-state=running
> subsystem process-type=Server suspend-state=RUNNING
> system-property product-name=undefined uuid=8c4ede2f-8e14-48bf-9eaf-73947e23edcf
> [standalone@embedded /] quit
> {noformat}
> This does not happen in 2.0.4.Final.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFCORE-1315) Double prompt when connecting to a new HC
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1315?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1315:
-------------------------------------
Priority: Optional (was: Minor)
> Double prompt when connecting to a new HC
> -----------------------------------------
>
> Key: WFCORE-1315
> URL: https://issues.jboss.org/browse/WFCORE-1315
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.0.8.Final
> Reporter: Brian Stansberry
> Assignee: Alexey Loubyansky
> Priority: Optional
>
> I observed this with 0.66.3 in a kind of franken-build of EAP 7. The logical equivalent would be 2.0.8.Final once WFCORE-1277 is fixed.
> {code}
> [domain@localhost:9990 core-service=discovery-options] connect 127.0.0.1:29990
> [disconnected core-service=discovery-options] [domain@127.0.0.1:29990 core-service=discovery-options] cd /
> [domain@127.0.0.1:29990 /]
> {code}
> Before the first line I had killed the HC at localhost:9990, so then I wanted to connect to another HC. Got a double prompt.
> Not a big deal, but I wanted to record it.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFCORE-1315) Double prompt when connecting to a new HC
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1315:
----------------------------------------
Summary: Double prompt when connecting to a new HC
Key: WFCORE-1315
URL: https://issues.jboss.org/browse/WFCORE-1315
Project: WildFly Core
Issue Type: Bug
Components: CLI
Affects Versions: 2.0.8.Final
Reporter: Brian Stansberry
Assignee: Alexey Loubyansky
Priority: Minor
I observed this with 0.66.3 in a kind of franken-build of EAP 7. The logical equivalent would be 2.0.8.Final once WFCORE-1277 is fixed.
{code}
[domain@localhost:9990 core-service=discovery-options] connect 127.0.0.1:29990
[disconnected core-service=discovery-options] [domain@127.0.0.1:29990 core-service=discovery-options] cd /
[domain@127.0.0.1:29990 /]
{code}
Before the first line I had killed the HC at localhost:9990, so then I wanted to connect to another HC. Got a double prompt.
Not a big deal, but I wanted to record it.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-2717) Exceptions returnd from remote ejb calls create ClassCastException
by Dirk Weil (JIRA)
[ https://issues.jboss.org/browse/WFLY-2717?page=com.atlassian.jira.plugin.... ]
Dirk Weil edited comment on WFLY-2717 at 1/20/16 10:41 AM:
-----------------------------------------------------------
I switched to WildFly version 9.0.2 - without change ...
Meanwhile - beause we desperately need a solution, I developed a (very quick and dirty) workaround by changing org.jboss.ejb.client.remoting.ProtocolMessageHandler#readAttachments:
{code:java}
protected Map<String, Object> readAttachments(final ObjectInput input) throws IOException, ClassNotFoundException
{
final int numAttachments = input.readByte();
if (numAttachments == 0)
{
return null;
}
final Map<String, Object> attachments = new HashMap<String, Object>(numAttachments);
for (int i = 0; i < numAttachments; i++)
{
try
{
// read the key
// final String key = (String) input.readObject();
final String key = input.readObject().toString();
// read the attachment value
final Object val = input.readObject();
attachments.put(key, val);
}
catch (StreamCorruptedException | ClassCastException e)
{
Logger logger = Logger.getLogger(this.getClass().getName());
logger.warning("Workaround for https://issues.jboss.org/browse/WFLY-2717 - ignoring exception while reading attachments: " + e);
break;
}
}
return attachments;
}
{code}
Now the excpected exceptions are returned to the client, but th real solution must go beyond just ignoring exception, I guess ...
was (Author: dweil):
I switched to WildFly version 9.0.2 - without change ...
Meanwhile - beause we desperately need a solution, I developed a (very quick and dirty) workaround by changing
{code:java}
org.jboss.ejb.client.remoting.ProtocolMessageHandler#readAttachments
{code}
:
{code:java}
protected Map<String, Object> readAttachments(final ObjectInput input) throws IOException, ClassNotFoundException
{
final int numAttachments = input.readByte();
if (numAttachments == 0)
{
return null;
}
final Map<String, Object> attachments = new HashMap<String, Object>(numAttachments);
for (int i = 0; i < numAttachments; i++)
{
try
{
// read the key
// final String key = (String) input.readObject();
final String key = input.readObject().toString();
// read the attachment value
final Object val = input.readObject();
attachments.put(key, val);
}
catch (StreamCorruptedException | ClassCastException e)
{
Logger logger = Logger.getLogger(this.getClass().getName());
logger.warning("Workaround for https://issues.jboss.org/browse/WFLY-2717 - ignoring exception while reading attachments: " + e);
break;
}
}
return attachments;
}
{code}
Now the excpected exception are returned to the client, but th real solution must go beyond just ignoring exception, I guess ...
> Exceptions returnd from remote ejb calls create ClassCastException
> ------------------------------------------------------------------
>
> Key: WFLY-2717
> URL: https://issues.jboss.org/browse/WFLY-2717
> Project: WildFly
> Issue Type: Bug
> Components: Remoting
> Affects Versions: 8.0.0.CR1, 8.1.0.Final
> Environment: Windows, Java 1.7.0_40
> Reporter: Dirk Weil
> Assignee: Panagiotis Sotiropoulos
>
> An exception thrown by an ejb is not marshalled correctly to the calling remote client. Instead a ClassCastException is raised.
> Stack trace on client:
> {noformat}
> java.lang.AssertionError:
> Expected: class java.lang.UnsupportedOperationException as (in)directly causing exception
> but: was <java.lang.ClassCastException: java.lang.Class cannot be cast to java.lang.String>
> Stacktrace was: java.lang.ClassCastException: java.lang.Class cannot be cast to java.lang.String
> at org.jboss.ejb.client.remoting.ProtocolMessageHandler.readAttachments(ProtocolMessageHandler.java:55)
> at org.jboss.ejb.client.remoting.InvocationExceptionResponseHandler$MethodInvocationExceptionResultProducer.getResult(InvocationExceptionResponseHandler.java:82)
> 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 com.sun.proxy.$Proxy6.getException(Unknown Source)
> at de.gedoplan.beantrial.wildflyejbremote.DemoTest.testGetException(DemoTest.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: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.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:168)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> 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.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)
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
> at org.junit.Assert.assertThat(Assert.java:865)
> at org.junit.Assert.assertThat(Assert.java:832)
> at org.junit.rules.ExpectedException.handleException(ExpectedException.java:198)
> at org.junit.rules.ExpectedException.access$500(ExpectedException.java:85)
> at org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:177)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> 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.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)
> {noformat}
> Stack trace on server:
> {noformat}
> 14:50:47,688 ERROR [org.jboss.as.ejb3.invocation] (EJB default - 3) JBAS014134: EJB Invocation failed on component DemoBean for method public abstract void de.gedoplan.beantrial.wi
> ldflyejbremote.Demo.getException(): javax.ejb.EJBException: java.lang.UnsupportedOperationException: Not implemented
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:190) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79) [wildfly-ejb3-8.0.0.CR1.jar:8.0
> .0.CR1]
> 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.CR1.jar:8
> .0.0.CR1]
> 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.CR1.jar:8.0.0.CR1]
> 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.CR1.jar:8.0.0.CR1]
> 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.CR1.jar:8.0.0.CR1]
> 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.CR1.jar:8.0.0.CR1]
> 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.CR1.jar:8.0.0.CR1]
> 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:185)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:329) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:70) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:203) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_40]
> at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_40]
> 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]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> Caused by: java.lang.UnsupportedOperationException: Not implemented
> at de.gedoplan.beantrial.wildflyejbremote.DemoBean.getException(DemoBean.java:17) [wildfly-ejbremote-demo.jar:]
> 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.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 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:82) [wildfly-weld-8.0.0.CR1.jar:8.0.0.CR1]
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) [wildfly-weld-8.0.0.CR1.jar:8.0.0.CR1]
> 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.CR1.jar:8.0.0.CR1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 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.1.Final.jar:2013-1
> 2-03 09:59]
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.CR1.jar:8.0.0.CR1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) [wildfly-ee-8.0.0.CR1.jar:8.0.0.CR1]
> 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.CR1.jar:8.0.0.CR1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:273) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
> ... 39 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months