GETTING MORE HELP

• Where can I get more help?
• What information should I send when requesting help?

OVERVIEW

What is the Jini(TM) Technology Core Platform Compatibility Kit?

The Jini(TM) Technology Core Platform Compatibility Kit (TCK) is one of the essential software tools required to qualify an implementation of Jini technology for commercial use and for use of the Jini logo. The TCK consists of a test harness, a suite of conformance tests, and associated documentation.

Why should I use the TCK to test my product?

The TCK is a free test suite that helps to ensure that your Jini technology-enabled client, service, or lookup service (hereafter referred to as "product") complies with some very basic, but critical, Jini specification requirements. Furthermore, signing the Jini Technology Commercial License requires that your product pass the TCK test suite. For more information see http://www.sun.com/jini/licensing/licenses.html and Passing the TCK document found in the TCK download.

Where can I get the TCK?

The TCK is available from http://www.sun.com/software/communitysource/jini/download.html.

RUNNING THE TCK

Which version of the TCK should I use?

For the 120 days following a new release of the TCK, you may use either the TCK version being replaced (which you must already have in your possession) or the new TCK version (which is available for download) to fulfill the TCK-related requirements of the Sun(TM) Community Source License (SCSL) for your Jini products. After 120 days from the most recent TCK release date, you must use the new TCK version for all compliance requirements.

Which SDK and operating system should I use to test my product?

While you may use Java(TM) 2 SDK, v1.2.2 or later on any operating system configuration, we recommend that you use a platform on which the TCK has been tested if you encounter problems. These tested platforms are listed in the installation instructions of the TCK documentation.

Which TCK tests (or test categories) must I pass?

You must run all the tests in all the categories that apply to your product. For example, if your product is a Jini technology-enabled service (Jini service) that also acts as a Jini technology-enabled client (Jini client), then you'll need to run both the client and service tests against your product to be considered compliant. If your product is a Jini lookup service that also acts as a Jini service (registers in other lookups), then you'll need to run both the service and lookup tests against your product. The tests contained in each category are:

com.sun.jini.tck.test.RequestPacketTest
com.sun.jini.tck.test.UnicastRequestTest
com.sun.jini.tck.test.CodeDownloadTest
com.sun.jini.tck.test.AnnouncementResponseTest
com.sun.jini.tck.test.RegistrationTest
com.sun.jini.tck.test.MultipleRegistrationTest
com.sun.jini.tck.test.PublicGroupTest
com.sun.jini.tck.test.NonPublicGroupTest
com.sun.jini.tck.test.MultipleGroupTest
com.sun.jini.tck.test.LeaseTest

com.sun.jini.tck.test.RequestPacketTest
com.sun.jini.tck.test.UnicastRequestTest
com.sun.jini.tck.test.CodeDownloadTest

com.sun.jini.tck.test.LookupByServiceIDTest
com.sun.jini.tck.test.LookupByClassTest
com.sun.jini.tck.test.LookupBySuperClassTest
com.sun.jini.tck.test.LookupByInterfaceTest
com.sun.jini.tck.test.MultipleServiceLeaseRenewalTest
com.sun.jini.tck.test.ServiceLeaseExpirationTest
com.sun.jini.tck.test.ServiceIDTest
com.sun.jini.tck.test.MultipleEventLeaseRenewalTest
com.sun.jini.tck.test.EventLeaseExpirationTest

On which platforms do I have to pass the TCK?

You must pass the TCK on at least one platform that supports Java 2 SDK, v1.2.2 or later. Which platform you use is entirely your choice.

Does every possible configuration of my service need to pass the TCK?

To pass the TCK, Jini clients, services, and lookup services must be able to abide by the TCK good citizenship requirements, such as discovering and joining only lookup services in the "public" group. It is not required that every possible configuration be capable of passing the TCK, nor is it required that the default configuration be capable of passing; it is simply required that at least one configuration be capable of passing. If your service implementation uses the net.jini.lookup.JoinManager to handle Jini discovery and join functions, this requirement of the TCK should be easily met.

What is an "official run" of the TCK?

An official run of the TCK is a single execution of the TCK test suite that meets certain requirements. These requirements are described in Passing the TCK, Section 2.1, found in the TCK download.

How long does it take to run the TCK?

A successful official run of the three TCK client tests should take approximately five minutes. A successful official run of the ten TCK service tests should take approximately three hours. A successful official run of the nine TCK lookup tests should take approximately one hour.

How can I shorten these test times for experimental and debugging purposes?

The TCK configuration file contains a commented-out property, com.sun.jini.tck.unofficialQuietTime, that can be used to reduce the wait time used by most tests. For an official run, the default value of 1800000 milliseconds (30 minutes) or greater must be used for this property. However, for purposes of experimentation and debugging, you can reduce this to something smaller, such as 60000 milliseconds (one minute). Once you have resolved any problems, you must comment out this property to perform an official TCK run. This property is further documented in the TCK test descriptions and property file.

How can I automate TCK testing for my product?

To automate the TCK testing for your product, you must implement your own specialized Admin object. See the next section of this FAQ for more information on how to implement your own Admin.

TCK ADMINS

What is an "Admin"?

An "Admin" is an object that is responsible for starting and stopping the product you are testing. The TCK comes with three default Admins (one each for clients, services, and lookup services), which simply ask you to start and stop your product at the appropriate times determined by each test.

Can I implement my own Admin object?

Yes! In fact it may be necessary to implement your own Admin in certain circumstances where the supplied default Admins do not work for your product. In addition, if you wish to automate TCK testing of your product, you will need to implement your own, specialized Admin object to start and stop your product automatically. To help you get started, the TCK download includes, as examples, the Admins used to automatically test the services found in the Jini(TM) Technology Starter Kit, v1.2.1_01 and v2.0. See the API docs and source files for the com.sun.jini.tck.admin1 and com.sun.jini.tck.admin2 packages in the TCK download.

How do I implement my own Admin object?

See Writing a TCK Admin, found in the TCK download.

COMMON PROBLEMS

What are some things to watch out for when running the TCK?

• Make sure rmid is started on the machine on which you are running the TCK.
• Make sure no HTTP server is using port 8080 on the machine on which you are running the TCK (the HTTP server started by the TCK uses port 8080).
• If your product contains downloadable classes, you must run your own HTTP server to support the downloading of these classes.
• Make sure that the directory you specified in the configuration file as the value of the com.sun.jini.tck.scratchDir is in the correct format for the operating system on which you are testing and that you have permission to write to the specified directory.
• Make sure that the paths in the TCK configuration file use the correct file separator format (for example, two backslashes '\\' on Microsoft Windows platforms).
• If you are using the DefaultServiceAdmin, make sure you are selecting the correct service from the list that is displayed by the TCK's DefaultServiceAdmin.
• If you suspect you are having codebase problems, pass the property -Dcom.sun.jini.tck.reggie.proxy.debug=true to the TCK virtual machine (VM) (you may also find the -Dnet.jini.discovery.debug=true helpful). If codebase is the problem, you will see one or more exceptions that should help you determine the problem.

TROUBLESHOOTING

The following questions and answers assume that you are familiar with the TCK test designs in the Jini Technology Core Platform Compatibility Kit Test Descriptions document found in the TCK download.

Why do fail (or get a NullPointerException) when I run the RegistrationTest or the MultipleRegistrationTest?

possible cause

Service packaging problem

detail

If the service being tested specifies an attribute in the entry registered with the lookup service but the service's codebase does not include the attribute class, then the TCK will fail to download the attribute class.

solution

In general, the service's downloadable JAR files should contain ALL classes that a client might require because the service provider has no control over the CLASSPATH used by the service's client (in this case the TCK).

My service doesn't appear to register with the TCK lookup (or when I use the DefaultServiceAdmin, my service is not in the list displayed by the TCK)

possible cause

The java.rmi.server.codebase property value that you specified for your service is incorrect.

detail

The DefaultServiceAdmin of the TCK is acting like a Jini client, and as such is trying to obtain the proxy for the service you are testing from the TCK lookup service. In order to do so, the TCK must have access to your service's classes.

solution

To verify that this is the problem, pass the property -Dcom.sun.jini.tck.reggie.proxy.debug=true to the TCK virtual machine (VM) (you may also find the -Dnet.jini.discovery.debug=true helpful). If the codebase is the problem, you will see one or more exceptions that should help you determine the problem.

Why am I failing a TCK test with "java.io.IOException: Could not create directory" or "java.io.IOException: The filename, directory name, or volume label syntax is incorrect"?

possible cause

The path you specified for the TCK property com.sun.jini.tck.scratchDir is the wrong format for the operating system on which you are testing or you do not have permission to write to the specified directory.

solution

Make sure that the directory you specified in the configuration file as the value of the com.sun.jini.tck.scratchDir is in the correct format for the operating system on which you are testing and that you have permission to write to the specified directory.

Why am I failing the PublicGroupTest?

possible cause

Your service is not registering with the "public" lookup service group.

detail

The Jini Core Platform Specification, Section DJ.3.2.1, says the service "should" default to using the "public" group. The TCK was designed to verify that Jini services act as 'good citizens', and one of our decisions about what makes up a good citizen is that the service must be capable of joining the "public" group. The PublicGroupTest is the test which verifies this behavior.

solution

To pass this test, you must make it possible to configure your service and clients to perform multicast discovery for at least the "public" group.

Why am I failing the NonPublicGroupTest?

possible cause

Your service registers in ALL_GROUPS.

detail

The test is designed to check for this behavior because your service should NOT register in ALL_GROUPS.

solution

Modify your service to not register with ALL_GROUPS.

possible cause

An identical service that registers in ALL_GROUPS is running on the network. You selected that service from the list displayed by the TCK's DefaultServiceAdmin.

detail

The TCK lookup service will allow registrations from any service on the network that specifies the group to which the lookup service belongs. Thus, a service that registers with ALL_GROUPS will always register in the TCK lookup service. It could be possible that an identical service to the one you are testing is running on the network and is registering with the TCK lookup service by joining ALL_GROUPS.

solution

Be very careful to select the service that you are testing or "None of the above" from the list displayed by the TCK's DefaultServiceAdmin. The class annotation of your service's proxy is included in the list and should help you determine which service is the one you are testing. The annotation will contain the IP address or name of the machine where you started your HTTP server for your services downloadable code.

possible cause

When using the TCK's DefaultServiceAdmin you inadvertently selected a service, that is not the one you are testing, from the pick list instead of "None of the above."

detail

For a well-behaved Jini service, the service should not join the TCK lookup service started by this test. Therefore, if the service you are testing is well-behaved, it should not appear in the list displayed by the TCK's DefaultServiceAdmin. So, in this case, you should select "None of the above" from the list.

solution

If the service you are testing doesn't appear in the list, select "None of the above".

possible cause

Your service uses a lookup locator that discovers the lookup service on the default port on the local host.

detail

In this configuration, locator discovery will find the TCK lookup service, even though it belongs to a randomly named group.

solution

Change your service so that the use of the hardcoded lookup locator is configurable and can be turned off for TCK testing. Alternatively, run the service on a different host than you run the TCK. The TCK config file provides the com.sun.jini.tck.defaultAdmin.address property, which can be set to support this.

My service uses a dynamic proxy and I'm using the TCK's DefaultServiceAdmin. When I'm presented with the list of services, how do I know which one is mine?

The DefaultServiceAdmin constructs each list element using the string form of the proxy's class name and the proxy's class annotation. The dynamic proxy's class name probably starts with $Proxy and careful examination of the class annotation should help you determine which service is the one you are testing.

When I run TCK v1.2A, why do I get a NullPointerException at line 438 of com.sun.jini.tck.harness.AbstractRunner.java? (BugID: 4663695)

possible cause

TCK classpath problem

detail

If you are using a custom Admin for the service being tested then the TCK must have any classes required by your Admin in the TCK's classpath. This is reported as a NullPointerException due to a bug in com.sun.jini.tck.harness.AbstractRunner (BugID: 4663695)

solution

The TCK's classpath must include the class files required by your service's Admin. In general, these should be the same classes required by a client of your service (such as service interfaces). This bug is fixed in TCK v2.0A.

Why is my service failing the com.sun.jini.tck.test.CodeDownloadTest?

possible cause

Service started in TCK's VM

detail

The TCK starts a lookup service in another VM and downloads the lookup service proxy JAR file when it unmarshals the proxy. If you are using a custom Admin for the service being tested and your Admin starts your service in the same VM as the TCK then your service won't download the lookup service proxy JAR file again (since it is already cached in the VM). Thus your service fails the test.

solution

Custom Admins must not start services in the same VM as the TCK.

GETTING MORE HELP

Where can I get more help?

For private technical questions, comments, and suggestions, email the engineers responsible for developing and maintaining the TCK at jinitck-questions@sun.com.

For more information on the legal aspects of the TCK, outlined in the SCSL, please look at http://www.sun.com/jini/licensing.

What information should I send when requesting help?

When requesting help from jinitck-questions@sun.com, it is important that you send the output obtained from running the TCK with debugging information turned on (set com.sun.jini.tck.debugLevel=all in the TCK configuration file). Additionally, describe the client, service, or lookup service that you are testing and the problem you are encountering.