[infinispan-issues] [JBoss JIRA] (ISPN-3849) Re-work ServiceLoader concepts
Tuomas Kiviaho (JIRA)
issues at jboss.org
Thu Sep 7 05:48:00 EDT 2017
[ https://issues.jboss.org/browse/ISPN-3849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13460099#comment-13460099 ]
Tuomas Kiviaho commented on ISPN-3849:
--------------------------------------
I pinpoint here that bundle providing ServiceLoader must be in state ACTIVE. Otherwise you'll end up with NPE because BundleContext will be missing.
{code}
private static <T> void addOsgiServices(Class<T> contract, Set<T> services) {
if (!Util.isOSGiContext()) {
return;
}
ClassLoader loader = ServiceFinder.class.getClassLoader();
if ((loader != null) && (loader instanceof org.osgi.framework.BundleReference)) {
final BundleContext bundleContext = ((BundleReference) loader).getBundle().getBundleContext();
final ServiceTracker<T, T> serviceTracker = new ServiceTracker<T, T>(bundleContext, contract.getName(),
null);
serviceTracker.open();
try {
final Object[] osgiServices = serviceTracker.getServices();
if (osgiServices != null) {
for (Object osgiService : osgiServices) {
services.add((T) osgiService);
}
}
} catch (Exception e) {
// ignore
}
}
}
{code}
A far better approach might be to ditch ServiceTracker altogether in favor of just handpicking the service reference because that class requires OSGi Compendium to be present and here it's not necessarily needed for what is being done.
Side note: ServiceReference objects that are also inside ServiceTracker should always be unget after service is no longer needed. Hence the open doesn't have close companion which contradicts the WhiteBoard pattern.
> Re-work ServiceLoader concepts
> ------------------------------
>
> Key: ISPN-3849
> URL: https://issues.jboss.org/browse/ISPN-3849
> Project: Infinispan
> Issue Type: Sub-task
> Components: Core
> Reporter: Brett Meyer
> Assignee: Brett Meyer
> Fix For: 7.0.0.Alpha4
>
>
> Any uses of ServiceLoader will need to be replaced by a new utility to first check OSGi services w/ SL as a fallback. This also requires that any internal services also need to be registered with OSGi (as well as external extension point impls, etc.). That's not invasive at all. OSGi blueprint files are very similar to the service loader text files in META-INF/services.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
More information about the infinispan-issues
mailing list