river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patricia Shanahan <p...@acm.org>
Subject Re: light refactoring
Date Thu, 30 Dec 2010 21:28:49 GMT
How about using an IDE to find all references to the Method-getting 
methods? There should not be a whole lot of places that use reflection, 
and therefore need a Method object.

Which is better, and how much work is involved, depends on how directly 
the method names get to the getMethod calls.

Patricia


Tom Hobbs wrote:
> Besides searching the entire code base for the string names of every
> method, is there anyway to easily get a list of reflectively used
> methods?  Or does anyone have a list of the (hopefully few) such
> methods?
> 
> On Thu, Dec 30, 2010 at 1:56 PM, Brian Murphy <btmurphy.alt@gmail.com> wrote:
>> On Wed, Dec 29, 2010 at 1:37 AM, <jgrahn@simulexinc.com> wrote:
>>
>> 3) Several of the "Constrainable" classes have the private method
>>> "getProxyTrustIterator" which is never used.   Is this safe to remove?
>>
>> No, this will break outrigger with respect to remote security.
>>
>> The getProxyTrustIterator method is called reflectively by the
>> infrastructure, and is necessary for verifying trust in the proxies
>> (both dynamic and non-dynamic) that a client might receive.
>> Therefore, that method is somewhat fundamental to the
>> extensions that were made to the Java security model to
>> support network security in the face of remote method
>> invocations and downloaded code. From the specification of
>> the net.jini.security.proxytrust.ProxyTrustVerifier.isTrusted
>> method:
>>
>> [snip]
>>     * A verifier is obtained from a candidate object as follows.
>>     * <ul>
>>     * <li>
>>     * If either the candidate object's class has a non-<code>static</code>
>>     * member method with signature:
>>     * <pre>ProxyTrustIterator getProxyTrustIterator();</pre>
>>     * or the candidate object is an instance of a dynamically generated
>>     * {@link Proxy} class and the contained invocation handler's class has
>>     * such a member method, then the <code>getProxyTrustIterator</code>
>>     * method is called (on the candidate object or its invocation handler).
>>     * For each object produced by the {@link ProxyTrustIterator#next next}
>>     * method of the returned iterator, the following substeps are used,
>> until
>>     * either a verifier is obtained or the iteration terminates. If no
>>     * verifier can be obtained from any object produced by the iterator,
>>     * then there is no verifier for the candidate object. For any given
>>     * object produced by the iterator, if a verifier cannot be obtained
>> from
>>     * the object but an intermediate operation involved in attempting to
>>     * obtain a verifier throws a <code>RemoteException</code>, that
>>     * exception is passed to the {@link ProxyTrustIterator#setException
>>     * setException} method of the iterator, and the iteration continues.
>>     * <p>
>>     * The <code>getProxyTrustIterator</code> method and the
>>     * <code>ProxyTrustIterator</code> methods are all invoked in a
>>     * restricted security context. If the specified trust verifier
>>     * context contains an {@link UntrustedObjectSecurityContext} instance,
>>     * then the security context returned by its
>>     * {@link UntrustedObjectSecurityContext#getContext getContext} method
>>     * is used. Otherwise, the security context used is equivalent to
>>     * the current security context (as returned by
>>     * {@link net.jini.security.Security#getContext Security.getContext})
>> with
>>     * an additional protection domain combined into the access control
>>     * context that contains an empty {@link java.security.CodeSource}
>>     * (<code>null</code> location and certificates),
>>     * <code>null</code> permissions, <code>null</code> class
loader, and
>>     * <code>null</code> principals.
>> [snip]
>>
>> I hope this helps,
>> Brian
>>
> 


Mime
View raw message