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 <[email protected]> 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 > >
