3:19 a.m.
Darryl Miles [https://community.jboss.org/people/dlmiles] created the discussion
"Re: Remote EJB call (JBoss AS7/EAP6 )"
To view the discussion, visit: https://community.jboss.org/message/832943#832943
--------------------------------------------------------------
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 http://www.springframework.org/schema/jee"
and xsi:schemaLocation=" http://www.springframework.org/schema/jee
http://www.springframework.org/schema/jee
http://www.springframework.org/schema/jee/spring-jee.xsd
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.
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/832943#832943]
Start a new discussion in Snowdrop at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&...]