3 Replies Latest reply on Dec 18, 2007 12:47 AM by Jason Greene

    PojoCacheListener fqn recovery

    Marvin Chase Newbie

      I know this question has been asked before but I've done a search in this forum for clues on how to get back the fqn reference to the object that triggered a PojoCacheListener event and I don't believe this has been fully answered. I found two references recommend using AopUtils for this purpose as in the below:

      BaseInterceptor inter = (BaseInterceptor) AopUtil.findCacheInterceptor(((Advised) obj)._getInstanceAdvisor());

      Where obj is the source object retrieved from the event. The issue here is that with 2.0.0.GA this returns the internal fqn (other posts indicate this issue as well) which isn't useful.

      Is this a bug? (I suspect not)

      Is there a fix for this or another way to get back the user provided fqn used to attach the original object to the cache. There are many applications for this feature and not having it makes things very difficult.

      If there is an answer to this somewhere out there please provide a reference as I haven't been able to find it after a day or so of debugging/looking.

      Thank you. I've been using JBoss PojoCache for several weeks now and it's one of the nicest solutions for distributed caching I have used.

        • 1. Re: PojoCacheListener fqn recovery
          Jason Greene Master

          It's good to here that POJO Cache is working for you.

          The interceptor is an internal implementation detail (not considered a public API). The interceptor only needs the internal fqn, which is why it is the only fqn it holds a reference to.

          Unfortunately there is no way to obtain the information you want using a public API, so I have created a feature request:

          You can use other internal details to get this, but since they aren't considered public, they might change. Ok now that you have been warned, once you have the internal Fqn, you can call get on the internal fqn for the org.jboss.cache.pojo.impl.PojoInstance.KEY attribute. This will give you a PojoInstance object, of which, you can call getReferences()


          • 2. Re: PojoCacheListener fqn recovery
            Marvin Chase Newbie


            Thank you for your reply and sorry for the very late response. I have been (and still am :)) swamped.

            I appreciate your adding this as a feature request. I have voted for it (hope others will too) and am watching it eagerly.

            A couple of comments:

            I tried the solution you proposed, and it does do what I want to an extent. Here is the test scenario.

            I have one object nested within another, and a method on the enclosing object modifies the enclosed object (field) value. I modeled this as follows:

            protected class integer implements Serializable {
             private static final long serialVersionUID = 811409324986665055L;
             private int i;
             public integer(int i) {
             this.i = new Integer(i);
             public integer add(int addend) {
             return new integer(this.i += addend);
             public String toString() {
             return i + ": integer";
            protected class IntegerWrapper implements Serializable {
             private static final long serialVersionUID = -6675820439881914329L;
             private integer value;
             public IntegerWrapper(int i) {
             value = new integer(i);
             public void makeChange() {
             public String toString() {
             return value + " wrapper";

            I interpreted your suggested solution as the following:

            private void showRealFQNFor(Event e) {
             BaseInterceptor interceptor = (BaseInterceptor) AopUtil.findCacheInterceptor(((Advised) e.getSource())._getInstanceAdvisor());
             Fqn internalFqn = interceptor.getFqn();
             PojoInstance pojoInstance = interceptor.getAopInstance();
             List<Fqn> fqns = pojoInstance.getReferences();

            First, I instantiate and add the enclosing object (IntegerWrapper) to a cache and I get the following attach notifications:

            Node attached: org.jboss.cache.pojo.notification.event.AttachedEvent[source=0: integer]
            Node attached: org.jboss.cache.pojo.notification.event.AttachedEvent[source=0: integer wrapper]

            Note that the fqn returned for the enclosing object is the internal representation (not useful for me) and the fqn of the enclosed object is the external representation of the enclosing object (this is what I need). I can achieve what I need for this event type even though I would have expected the fqn returned for the enclosing object to be the external representation.

            Second, I call the method on the enclosing object (IntegerWrapper.makeChange) to modify the enclosed object and I get the following:

            Field modified: org.jboss.cache.pojo.notification.event.FieldModifiedEvent[source=57: integer]

            When I call the makeChange method on the enclosing object is the event generated has the enclosed object as it's source (which is fine) and the fqn returned is the external fqn of the enclosing object which does not allow me to retrieve the enclosing object (which does not give me what I need).

            1) Have I interpreted your instructions incorrectly in my showRealFQNFor() method? I may well have since I don't think it matches up exactly with you description, but I didn't see a more obvious way using the 2.0.0.GA API.

            2) If I did interpret your reply correctly, is there another way for me to solve my issue I have with the FieldModifiedEvent type?

            3) To clarify what I think would be useful in relation to the feature request, it would be useful to retrieve the user created (external) fqn representation of the object added to the cache whenever any event type notification comes in for any objects enclosed within the object which was added to the cache.

            Thanks, and sorry if this is long. Just wanted to include all the information.

            • 3. Re: PojoCacheListener fqn recovery
              Jason Greene Master

              Yes, the way you mention is good.

              Regarding the problem you refer to, the only way to find the "source" fqn is to search up the tree. Once you find the referring fqn, you can pass that to cache.find(), and use the same technique, until you eventually hit the source.