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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>>>>> 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 <[email protected]> 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 <[email protected]> >>>>>>>>> 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 <[email protected]> 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 >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
