1 2 Previous Next 17 Replies Latest reply on Dec 11, 2003 3:31 AM by Bela Ban

    Fails on Java 1.3.1

    Andrew Perepelytsya Newbie


      "mr_dronski" wrote:
      "mr_dronski" wrote:
      Hi guys.

      The docs stated the cache was tested on java v1.4, but should work on 1.3. Anyway, trying to start it on 1.3 succeeds, but upon any attempt to modify the cache contents the 'ClassNotFoundException: boolean' is thrown.

      Everything works fine on 1.4. I know, I know... But we are limited to 1.3 by our customer. Is there any chance to retrofit the cache to 1.3? Right now I'm thinking of launching the cache in a separate JVM (1.4) on our Solaris box alongside the main J2EE application (running on 1.3).

      Your thoughts? :)

        • 1. Re: Jboss-ide 1.3.0  Tutorial. Xdoclet not generating web.xm
          Bela Ban Master

          jboss 3.2.2
          eclipse 3.1
          jboss-ide 1.3.3
          ant 1.6

          Objective: Trying to get the JBoss-ide 1.3 Tutorial to work....as directed.

          Okay, I am still having problems, generating the web.xml and jboss-web.xml using xdoclet.

          I started with the jboss-ide. Running the Xdoclet just generates skeleton web.xml and jboss-web.xml, like the tags are not being processed the tags are in *Servlet.java file.

          1) I ran Ant from the command line on the xdoclet-build.xml file created by the Eclipse-jboss-ide. The file builds with success. Enabled (force) and (verbose) on the attribute...not much change output is Build Successful.

          2) copied the src/* directories to (xdoclet-1.2.1)/samples/src/java directory....Ran the Sample/build and no entries for the ComputeServlet.java, just the Sample "SimpleServlet" entry.

          It is like the file is not even opened and if it is opened the tags are not being recognized or processed for some reason, but no error message. I compared the Tags to the SimpleServlet.java example in the xdoclet/samples/src/java/test/web directory and I see no alarming differences..... Any Ideas?

          ++++++++++++++ tutorial/web/ComputeServlet.java +++++++++++++++++

          * Created on Aug 23, 2004
          * To change the template for this generated file go to
          * Window - Preferences - Java - Code Generation - Code and Comments
          package tutorial.web;

          import java.io.IOException;
          import java.io.PrintWriter;

          import javax.servlet.http.HttpServlet;

          import javax.servlet.ServletException;
          import javax.servlet.ServletConfig;
          import javax.servlet.http.HttpServletRequest;
          import javax.servlet.http.HttpServletResponse;
          import javax.naming.Context;
          import javax.naming.InitialContext;
          import javax.rmi.PortableRemoteObject;

          import tutorial.interfaces.Fibo;
          import tutorial.interfaces.FiboHome;

          * @web.servlet
          * name="ComputeServlet"
          * display-name="Computation Servlet"
          * description="Servlet that compute Fibonacci suite"
          * @web.servlet-mapping
          * url-pattern="/Compute/*"
          * @web.ejb-ref
          * name="ejb/Fibo"
          * type="Session"
          * home="tutorial.interfaces.FiboHome"
          * remote="tutorial.interfaces.Fibo"
          * description="Reference to the Fibo EJB"
          * @jboss.ejb-ref-jndi
          * ref-name="ejb/Fibo"
          * jndi-name="ejb/Fibo"

          * @author youremail@yourdomain.com

          /* ==========================
          * Change History:
          * Replicate below :
          /* --
          * Date:
          * Name:
          * Desc:
          /* =============================== */
          public class ComputeServlet extends HttpServlet {
          private static final long serialVersionUID = 1L;
          private FiboHome home;

          public ComputeServlet() {



          • 2. Re: Fails on Java 1.3.1
            Ben Wang Master


            "bwang00" wrote:
            "bwang00" wrote:

            If there is a demand, we can certainly try it on JDK1.3. One thing though. Since current JBoss head src requires JDK1.4, so even JDK1.3 is working, the support is likely limited in the future. Please don't set your expectation too high. :-)



            • 3. Re: Fails on Java 1.3.1
              Ricardo Newbie


              "rtsaito" wrote:
              "rtsaito" wrote:

              Did you try to run the batch examples (ant run.batch) ? Did they run?

              • 4. Re: Fails on Java 1.3.1
                Ben Wang Master


                "bwang00" wrote:
                "bwang00" wrote:

                TreeCache (without Aop) has been successfully ported back to 3.2 source. It supports both JDK1.3 and JDK1.4 in that version.



                • 5. Re: Fails on Java 1.3.1
                  Andrew Perepelytsya Newbie


                  "mr_dronski" wrote:
                  "mr_dronski" wrote:
                  Having played with the cache for some more time I have a more precise picture now. The cache demos fail (when using ant scripts) on 1.3. Everything runs smoothly on 1.4.

                  But... When I tried to integrate the cache in the app, it ran perfectly ok on 1.3 . That is, without the TreeCacheGUI.

                  Again, perhaps, offtopic (feel free to move the message if so), but I had problems trying to run the cache in any of the replicated modes. Upon starting the cache, the call never returns. It seems to be a normal behaviour for MBeans, I guess, but setting the cache to LOCAL solves this problem. Am I missing some point here?

                  Despite all, it seems to be a valuable product. Way to go, guys :)

                  • 6. Re: Fails on Java 1.3.1
                    Ben Wang Master


                    "bwang00" wrote:
                    "bwang00" wrote:
                    Sorry, I don't know exactly where is your problem. Did you mean you can't run cache in REPLICATED mode only under JDK1.3? Since TreeCache uses JGroups for the underlying transport, you may want to double check there.



                    • 7. Re: Fails on Java 1.3.1
                      Norbert von Truchsess Newbie

                      I'm getting the same problem with JBossCache 1.0.2 on JDK 1.3.

                      Here is what I get from the log:

                      first instance 1 is started in JVM 1

                      >15:14:29,148 [INFO] org.jboss.cache.TreeCache: cache mode is REPL_SYNC
                      >GMS: address is siapp4c1:59485
                      >15:14:33,468 [INFO] org.jboss.cache.TreeCache: viewAccepted(): new members: [siapp4c1:59485]
                      >15:14:33,505 [INFO] org.jboss.cache.TreeCache: state could not be retrieved (must be first member in group)
                      >15:14:33,505 [INFO] org.jboss.cache.TreeCache: setState(): new cache is null (maybe first member in cluster)
                      >Cache: /
                      .... successfully put some entries into the cache ....

                      .... now instance 2 is started up on jvm 2 (diffenent machine). Log from instance 1 shows how instance 2 connects and retrieves state:

                      >15:17:36,868 [INFO] org.jboss.cache.TreeCache: viewAccepted(): new members: [siapp4c1:59485, siapp5c1:59614]
                      >15:17:36,952 [INFO] org.jboss.cache.TreeCache: getState(): locking tree
                      >15:17:37,028 [INFO] org.jboss.cache.TreeCache: getState(): returning the current state

                      ... now instance 2 tries to put an entry into the cache. While this happens instance 1 shows:

                      >java.lang.IllegalArgumentException: java.lang.ClassNotFoundException: boolean
                      > <<no stack trace available>>

                      This is to be found in the logs of instance 2:

                      >15:17:32,488 [INFO] org.jboss.cache.TreeCache: cache mode is REPL_SYNC
                      >GMS: address is siapp5:59614
                      >15:17:36,929 [INFO] org.jboss.cache.TreeCache: viewAccepted(): new members: [siapp4c1:59485, siapp5:59614]
                      >15:17:37,080 [INFO] org.jboss.cache.TreeCache: setState(): setting the new state
                      >15:17:37,126 [INFO] org.jboss.cache.TreeCache: setState(): locking the old tree
                      >15:17:37,181 [INFO] org.jboss.cache.TreeCache: setState(): locking the old tree was successful
                      >15:17:37,182 [INFO] org.jboss.cache.TreeCache: setState(): forcing release of all locks in old tree
                      >15:17:37,183 [INFO] org.jboss.cache.TreeCache: state was retrieved successfully (in 252 milliseconds
                      >Cache: /servers
                      > /ipidom06c1.muc
                      > /ipidom03c1.muc
                      > /ipidom04c1.muc
                      > /ipidom05c1.muc
                      > /q174298

                      ... cache state was received successfully and cache content can be read this means jgroups-communication seems to be fine.

                      ... as soon instance 2 tries to put an entry into the cache it gets:

                      >15:17:39,625 [ERROR] org.jgroups.blocks.RpcDispatcher: exception=java.lang.IllegalArgumentException: >java.lang.ClassNotFoundException: boolean
                      >java.lang.IllegalArgumentException: java.lang.ClassNotFoundException: boolean
                      > <<no stack trace available>>

                      as a result the entry is not replicated and can only be read from the cache-instance where it was put into.

                      • 8. Re: Fails on Java 1.3.1
                        Norbert von Truchsess Newbie

                        just digged a bit into the code, it seems that org.javagroups.blocks.MethodCall.invoke() generates the IllegalArgumentException because of the Boolean being passed in TreeCache.put():

                        public void put(Fqn fqn, Map data)
                        throws Exception
                        GlobalTransaction tx = getCurrentTransaction();
                        MethodCall m = new MethodCall(put_data_method, new Object[] {
                        tx, fqn, data, new Boolean(true) <--- this boolean seems to be the argument that is not suitable for remote method call in JVM 1.3.1
                        invokeMethod(tx, m);

                        • 9. Re: Fails on Java 1.3.1
                          Norbert von Truchsess Newbie

                          Ok, found it. It's caused by the design of org.jgroups.blocks.MethodCall.

                          MethodCall is used to call a remote method and for this it provides an an serialized (externalized) Version of the method's signature.
                          primitive Types are externalized using their primitive Class (e.g. Boolean.TYPE).
                          Lateron this is sent using org.jgroups.util.Util.objectToByteBuffer and retrieved on the other side using org.jgourps.util.Util.objectFromByteBuffer() which make use of ObjectOutputStream and ObjectInputStream.

                          the ObjectInputStream of SUNs JVM 1.3.1 doesn't support these primitive-types since it uses a Class.forName() to resolve an Object's Class.

                          this code-to-reproduce runs well on SUNs JVM 1.4.2, but fails on SUNs JVM 1.3.1:

                          import java.io.*;

                          public class ObjectInputOutput {

                          public static void main(String[] args) {
                          try {
                          ByteArrayOutputStream baos = new ByteArrayOutputStream();
                          ObjectOutputStream oos = new ObjectOutputStream(baos);
                          byte[] ba = baos.toByteArray();
                          ByteArrayInputStream bais = new ByteArrayInputStream(ba);
                          ObjectInputStream ois = new ObjectInputStream(bais);
                          } catch (Exception e) {

                          java com.bmw.test.ObjectInputOutput


                          java.lang.ClassNotFoundException: boolean
                          at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
                          at java.security.AccessController.doPrivileged(Native Method)
                          at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
                          at java.lang.ClassLoader.loadClass(ClassLoader.java:297)
                          at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:286)
                          at java.lang.ClassLoader.loadClass(ClassLoader.java:253)
                          at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313)
                          at java.lang.Class.forName0(Native Method)
                          at java.lang.Class.forName(Class.java:195)
                          at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:654)
                          at java.io.ObjectInputStream.inputClassDescriptor(ObjectInputStream.java:918)
                          at java.io.ObjectInputStream.readObject(ObjectInputStream.java:366)
                          at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350)
                          at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236)
                          at com.bmw.test.ObjectInputOutput.main(ObjectInputOutput.java:27)

                          • 10. Re: Fails on Java 1.3.1
                            Bela Ban Master

                            So what do you suggest we do to solve this problem ?


                            • 11. Re: Fails on Java 1.3.1
                              Norbert von Truchsess Newbie

                              I suggest using jgroups 2.2.6 and change org.jgroups.util.ContextObjectInputStream as it is implemented in JDK1.4:

                              package org.jgroups.util;

                              import java.io.IOException;
                              import java.io.ObjectStreamClass;
                              import java.io.InputStream;
                              import java.io.ObjectInputStream;
                              import java.util.HashMap;

                              * ObjectInputStream which sets a contact classloader for reading bytes into objects. Copied from
                              * MarshalledValueInputStream of JBoss
                              * @author Bela Ban
                              * @version $Id: ContextObjectInputStream.java,v 1.1 2004/07/26 15:26:46 belaban Exp $
                              public class ContextObjectInputStream extends ObjectInputStream {

                              * A class wide cache of proxy classes populated by resolveProxyClass
                              private static HashMap classCache = new HashMap();

                              private static final HashMap primClasses = new HashMap(8, 1.0F);
                              static {
                              primClasses.put("boolean", boolean.class);
                              primClasses.put("byte", byte.class);
                              primClasses.put("char", char.class);
                              primClasses.put("short", short.class);
                              primClasses.put("int", int.class);
                              primClasses.put("long", long.class);
                              primClasses.put("float", float.class);
                              primClasses.put("double", double.class);
                              primClasses.put("void", void.class);

                              * Creates a new instance of MarshalledValueOutputStream
                              public ContextObjectInputStream(InputStream is) throws IOException {

                              protected Class resolveClass(ObjectStreamClass v)
                              throws IOException, ClassNotFoundException {
                              String className = v.getName();
                              Class resolvedClass = null;
                              // Check the class cache first if it exists
                              if (classCache != null) {
                              synchronized (classCache) {
                              resolvedClass = (Class) classCache.get(className);

                              if (resolvedClass == null) {
                              ClassLoader loader = Thread.currentThread().getContextClassLoader();
                              try {
                              resolvedClass = loader.loadClass(className);
                              } catch (ClassNotFoundException e) {
                              /* This is a backport von JDK 1.4's java.io.ObjectInputstream to support
                              * retrieval of primitive classes (e.g. Boolean.TYPE) in JDK 1.3.
                              * This is required for org.jgroups.blocks.MethodCall to support primitive
                              * Argument types in JDK1.3:
                              resolvedClass = (Class) primClasses.get(className);
                              if (resolvedClass == null) {
                              /* Use the super.resolveClass() call which will resolve array
                              classes and primitives. We do not use this by default as this can
                              result in caching of stale values across redeployments.
                              resolvedClass = super.resolveClass(v);
                              if (classCache != null) {
                              synchronized (classCache) {
                              classCache.put(className, resolvedClass);
                              return resolvedClass;

                              • 12. Re: Fails on Java 1.3.1
                                Bela Ban Master

                                Done and check into JGroups CVS. I assume you tested that this works, right ?


                                • 13. Re: Fails on Java 1.3.1
                                  Norbert von Truchsess Newbie

                                  of course I checked this in separate code. Currenty I have a little trouble what version / branch of jboss-cache to checkout from cvs to get it compiled against jgroups 2.2.6

                                  What do you recommend? jboss-cache 1.02 seems not to be tagged separately.... Check out from CVS-head and work on the latest sources?

                                  • 14. Re: Fails on Java 1.3.1
                                    Bela Ban Master

                                    Yes, CVS head is prety good now (no errors in the entire JBossCache testsuite, which is a first !)


                                    1 2 Previous Next