Richard, We found that being able to specify meaningful default values for primitive members and default, non-mutable values for object members helps simplify the business logic that a bean implements. That is the reason we allow explicit default constructors and initializers for members. To avoid confusion, however, an EJB server should either disallow non-java defaults for bean members or provide warnings when such usage is detected. Imre Kifor Valto Systems -----Original Message----- From: Richard Monson-Haefel <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Date: Wednesday, March 17, 1999 11:46 AM Subject: Inital values of activated beans: (was RE: ejbCreate( ) - initial ize instance variables >The initial values set for fields in an Entity bean by the container with >regard to activation, should be the default values of the instance: null for >objects, zero for number primitives, and false for boolean. > >The specification is clear that bean developer should not define a >constructor in the bean. I think this implies that bean developers should >not initialize values in field declarations also, since this is activity is >done during instantiation. > >Any initialization of values by the bean developer should be done in >ejbCreate and ejbActivate methods. > > >Richard > > >-----Original Message----- >From: Imre Kifor >To: [EMAIL PROTECTED] >Sent: 3/17/99 8:25 AM >Subject: Re: ejbCreate( ) - initialize instance variables > >The spec states that all bean instances must be created using >newInstance() >on the bean's class. This means that there will be only one valid >initial >state per bean class in a running server (and is created through the >bean's >default public constructor). > >We keep one such "template" instance around for all deployed bean >classes >and before the server releases an instance back to the pool, we "wipe" >the >instance's state clean with the template using reflection. No >serialization >is required in the process and, since we operate on the Java 2 platform, >we >can reset private members as well. > >Imre Kifor >Valto Systems > >-----Original Message----- >From: Constantine Plotnikov <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] <[EMAIL PROTECTED]> >Date: Wednesday, March 17, 1999 8:50 AM >Subject: Re: ejbCreate( ) - initialize instance variables > > >>Hi! >> >>1. Do I understand it correctly? In your server, initial values for >all >> fields are saved for each instance and they are restored right >before >> creation. >> >>2. If yes, how do you save values? >> a) in serialized form >> b) just pointers to values recived as Field.get() >> c) other, please clarify what. >> >>3. If no, could you please clarify semantics of restoring values >> in your server. >> >>Constantine >> >>Imre Kifor wrote: >>> >>> We believe that bean instances retrieved from the instance pool >should >>> always be in their initial state (i.e. the state right after >construction) >>> regardless of the used persistence management type. >>> >>> This means that with Ejipt your 'country' member will be predictably >set >to >>> "USA" upon entering ejbCreate, ejbFindXXX and ejbActivate. Moreover, >since >>> Ejipt resets all instances before returning them to the pool, you >will >also >>> be assured that your possibly sensitive or very large member data is >not >>> held by pooled instances. >>> >>> Imre Kifor >>> Valto Systems >>> >>> -----Original Message----- >>> From: Sachin Aggarwal <[EMAIL PROTECTED]> >>> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]> >>> Date: Tuesday, March 16, 1999 11:26 PM >>> Subject: ejbCreate( ) - initialize instance variables >>> >>> >The spec mentions that ejbCreate( ) initializes instance variables. >>> > >>> >Question 1. Who's reponsibility is that in CMP beans ? The >containers or >>> the >>> >bean developers? >>> > >>> >If the answer to above is Bean Developer, then: >>> >Q2. If the instance variable is declared as public String county = >"USA"; >>> >and the bean developer does not reinitialize it in ejbCreate(), then >does >>> >the container have the right to initialize it to unpredicatable >values ? >>> > >>> >Thanks for your help. >>> > >>> >>======================================================================= >==== >>> >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". >>> > >>> > >>> >>> >======================================================================== >=== >>> 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". >> >>======================================================================= >==== >>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". >> > >======================================================================== >=== >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". > >=========================================================================== >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". > =========================================================================== 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".
