I can probably assist on this, as I have front end webservers (using plain Tomcat 7.x and Spring) connecting to a backend JBoss EAP 6.1 (that happens to also use Spring). This is all using JBoss's enchanced EJB remoting.
I do not fully understand how I got it to work it was a lot of trial and error.
Some things I learned:
* Do not have a file called jndi.properties in your web-app. This will interfere with Tomcat's own JNDI mechanism, such as for looking up JDBC connections. That needs to continue to keep working, the problem is that if you change the web-app environments config to use the alternative JNDI registry and services. Good if you are already running inside AS but not good for me, when I wanted Tomcat's regular and local JNDI to work, but have a few EJB remote beans to access another host on the network.
* Next I ensure I added dependencies for org.jboss.ejb.* into my WAR project (the client access code is an enchanced EJB remoting library that supports JBoss value added additional features, this is my understand anyway)
I am a maven user so this means I added (you shall need to resolve to the best versions to use for your particular version of JBoss AS / EAP / Wildfly:
[code]
<dependency>
<groupId>org.jboss</groupId>
<artifactId>jboss-ejb-client</artifactId>
</dependency>
<dependency>
<groupId>org.jboss</groupId>
<artifactId>jboss-remote-naming</artifactId>
</dependency>
<dependency>
<groupId>org.jboss.marshalling</groupId>
<artifactId>jboss-marshalling-river</artifactId>
</dependency>
<dependency>
<groupId>org.jboss.sasl</groupId>
<artifactId>jboss-sasl</artifactId>
</dependency>
<dependency>
<groupId>org.jboss.xnio</groupId>
<artifactId>xnio-nio</artifactId>
</dependency>
[/code]
* When setting up the JndiTemplate I chose to stay away from a bean called "jndiTemplate" as I think this maybe a magic name used by default (if it exists) that also affected badly. So I configured with:
[code]
<bean id="jbossJndiProperties" class="org.springframework.beans.factory.config.PropertiesFactoryBean">
<property name="location" value="classpath:/my-jndi.properties"/>
</bean>
[/code]
* The file /my-jndi.properties is a WAR toplevel level property file in the classpath, this means it src/main/resources/my-jndi.properties (in the Maven WAR project) or WEB-INF/classes/my-jndi.properties in the packaged WAR.
* In this file I have a single active line: java.naming.factory.url.pkgs=org.jboss.ejb.client.naming (it is my limited understanding, this overrides the default client implementation to instead use the JBoss enchanced EJB client not the JRE one, it is the JBoss enchancements that understand the configuration variable you are trying to set in the JNDI context environment.)
* I chose to configure each use of a remote EJB with xmlns:jee="http://www.springframework.org/schema/jee" and xsi:schemaLocation="http://www.springframework.org/schema/jee http://www.springframework.org/schema/jee/spring-jee.xsd",
* This means I used <jee:remote-slsb .../> modify this example to suit. My EJB was inside an EAR all using Maven to manage the project. The jndi-name is the fully qualified one you shall find emitted by JBoss AS / EAP / WildFly when it deploys the EJB with server logging enabled.
The use of ${ejbReference.earVersion} is some matter concerning a difference between testing and production environments in the as the item was versioned.
[code]
<jee:remote-slsb id="myStateless" jndi-name="ejb:com.domain.ear${ejbReference.earVersion}/com-domain-ejb-0.0.1-SNAPSHOT/MyStatelessImpl!com.domain.ejb.MyStateless"
business-interface="com.domain.ejb.MyStateless"
cache-home="true" lookup-home-on-startup="true" refresh-home-on-connect-failure="true" environment-ref="jbossJndiProperties">
</jee:remote-slsb>
[/code]
* Now we configure the JBoss enchanced EJB client part in the WAR property file jboss-ejb-client.properties (this file is magically looked for by the JBoss code).
Between devel (your local system), test (your testing platform) and live (the production environment) you tweat the 'remote.connections' and 'remote.clusters' lines,
obviously you should ideally remove all unused/unrequired credentials from the file that are not relevant to the environment in which you deploy the config.
My understanding is that port 4447 is the enchanced JBoss EJB remoting socket (which is not the standard port number for EJB)
In this file the specialized properties you are trying to configure can be setup (only JBoss enchanced EJB client codes look at this) :
[code]
#
# Not sure which things in this file are actually used.
##
endpoint.name=client-endpoint
#endpoint.create.options=
remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
#remote.connections=devel
remote.connections=test
#remote.connections=live
remote.connection.devel.host=127.0.0.1
remote.connection.devel.port=4447
remote.connection.devel.username=myusername
remote.connection.devel.password=myPaSsWoRD123456
remote.connection.test.host=10.123.52.87
remote.connection.test.port=4447
remote.connection.test.username=myusername
remote.connection.test.password=myPaSsWoRD123456
remote.connection.test.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=true
remote.connection.test.connect.options.org.xnio.Options.SASL_DISALLOWED_MECHANISMS=JBOSS-LOCAL-USER
remote.connection.live.host=10.212.70.125
remote.connection.live.port=4447
remote.connection.live.username=myusername
remote.connection.live.password=myPaSsWoRD123456
remote.connection.live.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=true
remote.connection.live.connect.options.org.xnio.Options.SASL_DISALLOWED_MECHANISMS=JBOSS-LOCAL-USER
remote.clusters=ejb
remote.cluster.ejb.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=true
remote.cluster.ejb.username=myusername
remote.cluster.ejb.password=myPaSsWoRD123456
#remote.connection.default.host=localhost
#remote.connection.default.port = 4447
#remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false
jboss.naming.client.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=true
jboss.naming.client.connect.options.org.xnio.Options.SASL_DISALLOWED_MECHANISMS=JBOSS-LOCAL-USER
jboss.naming.client.connect.options.org.xnio.Options.SASL_POLICY_NOPLAINTEXT=false
#jboss.naming.client.connect.options=
[/code]
* On the JBoss EJB server (AS/EAP/WildFly) you need to create the account that is used with username/password credentials as above.
This looks to have resulted in the file standalone/configuration/application-users.properties gaining an entry for the username/password-hashed.
Maybe the JBoss EJB / server configuration documentation is helpful on this point. Running the script $JBOSS_HOME/bin/add-user.* in the context of a non-admin application user.
* You need to ensure you have an appropiate profile for EJB and the subsystem enabled in the server configuration such as standalone/configuration/standalone-full.xml
I did experiment with the <management> and <security-realms> part of the config but it seems this was not needed in the final version that worked for me.
I would appreciate any indepth knowledge correcting any of my above claims. As I reiterate my configuration works by chance not by engineering, while there is documentation around the process of understanding what happens (the sequence of events) when an EJB client is library invokes on the server was better understood with the debugging and stepping into code! This is not good.
Also documentation on what all the defaults are,
How to turn on full debugging mode (hint make this easy!) so all configured options are dumped (as both client and server ends) during a remoting diagnostic session, if its possible to simplfy the steps by understanding the defaults better.
If would also be very good if there was a single Maven dependency maybe type=pom that was the collection of JARs needed for various JBoss EJB client profiles starting with 'all features with all the trimmings' down to 'basic remote EJB with SSL'. So save me having to track down what is compatible with that over multiple JARs needed on a foreign (non JBoss product) the client.