Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Chapter 4 - HF Sark study group

 
Marc Peabody
pie sneak
Sheriff
Posts: 4727
Mac Ruby VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
For discussion of Head First EJB's Chapter 4.

Other Chapter discussions:
1 2 3 4 5
[ February 18, 2005: Message edited by: Marc Peabody ]
 
gayle craig
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
p177 mentions "... bean construction (boring), bean creation (very important)..." What is the difference between bean construction and bean creation?
 
Marc Peabody
pie sneak
Sheriff
Posts: 4727
Mac Ruby VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by gayle craig:
p177 mentions "... bean construction (boring), bean creation (very important)..." What is the difference between bean construction and bean creation?


I assume it differentiates the processes object construction and becoming a bonafide bean, as explained in pages 188-189.
 
gayle craig
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
p 186 Sharpen your Pencil

1) ejbRemove()
2) ejbPassivate()
3) ejbActivate()
4) setSessionContext()? (I initially thought this was going to be ejbCreate() because #4 says "near the beginning", and also by process of elimination on the ejb***() methods. But then I realized it said in the instructions "...you have to know exaactly which methods are in the SessionBean interface" and obviously create() is in the Home, and ejbCreate is implemented in the Bean. )
 
gayle craig
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
p205 Sharpen your Pencil

... which of these will be safely passivated...

1. Socket - No
2. DataSource - Yes
3. Remote component interface - Yes
4. JNDI context - Yes
5. Connection - No
6. SessionContext - Yes
7. transient w/ null value - Yes
8. non-transient, Serializable w/ null value - Yes
9. transient w/ non-null value - No
10. non-transient, non-Serializable w/ null value - Yes
11. non-transient, non-Serializable w/ non-null value - No

I guessed on some of these, so I can't guarantee these are correct. Please let me know if you got different answers for these and why
 
Marc Peabody
pie sneak
Sheriff
Posts: 4727
Mac Ruby VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by gayle craig:
p205 Sharpen your Pencil

... which of these will be safely passivated...


I agree with those answers except for #9. I interpreted the question as: "Which values in an EJB will allow the EJB to safely passivate?" in which case #9 (transient with non-null) is true.
 
gayle craig
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hmm... I'm not sure what the difference is between "which of these will be safely passivated" and "Which values in an EJB will allow the EJB to safely passivate".

Regardless, I assumed from the book's comments on p205 that anything transient would not safely passivate. I re-read that part

"... while serialization is required to bring back transient fields with default values, passivation doesn't guarantee that!"

And now I guess my question is: How does the book define "safely"?
If "safely" means "will it passivate without error?", then #9 would be true. But if "safely" means "is it 100% guaranteed to come back when activated?", then #9 would be false.

Thoughts?
 
gayle craig
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
p220 Sharpen your Pencil:

AdviceHome - Assuming we're talking about how to change AdviceHome for the specific AdviceStatefulBean on the previou page, I think the only change is the create() method needs to take a String parameter. If it's talking about how to change an AdviceHome when a bean goes from stateless to stateful in general, it may not have to change at all if the ejbCreate() method signatures don't change.

Advice - no changes necessary?
 
gayle craig
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
gayle craig
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
 
gayle craig
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Srini Madala
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Follow up to Gayle's post regarding p230 Sharpen your pencil problem:

**********************************************************************
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.
************************************************************************

I did not get the concept about compiler check for these scenarios.

NO - methods to match the Home and component interfaces:
Is it because the methods are declared by bean provider in the home and component interface and is implemented by the container and the compiler does not have any idea at compile time?

YES - Methods to match the SessionBean interface:
Since these methods are specified in API and the compiler expects implementation in the bean class?

Can someone confirm?
 
Marc Peabody
pie sneak
Sheriff
Posts: 4727
Mac Ruby VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Srini,

That's pretty much how I understand it.

The IDE you're working in usually catches what we answered as 'NO'.
 
Chengwei Lee
Ranch Hand
Posts: 884
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Srinivas Madala:
I did not get the concept about compiler check for these scenarios.


Well, because your bean class did not implement your component & home interfaces. It merely implemented the SessionBean interface. Hence, the compiler will only check if you had implemented all the methods declared inside the SessionBean interface (not the component nor home interfaces).

Of course if you'd use your favorite IDE to generate or automate the generation, they might value-add to you by checking that the create method(s ) in home interface matches with your ejbCreate method(s) & your business method(s) signature(s) inside the component interface are the same as those in your bean class.

HTH.
 
Chengwei Lee
Ranch Hand
Posts: 884
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by gayle craig:
p220 Sharpen your Pencil:

AdviceHome - Assuming we're talking about how to change AdviceHome for the specific AdviceStatefulBean on the previou page, I think the only change is the create() method needs to take a String parameter. If it's talking about how to change an AdviceHome when a bean goes from stateless to stateful in general, it may not have to change at all if the ejbCreate() method signatures don't change.

Advice - no changes necessary?


Technically speaking, we can have an empty argument create method for the home interface of a stateful session bean. But the create method is a convenient place for us to initialize our stateful bean.

As for the component interface, changing from a stateless to stateful bean shouldn't require any change(s) to the signature(s) of its business methods. Implementation of these methods may change though.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic