Here's doco: http://wiki.jboss.org/wiki/Wiki.jsp?page=UsingJCAWithJBossESB Had to update server zip to include: jms-ra.rar jms-ds.xml Also added the JDBC xa rar as people will want to use XA datasources. Bill

Also added the JDBC xa rar as people will want to use XA datasources.

1. So now we can use XA Txs spanning DB and JMS resources?

2. I'm guessing we'd still be using the old JmsGateway when running in bootstrapper mode?

3. How does 'transacted' work? I mean an mdb has: supports, requiresNew, required, none.

Yes. Since it's JCA, it supports inflow and outflow directly it's naturally bi-directional. http://jira.jboss.com/jira/browse/JBESB-415 Mark. On 23 May 2007, at 03:39, Burr Sutter wrote: > This is great. Would this be the better way to instruct someone on > how to build their own "gateway"? For instance, lets say I wanted an > HL7 gateway which has its own tranport protocol with specialized > transformations. Is this the place to point a user? > > > > Bill Burke wrote: >> Here's doco: >> >> http://wiki.jboss.org/wiki/Wiki.jsp?page=UsingJCAWithJBossESB >> >> Had to update server zip to include: >> >> jms-ra.rar >> jms-ds.xml >> >> Also added the JDBC xa rar as people will want to use XA datasources. >> >> Bill > > _______________________________________________ > esb-dev mailing list > esb-dev(a)lists.jboss.org <mailto:esb-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/esb-dev ---- Mark Little mlittle(a)redhat.com <mailto:mlittle@redhat.com> JBoss, a Division of Red Hat Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland)

Kurt T Stam wrote: > 1. So now we can use XA Txs spanning DB and JMS resources? We should be able to, the XA transaction should encompass them both. > 2. I'm guessing we'd still be using the old JmsGateway when running in > bootstrapper mode? Weston had intended to develop a standalone implementation of JCA which would have been perfect for the standalone ESB. Not sure what will happen to that now. Using JCA will necessitate the full blown app server or the esb profile.

> 3. How does 'transacted' work? I mean an mdb has: supports, requiresNew, > required, none. MDB only supports Required and NotSupported transaction types as they have no calling context. I would assume that the transacted attribute would be equivalent.

Cool. Hey can we use JCA within the ESB now too (I mean this work was specific to a gateway right?) , or is that still something you're working on? --K Bill Burke wrote: > > Kevin Conner wrote: >> Kurt T Stam wrote: >>> 1. So now we can use XA Txs spanning DB and JMS resources? >> We should be able to, the XA transaction should encompass them both. >> >>> 2. I'm guessing we'd still be using the old JmsGateway when running in >>> bootstrapper mode? >> Weston had intended to develop a standalone implementation of JCA which >> would have been perfect for the standalone ESB. Not sure what will >> happen to that now. >> >> Using JCA will necessitate the full blown app server or the esb profile. >> > > As I've said before, the JBoss Embeddable project *already* includes > JCA and can run inside Junit tests, Tomcat standalone, and plain Java > apps. Eventually I'll get around to refactoring it to run in other > application servers. > > The JCA rewrite will continue. Supposedly Adrian was really itching > to get back to it anyways. If he doesn't pick it up, I definately > will. Really the brunt of the JCA rewrite is to pojitize it and remove > any MBean dependencies or at least, make them "aspectized". > > The JCA integration I did with ESB should really be moved to the JCA > project as it is an abstraction for any inflow container. MDB could > be written on top of it. It has a bridge interface that would allow > you to plug in other JCA implementations, well, at least in theory. I > have no idea if any other app server has an SPI or even an API we > could hack into. If we can't do that, we could probably still embed > our own JCA implementation into another application server. > > > >>> 3. How does 'transacted' work? I mean an mdb has: supports, >>> requiresNew, >>> required, none. >> MDB only supports Required and NotSupported transaction types as they >> have no calling context. I would assume that the transacted attribute >> would be equivalent. >> > The JCA integration layer I did is really a mini MDB container, so > yes, that's what it means. > > Bill >

As I've said before, the JBoss Embeddable project *already* includes JCA and can run inside Junit tests, Tomcat standalone, and plain Java apps. Eventually I'll get around to refactoring it to run in other application servers.

Well it'd be nice if we had JCA for listeners too no? It's to bad a gateway isn't a listener that takes extra params and we'd be done.. Bill Burke wrote: > Kurt, I don't understand what you mean with "can we use JCA within the > ESB", can u elaborate? I have a qa/junit test that uses the JMS > adapter as a <jca-gateway>. See the wiki on where it is. > > Yes, you can use what I did to write gateways if that's what you're > asking. > > Kurt T Stam wrote: >> Cool. >> >> Hey can we use JCA within the ESB now too (I mean this work was specific >> to a gateway right?) >> , or is that still something you're working on? >> >> --K >> >> Bill Burke wrote: >>> Kevin Conner wrote: >>>> Kurt T Stam wrote: >>>>> 1. So now we can use XA Txs spanning DB and JMS resources? >>>> We should be able to, the XA transaction should encompass them both. >>>> >>>>> 2. I'm guessing we'd still be using the old JmsGateway when >>>>> running in >>>>> bootstrapper mode? >>>> Weston had intended to develop a standalone implementation of JCA >>>> which >>>> would have been perfect for the standalone ESB. Not sure what will >>>> happen to that now. >>>> >>>> Using JCA will necessitate the full blown app server or the esb >>>> profile. >>>> >>> As I've said before, the JBoss Embeddable project *already* includes >>> JCA and can run inside Junit tests, Tomcat standalone, and plain Java >>> apps. Eventually I'll get around to refactoring it to run in other >>> application servers. >>> >>> The JCA rewrite will continue. Supposedly Adrian was really itching >>> to get back to it anyways. If he doesn't pick it up, I definately >>> will. Really the brunt of the JCA rewrite is to pojitize it and remove >>> any MBean dependencies or at least, make them "aspectized". >>> >>> The JCA integration I did with ESB should really be moved to the JCA >>> project as it is an abstraction for any inflow container. MDB could >>> be written on top of it. It has a bridge interface that would allow >>> you to plug in other JCA implementations, well, at least in theory. I >>> have no idea if any other app server has an SPI or even an API we >>> could hack into. If we can't do that, we could probably still embed >>> our own JCA implementation into another application server. >>> >>> >>> >>>>> 3. How does 'transacted' work? I mean an mdb has: supports, >>>>> requiresNew, >>>>> required, none. >>>> MDB only supports Required and NotSupported transaction types as they >>>> have no calling context. I would assume that the transacted attribute >>>> would be equivalent. >>>> >>> The JCA integration layer I did is really a mini MDB container, so >>> yes, that's what it means. >>> >>> Bill >>>

We could inject an implementation of ServiceInvoker that invokes directly on the pipeline. The BIG problem though is EPR publishing. JCA is not bi-directional. Outbound and inflow are two separate things. Don't know enough about outbound JCA yet, but we could possibly have a callback method or object that creates a JCAOutput EPR. I'll read more into it. Bill Kurt T Stam wrote: > Well it'd be nice if we had JCA for listeners too no? It's to bad a > gateway isn't a listener that takes extra params and we'd be done.. > > Bill Burke wrote: >> Kurt, I don't understand what you mean with "can we use JCA within the >> ESB", can u elaborate? I have a qa/junit test that uses the JMS >> adapter as a <jca-gateway>. See the wiki on where it is. >> >> Yes, you can use what I did to write gateways if that's what you're >> asking. >> >> Kurt T Stam wrote: >>> Cool. >>> >>> Hey can we use JCA within the ESB now too (I mean this work was >>> specific >>> to a gateway right?) >>> , or is that still something you're working on? >>> >>> --K >>> >>> Bill Burke wrote: >>>> Kevin Conner wrote: >>>>> Kurt T Stam wrote: >>>>>> 1. So now we can use XA Txs spanning DB and JMS resources? >>>>> We should be able to, the XA transaction should encompass them both. >>>>> >>>>>> 2. I'm guessing we'd still be using the old JmsGateway when >>>>>> running in >>>>>> bootstrapper mode? >>>>> Weston had intended to develop a standalone implementation of JCA >>>>> which >>>>> would have been perfect for the standalone ESB. Not sure what will >>>>> happen to that now. >>>>> >>>>> Using JCA will necessitate the full blown app server or the esb >>>>> profile. >>>>> >>>> As I've said before, the JBoss Embeddable project *already* includes >>>> JCA and can run inside Junit tests, Tomcat standalone, and plain Java >>>> apps. Eventually I'll get around to refactoring it to run in other >>>> application servers. >>>> >>>> The JCA rewrite will continue. Supposedly Adrian was really itching >>>> to get back to it anyways. If he doesn't pick it up, I definately >>>> will. Really the brunt of the JCA rewrite is to pojitize it and remove >>>> any MBean dependencies or at least, make them "aspectized". >>>> >>>> The JCA integration I did with ESB should really be moved to the JCA >>>> project as it is an abstraction for any inflow container. MDB could >>>> be written on top of it. It has a bridge interface that would allow >>>> you to plug in other JCA implementations, well, at least in theory. I >>>> have no idea if any other app server has an SPI or even an API we >>>> could hack into. If we can't do that, we could probably still embed >>>> our own JCA implementation into another application server. >>>> >>>> >>>> >>>>>> 3. How does 'transacted' work? I mean an mdb has: supports, >>>>>> requiresNew, >>>>>> required, none. >>>>> MDB only supports Required and NotSupported transaction types as they >>>>> have no calling context. I would assume that the transacted >>>>> attribute >>>>> would be equivalent. >>>>> >>>> The JCA integration layer I did is really a mini MDB container, so >>>> yes, that's what it means. >>>> >>>> Bill >>>> >