mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ulrich Kreher (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DIRMINA-822) Deserialising classes that do not implement Serializable fails
Date Sat, 12 Mar 2011 08:49:59 GMT

    [ https://issues.apache.org/jira/browse/DIRMINA-822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006007#comment-13006007

Ulrich Kreher commented on DIRMINA-822:

I am afraid, that is not enough. However, it is much better than getting an NPE in resolveClass.

My first example was a bit too simple. In our scenario we have our own remote method invocation
mechanism. This allows us to very easily change the used transport and various parameters
(TCP, SSL, XML-encoded, HTTP or even using RMI itself internally). We have a class similar
to this:

public class RemoteMethodInv
  static interface NonSerialisable
  { }
  String methodName;
  Class[] paramTypes;
  Object[] paramValues;

Now if we want to call a method remotely which has a parameter of type NonSerialisabe, the
invocation will always fail with Mina 2. But such a remote call is completely legal, as long
as the corresponding parameter value is serialisable. Even using null as value fails, and
null is very well serialisable.

I am not sure why Mina 2 uses an own (anonymous) ObjectInputStream at all, while Mina 1.1.7
does not. Maybe one can adapt the anonymous input stream to use more of its superclass. The
default java.io.ObjectInputStream does not have this problem, which is no surprise since it
may call lookup(Class, boolean).

> Deserialising classes that do not implement Serializable fails
> --------------------------------------------------------------
>                 Key: DIRMINA-822
>                 URL: https://issues.apache.org/jira/browse/DIRMINA-822
>             Project: MINA
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 2.0.2
>            Reporter: Ulrich Kreher
> AbstractIoBuffer uses ObjectStreamClass.lookup(Class) which returns null for classes
that do not implement Serializable. This in turn leads to a NullPointerException a few lines
below in resolveClass(ObjectStreamClass) where the ObjectStreamClass-parameter is null.
> Deserialising a non-serialisable class is completely legal, instances of such a class
will already fail to serialise so they will never get to deserialisation.
> Using ObjectStreamClass.lookupAny(Class) will solve this issue, but it is not available
before Java 6.

This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message