Что решает OSGi?
Указатель NULL - это тот, который указывает на никуда. Когда вы разыскиваете указатель p, вы говорите «дайте мне данные в месте, хранящемся в« p ». Когда p является нулевым указателем, местоположение, хранящееся в p, является nowhere, вы говорите «Дайте мне данные в месте« нигде ». Очевидно, он не может этого сделать, поэтому он выбрасывает NULL pointer exception.
В общем, это потому, что что-то не было правильно инициализировано.
4 ответа
отредактированный для ясности. Страница OSGi дала лучший простой ответ, чем мой
А простой ответ: Платформа услуг OSGi обеспечивает стандартизированную, ориентированную на компонент вычислительную среду для сотрудничающих сетевых услуг. Эта архитектура значительно уменьшает полную сложность здания, поддержания и развертывания приложений. Платформа услуг OSGi обеспечивает функции для изменения состава динамично на устройстве множества сетей, не требуя перезапусков.
В единственной структуре приложения, скажем Eclipse IDE, это не имеет большого значения для перезапуска, когда Вы устанавливаете новый плагин. Используя реализацию OSGi полностью, необходимо быть в состоянии добавить плагины во времени выполнения, получить новую функциональность, но не иметь для перезапуска затмения вообще.
Снова, не грандиозное предприятие в течение каждого дня, использования небольшого приложения.
, Но, когда Вы начинаете смотреть на мультикомпьютер, платформы распределенного приложения, это - то, где он начинает становиться интересным. Когда у Вас должно быть 100%-е время работы для критических систем, возможность заменить компоненты в горячем режиме или добавить, что новая функциональность во времени выполнения полезна. Предоставленный, существуют возможности того, чтобы сделать это теперь по большей части, но OSGi пытается связать все в миленькую платформу с едиными интерфейсами.
Делает OSGi, решают типичные проблемы, я не уверен в этом. Я имею в виду, это может, но издержки не могут стоить того для более простых проблем. Но это - что-то для рассмотрения, когда Вы начинаете иметь дело с большим, сетевым, приложениями.
Я не забочусь слишком много о hotplugability модулей OSGi (по крайней мере, в настоящее время). Это - больше вынужденный модульный принцип. Не имение в наличии миллионов "общедоступных" классов на пути к классу в любое время защищает хорошо от круговых зависимостей: необходимо действительно думать об открытых интерфейсах - не только с точки зрения "общественности" конструкции языка Java, но и с точки зрения библиотеки/модуля: Каковы (точно) компоненты, которые Вы хотите сделать доступным для других? Каковы (точно) интерфейсы (других модулей), действительно необходимо ли реализовать функциональность?
Это хорошо, та замена в горячем режиме идет с ним, но я перезапустил бы свои обычные приложения, чем тестирующий все комбинации hotplugability...
Я нашел следующие преимущества от OSGi:
- Каждый плагин является имеющим версию артефактом, который имеет его собственный classloader.
- Каждый плагин зависит и от определенных банок, которые он содержит и также другие определенные имеющие версию плагины.
- из-за управления версиями и изолированного classloaders, различные версии того же артефакта могут быть загружены одновременно. Если один компонент Вашего приложения полагается на одну версию плагина, и другой зависит от другой версии, они оба могут быть загружены одновременно.
С этим, можно структурировать приложение как ряд имеющих версию сменных артефактов, которые загружаются по требованию. Каждый плагин является автономным компонентом. Так же, как Знаток помогает Вам структурировать свою сборку, таким образом, это повторяемо и определяется рядом определенных версий артефактов, которыми это создается, OSGi помогает Вам сделать это во времени выполнения.
Он также используется для обеспечения дополнительной мобильности промежуточного программного обеспечения и приложений на мобильной стороне. Например, мобильная версия доступна для WinMo, Symbian, Android. Как только происходит интеграция с функциями устройства, они могут быть фрагментированы.