brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Svetoslav Neykov <svetoslav.ney...@cloudsoftcorp.com>
Subject [PROPOSAL] Class loading fallback in Karaf
Date Tue, 05 Jul 2016 12:56:11 GMT
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.
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message