JB,
Keep in mind the web application, .war not .wab, correctly retrieved a
Bluetooth define service. It is the @Component defined service that was not
found.
Is there some additional information I can provide? Below are the methods used
to retrieve services via JNDI, I can add additional logging if needed.
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NameNotFoundException;
import javax.naming.NamingException;
protected <T> T getServiceViaJndi(Context ctx,
Class<T> serviceInterfaceClass) {
T service = null;
String serviceInterface = serviceInterfaceClass.getCanonicalName();
try {
service = (T) ctx.lookup("osgi:service/" + serviceInterface);
} catch (NameNotFoundException e) {
getLogger().warn("Not Found Service " + serviceInterface, e);
} catch (NamingException e) {
getLogger().warn("Exception Loading Service " +
serviceInterface, e);
}
getLogger().info("Loaded Service {} = {}", serviceInterface, service);
return service;
}
protected <T> T getServiceViaJndi(Class<T> serviceInterfaceClass) {
try {
Context ctx = new InitialContext();
return getServiceViaJndi(ctx, serviceInterfaceClass);
} catch (NamingException e) {
getLogger().error("Getting " + serviceInterfaceClass.getName(),
e);
return null;
}
}
Paul Spencer
> On Sep 9, 2020, at 2:22 PM, Jean-Baptiste Onofre <j...@nanthrax.net> wrote:
>
> If the InitialContextFactory is the one of Karaf (not one embedded in the
> WebApplication), it should work.
> I suspect that, as you don’t have the import, when you do new
> InitialContextFactory in the WAR (in its own class loader), you don’t
> actually the context factory from Karaf.
>
> Let me prepare a test case to check this.
>
> Regards
> JB
>
>> Le 9 sept. 2020 à 18:52, Paul Spencer <paulspen...@mindspring.com> a écrit :
>>
>> JB,
>> 1) I am using “new InitialContext()” as defined in the 4.17.3 of the Karaf
>> Container Documentation.
>>
>> 2) The application is deployed as a WAR
>>
>> Paul Spencer
>>
>>> On Sep 9, 2020, at 12:39 PM, Jean-Baptiste Onofre <j...@nanthrax.net> wrote:
>>>
>>> Does your WebApplication use the InitialContextFactory from Karaf ?
>>>
>>> I mean: how do you deploy your WebApplication ? As WebBundle or WAR ?
>>>
>>> About JNDI "name" for service, you just have to add osgi.jndi.service.name
>>> service property.
>>>
>>> For instance, using "pure" Activator, you can do:
>>>
>>> Hashtable<String, String> serviceProperties = new Hashtable();
>>> serviceProperties.put("osgi.jndi.service.name", "my/foo");
>>> ref = bundleContext.registerService(Foo.class, foo, serviceProperties);
>>>
>>> Regards
>>> JB
>>>
>>>> Le 9 sept. 2020 à 18:31, Paul Spencer <paulspen...@mindspring.com> a écrit
>>>> :
>>>>
>>>> JB,
>>>> 1) The feature JNDI feature is install.
>>>>
>>>> 2) I have a OSGi command that has access to the
>>>> TouchPointManagerWebService service via JNDI. It is the Web Application
>>>> that has no access to the TouchPointManagerWebService service. Both the
>>>> command and the Web Application have access to the EwmConfigurationService
>>>> service. The EwmConfigurationService Is defined via Blueprint.
>>>>
>>>> 3) Please provide an example of “You can also add a service property
>>>> osgi.jndi.name to simplify the lookup.”
>>>>
>>>> ***
>>>> * Supporting information
>>>> ****
>>>> karaf@ewm-server()> bundle:services -p ewm-tpm-client ewm-configuration
>>>>
>>>> TouchPoint Manager Web Service Client (186) provides:
>>>> --------------------------------------------------------------
>>>> component.id = 29
>>>> component.name =
>>>> com.example.touchPointClient.internal.TouchPointWebServiceImpl
>>>> objectClass =
>>>> [com.example.touchPointWsApi.webServices.TouchPointManagerWebService]
>>>> service.bundleid = 186
>>>> service.id = 253
>>>> service.scope = bundle
>>>>
>>>> Configuration (176) provides:
>>>> --------------------------------------
>>>> objectClass = [com.example.core.services.EwmConfigurationService]
>>>> osgi.service.blueprint.compname = ewmConfigurationService
>>>> service.bundleid = 176
>>>> service.id = 219
>>>> service.scope = bundle
>>>> ----
>>>> objectClass = [org.osgi.service.blueprint.container.BlueprintContainer]
>>>> osgi.blueprint.container.symbolicname = ewm-configuration
>>>> osgi.blueprint.container.version = 2.0.0.SNAPSHOT
>>>> service.bundleid = 176
>>>> service.id = 250
>>>> service.scope = singleton
>>>> karaf@root()>
>>>>
>>>> karaf@ root()> feature:list --installed | grep -i jndi
>>>>
>>>>
>>>>
>>>> jndi │ 4.2.9 │ x │ Started │
>>>> enterprise-4.2.9 │ OSGi Service Registry JNDI access
>>>> karaf@root()> list -t 0| grep -i jndi
>>>> 84 │ Active │ 30 │ 9.4.28.v20200408 │ Jetty :: JNDI Naming
>>>> 197 │ Active │ 30 │ 1.1.0 │ Apache Aries JNDI API
>>>> 198 │ Active │ 30 │ 1.0.2 │ Apache Aries JNDI Core
>>>> 199 │ Active │ 30 │ 1.0.0 │ Apache Aries JNDI Support
>>>> for Legacy Runtimes
>>>> 200 │ Active │ 30 │ 1.0.0 │ Apache Aries JNDI RMI
>>>> Handler
>>>> 201 │ Active │ 30 │ 1.1.0 │ Apache Aries JNDI URL
>>>> Handler
>>>> 202 │ Active │ 30 │ 4.2.9 │ Apache Karaf :: JNDI :: Core
>>>> karaf@root()> jndi:names
>>>> JNDI Name │ Class Name
>>>> ────────────────────────┼───────────────────────────────────────────────
>>>> osgi:service/jndi │ org.apache.karaf.jndi.internal.JndiServiceImpl
>>>> osgi:service/jdbc/test │ org.postgresql.jdbc2.optional.SimpleDataSource
>>>> karaf@root()>
>>>>
>>>>
>>>> Paul Spencer
>>>>
>>>>
>>>>>> On Sep 9, 2020, at 12:07 PM, Jean-Baptiste Onofre <j...@nanthrax.net>
>>>>>> wrote:
>>>>>
>>>>> Hi Paul,
>>>>>
>>>>> If your component expose a service (that you can see with bundle:services
>>>>> for instance), and you have also the jndi feature installed, nothing to
>>>>> do: you will have the JNDI name mapped to the OSGi service (it’s not
>>>>> related to blueprint or DS, it’s directly service). You can also add a
>>>>> service property osgi.jndi.name to simplify the lookup.
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>>> Le 9 sept. 2020 à 18:03, Paul Spencer <paulspen...@mindspring.com> a
>>>>>> écrit :
>>>>>>
>>>>>> Karaf 4.2.9
>>>>>> PAX-WEB 7.2.16
>>>>>>
>>>>>> I have a running in a MyFaces web application and I am not getting an
>>>>>> OSGi Service defined via @Component via JNDI?
>>>>>>
>>>>>> I am following the "OSGi Services Registry and JNDI" documentation in
>>>>>> https://karaf.apache.org/manual/latest/#_naming_jndi to access the
>>>>>> service. Services defined via Blueprint are available to the web
>>>>>> application where as services defined via @Component are not.
>>>>>> Specifically the ctx.lookup(“osgi:service/...”) returns null for
>>>>>> services define via @Component.
>>>>>>
>>>>>> What is needed for services defined using @Component
>>>>>> (org.osgi.service.component.annotations.Component) to be available to a
>>>>>> Web Application using PAX-WEB via the JNDI schema
>>>>>> osgi:service/<interface>[/<filter>] ?
>>>>>>
>>>>>> Note: I have defined command in Karaf that is able to access the
>>>>>> service via @Reference
>>>>>> (org.apache.karaf.shell.api.action.lifecycle.Reference) and the JNDI
>>>>>> schema osgi:service/<interface>[/<filter>]
>>>>>>
>>>>>>
>>>>>> ***
>>>>>> * Environment information
>>>>>> ***
>>>>>> karaf@root()> feature:list --installed | grep -i pax
>>>>>>
>>>>>>
>>>>>>
>>>>>> pax-http-service │ 7.2.16 │ │ Started │
>>>>>> standard-4.2.9 │ Pax-Web OSGi HTTP Service
>>>>>> pax-web-core │ 7.2.16 │ │ Started │
>>>>>> org.ops4j.pax.web-7.2.16 │ Provide Core pax-web bundles
>>>>>> pax-jetty │ 9.4.28.v20200408 │ │ Started │
>>>>>> org.ops4j.pax.web-7.2.16 │ Provide Jetty engine support
>>>>>> pax-http-jetty │ 7.2.16 │ │ Started │
>>>>>> org.ops4j.pax.web-7.2.16 │
>>>>>> pax-http │ 7.2.16 │ │ Started │
>>>>>> org.ops4j.pax.web-7.2.16 │ Implementation of the OSGI HTTP Service
>>>>>> pax-http-whiteboard │ 7.2.16 │ │ Started │
>>>>>> org.ops4j.pax.web-7.2.16 │ Provide HTTP Whiteboard pattern support
>>>>>> pax-war │ 7.2.16 │ x │ Started │
>>>>>> org.ops4j.pax.web-7.2.16 │ Provide support of a full WebContainer
>>>>>> pax-transx-tm-api │ 0.4.4 │ │ Started │
>>>>>> pax-transx-0.4.4 │
>>>>>> pax-transx-tm-geronimo │ 0.4.4 │ │ Started │
>>>>>> pax-transx-0.4.4 │
>>>>>> pax-jdbc-spec │ 1.4.4 │ │ Started │
>>>>>> org.ops4j.pax.jdbc-1.4.4 │ Provides OSGi JDBC Service spec
>>>>>> pax-jdbc │ 1.4.4 │ │ Started │
>>>>>> org.ops4j.pax.jdbc-1.4.4 │ Provides JDBC Service support
>>>>>> pax-jdbc-config │ 1.4.4 │ │ Started │
>>>>>> org.ops4j.pax.jdbc-1.4.4 │ Provides JDBC Config support
>>>>>> pax-jdbc-postgresql │ 1.4.4 │ x │ Started │
>>>>>> org.ops4j.pax.jdbc-1.4.4 │ Provides JDBC PostgreSQL DataSourceFactory
>>>>>> pax-cdi │ 1.1.3 │ x │ Started │
>>>>>> org.ops4j.pax.cdi-1.1.3 │ Provide CDI support
>>>>>> pax-cdi-weld │ 1.1.3 │ │ Started │
>>>>>> org.ops4j.pax.cdi-1.1.3 │ Weld CDI 1.2 support
>>>>>> karaf@root()> list | grep -i pax
>>>>>> 133 │ Active │ 80 │ 1.4.4 │ OPS4J Pax JDBC Generic
>>>>>> Driver Extender
>>>>>> 134 │ Active │ 80 │ 1.4.4 │ OPS4J Pax JDBC Config
>>>>>> 135 │ Active │ 80 │ 1.4.4 │ OPS4J Pax JDBC Pooling
>>>>>> Support Base
>>>>>> 143 │ Active │ 80 │ 0.4.4 │ pax-transx-tm-api
>>>>>> 144 │ Active │ 80 │ 0.4.4 │ pax-transx-tm-geronimo
>>>>>> 233 │ Active │ 80 │ 1.1.3 │ OPS4J Pax CDI Bean Bundle
>>>>>> API
>>>>>> 234 │ Active │ 80 │ 1.1.3 │ OPS4J Pax CDI Extender for
>>>>>> Bean Bundles
>>>>>> 235 │ Active │ 80 │ 1.1.3 │ OPS4J Pax CDI Portable
>>>>>> Extension for OSGi
>>>>>> 236 │ Active │ 80 │ 1.1.3 │ OPS4J Pax CDI Service
>>>>>> Provider Interface
>>>>>> 237 │ Active │ 80 │ 1.1.3 │ OPS4J Pax CDI Weld Adapter
>>>>>> karaf@root()>
>>>>>> karaf@root()> list | grep -i faces
>>>>>> 230 │ Resolved │ 80 │ 5.1.0 │ primefaces
>>>>>> 240 │ Resolved │ 80 │ 2.2.12 │ Apache MyFaces JSF-2.2
>>>>>> Core API
>>>>>> 242 │ Resolved │ 80 │ 2.2.12 │ Apache MyFaces JSF-2.2
>>>>>> Core Impl
>>>>>>
>>>>>> Paul Spencer
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
