The DataSource now implements the private contract of the Serializable interface -
private void writeObject(java.io.ObjectOutputStream out) throws IOException private void readObject(java.io.ObjectInputStream in) throws IOException, ClassNotFoundException; private void readObjectNoData() throws ObjectStreamException;
Are you sure those methods are invoked of that call stack ?
I've added some debug code to my test case, and it seems that your serialization logic is not compatible with JBoss Marshalling. JBM requires that custom writeObject(...) and readObject(...) methods must properly call out.defaultWriteObject() and in.defaultReadObject(), respectively, before manipulating the stream.
I've submitted a PR to fix that:
With these changes, the DataSource can now serialize and deserialize correctly via JBoss Marshalling.
However, your deserialization logic assumes that the DataSource will be deserialized in the same JVM instance from which it was serialized. This assumption does not hold true in a cluster, nor even in a single server environment, where an SFSB is passivated on shutdown and re-activated on restart. Some other solution is needed.
Yeah, on second thought it is a bad solution, so I'm going to revert.
The only option is to do the full solution, which is a non-trivial implementation of the current IronJacamar container.