About Question enthuware.oce-ejbd.v6.2.554 :

[jszczepankiewicz]

I would put empty line after the statement "(Assume appropriate package and import statements.) for more readability.

[admin]

This has been updated.

thanks for your feedback!

[rkbansal83]

why not first option in the question is also the correct answer ?

System.out.println("rollback only = "+mctx.getRollbackOnly());

It can also be inserted at line 1

[admin]

Option 1 is indeed the correct option. I don't see any other correct option.
-Paul.

[mopuffus]

The code

Code: Select all

@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      }      }

[mopuffus]

The following code snippet:

Code: Select all

@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      
    }      
}

will deploy even if on the line //1 use the following code

Code: Select all

TimerService ts = mctx.getTimerService();
ts.createTimer(2000, null);

Everything will end with a run-time error, but the MDB is deploy-able.

IMHO the 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:

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

[admin]

Well, you are deploying the bean for the purpose of running it eventually. The question does not ask whether the bean is deployable or not. It asks which options can be inserted in the given place. There is no deployment descriptor used while deployment is an additional piece of information given in the question.

It is like saying which of the following is valid and arguing that everything is valid unless you actually compile it because everything can be written in a java file

HTH,
Paul.

[sanju.ait@gmail.com]

Creating timer in bean without having timeout method is not recommended or it is strictly not allowed?

[admin]

As per section 18.2.5,

The enterprise bean class of a bean that is to be registered with the timer service for timer callbacks must provide one or more timeout callback methods.

HTH,
Paul.

[sanju.ait@gmail.com]

But we can have more than one timeout callbacks only when max one method is annotated with @Timeout and rest timeout callbacks are @Schedule.
More than one @Timeout annotated methods is also not valid.

[alex]

Hi Paul,

I am interested in this explanation for option
System.out.println("user transaction = "+mctx.getUserTransaction());

In the absence of any deployment descriptor, the given bean is assumed to use container managed transaction demarcation. Thus, it cannot call getUserTransaction().

As I understand either we declare @TransactionManagement(TransactionManagementType.CONTAINER) explicity or don't it uses CONTAINER management transaction. And we can't override it via deployment descriptor.
So why the absence of any deployment descriptor is important here?

[admin]

You cannot override the transaction type in the DD, but you can specify it in DD if the bean does not specify it using annotation. So if the bean does not have annotation for transaction type, and if the DD specifies BEAN, then that would be valid scenario. Actually, that is how transaction type was specified before annotations came along. So that is same as before.

HTH,
Paul.

[alex]

I minunderstood following.
Section - 13.3.6 Specification of a Bean’s Transaction Management Type - The transaction management type of a bean is determined by the Bean Provider. The application assembler is not permitted to use the deployment descriptor to override a bean’s transaction management typeregardless of whether it has been explicitly specified or defaulted by the Bean Provider.

Now it's clear.
Thank you, Paul

[admin]

I think you have a point there. From the statement that you've quoted, your interpretation is correct. The words "in absence of DD" should be removed.

But section 13.3.1 says,

When designing an enterprise bean, the developer must decide whether the enterprise bean will demarcate transactions programmatically in the business methods (bean-managed transaction demarcation), or whether the transaction demarcation is to be performed by the container based on the transaction attributes specified in metadata annotations or in the deployment descriptor (container-managed transaction demarcation).

Further, in 13.3.6, it says,

Alternatively, the Bean Provider can use the transaction-type deployment descriptor element to specify the bean’s transaction management type. If the deployment descriptor is used, it is only necessary to explicitly specify the bean’s transaction management type if bean-managed transaction is used.

So I think the statement "in absence of DD" is fine afterall
-Paul.