[jira] Updated: (RIVER-265) PreferredClassProvider performs 'unlucky' caching

["Jukka Zitting (JIRA)" <ji...@apache.org>]

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

Jukka Zitting updated RIVER-265:
--------------------------------

    Fix Version/s:     (was: AR2)

> 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: Mark Brouwer
>
> 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/%3c46B9D9C6.8030001@cheiron.org%3e]. 

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