Когда RMI (реализация sun.rmi в виртуальных машинах Sun) де-сериализует объект как часть параметров или возвращаемого значения удаленного вызова, ему необходимо перейти от имени класса (строки в сериализованных данных) до a Class объект. Как RMI определяет, какой ClassLoader использовать для определения класса?Как (на уровне реализации) Java RMI загружает + определяет классы?
По умолчанию Java deserialisation выполняет поиск по стеку для первого несистемного класса и использует его загрузчик классов (т. Е. Первый ненулевой загрузчик классов). RMI добавляет аннотации к последовательному потоку, чтобы указать местоположение (URL), из которого должны быть загружены классы. По умолчанию загрузчики классов RMI используют это местоположение для поиска дополнительных классов. Существует системное свойство отключить это поведение (не плохая идея).
Итак, в основном, если не указаны удаленные кодовые базы, возвращаемое значение загружается ClassLoader, загружающим класс, который сделал вызов в заглушку? (Или ClassLoader, который определил конкретный класс Proxy, что заглушка является экземпляром?) Как насчет сервера? До тех пор, пока UnicastServerRef не сделает фактический upcall в экспортированный объект, в котором параметры точки были полностью десериализованы, все фреймы стека должны быть системными классами, поскольку они находятся в одном из потоков отправки RMI. Правильно? – jon
@jon Я считаю, что вы получаете либо загрузчик классов объекта сервера, либо контекст, в который он был экспортирован (обычно один и тот же). –
Ничего из этого не используется «по умолчанию». Вы должны установить свойство java.rmi.server.codebase в JVM, которое экспортирует удаленный объект, чтобы запустить весь процесс. Я не знаю, к чему относится «системный класс». RMI не использует «сериализацию Java по умолчанию», он добавляет свой собственный слой, который переопределяет resolveClass(). – EJP