Validation on J2EE modules can be manual or automatic. To run it manually you need to select the J2EE module, right click and select Run
Validation on the pop up menu. The automatic validation is triggered during a full build or an incremental build if auto build preference is turned on there is delta i.e a change in one of the resources in the modules. The validators that are registered to run on a J2EE module can be seen on the validation properties page.
The prerequisite to run this test is to have an Enterprise Application project with some module projects in the workbench. An Enterprise Application project can be created using J2EE module creation or EAR Import testcase, refer one of these testcases before trying to run this test. This EAR Validator is part of the j2ee component in the jst project.
The EAR Validator validates J2EE 1.2, 1.3 and 1.4 specification
artifacts and other artifacts that are related to the workbench for
Enterprise Application module or an Enterprise Application (ear)
archives. For each of the J2EE module artifacts validated if an error
condition is found the validator puts out a Error, Warning or
Informational message in the problems view based on the severity of
the error condition. Here are the list of artifacts and how to
validate these artifacts.
- Test if a module exists for each module defined in the
application.xml of the EAR module - To perform this test paste a
module that does not exist in the in the application.xml source (as
opposed to adding it using an Add Module operation where you are
forced to specify a project). e.g: Add this piece of XML to the
application.xml file and make sure a TestEAREJB module does not exist
in the workbench.
Result: On saving the application.xml file the following warning
"The module TestEAREJB.jar in enterprise application project
FooEAREJB is not mapped to a workbench project. Use the application
editor to correct." is put out in the problems view:
- Test if a corresponding j2ee module project (application client,
web, ejb, connector, utility jars) exists for each module defined in
the .modulemap - To perform this test delete a module defintion from
the application.xml file for an existing module defined in the .module
map file and re-add the module back to the application.xml to see if
an error condition shows up. Repeat this for existing utility JAR.For
e.g in this test we will be deleting a module called TestClient and
Result: On re-add of the module and to the application.xml and saving
it the following warning is put out in the problems view.
"The module TestClient.jar in enterprise application project
TestEJB is not mapped to a workbench project. Use the application
editor to correct. "
- Test if there are duplicate project refs for a module in the EAR -
To perform this test hand edit the URIs to have the same URI for 2
different module projects in application.xml file of the same EAR
module. For e.g replace the tag
<java>TestClient.jar</java> tag of an Application client
module to an ejb module in the same EAR Module.
Result: On saving the application.xml file the following warning is
put out in the problems view.
The module TestClient.jar has duplicate uri in EAR: Test.
- Test if the Manifest Class-Path: entry is valid for a module and
utility JAR project - To perform this test hand edit the manifest file
(MANIFEST.MF) to make it invalid.
Result: An error message "An error occurred validating the
MANIFEST.MF file in archive Foo." where Foo is then name the
module is put out in the problems view.
- Test manifest line length for a module and utility JAR project: To
perform this test hand edit and make the classpath line longer than 72
Result: An error message "Line XX in the MANIFEST.MF file in
archive Foo exceeds the specification limit of 72 bytes." where
Foo is then name the module and XX is the Line number that exceeds 72
bytes is put out in the problems view
- Test manifest not ending with blank line for a module and utility
JAR project - To perfomr this test hand edit and remove blank lines to
create the error condition.
Result: An error message "The MANIFEST.MF file in archive Foo
does not end with a newline." where Foo is the name the module
MANIFEST.MF file that does not end in a new line, is put out in the
- Test case of manifest file name - To perform this test rename to
"manifest.mf" this should get an error about the filename
(this error shows up only if there is a classpath entry in the
Result: The following error message "The case of the manifest
file name "META-INF/manifest.mf" in archive TestEAREJB.jar
in incorrect. File name must be "META-INF/MANIFEST.MF" where
TestEAREJB is the module that has the manifest file in lowercase, is
put out in the problems view
- Test spaces in a module/utility JAR uri (spaces not allowed) - To
perform this test add spaces in the module or utility jar URI to
create the error condtion. For e.g. For Connetor module change the
<connector>Test EARConnector.rar</connector> by adding a
Result: The following is the error put out in the problems view
"The URI Test EARConnector.rar contains a space. This is not
recommended because it cannot be referenced from a manifest file.
- Test security roles within a EAR - To perfomr this test copy and
paste duplicate security roles in xml. For e.g: the following xml show
2 security roles with the same name
Result: The warning message that is put out for duplicate security
roles is: "Duplicate security role named Sec1."
- Test the EJB module refs in the EAR. To perform this test in an
EJB module, a client module, and in a web module, add EJB refs, and
modify the source of the deployment descriptor file to change the
ejb-link to a non-existent ejb name.
Result: You should get a validation warning for each ejb ref that has
link to a non-existant ejb name.
Repeat for EJB local refs (in a 13 EAR). For an EJB ref that is
linked, make the home and remote disagree with the home and remote of
the linked EJB.
- Test Web module context roots for duplicates. For e.g. The
following XML shows the duplicate contect-root for 2 web modules in in
Result: An error message "Same context root "FooWeb"
exists in Web modules "FooWeb.war" and
"FooWeb1.war"" is put out in the problems view.
- Test project/module mismatch: Create a 1.2 and 1.3 enterprise
application project. Copy the 1.2 header from the xml file into the
xml file of the 1.3 project, and vice-versa. You should get validation
errors. For e.g. The following xml show that header of an J2EE 1.2 EAR
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE application PUBLIC "-//Sun Microsystems, Inc.//DTD
J2EE Application 1.2//EN"
Result: When the above XML is paste in the header of an J2EE 1.3 EAR
the validator puts out a error message as follows:
Document type version "1.2" for application.xml in project
"Test13EAR" needs to be version "1.3".