BROOKLYN-519 suggestion to remove BasicSpecParameter from serializing

[Valentin Aitken <va...@cloudsoft.io>]

Hi,

Like I described in BROOKLYN-519 AbstractBrooklynObjectSpec config 
serialization
could be source of deserialization problems in backwards compatibility.
I reviewed the code and I consider EntitySpecParameters are consumed 
only from the API
describing Spec types and catalog items.

I consider those parameters as NOT related to application deployment or 
application management during runtime
thus I suggest to not serialize ConfigKey objects in persistence state 
in order to
simplify persistence of Catalog items and AbstractBrooklynObjectSpec 
values. [1]

Could you also verify my assumption and comment? ^

[1] https://github.com/apache/brooklyn-server/pull/757

-- 
Valentin Aitken
Software Engineer
Cloudsoft Corporation Ltd.
www.cloudsoft.io

Re: BROOKLYN-519 suggestion to remove BasicSpecParameter from serializing

[Svetoslav Neykov <sv...@cloudsoft.io>]

Hi Valentin,

Parameters set on the specs are later converted to config keys on the entity which are then used for type inference and applying restrictions (can mark parameters as required). That's why I think it would be useful to keep the parameters passed in from yaml.

We had a similar problem with persisting entities - we persisted all of the config keys regardless of their source, which after changes on the java types lead to rebind failures. The solution there was to filter out the config keys coming from the entity's java class and persist only keys added externally. I think a similar approach would work great here as well. The changes I'm referring to were done in [1].

Svet.


[1] https://github.com/apache/brooklyn-server/pull/440 <https://github.com/apache/brooklyn-server/pull/440>



> On 7.07.2017 г., at 14:55, Valentin Aitken <va...@cloudsoft.io> wrote:
> 
> Hi,
> 
> Like I described in BROOKLYN-519 AbstractBrooklynObjectSpec config serialization
> could be source of deserialization problems in backwards compatibility.
> I reviewed the code and I consider EntitySpecParameters are consumed only from the API
> describing Spec types and catalog items.
> 
> I consider those parameters as NOT related to application deployment or application management during runtime
> thus I suggest to not serialize ConfigKey objects in persistence state in order to
> simplify persistence of Catalog items and AbstractBrooklynObjectSpec values. [1]
> 
> Could you also verify my assumption and comment? ^
> 
> [1] https://github.com/apache/brooklyn-server/pull/757
> 
> -- 
> Valentin Aitken
> Software Engineer
> Cloudsoft Corporation Ltd.
> www.cloudsoft.io
> 
>