SCBCD Mock Questions - 12 - Answers

1)2
Answer 2 is correct. The message-driven bean class must define one onMessage method whose signature must follow these rules:
* The method must be declared as public.
* The method must not be declared as final or static.
* The return type must be void.
* The method must have a single argument of type javax.jms.Message.
* The throws clause must not define any application exceptions.

2)2
Answer 2 is correct.
A message-driven bean instance's life starts when the container invokes newInstance() on the message-driven bean class to create a new instance. Next, the container calls setMessageDrivenContext() followed by ejbCreate() on the instance.
The message-driven bean instance is now ready to be delivered a message sent to its Destination by any client.
When the container no longer needs the instance (which usually happens when the container wants to reduce the number of instances in the method-ready pool), the container invokes ejbRemove() on it. This ends the life of the message-driven bean instance.

3)1,3
Answers 1 and 3 are correct. A message driven bean must implement directly or indirectly implement 2 interfaces.
The MessageListener interface is used to receive asynchronously delivered messages. This interface only defines the onMessage() method.
The MessageDrivenBean is used by the container to notify the enterprise Bean instances of the instance's life cycle events. The required methods are: setMessageDrivenContext and ejbRemove.

4)1,4,5
Answers 1, 4 and 5 are correct.
Invoking getEJBHome() or getEJBLocalHome() is disallowed in message-driven bean methods because there are no EJBHome or EJBLocalHome objects for message-driven beans. The Container will throw and log the java.lang.IllegalStateException if these methods are invoked.
Invoking the getCallerPrincipal() and isCallerInRole() methods is disallowed in the message-driven bean methods because the Container does not have a client security context. The Container will throw and log the java.lang.IllegalStateException if either of these methods is invoked.
Answer 2 is incorrect, the message-driven bean can use the method getRollbackOnly() without causing any problems. However an IllegalStateException is thrown when the method is invoked while the instance is not associated with a valid transaction.
Answer 3 is incorrect, the UserTransaction interface is unavailable to message-driven beans with container-managed transaction demarcation.

5)3
Answer 3 is correct, this is the only method except from your business methods that has a meaningful transaction context.
Answer 1 is incorrect, the only operations that are allowed from within the ejbCreate() method is to lookup your JNDI environment.
Answer 2 is incorrect, your constructor is left empty in most cases, you don't have a meaningful transaction context or a message driven context. Answer 4 is incorrect, you can access a BMP or a CMP entity bean or a session bean from within your message-driven bean. Answer 5 is incorrect, the only allowed operations from the setMessageDrivenContext() is to lookup your JNDI environment.
The onMessage() method can be used to access the resource manager, access to other enterprise bean's, using the getRollBackOnly() and setRollbackOnly() methods from the MessageDrivenContext and searching your JNDI environment. Bean managed beans can use also the userTransaction context.

6) IllegalStateException is the exception that the container will throw when you use the isCallerInRole() method from the MessageDrivenContext interface.
Invoking the isCallerInRole() method is disallowed in the message-driven bean methods because the container does not have a client security context.

7)2,3
Answers 2 and 3 are correct. Answer 1 is incorrect, the class implementing the MessageDrivenBean interface cannot be final.
Answer 4 is incorrect, the message driven bean must implement the MessageDrivenBean interface and the MessageListener interface directly or indirectly.
Answer 5 is incorrect, methods defined in the message driven bean can throw a RuntimeException, they can however not throw checked exceptions. However, it is a better
practice not to throw a RuntimeException.
Learn more...
The following are the requirements for the message-driven bean class:
* The class must implement, directly or indirectly, the javax.ejb.MessageDrivenBean interface.
* The class must implement, directly or indirectly, the javax.jms.MessageListener interface.
* The class must be defined as public, must not be final, and must not be abstract.
* The class must have a public constructor that takes no arguments. The Container uses this constructor to create instances of the message-driven bean class.
* Each message-driven bean class must have one ejbCreate method, with no arguments.
* The class must not define the finalize() method.

8)1,5
Answer 1 and 5 are correct.
Bean managed message beans will acknowledge when the onMessage() method completes. Bean managed message beans has 2 choices how to acknowledge, this depends on the deployment descriptor. Container managed message beans will acknowledge depending on the status of the transaction.
Answer 2 is incorrect, the onMessage() method cannot return false, as it signature is a void. Container managed message beans acknowledge to the message service depending on the status of the transaction. Answer 3 is incorrect, message driven beans does not throw checked exceptions. Answer 4 is incorrect, only bean managed message beans will use the configuration inside the deployment descriptor for acknowledgement.

9)1
Answer 1 is correct.
The correct declaration is: public void onMessage(Message message)
This method is defined in the javax.jms.MessageListener interface, the interface need to be implemented by the message driven bean together with the MessageDrivenBean interface.
All the methods in the message driven bean class will not throw a RemoteException, a message driven bean does not a have a client view, not locally and not remotely.

10) acknowledge-mode is the correct answer.
If bean managed transaction demarcation is used, the message receipt cannot be part of the bean-managed transaction, and, in this case, the receipt is acknowledged by the container. If bean managed transaction demarcation is used, the Bean Provider can indicate in the acknowledge-mode deployment descriptor element whether JMS AUTO_ACKNOWLEDGE semantics or DUPS_OK_ACKNOWLEDGE semantics should apply. If the acknowledge-mode deployment descriptor element is not specified, JMS AUTO_ACKNOWLEDGE semantics are assumed.