-
1. Re: JBMICROCONT-380; constructor (property) matching
adrian.brock Nov 6, 2008 10:38 AM (in response to alesj)Like I said on the JIRA issue, its not possible in general.
The only way to get close would be for the ValueMetaData to say
that it doesn't need the type before you can get the value.
Then you could invoke getValue(TypeInfo, ClassLoader)
(with null for the TypeInfo) before you determine the constructor.
But you'd still need to extend the fuzzy match processing
to not only look at the exact type but also all the interfaces
of the value returned.
Even then you could still get an ambiguity, e.g. in the example on the JIRA issue
if the injection implemented both Kernel and Controller.
This particular issue would probably be better resolved if we just
changed the BeanMetaDataDeployer to use @Inject for the controller
so you don't have to specify it in the xml.
The only reason all the different config mechanisms exist
(constructors/setters) is supposedly for backwards compatiblity
but the example from embedded shows that the ambiguous constructor
breaks that anyway. ;-) -
2. Re: JBMICROCONT-380; constructor (property) matching
wolfc Nov 6, 2008 10:43 AM (in response to alesj)Can we then have an exception if the parameter type is unspecified and there are multiple constructors to choose from?
-
3. Re: JBMICROCONT-380; constructor (property) matching
adrian.brock Nov 6, 2008 11:05 AM (in response to alesj)"wolfc" wrote:
Can we then have an exception if the parameter type is unspecified and there are multiple constructors to choose from?
I know we used to issue a WARNing, because Scott asked me to add it.
But I can't find it in the current code?
Ales, did you remove it during one of your refactorings? :-) -
4. Re: JBMICROCONT-380; constructor (property) matching
alesj Nov 6, 2008 3:17 PM (in response to alesj)"adrian@jboss.org" wrote:
Ales, did you remove it during one of your refactorings? :-)
Where was it?
In Config class?
I'll check history to find the true culprit,
as I doubt it was me. ;-)