You can overwrite the information defined in the annotation with the DD. The annotations defined in the modules of Servlet 2.5 or later and EJB 3.0 or later can be overwritten by the DD.
The methods of overwriting the annotations are as follows:
Annotation | Attribute | Message |
---|---|---|
@WebServlet | name attribute | KDJE42397-W |
@WebFilter | filtername attribute | KDJE42398-W |
The overwriting method differs depending on whether the target DD elements and child elements can appear multiple times.
This subsection describes the rules for overwriting the annotations using the DD by separating them into the following 4 patterns.
Table 12-16 Pattern of rules for overwriting the annotations using the DD
Pattern | Occurrence count of the DD elements corresponding to the annotations | Presence of keys | Occurrence count of the DD child elements | Reference location |
---|---|---|---|---|
Pattern 1 | 0 times or once | When the key does not exist | -- | (1) |
Pattern 2 | 0 or more times or 1 or more times | When the key does not exist | -- | (2) |
Pattern 3 | When the key exists | 0 times or once | (3) | |
Pattern 4 | 0 or more times or 1 or more times | (4) |
For the mapping between the annotation and DD elements, presence or absence of keys for each element, and the key elements, see the standard specifications.
The description of each pattern is as follows:
If the occurrence count of an element is 0 times or once, whether to overwrite the definition is determined by whether the element corresponding to the annotation is defined in the DD. The key value does not make a difference.
The following figure shows an example of an element with occurrence count of 0 times or once. In this example, the key exists.
Figure 12-3 Example of an element that appears 0 times or once
The definitions of both the DD and annotations are valid.
The following figure shows an example when the key does not exist. In addition to the security role defined in @DeclareRoles, a new security role is defined in the DD.
Figure 12-4 Example when the key does not exist
In this example, three security roles, 'admin', 'adminadmin', and 'adminadminadmin', are defined in the annotation. In addition to these, 'admin2' defined in the DD is added and applied in the merged DD. Note that 'adminadmin' is a security role defined in both, annotation and the DD. The application is operated assuming the merged DD is defined.
Note that when this pattern is applicable, the annotation definition cannot be changed using the server management commands. Even if the information corresponding to the annotation is deleted or changed in the property file and the cjsetappprop command is executed, the information defined in the annotation is output to the property file obtained by using the cjgetappprop command thereafter.
When the child element within a DD element appears 0 times or once, the overwriting method differs on the basis of the key value.
Figure 12-5 Example when the child element appears 0 times or once
In this example, the value of the environment entry 'res1' is changed from 'TEST' defined in the annotation to 'RUNNING' defined in the DD. The application is operated assuming that the merged DD is defined.
When the child element within a DD element appears 0 or more times or 1 or more times, the overwriting method differs on the basis of the key value.
Figure 12-6 Example when the child element appears 0 or more times or 1 or more times
In this example, the element 'injection-target' defined in the DD is added to the annotation definition. The application is operated assuming that the merged DD is defined.