river-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Brouwer (JIRA)" <j...@apache.org>
Subject [jira] Assigned: (RIVER-147) PreferredClassProvider protected method to determine codebase equivalence
Date Wed, 08 Aug 2007 13:12:59 GMT

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

Mark Brouwer reassigned RIVER-147:
----------------------------------

    Assignee: Mark Brouwer

> 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.


Mime
View raw message