No need for validate-exceptions, setData is defined abstract by the user in bean impl class with all the required exceptions in its throws statement. The overridden setData will also throw those exceptions.
Another options is to allow putting ejb:dataobject in the setData method: /** * ejb:dataobject validate-method="setDataValidation" */ public abstract void setData( MyDataObject d ) throws ValidationException; But here comes an interesting question: why not make ejb:dataobject a method level tag instead of a class level tag? Let user define it right there before the getData/setData. This makes it possible to have multiple dataobjects too (or different fine-grained dataobject classes and get/sets): /** * ejb:dataobject validate-method="setDataValidation" */ public abstract void setData( MyDataObject d ) throws ValidationException; /** * ejb:dataobject */ public abstract TheOtherDataObject getTheOtherDO(); public abstract void setTheOtherDO(TheOtherDataObject d ); xdoclet will then try to guess the dataobject class name from return type of getter or argument of setter. Existing class/pattern/package are still valid (of course in method level context) but will be optional, you may only want to use them in cases where you are overriding from another bean and another get/setdata which requires you to return the dataobject type of the parent method. Note that the above scenario doesn't mean we'll break compatibility with older versions, class level ejb:dataobject will remain as is. And about "fine-grained dataobject classes", obviously you should designate which field belongs to which dataobject class. This can be done with a ejb:dataobject-field tag for the field's getter method: /** * @ejb:persistent-field ... * @ejb:dataobject-field name="DataObject1" * @ejb:dataobject-field name="DataObject2" */ public abstract int getId(); /** * ejb:dataobject name="DataObject1" */ public abstract DataObject1 getDO1(); public abstract void setDO1( DataObject1 d ); /** * ejb:dataobject name="DataObject2" */ public abstract TheOtherDataObject getTheOtherDO(); public abstract void setTheOtherDO(TheOtherDataObject d ); By default all fields are members of all dataobjects but as soon as you define one @ejb:dataobject-field you have to specify explicitly. I think now that you want to enhance it it's good to do it correctly, at least I think it's correct this way ;-) This proposal covers your feature request and also another request to support fine-grained dataobjects, but we can indeed handle it step by setp. PS: Glad to see you again Andy :o) Cheers, Ara. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:xdoclet-devel- > [EMAIL PROTECTED]] On Behalf Of Andreas Schaefer > Sent: Saturday, February 02, 2002 10:18 PM > To: [EMAIL PROTECTED] > Subject: [Xdoclet-devel] Extended Entity.setData() method > > Hi Geeks > > I would like to check the data set by the > setData() method and throw an user > exception. > Therefore the @ejb:data-object should > have the following attributes: > - validate-exceptions: list of exception thrown > by setData() (fully qualified) > - validate-method: name of the method used > to validate the data holder. It contains one > argument: the dataholder and must be specified > in the EntityBean or in one of its super-class. > Both are ignored if container or setdata is set to > false. > > Any comments ? > > xxxxxxxxxxxxxxxxx > Andreas Schaefer > Senior Consultant > JBoss Group, LLC > xxxxxxxxxxxxxxxxx > > > > _______________________________________________ > Xdoclet-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/xdoclet-devel _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
