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.



1. 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.
   
   <module id="EjbModule_1102967206648">
   <ejb>TestEAREJB.jar</ejb>
   </module>
   
   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:
   
   
2. 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 re-adding it.
   
   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. "
   
   
3. 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. application.xml Test/META-INF
   
   
4. 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.
   
5. 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 chars.
   
   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
   
6. 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 problems view.
   
   
7. 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 MANIFEST.MF).
   
   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
   
   
8. 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>TestEARConnector.rar</connector> to <connector>Test EARConnector.rar</connector> by adding a space.
   
   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. application"
   
   
   
9. 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
   <security-role>
   <description>Sec Role</description>
   <description>Sec Role</description>
   <role-name>Sec1</role-name>
   </security-role>
   <security-role>
   <description>Sec Role</description>
   <description>Sec Role</description>
   <role-name>Sec1</role-name>
   </security-role>
   
   Result: The warning message that is put out for duplicate security roles is: "Duplicate security role named Sec1."
   
   
10. 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.
    
    
11. Test Web module context roots for duplicates. For e.g. The following XML shows the duplicate contect-root for 2 web modules in in a application.xml
    
    <module id="WebModule_1102974961203">
    <web>
    <web-uri>FooWeb.war</web-uri>
    <context-root>FooWeb</context-root>
    </web>
    </module>
    
    <module id="WebModule_1102974961203">
    <web>
    <web-uri>Foo1Web.war</web-uri>
    <context-root>FooWeb</context-root>
    </web>
    </module>
    
    Result: An error message "Same context root "FooWeb" exists in Web modules "FooWeb.war" and "FooWeb1.war"" is put out in the problems view.
    
    
12. 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 module
    
    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE application PUBLIC "-//Sun Microsystems, Inc.//DTD J2EE Application 1.2//EN" "http://java.sun.com/j2ee/dtds/application_1_2.dtd">
    <application id="Application_ID">
    <display-name>Test12EAR</display-name>
    </application>
    
    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".