Spec-Zone .ru
спецификации, руководства, описания, API
|
|
Spec-Zone .ru
спецификации, руководства, описания, API
|
java.rmi.MarshalledObject теперь универсальныйMarshalledObject теперь имеет параметр типа, представляющий тип содержавшего сериализированного объекта.null RMIClientSocketFactory в данной виртуальной машине, тогда или тот объект фабрики или эквивалентный объект фабрики остались бы навсегда достижимыми в виртуальной машине, предотвращая это (и ее загрузчик класса определения) от того, чтобы когда-либо быть собранным "мусор"; эта ошибка была исправлена. (Есть эквивалентная ошибка для фабрик сокета, используемых, чтобы экспортировать удаленный объект: .)sun.rmi.dgc.client.gcInterval и sun.rmi.dgc.server.gcInterval, была одна минута по умолчанию. Интервал по умолчанию является теперь одним часом, чтобы лучше снабдить приложения большими размерами "кучи" без специальной конфигурации.rmic, предварительно генерировать тупиковые классы для удаленных объектов. Отметьте это rmic должен все еще использоваться, чтобы предварительно генерировать тупиковые классы для удаленных объектов, которые должны поддерживать клиенты, работающие на более ранних версиях. Когда приложение экспортирует удаленный объект (использующий конструкторов или статичный exportObject methods1 классов java.rmi.server.UnicastRemoteObject или java.rmi.activation.Activatable) и предварительно сгенерированный тупиковый класс для класса удаленного объекта не может быть загружен, тупик удаленного объекта будет a java.lang.reflect.Proxy экземпляр (чей класс динамически сгенерирован) с a java.rmi.server.RemoteObjectInvocationHandler как его обработчик вызова.
Существующее приложение может быть развернуто, чтобы использовать динамически сгенерированные тупиковые классы безоговорочно (то есть, существуют ли предварительно сгенерированные тупиковые классы), устанавливая системное свойство java.rmi.server.ignoreStubClasses к "true". Если это свойство устанавливается в "true", предварительно сгенерированные тупиковые классы никогда не используются.
Примечания:
rmic или клиент доберется ClassNotFoundException десериализация тупика удаленного объекта. Пред5.0 клиентов не будут в состоянии загрузить экземпляр динамически сгенерированного тупикового класса, потому что такой класс содержит экземпляр RemoteObjectInvocationHandler, который не был доступен до этого выпуска.java.rmi.StubNotFoundException если предварительно сгенерированный тупиковый класс для класса удаленного объекта не мог бы быть загружен. С добавленной поддержкой динамически сгенерированных тупиковых классов, экспортируя удаленный объект, у которого нет никакого предварительно сгенерированного тупикового класса, тихо успешно выполнится вместо этого. Пользователь, развертывающий серверное приложение, чтобы поддерживать пред5.0 клиентов, должен все еще удостовериться, что предварительно генерировал тупиковые классы для классов удаленного объекта сервера, даже при том, что о недостающих тупиковых классах больше не сообщают во время экспорта. О таких ошибках вместо этого сообщат пред5.0 клиентам, когда это десериализует динамически сгенерированный тупиковый класс.1 статический метод UnicastRemoteObject.exportObject(Remote) как объявляют, возвращается java.rmi.server.RemoteStub и поэтому не может использоваться, чтобы экспортировать удаленный объект, чтобы использовать динамически сгенерированный тупиковый класс для его тупика. Экземпляр динамически сгенерированного тупикового класса является a java.lang.reflect.Proxy экземпляр, который не присваиваем RemoteStub.
javax.rmi.ssl.SslRMIClientSocketFactory и javax.rmi.ssl.SslRMIServerSocketFactory, которые связываются по Уровню защищенных сокетов (SSL) или Безопасность Транспортного уровня (TLS) протоколы, используя Расширение Защищенного сокета Java (JSSE). Эти классы фабрики сокета обеспечивают простой способ использовать JSSE с Java RMI, включая осуществлению целостности, конфиденциальность (через шифрование), аутентификация сервера, и (дополнительно) аутентификация клиента для удаленных вызовов метода. Для получения дополнительной информации по тому, как использовать пользовательские фабрики сокета с Java RMI, см., что учебное руководство "Использует Пользовательские Фабрики Сокета с Java RMI". Для получения дополнительной информации по JSSE (включая то, как сконфигурировать это), см. Справочник JSSE.rmid или Java Сервер RMI от inetd/xinetd (начиная с 5.0)System.inheritedChannel метод, позволяет приложению получать канал (java.nio.channels.SocketChannel или java.nio.channels.ServerSocketChannel, например) наследованный от процесса, который запустил виртуальную машину (VM). Такой наследованный канал может привыкнуть к любой службе единственное входящее соединение (в случае a SocketChannel) или примите многократные входящие соединения (в случае ServerSocketChannel). Поэтому, Java сетевые приложения, запущенные inetd (Солярис (ТМ) Операционная система) или xinetd (Linux) может теперь получить SocketChannel или ServerSocketChannel наследованный от inetd/xinetd. С добавлением этой функции, Java демон активации RMI rmid был улучшен, чтобы поддерживать быть запущенным от inetd/xinetd так, чтобы rmid может быть запущен только, когда это получает входящее соединение. Для получения дополнительной информации на улучшениях к rmid чтобы поддерживать эту функцию, см. страницу инструментов для rmid (для Операционной системы Соляриса). Для получения дополнительной информации на том, как сконфигурировать inetd запускаться rmid, см., что учебное руководство "Конфигурирует inetd Запускаться rmid".
Приложение, используя Java RMI может также быть разработано, чтобы быть запущенным от inetd или xinetd. Для примера на том, как реализовать этот метод, см., что учебное руководство "Разрабатывает Службы, которые будут Запущены от inetd."
rmic тупиковая опция версии протокола по умолчанию теперь -v1.2 (начиная с 5.0)rmic выполняется без опции, чтобы определить тупиковую версию протокола JRMP, которая будет использоваться сгенерированными классами, она теперь ведет себя как будто -v1.2 опция была определена, вместо -vcompat опция как в предыдущих выпусках. Это изменение означает это по умолчанию, rmic не генерирует скелетных классов и генерирует тупиковые классы, которые только реализуют 1.2 тупиковых версии протокола. Если удаленный класс реализации должен быть создан, чтобы поддерживать клиенты, работающие на JDK 1.1, то -vcompat опция должна теперь быть определена явно. (Кроме того, отметьте, что как описано выше, если удаленный класс реализации не должен поддерживать клиенты, работающие на любом выпуске до 5.0, то rmic не должен быть выполнен вообще для того класса.)
См. документацию инструментов для rmic Солярис и Linux[] Windows[] для получения дополнительной информации об этих параметрах командной строки.
rmic больше не компилирует произвольные исходные файлы в пути к классу (начиная с 5.0)rmic иногда был бы, обрабатывая ее входные файлы класса, попытка скомпилировать произвольный .java исходные файлы, с которыми это встретилось в пути к классу. В 5.0, rmic не пытается скомпилировать любые исходные файлы кроме тех для тупика, скелета, или классов связи, которые это генерирует. Ожидание состоит в том что удаленные классы реализации, к которым передают rmic, так же как все классы и интерфейсы, от которых они зависят, были уже успешно скомпилированы с javac прежде rmic выполняется. Если существующая процедура сборки зависит от предыдущего поведения rmic для того, чтобы скомпилировать некоторые из его исходных файлов приложения, тогда та процедура сборки должна будет быть изменена, чтобы гарантировать, что все необходимые классы правильно компилируются с javac перед выполнением rmic.
Эта функция делается возможной новым "программируемым доступом сложить трассировочную информацию" функция java.lang.Throwable в J2SE 1.4, который включал создание a Throwable's складывают часть данных трассировки его значения по умолчанию сериализированная форма. То, что Java клиентской стороны реализация времени выполнения RMI теперь делает, чтобы сотрудничать с этой функцией, должно добавить трассировку клиентской стороны к неупорядоченной трассировке серверной стороны, вместо того, чтобы просто перезаписать с трассировкой клиентской стороны, как это сделало в предыдущих выпусках.
Определенные серверные приложения могут хотеть препятствовать тому, чтобы любые данные трассировки стека серверной стороны сопровождали исключение, которое будет упорядочено как результат удаленного вызова (как часть значения по умолчанию исключения сериализированная форма в J2SE 1.4), возможно по причинам производительности или конфиденциальности. В таких случаях, специфичном для реализации системном свойстве
sun.rmi.server.suppressStackTracesможет быть установлен в "истину" заставить Java серверной стороны реализация времени выполнения RMI очищать трассировки стека всех исключений, выданных от текущей виртуальной машины как результат удаленных вызовов метода.
RMIClassLoader (начиная с 1.4)java.rmi.server.RMIClassLoader теперь делегируйте их поведение к экземпляру нового интерфейса поставщика услуг, java.rmi.server.RMIClassLoaderSpi. Поставщик услуг может быть сконфигурирован, чтобы увеличить Java RMI динамическое поведение загрузки класса для данного приложения. По умолчанию поставщик услуг реализует стандартное поведение всех статических методов в RMIClassLoader. См. документацию класса RMIClassLoader и RMIClassLoaderSpi для большего количества деталей.java.rmi.server.hostname свойство может теперь быть динамически обновлено, чтобы указать, что будущий экспорт должен использовать новое имя хоста. Поэтому, новое значение имени хоста будет содержаться в тупике для объекта, который экспортируется после того, как свойство обновляется.sun.rmi.transport.proxy.eagerHttpFallback был добавлен, чтобы позволить дополнительное управление, когда Java фабрика сокета значения по умолчанию RMI отступит к туннелированию HTTP. Это свойство конфигурирует фабрику сокета по умолчанию так, чтобы любой SocketException, брошенный начальной (прямой) попыткой подключения, инициировал туннелирование HTTP; эта более "нетерпеливая" стратегия нейтрализации может быть полезной, имея дело с брандмауэрами, которые отрицают вместо, игнорируют попытки подключения к несанкционированным портам.java.rmi.Naming.list Метод Больше Не Предварительно ожидает Схему к Возвращенным Именам (начиная с 1.4.1)Naming.list метод, предварительно ожидаемый схема rmi: к каждому имени, содержавшемуся в возвращенном массиве строк. Naming.list реализация теперь соответствует спецификацию, возвращая массив имен, которые отформатированы URL, но без компонента схемы.java.rmi.activation.ActivationGroupDesc (начиная с 1.3)getClassName метод, который возвращает имя класса группы, может теперь возвратиться null, указание на групповую реализацию системы по умолчанию. Ранее, getClassName метод возвратил бы имя внутреннего класса реализации, если бы групповая реализация по умолчанию была выбрана, когда дескриптор был создан. Из-за этого изменения, если приложение, работающее в 1.3 виртуальных машинах, регистрирует новый объект activatable в ActivationSystem, rmid должен также быть обновлен, чтобы работать 1.3, начиная с пред1.3 rmid не будет в состоянии активировать недавно зарегистрированный объект activatable.
rmic (начиная с 1.3)rmic Солярис и Linux[] Windows[] теперь предполагает, что целевой каталог для сгенерированных тупиков является названным в честь пакета подкаталогом текущего рабочего каталога. Если"-d"опция не определяется, результатом является то же самое, как если бы это было определено с текущим рабочим каталогом "." как параметр."-d"может все еще использоваться, чтобы переопределить целевой каталог по умолчанию. Две новых опции,"-idl"и"-iiop"были добавлены, чтобы генерировать IDL и тупики для IIOP, соответственно.
rmid (начиная с 1.3)rmid Солярис и Linux[] Windows[] теперь требует файла политики безопасности.java.rmi.StubNotFoundException. Это исключение было результатом отказа времени выполнения RMI определить местоположение тупикового объекта во время попытки заменить реализацию удаленного объекта ее соответствующим тупиком. В 1.2.2 и более поздние выпуски, неэкспортируемый удаленный объект, который передают в вызове RMI, больше не будет приводить к исключению, а скорее удаленный объект будет сериализирован вместо его тупика. Если реализация удаленного объекта не будет сериализуема, то попытка передать неэкспортируемый объект в вызове RMI приведет к a java.rmi.RemoteException с вложенным исключением java.io.NotSerializableException.