But I took this from a working code example. Is there a difference between the AS7 versions?

Other thing is that it looks like this is working by accident if you have a valid jboss-ejb-client.properties in the classpath, maybe this force the behaviour also ?!

It's not accident It's intentional. So if you have the jboss-ejb-client.properties in the classpath, the EJB client API will know what nodes to connect to (which by the way might even be totally different from what's specified in the PROVIDER_URL of the JNDI context). The reason remote-naming introduced that "jboss.naming.client.ejb.context" was to avoid forcing users to add a jboss-ejb-client.properties in their classpath for setting up nodes for EJB invocations. When that property is present, the remote-naming implementation will internally create a client context and add the connection created for the PROVIDER_URL, to the EJB client context.

That is excellent, thanks. However, I am still running into issues with this approach:

1. Without adding Context.SECURITY_PRINCIPAL and Context.SECURITY_CREDENTIALS I get "Authentication failed". How can we use anonymous security details with this approach? Not a deal breaker as we should be using security, but is it possible?

2. With this approach, I always get "No EJB receiver available for handling..." IllegalStateException whenever I try to use the bean. Any idea why?

Edit: The bean is annotated @Stateless @Remote(MyRemoteBean.class) and implements MyRemoteBean.

// stand-alone integration test (not run from within JBoss, and no jboss-ejb-client.properties available in the class path)

3. Prerequisites say object must be serializable. What does this mean to a remote EJB? The class itself is not distributed in any library, only the interface. Does this apply to our EJBs? Or only to the proxy (which we have no control over)?

1. Without adding Context.SECURITY_PRINCIPAL and Context.SECURITY_CREDENTIALS I get "Authentication failed". How can we use anonymous security details with this approach? Not a deal breaker as we should be using security, but is it possible?

Wolf answered that in his reply. In fact even that article I pointed to does mention that AS7.1 is secured by default and can't be accessed without appropriate security credentials being passed from client.

Shadow Creeper wrote:

2. With this approach, I always get "No EJB receiver available for handling..." IllegalStateException whenever I try to use the bean. Any idea why?

Edit: The bean is annotated @Stateless @Remote(MyRemoteBean.class) and implements MyRemoteBean.

// stand-alone integration test (not run from within JBoss, and no jboss-ejb-client.properties available in the class path)

Without looking at the entire exception stacktrace and the server side logs of what the JNDI names of that bean are, can't really say what's wrong.

Shadow Creeper wrote:

3. Prerequisites say object must be serializable. What does this mean to a remote EJB? The class itself is not distributed in any library, only the interface. Does this apply to our EJBs? Or only to the proxy (which we have no control over)?

That's a statement for all objects that are expected to be available remotely via JNDI (i.e. java:jboss/exported/ namespace). The EJB proxies are implemented and bound by the EJB container and it takes care of having it serializable.

Question 1 was about the fact that when using the jboss-ejb-client.properties file I can set the following to allow me to leave out login details. I don't want to do this in production, but I was just wondering if this was possible using the PROVIDER_URL method.

Previously (in JBoss5, and also in JBoss 7.1 when using the jboss-ejb-client.properties method) I would always close the Context after bean lookup (in the finally block as you can see above). Apparently, using the PROVIDER_URL, this causes the bean to disconnect.

Is this a bug? Or is this expected?

EDIT: This is really 2 separate new questions (the original question has been answered), moving this to another discussion. Thanks a ton to Wolf and Jaikiran!