Разрешает ли OSGI JNDI сосуществовать с вызовами JNDI из не-OSGI-кода?

Глава 126Спецификация OSGI Enterprise Release 5 упоминает совместимость:

«Поддержка традиционной модели программирования JNDI, используемой клиентами Java SE и Java EE».

и использование кода, не знакомого с OSGI:

«Клиенты и провайдеры JNDI-контекста, которые не знают OSGi, используют статические методы для подключения к реализации JRE JNDI. Класс InitialContext обеспечивает доступ к контексту от провайдера, а провайдеры используют статические методы NamingManager для преобразования объектов и поиска контекстов URL. Традиционная модель не знает OSGi и поэтому может быть надежно использована только в том случае, если будут устранены последствия этого недостатка OSGi ".

но мне не ясно, относится ли этот текст только к «устаревшему» коду, выполняемому внутри пакета OSGI, или также к коду вне контейнера OSGI, например, в сценарии, в котором контейнер OSGI встроен в приложение.

В сценарии встраивания может существовать код приложения как снаружи, так и внутри контейнера OSGI, который выполняет вызовы JNDI, и при выполнении в той же JVM они будут совместно использовать реализацию JNDI.

Вопрос: Должна ли реализация OSNI JNDI, работающая во встроенном контейнере OSGI, позволять неинвазированному OSGI коду вне контейнера выполнять свои вызовы JNDI, как обычно, или требуется какой-то перенос на «OSGI-осведомленность»?

Попробуйте сами с Apache Karaf 2.3.0 (который использует Apache Aries JNDI 1.0.0), но это не похоже на работу, поскольку Apache Aries требует, чтобы клиентские вызовы JNDI исходили из пакета OSGI.
Частичная трассировка стека:

javax.naming.NoInitialContextException: The calling code's BundleContext could not be determined.
    at org.apache.aries.jndi.OSGiInitialContextFactoryBuilder.getInitialContext(OSGiInitialContextFactoryBuilder.java:46)
    at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
    at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307)
    at javax.naming.InitialContext.init(InitialContext.java:242)
    at javax.naming.InitialContext.<init>(InitialContext.java:192)

Вопрос: Это правильное поведение, или есть раздел спецификации, на который я могу сослаться, который нарушается этим ограничением?

Ответы на вопрос(3)

Ваш ответ на вопрос