[infinispan-issues] [JBoss JIRA] (ISPN-1583) AbstractDelegatingAdvancedCache with(ClassLoader), withFlags(Flag...) logic is broken

Paul Ferraro (JIRA) jira-events at lists.jboss.org
Wed Dec 12 17:46:17 EST 2012


     [ https://issues.jboss.org/browse/ISPN-1583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro reopened ISPN-1583:
--------------------------------



Why did you close this as opposed to just lowering the priority?  Do you disagree that this is a significant usability bug?  How do you expect users to know that they need to override these two methods in order have a usable cache delegate?

In AS7, cache instances created by the infinispan subsystem are custom implementations of this delegate class.  See:
https://github.com/jbossas/jboss-as/blob/master/clustering/infinispan/src/main/java/org/jboss/as/clustering/infinispan/DefaultEmbeddedCacheManager.java
The DelegatingCache inner class extends:
https://github.com/jbossas/jboss-as/blob/master/clustering/infinispan/src/main/java/org/jboss/as/clustering/infinispan/AbstractAdvancedCache.java
...which contains the workaround for this issue.

Until I implemented this workaround, no invocation flags were applied to cache operations.  Kind of a big deal, I think.

As I see it, this issue can be fixed in 1 of 2 ways:
* via an abstract method to AbstractDelegatingAdvancedCache (see above) that needs to be extended by the implementing class that re-wraps the cache instance
* via adding a factory parameter to the AbstractDelegatingAdvancedCache constructor that performs the cache wrapping

e.g.
{code}
public interface AdvancedCacheWrapper {
  <K, V> AdvancedCache<K, V> wrap(AdvancedCache<K, V> cache);
}

public class AbstractDelegatingAdvancedCache<K, V> extends AbstractDelegatingCache<K, V> implements AdvancedCache<K, V> {
  private final AdvancedCache<K, V> cache;
  private final AdvancedCacheWrapper wrapper;
  protected AbstractDelegatingAdvancedCache(AdvancedCache<K, V> cache, AdvancedCacheWrapper wrapper) {
    super(cache);
    this.cache = cache;
    this.wrapper = wrapper;
  }
  public AdvancedCache<K, V> with(ClassLoader loader) {
    return this.wrapper.wrap(this.cache.with(loader));
  }
  public AdvancedCache<K, V> withFlags(Flag... flags) {
    return this.wrapper.wrap(this.cache.withFlags(flags));
  }
  // ...
}
{code}
The latter is probably the more elegant solution.
                
> AbstractDelegatingAdvancedCache with(ClassLoader), withFlags(Flag...) logic is broken
> -------------------------------------------------------------------------------------
>
>                 Key: ISPN-1583
>                 URL: https://issues.jboss.org/browse/ISPN-1583
>             Project: Infinispan
>          Issue Type: Bug
>          Components: Core API
>    Affects Versions: 5.1.0.BETA5
>            Reporter: Paul Ferraro
>            Assignee: Galder Zamarreño
>
> When the withFlags(...) logic was modified to use a DecoratedCache instead of thread-local storage, any caches already decorated with the AbstractDelegatingAdvancedCache(...) broke.
> Take the following code:
> AdvancedCache<K, V> baseCache;
> AdvancedCache<K, V> customCache = new AbstractDelegatingAdvancedCache<K, V>(baseCache) {
>   public void clear() {
>      // custom clear logic
>   }
> };
> customCache.withFlags(Flag.CACHE_MODE_LOCAL).clear();
> In the above statement, the flag is not applied.
> The call to withFlags(...) returns a reference to customCache, and the reference to DecoratedCache containing the flags is lost to garbage collection.
> In the case of with(ClassLoader) we have the opposite problem.
> customCache.with(customClassLoader).clear();
> In the above statement, the native clear() method is invoked instead of my custom clear() method. with(ClassLoader) returns a reference to DecoratedCache.  The clear() method then operates on baseCache, instead of customCache.

--
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



More information about the infinispan-issues mailing list