Well, I feel that iBATIS needs 'special' access to the classes. I have a very good case. We store the last modification date for many objects. So, I wanted to update the field 'lastUpdateTime' in all setters. But this does not work if iBATIS populates the object using the same 'setters' than other users. I feel this relates to the 'anemic model' anti-pattern. One simple solution is just to have dedicated setters (e.g. prefixed by 'ibatis') They could be declared by adding a 'setter-method' directive in the result map (or using annotations) I have just started using iBATIS and appreciate a lot its simplicity, but I am really uncomfortable weakening that much my object model. J-F
-----Message d'origine----- De : Clinton Begin [mailto:[EMAIL PROTECTED] Envoyé : vendredi 27 juillet 2007 21:22 À : [email protected] Objet : Re: Extending IBATIs No...and going forward, we'll support JavaBeans only in that get/set methods are properties. The JavaBeans spec and related APIs including BeanInfo are horrible and have created far more problems for us and others than they have solved. In the future we'll support classes as classes, not classes as JavaBeans. That said, sorry for ProbeFactory being static, there's no excuse for that. Clinton On 7/27/07, Daniel Pitts < [EMAIL PROTECTED]> wrote: Does iBATIS use Introspector and BeanInfo? If it does (and it should!), then you can create a custom BeanInfo class that defines the getter/setter methods for particular properties. _____ From: Clinton Begin [mailto: [EMAIL PROTECTED] Sent: Friday, July 27, 2007 8:57 AM To: [email protected] Subject: Re: Extending IBATIs Can you live with simply letting it map directly to the fields? Clinton On 7/26/07, Jean-François Daune < <mailto:[EMAIL PROTECTED]> [EMAIL PROTECTED] > wrote: Hi, I would like to customize iBATIS by replacing use of Javabeans setter as default with custom setter (with a prefix). Is it possible? I do not see any extension point for this in iBATIS. ProbeFactory is impossible to extend. Cheers, J-F
