1) Option 'B' seems right, "Foo create();" can be the part of local home interface instead.
2) We can't Access JMS Resource Manager Connection factories from setMessageDrivenContext, the only place we can access JMS RMCF is onMessage(), hence statement seems invalid.
3) I don't see third correct answer. Options A and C should be the only correct choices.
Corrections to above replies would be appreciated.
SCJP<br />SCBCD<br /> <br />***Brains, like hearts, go where they are appreciated***
Joined: Jul 20, 2004
Thx for ur reply, but for the 1st question, why A is incorrect? is it because of the return type or whatever? I think for the method name itself is not invalid, also, I do think write a method named create is really confused, but is it not allowed?(as the create can be one of the business method with bad name)
Whoever came up with (1) probably wanted to see if you could tell the difference between a Home interface and a Component interface - I can't cite a reason why (A) is wrong - though its suspect, you better have a good reason for returning another instance (or the same?) of the component interface of a stateless object that theoretically has exactly the same capabilities as the current one (because it lacks state). I can't think of one. I think someone simply clobbered a Home interface to see if you could tell the difference between a component interface and a home interface.
(2) Pretty much the only thing you can do in setMessageDrivenContext other than storing the context reference, is using JNDI. Any accesses to any resource managers or invocation of other beans has to wait until onMessage().
(3) In this one you would have been well within you rights to say that only (A) is valid. The other three aren't even available unless your stateful session bean implements the SessionSynchronization interface which you can only use with CMT - which the question does not explicitly mention (and it certainly does not occur by default). And as you indicated, even if you do implement SessionSynchronization, afterBegin and beforeCompletion occur within the transaction - calls to getRollbackOnly() and setRollbackOnly() are valid during those methods.