Subject: Upgrade to Spark 1.2.1 using Guava

Maybe but any time the work around is to use "spark-submit --conf spark.executor.extraClassPath=/guava.jar blah” that means that standalone apps must have hard coded paths that are honored on every worker. And as you know a lib is pretty much blocked from use of this version of Spark—hence the blocker severity.

I could easily be wrong but userClassPathFirst doesn’t seem to be the issue. There is no class conflict.

On Feb 27, 2015, at 7:13 PM, Sean Owen <[EMAIL PROTECTED]> wrote:

This seems like a job for userClassPathFirst. Or could be. It's
definitely an issue of visibility between where the serializer is and
where the user class is.

At the top you said Pat that you didn't try this, but why not?

On Fri, Feb 27, 2015 at 10:11 PM, Pat Ferrel <[EMAIL PROTECTED]> wrote: