Mailing-List: contact dev-help@brooklyn.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@brooklyn.apache.org
From: Svetoslav Neykov <svet@cloudsoft.io>
Content-Type: multipart/alternative;
 boundary="Apple-Mail=_B249C305-3743-4388-BCE9-F1904798A02D"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: BROOKLYN-519 suggestion to remove BasicSpecParameter from
 serializing
Date: Fri, 7 Jul 2017 16:09:23 +0300
References: <d6d67ced-d47a-b261-2735-6063ae168b08@cloudsoft.io>
To: dev@brooklyn.apache.org
In-Reply-To: <d6d67ced-d47a-b261-2735-6063ae168b08@cloudsoft.io>
Message-Id: <788E7134-543E-4D5C-AED7-6FFDB0FDD574@cloudsoft.io>
archived-at: Fri, 07 Jul 2017 13:09:32 -0000

--Apple-Mail=_B249C305-3743-4388-BCE9-F1904798A02D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

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 =D0=B3., at 14:55, Valentin Aitken =
<valentin@cloudsoft.io> wrote:
>=20
> Hi,
>=20
> 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.
>=20
> 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]
>=20
> Could you also verify my assumption and comment? ^
>=20
> [1] https://github.com/apache/brooklyn-server/pull/757
>=20
> --=20
> Valentin Aitken
> Software Engineer
> Cloudsoft Corporation Ltd.
> www.cloudsoft.io
>=20
>=20


--Apple-Mail=_B249C305-3743-4388-BCE9-F1904798A02D--