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. Is this something that XDoclet can do and if so, how do l detect this attribute in an XDT?
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/>());
******************************************************************************** This electronic mail system is used for information purposes and is not intended to form any legal contract or binding agreement. The content is confidential and may be legally privileged. Access by anyone other than the addressee(s) is unauthorised and any disclosure, copying, distribution or any other action taken in reliance on it is prohibited and maybe unlawful All incoming and outgoing e-mail communications and attachments are scanned automatically by software designed to detect and remove any material containing viruses or other unauthorised content. While we undertake best endeavours to ensure that this content checking software is up to date, recipients should take steps to assure themselves that e-mails received are secure. ***************************************************************************************
