2016-04-12 13 views
0

Ich suche EJBs, die auf einer WildFly-Server-Instanz (Zielserver) von einer anderen WildFly-Serverinstanz bereitgestellt werden, und lade sie auf. Dazu folge ich dem Link - 'https://docs.jboss.org/author/display/WFLY9/Developer+Guide#DeveloperGuide-EJBinvocationsfromaremoteserver'wildfly-9.0.2.Final - EJB-Aufrufe von einem Remote-Server

test.jar wurde auf dem Zielserver bereitgestellt. Im Folgenden sind die Bereitstellungsprotokolle aufgeführt.

16:34:46,545 INFO [org.jboss.weld.deployer] (MSC service thread 1-6) WFLYWELD0010: Stopping weld service for deployment test.jar 
16:34:46,569 INFO [org.jboss.as.server.deployment] (MSC service thread 1-7) WFLYSRV0028: Stopped deployment test.jar (runtime-name: test.jar) in 40ms 
16:34:46,573 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0027: Starting deployment of "test.jar" (runtime-name: "test.jar") 
16:34:46,588 INFO [org.jboss.weld.deployer] (MSC service thread 1-5) WFLYWELD0003: Processing weld deployment test.jar 
16:34:46,595 INFO [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-5) JNDI bindings for session bean named TestHelperBean in deployment unit deployment "test.jar" are as follows: 

java:global/test/TestHelperBean!moc.test.ejb.session.TestHelperLocal 
java:app/test/TestHelperBean!moc.test.ejb.session.TestHelperLocal 
java:module/TestHelperBean!moc.test.ejb.session.TestHelperLocal 
java:global/test/TestHelperBean!moc.test.ejb.session.TestHelperRemote 
java:app/test/TestHelperBean!moc.test.ejb.session.TestHelperRemote 
java:module/TestHelperBean!moc.test.ejb.session.TestHelperRemote 
java:jboss/exported/test/TestHelperBean!moc.test.ejb.session.TestHelperRemote 

16:34:46,610 INFO [org.jboss.weld.deployer] (MSC service thread 1-5) WFLYWELD0006: Starting Services for CDI deployment: test.jar 
16:34:46,614 INFO [org.jboss.weld.deployer] (MSC service thread 1-1) WFLYWELD0009: Starting weld service for deployment test.jar 
16:34:46,834 INFO [org.jboss.as.server] (XNIO-1 task-3) WFLYSRV0016: Replaced deployment "test.jar" with deployment "test.jar" 

Stateless Session-Bean wurde auf dem Zielserver bereitgestellt.

package moc.test.ejb.session; 
import javax.ejb.Remote; 
import javax.ejb.Stateless; 
import javax.ejb.Local; 
@Stateless 
@Remote (TestHelperRemote.class) 
@Local(TestHelperLocal.class) 
public class TestHelperBean implements TestHelperRemote,TestHelperLocal 
{ 
public boolean testFunction() throws Exception 
{ 
    try 
    { 
     System.out.println("[TestHelperBean][testFunction]"); 
    }catch(Exception e) 
    {} 
    return false; 
} 
} 

Folgendes ist der Client-Code, der die test.jarbanine-Instanz aufruft.

package com.testmodule.pojo; 
import java.util.Hashtable; 
import javax.naming.Context; 
import moc.test.ejb.session.TestHelperRemote; 
public class Test { 
public void getDbConnection(){ 
    try{ 
     final Hashtable<String, String> props = new Hashtable<String, String>();    
     props.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming"); // setup the ejb: namespace URL factory   
     final Context context = new javax.naming.InitialContext(props); // create the InitialContext 
     final TestHelperRemote bean = (TestHelperRemote) context.lookup("ejb:" + "" + "/" + "test" + "/" 
       + "" + "/" + "TestHelperBean" + "!" + moc.test.ejb.session.TestHelperRemote.class.getName()); 
     bean.testFunction();       
    } 
    catch(Exception e){e.printStackTrace();} 

aber zur Laufzeit aufgetreten folgende Fehler

15:58:48,972 ERROR [stderr] (default task-1) java.lang.IllegalStateException: EJBCLIENT000025: No EJB receiver available for handling [appName:, moduleName:test, distinctName:] combination for invocation context [email protected] 
15:58:48,973 ERROR [stderr] (default task-1) at org.jboss.ejb.client.EJBClientContext.requireEJBReceiver(EJBClientContext.java:774) 
15:58:48,974 ERROR [stderr] (default task-1) at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:116) 
15:58:48,974 ERROR [stderr] (default task-1) at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186) 
15:58:48,975 ERROR [stderr] (default task-1) at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:255) 
15:58:48,975 ERROR [stderr] (default task-1) at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:200) 
15:58:48,976 ERROR [stderr] (default task-1) at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:183) 

, warum dieser Fehler aufgetreten ist?

+1

Verwenden Sie den Namespace * ejb: * nicht wie in [WildFly Remote JNDI-Referenz] (https://docs.jboss.org/author/display/WFLY9/Remote+JNDI+) beschrieben, sondern mit dem Namespace * remote * Referenz + Update + Entwurf). Beachten Sie, dass der * http-remoting * -Client davon ausgeht, dass JNDI-Namen in Remote-Lookups relativ zum ** java: jboss/exportierten ** Namespace sind, ein Nachschlagen eines absoluten JNDI-Namens schlägt fehl. Daher sollten Sie die Suche auf 'test/TestHelperBean! Moc.test.ejb.session.TestHelperRemote' durchführen. – aribeiro

+0

@aribeiro ... Nach der Verwendung der Remote-Namespace-Suche JNDI ist NameNotFoundException aufgetreten .... javax.naming.NameNotFoundException: test/TestHelperBean! Moc.test.ejb.session.TestHelperRemote - Dienst jboss.naming.context.java.test . "TestHelperBean! Moc.test.ejb.session.TestHelperRemote" –

+1

Könnten Sie bitte Ihre Frage mit den Eigenschaften aktualisieren, die Sie verwendet haben, um diese neueste Suche einzurichten? – aribeiro

Antwort

1

Ihr Client (dh der Code, der versucht, einen Dienst aufzurufen) befindet sich in Wildfly-Instanz 1, wo Ihr Server (dh wo Ihr ejb bereitgestellt ist) auf Instanz 2 liegt. Nehmen wir an, dass Instanz 1 auf dem Standardport 8080 läuft Beispiel 2 läuft auf Port 8180

The link you used in your question, hat einen Abschnitt einen Sicherheitsbereich erstellen auf dem Client-Server, die die verschiedenen erforderlichen Schritte für die Erstellung von „outbound-socket-Bindung“ und „Remote-outbound- beschreiben aufgerufen Verbindung." Ich bin mir nicht sicher, ob Sie das schon getan haben oder nicht. Ohne diesen Schritt weiß die Anwendung von Instanz 1 nicht, wie sie sich mit dem Dienst von Instanz 2 verbinden soll.

Wenn Sie nicht auf die Konfigurationsroute gehen möchten, können Sie unter stackoverflow question - wildfly-to-wildfly-ejb-client-without-remote-outbound-connections eine gute Beschreibung erstellen. Diese Technik funktioniert für mich und könnte Ihnen helfen, Ihre eigene Lösung zu finden. Mit dieser Lösung können Sie die Serveradresse, den Port (in diesem Beispiel 8180), den Benutzernamen und das Passwort angeben, die für die Verbindung mit dem ejb benötigt werden, der auf der 2. Wildfly-Instanz gehostet wird.

Verwandte Themen