Java rmi error unmarshalling arguments

Перейти к содержанию

Перейти к содержанию

На чтение 2 мин Просмотров 411 Опубликовано 19.05.2010

Java RMI(Java Remote Method Invocation) is a Java API that performs the object-oriented equivalent of remote procedure calls (RPC), it allows an object running in one Java virtual machine to invoke methods on an object running in another Java virtual machine. It provides for remote communication where all participating applications are written by Java.

Today, when I ran a “hello world” example, unfortunately I got the following error messages:

Exception in thread "main" java.rmi.MarshalException: error marshalling arguments; nested exception is:
java.io.NotSerializableException: server.Hello
at sun.rmi.registry.RegistryImpl_Stub.rebind(Unknown Source)
at java.rmi.Naming.rebind(Naming.java:160)
at server.HelloServer.main(HelloServer.java:24)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:592)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:90)
Caused by: java.io.NotSerializableException: server.Hello
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1081)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:302)
... 8 more

The Java RMI server ran on IDEA9.0 and the Java version is “1.6.0_18″. I confused a lot why this error occurs, my initial understanding was, perhaps, caused by that the JVM engine is not able to detect where are the serialized class or data, but quickly I learned that a required class was missing in classpath.

A Java class can be turned to be remotely accessible by implementing a custom remote interface, it have to extend uka.karmi.rmi.Remote and UnicastRemoteObjectUnicastRemoteObject both, UnicastRemoteObject is exported in constructor, but my remote object has not implemented class UnicastRemoteObject. I extended UnicastRemoteObject for calss Hello then “java rmi error unmarshalling arguments” error was gone.
This is code what the error unmarshalling arguments occurs:

public class Hello implements HelloInterface {
  public Hello() throws RemoteException {
  }

  public String sayHello() throws RemoteException {
    return "good hello";
  }
}

I fixed code as below to resolve error unmarshalling arguments:

public class Hello extends UnicastRemoteObject implements HelloInterface {
  public Hello() throws RemoteException {
  }

  public String sayHello() throws RemoteException {
    return "good hello";
  }

}

Содержание

  1. Why am i getting «Unmarshalling Exceptions»
  2. Comments
  3. Java remote interface — RMI tutorial — error: unmarshalling arguments
  4. Динамическая загрузка кода, используя Java™ RMI (Используя java.rmi.server.codebase Свойство)
  5. 1.0 Начинаясь
  6. 2.0 Какова кодовая база?
  7. 3.0 Как это работает?
  8. 3.1 Как кодовая база используется в апплетах
  9. 3.2 Как кодовая база используется в Java RMI
  10. 4.0 Используя кодовую базу в Java RMI для больше чем только тупиковой загрузки
  11. 5.0 Примеры командной строки
  12. Примеры
  13. 6.0 Поиск и устранение неисправностей подсказок
  14. 6.1 Если Вы встречаетесь с проблемой, выполняющей Ваш Java сервер RMI
  15. 6.2 Если Вы встречаетесь с проблемой, выполняющей Ваш Java клиент RMI

Why am i getting «Unmarshalling Exceptions»

I have tried to run an application on my server, but when i execute the java server code i get the following exception

java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:

java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
java.lang.ClassNotFoundException: ext.bt.ppd.extract.mathCalcImp_Stub
java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
java.lang.ClassNotFoundException: ext.bt.ppd.extract.mathCalcImp_Stub
java.lang.ClassNotFoundException: ext.bt.ppd.extract.mathCalcImp_Stub
at java.lang.Throwable.fillInStackTrace(Native Method)
at java.lang.Throwable.fillInStackTrace(Compiled Code)
at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(Compiled Code)
at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:224)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:358)
at sun.rmi.registry.RegistryImpl_Stub.rebind(Unknown Source)
at java.rmi.Naming.rebind(Naming.java:165)
at ext.bt.ppd.extract.calcServ.main(calcServ.java:30)
RemoteException occurred in server thread; nested exception is:
java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
java.lang.ClassNotFoundException: ext.bt.ppd.extract.mathCalcImp_Stub

The Stub and Skel have been placed in codebase directory but yet it wont work. When i tried it on a Apache Server it worked fine

Still your problem looks like a codebase thing.

ext.bt.ppd.extract.mathCalcImp_Stub should be accessible via codebase. If it is in a jar file, check that your codebase includes the jar file:
-Djava.rmi.server.codebase=http://host:port/jarfile.jar

if not be sure to add a final slash on it
-Djava.rmi.server.codebase=http://host:port/directory/

and to have the right file structure.

Источник

Java remote interface — RMI tutorial — error: unmarshalling arguments

Hi!
Trying to test the rmi tutorial via Netbeans to set up a remote server — client interface.
When running the server the following exception appears:

exception: java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
java.lang.ClassNotFoundException: remotetests.MyRemoteInterface

The rmi registry is running in the background.

It seems the server is unable to publish the remote object??
Below are server, remote interface and client classes

Please help — Thanks!

The server class looks like this:

import java.io.Serializable;
import java.net.InetAddress;
import java.rmi.*;
import java.rmi.registry.LocateRegistry;
import java.rmi.server.*;

+public class MyRemoteClass extends UnicastRemoteObject implements MyRemoteInterface, Serializable <+

+public MyRemoteClass() throws RemoteException <+
+//Constructor code+
System.out.println(«MyRemote constructor»);
+>+

+public void myMethod1() throws RemoteException <+
+//Here we put the code we want+
System.out.println(«I am in myMethod1()»);
+>+

+public int myMethod2() throws RemoteException <+
return 5; //Here we put the code we want
+>+

+public void anotherMethod() <+
+//If we define another method, this can´t be called in a remote way unless we call it from the remote interface+
+>+

+public static void main(String[] args) <+
+try <+
System.out.println(«running main»);
MyRemoteInterface mir = new MyRemoteClass();
InetAddress address = java.net.InetAddress.getLocalHost();
System.out.println(«host name : « address.getHostName());+
+// Naming.rebind(«//»+java.net.InetAddress.getLocalHost().getHostAddress() +»/RMI_Test», mir); //»:» ++args[0]+
LocateRegistry.getRegistry().rebind(«//»java.net.InetAddress.getLocalHost().getHostAddress(), mir);+
+// System.out.println(«Server started. Bound RMI test»);+
+> catch (Exception e) <+
System.err.println(«exception: « e);+
+>+
+>+
+>+

The remote interface class:

package remotetests;
import java.rmi.*;

+public interface MyRemoteInterface extends Remote <+

public void myMethod1() throws RemoteException;

public int myMethod2() throws RemoteException;

Источник

Динамическая загрузка кода, используя Java™ RMI
(Используя java.rmi.server.codebase Свойство)

Это учебное руководство организуется следующим образом:

1.0 Начинаясь

Одна из старших значащих возможностей платформы Java™ является возможностью динамически загрузить программное обеспечение Java с любого Универсального Локатора Ресурса (URL) к виртуальной машине (VM), работающий в отдельном процессе, обычно на различной физической системе. Результат состоит в том, что удаленная система может выполнить программу, например апплет, который никогда не устанавливался на его диске. Для первых немногих разделов этого документа будет обсуждена кодовая база относительно апплетов, чтобы помочь описать кодовую базу относительно Java Удаленный Вызов метода (Java RMI).

Например, VM, работающий изнутри веб-браузера, может загрузить байт-коды для подклассов java.applet.Applet и любые другие классы необходимы тому апплету. Система, на которой работает браузер, наиболее вероятно никогда не выполняла этот апплет прежде, ни устанавливала его на его диске. Как только все необходимые классы были загружены с сервера, браузер может запустить выполнение программы апплета, используя локальные ресурсы системы, на которой работает клиентский браузер.

RMI Java использует в своих интересах эту возможность загрузить и выполнить классы и на системах, где те классы никогда не устанавливались на диске. Используя Java API RMI любой VM, не только те в браузерах, может загрузить любой Java файл class включая специализированный Java классы тупика RMI, которые включают выполнению вызовов метода на удаленном сервере, используя системные ресурсы сервера.

Понятие кодовой базы происходит из использования ClassLoader s в языке программирования Java. Когда программа Java использует a ClassLoader , тот загрузчик class должен знать расположение (я), из которого нужно позволить загрузить классы. Обычно, загрузчик class используется в соединении с сервером HTTP, который подает скомпилированные классы для платформы Java. Наиболее вероятно, первое ClassLoader / кодовая база, соединяющая это, Вы вошли в контакт с, был AppletClassLoader , и часть «кодовой базы» HTML-тэг, таким образом, это учебное руководство предположит, что у Вас есть некоторый опыт с Java программирование RMI, так же как запись файлов HTML, которые содержат теги апплета. Например, источник HTML будет содержать что-то как:

2.0 Какова кодовая база?

Кодовая база может быть определена как источник, или место, из которого можно загрузить классы в виртуальную машину. Например, если бы Вы пригласили нового друга к себе на обед, то Вы должны были бы дать тому другу направления месту, где Вы жили, так, чтобы он или она мог определить местоположение Вашего дома. Точно так же можно думать о кодовой базе как о направлениях, которые Вы даете VM, таким образом, это может найти Ваш [потенциально отдаляют] классы.

Можно думать о Вашем CLASSPATH как «локальная кодовая база», потому что это — список мест на диске, из которого Вы загружаете локальные классы. Загружая классы из локального находящегося на диске источника, Вашего CLASSPATH с переменной консультируются. Ваш CLASSPATH может быть установлен взять или относительные или абсолютные пути к каталогам и/или архивам файлов class. Так так же, как CLASSPATH своего рода «локальная кодовая база», кодовая база, используемая апплетами и удаленными объектами, может считаться «удаленной кодовой базой».

3.0 Как это работает?

3.1 Как кодовая база используется в апплетах

Чтобы взаимодействовать с апплетом, тот апплет и любые классы, которые это должно выполнить, должны быть доступными удаленными клиентами. В то время как к апплетам можно получить доступ от» ftp:// «или локальный» file:/// «URL, к ним обычно получают доступ от удаленного сервера HTTP.

  1. Клиентский браузер запрашивает апплет class, который не находится в клиенте CLASSPATH
  2. Определение class апплета (и любой другой class, в котором это нуждается) загружается от сервера до клиента, использующего HTTP
  3. Апплет выполняется на клиенте

Рисунок 1: Загрузка апплетов

Кодовая база апплета всегда относительно URL страницы HTML в который тег содержится.

3.2 Как кодовая база используется в Java RMI

Используя Java RMI, приложения могут создать удаленные объекты, которые принимают вызовы метода от клиентов в другом VMs. Для клиента, чтобы вызвать методы на удаленном объекте, у клиента должен быть способ связаться с удаленным объектом. Вместо того, чтобы иметь необходимость программировать клиент, чтобы говорить протокол удаленного объекта, Java, RMI использует специальные классы, названные тупиками, которые могут быть загружены на клиент, которые используются, чтобы связаться с (сделайте вызовы метода на), удаленный объект. java.rmi.server.codebase значение свойства представляет одно или более расположений URL, с которых могут быть загружены эти тупики (и любые классы, необходимые тупикам).

Как апплеты, должны были выполниться классы, удаленные вызовы метода могут быть загружены с» file:/// «URL, но как апплеты,» file:/// «URL обычно требует, чтобы клиент и сервер находились на том же самом физическом узле, если файловая система, упомянутая URL, не делается доступным использованием некоторого другого протокола, такого как NFS.

Обычно, классы должны были выполниться, удаленные вызовы метода должны быть сделаны доступными из сетевого ресурса, такого как сервер FTP или HTTP.

Рисунок 2: Загрузка Java тупики RMI

  1. Кодовая база удаленного объекта определяется сервером удаленного объекта, устанавливая java.rmi.server.codebase свойство. Java сервер RMI регистрирует удаленный объект, связанный с именем, с Java реестр RMI. Набор кодовой базы на сервере VM аннотируется к ссылке удаленного объекта в Java реестр RMI.
  2. Java клиент RMI запрашивает ссылку на именованный удаленный объект. Ссылка (тупиковый экземпляр удаленного объекта) — то, что клиент будет использовать, чтобы сделать удаленные вызовы метода удаленного объекта.
  3. Java реестр RMI возвращает ссылку (тупиковый экземпляр) к требуемому class. Если определение class для тупикового экземпляра может быть найдено локально в клиенте CLASSPATH , который всегда ищется перед кодовой базой клиент загрузит class локально. Однако, если определение для тупика не находится в клиенте CLASSPATH , клиент попытается получить определение class от кодовой базы удаленного объекта.
  4. Клиент запрашивает определение class от кодовой базы. Кодовой базой, которую использует клиент, является URL, который аннотировался к тупиковому экземпляру, когда тупиковый class был загружен реестром. Назад в шаге 1, аннотируемый тупик для экспортируемого объекта был тогда зарегистрирован в Java реестр RMI, связанный с именем.
  5. Определение class для тупика (и любой другой class, в котором это нуждается) загружается на клиент. Отметьте:Шаги 4 и 5 являются шагами sames, которые реестр сделал, чтобы загрузить удаленный объект class, когда удаленный объект был связан с именем в (зарегистрированный в) Java реестр RMI. Когда реестр, предпринятый, чтобы загрузить тупиковый class удаленного объекта, это запрашивало определение class от кодовой базы, связанной с тем удаленным объектом.
  6. Теперь у клиента есть вся информация, что она должна вызвать удаленные методы на удаленный объект. Тупиковый экземпляр действует как прокси к удаленному объекту, который существует на сервере; так в отличие от апплета, который использует кодовую базу, чтобы выполнить код в его локальном VM, Java, клиент RMI использует кодовую базу удаленного объекта, чтобы выполнить код в другом, потенциально отдалить VM, как иллюстрировано в рисунке 3:

Рисунок 3: Java клиент RMI, делающий удаленный вызов метода

4.0 Используя кодовую базу в Java RMI для больше чем только тупиковой загрузки

В дополнение к загрузке тупиков и их связанных классов клиентов, java.rmi.server.codebase свойство может использоваться, чтобы определить расположение, с которого может быть загружен любой class, не только тупики.

Когда клиент делает вызов метода удаленного объекта, метод, который это вызывает, мог быть записан, чтобы не принять параметры или много параметров. Есть три отличных случая, которые могут произойти, основанные на типе (ах) данных параметра (ов) метода.

В первом случае все параметры метода (и возвращаемое значение) являются примитивными типами данных, таким образом, удаленный объект знает, как интерпретировать их как параметры метода, и нет никакой потребности проверить CLASSPATH или любая кодовая база.

Во втором случае, по крайней мере одном удаленном параметре метода или возвращаемом значении объект, для которого удаленный объект может найти определение class локально в CLASSPATH .

В третьем случае (показанный как Шаг 6, в рисунке 4), удаленный метод получает объектный экземпляр, для которого удаленный объект не может найти определение class локально в CLASSPATH . Этот тип удаленного вызова метода иллюстрируется в рисунке 4. class объекта, отправленного клиентом, будет подтипом объявленного типа параметра. Подтип также:

  • Реализация интерфейса, который объявляется как параметр метода (или возврат) тип
  • Подкласс class, который объявляется как параметр метода (или возврат) тип

Рисунок 4: Java клиент RMI, делающий удаленный вызов метода, передавая неизвестный подтип как параметр метода

7. Как кодовая база апплета, определенная клиентом кодовая база используется, чтобы загрузить Remote классы, неудаленные классы, и интерфейсы к другому VMs. Если codebase свойство устанавливается на клиентском приложении, тогда та кодовая база аннотируется к экземпляру подтипа, когда подтип class загружается клиентом. Если кодовая база не будет установлена на клиенте, то удаленный объект будет по ошибке использовать свою собственную кодовую базу.

5.0 Примеры командной строки

В случае апплета значение кодовой базы апплета встраивается в страницу HTML, как мы видели в примере HTML в первом разделе этого учебного руководства.

В случае Java кодовая база RMI, вместо того, чтобы иметь ссылку на class, встроенный в страницу HTML, клиент первые контакты Java реестр RMI для ссылки на удаленный объект. Поскольку кодовая база удаленного объекта может обратиться к любому URL, не только тому, который является относительно известного URL, значения Java, кодовой базой RMI должен быть абсолютный URL к расположению тупикового class и любых других классов, необходимых тупиковому class. Это значение codebase свойство может обратиться к:

  • URL каталога, в котором классы организуются в названных в честь пакета подкаталогах
  • URL файла JAR, в котором классы организуются в названных в честь пакета каталогах
  • Разграниченная пространством строка, содержащая многократные экземпляры файлов JAR и/или каталогов, которые соответствуют критериям выше

Отметьте: Когда codebase значение свойства устанавливается в URL каталога, значение должно быть завершено «/».

Примеры

Если расположение Ваших загружаемых классов находится на сервере HTTP, названном «webvector», в каталоге «экспорт» (под веб-корнем), Ваш codebase установка свойства могла бы быть похожей на это:

Если расположение Ваших загружаемых классов находится на сервере HTTP, названном «webline», в файле JAR, названном «mystuff.jar», в каталоге «общественность» (под веб-корнем), Ваш codebase установка свойства могла бы быть похожей на это:

Теперь давайте предположим, что расположение Ваших загружаемых классов было разделено между двумя файлами JAR, «myStuff.jar» и «myOtherStuff.jar». Если эти файлы JAR располагаются на различных серверах (названный «webfront» и «webwave»), Ваш codebase установка свойства могла бы быть похожей на это:

6.0 Поиск и устранение неисправностей подсказок

Любой сериализуемый class, включая Java тупики RMI, может быть загружен, если Ваш Java программы RMI конфигурируется должным образом. Вот условия, при которых будет работать динамическая тупиковая загрузка:

  1. Тупиковый class и любой из классов, на которые полагается тупик, подаются от URL, достижимого от клиента.
  2. java.rmi.server.codebase свойство было установлено на программе сервера (или в случае активации, программы «установки»), который делает звонок bind или rebind , так, что:
    • Значение codebase свойством является URL в шаге A
  • Если URL, определенный как значение codebase свойство является каталогом, оно должно закончиться в запаздывании «/»
  • rmiregistry не может найти тупиковый class или любой из классов, на которые тупик полагается в CLASSPATH . Это — так кодовая база, аннотируется к тупику, когда реестр делает свою загрузку class тупика, в результате звонков bind или rebind в сервере или коде установки.
  • Клиент установил a SecurityManager это позволяет тупику быть загруженным. В Java 2 SDK, Standard Edition, v1.2 и позже, это означает, что у клиента должен также быть должным образом сконфигурированный файл политики безопасности.
  • Есть две типичных проблемы, связанные с java.rmi.server.codebase свойство, которые обсуждаются затем.

    6.1 Если Вы встречаетесь с проблемой, выполняющей Ваш Java сервер RMI

    Первой проблемой, с которой Вы могли бы встретиться, является получение a ClassNotFoundException пытаясь к bind или rebind удаленный объект к имени в реестре. Это исключение обычно происходит из-за уродливого codebase свойство, приводящее к реестру, не бывшему способному определять местоположение тупиков удаленного объекта или других классов, необходимых тупику.

    Важно отметить, что тупик удаленного объекта реализует весь одинаковый интерфейсы как удаленный объект непосредственно, таким образом, те интерфейсы, так же как любые другие пользовательские классы, объявленные как параметры метода или возвращаемые значения, должны также быть доступными для скачивания от указанной кодовой базы.

    Наиболее часто это исключение выдается в результате исключения запаздывающей наклонной черты со значения URL свойства. Другие причины включали бы: значением свойства не является URL; путь к классам, определенным в URL, является неправильным или написанным c орфографическими ошибками; тупиковый class или любые другие необходимые классы не все доступны от указанного URL.

    Исключение, с которым можно встретиться в таком случае, было бы похоже на это:

    6.2 Если Вы встречаетесь с проблемой, выполняющей Ваш Java клиент RMI

    Второй проблемой, с которой Вы могли встретиться, является получение a ClassNotFoundException пытаясь к lookup удаленный объект в реестре. Если Вы получаете это исключение в stacktrace, следующем из попытки выполнить Ваш Java клиентский код RMI, то Ваша проблема CLASSPATH с которого Ваш Java был запущен реестр RMI. См. требование C в разделе 6.0. Вот то, на что будет похоже исключение:

    Источник


    RMI error: java.rmi.UnmarshalException: error unmarshalling arguments


    posted 16 years ago

    • Mark post as helpful


    • send pies

      Number of slices to send:

      Optional ‘thank-you’ note:



    • Quote
    • Report post to moderator

    I am running my RMI server program in Eclipse 3.2.1 with JVM 1.5.0_07, and sending the following VM argument -Djava.rmi.server.codebase=file:/CHIP/. I get the following error when running it on my local machine.

    CHIPserverImpl exception: java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
    java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
    java.lang.ClassNotFoundException:
    I have the rmiregistry running … I believe my codebase argument is correct. Any ideas what the problem could be?
    [ January 02, 2007: Message edited by: Greg Ferrell ]


    posted 16 years ago

    • Mark post as helpful


    • send pies

      Number of slices to send:

      Optional ‘thank-you’ note:



    • Quote
    • Report post to moderator

    Usually that error comes up when one of the VMs cannot find a class it needs to unmarshall the serialized data. Are you running both VMs on the same machine? If not, you probably don’t want to use a CODEBASE with a file URI.

    RMI looks in the VM classpath first then checks the CODEBASE.

    Double check the runtime classpaths for both VMs and make sure that all the classes you pass between the two VMs are present ( don’t forget classes that are referenced inside other classes ).

    Greg Ferrell

    Greenhorn

    Posts: 5


    posted 16 years ago

    • Mark post as helpful


    • send pies

      Number of slices to send:

      Optional ‘thank-you’ note:



    • Quote
    • Report post to moderator

    Usually that error comes up when one of the VMs cannot find a class it needs to unmarshall the serialized data. Are you running both VMs on the same machine? If not, you probably don’t want to use a CODEBASE with a file URI.

    RMI looks in the VM classpath first then checks the CODEBASE.

    Double check the runtime classpaths for both VMs and make sure that all the classes you pass between the two VMs are present ( don’t forget classes that are referenced inside other classes ).

    I am running the VMs on the same machine for testing purposes as of now. How can I check the runtime classpath for the VM? I’m not sure exactly how Eclipse builds this based on my settings, but another guy is getting the example working, and he has his environment setup the same way I do, with the same VM argument.

    Chris Beihl

    Greenhorn

    Posts: 4


    posted 16 years ago

    • Mark post as helpful


    • send pies

      Number of slices to send:

      Optional ‘thank-you’ note:



    • Quote
    • Report post to moderator

    To find out your classpath of the run profile you launched :

    1. pull up the run dialog ( Run -> Run… )
    2. click on the run profile you are using
    3. click the Classpath tab
    4. look under User entries

    Good luck

    Greg Ferrell

    Greenhorn

    Posts: 5


    posted 16 years ago

    • Mark post as helpful


    • send pies

      Number of slices to send:

      Optional ‘thank-you’ note:



    • Quote
    • Report post to moderator

    Thanks for the replies.

    Turns out I had the codebase (-Djava.rmi.server.codebase) attribute set incorrectly … Maybe I shouldn’t be diving into Java/Eclipse & RMI all at the same time

    Greg Ferrell

    Greenhorn

    Posts: 5


    posted 16 years ago

    • Mark post as helpful


    • send pies

      Number of slices to send:

      Optional ‘thank-you’ note:



    • Quote
    • Report post to moderator

    Apparently, there�s some magic going on behind the scenes in Eclipse that I simply do not understand.

    After I got this working the other day, I was changing around the build path a bit (adding & removing some source directories and libraries) and this stopped working AGAIN with the exact same error.

    I eventually solved the problem AGAIN by changing the codebase argument from:
    -Djava.rmi.server.codebase=file:/java/bin/ to
    -Djava.rmi.server.codebase=file:k:/java/bin/

    All I did is put the complete path to the default output folder in Eclipse (k:/java/bin) instead of java/bin

    Does anyone have any idea why this would have changed? My .project & .classpath files are in k:/java and that’s where the root of the project exists.

    TIA!

    Потому что требуется проект, как маленький белый, чтобы начать изучать RMI. Не так много ерунды, перечислите несколько вопросов, которые возникают при запуске Demo RMI, и решение для ее решения.


    Во-первых, операционная среда

    IDE используется идеей 2018.1.5, а версия JDK составляет 10.0.1.

    Во-вторых, описание проблемы

    1. java.net.ConnectException: Connection refused: connect

    Причина: без запуска реестра до запуска программы RMI Server-Side.

    Обходной путь: Потому что после Java 1.5 исполняемая именованная rmiregistry встроена в JDK, как показано на рисунке 1.1. Поскольку программа реестра включена в переменную среды. Что нам нужно сделать, это выполнить программу реестра непосредственно в консоли, как показано на рисунке 1.2, затем запустите клиентскую программу.

    Рисунок 1.1 Расположение применения Rmiregistry

    Рисунок 1.2 Запустите программу реестра

    2.java.rmi.UnmarshalException: error unmarshalling arguments

    На самом деле это аномальное полное утверждение выглядит следующим образом:

    java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: 
        java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is: 
        java.lang.ClassNotFoundException: rmi.service.UserHandler

       ······
        at java.rmi.Naming.rebind(Naming.java:177)

    Здесь UserHandler — мой удаленный объект.

    Причина: очевидно, потому что программа реестра не находит класс удаленного объекта.

    Обходной путь: Перед запуском программы регистрации вам необходимо ввести тот же каталог с удаленным объектом, прежде чем запустить.Примечание. Каталог здесь является каталог классов. Если вы не знаете адрес классов, вы можете нажать «Файл» — «Структура проекта» — «Настройки проекта» — «Модули», выберите соответствующий модуль. Затем нажмите на вкладку «Пути», «Выходной путь» — это класс, как показано на рисунке 1.3.

    Рисунок 1.3 Расположение классов
    ​​​​

    3. Java.lang.unsupportedClassVersionError: Ваш удаленный объект был составлен более поздней версией Java Runtime (файл класса версии 54.0), эта версия Java Runtime распознает только версии файла классов до 52,0

    Причина: Здесь очень ясно, что скомпилированная версия класса составляет 54,0, а текущая Java работает всего 52,0.

    Решение: Версия JDK10 составляет 54,0, а версия JDK1.8 составляет 52,0. Итак, здесь нужно только изменить версию JDK 1,8, а затем перекомпилировать ее.


    Наконец, рекомендую этот блогhttps://blog.csdn.net/lmy86263/article/details/72594760

    Содержание, написанное этим блоггером, имеет большую помощь для новичков RMI.

    Понравилась статья? Поделить с друзьями:
  • Java nio file nosuchfileexception как исправить
  • Java nio file accessdeniedexception как исправить
  • Java nio channels closedchannelexception майнкрафт как исправить
  • Java net sockettimeoutexception read timed out ошибка
  • Java net socketexception unrecognized windows sockets error 0 cannot bind