@TriggersRemove should allow for the expiry of multiple caches

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Annotate two different methods on a class with @Cacheable with different 
cache names
2. Add two @TriggersRemove annotation to a third "remove" method, with each 
annotation referencing one of the two @Cacheable cacheNames.

What is the expected output? What do you see instead?
Ideally, the "remove" method would, upon invocation, clear the associated entry 
in both associated caches.
Instead - it is a compile error for having a duplicate @TriggersRemove 
annotation on the "remove" method.

What version of the product are you using? On what operating system?
1.0.5

Please provide any additional information below.

My (currently non-compiling) use case is similar to the following:

public class SocialNetwork {

  @Cacheable(cacheName="friends")
  public Friend getFriend(int userId)

  @Cacheable(cacheName="enemies")
  public Enemy getEnemy(int userId)

  @TriggersRemove(cacheName="friends")
  @TriggersRemove(cacheName="enemies")
  public void befriendEnemy(int userId, int userIdOfBefriendedEnemy)

}

I have a custom key generator that only looks at the first method argument that 
I would apply to all three methods above.

It would be great if something like the following would be supported:

  @TriggersRemove(cacheNames={"friends", "enemies"})
  public void befriendEnemy(int userId, int userIdOfBefriendedEnemy)

Original issue reported on code.google.com by brian.la...@gmail.com on 28 Jun 2010 at 9:20

[GoogleCodeExporter]

Sounds like a great feature. I'm working on the release of 1.1.0 right now but 
as soon as that's out we can look at adding this for both 1.0.6 and 1.1.1

Original comment by eric.dalquist on 28 Jun 2010 at 9:40

• Changed state: Accepted
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Original comment by eric.dalquist on 28 Jun 2010 at 11:51

• Added labels: Milestone-Release1.0.6, Milestone-Release1.1.1, Milestone-Release1.2.0

[GoogleCodeExporter]

This is exactly I was gonna ask.

The work around I am doing now is to make the first  @TriggersRemove function 
to call another function that also marked as  @TriggersRemove... this is really 
making the code look bad...

Original comment by timobj@gmail.com on 29 Jun 2010 at 12:04

[GoogleCodeExporter]

Original comment by eric.dalquist on 29 Jun 2010 at 8:19

• Changed state: Started

[GoogleCodeExporter]

I've fixed this and published a 1.1.1-SNAPSHOT release If you would like to try 
it out you can find it in the Sonatype snapshot repository:

    <repositories>
        <repository>
            <id>sonatype-nexus-snapshots</id>
            <name>Sonatype Nexus Snapshots</name>
            <url>http://oss.sonatype.org/content/repositories/snapshots</url>

            <releases>
                <enabled>false</enabled>
            </releases>
            <snapshots>
                <enabled>true</enabled>
            </snapshots>
        </repository>
    </repositories>

Original comment by eric.dalquist on 29 Jun 2010 at 9:15

• Changed state: Fixed
• Removed labels: Milestone-Release1.0.6

[GoogleCodeExporter]

Works like a charm! Thank you for implementing this, and so quickly. I'm now 
looking forward to the 1.1.1 release with great anticipation.

One note though - what are the semantics of using @TriggersRemove with 2+ 
cacheNames where the associated caches use a mix of different key generators? 
Do you throw an exception or simply ignore it with a warning?

My use case works fine as all methods involved use the same generator (which I 
assume the implementation assumes is the case). However, this 
assumption/requirement is missing from the javadoc for @TriggersRemove's 
cacheNames attribute. Do you think it would make sense to add it there, or 
perhaps address it in the wiki?

I mention this not because I can think of a legitimate use cases of targeting 
caches with different generators for removal via @TriggersRemove (I can't) - 
but if someone accidentally *did* configure their methods/annotations in such a 
way, it could result in some very odd behaviour (if no exception was thrown).

Anyway, great job, and thanks again for the quick patch.

Original comment by brian.la...@gmail.com on 30 Jun 2010 at 7:45

[GoogleCodeExporter]

Great, glad it works.

It will simply use the key generator configured in the @TriggersRemove 
annotation. The library doesn't track key generators to caches, just to 
@Cacheable and @TriggersRemove annotations. It's perfectly valid to have 
multiple annotations pointing to the same cache using different generators.

I did think of this when making the change but there isn't a nice way to have 
multiple key generators. I'll be sure to update the docs to describe the 
behavior.

Original comment by eric.dalquist on 30 Jun 2010 at 8:27

[GoogleCodeExporter]

I know you said there isn't a nice way to implement it, but do we plan to 
include this use case in a near future?
Something like this?

@TriggersRemoves{
  @TriggersRemove{
     cacheName= ...,
     keyGenerator= ...
 },
  @TriggersRemove{
     cacheName= ...,
     keyGenerator= ...
 }
}

Thanks,

Jiang

Original comment by timobj@gmail.com on 1 Jul 2010 at 2:50

[GoogleCodeExporter]

I guess we hadn't thought about that but we could look at a way to support 
multiple TriggersRemove/Cacheable annotations on a single method.

Original comment by eric.dalquist on 1 Jul 2010 at 2:54