MINA
  1. MINA
  2. DIRMINA-627

ByteBuffer.getObject() doesn't support Class objects for non-serializable classes

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.1.7
    • Fix Version/s: 2.0.3
    • Component/s: Core
    • Labels:
      None

      Description

      Instances of java.lang.Class are serializable, whether or not the class they represent is serializable. However, org.apache.mina.common.ByteBuffer's optimizations prevent it from unserializing Class instances representing classes that are not serializable. For example, given

      public interface NotSerializable {}
      /.../
      ObjectOutputStream o = /.../;
      o.writeObject (NotSerializable.class);
      /.../
      ObjectInputStream i = /..bytes written by o, above../;
      Object read = i.readObject();

      The 'read' object will be NotSerializable.class.

      Trying the same thing with buffer.putObject (NotSerializable.class); buffer.flip(); buffer.getObject() throws a NullPointerException.

      1. tests.patch
        3 kB
        Owen Jacobson
      2. fix.patch
        3 kB
        Owen Jacobson
      3. AbstractIoBuffer.java
        1 kB
        wangzhenghang
      4. IoBufferTest.java
        3 kB
        wangzhenghang

        Activity

        Hide
        Owen Jacobson added a comment -

        I've attached a patch to ByteBufferTest that both validates my assertion about OOS/OIS and exercises ByteBuffer, with a class's Class and an interface's Class.

        I ran into this doing some remoting (using Camel) over Mina: Camel's MethodInvocation message includes the class object for the method, which in turn includes the class object for the interface it's defined on.

        Show
        Owen Jacobson added a comment - I've attached a patch to ByteBufferTest that both validates my assertion about OOS/OIS and exercises ByteBuffer, with a class's Class and an interface's Class. I ran into this doing some remoting (using Camel) over Mina: Camel's MethodInvocation message includes the class object for the method, which in turn includes the class object for the interface it's defined on.
        Hide
        Owen Jacobson added a comment -

        I've attached a (trivial) fix for the problem.

        I'm a little dubious of the value of the "optimization" to OOS/OIS' protocols. I did a few ad-hoc tests with it and never got more than a 5% saving on byte size. Wouldn't it be a better idea, if we're concerned about data size, to use a normal OOS/OIS pair plus a GzipStream or similar? Less risk of introducing protocol quirks like this issue and DIRMINA-481...

        Protocol optimizations should be left up to things in the ProtocolCodec or filter stack.

        Show
        Owen Jacobson added a comment - I've attached a (trivial) fix for the problem. I'm a little dubious of the value of the "optimization" to OOS/OIS' protocols. I did a few ad-hoc tests with it and never got more than a 5% saving on byte size. Wouldn't it be a better idea, if we're concerned about data size, to use a normal OOS/OIS pair plus a GzipStream or similar? Less risk of introducing protocol quirks like this issue and DIRMINA-481 ... Protocol optimizations should be left up to things in the ProtocolCodec or filter stack.
        Hide
        Emmanuel Lecharny added a comment -

        I think that's belong to 3.0. Anyway, we will have most certainly a better way to handle buffers in 3.0

        Show
        Emmanuel Lecharny added a comment - I think that's belong to 3.0. Anyway, we will have most certainly a better way to handle buffers in 3.0
        Hide
        wangzhenghang added a comment - - edited

        This bug can be easly to fixed. Serializable object can be divide into three types:

        a)Class instances representing classes that are not serializable

        b)Primitive objects

        c)Other serializable objects.

        The first tow types's ClassDescriptor should be written, the third one just write its class name. The attachments are AbstractIoBuffer.java fixed by me and a testCase. The attachments are about mina-2.0.0-M5, it's the same way to fixed this bug in mina-1.1.7.

        Show
        wangzhenghang added a comment - - edited This bug can be easly to fixed. Serializable object can be divide into three types: a)Class instances representing classes that are not serializable b)Primitive objects c)Other serializable objects. The first tow types's ClassDescriptor should be written, the third one just write its class name. The attachments are AbstractIoBuffer.java fixed by me and a testCase. The attachments are about mina-2.0.0-M5, it's the same way to fixed this bug in mina-1.1.7.
        Hide
        Emmanuel Lecharny added a comment -

        This bug will be fixed in MINA 2.0.3. I just applied the proposed patches and added the tests.

        Many thanks and sorry for the delay ...

        Show
        Emmanuel Lecharny added a comment - This bug will be fixed in MINA 2.0.3. I just applied the proposed patches and added the tests. Many thanks and sorry for the delay ...
        Hide
        Emmanuel Lecharny added a comment -
        Show
        Emmanuel Lecharny added a comment - Patch applied in http://svn.apache.org/viewvc?rev=1082736&view=rev

          People

          • Assignee:
            Unassigned
            Reporter:
            Owen Jacobson
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development