What is your client doing with the connection factory? Is it just sending messages?
Not only, it subscribes to topics also
If you are subscribing to topics in the container then you really should be using an MDB to leverage all the benefits of Java EE (e.g. transactions, security, easy instance and session pooling). However, if you're set against that then you can use "java:/ConnectionFactory" to consume messages. It uses a HornetQ "in-vm" connector which is optimized for local use.
If you are sending messages within the container you should use "java:/JmsXA" which is pooled.
As you know, you should use "jms/RemoteConnectionFactory" from remote clients.
I have server-side class and unit test, which tests this class in client VM. In Jboss 4 it used to work, now there is some artificial constraint and JNDI names are different for in-VM and remote invocation. My question was how to work around this strange behaviour.
In Jboss 4 it used to work, now there is some artificial constraint and JNDI names are different for in-VM and remote invocation. My question was how to work around this strange behaviour.
JBoss AS 7 is quite different than JBoss AS 4.x. As you can imagine, much has changed since 2004 when AS 4.x was first released.
Different connection factories are optimized for different use-cases. They are named and bound in JNDI to make it (relatively) easy to see that. Furthermore, only JNDI bindings in "java:jboss/exported" are visible to remote clients. Whether or not you call that an "artificial constraint" or "strange" is up to you.
If you want to use the same JNDI name for both remote and local clients you simply need to configure them appropriately, e.g.:
<connection-factory name="RemoteConnectionFactory"> <connectors> <connector-ref connector-name="netty"/> </connectors> <entries> <entry name="java:jboss/exported/ConnectionFactory"/> </entries> </connection-factory>
Then you should be able to use "ConnectionFactory" both locally and remotely.
Many thanks, I will try this.