Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
jtsk_2.1
-
None
Description
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.
Attachments
Issue Links
- is related to
-
RIVER-147 PreferredClassProvider protected method to determine codebase equivalence
-
- In Progress
-