Jakarta EE: Managed Beans TCK Coverage

1.0.PFD

Contents

Chapter Summary
Section Summary
Coverage Detail
Unmatched Tests
Unversioned Tests
Test Group Summary

Coverage Distribution

 
 
 
 
 
 
 
 
 
 

Chapter Summary

Chapter Assertions Testable Total Tested Total Tests Tested
(problematic)		 Tested
(working)		 Coverage %
2 Managed Beans Definition372000000.00%
Total372000000.00%

Section Summary

SectionAssertionsTestableTotal TestedTested
(problematic)		Tested
(working)		Coverage %
2 Managed Beans Definition00000
2.1 Basic Model00000
2.1.1 Component definition830000.00%
2.1.2 Naming760000.00%
2.1.3 Lifecycle and Resource Injection550000.00%
2.1.4 Threading110000.00%
2.1.5 Interceptors10000
2.2 Extensions10000
2.2.1 Component Definition210000.00%
2.2.2 Naming20000
2.2.3 Lifecycle and Resource Injection20000
2.2.4 Threading10000
2.2.5 Interceptors10000
2.3 [Injection of] Managed Bean References440000.00%
2.3.1 Application Component Provider's Responsibilities10000
2.3.2 Jakarta EE Product Provider's Responsibilities10000

Coverage Detail

Colour Key
Assertion is covered
Assertion is not covered
Assertion test is unimplemented
Assertion is untestable

Section 2.1.1 - Component definition

A Managed Bean can be declared by annotating its class with the jakarta.annotation.ManagedBean annotation.

aa)

Verify a top-level class

Coverage

No tests exist for this assertion

ab)

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.

b)Doesn't define any error condition

Test that a managed bean may not be a final class.

c)Doesn't define any error condition

Test that a managed bean may not be an abstract class.

d)Doesn't define any error condition

Test that a managed bean may not be a non-static inner class.

e)Doesn't define any error condition

Test that a managed bean may not be a generic class.

f)Doesn't define any error condition

A Managed Bean may not be serializable, unlike a regular JavaBean component.

g)

Managed Bean implementations must support Managed Beans that have a no-argument constructor.

Coverage

No tests exist for this assertion

Section 2.1.2 - Naming

a)Verify the name is optional

A Managed Bean may optionally have a name, a String.

Coverage

No tests exist for this assertion

b)

The name can be specified using an element of the ManagedBean annotation.

Coverage

No tests exist for this assertion

c)The behaviour here is unspecified.

Managed Bean names must be unique within a Jakarta EE module. It is an error if a Jakarta EE module contains an EJB component and a Managed Bean with the same name.

For each named Managed Bean, Jakarta 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>.

d)

Test that the application namespace entry exists.

Coverage

No tests exist for this assertion

e)

Test that the module namespace entry exists.

Coverage

No tests exist for this assertion

Jakarta 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.

f)

Test obtaining a new instance via JNDI lookup.

Coverage

No tests exist for this assertion

g)

Test obtaining a new instance via resource injection.

Coverage

No tests exist for this assertion

Section 2.1.3 - Lifecycle and Resource Injection

Managed Beans may use the jakarta.annotation.PostConstruct and jakarta.annotation.PreDestroy annotations to identify methods to be called back by the container at the appropriate points in the bean's lifecycle.

a)

Test the jakarta.annotation.PostConstruct annotation.

Coverage

No tests exist for this assertion

b)

Test the jakarta.annotation.PreDestroy annotation.

Coverage

No tests exist for this assertion

In a Jakarta EE implementation, a Managed Bean may use any of the resource injection functionality laid out in Chapter EE.5 of the Jakarta EE Platform specification, "Resources, Naming and Injection".

ca)

Check @Resource injection

Coverage

No tests exist for this assertion

cb)

Check @EJB injection

Coverage

No tests exist for this assertion

d)Check that lookup does use the naming context of the method's caller

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

Section 2.1.4 - Threading

a)

Method invocations on a Managed Bean execute in the same thread as the caller.

Coverage

No tests exist for this assertion

Section 2.1.5 - Interceptors

a)No way to verify as spec doesn't provide a way to bind interceptors to a bean

A Managed Bean may use interceptors as defined in the Interceptor specification.

Section 2.2 - Extensions

a)

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.

Section 2.2.1 - Component Definition

a)

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

b)

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.

Section 2.2.2 - Naming

a)

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".

b)

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.

Section 2.2.3 - Lifecycle and Resource Injection

a)

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".

b)

An extension specification may allow Managed Beans to have their own "java:comp" namespace.

Section 2.2.4 - Threading

a)

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.

Section 2.2.5 - Interceptors

a)

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 jakarta.interceptor package.

Section 2.3 - [Injection of] Managed Bean References

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.

a)

Test that the latter lookup only works within the Managed Bean's module.

Coverage

No tests exist for this assertion

b)

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.

c)

Test injection with no name.

Coverage

No tests exist for this assertion

d)

Test injection with a name.

Coverage

No tests exist for this assertion

Section 2.3.1 - Application Component Provider's Responsibilities

a)What is this about?

The Application Component Provider is responsible for requesting injection of a Managed Bean, or by looking it up in JNDI using an appropriate name.

Section 2.3.2 - Jakarta EE Product Provider's Responsibilities

a)

The Jakarta EE Product Provider is responsible for providing appropriate instances of the requested Managed Bean class as required by this specification.