They are shaded to prevent version clashes. If you require these libraries you should include them in your own JAR, and not piggy-back off of the provided JAR. This allows you to use a different version of a dependency than Storm relies on this. If you are using Maven, you should explicitly list it as a dependency, and it'll get bundled in -- otherwise, it'll be marked as "provided" and not bundled in.
ex. if you need Guava, yours would be at com/google/guava, and Storm's will be at com/google/storm/guava -- or something similar. These can be the same version if desired. On Fri, Sep 12, 2014 at 12:58 PM, Simon Cooper < [email protected]> wrote: > Can I ask why it is necessary for curator & zookeeper will be shaded? This > will cause problems for us, as we're using the Utils.newCurator* methods in > our own code to get access to the same zookeeper used by storm, for our own > configuration data. > > If curator is shaded, when running locally this will return an instance of > org.apache.curator.framework.CuratorFramework, when running on a cluster, > it'll return an org.apache.storm.curator.framework.CuratorFramework, and I > can't think of a workaround to allow the same java code to work with both > packages, which means we won't be able to use these methods at all. Is it > necessary for curator to be shaded? >
