Remote JMS Connection Factory Is Not showing up on Local JND

[ioparra]

I'm currently running JBoss3.0 and have been connecting to another machine for JMS messages. On deployment, everything works fine. My MDB are finding the correct RemoteJMSProvider and attaching just fine.

The problem is when I attempt to grab a ConnectionFactory from JNDI. In 2.4.4, there where ConnectionFactoryLoaders that would bind a JMSProvider's connection factory to JNDI, but ConnectionFactoryLoaders are obsolete as of 3.0. After Searching some more, I found that the loading of the ConnectionFactories for 3.0 are now being done by the different ILservers(OIL, UIL, RMI, etc). The local JBoss Instance does not have an ILServer. What if the ConnectionFactory is for a remote server? How does the remote JMS put it's ConnectionFactory into the local JNDI tree? If I wanted to browse over any specific queues on these remote connections, how do I find the Queue from JNDI? If I specify the destinations within my local jms-destinations-service.xml, would the remote connection know that, while the JNDI references is to a local configuration, to really make a remote request?

Ultimately I'd like to know:
1) Is there an mbean entry that will generate a ConnectionFactory from a generic JMSProvider and bind this factory to JNDI? ie. do what the ConnectionFactoryLoader did pre 3.0.

2) After I have a connection, what can I assume about the JNDI entry for Queue/Topics. Should they exist in my local jboss-destinations-service.xml or should the loader create the jndi entry for me? I can see keeping this JNDI entry up-to-date as being an issue, but that's a slightly different problem.

Any Ideas?

The only I found to get around this problem is to grab the JMSProvider directly from JNDI, grab its Context and make directy JNDI call from that context.
-Ivan

[davidjencks]

The ConnectionFactoryLoader mbeans were replaced with various ConnectionManager mbeans. By default, the jms resource adapter is deployed using some of these. The configuration is in jms-service.xml, the main mbean is
jboss.jca:service=XaTxCM,name=jmsra

[ioparra]

Thanks David, modifying the XaTxCM and the XaTxDS did the trick. Unfortunately I'm still missing the Queue/Topic entries in JNDI. Any ideas on how to put a Remote Queue/Topic into JNDI???

[ioparra]

Thanks David-
Modifying the XaTxCM and the XaTxDS did the trick. Any ideas on how to get Remote Queues/Topics into the local JNDI?

[ioparra]

Apparently, if I deploy the jboss-destinations-service.xml on my local machine and specify that the queue/topic exist there, it then works. Victory!!!

[dshaul]

Hi ioparra
I have exatlly the same problem, you wrote:
>> modifying the XaTxCM and the XaTxDS did the trick
can you please send the modification line instead the XaTxCM and XaTxDs lines?
Thanks

[naka]

Hi Ivan,

I have an application that has MDBs and durable subscriptions to Topics. The whole set-up is currently on a single box with Red Hat Linux 7.2 server and JBoss 3.0.4 with Jetty.

I now have to move one Topic to another physical box with the same set-up (I may have to move other Topics too in future). I am new to JBoss/JMS and was going to post my query in the Beginners' Corner, but your "victory" seems to be the ideal solution for what I have on hand. Can you please help me with the steps?

Regards,
NK

[ioparra]

Sorry for taking so long to reply. I hope you have found your answer. I got hit with the post-dotcom syndrome and was unavailable for a stretch. But now I'm back in business. Find any results?

[hergaty]

hi ioparra,

can you send me your solution too? I've horrible trouble since upgrading from jboss-3.0 to 3.2.

thanks a lot,
thomas

[ccanning]

Hi ioparra,

Would it be possible to get a more detailed description of your process and config for JMS on multiple machines? Thanks.

[ioparra]

I'm sorry. Its been a year now and the company I was working for is no longer reachable. David may still have the answer. Perhaps if we plead and beg with him, he will enlighten us with his knowledge.

BTW. David, long time no talk. Sorry for being cocooned. Keep in mind, David is a busy guy!