You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@brooklyn.apache.org by Alex Heneveld <al...@cloudsoftcorp.com> on 2014/10/24 15:00:03 UTC
Re: Rebind support for entities created from OSGi bundles <- and
versioning
Svet-
SGTM.
The ability to associate entities with the catalog item which created
them will have other benefits too, facilitating audit, lifecycle
control, etc.
Re your version comment, worth noting once #92 (catalog item versioning)
is completed we expect there will be a nice way to introduce new
versions of catalog items without disrupting running instances. If
someone updates a catalog item but leaves its version number unchanged,
it will apply to new instances, AND to old instances when migrated to a
new server, and so it could be a way to force-apply a hot-fix. But that
would not be the recommended way and only done in extremis.
We'd have a nice recommended way, which would be to *always* increase
version number (and it might be a qualifier bump, not even a point
release, e.g. using osgi-style datestamps) and then issue a precise
instruction "update service instance X from version A to A'" (or maybe
the instruction would actually be of the form "apply this set of catalog
version updates to this set of entity instances").
Thoughts? People with expertise or love of versioning minutiae please
tune in here or to #92! (Note that the catalog item is like a set of
OSGi bundles, cf an old Eclipse "Feature", so versioning it seems to me
to simplify things, even though we have a veritable plethora of versions
-- the catalog item, the osgi bundles, and of course the underlying
software itself.)
Best
Alex
On 24/10/2014 13:16, Svetoslav Neykov wrote:
> Hi dev list,
>
>
>
> Problem:
>
> Currently Brooklyn rebinds persisted objects against the application
> classpath. When the entities are created from catalog items referencing OSGi
> bundles it fails to find the required classes.
>
>
>
> Proposed solution:
>
> Record the catalog item ID in the entity/policy object and make sure it is
> serialized. When rebinding use the catalog item's class loader to resolve
> the correct class, falling back to the app class loader.
>
>
>
> An important effect of this setup is that if a catalog item is updated (not
> recommended for non-hot-fix changes) rebinding will force Brooklyn to use
> the updated version.
>
>
>
> Any thoughts or suggestions?
>
>
>
> Svet.
>
>
>
>