7 Replies Latest reply on Sep 20, 2006 5:23 AM by ben.wang

    Minimizing POJOCache impact on existing codebases

    gregory.pierce

      Okay so I've gone through the examples and they contain nothing useful for the use case that I'm trying to build. I don't want to use aopc - EVER. How do I configure JBossCache to take POJOs in a regular application where I have created a cache without having to tie my build process to JBossCache?

      This documentation does not talk about adding objects at runtime to a cache:

      http://labs.jboss.com/file-access/default/members/jbosscache/freezone/docs/1.4.0/TreeCache/en/html_single/index.html

      I've seen references to PropertyConfigurator not needing to be defined as it will take defaults. What are the defaults? If I'm annotating a POJO, what else do I need to do to get it into the cache? The examples do not specify this without immediately falling into a variety of PropertyConfigurator information. If PropertyConfigurator setup required in order for us to get this stuff to use annotated POJOs?

      package org.jboss.labs.jbosscache.model;
      
      
      @org.jboss.cache.aop.annotation.PojoCacheable
      public class Person
      {
       private String firstName;
       private String lastName;
       private Address address;
      
       public String getFirstName()
       {
       return firstName;
       }
      
       public void setFirstName(String firstName)
       {
       this.firstName = firstName;
       }
      
       public String getLastName()
       {
       return lastName;
       }
      
       public void setLastName(String lastName)
       {
       this.lastName = lastName;
       }
      
       public Address getAddress()
       {
       return address;
       }
      
       public void setAddress(Address address)
       {
       this.address = address;
       }
      }
      


      If its not as simple as putting this annotation there and running my application, why isn't it this simple or for that matter - why do I have to EVER annotate my POJOs at all?

      From what I can tell we either have to use a special classloader so that JBC can bootstrap the classes properly, create an aop file to define a pointcut and annotate an object.

      Is there no approach where we can:

      1) Not use a custom classloader

      2) Have JBC annotate an entire object without having to go through the codebase and add annotations to everything (JBC can add/detect this annotation at runtime)

      3) Not use aopc


      At the very least we shouldn't have to annotate the pojo. If you get a pojo and you can't treat it in an AOP manner wouldn't it be better to fallback to treecache as opposed to exploding with the fury of a stracktrace?

        • 1. Re: Minimizing POJOCache impact on existing codebases

          To answer your questions:

          1. There are two ways to instrument your POJO: compile time (a la aopc) and load time (a la -javaagent option for special classloader). I believe Terracotta also uses the latter approach.

          2. BTW, the proper PojoCache doc is under:
          http://labs.jboss.com/file-access/default/members/jbosscache/freezone/docs/1.4.0/PojoCache/en/html/index.html.

          3. If your POJO implements Serializable, then yes, it will fall back to the plain cache behavior. It is documented.

          • 2. Re: Minimizing POJOCache impact on existing codebases
            gregory.pierce

            I went to the POJOCache documentation and looked for the javaagent information and found the following:


            If you are running JDK5.0, you can also use the javaagent option that does not require a separate Classloader. Here are the ant snippet from one-test-aop50, for example.

             <target name="one.test.aop50" depends="compile, generateClassLoader" description="run one junit test case.">
             <junit printsummary="yes" timeout="${junit.timeout}" fork="yes">
             <jvmarg value="-Djboss.aop.path=${output}/resources/jboss-aop.xml"/>
             <jvmarg value="-javaagent:${lib-50}/jboss-aop-jdk50.jar"/>
             <classpath path="${output}/etc" />
             <sysproperty key="log4j.configuration" value="file:${output}/etc/log4j.xml" />
             <classpath refid="lib.classpath.50"/>
             <classpath refid="build.classpath.50"/>
             <formatter type="xml" usefile="true"/>
             <test name="${test}" todir="${reports}"/>
             </junit>
             </target>
            





            This simply does not give any realy information without tearing down the build script and makes an assumption that the user knows what the javaagent flag is. Is there an expectation that the user would have gone into the AOP documentation or JVM documentation to try and figure out what this flag is supposed to mean, do, etc?

            • 3. Re: Minimizing POJOCache impact on existing codebases
              gregory.pierce

              Note, that is the only information in the documentation at all with respect to special classloader/javaagent.

              • 4. Re: Minimizing POJOCache impact on existing codebases
                gregory.pierce

                Further take a look at this paragraph in the documentation


                In this chapter, we explain how to instrument (or "aspectize") the POJOs via JBossAop. There are two steps needed by JBossAop: 1) POJO declaration, 2) instrumentation. But depends on the JDK and instrumentation mode that you are using, you may not need to pre-process your POJO at all. That is, if you use JDK5.0 and load-time mode, then all you need to do is annotation your POJO (or declare it in a xml file). This makes your PojoCache programming nearly transparent.


                This is clearly not the case, there are certainly more steps involved tha simply annotating your POJO to get things to work in load-time mode.

                • 5. Re: Minimizing POJOCache impact on existing codebases

                  Greg,

                  To answer your questions regarding load-time instrumentation.

                  1. You will notice in the examples dir, I have not put any load-time examples there. The main reason actually is that we don't encourage load time option for production usage. This is because, say, 1) run under JBoss AS, it will be very slow to start AS because JBoss Aop/Javaassit need to inspect all of the classes involved, and 2) under other AS envs, no way we can have our own special class loader without servere tinkering.

                  So unless you run it as a standalone, load-time option is not that good. You will notice that Terracotta has had vendor specific start up scripts, of which is a pain, IMO.

                  And honestly, I don't see the downside of using AOPC for production. Do you see one?

                  2. So like you mentioned, it is good to learn this product using load-time option. I agree. Actually, I use the following Java options to run the unit test inside my IDE:

                  -Djboss.aop.path=${output}/resources/jboss-aop.xml -javaagent:${lib-50}/jboss-aop-jdk50.jar

                  So can you possibly contribute an example that runs with load time? :-)

                  3. Finally, PojoCache with default configuration property (e.g., LOCAL mode) is simply not interesting. You can't see the fine-grained graph replication at work!

                  -Ben

                  • 6. Re: Minimizing POJOCache impact on existing codebases
                    gregory.pierce

                     

                    "ben.wang@jboss.com" wrote:
                    Greg,

                    To answer your questions regarding load-time instrumentation.

                    1. You will notice in the examples dir, I have not put any load-time examples there. The main reason actually is that we don't encourage load time option for production usage. This is because, say, 1) run under JBoss AS, it will be very slow to start AS because JBoss Aop/Javaassit need to inspect all of the classes involved, and 2) under other AS envs, no way we can have our own special class loader without servere tinkering.


                    The issue, however, is that there are plenty of people who would want to use JBossCache in a standalone mode and as such not even documenting the option makes things a little bit more painful - especially when you want to compare/compete with a standalone product.



                    And honestly, I don't see the downside of using AOPC for production. Do you see one?


                    The ant driven aopc path makes some assumptions about the availability of precompiled class files. If you have an environment where that isn't the case and I have one that isn't even a contrived example as I've written a tool that generates templated classes, and while I can do aopc in the background I really just want to use the 'scripting' environment that created the classes and instrument them as class-load or runtime.



                    2. So like you mentioned, it is good to learn this product using load-time option. I agree. Actually, I use the following Java options to run the unit test inside my IDE:

                    -Djboss.aop.path=${output}/resources/jboss-aop.xml -javaagent:${lib-50}/jboss-aop-jdk50.jar

                    So can you possibly contribute an example that runs with load time? :-)



                    I am working on that very thing. Actually putting together a whitepaper that speaks to JBossCache specifically.


                    3. Finally, PojoCache with default configuration property (e.g., LOCAL mode) is simply not interesting. You can't see the fine-grained graph replication at work!

                    -Ben



                    While its not all that interesting, you have to be able to show people how to walk before they can run. The problem with the current stuff is that we show people EVERYTHING, and the simple cases are simply missing. I want to do this as a progression showing the bare basics of getting started and going from there - assumig that JBossCache is used in a standalone manner.

                    • 7. Re: Minimizing POJOCache impact on existing codebases

                       

                      "gregory.pierce@jboss.com" wrote:

                      I am working on that very thing. Actually putting together a whitepaper that speaks to JBossCache specifically.


                      Good! The example POJOs are located under examples distro. There is actually a loodtime directory that is using the special classloader (except it is geared toward 1.4). But you can take those structure to modify further.


                      While its not all that interesting, you have to be able to show people how to walk before they can run. The problem with the current stuff is that we show people EVERYTHING, and the simple cases are simply missing. I want to do this as a progression showing the bare basics of getting started and going from there - assumig that JBossCache is used in a standalone manner.


                      OK, I am looking forward to see the examples that you come up then.

                      Thanks,

                      -Ben