Czy JNDI OSGI pozwala na współistnienie z wywołania JNDI z kodu spoza OSGI?

Question

Rozdział 126 OSGI Enterprise Release 5 specification wspomina zgodność "Wsparcie tradycyjny model programowania JNDI używane przez klientów Java SE i Java EE"

i wykorzystanie kodu OSGI-nieświadomego:

„Klienci i dostawcy JNDI kontekście, że są nieświadomi OSGi wykorzystać metody statyczne, aby połączyć się z realizacji JRE JNDI Klasa InitialContext zapewnia dostęp do a. Kontekst dostawcy usług i dostawców usługi używają statycznych metod NamingManager do konwersji obiektów i odnajdywania kontekstów adresów URL Ten tradycyjny model nie zna OSGi i dlatego może być używany niezawodnie tylko wtedy, gdy zarządzane są konsekwencje braku świadomości OSGi. "

ale to nie jest dla mnie jasne, czy tekst ten odnosi się tylko do „spuścizna” Kod wykonywany wewnątrz wiązki OSGI, lub też kodować zewnątrz pojemnika OSGI, f ex w scenariuszu, w którym pojemnik OSGI jest osadzony w Aplikacja.

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 gdy są wykonywane w tej samej maszynie JVM, będą współużytkować implementację JNDI.

Pytanie: Jeżeli uruchomiona jest implementacja JNDI OSGI we wbudowanym pojemnikiem OSGI pozwalają OSGi-nieświadomy kod na zewnątrz pojemnika do wykonywania swoich JNDI wymaga jak zwykle, czy jest jakiś Porting do required „OSGI świadomość”?

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

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 to poprawne zachowanie, czy jest tam sekcja specyfikacji mogę odnieść się do tego jest naruszona przez to ograniczenie?

Answer 1

Nie jestem pewien, czy rozumiem problem poprawnie ... JNDI jest interfejsem dostawcy usług i wymaga pewnej podstawowej implementacji, aby uruchomić. Wszystko, co musisz zrobić, to zapewnić mu kontener OSGI.

Zalecam utworzenie pojedynczego pakietu ze wszystkimi słoikami wymaganymi przez JNDI i wyeksportowanie wszystkich pakietów. Następnie użyj Dynamic-Import: *, aby go użyć. Działało w naszym przypadku (aplikacja Eclipse RCP z JBoss 5 JNDI używana do połączeń EJB).

Jeśli jednak potrzebujesz JNDI wewnątrz i na zewnątrz kontenera i nie chcesz mieć problemów z Classloadingiem, poleciłbym dodać wszystkie słoiki do ścieżki klasy aplikacji. W ten sposób powinien być dostępny w całej aplikacji.

Answer 2

Wpadłem na ten sam problem podczas próby wdrożenia Apache Karaf na Weblogic. Używamy karaf poprzez mostek serwletów - wojna jest wdrażana w weblogic, która łączy wszystkie żądania HTTP z karaf.

Używam z następującymi aplikacjami na WebLogic:

1. APP1 (używa JNDI)
2. app2
3. karaf-most (mosty żądania do Karaf)

Niezwłocznie jak karaf rozpoczyna implementację Aries JNDI działającą wewnątrz Karaf ustawia InitialContextFactoryBuilder wewnątrz javax.naming.NamingManager na własną implementację. NamingManager przechowuje statyczne odwołanie do początkowego konstruktora fabryki kontekstów, więc dowolne wdrożenie, niezależnie od tego, czy działa w środowisku OSGI, powoduje, że to statyczne odwołanie staje się dostawcą JNDI.

W moim przypadku, gdy app1 (nie-OSGI) próbuje zrobić nowy InitialContext, Aries JNDI próbuje go rozwiązać przy użyciu BundleContext i nie powiedzie się.

Naprawiłem to za pomocą bardzo brzydkich hacków, które obejmowały wyodrębnianie pakietu javax.naming z jre i instalowanie go jako pakietu w karaf.

Tak więc odpowiedź na twoje pytanie: Myślę, że kwestia dotyczy w rzeczywistości, a nie OSGI, w jaki sposób zarządza wyszukiwaniem JNDI.

Answer 3

Wydaje się, że Apache Aries pomyślał o tym i dostarczył implementację budowniczego fabryki kontekstu początkowego JRE (org.apache.aries.jndi.JREInitialContextFactoryBuilder), który wydaje się działać. Aby to działało, musiałem zmienić kod Aries, który rejestruje szeroki początkowy konstruktor kontekstu maszyny JVM. Może istnieć inny (i być może lepszy) sposób osiągnięcia tego. Ale wydawało się, że działa.

Należy również pamiętać, że problem nie kończy się na ustawianiu InitialContextFactoryBuilder w menedżerze nazw NamingManager. To samo dotyczy ObjectFactoryBuilder (który ponownie ustawia JVM w NamingManager). W zależności od dostawcy JNDI, z którym próbujesz się połączyć, może być konieczna zmiana tej części kodu JNDI Aries. na przykład dla połączenia Tibco EMS JNDI, musiałem zmodyfikować kod dla OSGiObjectFactoryBuilder z Aries, aby zwrócić specyficzny dla Tibco ObjectFactory. Można to łatwo uogólnić za pomocą wartości środowiska Context.OBJECT_FACTORIES.

Podniosłem JIRA dla tego samego - https://issues.apache.org/jira/browse/ARIES-1127