p.s. - the exception is this:

java.lang.ClassCastException: java.lang.Class
at org.jboss.serial.persister.ArrayPersister.saveObjectArray(ArrayPersister.java:106)
at org.jboss.serial.persister.ArrayPersister.writeData(ArrayPersister.java:101)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.describeObject(ObjectDescriptorFactory.java:275)
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectOutput.writeObject(DataContainer.java:202)
at org.jboss.serial.persister.ObjectOutputStreamProxy.writeObjectOverride(ObjectOutputStreamProxy.java:60)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:305)

I took a look at JBSER-77 and threw a breakpoint on the line that Oleg mentioned:

persister.writeData(metaData, cache.getOutput(), obj, cache.getSubstitution());

persister is of course an Array Persister (per the stack trace I posted before),

and

obj is a java.lang.Class representing org.springframework.core.io.Resource[]

. . . so . . . yes I think this is likely to be the same bug.

I'll mark JBSER-78 as a dupe of JBSER-77. As soon as you have a new release I'll test the fix with my particular case. That way you don't need to introduce a test case with a dependency on an external library....

Regards,
Matthew Smith

Clebert,

I tested the jar you posted to the JIRA record, and it appears to have fixed the problem which happens during serialization. Now I am seeing the following exception during deserialization:

Caused by: org.jboss.serial.exception.SerializationException: Could not create instance of org.springframework.context.support.ClassPathXmlApplicationContext - org.springframework.context.support.ClassPathXmlApplicationContext
at org.jboss.serial.classmetamodel.ClassMetaData.newInstance(ClassMetaData.java:342)
at org.jboss.serial.persister.RegularObjectPersister.readData(RegularObjectPersister.java:239)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectDescriptionFromStreaming(ObjectDescriptorFactory.java:411)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromDescription(ObjectDescriptorFactory.java:81)
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectInput.readObject(DataContainer.java:634)
at org.jboss.serial.io.JBossObjectInputStream.readObjectOverride(JBossObjectInputStream.java:163)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
at SerializeSpringTest.deserializeObject(SerializeSpringTest.java:59)
... 17 more
Caused by: java.lang.InstantiationException: org.springframework.context.support.ClassPathXmlApplicationContext
at java.lang.Class.newInstance3(Class.java:346)
at java.lang.Class.newInstance(Class.java:305)
at org.jboss.serial.classmetamodel.ClassMetaData.newInstance(ClassMetaData.java:334)
... 24 more


Here's a snippet from the relevant VM source code I could find for the line that throws the InstantationException :

// NOTE: the following code may not be strictly correct under
 // the current Java memory model.
 /*ibm@39253*/
 Constructor tmpConstructor = cachedConstructor;
 Class caller = newInstanceCallerCache;

 // Constructor lookup
 if (tmpConstructor == null) { /*ibm@39253*/
 if (this == Class.class) {
 throw new IllegalAccessException(
 "Can not call newInstance() on the Class for java.lang.Class"
 );
 }
 try {
 final Constructor c =
 getConstructor1(new Class[] {}, Member.DECLARED); /*ibm@59791*/
 // Disable accessibility checks on the constructor
 // since we have to do the security check here anyway
 // (the stack depth is wrong for the Constructor's
 // security check to work)
 java.security.AccessController.doPrivileged
 (new java.security.PrivilegedAction() {
 public Object run() {
 c.setAccessible(true);
 return null;
 }
 });
 tmpConstructor = c; /*ibm@39253*/
 } catch (NoSuchMethodException e) {
 throw new InstantiationException(getName());
 }

Clebert,

It would be nice if I could serialize the spring stuff without having to go create my own custom versions of all those spring class (with default constructors added). If it's possible to serialize and deserialize the object without the default constructor, and even if that would not be desirable default behavior, would you consider adding an option to JBoss serialization that would use that behavior?

Regards,
Matthew Smith

hmm... yes, unintentionally serializing a simpledateformat into 400k is definately a side effect I'd like to avoid.

What immediately comes to mind is inclusion/exclusion lists/wildcards.... however, I'm afraid a might be bloating your API for a special case. Are there any cases other than mine where it might be useful to enable the ghost constructors for either (a) for everything or (b) for some specific list/wildcard match of packages/classes..

Regards,
Matthew Smith

Clebert,

Considering no one else has jumped in with a similar need yet, how about providing that global option, and then I'll worry about making all my simpledateformat's transient in my class hierarchy, or maybe forking jboss serialization to provide myself with a filtering mechanism.

Regards,
Matthew Smith