+ 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 > <[email protected]> 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.
