[jira] [Created] (BROOKLYN-90) Persist as deployable YAML (and better serialization)

["Alex Heneveld (JIRA)" <ji...@apache.org>]

Alex Heneveld created BROOKLYN-90:
-------------------------------------

             Summary: Persist as deployable YAML (and better serialization)
                 Key: BROOKLYN-90
                 URL: https://issues.apache.org/jira/browse/BROOKLYN-90
             Project: Brooklyn
          Issue Type: New Feature
    Affects Versions: 0.7.0-M2
         Environment: all
            Reporter: Alex Heneveld



Currently we persist as XML using xstream, to different folders for `entities`, `policies`, etc.

Meanwhile we also use FOUR other serialization tools in various places:
* Codehaus Jackson in REST (older version, but porting to FasterXML was not straightforward!)
* FasterXML Jackson in CAMP REST server
* GSON in a few places for ad hoc json work
* java.util.Serializable in tests sometimes (we don't require this for any of the above, but a few tests assert it to be overly careful)

And on top of this [~cowtowncoder] is working to handle generics better in java-classmate [1] which I expect will result in significant changes which we'd like to leverage, since currently there are some dodgy edge cases with all the above when generics are used [2].

Things are actually working fine now for all practical purposes, but I want to record the above info, and note that there is a better way, which would give us some nice features.  Specifically:

*It would be nice if persistence could be done to/from YAML/JSON.*

This would allow JSON-optimized document stores to be used as backing stores, giving more efficient read/write semantics during persistence, search capabilities, and possibly some nice versioning features.

This would also allow us to work towards using the same format for rebind _and_ for YAML deployment.  So we could take persisted files and just deploy them.  (We'd need some new features for this, like referencing  co-existing YAML files for locations and adjuncts, but it doesn't seem that far away.)

Finally it feels wise as part of this move to switch to a directory structure akin to that used in the REST API and under {{brooklyn-managed-processes}}, using {{apps/<APP_ID>/entities/<ENTITY_ID>/}}, with the entity state and the state of its adjuncts (as well as locations, where locations are linked to a primary entity) stored underneath.

BTW when I say YAML/JSON, in case it isn't clear, what I mean is the subset of YAML which can be serialized as valid JSON; so not using YAML "id" refs etc; but allowing YAML syntax for lists and maps and multi-line strings, and generating that when a person asks nicely for something readable.

And of course all Brooklyn serialization should use this mechanism, so the list of 5 above becomes 1.  And that one is probably fasterxml ... or anything that succeeds it to incorporate java-classmate.

Have not put a due date on this but it's definitely on the wish list!

[1]  https://github.com/cowtowncoder/java-classmate
[2]  https://github.com/FasterXML/jackson-databind/issues/543



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)