See
http://archives.java.sun.com/cgi-bin/wa?A2=ind0608&L=jini-users&P=R7915&I=-3
and an existing RFE in the Sun bug database
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6190433

I have modified my version of PreferredClassProvider and added the
following method to it that provides the requested hook, although I'm
not satisfied so I would like to get some input.

/**
 * Indicates whether a class with the specified codebase annotation
 * <code>URL</code>s is defined within the specified class loader,
 * for the purpose of deciding whether the class originated from the
 * <code>defaultLoader</code> or that the class is considered a
 * 'class boomerang'.
 * <p>
 * This implementation will consider a class to be defined in the
 * specified class loader when the codebase annotation for that class
 * loader matches the <code>URL</code>s passed in.
 *
 * @param urls annotation <code>URL</code>s that serve as the codebase
 *        for the class being loaded
 * @param loader class loader for which must be verified whether it
 *        represents the class loader from which a class with the
 *        codebase as in <code>urls</code> could have originated
 * @return <code>true</code> when the class is defined within the
 *         class loader passed in, <code>false</code> otherwise
 */
protected boolean isClassDefinedInClassLoader(URL[] urls,
                                              ClassLoader loader) {
    try {
        return Arrays.equals(urls, getLoaderAnnotationURLs(loader));
    }
    catch (MalformedURLException e) {
        return false;
    }
}

While the above works and represent no semantic change to the current
implementation and it allows me to extend PreferredClassProvider to add
my own logic, I don't like the fact a class boomerang must be determined
based on an array or URLs while it is the codebase annotation used while
marshalling of type String that is what I keep track of in Seven.

That means that I have to create an array of URLs based on the codebase
annotation which is not that hard, but it also means I must compare an
array of URLs and the URL object I find a problematic object to perform
equals on, it can result in a match even while I never handed out a
particular codebase annotation and it can be a slow operation therefore
I don't want to do that in code might have to check a lot of these
arrays when services are deployed under many codebases (see other post).

Therefore I would like to change my current semantics and use as the
first argument a String representing the codebase instead of an array of
URLs. This means that the current implementation likely has to parse
that string into an array of URLs but there is already a cache for that
(URL[] pathToURLs(String)).

If somebody has an opinion to share it is appreciated,
--
Mark

Reply via email to