river-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Greg Trasuk (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (RIVER-265) PreferredClassProvider performs 'unlucky' caching
Date Wed, 24 Apr 2013 15:53:15 GMT

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

Greg Trasuk updated RIVER-265:

    Fix Version/s:     (was: River_2.2.1)

I believe this is in trunk, but not in the 2.2.1 maintenance release.
> 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
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message