Proper fix for the bug where JME's quaternion wasn't

being serialized automatically.
When a class is final and in the field of a class that
is registered, it is safe to register it automatically
because the type can be determined reliably on the
other end of the stream.  So now it allows that.


git-svn-id: https://jmonkeyengine.googlecode.com/svn/trunk@7276 75d07b2b-3a1a-0410-a2c5-0572b91ccdca

engine/src/networking/com/jme3/network/serializing/Serializer.java

@@ -293,8 +293,7 @@ public abstract class Serializer {
         }            
         
         if( failOnMiss ) {
-            Logger.getLogger(Serializer.class.getName()).log(Level.WARNING, "Class has not been registered {0}", cls);
+            throw new IllegalArgumentException( "Class has not been registered:" + cls );
-//            throw new IllegalArgumentException( "Class has not been registered:" + cls );
         }
         return registerClass(cls, fieldSerializer);
     }

engine/src/networking/com/jme3/network/serializing/serializers/FieldSerializer.java

@@ -72,7 +72,20 @@ public class FieldSerializer extends Serializer {
             SavedField cachedField = new SavedField();
             cachedField.field = field;
 
-            if (Modifier.isFinal(field.getType().getModifiers())) cachedField.serializer = Serializer.getSerializer(field.getType());
+            if (Modifier.isFinal(field.getType().getModifiers())) {
+                // The type of this field is implicit in the outer class
+                // definition and because the type is final, it can confidently
+                // be determined on the other end.
+                // Note: passing false to this method has the side-effect that field.getType()
+                // will be registered as a real class that can then be read/written
+                // directly as any other registered class.  It should be safe to take
+                // an ID like this because Serializer.initialize() is only called 
+                // during registration... so this is like nested registration and
+                // doesn't have any ordering problems.
+                // ...well, as long as the order of fields is consistent from one
+                // end to the next. 
+                cachedField.serializer = Serializer.getSerializer(field.getType(), false);
+            }                
 
             cachedFields.add(cachedField);
         }