Page 1 of 1
About Question enthuware.oce-ejbd.v6.2.554 :
Posted: Tue May 17, 2011 3:15 pm
by jszczepankiewicz
I would put empty line after the statement "(Assume appropriate package and import statements.) for more readability.
Re: About Question enthuware.oce-ejbd.v6.2.554 :
Posted: Sat May 21, 2011 5:50 am
by admin
This has been updated.
thanks for your feedback!
Re: About Question enthuware.oce-ejbd.v6.2.554 :
Posted: Sun Dec 16, 2012 11:51 am
by 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
Re: About Question enthuware.oce-ejbd.v6.2.554 :
Posted: Sun Dec 16, 2012 3:27 pm
by admin
Option 1 is indeed the correct option. I don't see any other correct option.
-Paul.
Re: About Question enthuware.oce-ejbd.v6.2.554 :
Posted: Mon Aug 26, 2013 10:15 am
by 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 } }
Re: About Question enthuware.oce-ejbd.v6.2.554 :
Posted: Mon Aug 26, 2013 10:21 am
by 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.
Re: About Question enthuware.oce-ejbd.v6.2.554 :
Posted: Tue Aug 27, 2013 2:23 pm
by 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.
Re: About Question enthuware.oce-ejbd.v6.2.554 :
Posted: Wed Aug 28, 2013 1:46 pm
by sanju.ait@gmail.com
Creating timer in bean without having timeout method is not recommended or it is strictly not allowed?
Re: About Question enthuware.oce-ejbd.v6.2.554 :
Posted: Wed Aug 28, 2013 3:26 pm
by 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.
Re: About Question enthuware.oce-ejbd.v6.2.554 :
Posted: Thu Aug 29, 2013 12:02 pm
by 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.
Re: About Question enthuware.oce-ejbd.v6.2.554 :
Posted: Sun Sep 29, 2013 8:14 am
by 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?
Re: About Question enthuware.oce-ejbd.v6.2.554 :
Posted: Sun Sep 29, 2013 9:08 am
by 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.
Re: About Question enthuware.oce-ejbd.v6.2.554 :
Posted: Sun Sep 29, 2013 11:15 am
by 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
Re: About Question enthuware.oce-ejbd.v6.2.554 :
Posted: Sun Sep 29, 2013 11:56 am
by 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.