JBossDeveloper

You're close, but not quite there.  Try something like this:

                <connectors>

                    ...

                    <connector name="remote-jmsxa">

                        <factory-class>org.hornetq.core.remoting.impl.netty.NettyConnectorFactory</factory-class>

                        <param key="host" value="my.remote.host"/>

                        <param key="port" value="5445"/>

                    </connector>

                    ...

                </connectors>

                ...

                <jms-connection-factories>

                     ...

                    <pooled-connection-factory name="remote-hornetq-ra">

                        <transaction mode="xa"/>

                        <connectors>

                            <connector-ref connector-name="remote-jmsxa"/>

                        </connectors>

                        <entries>

                            <entry name="java:/RemoteJmsXA"/>

                        </entries>

                    </pooled-connection-factory>

                </jms-connection-factories>

You shouldn't need to add any kind of acceptor on the other side since there is already an acceptor (or should be) listening on 5445.

Another quick question, I am using blank Initial Context in JNDI lookup code so I am just wondering how would my JNDI lookup code would know that it has to lookup on local server or remote server?

A blank context simply means use the defaults which in JBoss AS means a local lookup.  If you wanted to perform a remote lookup you'd have to pass in the proper attributes, e.g.:

        final Properties env = new Properties();

        env.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");

        env.put(Context.PROVIDER_URL, "remote://localhost:4447");

        env.put(Context.SECURITY_PRINCIPAL, "username");

        env.put(Context.SECURITY_CREDENTIALS, "password");

        Context context = new InitialContext(env);

        Object obj = context.lookup("whatever");

In this case, the connection factory lookup is actually local since it is bound to the local JNDI namespace.  The fact that the local connection factory points to a remote server is essentially irrelevant for the purposes of the JNDI look-up.

Thanks a lot Justin. Finally, it worked :-) . So local connection factory pointing to remote server is required for MDB configuration.

So local connection factory pointing to remote server is required for MDB configuration.

This isn't strictly true.  You only need a <pooled-connection-factory> pointing to a remote server if your MDB needs to send messages to that remote server.  This has nothing to do with the MDB per se.  The MDB consumes messages from a remote server based on its activation configuration.

Hi,

do you mean that the "remote configuration elements" must always be in the MDB activation code and there is no other way ?

Is there a way to only declare a connection factory name & a queue name in the MDB code and let the low level elements (IP & Ports) externalized in the AS configuration XML files ?

do you mean that the "remote configuration elements" must always be in the MDB activation code and there is no other way ?

That's correct.  The MDB activation properties can either be set via annotations or via ejb-jar.xml.  Once AS7-3816 is resolved you will be able to put system properties in ejb-jar.xml instead of hard-coding the values.

Is there a way to only declare a connection factory name & a queue name in the MDB code and let the low level elements (IP & Ports) externalized in the AS configuration XML files ?

When you say MDB code do you mean in the MDB's onMessage() once the message has been received?

Hi Justin,

when I say "MDB code" I mean all the MDB java class source code.

My problem is to externalyze the IT configuration elements (IP, Ports, ...) from an application which will be bundled as a "simple EAR"...

Nor the two solutions are "production acceptable"

If you are inside an MDB then I assume you will need a connection factory for sending messages (rather than consuming them).  If that is the case then you can use a <pooled-connection-factory> which is 100% configured in standalone*.xml.  Check out the "JmsXA" connection factory in standalone*.xml for an example.  You can create a new <pooled-connection-factory> with a connector like this to reach a remote server:

   <connector name="remote-jmsxa">

      <factory-class>org.hornetq.core.remoting.impl.netty.NettyConnectorFactory</factory-class>

      <param key="host" value="remoteHost"/>

      <param key="port" value="5445"/>

   </connector>

A <pooled-connection-factory> has the benefit of pooling (obviously) and of easy configuration. 

However, if for some reason you wanted to create the connection yourself then you could declare system properties in standalone*.xml and look those up in your code using System.getProperty(..).

Note that by default remote access is secured, so you will have to configure a username and password on the PCF (unless you disable security).

All this seems beautifull but where can I found a ALL-IN-ONE clear example ?

I always found "solution sub-parts" but nowhere one full article where all is well explained

Here is my today knowledge :

Read from local JMS with half-externalized configuration : YES

Write to local JMS with half-externalized configuration : YES

Read from local JMS with full-externalized configuration : YES

Write to local JMS with full-externalized configuration : YES

Read from remote JMS with half-externalized configuration : YES

Write to remote JMS with half-externalized configuration : YES

Read from remote JMS with full-externalized configuration : NO

Write to remote JMS with full-externalized configuration : NO

haf-externalized : IT elements are somewhere in the EAR (Class code or EJB-JAR.XML).

full-externalized : IT elements are defined in the JBoss HornetQ XML files, nothing is hard-coded in the EAR.

Read from remote JMS with full-externalized configuration : NO

As I said, this won't be possible until AS7-3816 is resolved.

Write to remote JMS with full-externalized configuration : NO

This is what I was talking about in my previous comment.  What specific part of this isn't clear?