Fiddler
v2.1.2 Release Notes

The specification for Fiddler is defined not only by the River Lookup Discovery Service Specification, but also by the API documentation (generated by the Javadoc(TM) tool) for com.sun.jini.fiddler.FiddlerAdmin and net.jini.admin.Administrable.

Changes since the v2.1.1 release

Changes since the v2.1 release

None

Changes since the v2.0.1 release

Configuration

In this release, no new configuration entries have been added, nor have any other changes occurred with respect to the configuration.

A full list of supported configuration entries is given in this service's man page.

Logging

In this release, no changes have occurred with respect to the logging mechanism employed by Fiddler; which logs diagnostic information using a separate Logger for each type of information logged. The name of each logger is a dot-separated concatenation of the implementation package name, com.sun.jini.fiddler, with a descriptive string. A description of each logger used by this service, as well as what information is logged to which logger, and at what logging level, is given in this service's man page.

Bug Fixes of Interest

A number of bugs have been addressed in this release of Fiddler. What follows is a description of those bugs that might be of interest:

4874580: FiddlerImpl throws NullPointerException in prepareNewLocators if locs is null

When calling the register method, if null is passed as the value of the locators parameter, a NullPointerException occurs.

This bug has been fixed.

4979612: Fiddler relies on LookupLocator.equals to determine interest in discovered Regs

When Fiddler searches through its set of client registrations to determine if any of those registrations are interested in a particular previously discovered lookup service, it compares the locators of interest from each registration to the locator that is returned by a call to getLocator on the discovered lookup service. That comparison is done using LookupLocator.equals.

LookupLocator.equals employs a case-insensitive string compare of the host names of the locators to determine equality. Thus, if one locator is associated with a hostname of "myHost", and the other locator is associated with a fully qualified hostname like "myHost.myCompany.com", LookupLocator.equals will return false, and Fiddler will view as different, locators that should actually be considered the same.

To address this bug, the implementation in this release now employs the same strategy that URL currently employs. That is, it first applies LookupLocator.equals (to do a case-insensitive string compare). If the call to LookupLocator.equals returns false, then the IP addresses associated with each locator are retrieved and compared to determine equality.

4984939: Fiddler threads should guard against lost interrupts

Thread subclasses in Fiddler that use logging and do not override the Thread.interrupt method to set an "interrupted" field are susceptible to lost interrupts. This is because java.util.logging swallows internal InterruptedIOExceptions without setting the receiving thread's interrupted status; effectively 'forgetting' the interrupt that occurred. The end result is that some of Fiddler's threads could endlessly loop instead of terminate, causing shutdown processing in Fiddler to hang.

This bug has been fixed.

5042473: FiddlerImpl.SetLocatorsTask handles NO_LOCATORS incorrectly

Prior to this release, when a client requested that locator discovery be "turned off" by requesting the replacement of a registration's locators-of-interest with the empty set (through an invocation of the setLocators method), the result was the opposite of what the specification prescribes. That is, the locators-of-interest were not replaced at all.

This bug has been fixed.

5049735: Fiddler should properly handle remote calls that arrive before init completes

Prior to this release, Fiddler contained no logic to ensure that remote calls received before initialization completes would be handled properly. Problems could occur, for example, if an instance of Fiddler is run with a well-known endpoint that was used (and advertised) by a previous instance of Fiddler.

To address this issue, Fiddler now handles such "early" calls by blocking until initialization completes.

6226306: Fiddler should allow null loginContext config entry, performing no JAAS login when null

Prior to this release, if Fiddler's configuration included a loginContext entry, Fiddler would require that entry to be non-null; throwing an exception if a null value were entered. (Note that if the entry were simply absent from the configuration, Fiddler interpretted this as an indication that no JAAS login should be performed.)

To address this issue, Fiddler now interprets a null value for the loginContext entry, as well as an absent entry, as an indication that a JAAS login should not be performed.

Notes Of Interest

Fiddler Has 3 Modes of Execution

• Transient - Fiddler does not persist its state and is not activatable
• Nonactivatable - Fiddler does persist its state but is not activatable
• Activatable - Fiddler persists its state and is activatable

For details, see the com.sun.jini.fiddler package documentation.