I have the feeling checking return type is a bug. As per enterprise spec 121.9.1: Signature Disambiguation Constructors, factory methods, and property set methods are described with Metadata. The Blueprint Container must map these descriptions to an actual method or constructor. In practice, there can be multiple methods/constructors that could potentially map to the same description. It is therefore necessary to disambiguate this selection. Both factory methods and constructors have the same concept of signatures. A signature consists of an ordered sequence of zero or more types. For methods, only publicly accessible methods with the appropriate name are considered. For constructors, all publicly accessible constructors are considered. The disambiguation process described here is valid for all constructors and methods because the signature concept applies to both of them. 1 Discard any signatures that have the wrong cardinality 2 Find the list of signatures that have assignable types for each argument in their corresponding positions. Assignable is defined in Type Compatibility on page 239. If a type was specified for an argument, then this type must match the name of the corresponding reified type in the signature exactly. 3 If this result list has one element, then this element is the answer. If this list has more than one element, then the disambiguation fails. 4 Otherwise, find the list of signatures that have compatible types for each argument in their corresponding positions. Compatibility is defined in Type Compatibility on page 239. 5 If this result list has one element, then this element is the answer. If the list has more than one element, then the disambiguation fails. 6 If the arguments cannot be reordered (the index of the argument is used and is thus not -1, or there are less than two arguments) then the disambiguation fails. 7 Find all signatures that match a re-ordered combination of the arguments. Reordering must begin with the first argument and match this argument against the first assignable types in a signature, going from position 0 to n. If the type is assignable from the argument, then it is locked in that position. If the argument has a type, then it must exactly match the name of the selected signature type. The same is done for the subsequent arguments. If all arguments can find an exclusive position in the signature this way, than the signature is added to the result. 8 If the result list contains one signature, then this is the resulting signature. If the list has more than one element, then the disambiguation fails. 9 Repeat step 6, but now look for compatible types instead of assignable types. 10 If the result list contains one signature, then this is the resulting signature. 11 Otherwise, the disambiguation fails
JP De : CLEMENT Jean-Philippe [mailto:[email protected]] Envoyé : mardi 24 juin 2014 17:03 À : [email protected] Objet : RE: Troubles when creating a builder with blueprint. Two methods doing the same thing are what I call duplicates… but anyway… Is checking the return type of a method part of Blueprint spec or not? JP De : Charlie Mordant [mailto:[email protected]]<mailto:[mailto:[email protected]]> Envoyé : mardi 24 juin 2014 15:51 À : [email protected]<mailto:[email protected]> Objet : Re: Troubles when creating a builder with blueprint. A Javabean is manipulated by a builder, a Javabean isn't a builder itself. I gave builder pattern implementation and did not duplicated any method of the bean (I made an internal builder class). http://en.wikipedia.org/wiki/Builder_pattern Javabean spec specify setter should be void, blueprint just follows the spec: look at section 7.1 and 8.3 of the JavaBean Spec: http://www.oracle.com/technetwork/java/javase/documentation/spec-136004.html Regards, 2014-06-24 15:18 GMT+02:00 CLEMENT Jean-Philippe <[email protected]<mailto:[email protected]>>: I understand I can duplicate methods, either manually or not. My question is rather why some extra code has been added to check return type although it is outside Java spec? ...does Blueprint specify to do so? JP -----Message d'origine----- De : Jean-Baptiste Onofré [mailto:[email protected]<mailto:[email protected]>] Envoyé : mardi 24 juin 2014 14:53 À : [email protected]<mailto:[email protected]> Objet : Re: Troubles when creating a builder with blueprint. Hi JP, you can using a wrapper bean or a factory. Regards JB On 06/24/2014 12:20 PM, CLEMENT Jean-Philippe wrote: > A builder usually returns itself to cumulates changes via Java. It could be > good to use the same method either from Java or Blueprint. From a language > perspective there is nothing which prevents this as a method is identified > via its name and arguments; it is not tied to its return type. > > Is the return type really prohibited from the Blueprint spec or is it left > unspecified? > > JP > > > -----Message d'origine----- > De : Jean-Baptiste Onofré > [mailto:[email protected]<mailto:[email protected]>] Envoyé : lundi 23 > juin 2014 17:49 À : [email protected]<mailto:[email protected]> Objet > : Re: Troubles when > creating a builder with blueprint. > > Hi Christophe, > > in JavaBeans (following by Blueprint), a setter is void, and a getter doesn't > have argument. > So it should be: > > public void setMaxValue(float maxValue) { > this.maxValue=maxValue; > } > public float getMaxValue() { > return this.maxValue; > } > > Regards > JB > > On 06/23/2014 05:34 PM, Lasserre Christophe wrote: >> Hello, >> >> I wrote a builder containing the following setter which does not >> return void (see following sample). >> >> /** >> >> * @param maxValue >> >> * Maximal value for compression law attributes >> >> * @return the builder. >> >> */ >> >> public CompressionLawBuilder setMaxValue(final float maxValue) >> { >> >> this.maxValue = maxValue; >> >> return this; >> >> } >> >> When I try to create the builder via blueprint, the runtime returns me >> the following error message; "Caused by: >> org.osgi.service.blueprint.container.ComponentDefinitionException: No >> setter for maxValue property" >> >> If I change the setter and make it return void, everything works >> perfectly, so is it normal that the return type of the setter has an >> impact on the application behavior ? >> >> Chris. >> >> [@@ OPEN @@] >> > > -- > Jean-Baptiste Onofré > [email protected]<mailto:[email protected]> > http://blog.nanthrax.net > Talend - http://www.talend.com > -- Jean-Baptiste Onofré [email protected]<mailto:[email protected]> http://blog.nanthrax.net Talend - http://www.talend.com -- Charlie Mordant Full OSGI/EE stack made with Karaf: https://github.com/OsgiliathEnterprise/net.osgiliath.parent
