Serwer RMI: rmiregistry lub LocateRegistry.createRegistry

Question

Dla RMI po stronie serwera, czy musimy uruchomić program rmiregistry, czy po prostu zadzwonić pod numer LocateRegistry.createRegistry? Jeśli obie są możliwe, jakie są zalety i wady?

Answer 1

To jedna rzecz ... rmiregistry to osobny program, który można uruchomić z wiersza poleceń lub skryptu, podczas gdy LocateRegistry.createRegistry robi to samo programowo.

Z mojego doświadczenia wynika, że ​​w przypadku "prawdziwych" serwerów należy używać rmiregistry, aby wiedzieć, że zawsze działa niezależnie od tego, czy aplikacja kliencka jest uruchamiana, czy nie. createRegistry jest bardzo przydatny do testowania, ponieważ możesz w razie potrzeby uruchomić i zatrzymać rejestr z testu.

Answer 2

Jeśli piszesz samodzielną aplikację java, powinieneś zacząć swoją własną bibliotekę, ale jeśli piszesz aplikację J2EE, która oczywiście działa wewnątrz kontenera J2EE, to chcesz "LocateRegistry", ponieważ jest już uruchomiona na serwer aplikacji!

Answer 3

Jeśli używasz Spring do eksportowania usług RMI, automatycznie uruchamia rejestr, jeśli jeszcze nie jest uruchomiony. Zobacz RmiServiceExporter

Answer 4

Jeśli zaczniemy od pierwszej rmiregistry, RmiServiceExporter zarejestruje się w bieżącej rmiregistry. W tym przypadku musimy ustawić właściwość systemową "java.rmi.server.codebase", gdzie znajduje się klasa "org.springframework.remoting.rmi.RmiInvocationWrapper_Stub". W przeciwnym razie, RmiServiceExporter nie będzie uruchomiony i dostał wyjątek „ klasa ClassNotFoundException nie znaleziono: org.springframework.remoting.rmi.RmiInvocationWrapper_Stub; wyjątek zagnieżdżonych jest: ...”

Jeśli serwer RMI, klient RMI i rmiregistry może uzyskać dostęp do tego samego systemu plików, możesz chcieć, aby właściwość systemowa była automatycznie konfigurowana do miejsca, w którym plik spring.jar znajduje się w udostępnionym systemie plików. Poniższe klasy narzędzi i konfiguracja sprężyn pokazują, w jaki sposób można to osiągnąć.

abstract public class CodeBaseResolver { 
    static public String resolveCodeBaseForClass(Class<?> clazz) { 
    Assert.notNull(clazz); 
    final CodeSource codeSource = clazz.getProtectionDomain().getCodeSource(); 
    if (codeSource != null) { 
     return codeSource.getLocation().toString(); 
    } else { 
     return ""; 
    } 
    } 
} 

public class SystemPropertyConfigurer { 
    private Map<String, String> systemProperties; 
    public void setSystemProperties(Map<String, String> systemProperties) { 
    this.systemProperties = systemProperties; 
    } 

    @PostConstruct 
    void init() throws BeansException { 
    if (systemProperties == null || systemProperties.isEmpty()) { 
     return; 
    } 
    for (Map.Entry<String, String> entry : systemProperties.entrySet()) { 
     final String key = entry.getKey(); 
     final String value = SystemPropertyUtils.resolvePlaceholders(entry.getValue()); 
     System.setProperty(key, value); 
    } 
    } 
} 


<bean id="springCodeBase" class="org.springframework.beans.factory.config.MethodInvokingFactoryBean"> 
    <property name="staticMethod" value="xx.CodeBaseResolver.resolveCodeBaseForClass" /> 
    <property name="arguments"> 
    <list> 
     <value>org.springframework.remoting.rmi.RmiInvocationWrapper_Stub</value> 
    </list> 
    </property> 
</bean> 

<bean id="springCodeBaseConfigurer" class="xx.SystemPropertyConfigurer" 
    depends-on="springCodeBase"> 
    <property name="systemProperties"> 
    <map> 
     <entry key="java.rmi.server.codebase" value-ref="springCodeBase" /> 
    </map> 
    </property> 
</bean> 

<bean id="rmiServiceExporter" class="org.springframework.remoting.rmi.RmiServiceExporter" depends-on="springCodeBaseConfigurer"> 
    <property name="serviceName" value="XXX" /> 
    <property name="service" ref="XXX" /> 
    <property name="serviceInterface" value="XXX" /> 
    <property name="registryPort" value="${remote.rmi.port}" /> 
</bean> 

Powyższy przykład pokazuje, jak właściwość systemu można ustawić automatycznie tylko wtedy, gdy serwer RMI, klient RMI i rejestru RMI może dostęp do tego samego systemu plików. Jeśli to nie jest prawda lub baza kodów źródłowych Spring jest udostępniana za pomocą innej metody (np. HTTP), możesz zmodyfikować CodeBaseResolver zgodnie ze swoimi potrzebami.