Message: A new issue has been created in JIRA.
--------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/xdoclet/secure/ViewIssue.jspa?key=XDT-584 Here is an overview of the issue: --------------------------------------------------------------------- Key: XDT-584 Summary: guard clauses in entity bean when setting value objects Type: Improvement Status: Assigned Priority: Minor Time Spent: Unknown Remaining: Unknown Project: XDoclet Components: EJB Module Versions: 1.2 Beta 2 1.2 Beta 3 Assignee: xdoclet-devel (Use for new issues) Reporter: Jamie Burns Created: Tue, 29 Jul 2003 9:26 AM Updated: Tue, 29 Jul 2003 9:26 AM Description: I have a couple of issues to do with the code generated for setting value objects in an entity bean. For setting value objects, XDoclet generates a CMP with setter code for the value object like public abstract class SomeEntityCMP ... public void setSomeValueObject( com.company.SomeValueObject valueHolder) { try { setSomeAttribute(valueHolder.getSomeAttribute()); ... My first issue is that it does not deal with a null valueHolder. My second issue is that it does not check the valueHolder is a value object representing this instance of the entity bean. In my mind that means l can get a value object from an entity bean with one key and then set that value object on an entity bean with a different key. I would like to see these issues addressed to protect this part of the code against careless and badly behaved clients. I would like to introduce the following guard clauses into these value object setters. public abstract class SomeEntityCMP ... public void setSomeValueObject( com.company.SomeValueObject valueHolder ) { if(valueHolder == null) throw new NullValueObjectException("Cannot update SomeEntity " + (pk=" + this.getPk() + ") with a null SomeValueObject"); if(this.getPk().equals(valueHolder.getPk()) == false) throw new HolidayBookingException("Cannot update SomeEntity " + (pk=" + this.getPk() + ") with values from " + "SomeValueObject (pk=" + valueHolder.getPk()); try { setSomeAttribute( valueHolder.getSomeAttribute() ); ... I would like to get some views on the exceptions being thrown in the guard clauses. In my view it would be ideal if these were checked application exceptions. Both situations can be corrected by the client provided it is informed of the problem. However, this would mean adding a throws clause to the setter method, which l expect will break existing applications built with XDoclet. An alternative would be to throw non-checked exceptions like EJBException (which is thrown when the try...catch catches any java.lang.Exception) or some other runtime exceptions like NullPointerException or IllegalArgumentException. These would not break existing applications, but we would still be in a situation where we are not forcing good behaviour on the client. Also, these exceptions dont communicate the recoverable nature of the problem. I am aware that l could put the guard clauses into a validate method as demonstrated in the CustomerBean in the samples. I would like to steer away from this solution for a couple of reasons. Firstly, l can see myself creating alot of duplicated code. Secondly, l think if XDoclet is generating all this code it should bear the burden of guarding the method. I have one idea that might put the burden onto XDoclet and not break existing applications. l could add an optional attribute to the valueobject element of ejbdoclet. The entity-value.xdt which generates this code could then add the guard clauses and exceptions if the attribute was present. I have created some XDT for the entity-value.xdt which creates the guard clauses. if(valueHolder == null) throw new xdoclet.ejb.NullValueObjectException("Cannot update <XDtEjb:ejbName/> (pk=" + this.<XDtEjbPk:primkeyGetter/>() + ") with a null <XDtEjbValueObj:currentValueObjectClass/>"); if(this.<XDtEjbPk:primkeyGetter/>().equals(valueHolder.<XDtEjbPk:primkeyGetter/>()) == false) throw new xdoclet.ejb.WrongPkValueObjectException("Cannot update <XDtEjb:ejbName/> (pk=" + this.<XDtEjbPk:primkeyGetter/>() + ") with values from <XDtEjbValueObj:currentValueObjectClass/> (pk=" + valueHolder.<XDtEjbPk:primkeyGetter/>()); Could l get some feedback on this idea. If my proposed solution is acceptable l will add the optional attribute and upload the changes to this issue. Thanks --------------------------------------------------------------------- JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/xdoclet/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
