2013-06-03 5 views
0

Mon application a quelques modules OSGI et une partie non-OSGI. J'ai essayé de rechercher des services osgi dans un sous-système non-osgi via JNDI avec apache aries. J'utilise glassfish.Bélier jndi recherche dans osgi

Mon xml plan ressemble:

<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> 

J'ai essayé une recherche avec:

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

I déployé 4 Bundles:

  1. Apache Aries Util
  2. Apache Aries Proxy Lot
  3. Apache Aries Plan Bundle
  4. Apache Aries JNDI Bundle

mais je reçois une exception:

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) 

Ai-je oublié un paquet? Quelqu'un peut-il m'aider?

Répondre

0

GlassFish possède son propre moteur JNDI, tandis qu'Aries JNDI est également une implémentation autonome.

Les applications Java EE ordinaires (EAR, WAR, ...) utiliseront le moteur GlassFish JNDI. Le moteur Glassfish JNDI ne prend pas en charge "osgi: service". Dans le cas où votre sous-système est une application Java EE ordinaire, cela ne fonctionnera pas.

En fonction de votre stacktrace, vous utilisez le moteur Glassfish JNDI.

Bélier JNDI est utile dans le cas du scénario suivant: Vous avez un fichier JAR existant qui a une classe qui recherche un objet via JNDI. L'emplacement JNDI peut être configuré. Vous ajoutez des entrées OSGi à MANIFEST.MF et déployez le fichier JAR dans le conteneur OSGi. Même dans ce cas, vous devez vous assurer que votre nouveau faisceau relie l'Aries JNDI et que le service est enregistré avant la recherche.

+0

Comment puis-je enregistrer un service osgi que je peux rechercher dans une autre machine JVM sans Aries? Si je l'enregistre avec le bundlecontext, seuls les autres bundles peuvent trouver le service – bg89

+0

Une autre JVM ou dans la même JVM mais en dehors du conteneur OSGi? Si vous êtes intéressé par une autre JVM, cela ne peut se faire que via un protocole distant (RMI, SOAP WS, API RESTFul, ...) –

+0

Oui, une autre JVM – bg89

Questions connexes