[infinispan-issues] [JBoss JIRA] (ISPN-2036) IllegalArgumentException during TreeCache instantiation

[ https://issues.jboss.org/browse/ISPN-2036?page=com.atlassian.jira.plugin.... ] Galder Zamarreño edited comment on ISPN-2036 at 5/11/12 5:14 AM: ----------------------------------------------------------------- I've looked at this and can't see what the fix for this should be. Aside from the actual fix, there's a pretty entangled hierarchy of classes, added by several people, whose responsibility is not very clear, plus they're wasteful, i.e. AbstractDelegatingCache has a ref to Cache, and this class is extended by AbstractDelegatingAdvancedCache has a ref to AdvancedCache. Then, DecoratedCache extends AbstractDelegatingAdvancedCache adding yet another cache ref via CacheImpl. So, DecoratedCache has 3 references to the same cache instance :/ In paralel, there's another, very similar hierarchy: AbstractDelegatingCacheImpl extends AbstractDelegatingCache and adds a ref to CacheImp, so that's 2 cache refs. Then, AbstractDelegatingCacheImpl is extended twice: first by CacheAdapter (originally to support ISPN-841) which adds TreeContextContainer (which contains a thread local for flags), and secondly, DecoratedCacheAdapter (ISPN-1987), which seems to be the equivalent without a thread local. I'm not sure what this DelegatingCache that @Michael reports above, but my bet is that this is an AS class that comes from trying to use a cache instance coming from a call to Cache.withFlags() within AS. I've created a test that replicates this issue in https://github.com/galderz/infinispan/commit/e3b5cdbc0a991ea5b3f8a0c3d67d..., but the fix should clearly not be limited to DecoratedCache, but any potential delegates (i.e. delegates created within managed envs such as AS). @Manik, your suggested fix on IRC yesterday: {code}[17:18] <manik> galderz: maybe in CacheAdapter.withFlags() we should pass in the actual cache and not the CacheAdapter when constructing a DecoratedCacheAdapter [17:18] <manik> galderz: and also pass in the TreeCacheContext to the DecoratedCacheAdapter{code} does not seem to valid. DecoratedCacheAdapter constructor already receives the CacheImpl and TCC as parameters. was (Author: galder.zamarreno): I've looked at this and can't see what the fix for this should be. Aside from the actual fix, there's a pretty entangled hierarchy of classes, added by several people, whose responsibility is not very clear, plus they're wasteful, i.e. AbstractDelegatingCache has a ref to Cache, and this class is extended by AbstractDelegatingAdvancedCache has a ref to AdvancedCache. Then, DecoratedCache extends AbstractDelegatingAdvancedCache adding yet another cache ref via CacheImpl. So, DecoratedCache has 3 references to the same cache instance :/ In paralel, there's another, very similar hierarchy: AbstractDelegatingCacheImpl extends AbstractDelegatingCache and adds a ref to CacheImp, so that's 2 cache refs. Then, AbstractDelegatingCacheImpl is extended twice: first by CacheAdapter (originally to support ISPN-841) which adds TreeContextContainer (which contains a thread local for flags), and secondly, DecoratedCacheAdapter (ISPN-1987), which seems to be the equivalent without a thread local. I'm not sure what this DelegatingCache that @Michael reports above, but my bet is that this is an AS class that comes from trying to use a cache instance coming from a call to Cache.withFlags() within AS. I've created a test that replicates this issue in https://github.com/galderz/infinispan/commit/e3b5cdbc0a991ea5b3f8a0c3d67d..., but the fix should clearly not be limited to DecoratedCache, but any potential delegates (i.e. delegates created within managed envs such as AS). @Manik, your suggested fix on IRC yesterday: {code}[17:18] <manik> galderz: maybe in CacheAdapter.withFlags() we should pass in the actual cache and not the CacheAdapter when constructing a DecoratedCacheAdapter [17:18] <manik> galderz: and also pass in the TreeCacheContext to the DecoratedCacheAdapter{code} does not seem to valid. DecoratedCacheAdapter constructor already receives the CacheImpl and TCC as parameters. @Manik, I've also got ISPN-1948 in the pipeline which is pretty important, so I'm gonna focus on that. Can I leave 2036 with you? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira