You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@river.apache.org by "Jukka Zitting (JIRA)" <ji...@apache.org> on 2009/01/27 16:56:59 UTC

[jira] Updated: (RIVER-147) PreferredClassProvider protected method to determine codebase equivalence

     [ https://issues.apache.org/jira/browse/RIVER-147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jukka Zitting updated RIVER-147:
--------------------------------

    Fix Version/s:     (was: AR2)

> PreferredClassProvider protected method to determine codebase equivalence
> -------------------------------------------------------------------------
>
>                 Key: RIVER-147
>                 URL: https://issues.apache.org/jira/browse/RIVER-147
>             Project: River
>          Issue Type: Improvement
>          Components: net_jini_loader
>    Affects Versions: jtsk_2.0
>            Reporter: Jim Hurley
>            Assignee: Mark Brouwer
>            Priority: Minor
>
> Bugtraq ID [6190433|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6190433]
> To facilitate experimentation in addressing codebase evolution problems, it might be worthwhile to add some form of protected method to PreferredClassProvider, that would allow a subclass to determine when two codebases are equivalent. A minimum would seem to be to replace some existing calls to Arrays.equals(URL[], URL[]) with calls to a protected method, with Arrays.equals as the default implementation of the method. The specific Arrays.equals calls I have in mind are those related to boomerang and default loader use: the calls in loadClass, annotationsMatch, and findOriginLoader0. It may also be desirable to allow subclass control for the calls in LoaderKey.equals and checkLoader, but that's less clear to me, given security implications. For use in LoaderKey.equals, it would also be necessary to provide a means for the subclass to compute a hash value. It would seem important for the subclass to be able to distinguish the former calls from the latter ones, if the latter are supported.
> Work Around:
> Clone PreferredClassProvider instead.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.