[
https://issues.apache.org/jira/browse/FELIX-5151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15072581#comment-15072581
]
Frank Lyaruu commented on FELIX-5151:
-------------------------------------
That sounds perfect.
> 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)
