You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by Paul Spencer <pa...@mindspring.com> on 2020/09/09 16:03:33 UTC

Access to @Component defined service via JNDI from Webapp using PAX-WEB?

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



Re: Access to @Component defined service via JNDI from Webapp using PAX-WEB?

Posted by Paul Spencer <pa...@mindspring.com>.
JB,
To close out this thread, I switched from using a list of bundles to support MyFaces that was used by the Karaf 3.0 based implementation of the application to the pax-jsf-support feature and all is working.

Paul Spencer


> On Sep 13, 2020, at 2:30 PM, Jean-Baptiste Onofre <jb...@nanthrax.net> wrote:
> 
> Hi Paul,
> 
> Thanks for the update. I agree: it seems something about your application and/or environment.
> 
> I will take a look tomorrow (I’m busy tonight).
> 
> Regards
> JB
> 
>> Le 13 sept. 2020 à 16:53, Paul Spencer <pa...@mindspring.com> a écrit :
>> 
>> JB,
>> I have created a simplified example based on the Karaf Booking examples and the JNDI service lookup works are you expected, which means there is something about my service or environment that is preventing the service from being accessible via JNDI within a PAX-WEB environment.
>> 
>> Paul Spencer
>> 
>>> On Sep 10, 2020, at 10:19 AM, Paul Spencer <pa...@mindspring.com> wrote:
>>> 
>>> 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 <jb...@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 <pa...@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 <jb...@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 <pa...@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 <jb...@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 <pa...@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
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 


Re: Access to @Component defined service via JNDI from Webapp using PAX-WEB?

Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
Hi Paul,

Thanks for the update. I agree: it seems something about your application and/or environment.

I will take a look tomorrow (I’m busy tonight).

Regards
JB

> Le 13 sept. 2020 à 16:53, Paul Spencer <pa...@mindspring.com> a écrit :
> 
> JB,
> I have created a simplified example based on the Karaf Booking examples and the JNDI service lookup works are you expected, which means there is something about my service or environment that is preventing the service from being accessible via JNDI within a PAX-WEB environment.
> 
> Paul Spencer
> 
>> On Sep 10, 2020, at 10:19 AM, Paul Spencer <pa...@mindspring.com> wrote:
>> 
>> 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 <jb...@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 <pa...@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 <jb...@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 <pa...@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 <jb...@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 <pa...@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
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 


Re: Access to @Component defined service via JNDI from Webapp using PAX-WEB?

Posted by Paul Spencer <pa...@mindspring.com>.
JB,
I have created a simplified example based on the Karaf Booking examples and the JNDI service lookup works are you expected, which means there is something about my service or environment that is preventing the service from being accessible via JNDI within a PAX-WEB environment.

Paul Spencer

> On Sep 10, 2020, at 10:19 AM, Paul Spencer <pa...@mindspring.com> wrote:
> 
> 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 <jb...@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 <pa...@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 <jb...@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 <pa...@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 <jb...@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 <pa...@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
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 


Re: Access to @Component defined service via JNDI from Webapp using PAX-WEB?

Posted by Paul Spencer <pa...@mindspring.com>.
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 <jb...@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 <pa...@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 <jb...@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 <pa...@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 <jb...@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 <pa...@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
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 


Re: Access to @Component defined service via JNDI from Webapp using PAX-WEB?

Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
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 <pa...@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 <jb...@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 <pa...@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 <jb...@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 <pa...@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
>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 


Re: Access to @Component defined service via JNDI from Webapp using PAX-WEB?

Posted by Paul Spencer <pa...@mindspring.com>.
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 <jb...@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 <pa...@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 <jb...@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 <pa...@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
>>>> 
>>>> 
>>> 
>> 
> 


Re: Access to @Component defined service via JNDI from Webapp using PAX-WEB?

Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
By the way, using @Component, you can do:

@Component(name = "foo", service = Foo.class, immediate = true, property = { "osgi.jndi.service.name=my/foo" })
public class MyFoo {
…
}

Regards
JB

> Le 9 sept. 2020 à 18:39, Jean-Baptiste Onofre <jb...@nanthrax.net> a écrit :
> 
> 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 <pa...@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 <jb...@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 <pa...@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
>>>> 
>>>> 
>>> 
>> 
> 


Re: Access to @Component defined service via JNDI from Webapp using PAX-WEB?

Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
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 <pa...@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 <jb...@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 <pa...@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
>>> 
>>> 
>> 
> 


Re: Access to @Component defined service via JNDI from Webapp using PAX-WEB?

Posted by Paul Spencer <pa...@mindspring.com>.
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 <jb...@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 <pa...@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
>> 
>> 
> 


Re: Access to @Component defined service via JNDI from Webapp using PAX-WEB?

Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
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 <pa...@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
> 
>