спецификации, руководства, описания, API

^{Архитектура Отладчика Платформы Java™ -
Интерфейсы Поставщика услуг}

^{J2SE 5.0 добавляет новые интерфейсы поставщика услуг к Интерфейсу Отладки Java (JDI) так, чтобы Соединитель и реализации TransportService могли быть разработаны и развернуты. TransportService является новый class в 5.0. Это представляет базовую транспортную службу, используемую Соединителем, и используется, чтобы установить соединения и транспортный Протокол Провода Отладки Java (JDWP) пакеты между отладчиком и целевым VM.}

^{В дополнение к новым интерфейсам поставщика услуг в JDI J2SE 5.0 также включает новый транспортный интерфейс библиотеки, названный Транспортным Интерфейсом Протокола Провода Отладки Java™ (jdwpTransport). Это - собственное (C/C++) интерфейс, чтобы позволить разработку и развертывание транспортных библиотек. Транспортная библиотека загружается стороной отлаживаемой программы агент JDWP и пользуется, чтобы установить соединение с отладчиком и транспортировать пакеты JDWP между отладчиком и VM.}

^{Эта страница описывает много сценариев, где новые интерфейсы могут использоваться. Это также обеспечивает краткий обзор задач, включенных в разработку и развертывание новых Соединителей и транспортных реализаций.}

^{Сценарии в качестве примера}
^{Разработка Соединителя}
^{Развертывание Соединителя}
^{Разработка TransportService}
^{Развертывание TransportService}

^{Сценарии в качестве примера}

^{Интерфейсы поставщика услуг и собственный транспортный интерфейс, как ожидают, будут использоваться следующими классами пользователей:}

^{Отладчик и поставщики инструмента, которые должны разработать новые реализации LaunchingConnector или хотеть предоставить дополнительные транспортные возможности для удаленной отладки "и вне" TCP/IP и транспортов разделяемой памяти, обеспеченных Sun.}
^{Встроенное устройство, операционная система, или поставщики виртуальной машины, которые требуют удаленной отладки, используя транспорты это чем TCP/IP.}

^{Данный вышеупомянутый class пользователя следующее описывает много сценариев, где новые интерфейсы могли бы использоваться.}

^{Во многих средах, особенно встроенных устройствах, отладчик может быть обязан соединять с целевым VM использование транспорта кроме TCP/IP. В этом типе среды новые интерфейсы поставщика услуг могут использоваться, чтобы разработать и поддерживать отладку по альтернативному транспорту.}
^{На стороне отлаживаемой программы транспортная библиотека для нового транспорта может быть разработана, реализовывая интерфейс jdwpTransport. Для отладчика может быть разработана реализация TransportService. Когда реализация TransportService будет развернута, реализация VirtualMachineManager JDI автоматически создаст AttachingConnector и ListeningConnector, чтобы позволить удаленную отладку целевому VM.}
^{В некоторых средах отладчик может быть обязан соединять с целевым VM использование механизма кроме транспорта. Например, отладчик может использоваться, чтобы присоединить, способом только для чтения, к дампу катастрофического отказа или к подвешенному процессу.}
^{Для этих примеров может быть разработана реализация AttachingConnector. Реализация AttachingConnector расширяет com.sun.jdi.connect. AttachingConnectors и когда развернуто это появится в списке присоединения соединителей, возвращенных attachingConnectors VirtualMachineManager () метод.}
^{Во многих средах целевой VM будет запущен очень собственным способом. В таких средах параметры Соединителя или механизм запуска, используемый предоставленным Sun com.sun.jdi. CommandLineLaunch LaunchingConnector, возможно, не достаточен. В таких случаях операционная система или поставщик виртуальной машины могут решить разработать их собственный LaunchingConnector, который способен к запуску целевого VM. У этого нового LaunchingConnector были бы соответствующие параметры Соединителя, которые будут использоваться, чтобы сконфигурировать целевой VM для того, чтобы отладить. После того, как развернутый это будет казаться в списке Соединителей, возвращенных launchingConnectors VirtualMachineManager () метод.}
^{Другой пример возникает в корпоративной среде, где Интегрированная среда разработки (IDE) разработчик хочет поддерживать отладку по не-Sun, предоставленному транспорту. Например IDE может хотеть предоставить возможность отладки по безопасному соединению, используя TLS/SSL.}
^{В этом примере разработчик IDE разрабатывает транспортную библиотеку, используя интерфейс jdwpTransport. Это позволяет отлаживаемой программе использовать новый транспорт. На стороне отладчика у разработчика IDE есть выбор. Одна опция должна разработать и развернуть реализацию TransportService. Эта опция позволила бы новому транспорту использоваться для удаленной отладки.}

^{Альтернативно, разработчик IDE может решить создать реализацию Соединителя, которая инкапсулирует транспорт. Эта опция является соответствующей, когда разработчик IDE хочет добавить новые параметры Соединителя. Например, с безопасным транспортом разработчик IDE может хотеть иметь Соединитель, у которого есть параметры Соединителя, чтобы определить keystore, пароль, или другие опции должны были сконфигурировать безопасное соединение. Если новый Соединитель является соответствующим тогда, разработчик IDE разрабатывает транспортную библиотеку для стороны отлаживаемой программы и Соединитель для стороны отладчика. Тип Соединителя является выбором разработчика - одним примером является LaunchingConnector, который запускает отлаживаемую программу и устанавливает безопасное соединение между отладчиком и отлаживаемой программой.}

^{Разработка Соединителя}

^{Разработка Соединитель включает создание конкретной реализации LaunchingConnector, AttachingConnector, или ListeningConnector.}

^{У каждой реализации Соединителя должен быть общедоступный конструктор без аргументов в дополнение к реализации всех методов Connector. Конструктора вызовет VirtualMachineManager во время инициализации. Конструктор может быть не, или это может выполнить задачи инициализации, такие как загрузка транспортной службы. Конструктор не выдает проверенных исключений, таким образом, любые проблемы во время инициализации должны быть брошены как Ошибки или другие исключения непроверенные.}

^{Соединители не обязаны использовать TransportService. Некоторые Соединители могут соединить с целевым VM использование механизма кроме транспорта (в разделе Сценариев В качестве примера, мы перечисляем примеры AttachingConnectors, которые присоединяют, чтобы разрушить дампы или подвешенные процессы). Для Соединителей, которые используют реализацию TransportService, Соединитель может или сослаться на реализацию TransportService непосредственно или это может загрузить реализацию во времени выполнения. Соединители, которые хотят использовать Sun, если транспорты должны загрузить транспортную службу, используя код, такой как следующее:}

^{try {
    Class c = Class.forName("com.sun.tools.jdi.SocketTransportService");
    ts = (TransportService)c.newInstance();
} catch (Exception x) {
    throw new Error(x);
}}

^{Java реализации SE не обязаны включать сокет Sun или реализации транспортной службы разделяемой памяти так в вышеупомянутом примере Ошибка, будет брошен, если транспортная служба не будет существовать.}

^{Предполагая, что тип Соединителя известен тогда, следующие элементы должны быть отмечены, разрабатывая реализацию:}

^{Список Соединителя. Параметры нужно тщательно рассмотреть. Для некоторых реализаций Соединителя конструкция параметра по умолчанию и парсинг могут быть объемом кода в реализации.}
^{Соединитель обязан называть транспорт, который он использует. Если реализация использует существующий TransportService тогда, рекомендуемое транспортное имя является именем базового TransportService. Таким образом, транспорт Соединителя () реализация возвращает Транспорт, для которого имя () метод возвращает java.lang. Строка, представляющая имя транспорта.}
^{Большинство реализаций Соединителя установит Соединение с целевым VM. После того, как установленный запуск Соединителя, присоедините, или признайте, что метод возвратит экземпляр VirtualMachine отладчику. Чтобы облегчить создание зеркала VirtualMachine, у VirtualMachineManager есть новый метод в 5.0, чтобы создать VirtualMachine. Следующий фрагмент кода показывает использование в качестве примера этого метода:}
```
^{VirtualMachine vm = Bootstrap.virtualMachineManager().createVirtualMachine(conn);}
```
^{VirtualMachineManager также включает другую форму createVirtualMachine для использования LaunchingConnectors. Другая форма позволяет LaunchingConnector определять java.lang. Процесс, который представляет отлаживаемую программу. См. спецификацию для com.sun.jdi. VirtualMachineManager для получения дальнейшей информации.}

^{Исходный код для примера LaunchingConnector может быть найден здесь. У Соединителя есть единственный Соединитель. Параметр под названием class, который определяет имя class class, чтобы работать в целевом VM. Пример демонстрирует все вышеупомянутые точки включая Соединитель. Параметр, транспортное именование, и использование createVirtualMachine метода.}

^{Развертывание Соединителя}

^{Развернуть Соединитель требует упаковки классов для реализации Соединителя в файл фляги наряду с конфигурационным файлом службы, который перечисляет полностью определенное имя class Соединителя. Файл фляги тогда развертывается в расположении, которое видимо к системе загрузчик class.}

^{Конфигурационный файл службы, который должен быть включен в файл фляги, называют META-INF/services/com.sun.jdi.connect.Connector. Файл просто перечисляет полно квалифицированные имена class Соединителя, включенного в файл фляги. Многократные реализации Соединителя могут быть включены в тот же самый файл фляги, и в этом случае имя class для каждого Соединителя перечисляется на отдельной строке.}

^{Предположите, что мы хотим развернуть запускающийся соединитель под названием SimpleLaunchingConnector. Чтобы развернуть это, мы создаем файл META-INF/services/com.sun.jdi.connect.Connector подобный следующему:}

^{# Our very simple launching connector
SimpleLaunchingConnector}

^{Этот конфигурационный файл службы тогда упаковывается в файл фляги наряду с классами, которые включают реализацию Соединителя:}

^{jar cf SimpleLaunchingConnector.jar \
    META-INF/services/com.sun.jdi.connect.Connector \
    SimpleLaunchingConnector.class}

^{Файл фляги тогда копируется в расположение, которое видимо к системе загрузчик class.}

^{После того, как развернутый Соединитель будет расположен отладчиком, когда отладчик будет перезапущен. Таким образом, SimpleLaunchingConnector будет включен в список Соединителей, возвращенных allConnectors VirtualMachineManager () метод. Кроме того, поскольку это - запускающийся соединитель, это будет также казаться в списке запускающихся соединителей, возвращенных launchingConnectors () метод.}

^{Разработка TransportService}

^{Разработка транспортной службы требует разработки двух компонентов:-}

^{Конкретная реализация com.sun.jdi.connect.spi. TransportService.}
^{Совместно использованная библиотека стороны отлаживаемой программы, которая реализует интерфейс jdwpTransport.}

^{Разработка транспортной службы требует высокой степени знакомства с транспортом и базовым протоколом связи. Транспортная служба по существу связывает JDWP с базовым протоколом связи. Услуга, которую это предоставляет, надежна, и пакетами JDWP обмениваются между отладчиком и отлаживаемой программой без потери данных или дублирования., Учитывая, что пакетами нужно обменяться надежным способом, мог бы означать, что дополнительный протокол поддерживает быть включенным в транспортную службу и кроме того обеспеченным базовым протоколом связи. Например, если отладка по сырым данным и ненадежному последовательному соединению требуется, тогда разработчик транспортной службы может быть обязан создавать в обнаружении ошибок и восстановлении в реализации, чтобы гарантировать, что пакеты JDWP могут быть достоверно транспортированы между отладчиком и отлаживаемой программой.}

^{Принятие деталей транспортного и базового протокола связи понимается тогда, следующий шаг должен рассмотреть следующее:}

^{Возможности TransportService () метод возвращают TransportService. Возможности указать на возможности транспортной службы. Разработчик транспортной службы таким образом должен рассмотреть:}
- ^{Может транспорт может поддерживать многократные параллельные соединения с единственным адресом слушателя?}
- ^{Тайм-ауты могут быть осуществимо реализованы, соединяясь, квитирование, или ожидая соединения, которое будет установлено?}
^{Собственной транспортной библиотекой может пользоваться только один, или многократный JDWP (или другой) агенты одновременно. Если транспорт будет поддерживать многократные среды тогда, то каждый звонок в функцию jdwpTransport_OnLoad возвратит новый указатель среды. Если транспорт только будет поддерживать единственную среду тогда, то вторые и последующие звонки jdwpTransport_OnLoad возвратят ошибку. Транспортный разработчик библиотеки должен поэтому решить, будет ли реализация библиотеки поддерживать один или многократные среды.}
^{Адреса, или конечные точки соединения, представляются Строками. Разработчик должен поэтому разработать схему адреса так, чтобы все компоненты адреса могли быть закодированы в Строку. Например адрес и конфигурация последовательного порта могли бы быть закодированы как что-то как:}
```
^{/dev/ttya;9600,1}
```
^{Разработайте соответствующую реализацию ListenKey. Поскольку TransportService может использоваться, чтобы слушать на многократном, все же отличающемся, адреса одновременно, слушать ключ используется, чтобы однозначно определить каждого "слушателя".}
^{Выберите соответствующее имя и описание для TransportService. При запуске VirtualMachineManager создаст Соединитель Присоединения и Слушания, чтобы инкапсулировать транспортную службу. Имя и описание этих Соединителей будут основаны на имени и описании транспортной службы - например, если имя TransportService () возвраты метода, "Последовательные" тогда Соединители, создаваемые VirtualMachineManager, назовут "SerialAttach" и "SerialListen".}

^{Однажды вышеупомянутое были разрешены, затем создавая TransportService, включает расширение com.sun.jdi.connect.spi. TransportService и обеспечение реализации. Присоединение и признает, что методы возвращают экземпляр com.sun.jdi.connect.spi. Соединение так реализация Соединения требуется так, чтобы отладчик мог обмениваться пакетами JDWP с отлаживаемой программой.}

^{Как пример реализации TransportService исходный код для транспорта сокета Sun может быть найден здесь. Это обеспечивается в ссылочных целях только.}

^{Разработать собственную транспортную библиотеку требует реализации каждой из функций, перечисленных в jdwpTransport спецификации. Прототипы функции и определения определяются в ${java_home}/include/jdwpTransport.h.}

^{Транспортный разработчик библиотеки компилирует и соединяет функциональные реализации в динамическую библиотеку (или эквивалентный). Библиотека экспортирует функцию jdwpTransport_OnLoad функция, которую вызовет агент JDWP, когда транспортная библиотека будет загружена. Некоторые встроенные среды не поддерживают динамическое подключение, и в таких средах транспортная библиотека, возможно, должна быть статически соединена. В этом случае нет никакой загрузки библиотеки, но функция jdwpTransport_OnLoad будет все еще вызвана, чтобы инициализировать транспортную библиотеку и получить указатель среды.}

^{Как пример jdwpTransport реализации исходный код для транспортной библиотеки сокета Sun (dt_socket) может быть найден здесь. Это обеспечивается в ссылочных целях только.}

^{Развертывание TransportService}

^{TransportService развертывается подобным образом к Соединителю. Развернуть TransportService требует упаковки классов для реализации TransportService в файл фляги наряду с конфигурационным файлом службы, который перечисляет полностью определенное имя class TransportService. Файл фляги тогда развертывается в расположении, которое видимо к системе загрузчик class.}

^{Конфигурационный файл службы, который должен быть включен в файл фляги, называют META-INF/services/com.sun.jdi.connect.spi.TransportService. Согласно развертыванию Соединителя конфигурационный файл может перечислить имена классов многократных реализаций транспортной службы, когда файл фляги включает многократные реализации.}

^{В случае транспортной службы com.sun. SerialTransportService тогда конфигурационный файл службы будет подобен следующему:-}

^{# Serial line transport
com.foo.SerialTransportService}

^{Этот конфигурационный файл службы тогда упаковывается в файл фляги наряду с классами, которые включают реализацию. Для этого примера мы предположим, что реализация включает много классов:-}

^{jar cf SerialTransportService.jar \
    META-INF/services/com.sun.jdi.connect.spi.TransportService \
    com/foo/SerialTransportService.class \
    com/foo/SerialConnection.class \
    com/foo/SerialCapabilities.clas \
    com/foo/SerialIO.class \
    com/foo/SerialProtocol.class}

^{Согласно развертыванию Соединителей, файл фляги тогда копируется в расположение, которое видимо к системе загрузчик class.}

^{TransportService может иметь собственные методы или положиться на другие API, которые требуют собственной библиотеки. В этом случае собственная библиотека должна быть расположением, которое позволяет ей быть загруженным, используя System.loadLibrary.}

^{Собственная транспортная библиотека загружается агентом JDWP. В должен быть расположен на нормальном пути поиска библиотеки времени выполнения для операционных систем. Например, на Солярисе или системах Linux это должно быть на пути поиска, определенном переменной окружения LD_LIBRARY_PATH.}

Свяжитесь с Нами

Архитектура Отладчика Платформы Java™ - Интерфейсы Поставщика услуг

Сценарии в качестве примера

Разработка Соединителя

Развертывание Соединителя