I came to this from looking at the following couple of pages and the fact that when I look at my Karaf installation, service property osgi.service.blueprint.compname references a bean. I’ve tried a few different things but thus far haven’t been able to get anything bound under blueprint:comp. osgi:service isn’t a problem.
In Karaf, I have blueprint, and I have JNDI installed, is that what you’re referring to by the “blueprint JNDI bundle”? http://www-01.ibm.com/support/knowledgecenter/SSCKBL_8.5.5/com.ibm.websphere.osgi.nd.doc/ae/ca_blueprint_jndi.html It contains the following: A WAB can contain blueprint XML. This can be used to declare and configure any number of components, which can then be looked up from servlets that are not themselves blueprint-managed. One particular use of this is shown in the OSGi blog sample application<http://www-01.ibm.com/support/knowledgecenter/api/content/SSCKBL_8.5.5/com.ibm.websphere.osgi.nd.doc/ae/sample_osgi_blog_readme.html>, in which the web bundle contains the following blueprint code: <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";> <reference id="blogService" interface="com.ibm.samples.websphere.osgi.blog.api.BloggingService"/> </blueprint> The JNDIHelper.getBloggingService() method call includes this code fragment: try { InitialContext ic = new InitialContext(); return (BloggingService) ic.lookup("blueprint:comp/blogService"); } catch (NamingException e) { This code looks up a blueprint-managed reference to an OSGi service. This is useful because blueprint-managed services are damped as described in section 121.10.1 of the OSGi Service Platform Release 4 Version 4.2 Enterprise Specification. If the BloggingService object is not available when the application code tries to use the reference, the application code waits until the service becomes available again. Previous versions of the getBloggingService method used a lookup of the following form: ic.lookup("osgi:service/com.ibm.samples.websphere.osgi.blog.api.BloggingService"); This is not so useful, because the application code can receive a ServiceUnavailableException exception if the service is not available when the application code tries to use the BloggingService object. For example: If theBloggingService object is temporarily unavailable because an in-place update is in progress, the user of the Blog web application can get an HTTP 500 (Internal Error) message in their web browser. With the new form of lookup, web requests wait for a short time (a second or two) until the update completes. Therefore it is easier to write a web application that remains continuously available, from a user perspective, even while the application is being updated in place. Also, from http://www.ibm.com/developerworks/library/os-osgiblueprint/ Service selection and proxies The reference and reference-list managers share several attributes. Three shared attributes are used for service selection: interface,component-name and a filter. You can use the interface attribute to specify an interface class. The interface class is used for two purposes: for service selection and for service proxies. The interface attribute is optional, but if set, it must specify an interface class. For service selection, the interface class is used to select services from the service registry registered with that interface name. For service proxies, the proxies returned by service reference managers must implement all the methods defined by that interface class. If the interface attribute is not specified, the proxy behaves as if it implements an interface without any methods. You can also use the component-name and filter attributes for service selection. The component-name attribute is just a convenient way of adding an osgi.service.blueprint.compname=<component-name> expression to the selection filter. Similarly, the filter attribute specifies the raw OSGi filter expression to be added to the selection filter. The interface, component-name, and filter attributes are combined to create one main OSGi filter expression used for the service selection. For example, the selection filter for the reference in Listing 7 is (&(objectClass=java.io.Serializable)), while the selection filter for the reference in Listing 9 is (&(objectClass=java.io.Serializable)(osgi.service.blueprint.compname=myAccount)(mode=shared)). Listing 9. Service selection example <reference id=”serviceReferenceTwo” interface=”java.io.Serializable” component-name=”myAccount” filter=”(mode=shared)”/> From: [email protected] [mailto:[email protected]] On Behalf Of Tim Ward Sent: Friday, September 05, 2014 1:46 PM To: OSGi Developer Mail List Subject: Re: [osgi-dev] blueprint:comp JNDI namespace Assuming that you have the blueprint JNDI bundle installed then what you need is: blueprint:comp/my-xface-impl The id of the bean is "my-xface-impl" The reference that you have declared in the XML creates a mandatory OSGi service dependency. This will prevent your blueprint container from starting unless someone else is providing an Xface service. You almost certainly don't want this, so I would suggest removing it. Regards, Tim Sent from my iPhone On 5 Sep 2014, at 16:33, "Leschke, Scott" <[email protected]<mailto:[email protected]>> wrote: Question. I think I need help with the use of the blueprint:comp JNDI namespace. If I have something like the following in a blueprint.xml, should I expect that there be a JNDI name of the form: blueprint:comp/my-xface ? <bean id="my-xface-impl" class="com.my.xface.impl.XfaceImpl"/> <reference id="my-xface" component-name=" my-xface-impl " interface=" com.my.xface.Xface"/> _______________________________________________ OSGi Developer Mail List [email protected]<mailto:[email protected]> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
