* ContractState's contract type has been moved to TransactionState and is now a string representing the class name of the contract class to allow classloading of arbitrary contracts from custom classloaders.
* Upgraded isolated JAR to new version.
AMQP doesn't define an enum type itself yet the old implementation
listed our snum type as that in the schema despite what we are actually
doing which is serialising the enum down as a list of a string and an
int accompanied by a list of AMQP choices that represent all of the enum
values
Review Comments
Use fingerprinting of the enum types to catch whenever they're changed,
include the enum constants in the fingerprint to avoid any collisions
* Fix the ToStringSerializer so it interacts with reference counting correctly, and stop ref counting byte arrays since they are invariable wrapped in an object we do reference count.
* Pull out object reference condition into a helper function shared by serialization and deserialization
* CORDA-540: Introduce mandatory reason for "kryoSpecific"
... before we forget why they are ignored in such a way
* CORDA-540: Write a test that exposes list serialization problem in AMQP mode
* Revert "Remove CompositeSignaturesWithKeys"
This reverts commit 9b3cad3
For future testing it would be nice, post serialisation, to have easy
access to the serialised objects schema so we can check how it was
serialised. Adding a helper function to return a data class that does
this in the same way we can for deserialize
Current implementation is such that if we find *a* constructor that
works for us we use that, this is of course rather non deterministic, it
also means we may not select the best constructor
for example
old versions had constructors that took
V1: A B
V2: A B C D
if current version, V3 is
V3: A B C D E
which provides secondary constructors for the above then there is a
chance we'd de-serialise objects that were serialised as V2 using the V1
constructor and thus throw away information we don't need to
Additional Changes:
Fixes following rebase onto master
If we attempt to deserialize a class and find that since it's
serialization the definition has changed we need to create a serializer
capable of evolving the serialised data and constructing an instance of
the new type
We currently cope with
* Removing members
* Adding nullable members
* Adding non nullable members if a constructor is provided that
allows us to set the old arguments and defaults the new (mandatory)
fields
* Reordering paramters
* java.time.* custom AMQP serializers and tests. Excludes pure enums.
* Register java.time.* serializers with scheme.
* Provide default implementation of `additionalSerializers`
* Ignore interfaces that are not serializable
* Annotate so test still works.
* Make methods accessible to serializer.
* Make sure interfaces are annotated in the carpenter. Expand tests to check whitelisting. Object is now whitelisted by default since it has no fields.
* Prevented Object from being whitelisted but allow arrays of Objects (i.e. pretty much an untyped array)
* Add LegalProseReference annotation
* Migrate code from autogenerated javascript to TypeScript source
* Add instructions to rebuild the web resources
* Make installWeb more reproducible
Can't have default factories now, they need building with whitelist and
classloader.
Also remove completely spurious import that broke everything, have a
feeling that was something IntelliJ pulled in "to be helpful"
* Fix typo: prefered -> preferred
* Simplify KryoVerifierSerializationScheme and resolve warning.
* Add a custom serialiser for PrivacySeed so that we can avoid invoking RNG.
Allow unique serializer factories to be created per unique set of
WhiteList / Class Loader pair. Remove default consruction of the
SerializerFactory to force use of the FactoryFactory to get the generic
factory and thus access to it's ClassLoader
