[JBoss JIRA] (WFLY-7840) elytron: authentication-context validation errors
by Claudio Miranda (JIRA)
Claudio Miranda created WFLY-7840:
-------------------------------------
Summary: elytron: authentication-context validation errors
Key: WFLY-7840
URL: https://issues.jboss.org/browse/WFLY-7840
Project: WildFly
Issue Type: Bug
Reporter: Claudio Miranda
Assignee: Jason Greene
elytron resource authentication-context has attribute match-rules marked as required=false and nillable=true, but fail to add an authentication-context with no match-rules attribute
{code}
/profile=default/subsystem=elytron/authentication-context=test123:add
{
"outcome" => "failed",
"failure-description" => {"domain-failure-description" => "WFLYCTL0155: 'match-rules' may not be null"},
"rolled-back" => true
}
{code}
Resource description snippet
{code}
"match-rules" => {
"type" => LIST,
"description" => "The match-rules for this authentication context.",
"expressions-allowed" => false,
"required" => false,
"nillable" => true,
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-7823) AMQP remote client failed to connect
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7823?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reassigned WFLY-7823:
------------------------------------
Component/s: JMS
(was: Application Client)
Assignee: Jeff Mesnil (was: Stuart Douglas)
> AMQP remote client failed to connect
> ------------------------------------
>
> Key: WFLY-7823
> URL: https://issues.jboss.org/browse/WFLY-7823
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.1.0.Final
> Environment: OS: Windows10 x64,
> Java: 1.8.0_102
> WildFly 10.1 Final (the same also on 11 night build) - standalone
> client: AmqpNetLite, v.1.2.2.0, Proton 0.14
> Reporter: Oleg Kozakevych
> Assignee: Jeff Mesnil
> Labels: amqp, artemis, wildfly
> Attachments: server.log, server_debug.log, standalone.xml
>
>
> AMQP remote client cannot connect to Artemis broker while it is embedded into WildFly.
> When client connects, it doesn't receive anything from the server. I turned on frame logging in AmqpNetLite and it show like following:
> {noformat}
> [03:58:25.015] SEND AMQP 3 1 0 0
> [03:58:25.062] SEND sasl-init(mechanism:PLAIN,initial-response:006775657374006775657374,hostname:127.0.0.1)
> {noformat}
> Server just does nothing, any traces, any response to client.
> I made changes as suggested by Justin in corresponding thread (https://developer.jboss.org/thread/269424)
> {noformat}
> The Artemis AMQP protocol implementation module (at <WFLY_HOME>/modules/system/layers/base/org/apache/activemq/artemis/protocol/amqp/main) needs a dependency on Netty in its module.xml (e.g. <module name="io.netty"/>).
> Artemis requires Proton-J 0.10 and Wildfly ships with 0.8 so you can copy proton-j-0.10.jar and proton-jms-0.10.jar from Artemis' /lib directory to <WFLY_HOME>/modules/system/layers/base/org/apache/qpid/proton/main and update the module.xml accordingly.
> {noformat}
> Then I turned debug traces and see following exception:
> {noformat}
> 13:01:00,713 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) java.nio.ReadOnlyBufferException
> 13:01:00,716 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at java.nio.ByteBuffer.array(ByteBuffer.java:996)
> 13:01:00,720 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.buffer.UnsafeByteBufUtil.setBytes(UnsafeByteBufUtil.java:368)
> 13:01:00,730 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.buffer.PooledUnsafeDirectByteBuf.setBytes(PooledUnsafeDirectByteBuf.java:205)
> 13:01:00,734 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:877)
> 13:01:00,745 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.handler.impl.ProtonHandlerImpl.outputBuffer(ProtonHandlerImpl.java:226)
> 13:01:00,749 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.context.AbstractConnectionContext.flushBytes(AbstractConnectionContext.java:145)
> 13:01:00,760 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.context.AbstractConnectionContext$LocalListener.onTransport(AbstractConnectionContext.java:160)
> 13:01:00,766 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.handler.impl.ProtonHandlerImpl.dispatch(ProtonHandlerImpl.java:349)
> 13:01:00,770 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.handler.impl.ProtonHandlerImpl.flush(ProtonHandlerImpl.java:257)
> 13:01:00,783 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.handler.impl.ProtonHandlerImpl.inputBuffer(ProtonHandlerImpl.java:158)
> 13:01:00,789 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.proton.plug.context.AbstractConnectionContext.inputBuffer(AbstractConnectionContext.java:81)
> 13:01:00,800 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.apache.activemq.artemis.core.protocol.proton.ActiveMQProtonRemotingConnection.bufferReceived(ActiveMQProtonRemotingConnection.java:127)
> 13:01:00,807 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:619)
> 13:01:00,814 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:68)
> 13:01:00,820 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:318)
> 13:01:00,832 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:304)
> 13:01:00,839 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.handler.codec.ByteToMessageDecoder.handlerRemoved(ByteToMessageDecoder.java:216)
> 13:01:00,849 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.DefaultChannelPipeline.callHandlerRemoved0(DefaultChannelPipeline.java:527)
> 13:01:00,855 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.DefaultChannelPipeline.callHandlerRemoved(DefaultChannelPipeline.java:521)
> 13:01:00,866 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.DefaultChannelPipeline.remove0(DefaultChannelPipeline.java:351)
> 13:01:00,871 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.DefaultChannelPipeline.remove(DefaultChannelPipeline.java:322)
> 13:01:00,882 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.DefaultChannelPipeline.remove(DefaultChannelPipeline.java:299)
> 13:01:00,887 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.apache.activemq.artemis.core.protocol.ProtocolHandler$ProtocolDecoder.decode(ProtocolHandler.java:175)
> 13:01:00,902 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:360)
> 13:01:00,913 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:244)
> 13:01:00,920 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at org.apache.activemq.artemis.core.protocol.ProtocolHandler$ProtocolDecoder.channelRead(ProtocolHandler.java:118)
> 13:01:00,931 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:318)
> 13:01:00,937 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:304)
> 13:01:00,949 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:846)
> 13:01:00,954 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:131)
> 13:01:00,965 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:511)
> 13:01:00,969 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:468)
> 13:01:00,981 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:382)
> 13:01:00,986 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:354)
> 13:01:00,998 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112)
> 13:01:01,003 ERROR [stderr] (Thread-1 (activemq-netty-threads-1534405955)) at java.lang.Thread.run(Thread.java:745)
> {noformat}
> Configuration and server logs are attached.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-4510) "IJ000451: The connection manager is shutdown" after disabling/enabling a datasource
by Manoj Dixit (JIRA)
[ https://issues.jboss.org/browse/WFLY-4510?page=com.atlassian.jira.plugin.... ]
Manoj Dixit commented on WFLY-4510:
-----------------------------------
We are facing same issues in Jboss EAP 6.4. Please let me know the solution.
> "IJ000451: The connection manager is shutdown" after disabling/enabling a datasource
> ------------------------------------------------------------------------------------
>
> Key: WFLY-4510
> URL: https://issues.jboss.org/browse/WFLY-4510
> Project: WildFly
> Issue Type: Bug
> Components: Batch
> Environment: Windows 8.1 x64, JDK 1.8.0_20, Wildfly 8.2.0.Final
> Reporter: Renann Prado
> Assignee: James Perkins
> Fix For: 9.0.0.Beta1
>
>
> The below exception is thrown after the DataSource is disabled/enabled.
> I read that in Wildfly 9 onwards disabling/enabling a DataSource is deprecated, so *maybe* this problem won`t happen in next Wildfly version.
> {noformat}
> 2015-04-12 16:48:07,691 ERROR [io.undertow.request] (default task-8) UT005023: Exception handling request to /XXXXXe-web/NewServlet: javax.batch.operations.BatchRuntimeException: JBERET000622: Failed to obtain connection from org.jboss.jca.adapters.jdbc.WrapperDataSource@da89438, java:jboss/dasources/MySQL
> at org.jberet.repository.JdbcRepository.getConnection(JdbcRepository.java:802) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> at org.jberet.repository.JdbcRepository.insertJobInstance(JdbcRepository.java:264) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> at org.jberet.repository.AbstractRepository.createJobInstance(AbstractRepository.java:91) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> at org.jberet.operations.JobOperatorImpl$1.invoke(JobOperatorImpl.java:82) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> at org.jberet.operations.JobOperatorImpl$1.invoke(JobOperatorImpl.java:79) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> at org.jberet.operations.JobOperatorImpl.invokeTransaction(JobOperatorImpl.java:295) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> at org.jberet.operations.JobOperatorImpl.start(JobOperatorImpl.java:79) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> at com.test.NewServlet.processRequest(NewServlet.java:64) [classes:]
> at com.test.NewServlet.doGet(NewServlet.java:95) [classes:]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_11]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_11]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_11]
> Caused by: java.sql.SQLException: javax.resource.ResourceException: IJ000451: The connection manager is shutdown: java:jboss/dasources/MySQL
> at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:154)
> at org.jberet.repository.JdbcRepository.getConnection(JdbcRepository.java:800) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> ... 36 more
> Caused by: javax.resource.ResourceException: IJ000451: The connection manager is shutdown: java:jboss/dasources/MySQL
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:371)
> at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:421)
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:515)
> at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:146)
> ... 37 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (JGRP-2126) Table.removeMany() creates unneeded temporary list
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2126?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2126:
--------------------------------
Added Table.removeMany():
{code:java}
<R> R removeMany(final AtomicBoolean processing, boolean nullify, int max_results, Predicate<T> filter, Supplier<R> result_creator, BiConsumer<R,T> accumulator, Predicate<R> result_validator)
{code}, which accepts a result creator, accumulator and validator (similar to Stream.collect()).
Both NAKACK2 and UNICAST3 create a MessageBatch and use it to move messages from the table to the batch, avoiding a temporary list creation.
> Table.removeMany() creates unneeded temporary list
> --------------------------------------------------
>
> Key: JGRP-2126
> URL: https://issues.jboss.org/browse/JGRP-2126
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Labels: CR3
> Fix For: 4.0
>
>
> When a thread acquires the CAS in NAKACK2 or UNICAST3 to deliver messages, it calls Table.removeMany() which removes messages that satisfy a condition and return them as a list. Next, a MessageBatch is created off of that list and passed up.
> The creation of the temp list is unnecessary; instead create a properly sized MessageBatch and make Table.removeMany() add the messages directly into the batch.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-7838) EJBClient user transaction is not propagated properly to the receiver
by Mate Varga (JIRA)
[ https://issues.jboss.org/browse/WFLY-7838?page=com.atlassian.jira.plugin.... ]
Mate Varga updated WFLY-7838:
-----------------------------
Attachment: wf-txn-fix.patch
> EJBClient user transaction is not propagated properly to the receiver
> ---------------------------------------------------------------------
>
> Key: WFLY-7838
> URL: https://issues.jboss.org/browse/WFLY-7838
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.1.0.Final
> Environment: not relevant
> Reporter: Mate Varga
> Attachments: wf-txn-fix.patch
>
>
> Setup:
> - WF 10.1.0.Final
> - two deployments, one EAR and one WAR
> - EAR exposes EJB methods (SFSBs and SLSBs)
> - WAR uses wildfly-ejb-client-bom 10.1.0 to call remote EJBs
> Problem:
> The client uses bean-managed transactions. The problem is that transactions are not propagated properly to the EJB side, therefore instead of using the existing BMT, container will use CMT. The flow in detail:
> - LocalEjbReceiver#processInvocation receives an EJBClientInvocationContext
> - EJBClientInvocationContext contains contextData, which was populated by the client. contextData correctly contains the appropriate UserTransactionId
> - processInvocation extracts the transaction Id and puts it into the interceptorContext's context data (NOT into privateData)
> - later in the interceptor chain, control reaches EJBRemoteTransactionPropagatingInterceptor, which is responsible for checking whether there is an user transaction present.
> - it tries to fetch the transaction ID from the interceptorContext's privateData (NOT from contextData)
> - it does not find the userTransaction there
> It looks to me that either EJBRemoteTransactionPropagatingInterceptor should look look for the userTransaction in contextData, or LocalEjbReceiver should put the userTransaction ID into privateData.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-7838) EJBClient user transaction is not propagated properly to the receiver
by Mate Varga (JIRA)
[ https://issues.jboss.org/browse/WFLY-7838?page=com.atlassian.jira.plugin.... ]
Mate Varga updated WFLY-7838:
-----------------------------
Description:
Setup:
- WF 10.1.0.Final
- two deployments, one EAR and one WAR
- EAR exposes EJB methods (SFSBs and SLSBs)
- WAR uses wildfly-ejb-client-bom 10.1.0 to call remote EJBs
Problem:
The client uses bean-managed transactions. The problem is that transactions are not propagated properly to the EJB side, therefore instead of using the existing BMT, container will use CMT. The flow in detail:
- LocalEjbReceiver#processInvocation receives an EJBClientInvocationContext
- EJBClientInvocationContext contains contextData, which was populated by the client. contextData correctly contains the appropriate UserTransactionId
- processInvocation extracts the transaction Id and puts it into the interceptorContext's context data (NOT into privateData)
- later in the interceptor chain, control reaches EJBRemoteTransactionPropagatingInterceptor, which is responsible for checking whether there is an user transaction present.
- it tries to fetch the transaction ID from the interceptorContext's privateData (NOT from contextData)
- it does not find the userTransaction there
It looks to me that either EJBRemoteTransactionPropagatingInterceptor should look look for the userTransaction in contextData, or LocalEjbReceiver should put the userTransaction ID into privateData.
I've attached a patch that fixes the problem for me.
was:
Setup:
- WF 10.1.0.Final
- two deployments, one EAR and one WAR
- EAR exposes EJB methods (SFSBs and SLSBs)
- WAR uses wildfly-ejb-client-bom 10.1.0 to call remote EJBs
Problem:
The client uses bean-managed transactions. The problem is that transactions are not propagated properly to the EJB side, therefore instead of using the existing BMT, container will use CMT. The flow in detail:
- LocalEjbReceiver#processInvocation receives an EJBClientInvocationContext
- EJBClientInvocationContext contains contextData, which was populated by the client. contextData correctly contains the appropriate UserTransactionId
- processInvocation extracts the transaction Id and puts it into the interceptorContext's context data (NOT into privateData)
- later in the interceptor chain, control reaches EJBRemoteTransactionPropagatingInterceptor, which is responsible for checking whether there is an user transaction present.
- it tries to fetch the transaction ID from the interceptorContext's privateData (NOT from contextData)
- it does not find the userTransaction there
It looks to me that either EJBRemoteTransactionPropagatingInterceptor should look look for the userTransaction in contextData, or LocalEjbReceiver should put the userTransaction ID into privateData.
> EJBClient user transaction is not propagated properly to the receiver
> ---------------------------------------------------------------------
>
> Key: WFLY-7838
> URL: https://issues.jboss.org/browse/WFLY-7838
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.1.0.Final
> Environment: not relevant
> Reporter: Mate Varga
> Attachments: wf-txn-fix.patch
>
>
> Setup:
> - WF 10.1.0.Final
> - two deployments, one EAR and one WAR
> - EAR exposes EJB methods (SFSBs and SLSBs)
> - WAR uses wildfly-ejb-client-bom 10.1.0 to call remote EJBs
> Problem:
> The client uses bean-managed transactions. The problem is that transactions are not propagated properly to the EJB side, therefore instead of using the existing BMT, container will use CMT. The flow in detail:
> - LocalEjbReceiver#processInvocation receives an EJBClientInvocationContext
> - EJBClientInvocationContext contains contextData, which was populated by the client. contextData correctly contains the appropriate UserTransactionId
> - processInvocation extracts the transaction Id and puts it into the interceptorContext's context data (NOT into privateData)
> - later in the interceptor chain, control reaches EJBRemoteTransactionPropagatingInterceptor, which is responsible for checking whether there is an user transaction present.
> - it tries to fetch the transaction ID from the interceptorContext's privateData (NOT from contextData)
> - it does not find the userTransaction there
> It looks to me that either EJBRemoteTransactionPropagatingInterceptor should look look for the userTransaction in contextData, or LocalEjbReceiver should put the userTransaction ID into privateData.
> I've attached a patch that fixes the problem for me.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months