Frank Lyaruu created FELIX-5151:
-----------------------------------
Summary: Scr Bind methods occasionally gets a null service
reference
Key: FELIX-5151
URL: https://issues.apache.org/jira/browse/FELIX-5151
Project: Felix
Issue Type: Bug
Components: Declarative Services (SCR)
Affects Versions: scr-1.8.2
Environment: Felix 4.4.0, MacOS, Java 8b66
Reporter: Frank Lyaruu
Hi Felix devs,
I'm having an intermittent issue with null services being passed to SCR bind
methods.
For example in this piece of code:
@Reference(name = "GitRepository", unbind =
"removeGitRepository",policy=ReferencePolicy.DYNAMIC,cardinality=ReferenceCardinality.MULTIPLE,target="(bare=true)")
public synchronized void addGitRepository(GitRepository bareRepository,
Map<String,Object> settings) {
if(bareRepository==null) {
logger.warn("add reference got passed a null. Settings: "+settings);
}
// ....
}
Most of the time it works fine, but from time to time a null reference gets
passed.
The output of the above snippet looks like this:
[main] WARN com.dexels.consul.repositoryloader.impl.RepositoryListenerImpl -
add reference got passed a null (thread: main). Settings:
{url=https://github.com/foo/bar, component.name=dexels.repository.git.bare,
id=backoffice, token=xxx, service.factoryPid=dexels.repository.git.bare,
objectClass=[Ljava.lang.String;@60baef24, bare=true, repositoryname=foo,
service.pid=dexels.repository.git.bare.5fd0cefd-ec30-4418-92d4-a708792590d8,
component.id=44, event.topics=[Ljava.lang.String;@6692b6c6, service.id=95}
And then it fails with an NPE when it tries to use the service:
java.lang.NullPointerException
at
com.dexels.consul.repositoryloader.impl.RepositoryListenerImpl.addGitRepository(RepositoryListenerImpl.java:135)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
org.apache.felix.scr.impl.helper.BaseMethod.invokeMethod(BaseMethod.java:231)
at org.apache.felix.scr.impl.helper.BaseMethod.access$500(BaseMethod.java:39)
at
org.apache.felix.scr.impl.helper.BaseMethod$Resolved.invoke(BaseMethod.java:624)
at org.apache.felix.scr.impl.helper.BaseMethod.invoke(BaseMethod.java:508)
at org.apache.felix.scr.impl.helper.BindMethod.invoke(BindMethod.java:37)
at
org.apache.felix.scr.impl.manager.DependencyManager.doInvokeBindMethod(DependencyManager.java:1608)
at
org.apache.felix.scr.impl.manager.DependencyManager.open(DependencyManager.java:1473)
at
org.apache.felix.scr.impl.manager.SingleComponentManager.createImplementationObject(SingleComponentManager.java:277)
at
org.apache.felix.scr.impl.manager.SingleComponentManager.createComponent(SingleComponentManager.java:127)
I see this issue pop up from time to time across different services and
different applications. It is pretty rare, but it does cause instability and it
is tricky to work around. If I switch to equinox + equinox declarative
services, this issue goes away.
It is quite a pain to reproduce, but I have captured it in a debugger a few
times:
What I see there is that the
org.apache.felix.scr.impl.helper.BindMethod.getParameters:605
return new Object[] {refPair.getServiceObject(), new
ReadOnlyDictionary( refPair.getRef() )};
The first array element: refPair.getServiceObject() yields null from time to
time.
In RefPair.getServiceObject():
public T getServiceObject()
{
return serviceObjectRef.get();
}
Where serviceObjectRef is an AtomicReference, and this is as far as my research
got.
I realise this is not the best bug report ever, but is there anyone who has
seen this before and can shed some light?
regards, Frank
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
