| Chapter | Assertions | Testable | Total Tested | Total Tests | Tested (problematic) |
Tested (working) |
Coverage % |
|---|---|---|---|---|---|---|---|
| 2 Managed Beans Definition | 37 | 20 | 0 | 0 | 0 | 0 | 0.00% |
| Total | 37 | 20 | 0 | 0 | 0 | 0 | 0.00% |
| Section | Assertions | Testable | Total Tested | Tested (problematic) | Tested (working) | Coverage % |
|---|---|---|---|---|---|---|
| 2 Managed Beans Definition | 0 | 0 | 0 | 0 | 0 | |
| 2.1 Basic Model | 0 | 0 | 0 | 0 | 0 | |
| 2.1.1 Component definition | 8 | 3 | 0 | 0 | 0 | 0.00% |
| 2.1.2 Naming | 7 | 6 | 0 | 0 | 0 | 0.00% |
| 2.1.3 Lifecycle and Resource Injection | 5 | 5 | 0 | 0 | 0 | 0.00% |
| 2.1.4 Threading | 1 | 1 | 0 | 0 | 0 | 0.00% |
| 2.1.5 Interceptors | 1 | 0 | 0 | 0 | 0 | |
| 2.2 Extensions | 1 | 0 | 0 | 0 | 0 | |
| 2.2.1 Component Definition | 2 | 1 | 0 | 0 | 0 | 0.00% |
| 2.2.2 Naming | 2 | 0 | 0 | 0 | 0 | |
| 2.2.3 Lifecycle and Resource Injection | 2 | 0 | 0 | 0 | 0 | |
| 2.2.4 Threading | 1 | 0 | 0 | 0 | 0 | |
| 2.2.5 Interceptors | 1 | 0 | 0 | 0 | 0 | |
| 2.3 [Injection of] Managed Bean References | 4 | 4 | 0 | 0 | 0 | 0.00% |
| 2.3.1 Application Component Provider's Responsibilities | 1 | 0 | 0 | 0 | 0 | |
| 2.3.2 Java EE Product Provider's Responsibilities | 1 | 0 | 0 | 0 | 0 |
| Colour Key |
|---|
| Assertion is covered |
| Assertion is not covered |
| Assertion test is unimplemented |
| Assertion is untestable |
A Managed Bean can be declared by annotating its class with the javax.annotation.ManagedBean annotation.
Verify a top-level class
Coverage
No tests exist for this assertion
Verify a static inner class
Coverage
No tests exist for this assertion
A Managed Bean must not be: a final class, an abstract class, a non-static inner class or a generic class.
Test that a managed bean may not be a final class.
Test that a managed bean may not be an abstract class.
Test that a managed bean may not be a non-static inner class.
Test that a managed bean may not be a generic class.
A Managed Bean may not be serializable, unlike a regular JavaBean component.
Managed Bean implementations must support Managed Beans that have a no-argument constructor.
Coverage
No tests exist for this assertion
A Managed Bean may optionally have a name, a String.
Coverage
No tests exist for this assertion
The name can be specified using an element of the ManagedBean annotation.
Coverage
No tests exist for this assertion
Managed Bean names must be unique within a Java EE module. It is an error if a Java EE module contains an EJB component and a Managed Bean with the same name.
For each named Managed Bean, Java EE containers must make available the following entries in JNDI, using the same naming schema used for EJB components. In the application namespace: java:app/<module-name>/<bean-name>. In the module namespace of the module containing the Managed Bean: java:module/<bean-name>.
Test that the application namespace entry exists.
Coverage
No tests exist for this assertion
Test that the module namespace entry exists.
Coverage
No tests exist for this assertion
Java EE applications may obtain a new instance of a Managed Bean by looking up the corresponding names in JNDI or by using resource injection. See Section MB.2.3, "[Injection of] Managed Bean References" for more details.
Test obtaining a new instance via JNDI lookup.
Coverage
No tests exist for this assertion
Test obtaining a new instance via resource injection.
Coverage
No tests exist for this assertion
Managed Beans may use the javax.annotation.PostConstruct and javax.annotation.PreDestroy annotations to identify methods to be called back by the container at the appropriate points in the bean's lifecycle.
Test the javax.annotation.PostConstruct annotation.
Coverage
No tests exist for this assertion
Test the javax.annotation.PreDestroy annotation.
Coverage
No tests exist for this assertion
In a Java EE implementation, a Managed Bean may use any of the resource injection functionality laid out in Chapter EE.5 of the Java EE Platform specification, "Resources, Naming and Injection".
Check @Resource injection
Coverage
No tests exist for this assertion
Check @EJB injection
Coverage
No tests exist for this assertion
A Managed Bean does not have its own component-scoped "java:comp" namespace. For this reason, Managed Beans should define resources in the "java:module" namespace or above. JNDI lookup operations from a method defined on a Managed Bean will use the naming context of that method's caller.
Coverage
No tests exist for this assertion
Method invocations on a Managed Bean execute in the same thread as the caller.
Coverage
No tests exist for this assertion
A Managed Bean may use interceptors as defined in the Interceptor specification.
Specifications that build on the present one (called here an "extension specification") may modify some of the aspects of the basic model, as detailed in the rest of this section.
An extension specification may provide ways to declare a Managed Bean that go beyond those in Section MB.2.1.1, "Component Definition".
Coverage
No tests exist for this assertion
An extension specification may allow a Managed Bean to declare constructors with complex signatures, thus dropping the requirement that a no-argument constructor be present.
An extension specification may offer alternative ways to name a Managed Bean, e.g. as a side-effect of placing some other annotation on the bean class, but, if specified, the ManagedBean(name="...") annotation takes priority, and with it the rules in Section MB.2.1.2, "Naming".
Of course an extension specification may also introduce one or more additional namespaces in which some or all Managed Beans get registered, either with the Managed Bean name defined in Section MB.2.1.2, "Naming" or with an independently defined name.
An extension specification may define its own lifecycle model, adding e.g. pooling, sharing of instances, etc., beyond the basic model described in Section MB.2.1.3, "Lifecycle and Resource Injection".
An extension specification may allow Managed Beans to have their own "java:comp" namespace.
An extension specification may add its own threading requirements, overriding any requirements set in Section MB.2.1.4, "Threading". For example, invocations on a [proxy for] a Managed Bean may be performed using a different thread than the caller's.
An extension specification may add its own interceptor-like facilities to the predefined one. For example, an extension specification may allow declaring type-safe interceptors, defined using a different set of APIs than those in the javax.interceptor package.
An instance of a named Managed Bean can be obtained by looking up its name in JNDI using the same naming scheme used for EJB components: java:app/<module-name>/<bean-name>, java:module/<bean-name>. The latter will only work within the module the Managed Bean is declared in. Each such lookup must return a new instance.
Test that the latter lookup only works within the Managed Bean's module.
Coverage
No tests exist for this assertion
Test that each lookup returns a new instance.
Coverage
No tests exist for this assertion
The @Resource annotation can be used to request the injection of a Managed Bean given either its type or its name. If no name is specified, the type must be the Managed Bean class itself. If a name is specified, then the type of the resource can be any of the types that the Managed Bean class implements, including any of its interfaces.
Test injection with no name.
Coverage
No tests exist for this assertion
Test injection with a name.
Coverage
No tests exist for this assertion
The Application Component Provider is responsible for requesting injection of a Managed Bean, or by looking it up in JNDI using an appropriate name.
The Java EE Product Provider is responsible for providing appropriate instances of the requested Managed Bean class as required by this specification.
| Test Class | Test method |
|---|---|
rewrite (0) | |