RE: [JBoss-dev] jbossmq and jca 1.5
Hey David.. I want to see If I can start working on this. I know like amost zero about jca but I know quite a bit about the XA stuff and how jbossmq txs work with the MDB. anyways.. I guess what I need to know is how is the contianer going to initialize the jms stuff so that it can deliver the container it's messages. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Jencks Sent: Friday, August 30, 2002 1:35 PM To: jboss-dev Subject: [JBoss-dev] jbossmq and jca 1.5 I started looking at modifying jbossmq and/or the jmsra adapter to work with the j2ee connector architecture 1.5 facilities. I am definitely not a jms expert so a lot of what I say may not make sense. Here's what the new spec provides that I think is relevant: thread pooling through the WorkManager interface. You submit Work instances to be done in other threads. The app server controls the thread pooling. message inflow through the MessageEndpoint interfaces. In particular, I think we should use Option B which involves the jms system calling, on a MessageEndpoint supplied from the app server, beforeDelivery([the onMessage method]); //this starts the jta tx and informs the adapter via an XAResource the adapter supplied earlier. onMessage(message); //actual message delivery to MessageListener afterDelivery(); //ends the tx, again the adapter is informed via the XAResource. I keep getting lost looking at the jms code. My impression so far is that although the jca 1 jmsra adapter appears to work ok without modifying jbossmq, using the contracts mentioned above will require additional code in jbossmq itself, namely an additional way of delivering messages within a transaction. Does this make sense? Do any of the jbossmq experts want to work on this? There are very simple examples of using the work and message endpoint interfaces in the testsuite in .../jca/inflow. I haven't written the deployment portion of the connector 1.5 support yet: I'm hoping for a real adapter example that can be used to test it. However, I think for now everything needed can be set up without a deployer as explicit mbeans: this is what I did in the tests. Thanks david jencks --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jbossmq and jca 1.5
Hey Hiram, Glad to see you're getting interested. Unfortunately I leave for the weekend in a few minutes... more on monday. The part of jca 1.5 I haven't written is the deployment of the adapter. If you get that far, you should be able to write a simple mbean to create your ResourceAdapter and any adapter specific objects you need, then I can make it generic. Your adapter should have a ResourceAdapter object that sets up the environment. It will be provided a BootstrapContext object from which it can get a WorkManager. The WorkManager is a thread pool with transaction import capabilities. You won't need the tx import capabilities, but you should use the thread pool. I plan for the deployer to supply a WorkManager per deployed adapter, configured according to a jboss-specific dd, similar to the connection pool configuration. Instead, use the Message Inflow stuff. There's a unit test showing how it works with transactions - org.jboss.test.jca.test.MessageEndpointUnitTestCase. The deployment system I'm thinking of is to deploy the ResourceAdapter and other adapter specific objects as xmbeans by generating xmbean xml deployment descriptors for them. BTW, I modified the Trunk invoker to make our tm distributed, using the jca transaction import facilities. It compiles and runs, but I haven't managed to set up a test environment for it with 2 servers yet. Thanks! david jencks On 2002.10.05 02:58:45 -0400 Hiram Chirino wrote: Hey David.. I want to see If I can start working on this. I know like amost zero about jca but I know quite a bit about the XA stuff and how jbossmq txs work with the MDB. anyways.. I guess what I need to know is how is the contianer going to initialize the jms stuff so that it can deliver the container it's messages. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Jencks Sent: Friday, August 30, 2002 1:35 PM To: jboss-dev Subject: [JBoss-dev] jbossmq and jca 1.5 I started looking at modifying jbossmq and/or the jmsra adapter to work with the j2ee connector architecture 1.5 facilities. I am definitely not a jms expert so a lot of what I say may not make sense. Here's what the new spec provides that I think is relevant: thread pooling through the WorkManager interface. You submit Work instances to be done in other threads. The app server controls the thread pooling. message inflow through the MessageEndpoint interfaces. In particular, I think we should use Option B which involves the jms system calling, on a MessageEndpoint supplied from the app server, beforeDelivery([the onMessage method]); //this starts the jta tx and informs the adapter via an XAResource the adapter supplied earlier. onMessage(message); //actual message delivery to MessageListener afterDelivery(); //ends the tx, again the adapter is informed via the XAResource. I keep getting lost looking at the jms code. My impression so far is that although the jca 1 jmsra adapter appears to work ok without modifying jbossmq, using the contracts mentioned above will require additional code in jbossmq itself, namely an additional way of delivering messages within a transaction. Does this make sense? Do any of the jbossmq experts want to work on this? There are very simple examples of using the work and message endpoint interfaces in the testsuite in .../jca/inflow. I haven't written the deployment portion of the connector 1.5 support yet: I'm hoping for a real adapter example that can be used to test it. However, I think for now everything needed can be set up without a deployer as explicit mbeans: this is what I did in the tests. Thanks david jencks --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jbossmq and jca 1.5
Hi, I am sorry I have not had the time to do anything on the jca1.5 integration. I have not even had time to read the new spec. From what you say I would however draw the following conclusions: 1. The jca 1.5 have defined a new contract superceding chapter 8 in the JMS spec, which means that each JMS provider will have to roll its own JMS JCC provider adapter. 2. This only affecs asynchronous use, i.e only JMSContainerInvoker. 3. We would therefore perhaps want a jms.JCAContainerInvoker wich works agains the new JCA. 4. On the other hand we have been propagating for a year and a half now that chapter 8 in the JMS spec give us all we need, and we have integrated JBossMQ, SonicMQ and SwiftMQ through the chapter 8 api. 5. Adding a native RA to JBossMQ would entail recreating the Conumer stuff in the new RA. 6. My advice would actually be this: write a jca2chapter8 converter. To do this you would thake the stuff from StdServerSession, StdServerSessionPool and JMSContainerInvoker and integrate into the RA. The RA would continue to work against a ProviderAdapter and chapter 8, but would also be able to work with the new JCA. Look for example in StdServerSession - there you can split the TX logic and do your callback. The old way is that the appserver provides the thread pool (StdServerSessionPool), the JMS provider gets a (Std)ServerSession from the appserverpool, stuff its on session in it and let the appserver do its work. Seems to be verry similar. Hope this helps somewhat. //Peter On 30 Aug, David Jencks wrote: I started looking at modifying jbossmq and/or the jmsra adapter to work with the j2ee connector architecture 1.5 facilities. I am definitely not a jms expert so a lot of what I say may not make sense. Here's what the new spec provides that I think is relevant: thread pooling through the WorkManager interface. You submit Work instances to be done in other threads. The app server controls the thread pooling. message inflow through the MessageEndpoint interfaces. In particular, I think we should use Option B which involves the jms system calling, on a MessageEndpoint supplied from the app server, beforeDelivery([the onMessage method]); //this starts the jta tx and informs the adapter via an XAResource the adapter supplied earlier. onMessage(message); //actual message delivery to MessageListener afterDelivery(); //ends the tx, again the adapter is informed via the XAResource. I keep getting lost looking at the jms code. My impression so far is that although the jca 1 jmsra adapter appears to work ok without modifying jbossmq, using the contracts mentioned above will require additional code in jbossmq itself, namely an additional way of delivering messages within a transaction. Does this make sense? Do any of the jbossmq experts want to work on this? There are very simple examples of using the work and message endpoint interfaces in the testsuite in .../jca/inflow. I haven't written the deployment portion of the connector 1.5 support yet: I'm hoping for a real adapter example that can be used to test it. However, I think for now everything needed can be set up without a deployer as explicit mbeans: this is what I did in the tests. Thanks david jencks --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Peter AntmanChief Systems Architect, Business Development Technology in Media, Box 34105 100 26 Stockholm WWW: http://www.tim.se WWW: http://www.backsource.org Email: [EMAIL PROTECTED] Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942 --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jbossmq and jca 1.5
Many thanks, peter. I have to work on some other things for a while also, I will try to look into this more. Your pointers will be a big help in seeing how it works. Thanks david jencks On 2002.09.03 03:25:26 -0400 Peter Antman wrote: Hi, I am sorry I have not had the time to do anything on the jca1.5 integration. I have not even had time to read the new spec. From what you say I would however draw the following conclusions: 1. The jca 1.5 have defined a new contract superceding chapter 8 in the JMS spec, which means that each JMS provider will have to roll its own JMS JCC provider adapter. 2. This only affecs asynchronous use, i.e only JMSContainerInvoker. 3. We would therefore perhaps want a jms.JCAContainerInvoker wich works agains the new JCA. 4. On the other hand we have been propagating for a year and a half now that chapter 8 in the JMS spec give us all we need, and we have integrated JBossMQ, SonicMQ and SwiftMQ through the chapter 8 api. 5. Adding a native RA to JBossMQ would entail recreating the Conumer stuff in the new RA. 6. My advice would actually be this: write a jca2chapter8 converter. To do this you would thake the stuff from StdServerSession, StdServerSessionPool and JMSContainerInvoker and integrate into the RA. The RA would continue to work against a ProviderAdapter and chapter 8, but would also be able to work with the new JCA. Look for example in StdServerSession - there you can split the TX logic and do your callback. The old way is that the appserver provides the thread pool (StdServerSessionPool), the JMS provider gets a (Std)ServerSession from the appserverpool, stuff its on session in it and let the appserver do its work. Seems to be verry similar. Hope this helps somewhat. //Peter On 30 Aug, David Jencks wrote: I started looking at modifying jbossmq and/or the jmsra adapter to work with the j2ee connector architecture 1.5 facilities. I am definitely not a jms expert so a lot of what I say may not make sense. Here's what the new spec provides that I think is relevant: thread pooling through the WorkManager interface. You submit Work instances to be done in other threads. The app server controls the thread pooling. message inflow through the MessageEndpoint interfaces. In particular, I think we should use Option B which involves the jms system calling, on a MessageEndpoint supplied from the app server, beforeDelivery([the onMessage method]); //this starts the jta tx and informs the adapter via an XAResource the adapter supplied earlier. onMessage(message); //actual message delivery to MessageListener afterDelivery(); //ends the tx, again the adapter is informed via the XAResource. I keep getting lost looking at the jms code. My impression so far is that although the jca 1 jmsra adapter appears to work ok without modifying jbossmq, using the contracts mentioned above will require additional code in jbossmq itself, namely an additional way of delivering messages within a transaction. Does this make sense? Do any of the jbossmq experts want to work on this? There are very simple examples of using the work and message endpoint interfaces in the testsuite in .../jca/inflow. I haven't written the deployment portion of the connector 1.5 support yet: I'm hoping for a real adapter example that can be used to test it. However, I think for now everything needed can be set up without a deployer as explicit mbeans: this is what I did in the tests. Thanks david jencks --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Peter Antman Chief Systems Architect, Business Development Technology in Media, Box 34105 100 26 Stockholm WWW: http://www.tim.seWWW: http://www.backsource.org Email: [EMAIL PROTECTED] Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942 --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE!
Re: [JBoss-dev] jbossmq and jca 1.5
Hi David I am still looking into the code to become an JMS expert but I would like to help to implement this. Because I added the Common Interfaces of JMS 1.1 it would like to use this opportunity to make the appropriate changes here. This week I am pretty busy. Have fun - Andy I started looking at modifying jbossmq and/or the jmsra adapter to work with the j2ee connector architecture 1.5 facilities. I am definitely not a jms expert so a lot of what I say may not make sense. Here's what the new spec provides that I think is relevant: thread pooling through the WorkManager interface. You submit Work instances to be done in other threads. The app server controls the thread pooling. message inflow through the MessageEndpoint interfaces. In particular, I think we should use Option B which involves the jms system calling, on a MessageEndpoint supplied from the app server, beforeDelivery([the onMessage method]); //this starts the jta tx and informs the adapter via an XAResource the adapter supplied earlier. onMessage(message); //actual message delivery to MessageListener afterDelivery(); //ends the tx, again the adapter is informed via the XAResource. I keep getting lost looking at the jms code. My impression so far is that although the jca 1 jmsra adapter appears to work ok without modifying jbossmq, using the contracts mentioned above will require additional code in jbossmq itself, namely an additional way of delivering messages within a transaction. Does this make sense? Do any of the jbossmq experts want to work on this? There are very simple examples of using the work and message endpoint interfaces in the testsuite in .../jca/inflow. I haven't written the deployment portion of the connector 1.5 support yet: I'm hoping for a real adapter example that can be used to test it. However, I think for now everything needed can be set up without a deployer as explicit mbeans: this is what I did in the tests. Thanks david jencks --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
