5 Replies Latest reply on May 30, 2007 4:48 PM by jason.greene

    PojoCacheListener API changes in CR1?

    vincent.marquez

      I've noticed the API changed for the Listener model in pojocache, and I don't see a way to identify which object/fqn triggered the actual notification.

      In version 2.0 the Attach method (for instance) passed in the object being attached. In the API change, (CR1) is there some other way of recovering this object (or fqn at least?)

      Thanks for your help.

        • 1. Re: PojoCacheListener API changes in CR1?
          jason.greene

          The pojo notification system is being revamped and will be implementation complete by GA. Currently missing is remote notifications and the ability to ability to see field changes (only attach/detach is working at the moment). These should be available in the next CR. The API however is considered complete in CR1. It was changed to be more extensible, and to fix problems brought up by other users.

          The new API follows the java EventObject convention. So you just say getSource() to get the object the event corresponds with. In the case of attach this is the object being attached.

          -Jason

          • 2. Re: PojoCacheListener API changes in CR1?

            When revamped will it be possible to register a PojoCacheListener for a specific topic pattern or similar?

            I'd like to use the PojoCache across a cluster of servers and it would be nice if specific servers could register a listener for a particular topic they're interested in, rather than regsitering for all PojoCache event's then deciding if relevant to them or not.

            James

            • 3. Re: PojoCacheListener API changes in CR1?
              jason.greene

               

              "fatbatman" wrote:
              When revamped will it be possible to register a PojoCacheListener for a specific topic pattern or similar?

              I'd like to use the PojoCache across a cluster of servers and it would be nice if specific servers could register a listener for a particular topic they're interested in, rather than regsitering for all PojoCache event's then deciding if relevant to them or not.

              James


              What type of filtering capabilities are you looking for? Would something fqn based like addListener("/blah/foo/*", listener) be sufficient?

              -Jason

              • 4. Re: PojoCacheListener API changes in CR1?

                Yes, that's perfect for me.

                regards

                James

                • 5. Re: PojoCacheListener API changes in CR1?
                  jason.greene

                  I implemented this in HEAD, and will be available in CR2

                  http://jira.jboss.com/jira/browse/JBCACHE-1080