I think there is a bug in the hivemind declaration of the
SerializableAdaptor. When my application tries to unsqueeze a serializable
object, I get the following stack dump.
#
org.apache.tapestry.util.io.ResolvingObjectInputStream.resolveClass(Resolvin
gObjectInputStream.java:50)
# java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1513)
# java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1435)
# java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1626)
# java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274)
# java.io.ObjectInputStream.readObject(ObjectInputStream.java:324)
#
org.apache.tapestry.util.io.SerializableAdaptor.unsqueeze(SerializableAdapto
r.java:125)
# $SqueezeAdaptor_105ac0ee43f.unsqueeze($SqueezeAdaptor_105ac0ee43f.java)
#
org.apache.tapestry.util.io.DataSqueezerImpl.unsqueeze(DataSqueezerImpl.java
:181)
# $DataSqueezer_105ac0ee32b.unsqueeze($DataSqueezer_105ac0ee32b.java)
The relevant information is that the resolving object input stream has a
null _resolver member. This is because the SerializableAdaptor has a null
_resolver member. I think this is because either the hivemind declaration is
wrong, or auto-wiring is not working in this case. The hivemind declaration
is in tapestry.data.xml:
<service-point id="SerializableAdaptor" interface="SqueezeAdaptor">
Converts an object down to a compressed byte stream, and then to a
MIME-like string representation.
<invoke-factory>
<construct class="SerializableAdaptor"/>
</invoke-factory>
</service-point>
According to the Hivemind documentation a ClassResolver is auto-wired to a
property named classResolver, SerialziableAdaptor has a property named
Resolver, and therefore will not auto-wire.
Any comments on this problem?
I'm going to add a JIRA issue for this with this email in it.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
