Answer needed or Message Driven Mock question?

[Prabhagar Dhanasekaran]

Hi Folks,

I found this question from enthuware ejb+ scbcd 5. Could you guys please answer me for this question?

Which of the given options can be inserted at //1 in the code for a message bean given below, given that it is deployed without any deployment descriptor:

(Assume appropriate package and import statements.)
@MessageDriven(mappedName = "jms/backofficeQueueDestination", activationConfig = {
@ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "Auto-acknowledge"),
@ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue")
})
public class BackofficeMessageBean implements MessageListener {

@Resource
MessageDrivenContext mctx;

public BackofficeMessageBean() {
}

public void onMessage(Message message) {
System.out.println("BackofficeMessageBean received message..."+message);

//1 Insert code here

}

}


1) System.out.println("rollback only = "+mctx.getRollbackOnly());
2) System.out.println("user transaction = "+mctx.getUserTransaction());
3) Object obj = mctx.getEJBHome();
4) TimerService ts = mctx.getTimerService();

[Christophe Verré]

What is your doubt ? What was the answer and why don't you trust it ?

[Prabhagar Dhanasekaran]

The enthuware answer is option 1.

My doubt is why not Option 4.

Please correct me if I am wrong, my understanding is stateless & message driven beans can get TimerService interface reference using their EJBContext. If that is the case why option 4 is wrong.

Thanks

[Christophe Verré]

I think you're right. getTimerService() is allowed to be called in the message listener method of an MDB.

[Michael Wiezik]

As far as I can remember from Entuware, the explanation is you cannot use TimerService inside a bean unless you explicitely inject it (or define in xml descriptor), since TimerService is treated like any other resource factory.

I took it for granted and didn't check in the spec. If anybody disagrees please post response - it would be nice to have clarification before the exam.

[Sergio Tridente]

Hi Michal,

I think Enthuware is wrong on this one. Accordinlgy to the ejb-core spec., section 5.5.1 (Operations allowed in methods of a MDB), Table 3, it is allowed to call MessageDrivenContext.getTimerService() inside the message listener method, a business method interceptor method or a timeout callback method of an MDB.

Good luck for the exam, BTW.

[Paul Anilprem]

The answer that is given is correct. While is it allowed to call getTimerService() inside the message listener method, you cannot call it unless the timer service is injected. The bean code given in the question does not do that and so the option is invalid. The problem statement also makes it clear that the bean is deployed without any deployment descriptor.

16.14.1 Bean Provider�s Responsibility
The Bean Provider is responsible for requesting injection of a TimerService object using a Resource annotation, or using the defined name to lookup the TimerService object.

[Ralph Jaus]

Hi Paul,

great that you are answering so many questions. Thanks.

In this particular case, however, I disagree with your answer for the following reasons and think that option 4 is correct:

1. core spec 16.14 says:

The container must make the Timer Service interface available either through injection using the Resource annotation or in JNDI under the name java:comp/TimerService, in addition to through the EJBContext interface.

2. How Sergio Tridente pointed out above, the core spec explicitly states that calling getTimerService on the message driven context in a message listener method is allowed.

3.

you cannot call it unless the timer service is injected

Sorry, but mctx.getTimerService() just does a jndi lookup (like dependency injection). Of what use should a method be, that delivers an object, that has to be injected right before calling the method ?

4.

16.14.1 Bean Provider�s Responsibility
The Bean Provider is responsible for requesting injection of a TimerService object using a Resource annotation, or using the defined name to lookup the TimerService object.

Exactly the same formulation (just replace "TimerService" through "UserTransaction") is used for user transactions in 16.12.1. And just above 16.12.1 the spec gives the following example:

UserTransaction utx = ctx.getUserTransaction();

According to your argumentation and 16.2.1 this code wouldn't be correct, too !

Especially regarding the arguments in 1. and 2., putting the whole argumentation on that formulation about the bean providers responsibility doesn't seem to be very convincing to me.
[ November 30, 2008: Message edited by: Ralph Jaus ]

[Paul Anilprem]

Ralph,
Your are right that getTimerService() can be called. However, neither does this bean implement javax.ejb.TimedObject interface, nor does it specify any call back method using @Timeout annotation.

So when you call timerService.createTimer(...), it throws an exception:
java.lang.IllegalStateException: EJBTimerService.createTimer can only be called from a timed object. This EJB does not implement javax.ejb.TimedObject

Regardless, TimerService timerService = context.getTimerService(); is a valid call. timerService.createTimer(...) is not a valid call for this particular bean. Hopefully, this should clear the confusion.

HTH,
Paul.
[ November 30, 2008: Message edited by: Paul Anil ]

[Niranjan Deshpande]

Guys,

So which is the correct answer? :roll:
and why are the remaining options wrong?

[Ralph Jaus]

Hi Paul,

thanks for the explanation. Now I get the point:

TimerService ts = mctx.getTimerService();

is technically a valid statement and can be called. But functionally the call doesn't make sense because in order to create a timer (the duty of a timer service object is to create timers) the bean need a timeout callback method.

Of course for a test taker it is difficult to decide which view (technical, fnctional) should be applied. But since the number of correct answers is known (at least in the exam) it should be solvable.

and why are the remaining options wrong?

2) can't be used because user transactions are only for BMT. Since no transaction type is defined the default (=CMT) applies.

3) core spec 5.4.4:

The getEJBHome and get EJBLocalHome methods are inherited from the EJBContext interface. Message-driven beans must not call these methods.