Czy OSGI JNDI umożliwia współistnienie z wywołaniami JNDI z kodu innego niż OSGI?

Rozdział 126Specyfikacja OSGI Enterprise Release 5 wspomina zgodność:

„Obsługa tradycyjnego modelu programowania JNDI używanego przez klientów Java SE i Java EE”.

oraz wykorzystanie kodu nieświadomego OSGI:

„Klienci i dostawcy kontekstu JNDI, którzy nie wiedzą o OSGi, używają statycznych metod do łączenia się z implementacją JRE JNDI. Klasa InitialContext zapewnia dostęp do kontekstu od dostawcy, a dostawcy korzystają ze statycznych metod NamingManager do konwersji obiektów i znajdowania kontekstów URL. tradycyjny model nie jest świadomy OSGi i dlatego może być używany niezawodnie tylko wtedy, gdy konsekwencje braku świadomości OSGi są zarządzane ”.

ale nie jest dla mnie jasne, czy ten tekst dotyczy tylko kodu „starszego” wykonanego w pakiecie OSGI, czy też kodu poza kontenerem OSGI, f ex w scenariuszu, w którym kontener OSGI jest osadzony w aplikacji.

W scenariuszu osadzania może istnieć kod aplikacji zarówno na zewnątrz, jak i wewnątrz kontenera OSGI, który wykonuje wywołania JNDI, a ponieważ wykonują się w tej samej maszynie JVM, będą współużytkować implementację JNDI.

Pytanie: Czy implementacja OSGI JNDI działająca w osadzonym kontenerze OSGI umożliwia kodowi nieświadomemu OSGI poza kontenerem wykonywanie połączeń JNDI, jak zwykle, czy też wymagane jest przeniesienie do „świadomości OSGI”?

Sam próbuję tego z Apache Karaf 2.3.0 (który używa Apache Aries JNDI 1.0.0), nie wydaje się to działać, ponieważ Apache Aries wymaga wywołań klienta JNDI pochodzących z pakietu OSGI.
Częściowy ślad stosu:

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)

Pytanie: Czy jest to poprawne zachowanie, czy istnieje fragment specyfikacji, do którego mogę się odnieść, który jest naruszony przez to ograniczenie?

questionAnswers(3)

yourAnswerToTheQuestion