It should be very simple to do with the distributed cache. Have them add the
jar to the blob store and configure it to be downloaded with a link of their
choosing. Then include that link in the topology.classpath. The only thing to
be careful of is that if you upload a new version of the jar while your
topology is running you may end up with some workers using one version of the
jar and others using a different version, at least until they are restarted. -
Bobby
On Thursday, May 19, 2016 2:52 AM, Abhishek Agarwal <abhishc...@gmail.com>
wrote:
I have come across this requirement multiple times. For an end user,
creating a uber jar and submitting it directly works fine. But we have
systems which provide processing as a service. These systems take business
logic, completely agnostic of storm, from client in a jar. Service has its
own code (Topology main method etc) in a separate jar which invokes the
business code. storm-sql is a similar type of system.
There are some solutions -
1. Preparing an uber jar on runtime - This changes the internal structure
of jar. META-INF entries have to be handled correctly.
2. Loading the client jar dynamically in a class loader - This approach has
its own set of problems related to class visibility.
I wanted to know if someone else here has run into problem and how did they
solve it. I have also submitted a PR as one possible solution. Any feedback
is most welcome -
https://github.com/apache/storm/pull/1296/files
--
Regards,
Abhishek Agarwal
