Github user revans2 commented on the pull request:
https://github.com/apache/storm/pull/494#issuecomment-95684780
The problem here is one of classpath hell. The reason someone wants their
jar first in the classpath is because there is a conflict between something
that storm provides and something that the worker wants. In some cases the
developers of the dependency in question have maintained binary backwards
compatibility and this will work fine, but in too many cases, i.e. guava,
compatibility is not maintained. If the incompatibility results in a method not
found error or something like that it is simple to debug, but I have seen
issues, like with disruptor, where the errors are a lot more subtle, and
everything mostly works. Debugging those over a mailing list when I don't
really know what dependencies storm is running against is a real pain.
I am fine with having the option to make the user jar first on the
classpath, but I would want it to be off by default. @emidln if you want to do
that please file a JIRA for it at https://issues.apache.org/jira under STORM
and then update the title of the pull request to include the JIRA number, i.e.
`STORM-XXXX: optionally let stormjar.jar fist on classpath`
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
