Issue Details (XML | Word | Printable)

Key: OSGI-396
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Costin Leau
Reporter: Guillaume Nodet
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Spring OSGi

Custom collection listener bind method called twice for a given service

Created: 05/Mar/08 11:05 AM   Updated: 13/May/08 06:26 AM
Component/s: CORE
Affects Version/s: 1.0
Fix Version/s: 1.1 RC1

Time Tracking:
Not Specified


 Description  « Hide
When defining beans inheriting the following interface:

public interface ServiceRegistry<T> {
    void register(T service, Map<String, ?> properties);
    void unregister(T service, Map<String, ?> properties);
}

All service registrations makes the register method to be called twice.
It seems that the introspection on the class returns two methods, one with typed with Object, and another one typed with the actually class for T.
It seems the caller loops for all methods and call all of them. The documentation is not very clear about that, but I would think that only a single method for the given name would be called, and not all the versions of it.


 All   Comments   Work Log   Change History   FishEye   Builds      Sort Order: Ascending order - Click to sort in descending order
Costin Leau added a comment - 05/Mar/08 11:40 AM
All methods that have arguments matching that argument are called. For example, considering:

onBind(Object object)
onBind(SomeObject object)

onBind(Object) will be called one if an Object is bound but both onBind(Object) and onBind(SomeObject) will be called if SomeObject is used since both Object and SomeObject are compatible.

Costin Leau added a comment - 15/Apr/08 05:59 AM
Add more documentation for this to make the behaviour clearer.

Costin Leau added a comment - 24/Apr/08 10:51 AM
Guillaume, I initially misunderstood your problem. This will be fixed in RC1.

Costin Leau added a comment - 13/May/08 06:26 AM
Managed to solve the issue w/o depending on 1.5 (which would cause our Maven-based build infrastructure to get even more complex then it's currently is).