Hello, On 25 sept. 2013, at 16:59, Debeerst Benjamin <[email protected]> wrote:
> Hello all, > > > > First of all I'd like to say how wonderful iPOJO works. Thanks for all > the hard work going into that project (and all the others at Apache > Felix). Thanks ! > (Most of the time) there's good warnings or errors on why a > requirement could not be fulfilled, also the messages when > configurations don't work look nice (Altough one single error rather > than 3 is probably enough for non-applicable configurations.) > I agree, we are cleaning this. > > > To the actual problem: Although the documentation on requiring services > [1] is pretty extensive and detailed, there is an important note > missing: namely when a service requirement is declared via callback > methods, how is the actual specification is determined? Which contraints > are exsiting for the method names? > The method name is only involved in the computation of the dependency id, and is not involved in the specification deduction. However, we recently fixed a bug about this (https://issues.apache.org/jira/browse/FELIX-4228). When a dependency is using methods only, the specification deduction relies on the method signature. If the method parameters are not suitable for the deduction (i.e. does not receive the service object), an error is raised. When a dependency is using methods and other injection types (constructors and/or fields), then the information is deduced from the other injection points. The issue often arises from the implicit combinations of methods, constructors and fields into the same dependency. When the 'id' attribute is set, the combination is explicit. When the dependency id is not set, an id is automatically computed: - for fields and constructors, it's the specification name - for method its the method name without the 'bind' prefix (if this prefix is used). I agree it's not crystal clear, and we should improve this. > > > I was wondering the whole time why no service was bound for an > implementation like this: > > > > Set<MyServiceInterface> myServices; > > @Bind(optional=true, aggregate=true) > > addMyService(MyServiceInterface newService) { > > myServices.add(newService); > > } > > > > I thought the specification and binding would be clear through the @Bind > annotation and the method signature. However it turns out that the > method name has to start with 'bind' to get this to work: > > > > Set<MyServiceInterface> myServices; > > @Bind(optional=true, aggregate=true) > > bindMyService(MyServiceInterface newService) { > > myServices.add(newService); > > } > > It should not be an issue for the specification deduction. It's probably related to the bug we fixed. Anyway, I've opened https://issues.apache.org/jira/browse/FELIX-4250 to track it. As we are heavily working on improving the dependency model (timeout, exception, interceptors were recently added), we are going to rewrite the documentation. I hope to simplify it while being as precise as possible. > > Maybe it would be good to mention this requirement in the documentation > [1], and document some details on the specification discovery. I could > not find a note about that. > > > > I also post this to the list as others might run into the same issue. > > > > Moreover I was wondering why the 'specification' argument of the @Bind > annotation is a String and not a Class object? It would be very helpful > to be able to write @Bind(specification=MyService.class). For the > @Provides class annotation this is possible. > > (@Bind(specification=MyService.class.getName()) is not possible either, > because it is not regarded as a constant expression by the compiler) > I've opened another ticket about this: https://issues.apache.org/jira/browse/FELIX-4251. The main issue is to keep the backward compatibility. Thanks and Regards, Clement > > Regards, > > Benjamin > > > > [1] > http://felix.apache.org/documentation/subprojects/apache-felix-ipojo/apa > che-felix-ipojo-userguide/describing-components/service-requirement-hand > ler.html > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
