You are right but if that is what you want then remove as told by Raghuram
also (I think he wanted to send the mail to ejb list)
<primkey-field>accNumber</primkey-field>
this . When you give the user defined primary key class then App server
does introspection automatically.
You need to carefully override the hascode() and equals method then.
Manoj Kumar
<[EMAIL PROTECTED] To: [EMAIL PROTECTED]
OM> cc:
Sent by: A Subject: Re: Problem with Return type
of Abstarct get/set methods in
mailing list for CMP Entity Beans
Enterprise
JavaBeans
development
<EJB-INTEREST@JAV
A.SUN.COM>
12/24/2002 03:26
PM
Please respond to
m.kumar
Hi,
But i think as per the design patterns , one should always use the
Primary key class so that if at a later point of time your primary key
changes to a
composite primary key then the impact on the code will be minimum. Though
the possibility of change in primary key is very little. I donot think that
having the
own primary key introduces any overhead in performance other than the bit
of extra coding which the developer has to do,
Please make me correct if i am wrong in my understanding...
Thanks
Manoj
Ashwani Kalra wrote:
> Hi,
> Hicks you are right. He doesnt need compound key.
>
>
<prim-key-class>personal.ejb.learning.cmpbean.AccountCMPPK</prim-key-class>
>
> change to
>
> <prim-key-class>java.lang.Integer</prim-key-class>
>
> will suffice I think
>
> Do not use personal.ejb.learning.cmpbean.AccountCMPPK class as primary
> key.
>
> Cheers
> ______________________________________________
> Ashwani Kalra
> HomePage : http://www.geocities.com/ashwani_kalra/
> ________________________________________________
>
> "Hicks, James"
> <James.Hicks@LMBE To:
[EMAIL PROTECTED]
> RRY.COM> cc: (bcc:
ashwani.kalra/Polaris)
> Sent by: A Subject: Re: Problem
with Return type of Abstarct get/set methods in
> mailing list for CMP E ntity
Beans
> Enterprise
> JavaBeans
> development
> <EJB-INTEREST@JAV
> A.SUN.COM>
>
> 12/23/2002 11:56
> PM
> Please respond to
> "Hicks, James"
>
> The problem now is that the account number field is a custom type. Your
> database and application server know nothing about it, so it stores it in
> binary format in your database.
>
> Why are you using a custom PK class? I see that you only have a single
> field in the class, why not make your account number field an int or long
> and use either a java.lang.Integer or java.lang.Long as the primary key
> class. This would solve your problem easily.
>
> If on the other hand you want to use a custom PK class, change the
account
> number field back to a int and make the changes that I gave you in the
> first email. Your app server should be match the fields in the pk class
to
> the fields in the bean class.
>
> I have seen very few instances where a custom PK class was actually
needed.
> They usually come into play when integrating with existing database
> designs.
>
> James Hicks
> -----Original Message-----
> From: Manoj Kumar [mailto:[EMAIL PROTECTED]]
> Sent: Monday, December 23, 2002 11:30 AM
> To: Hicks, James
> Cc: [EMAIL PROTECTED]
> Subject: Re: Problem with Return type of Abstarct get/set methods in
> CMP Entity Beans
>
> One more factor which i noticed after changing the return type 'int'
> to the primary key class 'AccontPK' is that i could deploy my CMP
bean
> however while calling the create method on the bean i was getting
data
> type inconsistency. My underlying table was having the following
> structure
>
> SQL> desc account
> Name Null? Type
> ------------------------------- -------- ----
> ACCNUMBER NUMBER(7)
> OWNERNAME VARCHAR2(30)
> BALANCE NUMBER(7)
>
> When i changed the structure of my table to
>
> SQL> desc account
> Name Null? Type
> ------------------------------- -------- ----
> ACCNUMBER RAW(1000)
> OWNERNAME VARCHAR2(30)
> BALANCE NUMBER(7)
>
> then i could run my bean successfully........
>
> I could not get what was wrong with my earlier table definition.
After
> creating the record when i checked the record in table 'account' ,
> accountnumber column was having the following value.
>
> AccountNumber Column
>
ACED000573720028706572736F6E616C2E656A622E6C6561726E696E672E636D706265616E2E4669727374434D50504BB6AD9841A6518F7B0200014900096163634E756D626572787000000066
>
> It seems that i made some mistake in the deployment descriptor...
>
> Any suggestions in this regard are welcome !!!!!!!!
>
> Thanks
> Manoj
>
> "Hicks, James" wrote:
>
> It would help to see your deployment descriptors. That is
> probably where your error is.
>
> James
>
> -----Original Message-----
> From: Manoj Kumar [mailto:[EMAIL PROTECTED]]
> Sent: Monday, December 23, 2002 10:17 AM
> To: [EMAIL PROTECTED]
> Subject: Problem with Return type of Abstarct get/set methods
in
> CMP Entity Beans
>
> Hi,
> I have created a 'Account' Entity bean having a Primary Key
class
> 'AccountPK' which has a AccountNumber field. My bean class has
> abstarct set/get methods for AccountNumber also. Signatures of
> these methods is as under
>
> public abstract int getAccNumber();
> public abstract void setAccNumber(int accnumber);
>
> When i tried deploying the Bean in weblgic 7.0, i got the
> exception saying that the return type of the abstarct methods
> getAccountNumber should be of primary key AccountPK and not the
> int. However, all the examples which i could find in tutorials
> and Books says that the return type should be the data type of
> the field which in this case is int.
>
> Thanks in advance!
>
> Manoj Kumar.
>
>
===========================================================================
>
> To unsubscribe, send email to [EMAIL PROTECTED] and include
> in the body of the message "signoff EJB-INTEREST". For general
> help, send email to [EMAIL PROTECTED] and include in the
body
> of the message "help".
>
> The information transmitted is intended only for the person or
> entity to which it is addressed and may contain confidential,
> proprietary, and/or privileged material. Any review,
> retransmission, dissemination, or other use of, or taking of
any
> action in reliance upon this information by persons or entities
> other than the intended recipient is prohibited. If you receive
> this in error, please contact the sender and delete the
material
> from all computers.
>
> The information transmitted is intended only for the person or entity to
> which it is addressed and may contain confidential, proprietary, and/or
> privileged material. Any review, retransmission, dissemination, or other
> use of, or taking of any action in reliance upon this information by
> persons or entities other than the intended recipient is prohibited. If
you
> receive this in error, please contact the sender and delete the material
> from all computers.
>
>
------------------------------------------------------------------------
> Name: InterScan_Disclaimer.txt
> InterScan_Disclaimer.txt Type: Plain Text (text/plain)
> Encoding: 7bit
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
This e-Mail may contain proprietary and confidential information and is sent for the
intended recipient(s) only.
If by an addressing or transmission error this mail has been misdirected to you, you
are requested to delete this mail immediately.
You are also hereby notified that any use, any form of reproduction, dissemination,
copying, disclosure, modification,
distribution and/or publication of this e-mail message, contents or its attachment
other than by its intended recipient/s is strictly prohibited.
Visit Us at http://www.polaris.co.in
