-
1. Re: EJB call from one EAR to another EAR, local or remote?
dmlloyd May 23, 2018 1:56 PM (in response to mevans7)As you've discovered, you'll be facing ClassCastExceptions if you try to make local invocations between two application modules which have different copies of the classes in question. You should probably use remote invocation for this unless you're ready to restructure things. The good news though is that in-VM remote EJB invocation is very optimized so that no network connection should be necessary. This means you don't have to worry about TLS or network latency.
-
2. Re: EJB call from one EAR to another EAR, local or remote?
mevans7 May 23, 2018 2:23 PM (in response to dmlloyd)I can use remote interface calls. But I'm left with the problem that in a two way SSL/TLS configuration, WildFly 12 requires the client certificate in order to access the "remove" (yet local) EJB. This behavior is different than from WildFly 10. I was hoping that these calls would be considered "local" internally and not require the client keys.
How can I make remote EJB calls from one EE application to another (deployed in the same server) without having to supply a client private key certificate to WildFly 12?
-
3. Re: EJB call from one EAR to another EAR, local or remote?
dmlloyd May 23, 2018 2:29 PM (in response to mevans7)That sounds very odd, like either there is some configuration problem or a bug. Or both. You should not need a client certificate in order to call an EJB on the same JVM.
-
4. Re: EJB call from one EAR to another EAR, local or remote?
mevans7 May 23, 2018 8:02 PM (in response to dmlloyd)I re-tested two way SSL/TLS in WildFly 12 to be sure of the failure. If I don't have client certificates defined in standalone.sh, and I have one EJB call another via remote interface, I get the following exception:
2018-05-23 16:48:28,628 ERROR [org.jboss.as.ejb3.invocation] (default task-5) WFLYEJB0034: EJB Invocation failed on component MyFirstBean for method ... java.rmi.RemoteException: org.jboss.ejb.client.RequestSendFailedException: EJBCLIENT000409: No more destinations are available
at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:567) [jboss-ejb-client-4.0.9.Final.jar:4.0.9.Final]
at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503) [jboss-ejb-client-4.0.9.Final.jar:4.0.9.Final]
at org.jboss.ejb.protocol.remote.RemotingEJBClientInterceptor.handleInvocationResult(RemotingEJBClientInterceptor.java:56) [jboss-ejb-client-4.0.9.Final.jar:4.0.9.Final]
at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:569) [jboss-ejb-client-4.0.9.Final.jar:4.0.9.Final]
at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503) [jboss-ejb-client-4.0.9.Final.jar:4.0.9.Final]
at org.jboss.ejb.client.TransactionPostDiscoveryInterceptor.handleInvocationResult(TransactionPostDiscoveryInterceptor.java:133) [jboss-ejb-client-4.0.9.Final.jar:4.0.9.Final]
at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:569) [jboss-ejb-client-4.0.9.Final.jar:4.0.9.Final]
at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503) [jboss-ejb-client-4.0.9.Final.jar:4.0.9.Final]
at org.jboss.ejb.client.DiscoveryEJBClientInterceptor.handleInvocationResult(DiscoveryEJBClientInterceptor.java:108) [jboss-ejb-client-4.0.9.Final.jar:4.0.9.Final]
at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:569) [jboss-ejb-client-4.0.9.Final.jar:4.0.9.Final]
at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503) [jboss-ejb-client-4.0.9.Final.jar:4.0.9.Final]
at org.jboss.ejb.client.NamingEJBClientInterceptor.handleInvocationResult(NamingEJBClientInterceptor.java:78) [jboss-ejb-client-4.0.9.Final.jar:4.0.9.Final]
at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:569) [jboss-ejb-client-4.0.9.Final.jar:4.0.9.Final]
at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503) [jboss-ejb-client-4.0.9.Final.jar:4.0.9.Final]
at org.jboss.ejb.client.TransactionInterceptor.handleInvocationResult(TransactionInterceptor.java:172) [jboss-ejb-client-4.0.9.Final.jar:4.0.9.Final]
at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:569) [jboss-ejb-client-4.0.9.Final.jar:4.0.9.Final]
at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503) [jboss-ejb-client-4.0.9.Final.jar:4.0.9.Final]
at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:913) [jboss-ejb-client-4.0.9.Final.jar:4.0.9.Final]
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:177) [jboss-ejb-client-4.0.9.Final.jar:4.0.9.Final]
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:112) [jboss-ejb-client-4.0.9.Final.jar:4.0.9.Final]
at com.sun.proxy.$Proxy128.amethod(Unknown Source)
at com.mycompany.mymethod(MyFile.java:197) [MyJar.jar:]
If I add -Djavax.net.ssl.keystore=/my-client.keystore, and -Djavax.net.ssl.keyStorePassword=my-password to the standalone.sh file (on the lines where the eval \"$JAVA\"... are, then the remote EJB methods get executed just fine.
(For both tests) I configure two way SSL/TLS by adding the following in my equivalent of standalone-full.xml:
<security-realm name="MYRealm">
<server-identities>
<ssl>
<keystore path="server.keystore" relative-to="jboss.server.config.dir" keystore-password="my-password" alias="my-alias" key-password="my-password"/>
</ssl>
</server-identities>
<authentication>
<truststore path="server.truststore" relative-to="jboss.server.config.dir" keystore-password="my-password"/>
<jaas name="my-security-domain"/>
</authentication>
</security-realm>
...
<https-listener name="https" disallowed-methods="TRACE DUMMY" max-post-size="104857600" enabled-protocols="TLSv1.2" verify-client="REQUIRED" security-realm="MYRealm" socket-binding="https"/>
The remote EJB calls work on WildFly 10 without having to add the keystores to the standalone.sh file.
Am I configuring something incorrectly?
-
5. Re: EJB call from one EAR to another EAR, local or remote?
mevans7 Aug 10, 2018 8:41 PM (in response to mevans7)Does anyone have any comments with respect to using two way SSL/TLS with application to application EJB calls?
My scenario is above. I have in ejb3:
<remote connector-ref="http-remoting-connector" thread-pool-name="default"/>
In remoting:
<http-connector name="http-remoting-connector" connector-ref="https"/>
In undertow:
<https-listener name="https" socket-binding="https" max-post-size="104857600" disallowed-methods="TRACE" ssl-context="https-two-way-server-ssl-context"/>
And the ssl-context is configured with a key-manager and a trust-manager.
This results in an error when calling an EJB from and in-WildFly deployed application (remote because calling application is deployed in a different war/ear).
If I add the -Djavax.net.ssl.* values to standalone.sh, then the error goes away.
How can I secure my server with SSL yet not have to secure in-server cross-deployment EJB calls? Or, can I have two separate connections (EJB receivers? listeners? other?), one for internal and one for external?