Овен jndi поиск в osgi

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

Мой план xml выглядит так:

<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">
 <bean id="repositoryservice"
  class="com.example.repository.jndi.RepoImpl">
 </bean>

 <service ref="repositoryservice"
  interface="javax.jcr.Repository">
 </service>

</blueprint>

Я попробовал поиск с помощью:

Context jndiContext = new InitialContext();
Repository repo = (Repository)jndiContext.lookup("osgi:service/" + 
                   Repository.class.getName());

Я развернул 4 пакета:

  1. Утилита Apache Aries
  2. Пакет прокси-серверов Apache Aries
  3. Пакет чертежей Apache Aries
  4. Пакет Apache Aries JNDI

Но я получаю исключение:

javax.naming.NamingException: Lookup failed for 'osgi:service/javax.jcr.Repository' in SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming} [Root exception is javax.naming.NameNotFoundException: osgi:service]
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:518)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at com.example.JndiTest.testRepositoryNotNull(JndiTest.java:27)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at junit.framework.TestCase.runTest(TestCase.java:176)
at junit.framework.TestCase.runBare(TestCase.java:141)
at junit.framework.TestResult$1.protect(TestResult.java:122)
at junit.framework.TestResult.runProtected(TestResult.java:142)
at junit.framework.TestResult.run(TestResult.java:125)
at junit.framework.TestCase.run(TestCase.java:129)
at junit.framework.TestSuite.runTest(TestSuite.java:255)
at junit.framework.TestSuite.run(TestSuite.java:250)
at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Caused by: javax.naming.NameNotFoundException: osgi:service
at com.sun.enterprise.naming.impl.TransientContext.resolveContext(TransientContext.java:310)
at com.sun.enterprise.naming.impl.TransientContext.lookup(TransientContext.java:218)
at com.sun.enterprise.naming.impl.SerialContextProviderImpl.lookup(SerialContextProviderImpl.java:77)
at com.sun.enterprise.naming.impl.RemoteSerialContextProviderImpl.lookup(RemoteSerialContextProviderImpl.java:109)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie.dispatchToMethod(ReflectiveTie.java:144)
at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie._invoke(ReflectiveTie.java:174)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:528)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:199)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1624)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1486)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:990)
at com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:214)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:742)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.dispatch(CorbaMessageMediatorImpl.java:539)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.doWork(CorbaMessageMediatorImpl.java:2324)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:497)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:540)

Я забыл пачку? Кто-нибудь может мне помочь?


person bg89    schedule 03.06.2013    source источник


Ответы (1)


GlassFish имеет собственный механизм JNDI, а Aries JNDI также является автономной реализацией.

Обычные приложения Java EE (EAR, WAR, ...) будут использовать движок GlassFish JNDI. Движок Glassfish JNDI не поддерживает «osgi:service». Если ваша подсистема представляет собой обычное приложение Java EE, она не будет работать.

Основываясь на вашей трассировке стека, вы используете движок Glassfish JNDI.

Aries JNDI полезен в случае следующего сценария: у вас есть существующий файл JAR с классом, который ищет объект через JNDI. Расположение JNDI можно настроить. Вы добавляете записи OSGi в MANIFEST.MF и развертываете JAR в контейнере OSGi. Даже в этом случае вы должны быть уверены, что ваш новый пакет подключается к Aries JNDI и что служба зарегистрирована до выполнения поиска.

person Balazs Zsoldos    schedule 03.06.2013
comment
Как я могу зарегистрировать службу osgi, которую я могу искать в другой JVM без aries? Если я зарегистрирую его в пакетном контексте, только другие пакеты смогут найти службу. - person bg89; 03.06.2013
comment
Другая JVM или в той же JVM, но вне контейнера OSGi? Если вас интересует другая JVM, это можно сделать только через какой-либо удаленный протокол (RMI, SOAP WS, RESTFul API,...) - person Balazs Zsoldos; 03.06.2013
comment
Глава об удаленных службах спецификации OSGi Enterprise может быть вам интересна. Вы можете найти две основные реализации: Apache CXF DOSGi, Eclipse ECF. С помощью этих двух вы можете удаленно предоставлять службы OSGi и использовать эти службы из другого контейнера OSGi. Однако эти технологии используют упомянутые решения внутри (например, REST API, SOAP, ...) - person Balazs Zsoldos; 03.06.2013
comment
Теоретически возможно ли использовать JNDI для доступа к службе osgi в другой JVM? - person bg89; 04.06.2013