Allow pre-definition of object ids before serialisation/deserialisation

[charvolant]

I have an object model where some of the items come from a seperate library of objects and should always be serialised as ids and deserialised from the library of objects. I've been able to define an extension of DefaultDeserializationContext and DefaultSerializationProvider so that I can extend findObjectId but it's been very awkward, in particular because WritableObjectId has been marked final and doesn't have any facility to set the idWritten flag. Trying to set up a custom serializer and then use a beanserializermodifier has caused all kinds of problems with the objectid serializer not being properly initialised for some reason.

I've ended up hacking around the problem by putting my context/provider extensions in the same package as WritableObjectId and setting idWritten directly. Which isn't exactly a clean solution.

I'd like to request the facility to be able to register certain object/id combinations as external to the serialisation/deserialisation, with a simple API to allow external context to be registered.

I'd also like to request a review of the use of final on some classes, such as WritableObjectId. Or at the least, the provision of enough API to allow it to be used cleanly.

[cowtowncoder]

Interesting.

Yes, I think it does make sense to be able to plug in pre-defined sets of ids to use for both serialization and deserialization. I will have to think of a good way to do that; based on past functionality one way is to allow registration of a handler to resolve ids, called first before considering local set of ids. This way set of ids may be open-ended and/or dynamically generated.

[charvolant]

Dynamically generated would be good, since it means that you can delegate resolution to some other object. In my case, I've got several external sources of information (basically objects that represent common terms, types and classifications associated with Darwin Core biology terms) so some sort of cascade or composition would allow me to keep them separate and use them as I see fit.

Being able to register a handler sounds most elegant, as long as it's readily accessible at something close to the object mapper/module level; it's horribly difficult to trace though where things come from at the lower levels.

[cowtowncoder]

Yes, absolutely, it would be registered through either mapper or module. About the only question there is whether to build system to allow multiple chained handlers (similar to how serializer/deserializer providers work) or just a single handler. In this case I suspect single one is sufficient as this does not sound like something where multiple sources are commonly composed; and if that was needed, caller could use a simple delegator where it is needed.