-
Notifications
You must be signed in to change notification settings - Fork 144
avoids IllegalArgumentException on unget #334
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
@tjwatson It would be great if you could have a look at this. |
83acc18
to
2bd466f
Compare
fixes https://issues.apache.org/jira/browse/FELIX-6726 ungetServiceObject may be called twice in some cases, which causes an IllegalArgumentException to be thrown and logged. Signed-off-by: Juergen Albert <[email protected]>
2bd466f
to
a623362
Compare
The prototype service references were implemented before my involvement in the SCR implementation. I admit that I am unclear on exactly how the prototype references are supposed to be handled, but I think there is a larger issue with how the prototype references are managed and tracked beyond this IllegalArgumentException. Consider a component that has two field references that are prototype required. In this case lets have them be a reference to A and a reference to B:
Should Right now it appears Felix SCR creates only one The other problem, which is more directly related to this issue, is that this call ends up ungetting the service object:
In fact it ends up ungetting all prototype instances from the prototye factory and closing down the tracking. This seems wrong to me and I am unclear what would happen if we had With all that said, this appears to be a much more complicated issue that I cannot spend time one for now and I am not convinced the fix in the current PR is correct for non-prototype service references. For now I suggest we catch the That is until we can get a better view of the correct specification behavior with respect to prototype service references. |
@tjwatson I am not 100% sure but I think we discussed how to handle multiple references to a single prototype from one component in the spec group and decided to handle this as a single reference which is then injected into the various fields/methods. |
I see that in https://docs.osgi.org/specification/osgi.cmpn/8.1.0/service.component.html#service.component-reference.scope which says:
But the problem is then later the spec says this which has some contradiction:
The problem is implementing this |
I am not sure if the second stated paragraph is a clear contradiction - but I get the problem with the current implementation of unget. Without any deeper thinking, I guess we need a usage (# references) counter. That would avoid the exception and would solve the edge case mentioned. |
@tjwatson What you describe seems to be an issue as well, but I'm not sure if this is what is causing this issue here. In my case here, I have only on Reference here, but for some reason, SCR thinks it has the service injected twice, because the service provides 2 interfaces that both are instances of the requested interface A. Thus I'm not sure, if this is the same issue we have here. I'm not sure if my solution is the right one and feels more like a workaround to the actual problem, that SCR sees one reference as 2 |
@juergen-albert Can you share your component xml? or the code? |
The test attached to this PR provokes the Behavior. |
It is related though because of this line of code in felix-dev/scr/src/main/java/org/apache/felix/scr/impl/manager/DependencyManager.java Line 2231 in c32fcc4
That ungets all known service objects that were obtained from the |
What I think needs to happen here is that it should not call But this still has weird corner cases if the All of this would have been so much more clear if each reference used a different |
How the hell did I manage to debug this setup the last time I worked on that? @tjwatson The main issue, is that felix-dev/scr/src/main/java/org/apache/felix/scr/impl/manager/DependencyManager.java Line 1948 in c32fcc4
produces returns a collection with 2 RefPair which both represent the same Object. I know this is kind of what you referred to in your issue description above, in my case , I have only one Reference declared, so I would expect only one RefPair to be here.
|
that sounds like the wrong customizer is used, the static singleton one only returns 0 or 1 |
For what it is worth, I don't see that while debugging your test, but I also don't see the actual exception get thrown, instead it is only logged. |
Strange. I can't confirm or deny what you see, as I'm unable to debug at the Moment. That the Exception is only logged is normal. |
Don't forget you have to uncomment this line in your test class to debug:
|
ahh, that makes sense :-) Thanks heaps. I'll take another look today and will post my findings. |
I finally have the cause of the issue here in this case and I actually think my suggest fix is correct:
|
Which after rereading @tjwatson initial comment shows that he was right as well, as he was already pointing at this issue. |
I have my doubts for cases that are not prototype references because in that case this will do nothing: felix-dev/scr/src/main/java/org/apache/felix/scr/impl/manager/DependencyManager.java Line 2230 in a623362
So I expect other reference types will be left with references that were never ungotten. |
fixes https://issues.apache.org/jira/browse/FELIX-6726
ungetServiceObject may be called twice in some cases, which causes an
IllegalArgumentException to be thrown and logged. It furthermore causes
to recreated ComponentServiceObjects to be created and never cleaned up
afterwards.