RE: No influence on CMP 2.0 getter setter methods - a feature or abug?
At 14:54 22.02.2001 , you wrote: >My two cents ... > >Putting checks in the EJB's will give you much better information on >exactly what has gone wrong. Adding checks in the DB as well can't hurt, >but without the EJB checks it might be hard to know what action to take in >the face of a generic SQL error. > >Nick Newman very true. that's why I would regard DB constraints only as an additional security measure to protect your data model integrity. depending on your jdbc driver the SQLException's error message can give you some information during development. however, if your client code has to react to the fact that a unique constraint on a non-pk key has been violated you have no choice but to put that check into the EJB tier and I would also generally regard that as better style. regards, robert (-) Robert Krüger (-) SIGNAL 7 Gesellschaft für Informationstechnologie mbH (-) Brüder-Knauß-Str. 79 - 64285 Darmstadt, (-) Tel: 06151 665401, Fax: 06151 665373 (-) [EMAIL PROTECTED], www.signal7.de
RE: No influence on CMP 2.0 getter setter methods - a feature or abug?
My two cents ... Putting checks in the EJB's will give you much better information on exactly what has gone wrong. Adding checks in the DB as well can't hurt, but without the EJB checks it might be hard to know what action to take in the face of a generic SQL error. Nick Newman At 01:11 PM 2/22/01 -0500, you wrote: >The search engine is back up. Here is the start of the >thread on database constraints vs. ejb constraints: > ><http://archives.java.sun.com/cgi-bin/wa?A2=ind0007&L=ejb-interest&P=R49824 >>http://archives.java.sun.com/cgi-bin/wa?A2=ind0007&L=ejb-interest&P=R49824 > >There seems to be some smart-ass named "Robert Krueger" >who thinks he knows all the answers :) :) :) > >Thanks Robert! > >-tim > > > -Original Message- > > From: Robert Krueger > [<mailto:[EMAIL PROTECTED]>mailto:[EMAIL PROTECTED]] > > Sent: Thursday, February 22, 2001 4:42 AM > > To: Orion-Interest > > Subject: RE: No influence on CMP 2.0 getter setter methods - a feature > > or abug? > > > > > > At 19:16 21.02.2001 , you wrote: > > > > hi, > > > > check EJB-INTEREST archives for discussions on this. I think > > most pros and > > cons (including my view on things ;-) were in a discussion a > > few months ago. > > > > at the moment the server hosting the search seems to be down, > > so I cannot > > give you the exact thread. > > > > regards, > > > > robert > > > > > > >This makes we want to ask a question that has nagged me for > > >a while. Where do you put data constraints? In the database? > > >or in the entity bean? > > > > > >For example, let's say we have a field called "absoluteTemp" > > >in Kelvin. We all know this value can never be negative (in > > >my universe anyway). This isn't a business rule, it a law > > >of nature. Do you implement it as a database constraint which > > >will throw a SQLException if violated, or do you check for > > >in some facade-setter of the entity and throw some other > > >Exception if violated? What are the pros and cons of either? > > > > > >-tim > > > > (-) Robert Krüger > > (-) SIGNAL 7 Gesellschaft für Informationstechnologie mbH > > (-) Brüder-Knauß-Str. 79 - 64285 Darmstadt, > > (-) Tel: 06151 665401, Fax: 06151 665373 > > (-) [EMAIL PROTECTED], www.signal7.de > > > >
RE: No influence on CMP 2.0 getter setter methods - a feature or abug?
> >There seems to be some smart-ass named "Robert Krueger" >who thinks he knows all the answers :) :) :) I've heard of him. he must be a real pain in the ass ;). cheers, robert >Thanks Robert! > >-tim (-) Robert Krüger (-) SIGNAL 7 Gesellschaft für Informationstechnologie mbH (-) Brüder-Knauß-Str. 79 - 64285 Darmstadt, (-) Tel: 06151 665401, Fax: 06151 665373 (-) [EMAIL PROTECTED], www.signal7.de
RE: No influence on CMP 2.0 getter setter methods - a feature or abug?
Title: RE: No influence on CMP 2.0 getter setter methods - a feature or abug? The search engine is back up. Here is the start of the thread on database constraints vs. ejb constraints: http://archives.java.sun.com/cgi-bin/wa?A2=ind0007&L=ejb-interest&P=R49824 There seems to be some smart-ass named "Robert Krueger" who thinks he knows all the answers :) :) :) Thanks Robert! -tim > -Original Message- > From: Robert Krueger [mailto:[EMAIL PROTECTED]] > Sent: Thursday, February 22, 2001 4:42 AM > To: Orion-Interest > Subject: RE: No influence on CMP 2.0 getter setter methods - a feature > or abug? > > > At 19:16 21.02.2001 , you wrote: > > hi, > > check EJB-INTEREST archives for discussions on this. I think > most pros and > cons (including my view on things ;-) were in a discussion a > few months ago. > > at the moment the server hosting the search seems to be down, > so I cannot > give you the exact thread. > > regards, > > robert > > > >This makes we want to ask a question that has nagged me for > >a while. Where do you put data constraints? In the database? > >or in the entity bean? > > > >For example, let's say we have a field called "absoluteTemp" > >in Kelvin. We all know this value can never be negative (in > >my universe anyway). This isn't a business rule, it a law > >of nature. Do you implement it as a database constraint which > >will throw a SQLException if violated, or do you check for > >in some facade-setter of the entity and throw some other > >Exception if violated? What are the pros and cons of either? > > > >-tim > > (-) Robert Krüger > (-) SIGNAL 7 Gesellschaft für Informationstechnologie mbH > (-) Brüder-Knauß-Str. 79 - 64285 Darmstadt, > (-) Tel: 06151 665401, Fax: 06151 665373 > (-) [EMAIL PROTECTED], www.signal7.de > >
RE: No influence on CMP 2.0 getter setter methods - a feature or abug?
Thanks for all the feedback, everyone.
Using a session bean to hold the business logic seems like a good solution,
even though (as Jeff writes) in some cases it might be putting quite an
effort into a small problem. To me, efficient system development is also
about keeping the simple things simple.
An extremely simple solution to the whole issue would be to have the
specification require the container to call a notification method when
setting a property if such a method exists. E.g.
public abstract void setBalance(Float balance);
public void onAfterSetBalance(Float balance) {
//if balance is negative put this account onto a certain list of accounts
}
I think such an approach would save quite some development time, and in some
cases I would prefer this from adding an extra class to handle the business
logic.
I noticed in the specification that so-called "method interceptors" was one
of the comming features of EJB - I wonder if that would be something like
this. Does anyone know?
Randahl
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Schnitzer
Sent: 21. februar 2001 23:25
To: Orion-Interest
Cc: Jens Peter Grosen; Simon Anker Christiansen; Kim Jørgensen
Subject: RE: No influence on CMP 2.0 getter setter methods - a feature
or abug?
I frequently hear this mantra repeated, and while it is largely a good
idea, I have difficulty seeing why it should be adhered to dogmatically.
There is value in being able to define side-effects of setters and
getters or minimal bean-specific business logic. As a trivial example I
offer my Member entity which publishes getLastLoginDate(),
getLoginCount(), and a loggedIn() method which updates the previous two
fields. Creating a session bean for this purpose is just a waste of
effort and processing time.
An example of a simple (and valuable) side-effect is a print statement
to trace bean access while debugging.
As someone already mentioned in response to poster's original question:
You can do what you described safely because clients only see the remote
interface view of the bean, not the implementation object view. If you
chose to call the persistence field "internalBalance" and avoided
putting the setter/getter in the remote interface, you could then be
sure that everyone will call the get/setBalance method you implement.
But realize that sophisticated business logic does belong in session
beans. My main guideline is "does this affect more than the single
entity?" If so, then definitely it should be a session bean.
Otherwise, the answer is still maybe :-)
And in any case, the client view is of session beans only. For
instance, the Member.loggedIn() method only gets called from the
ejbCreate of my MemberSession stateful SB facade.
Jeff
>-Original Message-
>From: Brian Wing Shun Chan [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, February 22, 2001 12:30 PM
>To: Orion-Interest
>Cc: Jens Peter Grosen; Simon Anker Christiansen; Kim Jørgensen
>Subject: Re: No influence on CMP 2.0 getter setter methods - a feature
>or abug?
>
>
>You don't want to put logic in Entity beans. Entity beans should only
>serve as models for the database.
>
>Put the logic in the Session beans that will call setBalance
>and any other
>methods you have. You can make all those methods one atomic
>transaction by
>declaring it in the descriptor as well.
>
>- Brian Chan
>
>On Wed, 21 Feb 2001, Randahl Fink Isaksen wrote:
>
>> 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. H... 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)
>>
RE: No influence on CMP 2.0 getter setter methods - a feature or abug?
Title: RE: No influence on CMP 2.0 getter setter methods - a feature or abug?
This makes we want to ask a question that has nagged me for
a while. Where do you put data constraints? In the database?
or in the entity bean?
For example, let's say we have a field called "absoluteTemp"
in Kelvin. We all know this value can never be negative (in
my universe anyway). This isn't a business rule, it a law
of nature. Do you implement it as a database constraint which
will throw a SQLException if violated, or do you check for
in some facade-setter of the entity and throw some other
Exception if violated? What are the pros and cons of either?
-tim
> -Original Message-
> From: Jeff Schnitzer [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, February 21, 2001 5:25 PM
> To: Orion-Interest
> Cc: Jens Peter Grosen; Simon Anker Christiansen; Kim Jørgensen
> Subject: RE: No influence on CMP 2.0 getter setter methods - a feature
> or abug?
>
>
> I frequently hear this mantra repeated, and while it is largely a good
> idea, I have difficulty seeing why it should be adhered to
> dogmatically.
>
> There is value in being able to define side-effects of setters and
> getters or minimal bean-specific business logic. As a
> trivial example I
> offer my Member entity which publishes getLastLoginDate(),
> getLoginCount(), and a loggedIn() method which updates the
> previous two
> fields. Creating a session bean for this purpose is just a waste of
> effort and processing time.
>
> An example of a simple (and valuable) side-effect is a print statement
> to trace bean access while debugging.
>
> As someone already mentioned in response to poster's original
> question:
> You can do what you described safely because clients only see
> the remote
> interface view of the bean, not the implementation object
> view. If you
> chose to call the persistence field "internalBalance" and avoided
> putting the setter/getter in the remote interface, you could then be
> sure that everyone will call the get/setBalance method you implement.
>
> But realize that sophisticated business logic does belong in session
> beans. My main guideline is "does this affect more than the single
> entity?" If so, then definitely it should be a session bean.
> Otherwise, the answer is still maybe :-)
>
> And in any case, the client view is of session beans only. For
> instance, the Member.loggedIn() method only gets called from the
> ejbCreate of my MemberSession stateful SB facade.
>
> Jeff
>
>
> >-Original Message-
> >From: Brian Wing Shun Chan [mailto:[EMAIL PROTECTED]]
> >Sent: Thursday, February 22, 2001 12:30 PM
> >To: Orion-Interest
> >Cc: Jens Peter Grosen; Simon Anker Christiansen; Kim Jørgensen
> >Subject: Re: No influence on CMP 2.0 getter setter methods -
> a feature
> >or abug?
> >
> >
> >You don't want to put logic in Entity beans. Entity beans should only
> >serve as models for the database.
> >
> >Put the logic in the Session beans that will call setBalance
> >and any other
> >methods you have. You can make all those methods one atomic
> >transaction by
> >declaring it in the descriptor as well.
> >
> >- Brian Chan
> >
> >On Wed, 21 Feb 2001, Randahl Fink Isaksen wrote:
> >
> >> 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. H... it seems
> >this is going to
> >> leave me with something like
> >>
> >> public abstract class AccountBean extends EntityBean {
> >> public abstract Float getBalance();
> >> public abstr
RE: No influence on CMP 2.0 getter setter methods - a feature or abug?
At 19:16 21.02.2001 , you wrote: hi, check EJB-INTEREST archives for discussions on this. I think most pros and cons (including my view on things ;-) were in a discussion a few months ago. at the moment the server hosting the search seems to be down, so I cannot give you the exact thread. regards, robert >This makes we want to ask a question that has nagged me for >a while. Where do you put data constraints? In the database? >or in the entity bean? > >For example, let's say we have a field called "absoluteTemp" >in Kelvin. We all know this value can never be negative (in >my universe anyway). This isn't a business rule, it a law >of nature. Do you implement it as a database constraint which >will throw a SQLException if violated, or do you check for >in some facade-setter of the entity and throw some other >Exception if violated? What are the pros and cons of either? > >-tim (-) Robert Krüger (-) SIGNAL 7 Gesellschaft für Informationstechnologie mbH (-) Brüder-Knauß-Str. 79 - 64285 Darmstadt, (-) Tel: 06151 665401, Fax: 06151 665373 (-) [EMAIL PROTECTED], www.signal7.de
RE: No influence on CMP 2.0 getter setter methods - a feature or abug?
I frequently hear this mantra repeated, and while it is largely a good
idea, I have difficulty seeing why it should be adhered to dogmatically.
There is value in being able to define side-effects of setters and
getters or minimal bean-specific business logic. As a trivial example I
offer my Member entity which publishes getLastLoginDate(),
getLoginCount(), and a loggedIn() method which updates the previous two
fields. Creating a session bean for this purpose is just a waste of
effort and processing time.
An example of a simple (and valuable) side-effect is a print statement
to trace bean access while debugging.
As someone already mentioned in response to poster's original question:
You can do what you described safely because clients only see the remote
interface view of the bean, not the implementation object view. If you
chose to call the persistence field "internalBalance" and avoided
putting the setter/getter in the remote interface, you could then be
sure that everyone will call the get/setBalance method you implement.
But realize that sophisticated business logic does belong in session
beans. My main guideline is "does this affect more than the single
entity?" If so, then definitely it should be a session bean.
Otherwise, the answer is still maybe :-)
And in any case, the client view is of session beans only. For
instance, the Member.loggedIn() method only gets called from the
ejbCreate of my MemberSession stateful SB facade.
Jeff
>-Original Message-
>From: Brian Wing Shun Chan [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, February 22, 2001 12:30 PM
>To: Orion-Interest
>Cc: Jens Peter Grosen; Simon Anker Christiansen; Kim Jørgensen
>Subject: Re: No influence on CMP 2.0 getter setter methods - a feature
>or abug?
>
>
>You don't want to put logic in Entity beans. Entity beans should only
>serve as models for the database.
>
>Put the logic in the Session beans that will call setBalance
>and any other
>methods you have. You can make all those methods one atomic
>transaction by
>declaring it in the descriptor as well.
>
>- Brian Chan
>
>On Wed, 21 Feb 2001, Randahl Fink Isaksen wrote:
>
>> 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. H... 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
>>
>>
>
>
>
Re: No influence on CMP 2.0 getter setter methods - a feature or abug?
You don't want to put logic in Entity beans. Entity beans should only
serve as models for the database.
Put the logic in the Session beans that will call setBalance and any other
methods you have. You can make all those methods one atomic transaction by
declaring it in the descriptor as well.
- Brian Chan
On Wed, 21 Feb 2001, Randahl Fink Isaksen wrote:
> 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. H... 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
>
>
