river-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From peter_firmst...@apache.org
Subject svn commit: r901152 [2/2] - /incubator/river/jtsk/trunk/doc/release-notes/
Date Wed, 20 Jan 2010 12:01:37 GMT
Modified: incubator/river/jtsk/trunk/doc/release-notes/outrigger.html
URL: http://svn.apache.org/viewvc/incubator/river/jtsk/trunk/doc/release-notes/outrigger.html?rev=901152&r1=901151&r2=901152&view=diff
--- incubator/river/jtsk/trunk/doc/release-notes/outrigger.html (original)
+++ incubator/river/jtsk/trunk/doc/release-notes/outrigger.html Wed Jan 20 12:01:35 2010
@@ -26,7 +26,7 @@
 <body text="black" bgcolor="white" link="#9b37cc" vlink="#cc1877" alink="white">
-v2.1.2 Release Notes</h1>
+Apache River v2.1.2 Release Notes</h1>
@@ -47,14 +47,272 @@
 <H3>Changes since the v2.1.1 release</H3>
+<li>[<a href='https://issues.apache.org/jira/browse/RIVER-255'>RIVER-255</a>] -         
+Outrigger DestroyThread does not catch exceptions from exporter.unexport
+<li>[<a href='https://issues.apache.org/jira/browse/RIVER-256'>RIVER-256</a>] -         
+Outrigger catch Throwable blocks should also catch Throwable
+    <H3>Changes since the v2.0.1 release</H3>
+<dt><b>Outrigger Implements the Proposed <code>net.jini.space.JavaSpace05</code>       Extension to JavaSpaces technology</b>
+This version of Outrigger implements the proposed
+<code>net.jini.space.JavaSpace05</code> extension to JavaSpaces
+technology. The <code>JavaSpace05</code> interface extends the
+<code>JavaSpace</code> interface to provide methods that allow clients to
+perform batch operations on the space (which are generally more efficient
+than performing an equivalent set of singleton operations) and to more
+easily develop applications where a given <code>Entry</code> needs to be
+read by multiple clients. See the API documentation for the <code><a
+interface for details.<p>
+<dt><b>New <code>Store</code> Implementation, PSEPro Runtime Classes Not
+Included in Release</b>
+The persistent version of Outrigger relies on a pluggable persistence layer,
+Previous releases included one implementation of the <code>Store</code>
+interface, <a
+This release adds a second implementation, <a
+While all the necessary classes are included with this release to run the
+transient version of Outrigger, or the persistent version using the new
+snaplogstore implementation of <code>Store</code>, the logstore
+implementation of <code>Store</code> requires the runtime classes for
+Progress Software's <i>ObjectStore PSEPro for Java</i>
+(PSEPro). Unfortunately, because of issues relating to the transition in
+licensing, this release does not include the PSEPro runtime classes,
+without which logstore will not work. We are sorry for any inconvenience
+this will cause.  We hope to make a release with a complete version of
+logstore available as a separate download in the future.
+Where v2.0.n releases used logstore as the default <code>Store</code>
+implementation, this release has no default store. In order to switch an
+existing set of configuration files, security policy files, etc., from
+using logstore to snaplogstore, you will need to change the <a
+<code>com.sun.jini.outrigger.store</code></a> configuration entry (or add a
+<code>store</code> if you don't already have one) to yield a
+<code>com.sun.jini.outrigger.snaplogstore.LogStore</code> object. You will
+also need to ensure that <code>outrigger-snaplogstore.jar</code> has been
+granted sufficient permissions (see Outrigger's package <a
+for a sample security policy file.).<p>
+Note that depending on the nature of your application snaplogstore can have
+a significantly different performance profile than logstore.<p>
+The storage formats used by snaplogstore and logstore are mutually
+<dt><b>Incompatible Change Made to <code>Store</code> Interface</b>
+The persistent version of Outrigger relies on a pluggable persistence
+layer, <a
+This release makes incompatible changes to a subsidiary interface, <a
+in order to support the implementation of the <a
+interface. New methods were added and existing methods were changed, so old
+implementations will need to be changed to work with the current
+release, and any implementation that works with the current release will
+need to be changed to work with previous releases.<p>
+Note, we consider the <code>Store</code> and its associated subsidiary
+interfaces to be experimental. They will often change incompatibly between
+releases, and could be removed completely.<p>
+<dt><b>Persistent Store Incompatible with Previous Versions</b>
+As part of implementing <a
+we made incompatible changes to Outrigger's persistent store. The files
+generated by previous releases will not be compatible with this release.
+<dt><b>Network Protocol Incompatible with Previous Versions</b>
+In order to use a more efficient protocol for returning the results of <a
+long)"><code>JavaSpace.write</code></a> calls, the network protocol used to
+communicate between Outrigger's proxy and server was incompatibly
+changed. Note, for most installations this should not cause a problem as
+clients will transparently download the new version of the proxy that uses
+the new protocol.
+<dt><b>The <code>JavaSpaceAdmin</code>,
+<code>ConstrainableJavaSpaceAdmin</code>, and <code>AdminIterator</code>
+Interfaces Have Been Deprecated</b>
+This release deprecates the <code><a
+com.sun.jini.outrigger.JavaSpaceAdmin</a></code> and <code><a
+interfaces. Outrigger's admin proxy still implements
+<code>JavaSpaceAdmin</code> (and if deployed with a Java(TM) Remote Method
+Invocation implementation that supports remote method constraints,
+<code>ConstrainableJavaSpaceAdmin</code>), but it is our intention to stop
+doing so in a future release. The primary function provided by
+<code>JavaSpaceAdmin</code> and <code>ConstrainableJavaSpaceAdmin</code>
+was the creation of <code><a
+instances that could be used to semi-exhaustively read through the contents
+of the space. Similar functionality is now provided through the <code><a
+href="../api/net/jini/space/JavaSpace05.html#contents(java.util.Collection, net.jini.core.transaction.Transaction, long, long)">JavaSpace05.contents</a> </code> method. <p>
+<code>JavaSpaceAdmin</code> extends the <code><a
+and <code><a
+interfaces. It is our intention for Outrigger's admin proxy to continue
+implementing <code>JoinAdmin</code> and <code>DestroyAdmin</code> after
+support for <code>JavaSpaceAdmin</code> is dropped.
+<dt><b>Outrigger's JAR Files Have Been Restructured</b>
+To better support the layering of applications on top of the starter kit
+the starter kit's JAR files, including those related to Outrigger, have
+been restructured. The changes to the server-side files
+(e.g. <code>outrigger.jar</code>, <code>outrigger-logstore.jar</code>,
+etc.) may require changes to the security policy files used for Outrigger
+servers. Permissions must now be granted to <code>jsk-lib.jar</code> in
+addition to Outrigger's other server side JAR files. The changes to
+<code>outrigger-dl.jar</code> have an impact on how Outrigger's codebase is
+specified. Outrigger now requires a multi-element codebase that includes
+both <code>outrigger-dl.jar</code> and <code>jsk-dl.jar</code>. Also note
+that all of the starter kit's "<code>-dl.jar</code>" files, including
+<code>outrigger-dl.jar</code>, have been moved out of the <code>lib</code>
+directory and into the new <code>lib-dl</code> directory.<p>
+For more details on the JAR file changes, please see the note in the Jini
+Technology Starter Kit Release Notes on <a href="new.html#JARchanges">
+JAR file changes</a>.
+For examples on how to start Outrigger and a description of Outrigger JAR
+file structure, please see <a
+package documentation</a>.
+<dt><b>Bug Fixes of Interest</b>
+<dt><b>4754465:Race condition between logging takes and competing queries</b><dt>
+There was a race condition in persistent configurations of Outrigger that
+theoretically allowed the effects of a non-transactional <code>take</code>,
+non-transactional <code>takeIfExists</code>, or entry lease cancellation to
+be made visible before the removal of the entry was made durable. This race
+condition could give rise to scenarios where an entry flits out of, and
+then back into existence. For example:
+<li> If there was a query, <em>Q</em>, that matched the entry
+     <em>E</em>,
+<li> and a concurrent operation, <em>O</em>, that was removing
+     <em>E</em> but the space crashed between the time <em>O</em> removed
+     <em>E</em> and the time <em>E</em>'s removal was made durable
+     then,
+<li> it was possible for <em>Q</em> to return <code>null</code>, implying
+     that <em>O</em> had succeeded, and
+<li> for a future query to return <em>E</em>, implying that <em>O</em>
+     had failed.
+The race condition has been fixed in this release.
+<dt><b>5002184:Blocking calls in server during destroy processing maxes CPU</b>
+The v2.0.n releases had a bug where if there was a blocked query
+in progress when the <a
+method was called, CPU usage would peak for up to two minutes and the
+process of destroying the server would be delayed. This was caused by
+Outrigger making repeated attempts to &#147nicely&#148 unexport the server
+with no pause between attempts. This version addresses this issue by
+introducing a pause between unexport attempts. This delay can be controlled
+using the <a
+configuration entry. This version also introduces the <a
+configuration entry, which can be used to control how long Outrigger will
+attempt nice unexport attempts before giving up and forcefully unexporting
+itself (see the <code>maxUnexportDelay</code> configuration entry for more
+<dt><b>6201948:Outrigger fails to unblock takes when last conflicting read
+lock is prepared</b><dt>
+Previous versions of Outrigger had a bug where Outrigger would not generate
+the correct internal events when an entry was read locked by two
+transactions and one of the transactions was prepared (Note Outrigger would
+generate the proper internal events if one of the two transactions was
+aborted, or if the entry was read locked by only one transaction and that
+transaction was prepared). <p>
+What this meant in practice was that if you had entry, <em>E</em>, read
+locked under two transactions <em>T1</em>, and <em>T2</em> and a blocked
+<code>take</code> (or <code>takeIfExists</code>) under <em>T1</em> whose
+template matched <em>E</em>, then the <code>take</code> would not unblock
+if <em>T2</em> was prepared (the <code>take</code> would unblock if
+<em>T2</em> was aborted) even though the prepare resolved the last
+conflicting transaction. A <code>take</code> (or <code>takeIfExists</code>)
+under <em>T1</em> started after the prepare of <em>T2</em> would function
+properly. The take would also eventually unblock if the <em>maximum server
+query timeout</em> feature was being used.
+<dt><b>6307184:Deadlock between adding entries and iteration</b>
+Previous 2.n versions of Outrigger had a bug where attempts to iterate over the
+space using the <code><a
+or the <code><a
+href="../api/net/jini/space/JavaSpace05.html#contents">net.jini.space.JavaSpace05.contents</a></code> method
+while at the same time writing entries of a type the iteration could return
+would cause a deadlock.  Note, in practice this was much more likely
+to happen with <code>AdminIterator</code> than <code>contents</code>.
+This issue has been fixed in this release.
 Licensed to the Apache Software Foundation (ASF) under one
 or more contributor license agreements.  See the NOTICE file

Modified: incubator/river/jtsk/trunk/doc/release-notes/reggie.html
URL: http://svn.apache.org/viewvc/incubator/river/jtsk/trunk/doc/release-notes/reggie.html?rev=901152&r1=901151&r2=901152&view=diff
--- incubator/river/jtsk/trunk/doc/release-notes/reggie.html (original)
+++ incubator/river/jtsk/trunk/doc/release-notes/reggie.html Wed Jan 20 12:01:35 2010
@@ -34,18 +34,119 @@
 from Sun Microsystems. The specification for the River lookup service is 
 available in <a href="../specs/html/lookup-spec.html">HTML</a>.
-The specification for Reggie is defined not only by the <i>River Lookup Service
+The specification for Reggie is defined not only by the <i>Jini Lookup Service
 Specification</i>, but also by the API documentation (generated by the 
 Javadoc(TM) tool) for <a href="../api/net/jini/admin/Administrable.html">
 <h3>Changes since the v2.1.1 release</h3>
+<li>[<a href='https://issues.apache.org/jira/browse/RIVER-225'>RIVER-225</a>] -         
+NullPointerException in Reggie during destroy
+<li>[<a href='https://issues.apache.org/jira/browse/RIVER-246'>RIVER-246</a>] -         
+Consider adding shutdown hook so Reggie sends final multicast packet if its VM 
+is terminated
+<h3>Changes since the v2.1 release</h3>
+<h3>Changes since the v2.0.1 release</h3>
+    <dt><b>Handling of Evolved Types</b></dt>
+    <dd>
+        Consider the case where service <code>S</code> has been deployed in a
+        network, and <code>S</code> needs to be modified to implement
+        a new interface.  Let's call the modified service <code>S'</code>.
+        In previous versions of Reggie, a client would not find a proxy to
+        <code>S'</code> when doing a lookup by the new interface unless
+        the <code>S'</code> proxy class was renamed.  This version of Reggie
+        allows a client to find a proxy to <code>S'</code> when doing a
+        lookup by the new interface, even if the name of the proxy class has
+        not been changed and there are instances of <code>S</code> already
+        registered.<p/>
+    </dd>
+    <dt><b>Reuse of Multicast Announcements</b></dt>
+    <dd>
+        Reggie now reuses multicast announcements when there are no changes
+        in host, port, or group information in order to minimize the expense of
+        signing announcement packets in deployments that have been configured
+        to use secure discovery.<p/>
+    </dd>
+    <dt><b>Delayed Verification of Multicast Requests</b></dt>
+    <dd>
+        Reggie also delays verifying signatures on multicast requests until
+        it can determine that it must reply to the request.  This minimizes
+        the expense of verifying signatures in deployments configured with
+        secure discovery.<p/>
+    </dd>
+    <dt><b>Socket Connection Timeout when Replying to a Multicast
+        Request</b></dt>
+    <dd>
+        This version of Reggie allows a deployer to specify a timeout to be
+        applied when establishing a connection to the multicast response
+        server of a client attempting to discover Reggie.  The timeout can
+        be specified by adding a
+        <a href="../api/net/jini/core/constraint/ConnectionRelativeTime.html">
+        <code>ConnectionRelativeTime</code></a> constraint to Reggie's
+        <code>discoveryConstraints</code>.  For information on additional
+        constraints supported by Reggie, refer to
+        <a href="../api/com/sun/jini/reggie/package-summary.html">
+        <code>Reggie's manual pages</code></a>
+        <p/>
+    </dd>
+    <dt><b>Modifications to Reggie's Proxies</b></dt>
+    <dd>
+        Reggie's
+        <a href="../api/net/jini/core/lookup/ServiceRegistrar.html">
+        <code>ServiceRegistrar</code></a>,
+        <a href="../api/net/jini/core/lookup/ServiceRegistration.html">
+        <code>ServiceRegistration</code></a>,
+        <a href="../api/net/jini/core/lease/Lease.html">
+        <code>Lease</code></a>, and admin proxies now override
+        <code>java.lang.Object.toString()</code> to facilitate debugging by
+        providing additional information, like Reggie's
+        <a href="../api/net/jini/core/lookup/ServiceID.html">
+        <code>ServiceID</code></a> and underlying Java (TM) Remote Method
+        Invocation (Java RMI) stub.<p/>
+        The communication protocol used between Reggie and its main proxy
+        has been modified to enable handling of evolved types.  This new
+        protocol is not compatible with that of earlier releases.<p/>
+    </dd>
+    <dt><b>Log File Format</b></dt>
+    <dd>
+        The log file format used by the persistent version of Reggie in this
+        release is not compatible with that of earlier releases.<p/>
+    </dd>
+    <dt><b>Bug Fixes</b></dt>
+    <dd>
+        <ul>
+            <li>
+                <i>4939735 - Reggie doesn't refresh self-registration on
+                restart</i><br/>
+                The persistent version of reggie no longer stores its
+                self-registration; rather, the self-registration is recreated
+                each time reggie is restarted to allow for configuration or
+                export changes to be reflected in the proxy reggie registers
+                with itself.
+            </li>
+            <li>
+                <i>5002218 - Reggie should properly handle remote calls that
+                arrive before initialization is complete</i><br/>
+                Calls that arrive while reggie is in the process
+                of initializing will now block until reggie has completed its
+                initialization.  Calls that arrive after reggie has commenced
+                its shutdown process will now result in a
+                <code>java.rmi.NoSuchObjectException</code>.
+            </li>
+        </ul>
+    </dd>
 <!-- No issues for now

Modified: incubator/river/jtsk/trunk/doc/release-notes/security.html
URL: http://svn.apache.org/viewvc/incubator/river/jtsk/trunk/doc/release-notes/security.html?rev=901152&r1=901151&r2=901152&view=diff
--- incubator/river/jtsk/trunk/doc/release-notes/security.html (original)
+++ incubator/river/jtsk/trunk/doc/release-notes/security.html Wed Jan 20 12:01:35 2010
@@ -25,7 +25,7 @@
-v2.1.2 Release Notes</h1>
+Apache River v2.1.2 Release Notes</h1>
@@ -35,7 +35,7 @@
 <code>net.jini.security</code></a> package and its subpackages provide
 abstractions and facilities for managing security.
-<H3>Changes since the v2.0.1 release</H3>
+<H3>Changes since the v2.1.1 release</H3>
@@ -43,6 +43,61 @@
+<H3>Changes since the v2.0.1 release</H3>
+<dt><b>New proxy preparer</b></dt>
+<p>A new proxy preparer class,
+<a href="../api/net/jini/security/VerifyingProxyPreparer.html">
+<code>VerifyingProxyPreparer</code></a>, has been added. In contrast to
+<a href="../api/net/jini/security/BasicProxyPreparer.html">
+<code>BasicProxyPreparer</code></a>, this new preparer always verifies that
+proxies are trusted, and permits full control over the context elements used
+during trust verification, the class loader used to find trust verifiers,
+and the principals used to scope dynamic permission grants. In particular,
+it can be used to specify a
+<a href="../api/net/jini/security/proxytrust/BasicUntrustedObjectSecurityContext.html">
+<code>BasicUntrustedObjectSecurityContext</code></a> context element for
+controlling the operation of
+<a href="../api/net/jini/security/proxytrust/ProxyTrustVerifier.html">
+<code>ProxyTrustVerifier</code></a> (see below).
+<a name="verification">
+<dt><b>Trust verification restriction</b></dt></a>
+<p><a href="../api/net/jini/security/proxytrust/ProxyTrustVerifier.html">
+<code>ProxyTrustVerifier</code></a> has been changed so that, by default,
+when attempting to obtain a bootstrap proxy, operations on untrusted objects
+are performed in a restricted security context that limits the permissions
+of unprivileged code (meaning code that does not use some form of
+<code>doPrivileged</code>) to just the permissions that have been
+granted to all code. In most cases this default will not cause problems,
+but there are cases where it will. In particular, if you are trying to
+verify a proxy that uses activation, and a remote call to activate the
+service is required to obtain the bootstrap proxy, the remote call will
+now fail due to lack of a <code>SocketPermission</code> (unless you have
+granted broad <code>connect</code> <code>SocketPermission</code> to all code,
+which is generally undesirable). To make such a deployment work, you need
+to provide a
+<a href="../api/net/jini/security/proxytrust/BasicUntrustedObjectSecurityContext.html">
+<code>BasicUntrustedObjectSecurityContext</code></a> context element that
+specifies which additional permissions unprivileged code is permitted to
+exercise (provided the code has already been granted those permissions).
+This is aimed in particular at specifying the permissions that local code
+(or already trusted code) is permitted to exercise. For example, you would
+specify <code>SocketPermission</code> to connect to whatever hosts and ports
+can be used for activation. You can use
+<a href="../api/net/jini/security/VerifyingProxyPreparer.html">
+<code>VerifyingProxyPreparer</code></a> (see above) to specify such a
+context element.
 Licensed to the Apache Software Foundation (ASF) under one

Modified: incubator/river/jtsk/trunk/doc/release-notes/servicediscovery.html
URL: http://svn.apache.org/viewvc/incubator/river/jtsk/trunk/doc/release-notes/servicediscovery.html?rev=901152&r1=901151&r2=901152&view=diff
--- incubator/river/jtsk/trunk/doc/release-notes/servicediscovery.html (original)
+++ incubator/river/jtsk/trunk/doc/release-notes/servicediscovery.html Wed Jan 20 12:01:35 2010
@@ -24,8 +24,8 @@
 <title>Jini Service Discovery Utilities Release Notes</title>
-<h1>River Service Discovery Utilities
-  <BR>v2.1.2 Release Notes
+<h1>Jini Service Discovery Utilities
+  <BR>River v2.1.2 Release Notes
@@ -34,22 +34,448 @@
 The class
 <a href="../api/net/jini/lookup/ServiceDiscoveryManager.html"> <code>net.jini.lookup.ServiceDiscoveryManager</code></a>
-is a utility class that can be used to help a River technology-enabled 
-service or client (<i>River service</i> or <i>River client</i>) 
+is a utility class that can be used to help a Jini technology-enabled 
+service or client (<i>Jini service</i> or <i>Jini client</i>) 
 acquire services of interest that are registered with lookup services 
 with which the service or client wishes to interact.
 The specification for the
 <a href="../api/net/jini/lookup/ServiceDiscoveryManager.html"> <code>ServiceDiscoveryManager</code></a>
-utility is contained in the  <i>River Service Discovery Utilities Specification</i>, 
+utility is contained in the  <i>Jini Service Discovery Utilities Specification</i>, 
 which is available in <a href="../specs/html/servicediscutil-spec.html">html</a>.
 <H3>Changes since the v2.0.1 release</H3>
+<li>[<a href='https://issues.apache.org/jira/browse/RIVER-324'>RIVER-324</a>] -         
+Under certain circumstances, the ServiceDiscoveryManager internal LookupCache 
+implementation can incorrectly  process attribute change events before the 
+lookup snapshot is processed.
+<H3>Changes since the v2.0.1 release</H3>
-  <dt> <b>None</b>
+  <dt> <b>Configuration</b>
+  <dd> In this release, no new configuration entries have been added, nor have any other
+       changes occurred with respect to the configuration.
+       <p>
+       A full list of supported configuration entries is given in this utility's
+       <a href="../api/net/jini/lookup/ServiceDiscoveryManager.html#sdmConfigEntries"> class documentation</a>.
+       <p>
+  <dt> <b>Logging</b>
+  <dd> In this release, no changes have occurred with respect to the logging mechanism
+       employed by the service discovery manager implementation, which logs diagnostic information to the
+       <a href="http://java.sun.com/j2se/1.4/docs/api/java/util/logging/Logger.html"> <code>Logger</code></a>
+       named <code>net.jini.lookup.ServiceDiscoveryManager</code>. For a description of the
+       information that is logged, as well as the associated logging levels, refer to the
+       <a href="../api/net/jini/lookup/ServiceDiscoveryManager.html#sdmLogging"> class documentation</a>.
+       <p>
+  <dt> <b>Bug Fixes of Interest</b>
+  <dd> A number of bugs have been addressed in this release of the
+       service discovery manager. What follows is a description of those
+       bugs that might be of interest:
+  <p>
+  <dt><b>4972100: SDM NPE in getServiceItems when blocking lookup called before
+filter is applied</b><dt>
+  <dd> When one of the blocking versions of the <code>lookup</code> method is
+       invoked, there are conditions in which a <code>NullPointerException</code>
+       can occur. One possible scenario in which this bug can occur is as follows:
+  SDM creates cache ----- RegisterListenerTask(wait for events)
+                          LookupTask begins
+                            get snapshot (lookup state)
+                            -- done --
+       *** start targetted service ***
+                          NOMATCH_MATCH event received
+                          NotifyEventTask (process event)
+                          NewOldServiceTask (new service)
+                            addToMap -- (item,null)
+exit wait
+call cach.lookup()
+                            filterMaybeDiscard()
+map(item,null) ===> NPE
+                              filter -- map(item,filteredItem)</code></pre>
+       If the timing is right, <code>getServiceItems</code> can be entered
+       before the filter is applied and the non-<code>null</code>
+       <code>filteredItem</code> is placed in the map. If this occurs,
+       <code>getServiceItems</code> will attempt to access
+       <code>filteredItem.srvc</code>, which will result in a
+       <code>NullPointerException</code>.
+  </dd>
+  <p>
+  <dt><b>5102733: SDM cache.notifyServiceMap does not use event ID in its decision process</b><dt>
+  <dd> Prior to this release, in the method
+       <code>ServiceDiscoveryManager.LookupCacheImpl.notifyServiceMap</code>,
+       only the sequence number of the new event and the sequence number stored
+       in the <code>EventReg</code> element of the <code>eventRegMap</code> were       compared when determining whether or not there is a "gap" in the event
+       sequence; in which case, a snapshot would be requested from the associated
+       lookup service. This could result in multiple unnecessary snapshots being       requested; and thus, unnecessary network traffic and resource usage.
+       <p>
+       To understand how this problem could occur, consider the following scenario:
+<pre>1 activatable lookup service registered with Phoenix (or RMID)
+4 services registered with that lookup service
+1 client using a cache to discover the services
+>>> phoenix -stop (or rmid -stop) to stop the lookup service
+>>> all 4 services eventually discard the lookup service
+>>> the client eventually discards the lookup service
+>>> restart phoenix (or rmid) before 30 minutes have expired
+    (to restart the lookup service and recover its state before
+    the client's original event registration [E0] has a chance
+    to expire)</pre>
+       When the client rediscovers the lookup service, its cache requests
+       a new event registration [E1]. But the lookup service still has E0
+       in its state.
+       <p>
+       When the services rediscover the lookup service, they reregister with
+       the lookup service, and the lookup service sends a serviceAdded
+       (<code>NOMATCH_MATCH</code>) event to both E0 and E1 for each of the
+       services. The cache's event listener receives both sets of events.
+       <p>
+       Prior to fixing this bug, <code>notifyServiceMap</code> only analyzed the       sequence numbers of the events. It did not distinguish which event
+       registration each event corresponded to. Because E0 was recovered after
+       the lookup service went down and was restarted, the sequence numbers
+       of the events sent to that registration were greater than
+       <code>Integer.MAX_VALUE</code>, which resulted in a "gap" in the sequence so
+       that clients would know that they might have missed events. Because E1 was
+       not interrupted by a shutdown/restart, its sequence numbers started at 0.       Thus, when serviceAdded events arrived for E0 and for E1, the sequence
+       looked something like the following to <code>notifyServiceMap</code>:
+<pre>event 0 --> Service0 added: Event ID = 0 - seq# 2147483650
+event 1 --> Service0 added: Event ID = 1 - seq# 0
+event 2 --> Service1 added: Event ID = 0 - seq# 2147483651
+event 3 --> Service1 added: Event ID = 1 - seq# 1
+event 4 --> Service2 added: Event ID = 0 - seq# 2147483652
+event 5 --> Service2 added: Event ID = 1 - seq# 2
+event 6 --> Service3 added: Event ID = 0 - seq# 2147483653
+event 7 --> Service3 added: Event ID = 1 - seq# 3</pre>
+       Because <code>notifyServiceMap</code> did not consider the event ID,
+       it appeared to <code>notifyServiceMap</code> that it was receiving a
+       stream of events in which the sequence numbers looked like:
+<pre>{ 2147483650, 0, 2147483651, 1, 2147483652, 2, 2147483653, 3 }</pre>
+       To <code>notifyServiceMap</code>, the sequence appeared to be
+       alternately "moving backward" and "moving forward" with a large
+       gap. In each case though, <code>notifyServiceMap</code> interpreted
+       the difference between sequence numbers as a gap; that is,
+<pre>(if event_(n+1)_seq# != 1 + event_n_seq#, then a gap is declared).</pre>
+       Thus, as each event was received, <code>notifyServiceMap</code>
+       declared a gap, and a new snapshot was requested; which meant that for
+       the four services, there were eight total snapshots requested.
+       To address this bug, the method <code>notifyServiceMap</code> was
+       modified to consider the event ID when determining whether or not
+       an event sequence contains a gap; which now results in the appropriate
+       behavior.
+  </dd>
+  <p>
+  <dt><b>6208587: SDM should create default LDM only when no DiscoveryManagement is configured</b><dt>
+  <dd> Prior to interrogating the configuration for a
+       <a href="../api/net/jini/discovery/DiscoveryManagement.html"> <code>DiscoveryManagement</code></a>
+       item (entry name = <b><i>discoveryManager</i></b>), a default
+       <a href="../api/net/jini/discovery/LookupDiscoveryManager.html"> <code>LookupDiscoveryManager</code></a>
+       is first created. Although that manager is initialized to discover no groups and no locators,
+       the <a href="../api/net/jini/discovery/LookupDiscovery.html"> <code>LookupDiscovery</code></a>
+       instance used by the default discovery manager to perform group discovery creates
+       a thread to listen for and process multicast announcements, as well as
+       additional, related threads. Thus, if a deployer configures a <i>discoveryManagement</i>
+       item, the creation of the default lookup discovery manager -- and the threads
+       that manager ultimately creates -- is unnecessary, and wastes resources.
+       <p>
+       This bug has been fixed.
+  </dd>
+  <p>
+  <dt> <b>Notes Of Interest</b>
+  <dd>
+       <p>
+       <b>Note 1: Service Reference Comparison</b>
+       <p>
+       The ability to appropriately compare two different service references
+       is very important to the
+       <a href="../api/net/jini/lookup/ServiceDiscoveryManager.html"> <code>ServiceDiscoveryManager</code></a>
+       in general, and the
+       <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a>
+       in particular. Currently, there are three mechanisms used to accurately
+       compare service references. Each mechanism is applied in different situations,
+       to achieve different goals.
+       <p>
+       When storing and managing service references, it is important to be able
+       to determine when two different references (proxies) refer to the same
+       back-end service (such references are referred to as <i>duplicates</i>)
+       so that the storage and management of any duplicate references can be
+       avoided. In addition to identifying duplicate references, the ability to
+       determine when a previously discovered service has been replaced with a
+       new version is also important so that consistent state may be maintained,       and entities that wish to know about such events can be informed.
+       Finally, when an entity wishes to discard (make eligible for rediscovery)
+       a particular service reference received from the
+       <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a>,
+       it is important for the <code>LookupCache</code> to be able to compare the
+       reference provided by the entity to each of the previously stored references
+       so that the appropriate reference can be accurately selected for discard.       <p>
+       <b>Comparison by <a href="../api/net/jini/core/lookup/ServiceID.html"> <code>net.jini.core.lookup.ServiceID</code></a></b>
+       <p>
+       To identify, and thus avoid storing, duplicate service references, the
+       <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a>
+       compares the instances of <a href="../api/net/jini/core/lookup/ServiceID.html"> <code>ServiceID</code></a>
+       associated with each reference. Recall that an individual well-behaved service of
+       interest will usually register with multiple lookup services, and for
+       each lookup service with which that service registers, the
+       <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a>
+       will receive a separate event containing a reference to the service. When the
+       <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a>
+       receives events from multiple lookup services, the
+       <a href="../api/net/jini/core/lookup/ServiceID.html"> <code>ServiceID</code></a>
+       (retrieved from the service reference in the event) is used to distinguish the
+       service references from each other. In this way, when a new event arrives containing
+       a reference associated with the same service as an already-stored reference,
+       the <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a>
+       can determine whether or not the new reference is a duplicate; in which case, the
+       duplicate is ignored.
+       <p>
+       <b>Comparison by <a href="../api/net/jini/io/MarshalledInstance.html"> <code>net.jini.io.MarshalledInstance.fullyEquals</code></a></b>
+       <p>
+       With respect to determining when a previously discovered service has been
+       replaced with a new version, the <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a> typically relies
+       on the event mechanism of the lookup service(s) with which that service is
+       registered to indicate that such an event has occurred. But there are
+       situations where the events from the lookup services do not provide enough
+       information to make such a determination. In those cases, the
+       <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a> employs
+       <a href="../api/net/jini/io/MarshalledInstance.html"> <code>MarshalledInstance.fullyEquals</code></a>
+       to make the determination.
+       <p>
+       When a well-behaved service is replaced with a new version, the new
+       version is typically reregistered with each lookup service with
+       which the old version is registered. As described in the
+       <a href="../specs/html/lookup-spec.html"><i>Jini(TM) Lookup Service Specification</i></a>,
+       each lookup service with which this reregistration process occurs first
+       sends a service-removed event (<code>TRANSITION_MATCH_NOMATCH</code>), and
+       then sends a separate service-added event (<code>TRANSITION_NOMATCH_MATCH</code>).
+       In this case, there is no ambiguity, and thus no need for the
+       <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a>
+       to compare the new and old service references. This is because the
+       combination of service-removed and service-added events from each
+       lookup service is an explicit indication that the service has been
+       replaced. Note that, as described in the specification, the lookup
+       service only sends a service-changed event (<code>TRANSITION_MATCH_MATCH</code>)
+       when the attributes of the service have been modified; not when the
+       service itself has been changed (replaced). Thus, if the
+       <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a>
+       receives a <code>TRANSITION_MATCH_MATCH</code> event, then it is guaranteed
+       that the service referenced in that event has not been replaced with a new
+       version.
+       <p>
+       Whenever the following conditions are satisfied, the <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a>
+       will use <a href="../api/net/jini/io/MarshalledInstance.html"> <code>MarshalledInstance.fullyEquals</code></a>
+       to compare two service references:
+       <p>
+         <ul>
+           <li> The references are duplicates (same <a href="../api/net/jini/core/lookup/ServiceID.html"> <code>ServiceID</code></a>)
+           <li> The <b><i>possibility</i></b> exists that the references may refer to different versions of the service
+         </ul>
+       <p>
+       When determining whether or not these conditions (in particular, the
+       second condition) are satisfied, the <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a> generally
+       takes a conservative approach. That is, only when it is absolutely
+       sure that two duplicates refer to the same version (such as when a
+       <code>TRANSITION_MATCH_MATCH</code> event is received), will the
+       <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a>
+       refrain from using
+       <a href="../api/net/jini/io/MarshalledInstance.html"> <code>MarshalledInstance.fullyEquals</code></a>
+       to compare the duplicate references; otherwise, duplicate references are
+       always compared using
+       <a href="../api/net/jini/io/MarshalledInstance.html"> <code>MarshalledInstance.fullyEquals</code></a>.
+       <p>
+       One example of a situation where the <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a>
+       employs <a href="../api/net/jini/io/MarshalledInstance.html"> <code>MarshalledInstance.fullyEquals</code></a>
+       is the situation
+       where a lookup service of interest is newly discovered or rediscovered.
+       In this situation, the <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a>
+       retrieves a snapshot of the services of interest that currently reside in that
+       lookup service. This is done so that previously undiscovered service references,
+       as well as new versions of previously discovered service references, can
+       both be stored, duplicates can be ignored, and clients can be sent the
+       appropriate notifications. Whenever a reference from the snapshot is a
+       duplicate of a previously discovered service reference, the
+       <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a>
+       always compares the two references using
+       <a href="../api/net/jini/io/MarshalledInstance.html"> <code>MarshalledInstance.fullyEquals</code></a>.
+       This is because the possibility always exists that the references may refer to different
+       versions of the service.
+       <p>
+       Another example of a situation where the
+       <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a>
+       employs <a href="../api/net/jini/io/MarshalledInstance.html"> <code>MarshalledInstance.fullyEquals</code></a>
+       is when a <code>TRANSITION_NOMATCH_MATCH</code> event is received that
+       contains a reference that is a duplicate of a previously discovered
+       reference. When such an event is received, the
+       <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a>
+       must allow for the possibility that the reference contained
+       in the event refers to a different version of the service
+       than that referenced by the previously discovered service reference.
+       This is because the event may represent either the second half of a
+       (remove/add) event pair, or it may be a notification of the initial
+       registration of a new version of the service with one of the (multiple)
+       lookup services targeted by the
+       <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a>
+       during the service discovery process.
+       <p>
+       To understand the last example described above, consider the situation
+       where a service initially registers with one lookup service and then
+       registers with a second lookup service. If the same version of the
+       service is registered with each lookup service, both lookup services
+       will send the same event -- a <code>TRANSITION_NOMATCH_MATCH</code>
+       event -- to indicate that a new service has registered with the
+       associated lookup service. In this case, there is no ambiguity for the
+       <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a>;
+       the second reference can be safely ignored because the references are
+       duplicates that refer to the exact same service.
+       <p>
+       But suppose that prior to registering with the second lookup service,
+       the service is replaced with a new version. In that case, the second
+       lookup service will still send a <code>TRANSITION_NOMATCH_MATCH</code> event, but
+       if the appropriate action is not taken to determine that the old version
+       of the service has been replaced, the new version of the service will
+       be ignored by the <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a>.
+       This is because the two references will have the same
+       <a href="../api/net/jini/core/lookup/ServiceID.html"> <code>ServiceID</code></a>,
+       and thus the <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a>
+       will identify the two references as duplicates; ultimately ignoring the new reference.
+       Of course, if the service is well-behaved, because the new version of the service will
+       eventually reregister with the first lookup service, that lookup service
+       eventually send a <code>TRANSITION_MATCH_NOMATCH</code> event followed by a
+       <code>TRANSITION_NOMATCH_MATCH</code> event to indicate that the service
+has been
+       replaced. But the <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a>
+       must still identify and handle this situation in order to prevent possible state
+       corruption, even though that corruption may be only temporary.
+       <p>
+       Thus, whenever a <code>TRANSITION_NOMATCH_MATCH</code> event is received
+and the
+       associated service reference is a duplicate of a previously discovered
+       reference, the <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a>
+       will always compare the two references using
+       <a href="../api/net/jini/io/MarshalledInstance.html"> <code>MarshalledInstance.fullyEquals</code></a>
+       to determine whether or not the references refer to the same version of the service.
+       When they do reference the same version, the
+       <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a>
+       ignores the duplicate reference; otherwise, the
+       <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a>
+       sends a service-removed event followed by a service-added event to indicate
+       that the old version of the service has been replaced.
+       <p>
+       <b>Comparison by <a href="http://java.sun.com/j2se/1.4/docs/api/java/lang/Object.html#equals"> <code>equals</code></a></b>
+       <p>
+       The mechanism employed by the <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a> to select (from
+       storage) a given reference for discard is the
+       <a href="http://java.sun.com/j2se/1.4/docs/api/java/lang/Object.html#equals"> <code>equals</code></a>
+       method provided by the discovered service itself. The
+       <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a>
+       relies on the provider of each service to override the
+       <a href="http://java.sun.com/j2se/1.4/docs/api/java/lang/Object.html#equals"> <code>equals</code></a>
+       method with an implementation that allows
+       for the identification of the service reference an entity wishes to
+       be discarded. Although the default implementation of
+       <a href="http://java.sun.com/j2se/1.4/docs/api/java/lang/Object.html#equals"> <code>equals</code></a>
+       often times may be sufficient for proper identification, service providers
+       are still encouraged to provide each service with its own well-defined
+       implementation of <a href="http://java.sun.com/j2se/1.4/docs/api/java/lang/Object.html#equals"> <code>equals</code></a>.
+       <p>
+       In addition to the
+       <a href="http://java.sun.com/j2se/1.4/docs/api/java/lang/Object.html#equals"> <code>equals</code></a>
+       method, each service should also
+       provide a proper implementation of the
+       <a href="http://java.sun.com/j2se/1.4/docs/api/java/lang/Object.html#hashCode"> <code>hashCode</code></a> method.
+       This is because references to the service may be stored in, or interact with,
+       container classes (for example,
+       <a href="http://java.sun.com/j2se/1.4/docs/api/java/util/HashMap.html"> <code>HashMap</code></a>)
+       where the service's <a href="http://java.sun.com/j2se/1.4/docs/api/java/lang/Object.html#equals"> <code>equals</code></a>
+       and <a href="http://java.sun.com/j2se/1.4/docs/api/java/lang/Object.html#hashCode"> <code>hashCode</code></a>
+       methods may be invoked "under the covers" by the container object with
+       which the service is interacting. From the point of view of the
+       <a href="../api/net/jini/lookup/ServiceDiscoveryManager.html"> <code>ServiceDiscoveryManager</code></a>
+       and the <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a>,
+       providing an appropriate implementation for both the
+       <a href="http://java.sun.com/j2se/1.4/docs/api/java/lang/Object.html#equals"> <code>equals</code></a>
+       method and the
+       <a href="http://java.sun.com/j2se/1.4/docs/api/java/lang/Object.html#hashCode"> <code>hashCode</code></a>
+       method is a key characteristic of good behavior in a Jini service.
+       <p>
+       <b>Note 2: The Service Discovery Filtering Mechanism</b>
+       <p>
+       The specification of the
+       <a href="../api/net/jini/lookup/ServiceItemFilter.html"> <code>ServiceItemFilter</code></a>
+       interface specifies what it means to <i>filter</i> a service reference selected as a
+       candidate for discovery. In particular, instances of
+       <a href="../api/net/jini/lookup/ServiceItemFilter.html"> <code>ServiceItemFilter</code></a>
+       can be defined to perform proxy preparation. Thus, through the client-defined filter
+       (through the
+       <a href="../api/net/jini/lookup/ServiceItemFilter.html#check"> <code>check</code></a>
+       method), clients can request that the
+       <a href="../api/net/jini/lookup/ServiceDiscoveryManager.html"> <code>ServiceDiscoveryManager</code></a>,
+       rather than the client itself, perform any desired proxy preparation
+       as part of the service discovery process.
+       <p>
+       To understand why this is important, consider what can happen when
+       the client performs preparation of its discovered proxies outside of the
+       <a href="../api/net/jini/lookup/ServiceDiscoveryManager.html"> <code>ServiceDiscoveryManager</code></a>.
+       When proxy preparation is performed outside of the service discovery
+       manager, the client risks encountering a cycle where a matching service is
+       discovered by the
+       <a href="../api/net/jini/lookup/ServiceDiscoveryManager.html"> <code>ServiceDiscoveryManager</code></a>,
+       is found to be untrusted when the client prepares the proxy, is discarded       by the client because it is untrusted, and is then ultimately rediscovered
+       because it still matches the original discovery criteria. Such a cycle
+       will generally repeat indefinitely because the service is not likely to
+       become trusted at any point in the future. Supplying the
+       <a href="../api/net/jini/lookup/ServiceDiscoveryManager.html"> <code>ServiceDiscoveryManager</code></a>
+       with the means to perform proxy preparation on the client's behalf
+       provides the client with a mechanism for avoiding such a cycle.
+       <p>
+       For more information, please refer to the section titled,
+       <i>SD.5.2 The <code>ServiceItemFilter</code> Interface</i>, contained in
+       <a href="../specs/html/servicediscutil-spec.html"><i>Jini(TM) Service Discovery Utilities Specification</i></a>.
+       <p>
+       <b>Note 3: The Service Discovery Event Mechanism</b>
+       <p>
+       The specification of the
+       <a href="../api/net/jini/lookup/ServiceDiscoveryListener.html"> <code>ServiceDiscoveryListener</code></a>
+       interface describes how the filtering mechanism and the event mechanism provided by instances of
+       <a href="../api/net/jini/lookup/LookupCache.html"> <code>net.jini.lookup.LookupCache</code></a>
+       interact.
+       <p>
+       Additionally, this specification specifies that instances of the
+       <a href="../api/net/jini/lookup/LookupCache.html"> <code>LookupCache</code></a>
+       use the method
+       <a href="../api/net/jini/io/MarshalledInstance.html"> <code>net.jini.io.MarshalledInstance.fullyEquals</code></a>
+       to determine when a service has changed in some fundamental way (for example,
+       when a service is replaced with a new version).
+       <p>
+       For more information, please refer to the section titled,
+       <i>SD.5.4 The <code>ServiceDiscoveryListener</code> Interface</i>, contained in the
+       <a href="../specs/html/servicediscutil-spec.html"><i>Jini(TM) Service Discovery Utilities Specification</i></a>
+       <p>
 <!-- No issues for now

Modified: incubator/river/jtsk/trunk/doc/release-notes/servicestarter.html
URL: http://svn.apache.org/viewvc/incubator/river/jtsk/trunk/doc/release-notes/servicestarter.html?rev=901152&r1=901151&r2=901152&view=diff
--- incubator/river/jtsk/trunk/doc/release-notes/servicestarter.html (original)
+++ incubator/river/jtsk/trunk/doc/release-notes/servicestarter.html Wed Jan 20 12:01:35 2010
@@ -25,7 +25,7 @@
-v2.1.2 Release Notes</h1>
+Apache River v2.1.2 Release Notes</h1>
@@ -39,6 +39,79 @@
   <dt> <b>None</b></dt>
+<H3>Changes since the v2.0.1 release</H3>
+  <dt> <b>Bug Fixes of Interest</b></dt>
+  <dd> The following bugs have been addressed in this release:
+  <p>
+  <dl>
+  <dt><b>
+      4835830: Add per-service proxy preparer support
+      </b></dt>
+  <dd>Per-service proxy preparer support has been added to
+      <code>NonActivatableServiceDescriptor</code> and
+      <code>SharedActivatableServiceDescriptor</code> via constructor
+      overloads that take proxy preparer parameters. This allows users
+      to individually prepare the service proxies returned by service
+      starter framework.
+      <P>
+  <dt><b>
+      4856937: Service starter should permit specifying dynamic policy provider
+      </b></dt>
+  <dd><code>ActivateWrapper</code> supports the
+      the <code>java.security.Security</code> property
+      <code>com.sun.jini.start.servicePolicyProvider</code>, which allows users
+      to specify the fully qualified class name of a dynamic policy provider to
+      use for wrapping individual service policies in a "shared" environment.
+      A custom service policy provider can be very useful when trying to
+      debug security related issues. See the start package documentation for
+      more detail.
+      <P>
+  <dt><b>
+      4858623: change ExportClassLoader to use context class loader for parent
+      </b></dt>
+  <dd><code>ActivateWrapper.ExportClassLoader</code> now uses the calling context's
+      class loader as its parent (versus the application classpath, used previously).
+      This allows "container" applications more control over the class loader
+      hierarchy used when launching services.
+      <P>
+  <dt><b>
+      6211452: change ActivateWrapper.ExportClassLoader to subclass PreferredClassLoader
+      </b></dt>
+  <dd><code>ActivateWrapper.ExportClassLoader</code> now extends
+      <code>PreferredClassLoader</code> instead of <code>URLClassLoader</code>.
+      A service can now specify a preferred list for its import class path,
+      to ensure that any classes that need to be annotated with the server's
+      codebase get loaded by the server's class loader rather than accidentally
+      being resolved in the container.
+      <P>
+  <dt><b>
+      4868839: Make utility class constructors private
+      </b></dt>
+  <dd>The following utility classes simply contain static methods and
+      are not meant to be instantiated:
+      <UL>
+      <LI><code>ClassLoaderUtil</code>
+      <LI><code>DestroySharedGroup</code>
+      <LI><code>HTTPDStatus</code>
+      </UL>
+      To ensure this, private constructors have been added to each of the
+      above classes.
+      <P>
+  <dt><b>
+      4936006: ServiceDescriptor's should support non-file-based classpath entries
+      </b></dt>
+  <dd>The <code>importCodebase</code> parameter in the constructors for
+      <code>NonActivatableServiceDescriptor</code> and
+      <code>SharedActivatableServiceDescriptor</code> now support either:
+      <UL>
+      <LI>a space delimited set of <code>URL</code>(s) representing a codebase or
+      <LI>a <code>File.pathSeparator</code> delimited set of class paths.
+      <UL>
+      <P>
 <!-- N/A
 <H3>Known Issues (& Workarounds)</H3>

View raw message