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?