Page: 1
/ 6
Total 90 questions
Which two are programming restrictions in the EJB specification? (Choose two.)
- A. An enterprise bean must NOT attempt to load a native library.
- B. An enterprise bean must NOT declare static fields as final.
- C. An enterprise bean must NOT attempt to create a new security manager.
- D. An enterprise bean must NOT propagate a RuntimeException to the container.
- E. An enterprise bean must NOT attempt to obtain a javax.naming.InitialContext.
Answer : A,C
Explanation: The following is a list of Java features that you should avoid, hence restricting their use in your EJB components' implementation code:
(A)Loading native libraries.
(C)Attempting to create or obtain a class loader, set or create a new security manager(C), stop the JVM, change the input, output, and error streams. That restriction enforces security and maintains the EJB container's ability to manage the runtime environment.
(not B)Using static, nonfinal fields. Declaring all static fields in the EJB component as final is recommended. That ensures consistent runtime semantics so that EJB containers have the flexibility to distribute instances across multiple JVMs.
Reference:Programming restrictions on EJB
Which three methods can Bean Developer use in any EJB compliant container implementing the full Java EE6 product? (Choose three.)
- A. Class.getClassLoader
- B. FileInputStream.read
- C. DataSource.getConnection
- D. EJBContext.getCallerPrincipal
- E. Executors.newSingleThreadExecutor
- F. QueueConnection.createQueueSession
Answer : B,C,D
Explanation: D: UseEJBContext.getCallerPrincipal()to obtain the java.security.Principal that identifies the caller.
Incorrect:
A: Do not load native libraries.
E: Not allowed:Starting, stopping, or managing threads in any way. That restriction eliminates the possibility of conflicts with the EJB container's responsibilities of managing locking, threading, and concurrency issues.
Reference:Programming restrictions on EJB
Reference:javax.ejb Interface EJBContext
Which two annotations can be applied at the class, method, and field levels? (Choose two.)
- A. @EJB
- B. @Init
- C. @Resource
- D. @RolesAllowed
- E. @PostActivate
Answer : A,C
Explanation: A:javax.ejb.EJB -
Description -
Target: Class, Method, Field -
Specifies a dependency or reference to an EJB business or home interface.
You annotate a beans instance variable with the @EJB annotation to specify a dependence on another EJB.
C:javax.annotation.Resource -
Description -
Target: Class, Method, Field -
Specifies a dependence on an external resource, such as a JDBC data source or a JMS destination or connection factory.
Incorrect:
B:javax.ejb.Init -
Description -
Target: Method -
D:javax.annotation.security.RolesAllowed
Description -
Target: Class, Method -
Specifies the list of security roles that are allowed to access methods in the EJB.
E:javax.ejb.PostActivate -
Description -
Target: Method -
Specifies the lifecycle callback method that signals that the EJB container has just reactivated the bean instance.
Reference:EJB 3.0 Metadata Annotations Reference
Which statement is true about both stateful session beans and stateless session beans?
- A. Bean instance are NOT required to survive container crashes.
- B. Any bean instance must be able to handle concurrent invocations from different threads.
- C. A bean with bean-managed transactions must commit or roll back any transaction before returning from a business method.
- D. The container passivates and actives them using methods annotated with @PrePassivate and @PostActivate annotations.
Answer : A,C
Explanation:
Note:
*Session beans can either be stateful or stateless. With stateful beans, the EJB container saves internal bean data during and in between method calls on the clients behalf. With stateless beans, the clients may call any available instance of an instantiated bean for as long as the EJB container has the ability to pool stateless beans. This enables the number of instantiations of a bean to be reduced, thereby reducing required resources.
Incorrect:
B:Stateful session beans maintain state both within and between transactions. Each stateful session bean is therefore associated with a specific client.
D:@PrePassivate(javax.ejb.PrePassivate) :
If a stateful session bean instance is idle for too long, the container might passivate it and store its state to a cache.
The method tagged by this annotation is called before the container passivates the bean instance.
This annotation is only applicable to stateful session beans.
Which must result in the destruction of a stateful session bean?
- A. A client calls an @Remove method and the method returns successfully.
- B. The server in which the stateful session bean was created is restarted.
- C. The stateful session bean participates in a transaction that is rolled back.
- D. The stateful session bean is chosen as a last recently used (LRU) victim for passivation.
Answer : A
Explanation: While in the ready stage, the EJB container may decide to deactivate, or passivate, the bean by moving it from memory to secondary storage. (Typically, the EJB container uses a least-recently-used algorithm to select a bean for passivation.) The EJB container invokes the method annotated @PrePassivate, if any, immediately before passivating it. If a client invokes a business method on the bean while it is in the passive stage, the EJB container activates the bean, calls the method annotated @PostActivate, if any, and then moves it to the ready stage.
Note:
At the end of the lifecycle, the client invokes a method annotated @Remove, and the EJB container calls the method annotated @PreDestroy, if any. The beans instance is then ready for garbage collection.
*When a stateful bean is passivated, the instance fields are read and then written to the secondary storage associated with the EJB object. When the stateful session bean has been successfully passivated, the instance is evicted from memory; it is destroyed.
*When a passivated bean instance times out or when a client invokes the method marked with @Remove, the container may destroy the bean. Before destroying, the container will invoke the method annotated with @PreDestroy.
Reference:The Java EE 6 Tutorial,The Lifecycles of Enterprise Beans
Suppose an EJB component is named HelloWorldBean is deployed as a standalone ejb- jar. Assuming the HelloWorldBean is implemented as follows:
Which types of clients are guaranteed to have access to HelloWorldBean:
- A. Java EE application client container applications
- B. Java EE ejb components within the same ejb-jar
- C. Java EE web-tier component applications deployed in the same container
- D. Java EE ejb component applications deployed in the same container
Answer : D
Assume an EJB application is comprised of the following EJB fragment:
You have been asked to convert the type of InventoryReportBean into a singleton session bean. How would you achieve this task?
Exhibit C:
Exhibit D:
- A. Keep InventoryReportBean as it is, modifying the internal structure to function as a singleton
- B. Change the @Stateless annotation of InventoryReportBean to @Singleton
- C. Create an ejb-jar.xml file, and override the annotation configuration information asin exhibit C above.
- D. Create an ejb-jar.xml file, and override the annotation configuration information asin exhibit D above.
Answer : D
Explanation: Note the line with <override-type>
Given Singleton bean FooEJB:
FooEJB is packaged as the only bean in an ejb-jar and deployed to a server instance.
Which represents the output generated from FooEJB after the deployment has completed?
- A. Init
- B. foo
- C. Init foo
- D. <no output>
- E. a or d
Answer : A
Explanation: Note:
*The PostConstruct annotation is used on a method that needs to be executed after dependency injection is done to perform any initialization. This method MUST be invoked before the class is put into service. This annotation MUST be supported on all classes that support dependency injection. The method annotated with PostConstruct MUST be invoked even if the class does not request any resources to be injected. Only one method can be annotated with this annotation. The method on which the PostConstruct annotation is applied MUST fulfill all of the following criteria - - The method MUST NOT have any parameters except in the case of EJB interceptors in which case it takes an InvocationC ontext object as defined by the EJB specification. - The return type of the method MUST be void. - The method MUST NOT throw a checked exception. - The method on which
PostConstruct is applied MAY be public, protected, package private or private. - The method MUST NOT be static except for the application client. - The method MAY be final. -
If the method throws an unchecked exception the class MUST NOT be put into service except in the case of EJBs where the EJB can handle exceptions and even recover from them.
*PostConstruct methods are invoked on the newly constructed instance, after any dependency injection has been performed by the container and before the first businessmethod is invoked on the bean.
A developer writes a stateless session bean FooBean and uses its deployment descriptor to declare a local ejb dependency on a stateful session bean in the same ejb-jar.
Which environment annotation, when declared within the FooBean bean class, is equivalent to the ejb-local-ref shown above?
- A. @EJB(beanName=BarBean) Privateacme.Bar barRef;
- B. @EJB(name=bar, beanName=BarBean) Privateacme.Bar barRef;
- C. @EJB(name=barRef, beanName=BarBean) Private acme.Bar bar;
- D. @EJB(name=ejab/barRef, beanName=BarBean) Private acme.Bar bar;
Answer : C
Explanation: name is barRef -
Example:
ejb-local-ref
share [gp] share [fb] share [tw] contribute
Via annotation -
Usable by EJB, Interceptor, Servlet, Filter, or Listener
packageorg.superbiz.refs;
importjavax.ejb.EJB;
importjavax.ejb.Stateless;
importjavax.naming.InitialContext;
@Stateless
@EJB(name="myFooEjb",beanInterface=FooLocal.class)
publicclassMyEjbLocalRefBeanimplementsMyBeanInterface{
@EJB
privateBarLocalmyBarEjb;
publicvoidsomeBusinessMethod()throwsException{
if(myBarEjb==null)thrownewNullPointerException("myBarEjb not injected");
// Both can be looked up from JNDI as well
InitialContextcontext=newInitialContext();
FooLocalfooLocal=(FooLocal)context.lookup("java:comp/env/myFooEjb");
BarLocalbarLocal=(BarLocal)context.lookup("java:comp/env/org.superbiz.refs.MyEjbLocal
RefBean/myBarEjb");
}
}
Via xml -
The above @EJB annotation usage is 100% equivalent to the following xml.
<ejb-local-ref>
<ejb-ref-name>myFooEjb</ejb-ref-name>
<local>org.superbiz.refs.FooLocal</local>
</ejb-local-ref>
<ejb-local-ref>
<ejb-ref-name>org.superbiz.refs.MyEjbLocalRefBean/myBarEjb</ejb-ref-name>
<local>org.superbiz.refs.BarLocal</local>
<injection-target>
<injection-target-class>org.superbiz.refs.MyEjbLocalRefBean</injection-target-class>
<injection-target-name>myBarEjb</injection-target-name>
</injection-target>
</ejb-local-ref>
A developer writes an interceptor class and a stateless session bean:
A client acquires an EJB reference to the FooLocal business interface and invokes the foo() method one time. Which describes the output?
- A. Foo FooInt AInt
- B. AInt Foo
- C. AInt FooInt Foo
- D. FooInt AInt Foo
Answer : C
Explanation: *At the end of the chain of interceptors, the actual bean method gets called.
*Interceptors can be bound in three different ways:
Default -
Class level -
Method level -
In this question both class level and method level interceptors are used.
The class level interceptor intercepts before the method-level interceptor.
Note:
*Interceptors are used in conjunction with Java EE managed classes to allow developers to invoke interceptor methods on an associated target class, in conjunction with method invocations or lifecycle events. Common uses of interceptors are logging, auditing, and profiling.
*An interceptor can be defined within a target class as an interceptor method, or in an associated class called an interceptor class. Interceptor classes contain methods that are invoked in conjunction with the methods or lifecycle events of the target class.
Interceptor classes and methods are defined using metadata annotations, or in the deployment descriptor of the application containing the interceptors and target classes.
*javax.interceptor.AroundInvoke
Designates the method as an interceptor method.
*The target class can have any number of interceptor classes associated with it. The order in which the interceptor classes are invoked is determined by the order in which the interceptor classes are defined in the javax.interceptor.Interceptors annotation.
Reference:Introduction to EJB3 Interceptors
Reference:The Java EE 6 Tutorial,Overview of Interceptors
A developer writes an interceptor class containing an AroundInvoke method, and applies it to the local business interface method of a stateless session bean:
11. @Interceptors(FooInterceptor.class)
12. public void bar() ()
A client obtains a reference to the beans local business interface, and calls the method bar two times from the same thread. Assuming that the container dispatches both cell to the same stateless session bean instance, how many instances of the FooInterceptor class will be used?
- A. 0
- B. 2
- C. 1
- D. Either 1 or 2
Answer : B
Explanation: You can specify one nonbusiness method as the interceptor method for a stateless or stateful session bean. Each time a client invokes a session bean business method, OC4J intercepts the invocation and invokes the interceptor method.
Reference:Configuring an Around Invoke Interceptor Method on an EJB 3.0 Session Bean
While excepting a business method in a stateless session bean the container rolls back the methods transaction. Which three are possible causes for the containers behavior?
(Choose three.)
- A. The bean uses container-managed transactions and invokes EJBContext.setRollbackOnly.
- B. The bean uses container-managed transactions and invokes EJBContext.getRollbackOnly.
- C. The business method throws a java.lang.NullPointerException.
- D. The business method throws a checked exception of a class type that is marked with the @ApplicationException annotation with the rollback element value true.
- E. The business method throws a unchecked exception of a class type that is marked with the @ApplicationException annotation with the rollback element value true.
- F. The bean uses container-managed transactions and throws a checked exception of a class type that is marked with the @ApplicationException annotation with the rollback element value false.
Answer : A,D,F
Explanation: A:setRollbackOnly -
Mark the current transaction for rollback. The transaction will become permanently marked for rollback. A transaction marked for rollback can never commit. Only enterprise beans with container-managed transactions are allowed to use this method.
Note:
* In a stateless session bean with bean-managed transactions, a business method must commit or roll back a transaction before returning.
*Bean-Managed Transactions
In bean-managed transaction demarcation, the code in the session or message-driven bean explicitly marks the boundaries of the transaction. Although beans with container- managed transactions require less coding, they have one limitation: When a method is executing, it can be associated with either a single transaction or no transaction at all. If this limitation will make coding your bean difficult, you should consider using bean- managed transactions.
* (incorrect)Unchecked runtime exceptions represent conditions that, generally speaking, reflect errors in your program's logic and cannot be reasonably recovered from at run time.
Incorrect:
B:getRollbackOnly -
Test if the transaction has been marked for rollback only. An enterprise bean instance can use this operation, for example, to test after an exception has been caught, whether it is fruitless to continue computation on behalf of the current transaction. Only enterprise beans with container-managed transactions are allowed to use this method.
A stateless session bean FooBean implements an asynchronous business method foo() on its bean class:
@Asynchronous
public void foo() ( )
The asynchronous business method is exposed through a remote business interface
FooRemote. A caller acquires an EJB reference to this bean and invokes it as follows:
100. fooRemoteRef.foo();
Which exception can result from the invocation on line 100?
- A. java.rmi.RemoteException
- B. java.util.concurrent.ExecutionException
- C. javax.ejb.EJBException
- D. java.lang.IllegalArgumentException
Answer : A
Explanation:
Note:
*RemoteRef represents the handle for a remote object. A RemoteStub uses a remote reference to carry out a remote method invocation to a remote object.
*invoke
public Object invoke(Remote obj,
Method method,
Object[] params,
long opnum)
throws Exception
Invoke a method. This form of delegating method invocation to the reference allows the reference to take care of setting up the connection to the remote host, marshaling some representation for the method and parameters, then communicating the method invocation to the remote host. This method either returns the result of a method invocation on the remote object which resides on the remote host or throws a RemoteException if the call failed or an application-level exception if the remote invocation throws an exception.
Parameters:
A developer impalements an asynchronous implementation for calculating insurance proposals. The input data for the calculations is made available on a single message queue. Two types of insurance proposals will be calculated: car and life. Message with data for other insurance types are posted on the queue but should be left on the queue by this implementation.
Which statement is true?
- A. The developer will NOT succeed because all messages will be consumed from the queue.
- B. The developer can implement a push-back mechanism if the message is of the wrong type.
- C. The developer can use a messageSelector to receive only the car and life data message if the JMS body contains selectable data.
- D. The developer can use a messageSelector to receive only the car and life data message if the header contains properties to make selection.
Answer : D
Explanation: A JMS message selector allows a client to specify, by header field references and property references, the messages it is interested in. Only messages whose header and property values match the selector are delivered. What it means for a message not to be delivered depends on the MessageConsumer being used (see
QueueReceiver and TopicSubscriber).
Reference:javax.jms Interface Message
Which two statements are true JMS message-driven beans? (Choose two.)
- A. The developer can use JMS message selector declarations to restrict the message that the bean receives.
- B. The developer can associate the bean with a specific queue or topic using the resource- ref element of the deployment descriptor.
- C. To achieve concurrent processing of more than one message at a time, more than one bean class must be associated with the same JMS queue.
- D. The developer can use the activationConfig element of the MessageDriven annotation to specify whether the bean should be associated with a queue or a topic.
Answer : A,D
Explanation: A:Elements in the deployment descriptor
The description of a MDB(message-driven beans)in the EJB 2.0 deployment descriptor contains the following specific elements:
*the JMS acknowledgement mode: auto-acknowledge or dups-ok-acknowledge
*an eventual JMS message selector: this is a JMS concept which allows the filtering of the messages sent to the destination
*a message-driven-destination, which contains the destination type (Queue or Topic) and the subscription
D:Example:
The following example is a basic message-driven bean:
@MessageDriven(activationConfig={
@ActivationConfigProperty(propertyName="destination", propertyValue="myDestination"),
@ActivationConfigProperty(propertyName="destinationType",
propertyValue="javax.jms.Queue")
})
public class MsgBean implements javax.jms.MessageListener {
public void onMessage(javax.jms.Message msg) {
String receivedMsg = ((TextMessage) msg).getText();
System.out.println("Received message: " + receivedMsg);
}
}
Reference:Developing message-driven beans
Reference:Message Driven Beans Tutorial
30 days access 