2011/5/11 Rupert Westenthaler <[email protected]>: > Hi all > > The ContextHelper utility class [1] contains the following Method > > public static <T> T getServiceFromContext(Class<T> clazz, > ServletContext context) { > BundleContext bundleContext = (BundleContext) > context.getAttribute(BundleContext.class.getName()); > ServiceReference reference = > bundleContext.getServiceReference(clazz.getName()); > return (T) bundleContext.getService(reference); > } > > This is typically called by JAX-RS Providers and Resources to lookup > required OSGI services via the servlet context. Such resources > (typically) do have a score that is limited to a single request (so > that implementers do not have to worry about threading issues). > Therefore one need to expect a lot of calls to this method. > > I am not worried about the frequent lookup of services, but I am > worried about that with this there are no calls to the ungetService > [2] method. > > If this is a problem I see two alternatives: > (1) add an additional method to WebFragment that allows to specify > the services this Fragment needs. Than it would be possible to add > such services to the Servlet context as soon as the WebFragment starts > and remove it when the fragment is removed. The above method would > than just return the service already present within the servlet > context
+1. The endpoint should leverage the JAX-RS @Context annotation to introspect all the JAX-RS components contributed by WebFragments to build the list of OSGi service that need to be looked up by the endpoint once to be used and re-used by the many instances of JAX-RS components. We need to have a look at how jersey handles context lookups and whether this can be extended for our purposes. -- Olivier http://twitter.com/ogrisel - http://github.com/ogrisel
