When this happens to me, it’s because I’m using PropertyDescriptor - it’s methods getReadMethod and getSetterMethod follow the JavaBeans spec very closely, so for example you can’t have a boxed Boolean ‘is’ getter, only primitives.
On 24 Jun 2014, at 16:24, CLEMENT Jean-Philippe <[email protected]> wrote: > 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]] > Envoyé : mardi 24 juin 2014 15:51 > À : [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]>: > 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]] > Envoyé : mardi 24 juin 2014 14:53 > À : [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]] Envoyé : lundi 23 > > juin 2014 17:49 À : [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] > > http://blog.nanthrax.net > > Talend - http://www.talend.com > > > > -- > Jean-Baptiste Onofré > [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
