Rebind support for entities created from OSGi bundles.

[Svetoslav Neykov <sv...@cloudsoftcorp.com>]

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.

 

Re: Rebind support for entities created from OSGi bundles <- and versioning

[Alex Heneveld <al...@cloudsoftcorp.com>]

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.
>
>   
>
>