Yep, as I wrote in an earlier post, that was what I chose to do.
Randahl
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of wim veninga
Sent: 22. februar 2001 15:38
To: Orion-Interest
Subject: Re: No influence on CMP 2.0 getter setter methods - a feature
or a bug?
Hi Randahl,
Why don't you just leave the method setBalance(float b)
out of the remote interface and put
public void setBalanceAndDoWhatHasToBeDoneWhenYouSetBalance(Float balance)
in the remote interface. So no other objects can call setBalance but only
setBalanceAndDoWhatHasToBeDoneWhenYouSetBalance(Float balance).
Greetings Wim Veninga.
----- Original Message -----
From: "Randahl Fink Isaksen" <[EMAIL PROTECTED]>
To: "Orion-Interest" <[EMAIL PROTECTED]>
Cc: "Jens Peter Grosen" <[EMAIL PROTECTED]>; "Simon Anker Christiansen"
<[EMAIL PROTECTED]>; "Kim Jørgensen" <[EMAIL PROTECTED]>
Sent: Wednesday, February 21, 2001 5:46 PM
Subject: No influence on CMP 2.0 getter setter methods - a feature or a bug?
> I have been reading the CMP 2.0 specification and I think it is simply
> great! Still, I am a bit surprised that the bean developer has no control
> over what happens when a field is set. Imagine an AccountBean, for
instance:
>
> public abstract class AccountBean extends EntityBean {
> //implemented by the persistence manager
> public abstract Float getBalance();
> //implemented by the persistence manager
> public abstract void setBalance(Float balance);
> }
>
> What if I wanted to do something useful when the balance was set? Say, I
> wanted to add the account to a list of surveilled accounts if a negative
> balance was set... it seems I cannot do that because the container
> implements the setBalance() method for me. And I cannot just declare a
> setBalance() method myself because I need the container's implementation
or
> I will not be able to store the balance. Hmmmm... it seems this is going
to
> leave me with something like
>
> public abstract class AccountBean extends EntityBean {
> public abstract Float getBalance();
> public abstract void setBalance(Float balance);
>
> public void setBalanceAndDoWhatHasToBeDoneWhenYouSetBalance(Float balance)
> {
> //check if balance is negative and take action
> ...
> setBalance(balance);
> }
> }
>
> Now I have _no_ guarantee that nobody will accidently call the original
> setBalance() method, thereby circumventing my little security system,
which
> was supposed to check for a negative balance. But, hey, I thought, then I
> will just declare the original setBalance() as protected - unfortunately
> that is not allowed by the specification.
>
> I would r e a l l y like to hear from anybody who knows a solution to
this.
> Any comments would be most welcomed.
>
> Randahl
>
>
