brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Svetoslav Neykov <s...@cloudsoft.io>
Subject Re: BROOKLYN-519 suggestion to remove BasicSpecParameter from serializing
Date Fri, 07 Jul 2017 13:09:23 GMT
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 <valentin@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
> 
> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message