[PROPOSAL] Class loading fallback in Karaf

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

Brooklyn has a number of places where it will try to load a class by name. It's either using Class.forName(..) or at best mgmt.getCatalogClassLoader().loadClass(...). This is highly likely to fail when run in Karaf.
Some examples of this behaviour:
  * configuring entitlements implementation in brooklyn.properties (or configuring any other class name for that matter)
  * initializers/enrichers in yaml
  * objects passed as config keys/sensors to an entity, with the entity not knowing how to load the classes - can't rebind. For example Brooklyn DSL deferred objects / SpecialFlagsTransformer passed as config
  * PolicyResource trying to attach a policy by class name

Longer term we should introduce bundle knowledge in all of those places. There are various ways to do that - ether by explicitly passing bundle symbolycName + version, loading through a catalog item or another OSGi mechanism altogether.
Shorter term I suggest we go for the following workaround, giving us time to introduce proper OSGi behaviour for each of the the above cases:
  * Pull the class loading logic in a single place. Same as ResourceUtils, but for classes.
  * Support bundle symbolic name + version embedded in the class name - for example org.apache.brooklyn.policy:0.10.0.SNAPSHOT:org.apache.brooklyn.policy.ha.ServiceFailureDetector. That will allow us to use the existing code paths to pass classes, but be able to resolve them.
  * Fall back to a white list of bundles to scan for the class name. For example "org.apache.brooklyn.*:0.10.0.SNAPSHOT". This will help in parsing existing yaml plans, using stock enrichers, rebinding.

Svet.

Re: [PROPOSAL] Class loading fallback in Karaf

[Geoff Macartney <ge...@cloudsoftcorp.com>]

+ 1 both for the longer term plan and the short term proposal


————————————————————
Gnu PGP key - http://is.gd/TTTTuI


> On 5 Jul 2016, at 13:56, Svetoslav Neykov <sv...@cloudsoftcorp.com> wrote:
> 
> Brooklyn has a number of places where it will try to load a class by name. It's either using Class.forName(..) or at best mgmt.getCatalogClassLoader().loadClass(...). This is highly likely to fail when run in Karaf.
> Some examples of this behaviour:
>  * configuring entitlements implementation in brooklyn.properties (or configuring any other class name for that matter)
>  * initializers/enrichers in yaml
>  * objects passed as config keys/sensors to an entity, with the entity not knowing how to load the classes - can't rebind. For example Brooklyn DSL deferred objects / SpecialFlagsTransformer passed as config
>  * PolicyResource trying to attach a policy by class name
> 
> Longer term we should introduce bundle knowledge in all of those places. There are various ways to do that - ether by explicitly passing bundle symbolycName + version, loading through a catalog item or another OSGi mechanism altogether.
> Shorter term I suggest we go for the following workaround, giving us time to introduce proper OSGi behaviour for each of the the above cases:
>  * Pull the class loading logic in a single place. Same as ResourceUtils, but for classes.
>  * Support bundle symbolic name + version embedded in the class name - for example org.apache.brooklyn.policy:0.10.0.SNAPSHOT:org.apache.brooklyn.policy.ha.ServiceFailureDetector. That will allow us to use the existing code paths to pass classes, but be able to resolve them.
>  * Fall back to a white list of bundles to scan for the class name. For example "org.apache.brooklyn.*:0.10.0.SNAPSHOT". This will help in parsing existing yaml plans, using stock enrichers, rebinding.
> 
> Svet.