Sounds like you did a ServiceOverride without actually realizing it yourself :)
And you have an excellent solution to your problem. Here is a link that explains how to not do it using a very very ugly hack :) http://tapestry.apache.org/tapestry5.1/tapestry-ioc/cookbook/override.html On Thu, Apr 22, 2010 at 2:13 PM, paha <ch_pa...@yahoo.com> wrote: > > Solved the problem with one very very nasty hack, but if somebody > interested: > > i commented the ioc binding for PropertyAccess implementation in > org.apache.tapestry5.ioc.services.TapestryIOCModule > // binder.bind(PropertyAccess.class, PropertyAccessImpl.class); > > then i introduced an own implementation in my app via > binder.bind(PropertyAccess.class, SpringPropertyAccessImpl.class); > as i said, BeanUtils from spring3 detect unvoid setters flawlessly. > > > Well, my solution is ugly. I have to keep own version of tapsetry-ioc in my > maven repo. But it is much much better than changing the code in many > projects that use setter chaining or introducing wrapper classes around the > domain objects. > > I'm quite newbie in tapestry ioc. Is there any clean way to introduce my > own > PropertyAccess implementation without hacking into source code? Is there > any > possibility of reconsidering setter detection > in future releases? > -- > View this message in context: > http://old.nabble.com/T5.1-Setters-returning-value-tp28288048p28328043.html > Sent from the Tapestry - User mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
