Performing JAXR Registry Updates and The Java Application Verification Kit for the Enterprise, Part 2 Tech Tips

You are receiving this e-mail because you elected to receive e-mail from Sun Microsystems, Inc. To update your communications preferences, please see the link at the bottom of this message. We respect your privacy and post our privacy policy prominently on our Web site http://sun.com/privacy/

Welcome to the Enterprise Java Technologies Tech Tips.

Enterprise Java Technologies
TECHNICAL TIPS

July 28, 2005
View this issue as simple text

	In this Issue

	Here you'll get tips on using enterprise Java technologies and APIs, such as those in Java 2 Platform, Enterprise Edition (J2EE). This issue covers: » Performing JAXR Registry Updates » The Java Application Verification Kit for the Enterprise, Part 2 These tips were developed using the Java 2, Enterprise Edition, v 1.4 SDK. You can download the SDK at http://java.sun.com/j2ee/1.4/download.html. This issue of the Tech Tips is written by Robert Eckstein, a staff member of java.sun.com. See the Subscribe/Unsubscribe note at the end of this newsletter to subscribe to Tech Tips that focus on technologies and products in other Java platforms. You can download the sample archive for the Performing JAXR Registry Updates. Any use of this code and/or information below is subject to the license terms. For more Java technology content, visit these sites: java.sun.com - The latest Java platform releases, tutorials, and newsletters. java.net - A web forum where enthusiasts of Java technology can collaborate and build solutions together. java.com - Hot games, cool apps -- Experience the power of Java technology.

	PERFORMING JAXR REGISTRY UPDATES

The March 22, 2005 Tech Tip, Java API for XML Registries (JAXR) showed how to use JAXR to query a registry. In the following tip, which is based on information in the J2EE 1.4 Tutorial and the Java Web Services Developer Pack 1.6 Tutorial, you'll learn how to use JAXR to update a registry.

Let's begin by reviewing the JAXR architecture and how to make a JAXR connection. Both of these were described in the previous tip. Recall that according to the JAXR specifications, a provider must implement key interfaces in two packages:

javax.xml.registry. Consists of the API interfaces and classes that define the registry access interface.
javax.xml.registry.infomodel. Consists of interfaces that define the information model for JAXR. These interfaces define the types of objects that reside in a registry, and how the objects relate to each other. One of the most commonly used interfaces in this package is the RegistryObject interface. Its subinterfaces include Organization, Service, and ServiceBinding.

The javax.xml.registry package is particularly important because it contains a number of useful client interfaces:

Connection. Represents a client session with a registry provider. The client must create a connection with the JAXR provider to use a registry.
RegistryService. The client obtains a RegistryService object from its connection. The RegistryService object enables the client to obtain the interfaces it uses to access the registry, such as BusinessQueryManager and BusinessLifeCycleManager.
BusinessQueryManager. An object that implements this interface allows the client to search a registry for information in accordance with the javax.xml.registry.infomodel interfaces.
BusinessLifeCycleManager. An object that implements this interface allows the client to modify or delete the information in a registry.

This tip will explore uses of the BusinessLifeCycleManager object to update the Service Registry 3.0 Early Access release that comes with the Java Web Services Developer Pack (Java WSDP) 1.6.

Making the JAXR Connection

A JAXR client always starts by creating an instance of the abstract class ConnectionFactory:

   import javax.xml.registry.*;
   ...
   ConnectionFactory connFactory = 
    ConnectionFactory.newInstance();

Next, the client creates a set of properties that specify the URL or URLs of the registry or registries being accessed. For example, the following code provides the URLs of the query service and publishing service for the Service Registry:

   Properties props = new Properties();
   props.setProperty("javax.xml.registry.queryManagerURL",
       "http://localhost:8080/soar/registry/soap");
   props.setProperty("javax.xml.registry.lifeCycleManagerURL",
       "https://localhost:8080/soar/registry/soap");

The client then sets the properties for the connection factory and creates the connection:

   connFactory.setProperties(props);
   Connection connection = connFactory.createConnection();

After creating the connection, the client uses the connection to obtain a RegistryService object. It then uses the RegistryService to get objects that implement the appropriate query interfaces:

   RegistryService rs = connection.getRegistryService();
   BusinessQueryManager bqm = rs.getBusinessQueryManager();
   BusinessLifeCycleManager blcm = 
       rs.getBusinessLifeCycleManager();

If a client needs to both read and write data to a registry, it should obtain both a BusinessQueryManager object and a BusinessLifeCycleManager object from the RegistryService object.

With that background, now let's examine how to perform registry updates.

Performing Updates on Registry Data

If a client has proper authorization, it can submit data to a registry, modify it, and remove it. It uses an object that implements the BusinessLifeCycleManager interface to perform these tasks. Registries usually allow a client to modify or remove data only if the data is being modified or removed by the same user who first submitted the data.

Getting Authorization from the Registry

Before it can submit data, the client must send its user name and password to the registry in a set of credentials. The following code fragment shows how to do this:

   String username = "myUserName";
   String password = "myPassword";

   // Get authorization from the registry
   PasswordAuthentication passwdAuth =
     new PasswordAuthentication(username,
       password.toCharArray();

   Set creds = new HashSet();
   creds.add(passwdAuth);
   connection.setCredentials(creds);

Creating an Organization

The client creates the organization object and populates it with data before publishing it. An Organization object is one of the more complex data items in the JAXR API. It normally includes the following objects:

Name
Description
Key. This object represents the ID that identifies the organization to the registry. This key is created by the registry, not by the user, and is returned after the organization is submitted to the registry.
PrimaryContact. This is a User object that refers to an authorized user of the registry. A User object normally includes a PersonName object and collections of TelephoneNumber, EmailAddress, and PostalAddress objects.
A collection of Classification objects.
Service objects and their associated ServiceBinding objects.

The following code fragment creates an organization, and specifies its name, description, and primary contact. When a client creates an organization to be published to a UDDI registry, it does not include a key. The registry returns the new key when it accepts the newly created organization.

   // Create organization name and description
   Organization org = 
     blcm.createOrganization("The Coffee Break");
   InternationalString s =
     blcm.createInternationalString("Purveyor of " +
       "the finest coffees. Established 1914");
   org.setDescription(s);

   // Create primary contact, set name
   User primaryContact = blcm.createUser();
   PersonName pName = blcm.createPersonName("Jane Doe");
   primaryContact.setPersonName(pName);

   // Set primary contact phone number
   TelephoneNumber tNum = blcm.createTelephoneNumber();
   tNum.setNumber("(800) 555-1212");
   Collection phoneNums = new ArrayList();
   phoneNums.add(tNum);
   primaryContact.setTelephoneNumbers(phoneNums);

   // Set primary contact email address
   EmailAddress emailAddress = 
     blcm.createEmailAddress("jane.doe@TheCoffeeBreak.com");
   Collection emailAddresses = new ArrayList();
   emailAddresses.add(emailAddress);
   primaryContact.setEmailAddresses(emailAddresses);

   // Set primary contact for organization
   org.setPrimaryContact(primaryContact);

Adding Classifications

The previous tip noted that organizations commonly belong to one or more classifications based on one or more classification schemes (taxonomies). To establish a classification for an organization using a taxonomy, the client first locates the taxonomy it wants to use. It uses the BusinessQueryManager to find the taxonomy. The findClassificationSchemeByName method takes a set of FindQualifier objects as its first argument, but this argument can be null.

   // Set classification scheme to NAICS
   ClassificationScheme cScheme = 
     bqm.findClassificationSchemeByName(null, "ntis-giv:naics");

The client then creates a classification using the classification scheme, and a concept (a taxonomy element) within the classification scheme. For example, the following code sets up a classification for the organization within the NAICS taxonomy. The second and third arguments of the createClassification method are the name and the value of the concept.

   // Create and add classification
   Classification classification =
     blcm.createClassification(cScheme,
     "Snack and Nonalcoholic Beverage Bars", "722213");
   Collection classifications = new ArrayList();
   classifications.add(classification);
   org.addClassifications(classifications);

Services also use classifications, so you can use similar code to add a classification to a Service object.

Adding Services and Service Bindings to an Organization

Most organizations add themselves to a registry in order to offer services. So the JAXR API has facilities to add services and service bindings to an organization.

Like an Organization object, a Service object has a name, a description, and a unique key that is generated by the registry when the service is registered. It can also have classifications associated with it.

A service also commonly has service bindings, which provide information about how to access the service. A ServiceBinding object normally has a description, an access URI, and a specification link that provides the linkage between a service binding and a technical specification. A technical specification describes how to use the service by using the service binding.

The following code fragment shows how to create a collection of services, add service bindings to a service, and then add the services to the organization. It specifies an access URI, but not a specification link. Because the access URI is not real, and because JAXR, by default, checks for the validity of any published URI, the binding sets its validateURI property to false.

   // Create services and service
   Collection services = new ArrayList();
   Service service = blcm.createService("My Service Name");
   InternationalString is = 
     blcm.createInternationalString("My Service Description");
   service.setDescription(is);

   // Create service bindings
   Collection serviceBindings = new ArrayList();
   ServiceBinding binding = blcm.createServiceBinding();
   is = blcm.createInternationalString("My Service Binding " +
     "Description");
   binding.setDescription(is);
   // allow us to publish a fictitious URI without an error
   binding.setValidateURI(false);
   binding.setAccessURI("http://TheCoffeeBreak.com:8080/sb/");
   serviceBindings.add(binding);

   // Add service bindings to service
   service.addServiceBindings(serviceBindings);

   // Add service to services, then add services to organization
   services.add(service);
   org.addServices(services);

Publishing an Organization

The primary method a client uses to add or modify organization data is the saveOrganizations method. This method creates one or more new organizations in a registry if they did not exist previously. If one of the organizations exists, but some of the data has changed, the saveOrganizations method updates and replaces the data.

After a client populates an organization with the information it wants to make public, it saves the organization. The registry returns the key in its response, and the client retrieves it.

   // Add organization and submit to registry
   // Retrieve key if successful
   Collection orgs = new ArrayList();
   orgs.add(org);
   BulkResponse response = blcm.saveOrganizations(orgs);
   Collection exceptions = response.getException();
   if (exceptions == null) {
     System.out.println("Organization saved");

     Collection keys = response.getCollection();
     Iterator keyIter = keys.iterator();
     if (keyIter.hasNext()) {
       javax.xml.registry.infomodel.Key orgKey =
         (javax.xml.registry.infomodel.Key) keyIter.next();
       String id = orgKey.getId();
       System.out.println("Organization key is " + id);
     }
   }

Publishing a Specification Concept

A service binding can have a technical specification that describes how to access the service. An example of such a specification is a WSDL document. To publish the location of a service's specification (if the specification is a WSDL document), you create a Concept object and then add the URL of the WSDL document to the Concept object as an ExternalLink object.

Consider the following example. First, you call the createConcept method to create a concept named HelloConcept. After setting the description of the concept, you create an external link to the URL of the Hello service's WSDL document. Then you add the external link to the concept.

   Concept specConcept = 
     blcm.createConcept(null, "HelloConcept", "");
   InternationalString s =
     blcm.createInternationalString(
       "Concept for Hello Service");
   specConcept.setDescription(s);
   ExternalLink wsdlLink = 
     blcm.createExternalLink(
       "http://localhost:8080/hello-jaxrpc/hello?WSDL",
       "Hello WSDL document");
   specConcept.addExternalLink(wsdlLink);

Next, you classify the Concept object as a WSDL document. To do this for a UDDI registry, you search the registry for the well-known classification scheme uddi-org:types. (The UDDI term for a classification scheme is tModel.) Then you create a classification using the name and value wsdlSpec. Finally, you add the classification to the concept.

   String schemeName = "uddi-org:types";
   ClassificationScheme uddiOrgTypes =
     bqm.findClassificationSchemeByName(null, schemeName);

   Classification wsdlSpecClassification = 
       blcm.createClassification(uddiOrgTypes,
       "wsdlSpec", "wsdlSpec");
   specConcept.addClassification(wsdlSpecClassification);

Finally, you save the concept using the saveConcepts method, similarly to the way you save an organization:

   Collection concepts = new ArrayList();
   concepts.add(specConcept);
   BulkResponse concResponse = blcm.saveConcepts(concepts);

After you publish the concept, you normally add the concept for the WSDL document to a service binding. To do this, you can retrieve the key for the concept from the response returned by the saveConcepts method. The code for retrieving the key is similar to that of finding the key for a saved organization:

   String conceptKeyId = null;
   Collection concExceptions = concResponse.getExceptions();
   javax.xml.registry.infomodel.Key concKey = null;
   if (concExceptions == null) {
     System.out.println("WSDL Specification Concept saved");

     Collection keys = concResponse.getCollection();
     Iterator keyIter = keys.iterator();
     if (keyIter.hasNext()) {
       concKey =
         (javax.xml.registry.infomodel.Key) keyIter.next();
       conceptKeyId = concKey.getId();
       System.out.println("Concept key is " + conceptKeyId);
     }
   }

Then you can call the getRegistryObject() method to retrieve the concept from the registry:

   Concept specConcept = 
     (Concept) bqm.getRegistryObject(conceptKeyId,
       LifeCycleManager.CONCEPT);

Next, you create a SpecificationLink object for the service binding, and set the concept as the value of its SpecificationObject:

   SpecificationLink specLink = 
     blcm.createSpecificationLink();
   specLink.setSpecificationObject(specConcept);
   binding.addSpecificationLink(specLink);

Now when you publish the organization with its service and service bindings, it also publishes a link to the WSDL document. The organization can then be found through queries, such as those described in the previous tip.

If the concept was published by someone else, and you don't have access to the key, you can find it using its name and classification. The code is similar to the code used to search for a WSDL document through a JAXR query. The difference is that you also create a collection of name patterns, and include that in your search. Here is an example:

   // Define name pattern
   Collection namePatterns = new ArrayList();
   namePatterns.add("HelloConcept");

   BulkResponse br = bqm.findConcepts(null, namePatterns, 
     classifications, null, null);

Removing Data from the Registry

You can remove any data from a registry that you have submitted. You use the key returned by the registry as an argument to one of the BusinessLifeCycleManager delete methods, such as deleteOrganizations, deleteServices, deleteServiceBindings, or deleteConcepts.

   String id = key.getId();
   System.out.println("Deleting organization with id " + id);
   Collection keys = new ArrayList();
   keys.add(key);
   BulkResponse response = blcm.deleteOrganizations(keys);
   Collection exceptions = response.getException();
   if (exceptions == null) {
     System.out.println("Organization deleted");
     Collection retKeys = response.getCollection();
     Iterator keyIter = retKeys.iterator();
     javax.xml.registry.infomodel.Key orgKey = null;
     if (keyIter.hasNext()) {
       orgKey =
         (javax.xml.registry.infomodel.Key) keyIter.next();
       id = orgKey.getId();
       System.out.println("Organization key was " + id);
     }
   }

You can use a similar mechanism to delete concepts, services, and service bindings.

Example

The example for this tip uses JAXR to publish content to the Service Registry 3.0 Early Access release provided with the Java Web Services Developer Pack (Java WSDP) 1.6. The Service Registry implements ebXML 3.0 specifications as well as UDDI 3.0.

Getting Started

To use the Service Registry, you need to start the Sun Java System Application Server. When you start the Application Server, it automatically starts both the Service Registry and the Xindice database.

If you haven't already done so, download and install the 2005 Q2 Release of the Sun Java System Application Server Platform Edition 8.1. Then install Java WSDP 1.6. After you install Java WSDP, restart the Application Server. Then open a web browser to the admin console (http://localhost:4848/). In the admin console, look under the "Web Applications" link for a web application named of "soar". Ensure that the web application is running.

Starting the Web Console

Start the Web Console for the Service Registry. The Web Console is a web-based user interface that allows you to search and publish content to the Registry. To start the Web Console, open a web browser to http://localhost:8080/soar. You should see the Web Console welcome screen.

regwelcome

Creating a Registry Account

Before you can publish content to the Registry, you need to create a registry account. However in this Early Access Release of the Service Registry user registration is disabled. In the future, you'll need to click on the "Create User Account" link on the welcome page to create an account. In the Early Access Release, all users have the identity RegistryOperator, and can publish to the registry without user authentication. Because everyone is authenticated, you should exercise this power with care, and delete only objects that you created.

Publishing to the Registry

The sample code for this tip (ttjul2005jaxr.jar) contains the source code for a program that uses JAXR to publish content to the Service Registry. It also includes a build.xml file to be used with an ant script to compile and run the program.

Download the sample code and unjar it. Then edit the build.xml file to reference the registry home inside of the JWSDP 1.6, as well as the Application Server home. The values in the build.xml file are initially set to:

   <property name="registry.home" 
      value="C:/Sun/jwsdp-1.6/registry" />
   <property name="container.home" value="C:/Sun/AppServer/" />

Next, compile and run the JAXR update program by entering the following:

   ant run

You should see output similar to the following:

   run:
     [java] Query URL is http://localhost:8080/soar/registry/soap
     [java] Publish URL is http://localhost:8080/soar/registry/soap
     [java] Created connection to registry
     [java] Got registry service, query manager, and 
     life cycle manager
     [java] Set AccessURI
     [java] Created ExtrinsicObject from MyHelloService.wsdl
     [java] Concept value: WSDL
     [java] Classification scheme is ObjectType
     [java] Set object type to WSDL
     [java] Set MIME type to text/xml
     [java] Set SpecificationObject for SpecificationLink
     [java] Hello Service saved
     [java] Service key is urn:uuid:
     7c769453-58a6-49f4-bbf3-85c6ce7f1a05

BUILD SUCCESSFUL
Total time: 13 seconds

Verifying the Update

You can verify the update by returning to the Web Console and using the Search option. Select a predefined Basic Query, and reset the Object Type to __Service. Then press the Search button. If the update was successful, you should see an entry for JAX-RPC Hello Service in the listing.

regobs

For more information about performing registry updates with JAXR, see the Java Web Services Developer Pack 1.6 Tutorial.

Back to Top

	THE JAVA APPLICATION VERIFICATION KIT FOR THE ENTERPRISE, PART 2

The June 22, 2005 Tech Tip, The Java Application Verification Kit for the Enterprise described how to use the Java Application Verification Kit for the Enterprise (AVK) to perform static testing of an application suite's source files and descriptors. An application suite consists of the EAR files, WAR files, and other deployment units that comprise the application to be verified.

After you use the AVK to perform static testing, you can also use it to perform runtime testing. Runtime testing determines the proportion of enterprise bean component methods, web services methods, and web components that are invoked by running an application. The following tip shows how to use the AVK to perform runtime testing. The tip is based on information in the Java Application Verification Kit (AVK) for the Enterprise User's Guide. An online version of the User's Guide is available. You can also find the User's Guide in the docs directory of AVK distribution.

If you haven't already done so, download the AVK distribution from the Java Application Verification Kit (AVK) for the Enterprise page, and install it. At this point, you should perform static testing on the pertinent application suite.

Next, start the Java Application Server with instrumentation turned on. The installation process for the AVK modifies the server configuration files to enable instrumentation. As a result, when you start the Application Server, instrumentation is enabled. To start the Application Server, use the asadmin start-domain command, specifying the name of the domain that you want to start. You can find the command in the appserver/bin directory below the AVK installation directory. (When you install the AVK, you have the option of installing an application server with the AVK, or using one that is already installed. This tip assumes that you installed the Application Server with your AVK.) You can optionally use the --verbose option to display the server log output:

   asadmin start-domain --verbose domain1

For database access, you can use the PointBase database that is part of the Application Server. It has a preconfigured Java Database Connectivity (JDBC) resource and connection pool. See the Sun Java System Application Server Platform Edition 8.1 Developer's Guide for details on using the JDBC API for database access. If your application uses a database, you'll need to start the database now.

Create Resources for the Application Suite

If your application uses server resources (for example, JDBC resources or Java Message Service (JMS) resources and destinations, you'll need to create those resources. You can use the Admin Console Application Server or the asadmin command to create these resources. To use the Admin Console, open the URL http://localhost:4848/ in a browser. Enter your administrative username and password (created when you installed the Application Server).

Before you deploy your application, you should open each module in the Application Server deployment tool and verify that the runtime information required by the Application Server is correct. Much of this information consists of the Java Naming and Directory Interface (JNDI) API names of any resources used by the application.

Remember that for each entity bean in your application suite, you will likely need to generate database tables. Again, you can use the PointBase database that comes with the Application Server. It has a preconfigured JDBC connection pool called PointBasePool and a preconfigured JDBC resource called jdbc/PointBase. You can use this resource or create your own resource administratively using the Admin Console. If you have a database that needs to be prepopulated with data, the simplest way to do this is to create an Ant task.

Deploy the Application Suite and Create an Exclude List for Component Libraries

The next step is to deploy the application suite. By default, the AVK reporting tool processes all deployed EAR files and standalone modules, assuming that they are part of the same application suite. Normally, you should undeploy any modules that are not part of the application suite that you are verifying.

Often, however, an application suite includes component libraries that are used by the application, but are not part of it. These libraries generally come from another vendor, and have already been verified. You can configure the AVK to exclude these libraries, or modules within them, from the runtime verification process.

To exclude some or all of an application from verification, go to the directory where you installed the AVK, and edit the <exclude-list> element in the file config/appVerification/AppExcludeList.xml. The <exclude-list> element indicates which application or component of the application must be excluded. For example, suppose that the application suite to be tested contains two EAR files, WombatApp.ear and KangarooApp.ear. Suppose too that WombatApp.ear contains the following modules:

ejb1.jar 
ejb2.jar 
web1.war 
web2.war

And KangarooApp.ear contains the following modules:

ejb3.jar 
ejb4.jar 
web3.war 
web4.war

To exclude all of KangarooApp from the verification process, you specify the following:

   <exclude-list>
        <j2ee-app>
            <name>KangarooApp</name>
        </j2ee-app>
   </exclude-list>

To exclude only two components of KangarooApp, ejb3.jar and web4.war, you specify the following:

   <exclude-list>
        <j2ee-app>
            <name>KangarooApp</name>
            <ejb-bundle>
                <name>ejb3.jar</name>
            </ejb-bundle>
            <web-bundle>
                <name>web4.war</name>
            </web-bundle>
        </j2ee-app>
   </exclude-list>

Use the ejb-app or web-app tag to specify a standalone EJB JAR file or web WAR file. For example:

       <ejb-app>
           <name>EjbModule</name>
       </ejb-app>
       <web-app>
           <name>WebModule</name>
       </web-app>

For more details, you can find the DTD for AppExcludeList.xml in the file dtds/application-verification-app-exclude_1_4.dtd in the AVK distribution.

When you make entries in the AppExcludeList.xml file, you don't specify a file extension for standalone module names (such as EAR files, EJB JAR files, or WAR files). However, you do need to provide a .jar or .war file extension for an EJB JAR or web WAR file contained within an application.

Execute the Application Suite

After you deploy the application suite, you run it to invoke as much of its functionality as possible. In this step, you either manually or automatically invoke the JavaServer Pages (JSP) pages, servlets, and public EJB methods. When you have finish the execution step, stop the server using the following command, (but do not undeploy the application):

   asadmin stop-domain

This command does several things as the server shuts down. It writes all data collected during the test execution of the application suite to disk. In addition, the server performs introspection on the deployed application suite, and generates the list of J2EE public APIs (including EJB methods and web components).

Run the Reporting Tool

After you execute the application suite, use the following command to run the reporting tool:

   reporttool -result

Note: If you are running on a Windows platform, you will need to update the reporttool.bat file in the bin directory below where you installed the AVK. Look for a line in the file that begins %JAVA_CMD%. Put quotes around %JAVA_CMD%, like this: "%JAVA_CMD%".

The reporting tool compares introspection and instrumentation results and produces reports from that comparison. From the comparison of the results, the reporting tool generates a set of HTML files, and displays the URL of a top-level summary report.

Jul 13, 2005 11:26:07 AM com.sun.enterprise.appverification.
tools.DynamicResultLogger findResult
INFO: staticDirName C:\Sun\javke1.4.1\reporttool\static
Jul 13, 2005 11:26:07 AM com.sun.enterprise.appverification.
tools.DynamicResultLogger findResult
INFO: Comparing instrumentation and introspection results...
Jul 13, 2005 11:26:08 AM com.sun.enterprise.appverification.
tools.DynamicResultLogger findResult
INFO: Generating final results ...
Jul 13, 2005 11:26:10 AM com.sun.enterprise.appverification.
tools.DynamicResultLogger generateSummary
INFO: Verfication results can be found at 
C:\Sun\javke1.4.1\reporttool\results\suiteSummary.html

The HTML pages are generated in the reporttool directory. The top-level summary report is in the reporttool directory, in file results/suiteSummary.html. The summary contains pointers to the results of the static archive tests and code scanning tests, a summary of the EJB method coverage for each module, and a summary of the web component coverage. The reporting tool provides a status of Pass or Fail when summarizing the results.

suitesum

The are two types of coverage reports generated: one for EJB methods, and one for web components.

EJB Method Coverage Reports

EJB method coverage is reported by EAR file or module. The guideline is that at least 80% of the EJB methods within each module must be covered.

The EJB Method Coverage page expands the EAR file or module contents and lists the JAR files and beans in each file, with the coverage. The Methods Called column shows the number of methods called versus the total number of methods for each bean. Clicking on the bean name brings up the EJB Method Coverage Detail page, which displays the status of each method within that bean. The first table contains the methods that were not called successfully. Either those methods were not called at all, or an exception was thrown during the call. The next table shows all methods that were called successfully. This information can be used to determine which methods need to be invoked to increase the coverage to meet the guidelines if the guidelines were not met.

Web Component Coverage Reports

Web component coverage is reported by context. The guideline is that 100% of the JSP pages and servlets must be called with no exceptions generated.

The table on the summary page reports the percentage of the web components that were called. Clicking on either Passed or Failed brings up the Web Component Coverage page, which lists each component by the context root, whether or not it was called, and if so, whether there was an exception. This information can be used to determine which web components must be called to increase the coverage to meet the guidelines.

webcomprpt

The coverage reports do not list JSP pages that are included by other JSP pages using an include directive. Instead, the reports list only the JSP pages that contain the include directives for these pages. JSP pages included with an include action, however, are listed in the coverage reports.

Removing Results and Reports

To remove the results and reports generated by the instrumentation code, run the reporting tool with the -clear_results option:

   reporttool -clear_results

Use this option if an exception was thrown during dynamic checking, and you have fixed the problem. To remove the exception from the results, you must clear all the results.

For more information about the AVK, see the Java Application Verification Kit (AVK) for the Enterprise page.

Back to Top

Comments? Send your feedback on the Tech Tips: http://developers.sun.com/contact/feedback.jsp?category=sdn

Subscribe to the following newsletters for the latest information about technologies and products in other Java platforms:

Core Java Technologies Tech Tips. Get tips on using core Java technologies and APIs, such as those in the Java 2 Platform, Standard Edition (J2SE).
Wireless Developer Tech Tips. Get tips on using wireless Java technologies and APIs, such as those in the Java 2 Platform, Micro Edition (J2ME).

You can subscribe to these and other Java technology developer newsletters or manage your current newsletter subscriptions on the Sun Developer Network Subscriptions page

IMPORTANT: Please read our Terms of Use, Privacy, and Licensing policies:
http://www.sun.com/share/text/termsofuse.html
http://www.sun.com/privacy/
http://developer.java.sun.com/berkeley_license.html

ARCHIVES: You'll find the Enterprise Java Technologies Tech Tips archives at:
http://java.sun.com/developer/EJTechTips/index.html

© 2005 Sun Microsystems, Inc. All Rights Reserved. For information on Sun's trademarks see: http://sun.com/suntrademarks
Java, J2EE, J2SE, J2ME, and all Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.