<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 13-01-28 3:11 AM, Dan Berindei
      wrote:<br>
    </div>
    <blockquote
cite="mid:CA+nfvwRHwG5TcUjAgSwr678uRj5WDkxKDtoaxDADh5qnMPD69w@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <p dir="ltr"><br>
          On 25 Jan 2013 23:26, "Vladimir Blagojevic" &lt;<a
            moz-do-not-send="true" href="mailto:vblagoje@redhat.com"
            target="_blank">vblagoje@redhat.com</a>&gt; wrote:<br>
          &gt;<br>
          &gt; Hey,<br>
          &gt;<br>
          &gt; I figured out why cache listeners notifications were not
          fired. We have<br>
          &gt; to add listener *after* cache.start() has been called. If
          listener is<br>
          &gt; added before start it will not be registered.<br>
          &gt;</p>
        <p dir="ltr">This doesn't sound right... DefaultCacheManager
          calls cache.start() automatically, so you should never have to
          call it explicitly.</p>
        <p dir="ltr">Looking at the code, the listener should be
          registered even if the cache wasn't started yet (e.g.
          ListenerRegistrationTest never calls start()). The only odd
          thing is that if you stop a cache, all the listeners are lost.
          Maybe that's what happened in your case?</p>
      </div>
    </blockquote>
    <br>
    Nevermind. Our listeners are good, it was my mistake about
    start/stop and how stop wiped out listeners.<br>
    <blockquote
cite="mid:CA+nfvwRHwG5TcUjAgSwr678uRj5WDkxKDtoaxDADh5qnMPD69w@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <p>You could add an interceptor to trigger your events, without
          using the cache's notifications&nbsp; at all. <br>
        </p>
        <p>If you're ok with changing the core, you could add a
          getValue() method to CacheEntryCreatedEvent, and an
          isCreated() method to CacheEntryModifiedEvent (as I suppose
          you don't want to call the updates listener when an entry is
          created). Both changes should be backwards-compatible.<br>
        </p>
      </div>
    </blockquote>
    Ok, I like isCreated(), I found a JIRA where Manik was against this
    idea of changing CacheEntryCreatedEvent for unrelated but similar
    reason!<br>
    <br>
    <br>
    <blockquote
cite="mid:CA+nfvwRHwG5TcUjAgSwr678uRj5WDkxKDtoaxDADh5qnMPD69w@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <p>
        </p>
        <p dir="ltr"><br>
          &gt; The second I have no idea how to implement as we do not
          have<br>
          &gt; CacheEntryExpired event. True, spec is not rigorous that
          such an event<br>
          &gt; has to be fired immediately after an entry has expired
          but eventually<br>
          &gt; (which might be on access). Either way, I am all ears on
          suggestions how<br>
          &gt; to implement this one.<br>
          &gt;</p>
        <p>I guess @CacheEntryEvicted/@CacheEntriesEvicted would be the
          closest thing we have in Infinispan. But you can't check in
          the listener if the entry was evicted because it expired or
          because there wasn't enough space in the data container (yet).<br>
        </p>
        <p>Come to think of it, if an entry is evicted because of size
          constraints, there isn't any way to keep track of its
          expiration time and invoke the expiration listener on access
          either. Is the expiration event mandatory in the JSR?<br>
        </p>
        <br>
      </div>
    </blockquote>
    Yes, but eventually have to notify not at time of expiration! RI for
    example simply checks on access and regular housekeeping if entry is
    expired. <br>
    <br>
    <br>
  </body>
</html>