All qa suite tests are now passing
All jtreg tests that are known to pass are passing (those that depend on
a Kerberos Domain server and Squid do not as expected).
To address concurrency,the issue of threads starting during service
server construction (River-418), a new interface has been created:
com.sun.jini.start.Starter
Any service that uses the start package can now delay starting of
threads until construction is complete. This prevents services from
becoming visible to other threads before construction is complete, for
compliance with the JMM.
All services except for Fiddler and Norm have been converted to use
Starter, remaining services will be updated in River 2.3.1
A JIRA issue for each service will be created to document progress on
Starter conversion.
Security Infrastructure changes:
1. org.apache.river.api.security.ConcurrentPolicyFile - copied
from Apache Harmony and refactored for immutable concurrency,
all implies permission checks are performed thread confined to
avoid synchronization issues with PermissionCollection
implementations. PermissonCollection's are not shared among
threads. Permissions are granted to Principals and CodeSource
signed by Certificate and / or by URI, not URL, this avoids
consulting DNS to determine URL identity.
2. net.jini.security.policy.DynamicPolicyProvider has been
reimplemented.
Changes to Policy.getPermissions(CodeSource codesource) semantics:
The contract for Policy.getPermissions changed in Java 6:
<quote>
getPermissions
public PermissionCollection getPermissions(CodeSource codesource)
Return a PermissionCollection object containing the set of
permissions granted to the specified CodeSource.
Applications are discouraged from calling this method since this
operation may not be supported by all policy implementations.
Applications should solely rely on the implies method to perform
policy checks. If an application absolutely must call a
getPermissions method, it should call
getPermissions(ProtectionDomain).
The default implementation of this method returns
Policy.UNSUPPORTED_EMPTY_COLLECTION. This method can be
overridden if the policy implementation can return a set of
permissions granted to a CodeSource.
Parameters:
codesource - the CodeSource to which the returned
PermissionCollection has been granted.
Returns:
a set of permissions granted to the specified CodeSource. If
this operation is supported, the returned set of permissions
must be a new mutable instance and it must support heterogeneous
Permission types. If this operation is not supported,
Policy.UNSUPPORTED_EMPTY_COLLECTION is returned.
</quote>
DynamicPolicy grants are no longer included when
getPermissions(CodeSource codesource) is called, instead the method
delegates to the underlying encapsulated base policy.
ConcurrentPolicyFile getPermissions(CodeSource codesource) is
implemented to return either privileged Permissions (CodeSource's
granted AllPermission), or UNSUPPORTED_EMPTY_COLLECTION. This is
purely a performance optimisation, allowing
ProtectionDomain.implies(Permission permission) to return early for
privileged ProtectionDomain's without consulting the Policy provider.
Changes to ClassLoader infrastructure regarding codebase annotations:
1. URL is no longer used as a Key in Collections. This changes
ClassLoading semantics slightly:
1. Codebase annotations will be normalised as URI according to
RFC3986 and compared for equality, remote code with
identical codebases annotations will share a URLClassLoader.
2. Previously codebases with different annotations would share
a URLClassLoader if they resolved to the same IP address.
This made firewall traversal and codebase replication
difficult and also prevented the use of dynamically assigned
IP addresses for codebase servers.
2. A new class org.apache.river.api.net.Uri has been provided to
implement RFC3986 compliance, it was copied from Apache Harmony
and updated to strictly comply with RFC3986. This new class does
not support Serializable and is final and immutable. It can be
serialized in it's string form and reconstructed remotely by
passing a string to its constructor. It has identical method
signatures to java.net.URI. Originally java.net.URI was utilised,
however while it implements RFC2396 and RFC2732, it doesn't
strictly comply and allows additional characters that should be
escaped in RFC2396, this means that a strictly compliant RFC2396
URI in normalized for may not be equal to a java.net.URI. In
addition java.net.URI didn't support escaped characters in host
names, which would prevent registered domains from some Locales
from being used in codebase strings.
3. URL and URN are both URI, previously only URL's were legal, so the
expanded form also allows URN to be utilised legally as codebase
annotations, this includes Rio's maven artifact URN scheme.
4. PreferredClassLoader no longer lazily loads the preferred list,
instead this is loaded during construction.
While these seem like huge semantic changes, the end result is codebase
annotations will still resolve to their correct ClassLoader as they
always have, but instead of using DNS to determine an IP addresses (in
the case of http and httpmd URL's), identity will be based on the
RFC3986 normalized form of the codebase string. The ClassLoader will
still use URL providers for resolving codebases. For the real oddball
case, where a developer expects three separate domain codebase
annotations to resolve to the same IP address and use the same
ClassLoader, that won't work anymore.
This won't be rushed out the door, plenty of time will be allowed for
testing.
