<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 12-10-11 7:45 AM, Manik Surtani
      wrote:<br>
    </div>
    <blockquote
      cite="mid:F27B6C0A-9875-4D03-AA0D-AD6D5F59D9A9@jboss.org"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <br>
      <div>
        <div>On 1 Oct 2012, at 14:40, Vladimir Blagojevic &lt;<a
            moz-do-not-send="true" href="mailto:vblagoje@redhat.com">vblagoje@redhat.com</a>&gt;
          wrote:</div>
        <br class="Apple-interchange-newline">
        <blockquote type="cite">
          <meta content="text/html; charset=ISO-8859-1"
            http-equiv="Content-Type">
          <div bgcolor="#FFFFFF" text="#000000">
            <div class="moz-cite-prefix">Now that I am actually
              implementing this I am wondering why don't we simply add
              getUUID to CacheRpcCommand. CancellationService will use
              this UUID for command cancellation, some other services
              might need UUID for something else. Introducing
              CancellableCommand does not add much except bunch of
              instanceof constructs and explicitly connects UUID with
              concept of command cancellation which might not been only
              valid use of command UUID.<br>
            </div>
          </div>
        </blockquote>
        <div><br>
        </div>
        <div>No, this should be on CancellableCommand only. &nbsp;No sense in
          engineering for something we may not need and polluting
          interfaces.</div>
        <br>
      </div>
    </blockquote>
    Ok, no problem. I'll adjust the PR. However, I need to mark that
    only CacheRpcCommand can be cancellable. So we make
    CancellableCommand extend CacheRpcCommand?<br>
  </body>
</html>