Spec-Zone .ru
спецификации, руководства, описания, API
|
|
Spec-Zone .ru
спецификации, руководства, описания, API
|
java.rmi.MarshalledObject теперь универсальныйMarshalledObject теперь имеет параметр типа, представляющий тип содержавшего сериализированного объекта.null RMIClientSocketFactory в данной виртуальной машине, тогда или тот объект фабрики или эквивалентный объект фабрики остались бы навсегда достижимыми в виртуальной машине, предотвращая это (и ее определение загрузчик class) от того, чтобы когда-либо быть собранным "мусор"; эта ошибка была исправлена. (Есть эквивалентная ошибка для фабрик сокета, используемых, чтобы экспортировать удаленный объект: .)sun.rmi.dgc.client.gcInterval и sun.rmi.dgc.server.gcInterval, была одна минута по умолчанию. Интервал значения по умолчанию является теперь одним часом, чтобы лучше снабдить приложения большими размерами "кучи" без специальной конфигурации.rmic, предварительно генерировать тупиковые классы для удаленных объектов. Отметьте это rmic должен все еще использоваться, чтобы предварительно генерировать тупиковые классы для удаленных объектов, которые должны поддерживать клиенты, работающие на более ранних версиях. Когда приложение экспортирует удаленный объект (использующий конструкторов или статичный exportObject methods1 классов java.rmi.server.UnicastRemoteObject или java.rmi.activation.Activatable) и предварительно сгенерированный тупиковый class для class удаленного объекта не может быть загружен, тупик удаленного объекта будет a java.lang.reflect.Proxy экземпляр (чей class динамически сгенерирован) с a java.rmi.server.RemoteObjectInvocationHandler как его обработчик вызова.
Существующее приложение может быть развернуто, чтобы использовать динамически сгенерированные тупиковые классы безоговорочно (то есть, существуют ли предварительно сгенерированные тупиковые классы), устанавливая системное свойство java.rmi.server.ignoreStubClasses к "true". Если это свойство устанавливается в "true", предварительно сгенерированные тупиковые классы никогда не используются.
Примечания:
rmic или клиент доберется ClassNotFoundException десериализация тупика удаленного объекта. Пред5.0 клиентов не будут в состоянии загрузить экземпляр динамически сгенерированного тупикового class, потому что такой class содержит экземпляр RemoteObjectInvocationHandler, который не был доступен до этого выпуска.java.rmi.StubNotFoundException если предварительно сгенерированный тупиковый class для class удаленного объекта не мог бы быть загружен. С добавленной поддержкой динамически сгенерированных тупиковых классов, экспортируя удаленный объект, у которого нет никакого предварительно сгенерированного тупикового class, тихо успешно выполнится вместо этого. Пользователь, развертывающий серверное приложение, чтобы поддерживать пред5.0 клиентов, должен все еще удостовериться, что предварительно генерировал тупиковые классы для классов удаленного объекта сервера, даже при том, что о недостающих тупиковых классах больше не сообщают во время экспорта. О таких ошибках вместо этого сообщат пред5.0 клиентам, когда это десериализует динамически сгенерированный тупиковый class.1 статический метод UnicastRemoteObject.exportObject(Remote) как объявляют, возвращается java.rmi.server.RemoteStub и поэтому не может использоваться, чтобы экспортировать удаленный объект, чтобы использовать динамически сгенерированный тупиковый class для его тупика. Экземпляр динамически сгенерированного тупикового class является 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 тупиковых версии протокола. Если удаленная реализация class должна быть создана, чтобы поддерживать клиенты, работающие на JDK 1.1, то -vcompat опция должна теперь быть определена явно. (Кроме того, отметьте, что как описано выше, если удаленная реализация class не должен поддерживать клиенты, работающие на любом выпуске до 5.0, то rmic не должен быть выполнен вообще для того class.)
См. документацию инструментов для rmic Солярис и Linux[] Windows[] для получения дополнительной информации об этих параметрах командной строки.
rmic больше не компилирует произвольные исходные файлы в пути class (начиная с 5.0)rmic иногда был бы, обрабатывая ее ввод файлы class, попытка скомпилировать произвольный .java исходные файлы, с которыми это встретилось в пути class. В 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 динамическое поведение загрузки class для данного приложения. По умолчанию поставщик услуг реализует стандартное поведение всех статических методов в RMIClassLoader. См. документацию class 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 метод, который возвращает имя class группы, может теперь возвратиться null, указание на групповую реализацию значения по умолчанию системы. Ранее, getClassName метод возвратил бы имя внутренней реализации class, если бы групповая реализация значения по умолчанию была выбрана, когда дескриптор был создан. Из-за этого изменения, если приложение, работающее в 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.