Mailing-List: contact dev-help@brooklyn.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@brooklyn.apache.org
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Subject: Re: Renaming persisted classes
From: Svetoslav Neykov <svetoslav.neykov@cloudsoftcorp.com>
In-Reply-To: <CABQFKi2t=w0Sm1Qhqdvs6xO5m1hO0SmoJWjvzr9PHKjBD_JC5A@mail.gmail.com>
Date: Thu, 19 May 2016 14:33:30 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <4354F44C-40F1-4059-A080-98CDB495F925@cloudsoftcorp.com>
References: <CAEzXC-EShYi16YmROtSotGfG-7i9KQcguMi1yjFa=QougtZzvw@mail.gmail.com> <CABQFKi2t=w0Sm1Qhqdvs6xO5m1hO0SmoJWjvzr9PHKjBD_JC5A@mail.gmail.com>
To: dev@brooklyn.apache.org
archived-at: Thu, 19 May 2016 11:33:38 -0000

For OSGi we will need to revisit the functionality to work across bundle =
boundaries. Supposedly users starting with the OSGi-fied distribution =
will have a clean slate, so don't need to worry about renamed classes, =
at least for the first version.
I can suggest another alternative for the standard (non-osgi) =
distribution - using classloader.getResources() will return all =
resources with the same name so no need to worry about overriding the =
files from downstream projects.

But even with the current approach we can have a predefined place to put =
those files, not necessarily in a brooklyn prefixed folder. After all =
ServiceLoader does exactly the same in a predefined location =
(META-INF/services).

Svet.

On 19.05.2016 =D0=B3., at 13:52, Richard Downer <richard@apache.org> =
wrote:
>=20
> I'm not sure I'm happy with the idea of many 3rd-party jars adding =
stuff
> into a Brooklyn-owned package. It doesn't rule out a couple of =
3rd-party
> packages happening to choose the same name. I also think there might =
be
> issues with OSGi, as OSGi requires explicit declaration of packages, =
but I
> don't know enough about OSGi to know for sure.
>=20
> Are there any other options for doing this? I'd suggest Java's
> ServiceLoader facility, but that requires 3rd party packages writing a =
Java
> class. Any other ideas?
>=20
> Richard.
>=20
>=20
> On 19 May 2016 at 11:32, Martin Harris =
<martin.harris@cloudsoftcorp.com>
> wrote:
>=20
>> Hi Folks,
>>=20
>> Just a quick heads-up about a PR I raised yesterday
>> <https://github.com/apache/brooklyn-server/pull/144>
>>=20
>> When Brooklyn is rebinding from persisted state, it instantiates =
classes
>> (such as entities) based on the persisted fully-qualified classname. =
This
>> causes a problem if the name of the class, or its package changes,
>> resulting in a ClassNotFoundException
>>=20
>> To resolve this issue, Brooklyn maintains a list of classes that have =
been
>> renamed
>> <
>> =
https://github.com/apache/brooklyn-server/blob/6efc98a6ac79ef009468f231c8a=
93814ff63c5d2/core/src/main/resources/org/apache/brooklyn/core/mgmt/persis=
t/deserializingClassRenames.properties
>>> .
>> The problem is that there is no way for downstream projects to extend =
this
>> list without simply copying the list and ensuring the copy is closer =
to the
>> head of the classpath - which risks divergence of the files
>>=20
>> PR 144 <https://github.com/apache/brooklyn-server/pull/144> resolves =
this
>> issue by moving the file into a specific package, then during
>> deserialisation it checks for any files in that package that end with
>> .properties. It=E2=80=99s assumed that downstream projects will use a
>> project-specific filename to prevent collisions
>>=20
>> Cheers
>> =E2=80=8B
>> --
>> Martin Harris
>> Lead Software Engineer
>> Cloudsoft Corporation Ltd
>> www.cloudsoftcorp.com
>> Mobile: +44 (0)7989 047-855
>>=20