Don't worry. Yes, that pattern is nicer, and I have already approached the vendor of my third party framework to support it.
However, I have found another workaround, which will do for me at the moment.
I was curious to see what those "design-decisions" might be which are alluded to in 3.3.6 of the user manual.
So I looked up the source of method autowireBeanProperties in AbstractAutowireCapableBeanFactory in package org.springframework.beans.factory.support.
It calls populateBean, which calls autowireByName which calls unsatisfiedNonSimpleProperties, all from the same class, which finally calls BeanUtils.isSimpleProperty.
Now, it is exactly the latter call which is doing all the "damage".
So I will probably implement some doWithBeanFactory method, as you suggested, and assemble those few source lines I found above without that ominous call to isSimpleProperty.
Another workaround would be to use StringBuffer instead of String, because that is not a type which is rejected by isSimpleProperty, and it is just as easy to configure as String in those rare cases I need it.
By the way, I would like to observe that I named this thread inappropriately: it has nothing to do with constructor injection as such. It should rather be called "Autowiring of String and other simple properties".
To complete the picture: did you observe that the JavaDoc of autowireBeanProperties does not mention with a single word, that String and other simple properties are not autowired? That piece of information is only given in 3.3.6 of the manual.
I feel, that is something to be repaired. Better still, the restriction should be abandoned altogether, or some sound reason should be made public.
I guess you have access to an active committer to that package and can draw his attention to this issue. :rolleyes:
Thanks a lot for your help.