Chapter 6 - HF study group

[Marc Peabody]

For discussion of Head First EJB's Chapter 6.

Other Chapter discussions:
1 2 3 4 5 6

[Leena Diwan]

Page 316 code example:
1. why is it ok to use 'this' in 'return this.getLast()'?
What I had kept in mind is not to use-
'return this' and <method>(this) in the code. Is it ok here as we are calling a method on 'this' so that the actual value returned will be different?
In practical world, would you avoid using 'this' altogether for consistency/uniformity reasons or use it and expect the next programmer to know where to use it and where to not?

2. Im a little confused about the name of the getters and setters in the code - The abstract setters should be like the columns in the database. So if I have a 'Name' column, getName() and setName() should be abstract.
And the method exposed through the component interface should be of different name. May be like - getTheName() and setTheName() - right?
My next question stemming from that - does it remain as intuitive as it should be or does the developer need to juggle to choose some method name? like- trying out getCustName, getTheName, getMyName! and then documenting which one he chose for which one!

Page 318 code example:
ejbPostCreate() is missing from the code.

Regards,
Leena

[Leena Diwan]

Sharpen your pencil page 319
1.

H
ejbCreate()
ejbPostCreate()

C
getLastName()
setLastName()
getFirstName()
setFirstName()
getAddress()
setAddress()

EB
setEntityContext()
unsetEntityContext()
ejbLoad()
ejbStore()
ejbActivate()
ejbPassivate()
ejbRemove()

VF
getLast()
setLast()
getFirst()
setFirst()
getCustAddress()
setCustAddress()
getPK()
setPK()

I have not marked anything for the makePK() method.

2. The compiler cares about -
setEntityContext()
unsetEntityContext()
ejbLoad()
ejbStore()
ejbActivate()
ejbPassivate()
ejbRemove()

Regards,
Leena

[gayle craig]

RE: Code sample on page 318

Ok good, I thought the code on page 318 was missing ejbPostCreate() also, but didn't see it in the Confirmed Errata

I thought the code on 318 should also have an ejbHomeUpdateAll() too, based on the home business method you see on p 314? Is that wrong?

Gayle

[gayle craig]

I agree with your answers for the p 319 Sharpen your Pencil.

I initially put an H beside makePK() because I thought it was a home business method. But its not, its just a helper method. I would say none of the symbols (H, C, EB, VF) fit for that, it has to be there just b/c the bean developer is responsible for assigning a primary key, and they've made this helper method to accomplish that.

[Leena Diwan]

Originally posted by gayle craig:
I thought the code on 318 should also have an ejbHomeUpdateAll() too, based on the home business method you see on p 314? Is that wrong?

Yes I agree. It should be there.

[gayle craig]

p 335 Brain Power

These are my best guesses. If anyone has a better explanation, please respond.

-----------------------------------------------------------
1. ... explain why each of the three different return types is what it is...

-----> public Customer create (Sting last, String first) throws CreateException, RemoteException;

This returns a Customer object because this is the method the client calls and the client will need a handle to a Customer object, so the container must provide that to return from this method.

-----> public String ejbCreate (String last, String first) {...}

Returning the Customer object is not necessary here. So only returning the Primary Key which was generated is necessary. However, I don't understand why the PK we return will always be null (p 333).

-----> public void ejbPostCreate (String last, String first) {...}

Return void because everything is done at this point, there's really nothing to return.


-----------------------------------------------------------
2. Why do both ejbCreate<method> and ejbPostCreate<method> have the same arguments?

Maybe they have the same arguments in case verification is required? Otherwise, it seems like its unnecessary because you should have this information as member data.

[Leena Diwan]

Sharpen your pencil: page 323

1. ejbPassivate or remove?[I had written ejbPassivate() earlier but now Im not sure because the description is - 'the client calls this method']
2. ejbRemove
3. setEntityContext
4. ejbActivate

Regards,
Leena

[Leena Diwan]

Originally posted by gayle craig:
p 335 Brain Power
Returning the Customer object is not necessary here. So only returning the Primary Key which was generated is necessary. However, I don't understand why the PK we return will always be null (p 333).

If we keep in mind what calls a method it is easier and sensible. The container calls ejbCreate(). And it is mainly used to 'make/form' the primary key. But what is the use of returning it to the Container?

The client expects the EJBObject so we return it from the create() method.
The ejbCreate must form the PK. but returning it to the container is meaning less. No use to it.

Originally posted by gayle craig:
p 335 Brain Power
2. Why do both ejbCreate<method> and ejbPostCreate<method> have the same arguments?
Maybe they have the same arguments in case verification is required? Otherwise, it seems like its unnecessary because you should have this information as member data.

Creatin is not done till ejbPostCreate ends. And it is the 'next' method that gets called in the chain or creation process. So the data might still be needed. Because we need to provide the implementation of it [i.e. use it to initialise the CMR fields] we, as developers need to do it.

Regards,
Leena

[gayle craig]

p 361 Exercise

Entity Bean
------------
ejbSetEntityContext(EntityContext ec)
ejbPassivate()
ejbLoad()
ejbStore()


Product Bean
--------------
ejbCreate (String, String, String)
ejbHomeGetLowInventory(int)
ejbSetEntityContext (EntityContext)
ejbUnsetEntityContext ()
ejbActivate()
ejbPassivate()
ejbRemove()
(make both a public abstract version and public version of these next three... does this work?)
public abstract String getProductDescription()
public abstract int getQuantity()
public abstract float getPrice()
public String getProdDesc()
public int getQty()
public float getPrc()
(and make set methods for all these get methods, with return type void)


Do not put in your abstract Bean class:
- finder methods
- ejbLoad/ejbStore

What did I miss? I feel like this is not quite right.

[Leena Diwan]

Page 171 of the spec.
The implementation of the Bean Provider�s ejbCreate<
METHOD>(...) methods should be coded to return a null.[14]

[14]The above requirement is to allow the creation of an entity bean with bean-managed persistence by subclassing an entity bean
with container-managed persistence.[This is a small note on the page]

Regards,
Leena

[Leena Diwan]

Originally posted by gayle craig:
p 361 Exercise
ejbSetEntityContext (EntityContext)
ejbUnsetEntityContext ()

Should be setEntityContext() and unsetEntityContext(). Typo error I guess.

Regards,
Leena
[ March 07, 2005: Message edited by: Leena Diwan ]

[Leena Diwan]

Gayle-- ( make both a public abstract version and public version of these next three... does this work?)

Read carefully. The method names are different. Otherwise the class will not compile. One of my post at the top of the page have a question about it about its choosing method names in real life situations.

Gayle -- Do not put in your abstract Bean class:
- finder methods
- ejbLoad/ejbStore

why not ejbLoad and ejbStore methods? I feel it is must. It is one of the callbacks in EntityBean interface which the bean must implement. The class is abstract because of the other methods, not these.

Regards,
Leena
[ March 08, 2005: Message edited by: Leena Diwan ]

[gayle craig]

Originally posted by Leena Diwan:


why not ejbLoad and ejbStore methods? I feel it is must. It is one of the callbacks in EntityBean interface which the bean must implement. The class is abstract because of the other methods, not these.

Regards,
Leena

Yes, I guess we do implement ejbLoad and ejbStore. I thought I read that the container implements these too, like the finder methods. But I can't find it now.

[gayle craig]

Originally posted by Leena Diwan:


Read carefully. The method names are different. Otherwise the class will not compile. One of my post at the top of the page have a question about it about its choosing method names in real life situations.

Yes, my method names are different. GetProductDescription vs/ getProdDesc. Is that still wrong though?

public abstract String getProductDescription()
public abstract int getQuantity()
public abstract float getPrice()
public String getProdDesc()
public int getQty()
public float getPrc()

[Leena Diwan]

This is right. Sorry about that. I didn't read the top 3 last time.

As per my understanding -

1. The abstract accessor method names must be the get/set methods of the fields in the table structure.
2. The other get/set methods are really the methods due to the component interface. So there we need to choose a diff name for a method.

Regards,
Leena

[damian croft]

Re: the second post in this thread:

2. Im a little confused about the name of the getters and setters in the code - The abstract setters should be like the columns in the database. So if I have a 'Name' column, getName() and setName() should be abstract.
And the method exposed through the component interface should be of different name. May be like - getTheName() and setTheName() - right?

Yes, I'm really confused about this too. Can anyone explain it to me?

Does the method name in the virtual persistent field absolutely HAVE TO derive from the database column name? (On page 316 of HF it gives the abstract method setCustAddress(String Address) - but on page 315, in the diagram of the database it gives the column name as simply "Address") How does this work?

Thanks,
damian

[damian croft]

to answer my own question......

No, they map to the fields in the ejb-jar. Right?