1 2 Previous Next 15 Replies Latest reply on Nov 21, 2006 11:42 PM by ben.wang

    Name change for PojoCache annotation

      Since 1.4 release, I have created two annotations: @PojoCacheable and @InstanceOfPojoCacheable for POJO declaration. The first denotes that such that POJO will be instrumented while the second one means any sub-class will also be intrumented.

      The original intention originally was to put a wrapper around the JBoss Aop @Prepare and @Prepare(... instanceof(...)) such that user won't have to use the JBoss Aop annotation directly.

      Still the user needs to exercise the PojoCache.attach api to attach the POJO, e.g. That is, our model is minimal API (instead of API-less where all you need to do is declare the POJO annotation).

      Now, Bela has suggested we change the name (see part of:
      http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985215#3985215). Since 2.0 is not out yet, this may be a good time to discuss the name change.

      Obvious candidate is perhaps @Replicated and @InstanceOfReplicated. Originally, I have thought about it but felt that it is a bit over-loaded (since user would then expect this is api-less). But if people think it is more appropriate, I can certainly oblige.

      Thoghts?

        • 1. Re: Name change for PojoCache annotation
          genman

          You could use something like "@Entity" like the EJB spec has. But I guess the purpose of the Pojo cache is to provide fine-grained replication, so "@Replicated" or "@Replicable" or something would be okay. "@Replicable" means "capable of replication, which might make more sense than "@Replicated" which sort of seems to mean that it's already been replicated ... which isn't exactly true.

          For inheritence, it seems appropriate to add an attribute rather than a separate annotation, for example:

          @Replicable(instanceOf=true)
          or
          @Replicable(subclasses=true)

          There might be some sort of relation term that would fit better than "instanceof", that means "child classes also".

          • 2. Re: Name change for PojoCache annotation

             

            "genman" wrote:
            For inheritence, it seems appropriate to add an attribute rather than a separate annotation, for example:

            @Replicable(instanceOf=true)
            or
            @Replicable(subclasses=true)

            There might be some sort of relation term that would fit better than "instanceof", that means "child classes also".


            Idea of using attribute is very good but it won't work as is. If you look at jbosscache-aop.xml, you will see that the now @InstanceOfPojoCacheable tag is used inside the JBoss Aop prepare statement:
             <prepare expr="field(!static * $instanceof{@org.jboss.cache.pojo.annotation.InstanceOfPojoCacheable}->*)" />
            


            So replace that with a generic annotation with additional attribute won't work.

            "sub-class" in better than InstanceOf (I am following the JBoss Aop usage, as you can see here), but SubClassOfReplicable, e.g., seems wordy?

            • 3. Re: Name change for PojoCache annotation
              kabirkhan

               

              "genman" wrote:

              @Replicable(instanceOf=true)
              or
              @Replicable(subclasses=true)
              means "child classes also".

              I agree this is nice, but the AOP pointcut matcher cannot match on annotation attributes. It could perhaps be added eventually.

              How about @Replicable and @ReplicableRoot?

              <prepare expr="field(!static * @Replicable->*)" />
              <prepare expr="field(!static * $instanceof{@ReplicableRoot}->*)" />
              


              • 4. Re: Name change for PojoCache annotation
                belaban

                I like the attribute a lot. Kabir, when can we have this feature ? :-)
                -1 on @Replicable, +1 on @Replicated, or maybe we leave it at @Clustered (or @Clusterable)

                • 5. Re: Name change for PojoCache annotation

                  Guys, I need to make this change by tomorrow to make it to Alpha. Can you pitch in your opinions so we can reach an agreement then?

                  As the base annotation, actually I'd vote for @Replicable now (Bela what's your objection here?). And then the corresponding one: @SubClassReplicable.

                  • 6. Re: Name change for PojoCache annotation
                    belaban

                    I think you can always change the name until beta2 or 3...

                    I vote for @Replicated and *no* sub-annotation: if Person is @Replicated, then Student (subclass) should be @Replicated too !

                    Same semantics as for Serializable...

                    • 7. Re: Name change for PojoCache annotation
                      kabirkhan

                       

                      "bela@jboss.com" wrote:
                      I like the attribute a lot. Kabir, when can we have this feature ? :-)


                      I've created a task for investigating if it will be possible for AOP 2.0.alpha3

                      http://jira.jboss.com/jira/browse/JBAOP-309

                      • 8. Re: Name change for PojoCache annotation
                        brian.stansberry

                        I have a small preference for @Replicated too, only because I had to look "replicable" up on dictionary.com to confirm that that's the correct word for the meaning ("replicatable" is not a word.)

                        Re: Serializable semantics, one thing that sucks about them is there's no way to turn it off; i.e. indicate "this subclass isn't Serializable". Maybe not an issue here, but it's a pain in the case of Serializable.

                        • 9. Re: Name change for PojoCache annotation
                          genman

                          I sort of liked Replicable myself, it fits with the naming theme of Serializable and Externalizable. People are capable of dealing with new words in computing, just think of words like deprecated and obfuscate.

                          • 10. Re: Name change for PojoCache annotation
                            belaban

                            Regarding extending @Replicated to subclasses: if you want to cut transitive closure of @Replicated to the subclass hierarchy, use @Transient for a class. Then instances of this class, plus subclasses will *not* be @Replicated.

                            • 11. Re: Name change for PojoCache annotation
                              belaban

                              Actually, while I like @Replicated more, you've got a point there...

                              • 12. Re: Name change for PojoCache annotation

                                So looks like we should just provide @Replicable (or @Replicated) and give the semantics of it applies to all subclass as well. Later on when AOP can provide attribute matching, we can then add the attribute (subclass=true) to distinguish it.

                                One other possible way to break the closure is actually to comment out the prepare...instanceof... statement in pojocache-aop.xml. But it applies to all POJOs so not a permanent solution.

                                Ideally, I'd like to get this done before Brian start the integration into 5.0. This is becuase there are tedious changes for the testing POJOs there (unless he doesn't object).

                                OK, it is between @Replicated and @Replicable. Elias has convinced me to switch over to @Replicable (like I mentioned). So looks like it is 2 agaisnt 2. Anyone else wants to cast the switching vote? :-)

                                • 13. Re: Name change for PojoCache annotation
                                  brian.stansberry

                                   

                                  "ben.wang@jboss.com" wrote:

                                  Ideally, I'd like to get this done before Brian start the integration into 5.0. This is becuase there are tedious changes for the testing POJOs there (unless he doesn't object).


                                  The FIELD repl integration testing is underway as we speak. If we're just talking about switching the pojocache-aop.xml file and changing the annotation on the couple test classes in the o.j.test.cluster.web.aop package, doing that later's no big deal. If it's more than that, then we're running out of time.

                                  But 2.0.0.Alpha *must* be cut on Friday. If pushing this in risks that, please defer it.

                                  Re: @Replicable, that's fine. My comment about the dictionary should only have counted as a 1/10 vote.

                                  • 14. Re: Name change for PojoCache annotation

                                    OK. Not much risk just tedious update so let's defer it then.

                                    1 2 Previous Next