4 Replies Latest reply on Nov 15, 2004 10:31 AM by Paul Vallender

    TreeCacheAop and default constructors

    Peter Oxenham Newbie

      FYI

      Lately I have been playing with TreeCacheAop, with not much luck, especially from inside of JBoss. So I decided to just go with an external test app.

      I then ran into some more problems. One of them was that I was getting a java.lang.InstantiationException. Being fairly new to Java, I really had no idea what this was.

      I turns out this is because the object I was putting/getting had no default constructor.

      There is no mention of this requirement in the TreeCache documentation, so I thought I should post this here incase anyone else has the same problem.

      Good luck

        • 1. Re: TreeCacheAop and default constructors
          Ben Wang Master

          The error you are seeing should have nothing to do with TreeCacheAop.

          TreeCacheAop does not require a POJO to have a default constructor. It does not replicate the whole object (therefore no need for Serializable either). Instead, it breaks down the object by mapping the members into primitive types eventually.

          There are couple of aop test cases under testsuite and "examples" directory of the standalone package. Maybe you want to check out the usage there.

          Thanks,

          -Ben

          • 2. Re: TreeCacheAop and default constructors
            Paul Vallender Newbie

            Hi,

            TreeCacheAop does not require a POJO to have a default constructor.

            I am sure this is true, However, I am also having problems with Class instantiation exceptions. The problem only occurs when a second cache attempts a getObject for an object created in the first cache.

            If the class has no contructors then everything is fine. If the class has one or more constructors (but no default), then the class loader creates an instantiation exception. If a default constructor is added, then everthing works.

            therefore no need for Serializable either

            In the situation where one cache is running and objects are added. A second cache starts and the initial state is transferred to the second cache. If the objects are not Serializable then a class not serialized exception occurs (at least for me it does). It seems that serialization is required to tranfer the initial state. Is this true or is it something that I am doing wrong (I have had a look through the doc, sorry if I have missed this).

            Many thanks.

            • 3. Re: TreeCacheAop and default constructors
              Bela Ban Master

               

              "paulvallender" wrote:
              Hi,

              therefore no need for Serializable either

              In the situation where one cache is running and objects are added. A second cache starts and the initial state is transferred to the second cache. If the objects are not Serializable then a class not serialized exception occurs (at least for me it does). It seems that serialization is required to tranfer the initial state. Is this true or is it something that I am doing wrong (I have had a look through the doc, sorry if I have missed this).

              Many thanks.


              No, Serializable is *not* required, but you need to declare all your POJO objects. Because we map POJOs down to their primitive types (boolean, int, String etc), and add those to the (superclass) TreeCache, we will by definition only transfer serializable types on state transfer.
              If you don't declare your POJOs in jboss-aop.xml, then we fall back to Serializable/Externalizable, and if a non-declared POJO doesn't implement any of those 2 interfaces, serialization throws an exception.
              State transfer is implemented in TreeCache, not TreeCacheAop.

              Bela

              • 4. Re: TreeCacheAop and default constructors
                Paul Vallender Newbie

                Bela,

                Thanks for the quick reply. I thought I had declared all POJOs in that test, but it seems this wasn't the case (I can't reproduce the Serialisation error today).

                Thanks,

                Paul.