[
https://issues.apache.org/jira/browse/RIVER-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Firmstone updated RIVER-265:
----------------------------------
Fix Version/s: River_3.0.0
> PreferredClassProvider performs 'unlucky' caching
> -------------------------------------------------
>
> Key: RIVER-265
> URL: https://issues.apache.org/jira/browse/RIVER-265
> Project: River
> Issue Type: Bug
> Components: net_jini_loader
> Affects Versions: jtsk_2.1
> Reporter: Mark Brouwer
> Assignee: Peter Firmstone
> Fix For: River_3.0.0
>
>
> Although this issue is registered as a bug it can be argued whether the
> current behavior is indeed a bug, for my usage however it revealed itself as
> such, hence the issue type.
> If looking at the method {{PreferredClassProvider.lookupLoader}} line
> {{1532}} (Sun JTSK) you can see there is a map that associates class loaders
> with a key that is a tuple of the codebase annotation and the parent class
> loader of the class loader created/found (representing the value of the
> entry).
> In case a new class loader is created that class loader is put in the map to
> be able to find it when that method is consulted with the same Urls and
> parent class loader, but also in case a class loader is found through
> {{findOriginLoader}} the class loader found is put in the map.
> The problem is that the above logic assumes that one class loader has one
> codebase annotation associated with it and this assumption is false when you
> have a class loader that support multiple codebase annotations per class
> loader, as a result codebase boomerang logic seems to be broken under some
> conditions.
> When the class loaders created by {{PreferredClassProvider}} have a one on
> one relation between codebase and class loader the current map is OK. However
> the map should not cache for class loaders found through {{findOriginLoader}}
> as these might result in class loaders that have an annotation that depends
> on the context a class loader operates under. When one only puts an entry in
> the map when a class loader is created everything works as expected as the
> class loaders out of control of {{PreferredClassProvider}} (which can have
> multiple codebase annotations) don't end up for matching purposes in the map.
> The original discussion leading to this issue can be found
> [here|http://mail-archives.apache.org/mod_mbox/incubator-river-dev/200708.mbox/%[email protected]%3e].
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
