I have had a chat about that with the main author of geronimo transaction layer.
It seems that there is a missing piece of code inside jencks to wrap
the XAResource in a NamedXAResource.
The missing piece looks like
public MessageEndpoint createEndpoint(XAResource
adapterXAResource) throws UnavailableException {
NamedXAResource wrapper = adapterXAResource == null ? null :
new WrapperNamedXAResource(adapterXAResource, containerId);
return endpointFactory.getMessageEndpoint(wrapper);
}
in the MessageEndpointFactory from jencks.
Has a hack, you could try to put that in the JCA flow somewhere.
Note that the containerId should be roughtly equivalent to the resource manager
which supplies xids from XAResource.recover and should be the same across
restart. I guess using the JMS broker id should be fine.
I'll try to give it more time this week, but if you want to try, please go.
You already have a working test case, so it would be easier for you.
On 10/2/06, Jamie McCrindle <[EMAIL PROTECTED]> wrote:
Oddly enough, the code that would have made this work was added by
jstrachan into transactionimpl and then removed to add the exception:
http://svn.apache.org/viewvc/geronimo/server/trunk/modules/geronimo-transaction/src/main/java/org/apache/geronimo/transaction/manager/TransactionImpl.java?view=log
help!
On 10/2/06, Jamie McCrindle <[EMAIL PROTECTED]> wrote:
> Started debugging the geronimo-transaction code and found that the
> reason that the rollback is called is because: an
> IllegalStateException is being thrown:
>
> java.lang.IllegalStateException: Cannot log transactions unles XAResources
are n
> amed! [EMAIL PROTECTED]
> at
org.apache.geronimo.transaction.manager.TransactionImpl$TransactionBr
> anch.getResourceName(TransactionImpl.java:658)
> at
org.apache.geronimo.transaction.log.GeronimoHOWLLog.prepare(GeronimoH
> OWLLog.java:229)
> at
org.apache.geronimo.transaction.manager.TransactionImpl.internalPrepa
> re(TransactionImpl.java:415)
> at
org.apache.geronimo.transaction.manager.TransactionImpl.commit(Transa
> ctionImpl.java:286)
> at
org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit
> (TransactionManagerImpl.java:143)
> at
org.apache.geronimo.transaction.context.InheritableTransactionContext
> .complete(InheritableTransactionContext.java:196)
> at
org.apache.geronimo.transaction.context.InheritableTransactionContext
> .commit(InheritableTransactionContext.java:146)
> at
org.apache.geronimo.transaction.context.GeronimoTransactionManager.co
> mmit(GeronimoTransactionManager.java:81)
> at
org.apache.geronimo.transaction.context.GeronimoTransactionDelegate.c
> ommit(GeronimoTransactionDelegate.java:51)
> at org.jencks.XAEndpoint.afterDelivery(XAEndpoint.java:103)
> at
org.apache.activemq.ra.MessageEndpointProxy$MessageEndpointAlive.afte
> rDelivery(MessageEndpointProxy.java:125)
> at
org.apache.activemq.ra.MessageEndpointProxy.afterDelivery(MessageEndp
> ointProxy.java:64)
> at
org.apache.activemq.ra.ServerSessionImpl.afterDelivery(ServerSessionI
> mpl.java:214)
> at org.apache.activemq.ActiveMQSession.run(ActiveMQSession.java:751)
> at
org.apache.activemq.ra.ServerSessionImpl.run(ServerSessionImpl.java:1
> 63)
> at
org.apache.geronimo.connector.work.WorkerContext.run(WorkerContext.ja
> va:291)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown
So
> urce)
> at java.lang.Thread.run(Thread.java:595)
>
> will continue the investigation...
>
> On 10/2/06, Jamie McCrindle <[EMAIL PROTECTED]> wrote:
> > hiya,
> >
> > JCAFlow is still not quite working for me. Here is some of the stuff
> > I've done and what happened:
> >
> > I changed my test case to use the transactional behaviour (tm.begin(),
> > tm.commit()) but i'm still getting the STATUS_NO_TRANSACTION
> > exception.
> >
> > I took the JcaFlow test and modified it to try and replicate the
> > behaviour only in a test case. The first thing that happened was that
> > i got a TransportConnector NPE which looks to be fixed in a later
> > version of activemq. I changed the test to directly create the
> > activemq broker rather than use an activemq.xml file.
> >
> > I started using the EchoComponent that comes with servicemix in one
> > container and a DefaultServiceMixClient in the other but go a
> > "component is not the owner" from the EchoComponent trying to set a
> > "Flow 'JCA' was specified but not able to handle exchange" because
> > JCAFlow can't handle transacted synchronous exchanges. Wasn't
> > explicitly creating a transaction. Tried setting
> > autoEnlistInTransaction to false on both containers but didn't make a
> > difference.
> >
> > Ah, figured it out. Wierd. TransformComponentSupport does this:
> >
> > boolean txSync = exchange.isTransacted() &&
> > Boolean.TRUE.equals(exchange.getProperty(JbiConstants.SEND_SYNC));
> >
> > and then this:
> >
> > if (txSync) {
> > getDeliveryChannel().sendSync(exchange);
> >
> > which means that it can't be used in JCA flows?
> >
> > Right. Wrote my own EchoComponent and sendSync works. But I'm still
> > getting the STATUS_NO_TRANSACTION when I try and use the full blown
> > component.
> >
> > will continue...
> >
> > On 9/29/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
> > > Have you tried starting transaction before sending the
> > > jbi exchange ?
> > >
> > > tm.start();
> > > client.sendSync(me);
> > > client.done(me);
> > > tm.commit();
> > >
> > > You can take a look at the junit tests for the EIP component.
> > >
> > >
> > > On 9/29/06, Jamie McCrindle <[EMAIL PROTECTED]> wrote:
> > > > Hmmm... just created a basic echo component (based on the mvn
> > > > service-engine archetype) and called it using the JCA code from the
> > > > JcaTest case in servicemix-core and got the same error (using both a
> > > > DefaultServicemixClient and the SenderComponent).
> > > >
> > > > tried setting autoEnlistInTransaction="true" on both the client
> > > > container and server container.
> > > >
> > > > hmmm... not sure of my next step...
> > > >
> > > > for reference, the client code is as follows:
> > > >
> > > > TransactionManagerFactoryBean tmcf = new
> > > > TransactionManagerFactoryBean();
> > > > tmcf.afterPropertiesSet();
> > > > ExtendedTransactionManager etm = (ExtendedTransactionManager)
> > > > tmcf.getObject();
> > > > TransactionContextManagerFactoryBean tcmfb = new
> > > > TransactionContextManagerFactoryBean();
> > > > tcmfb.setTransactionManager(etm);
> > > > tcmfb.afterPropertiesSet();
> > > > TransactionContextManager tcm = (TransactionContextManager)
> > > > tcmfb.getObject();
> > > > GeronimoTransactionManagerFactoryBean gtmfb = new
> > > > GeronimoTransactionManagerFactoryBean();
> > > > gtmfb.setTransactionContextManager(tcm);
> > > > gtmfb.afterPropertiesSet();
> > > > TransactionManager tm = (TransactionManager) gtmfb.getObject();
> > > > tt = new TransactionTemplate(new
> > > > JtaTransactionManager((UserTransaction) tm));
> > > >
> > > > JCAFlow senderFlow = new JCAFlow();
> > > > senderFlow.setJmsURL("tcp://localhost:61616");
> > > > senderFlow.setTransactionContextManager(tcm);
> > > > senderContainer.setTransactionManager(tm);
> > > > senderContainer.setEmbedded(true);
> > > > senderContainer.setName("senderContainer");
> > > > senderContainer.setFlow(senderFlow);
> > > > senderContainer.setMonitorInstallationDirectory(false);
> > > > senderContainer.init();
> > > > senderContainer.start();
> > > > senderContainer.setAutoEnlistInTransaction(true);
> > > >
> > > > DefaultServiceMixClient client;
> > > > client = new DefaultServiceMixClient(senderContainer);
> > > > InOut inOut = client.createInOutExchange(new
> > > > QName("http://org.echo/jbi";, "echo"), null, null);
> > > > NormalizedMessage inMessage = inOut.createMessage();
> > > > inMessage.setContent(new StringSource("<test/>"));
> > > > inOut.setInMessage(inMessage);
> > > > client.sendSync(inOut);
> > > >
> > > > server code is pretty much the same as the archetype except that i
> > > > forced the endpoint in rather than deployed it as in MyLifeCycle:
> > > >
> > > > protected void doInit() throws Exception {
> > > > super.doInit();
> > > > su = new XBeanServiceUnit();
> > > > su.setComponent(component);
> > > > MyEndpoint myEndpoint = new MyEndpoint();
> > > > myEndpoint.setServiceUnit(su);
> > > > myEndpoint.setService(new QName("http://org.echo/jbi";, "echo"));
> > > > myEndpoint.setEndpoint("echo");
> > > > myEndpoint.validate();
> > > > su.addEndpoint(myEndpoint);
> > > > component.getRegistry().registerServiceUnit(su);
> > > > }
> > > >
> > > > protected void doStop() throws Exception {
> > > > super.doStop();
> > > > su.stop();
> > > > }
> > > >
> > > > protected void doStart() throws Exception {
> > > > super.doStart();
> > > > su.start();
> > > > }
> > > >
> > > > On 9/29/06, Jamie McCrindle <[EMAIL PROTECTED]> wrote:
> > > > > hiya,
> > > > >
> > > > > I'll try and call a standard component and see if i get the same
> > > > > problem, in which case i can at least isolate it to it being the
> > > > > component rather than the configuration. will get back to you.
> > > > >
> > > > > cheers,
> > > > > j.
> > > > >
> > > > > On 9/29/06, Jamie McCrindle <[EMAIL PROTECTED]> wrote:
> > > > > > hi Guillaume,
> > > > > >
> > > > > > The component is my own and is currently blissfully unaware of the
> > > > > > transaction (just moved from non transactional jms flow to jca
flow).
> > > > > >
> > > > > > cheers,
> > > > > > j.
> > > > > >
> > > > > > On 9/29/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
> > > > > > > My first guess is that the component is doing something wrong
> > > > > > > with the transaction (suspend, commit, rollback).
> > > > > > > The only operation allowed is to mark the transaction as rollback
only.
> > > > > > > Which component receives the exchange ?
> > > > > > >
> > > > > > > On 9/29/06, Jamie McCrindle <[EMAIL PROTECTED]> wrote:
> > > > > > > > ERROR - AbstractTransactionContext - Unable to roll back
transaction
> > > > > > > > java.lang.IllegalStateException: Status is STATUS_NO_TRANSACTION
> > > > > > > > at
org.apache.geronimo.transaction.manager.TransactionImpl.rollback(Tran
> > > > > > > > sactionImpl.java:438)
> > > > > > > > at
org.apache.geronimo.transaction.context.InheritableTransactionContext
> > > > > > > > .rollbackAndThrow(InheritableTransactionContext.java:308)
> > > > > > > > at
org.apache.geronimo.transaction.context.InheritableTransactionContext
> > > > > > > > .complete(InheritableTransactionContext.java:199)
> > > > > > > > at
org.apache.geronimo.transaction.context.InheritableTransactionContext
> > > > > > > > .commit(InheritableTransactionContext.java:146)
> > > > > > > > at
org.apache.geronimo.transaction.context.GeronimoTransactionManager.co
> > > > > > > > mmit(GeronimoTransactionManager.java:81)
> > > > > > > > at
org.apache.geronimo.transaction.context.GeronimoTransactionDelegate.c
> > > > > > > > ommit(GeronimoTransactionDelegate.java:51)
> > > > > > > > at
org.jencks.XAEndpoint.afterDelivery(XAEndpoint.java:103)
> > > > > > > > at
org.apache.activemq.ra.MessageEndpointProxy$MessageEndpointAlive.afte
> > > > > > > > rDelivery(MessageEndpointProxy.java:125)
> > > > > > > > at
org.apache.activemq.ra.MessageEndpointProxy.afterDelivery(MessageEndp
> > > > > > > > ointProxy.java:64)
> > > > > > > > at
org.apache.activemq.ra.ServerSessionImpl.afterDelivery(ServerSessionI
> > > > > > > > mpl.java:214)
> > > > > > > > at
org.apache.activemq.ActiveMQSession.run(ActiveMQSession.java:751)
> > > > > > > > at
org.apache.activemq.ra.ServerSessionImpl.run(ServerSessionImpl.java:1
> > > > > > > > 63)
> > > > > > > > at
org.apache.geronimo.connector.work.WorkerContext.run(WorkerContext.ja
> > > > > > > > va:291)
> > > > > > > > at
EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown So
> > > > > > > > urce)
> > > > > > > >
> > > > > > > > On 9/29/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
> > > > > > > > > Do you have the full stack trace please ?
> > > > > > > > >
> > > > > > > > > On 9/29/06, Jamie McCrindle <[EMAIL PROTECTED]> wrote:
> > > > > > > > > > hiya,
> > > > > > > > > >
> > > > > > > > > > i'm getting a "Status is STATUS_NO_TRANSACTION" exception
from
> > > > > > > > > > servicemix but I've just switched to using jcaFlow so I'm
not too
> > > > > > > > > > surprised. any pointers of where to look for what might be
the issue?
> > > > > > > > > >
> > > > > > > > > > the setup is a webapp with an embedded servicemix container
calling a
> > > > > > > > > > component on a standard servicemix container both using jca
flow. i
> > > > > > > > > > suspect it's the configuration of the jca container in the
webapp
> > > > > > > > > > that's not behaving because it's custom built but any
pointers would
> > > > > > > > > > be awesome.
> > > > > > > > > >
> > > > > > > > > > cheers,
> > > > > > > > > > j.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Cheers,
> > > > > > > > > Guillaume Nodet
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Cheers,
> > > > > > > Guillaume Nodet
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > Cheers,
> > > Guillaume Nodet
> > >
> >
>
--
Cheers,
Guillaume Nodet
