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
* Rename KeyFactory to CompositeKeyFactory
* Move expandedCompositeKeys into TestDSL as the only place that uses it
* Move NullKeys out of their own package
* Move remaining crypto classes into superpackage
* Move utility classes out of crypto and into utilities package
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
* Minor changes and expose the problem with class serialization
* Custom serializer for Class
* More changes to make TransactionEncumbranceTests pass in AMQP mode
* java.time.* custom AMQP serializers and tests. Excludes pure enums.
* Register java.time.* serializers with scheme.
* Provide default implementation of `additionalSerializers`
* Refactor Kryo contexts into separate classes, according to their use-cases. This prevents Kotlin from trying to instantiate them all every time.
* Also refactor AMQP contexts accordingly.
* Expand comments to explain why these serialisation contexts have been separated.
* Removed Requery object relational mapping usage (and associated schemas including node-schemas module)
* Fixed issues with NodeAttachmentService tests.
Cannot use JPA custom converters with Primary Key fields.
Hibernate entities require explicit call to flush() to persist to disk.
* Removed redundant requery converters (equivalents not even required in Hibernate).
* Removed remaining gradle requery dependency definitions.
* Fixed broken tests.
* Fixes for failing NodeVaultService tests:
- Dynamic SQL updates (in soft locking code)
- Explicit request by session to participate in transaction (causing "TransactionRequiredException" Executing an update/delete query)
- Explicit flush() required to persist to disk
* Updated changelog.
Fixed compiler warning.
* Fixed WHERE clause AND/OR condition.
Enforced immediate data visibility through transaction commit.
* Final fixes to address failing tests.
* Deferred all hibernate session/txn management to DatabaseTransactionManager.
* Fixed transaction boundaries in failing Cash tests.
* Fixes to address failing tests (transaction boundaries, merge detached object, config clean-up).
* Final adjustment to transaction boundaries in JUnit tests.
* Refactored AttachmentSchemaV1 into NodeAttachmentService itself and referenced from NodeServicesV1.
* Refactored HSQL UPDATE statements to use CriteriaUpdate API.
* Updated all criteria API getters to reference attribute names by type.
* Remove redundant VaultSchema entity name (required when previously using HSQL UPDATE syntax)
* Fix compiler warnings.
* Minor changes following rebase from master.
* Fixed suppress warning type.
* 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
As discussed with @rick-r3 this class is no longer fit for purpose because it may break reference equality if part of the graph been serialized with Kryo and part with AMQP
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.
Removing unused default method on the factory, it was added for testing
although given there are easier ways to build factories for the tests it
was never used and doesn't need leaving in