gayle craig

If message beans don't have homes, why does p. 453 say:

"... Remember, the Container keeps a separate pool of beans for each home (and every deployed bean type gets its own home)...."

p 447 Sharpen your Pencil

Which ones does the compile care about?

1. ejbCreate()
2. onMessage()
3. ejbRemove() and setMessageDrivenContext()

I say #2 and #3?

For discussion of Head First EJB's Chapter 8.

Other Chapter discussions:
1 2 3 4 5 6 7
[ March 20, 2005: Message edited by: gayle craig ]

So how do we go about defining in the Deployment Descriptor something where Bean A has more than one relationship (i.e. Bean A has a relationship with Bean B and Bean C)? There will be more than one ejb-relationship-role definition for A I assume? And there will be more than one ejb-relation tag, also?


Let's say there's a 1 to many between A and B. And Many to Many between A and C.
A B
(1) ------ (*)

A C
(*) ------ (*)

I think it would be like this. Is this right?

<relationships> <ejb-relation> <ejb-relationship-role> <ejb-relationship-role-name>ABean</ejb-relationship-role-name> <multiplicity>Many</multiplicity> // A has many instances of B <relationship-role-source> <ejb-name>BBean</ejb-name> </relationship-role-source> <cmr-field> <cmr-field-name>bees</cmr-field-name> // ABean must have a member variable of type Collection named "bees" <cmr-field-type>java.util.Collection</cmr-field-type> </cmr-field> </ejb-relationship-role> <ejb-relationship-role> <ejb-relationship-role-name>BBean</ejb-relationship-role-name> <multiplicity>One</multiplicity> // B has only 1 instance of A <relationship-role-source> <ejb-name>ABean</ejb-name> </relationship-role-source> <cmr-field> <cmr-field-name>aye</cmr-field-name> // BBean must have a member variable of type ABean named "aye" </cmr-field> </ejb-relationship-role> </ejb-relation> <ejb-relation> <ejb-relationship-role> <ejb-relationship-role-name>ABean</ejb-relationship-role-name> <multiplicity>Many</multiplicity> // A has many instances of C <relationship-role-source> <ejb-name>CBean</ejb-name> </relationship-role-source> <cmr-field> <cmr-field-name>cees</cmr-field-name> <cmr-field-type>java.util.Set</cmr-field-type> // ABean must have a member variable of type Set named "cees" </cmr-field> </ejb-relationship-role> <ejb-relationship-role> <ejb-relationship-role-name>CBean</ejb-relationship-role-name> <multiplicity>Many</multiplicity> // C has many instances of A <relationship-role-source> <ejb-name>ABean</ejb-name> </relationship-role-source> <cmr-field> <cmr-field-name>ayes</cmr-field-name> <cmr-field-type>java.util.Collection</cmr-field-type> // CBean must have a member variable of type Collection named "ayes" </cmr-field> </ejb-relationship-role> </ejb-relation> </relationships>
[ March 20, 2005: Message edited by: gayle craig ]

p 407 Sharpen your pencil

[LEGAL] SELECT OBJECT (m) FROM MovieSchema m

[LEGAL] SELECT m.title FROM MovieSchema m

[NOT LEGAL] SELECT m FROM MovieSchema m

[NOT LEGAL] SELECT OBJECT (m.title) FROM MovieSchema m


Is that right?

P 397

"The two select methods ... doesn't say WHAT the methods will return... but we'll tell the container that one will return a Collection of Movies and one a Collection of Strings."

Where/how do we tell the container that? Does the container just know based on the EJB-QL that we write? Or from something else?

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()

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.

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.

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.

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.

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

Sharpen your Pencil, p239

This one was kinda hard. I'm still not sure on a couple of them, and by no means sure these are right.

BEAN PROVIDER
---------------
implementing the EJBObject class
creating the home interface
implementing SessionBean
implementing ejbCreate() method
implementing ejbActivate() method
implementing ejbPassivate() method

CLIENT
---------------
invoking create()
invoking a business method on the component interface

CONTAINER
---------------
invoking setSessionContext()
invoking ejbCreate()
invoking ejbRemove()
implementing the create() method


UNSURE OF:
---------------
implementing the SessionContext class -- I know the Bean has the ability to USE the SessionContext class, but I don't think it Implements it per-se. I'd guess the container does this, then, mostly because I don't recall the book really talking about *implementing* this class yet.

implementing the Handle class -- same thoughts as for implementing the SessionContext class.

creating the Home object class

I still don't exactly understand why the ejbCreate() methods must have a return type of void, unlike the corresponding create() methods in the Home interface. How does this work if ejbCreate() doesn't return anything. Must be container magic I guess.


Answer: ejbCreate() is called by the container to tell the bean it has been created and make it a full-fledged bean. The constructor has already been called, so this is more like an event than an actual "create".
[ February 23, 2005: Message edited by: gayle craig ]

p230 Sharpen your Pencil

Compiler Checked?

NO - methods to match the Home interface
NO - Methods to match the Component interface
YES - Methods to match the SessionBean interface.