Yes,  I just checked that out and find out it does not work on 0.6.
Ok, good luck, you are doing great job in emr!

BTW
If I may say, you need to add service support to Zeppelin.
I.e. to allow start of Zeppelin this way:
sudo /etc/init.d/zeppelin start

*that will start zeppelin under Zeppelin user.
On Jan 15, 2016 9:03 AM, "Jonathan Kelly" <jonathaka...@gmail.com> wrote:

> Yes, there are a lot of changes since 0.5.5, of course, but we're not
> going to support an unreleased version on EMR. We did that for emr-4.1.0
> (the first version to support Zeppelin), but it's much less confusing for
> us to support only released versions on EMR. As I mentioned earlier, we
> will upgrade to 0.5.6 once it's released, but as I also mentioned earlier,
> while the Notebook API appears fixed on 0.5.6, the Job API is not. The
> Job API, btw, is what allows you to run notebooks via the REST API. The
> Notebook API only lets you do CRUD on notebooks/paragraphs/crons.
>
> FWIW, I also tried building Zeppelin from the tip of the master branch but
> still hit the same error when using the Job API, but that's not too
> surprising because v0.5.6 isn't too different from the tip of the master
> branch, particularly in the REST API code (other than the new Shiro
> Security API).
>
> On Thu, Jan 14, 2016 at 10:45 PM Ophir Cohen <oph...@gmail.com> wrote:
>
>> I havn't try the job api, in fact what is the differences between
>> notebook and job api?
>> Anyway, why not jumping to 0.6.0?
>> Looks like there is MANY improvments and bug fixes there....
>> Sounds to me that you are debugging last year snow 😉
>> On Jan 15, 2016 3:07 AM, "Jonathan Kelly" <jonathaka...@gmail.com> wrote:
>>
>>> But now some bad news. I was playing around with the REST API a little
>>> more, and I noticed that I get the same AbstractMethodError on Zeppelin
>>> 0.5.6 for a POST to /api/job/2A94M5J1Z. :( Does anybody have any idea how
>>> this error could possibly have been fixed for /api/notebook in one release,
>>> for /api/notebook/* in the next release, and yet still fail for /api/job/*
>>> in that same release?
>>>
>>> On Thu, Jan 14, 2016 at 4:13 PM Jonathan Kelly <jonathaka...@gmail.com>
>>> wrote:
>>>
>>>> Oh, hey, good news! I just tried Zeppelin 0.5.6 on EMR, and the
>>>> Notebook API works fine. So now we just need Zeppelin 0.5.6 to be
>>>> officially released, and then we can support it on a future version of EMR.
>>>>
>>>> On Thu, Jan 14, 2016 at 2:01 AM Ophir Cohen <oph...@gmail.com> wrote:
>>>>
>>>>> OK, I've made it work.
>>>>> As Jonathan stated above, on emr 4.1 the notebook APIs does not work
>>>>> at all. On both, emr 4.2 and emr 4.3 the /api/notebook works but the query
>>>>> for a specific notebook not.
>>>>>
>>>>> Deploying vanilla Zeppelin (master branch) on the same cluster worked
>>>>> as a charm.
>>>>>
>>>>> It probably origin by Zeppelin versions (0.5.5 on emr vs. 0.6.0 the
>>>>> latest).
>>>>>
>>>>> Now I'm encountering different error that, as far as I can see, does
>>>>> not interfere Zeppelin work:
>>>>> ERROR [2016-01-14 09:55:38,499] ({qtp1505370540-32}
>>>>> NotebookServer.java[onMessage]:176) - Can't handle message
>>>>> java.lang.NullPointerException
>>>>>
>>>>> Many of those.
>>>>> If anyone knows what does it mean....
>>>>>
>>>>> On Thu, Jan 14, 2016 at 12:23 AM, Jonathan Kelly <
>>>>> jonathaka...@gmail.com> wrote:
>>>>>
>>>>>> Interesting... I confirmed that removing all of the extra classpath
>>>>>> entries added by EMR in zeppelin-env.sh does not fix this issue. This 
>>>>>> must
>>>>>> mean that the issue is caused by the custom EMR builds of either Spark or
>>>>>> Hadoop, which we use when building Zeppelin.
>>>>>>
>>>>>> On Wed, Jan 13, 2016 at 2:15 PM Jonathan Kelly <
>>>>>> jonathaka...@gmail.com> wrote:
>>>>>>
>>>>>>> Ah, never mind. I had incorrectly been excluding the jars in
>>>>>>> /usr/lib/zeppelin/interpreter, and I just noticed that 
>>>>>>> jersey-core-1.9.jar
>>>>>>> appears in two places underneath that directory (in the hive and phoenix
>>>>>>> interpreter libs), and those jars are included in the Zeppelin server
>>>>>>> classpath. This older version of jersey-core conflicts with
>>>>>>> jersey-core-1.13.jar from /usr/lib/zeppelin/lib, so this probably 
>>>>>>> doesn't
>>>>>>> help. However, removing just these two jars did not help by itself.
>>>>>>>
>>>>>>> Haven't tried removing classpath entries from zeppelin-env.sh yet
>>>>>>> though.
>>>>>>>
>>>>>>> On Wed, Jan 13, 2016 at 2:07 PM Jonathan Kelly <
>>>>>>> jonathaka...@gmail.com> wrote:
>>>>>>>
>>>>>>>> Yeah, I'm sure you're right that it must be due to something that
>>>>>>>> EMR is putting in the classpath, but the thing is that I didn't see
>>>>>>>> anything else in the classpath that includes the 
>>>>>>>> javax.ws.rs.core.Response
>>>>>>>> class.
>>>>>>>>
>>>>>>>> And yes, I agree that trying to remove these two jars from the
>>>>>>>> Zeppelin classpath was a futile attempt and would only have helped if
>>>>>>>> somehow these jars were near duplicates of each other but different
>>>>>>>> versions of the same thing. Besides, if removing one of the jars had
>>>>>>>> helped, it would have shown that this was probably not a problem with 
>>>>>>>> EMR
>>>>>>>> specifically but with Zeppelin itself, which of course would have been
>>>>>>>> doubtful.
>>>>>>>>
>>>>>>>> Anyway, I'll try removing the EMR-supplied extra classpath entries
>>>>>>>> from zeppelin-env.sh.
>>>>>>>>
>>>>>>>> On Wed, Jan 13, 2016 at 1:48 PM Ophir Cohen <oph...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Interesting
>>>>>>>>>
>>>>>>>>> I'm using emr 4.1.0,  I'll try 4.2.0 tomorrow.
>>>>>>>>>
>>>>>>>>> If I need to guess, I don't think that the mis-version dependency
>>>>>>>>> comes from the zeppelin jars as Zeppelin api works when not in emr.
>>>>>>>>> It most likely that it comes from the emr classpath.
>>>>>>>>> I would have removed all the additional paths (set in
>>>>>>>>> zeppelin-env.sh) and check again.
>>>>>>>>>
>>>>>>>>> BTW
>>>>>>>>> Removing the one of the jars from Zeppelin as you did won't work
>>>>>>>>> as Zeppelin needs these jars.
>>>>>>>>> If you really want to test it you need to build zeppelin and
>>>>>>>>> instructe maven to exclude the problematic dependency  fron one of 
>>>>>>>>> these
>>>>>>>>> jars.
>>>>>>>>> In other words, maven should bring the jar, but without the
>>>>>>>>> duplicate dependency.
>>>>>>>>> Having said that, and as I stated above, I think that the
>>>>>>>>> problematic dependency comes from the additional classpath and not 
>>>>>>>>> from
>>>>>>>>> Zeppelin core jars.
>>>>>>>>> On Jan 13, 2016 11:08 PM, "Jonathan Kelly" <jonathaka...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hi, Ophir, (Jonathan from EMR here)
>>>>>>>>>>
>>>>>>>>>> Are you using emr-4.1.0 or emr-4.2.0? I just tried this with
>>>>>>>>>> emr-4.2.0 and found that http://<my-server>:8890/api/notebook
>>>>>>>>>> works for me, but http://<my-server>:8890/api/notebook/2A94M5J1Z
>>>>>>>>>> fails. For some reason it doesn't quite fail with the same exception 
>>>>>>>>>> that
>>>>>>>>>> you're seeing, but it definitely seems like a similar cause anyway. 
>>>>>>>>>> Here's
>>>>>>>>>> the exception I get:
>>>>>>>>>>
>>>>>>>>>> WARN [2016-01-13 20:34:52,279] ({qtp508683864-37}
>>>>>>>>>> ServletHandler.java[doHandle]:590) - Error for 
>>>>>>>>>> /api/notebook/2A94M5J1Z
>>>>>>>>>> java.lang.AbstractMethodError:
>>>>>>>>>> javax.ws.rs.core.Response.getStatusInfo()Ljavax/ws/rs/core/Response$StatusType;
>>>>>>>>>> at
>>>>>>>>>> javax.ws.rs.WebApplicationException.validate(WebApplicationException.java:186)
>>>>>>>>>> at
>>>>>>>>>> javax.ws.rs.ClientErrorException.<init>(ClientErrorException.java:88)
>>>>>>>>>> at
>>>>>>>>>> org.apache.cxf.jaxrs.utils.JAXRSUtils.findTargetMethod(JAXRSUtils.java:503)
>>>>>>>>>> at
>>>>>>>>>> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.processRequest(JAXRSInInterceptor.java:207)
>>>>>>>>>>
>>>>>>>>>> I found that the Zeppelin classpath includes two different jars
>>>>>>>>>> that contain the javax/ws/rs/core/Response class: 
>>>>>>>>>> /usr/lib/zeppelin/lib/javax.ws.rs-api-2.0-m10.jar
>>>>>>>>>> and /usr/lib/zeppelin/lib/jersey-core-1.13.jar
>>>>>>>>>>
>>>>>>>>>> What's weird though is that if I remove either of these from the
>>>>>>>>>> classpath, the Zeppelin server fails to start up for different 
>>>>>>>>>> reasons. If
>>>>>>>>>> I remove /usr/lib/zeppelin/lib/jersey-core-1.13.jar, I get a
>>>>>>>>>> ClassNotFoundException for 
>>>>>>>>>> com.sun.jersey.core.util.FeaturesAndProperties,
>>>>>>>>>> and if I remove /usr/lib/zeppelin/lib/javax.ws.rs-api-2.0-m10.jar,
>>>>>>>>>> I get a ClassNotFoundException for javax.ws.rs.NotFoundException.
>>>>>>>>>>
>>>>>>>>>> According to a `mvn ... dependency:tree` in the zeppelin-server
>>>>>>>>>> submodule, /usr/lib/zeppelin/lib/jersey-core-1.13.jar comes 
>>>>>>>>>> indirectly from
>>>>>>>>>> zeppelin-server's direct dependency
>>>>>>>>>> on com.sun.jersey:jersey-servlet:jar:1.13:compile, and 
>>>>>>>>>> /usr/lib/zeppelin/lib/javax.ws.rs-api-2.0-m10.jar
>>>>>>>>>> comes from zeppelin-server's direct dependency on 
>>>>>>>>>> javax.ws.rs:javax.ws.rs-api:jar:2.0-m10:compile.
>>>>>>>>>> Both of these dependencies seem to have been added a long time ago, 
>>>>>>>>>> and
>>>>>>>>>> both seem to be used by the websocket API rather than the REST API 
>>>>>>>>>> (at
>>>>>>>>>> least based upon the Git commit descriptions where they were added), 
>>>>>>>>>> so
>>>>>>>>>> this confuses me even more.
>>>>>>>>>>
>>>>>>>>>> Does anybody from the Zeppelin side have any idea what is going
>>>>>>>>>> on here?
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Jonathan
>>>>>>>>>>
>>>>>>>>>> On Wed, Jan 13, 2016 at 5:34 AM Ophir Cohen <oph...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi All,
>>>>>>>>>>> We migrated our Zeppelin to use EMR Zeppelin. It's straight
>>>>>>>>>>> forward and we were happy with the migration till we found out that
>>>>>>>>>>> something isn't working well with the rest API.
>>>>>>>>>>>
>>>>>>>>>>> Calling to the interpreter API:
>>>>>>>>>>> http://<my-server>:8890/api/interpreter
>>>>>>>>>>> and this:
>>>>>>>>>>> http://<my-server>:8890/api/interpreter/setting
>>>>>>>>>>> Returns results as expected.
>>>>>>>>>>>
>>>>>>>>>>> When trying to access the notebooks:
>>>>>>>>>>> http://<my-server>:8890/api/notebook
>>>>>>>>>>> Or a specific notebook:
>>>>>>>>>>> http://<my-server>:8890/api/notebook/2A94M5J1Z
>>>>>>>>>>> It fails with HTTP 500 error.
>>>>>>>>>>>
>>>>>>>>>>> The error I can see in the logs is NoSuchMethodError (see below)
>>>>>>>>>>> which suggests we might have here 'jar-hell' and the wrong 
>>>>>>>>>>> (probably old)
>>>>>>>>>>> jar loaded instead of the need one - but I can't figure that out.
>>>>>>>>>>> Thanks!
>>>>>>>>>>>
>>>>>>>>>>> The exception:
>>>>>>>>>>> WARN [2016-01-13 07:47:11,690] ({qtp716961517-38}
>>>>>>>>>>> ServletHandler.java[doHandle]:590) - Error for 
>>>>>>>>>>> /api/notebook/2A94M5J1Z
>>>>>>>>>>> java.lang.NoSuchMethodError:
>>>>>>>>>>> javax.ws.rs.ClientErrorException.validate(Ljavax/ws/rs/core/Response;Ljavax/ws/rs/core/Response$Status$Family;)Ljavax/ws/rs/core/Response;
>>>>>>>>>>>         at
>>>>>>>>>>> javax.ws.rs.ClientErrorException.<init>(ClientErrorException.java:88)
>>>>>>>>>>>         at
>>>>>>>>>>> org.apache.cxf.jaxrs.utils.JAXRSUtils.findTargetMethod(JAXRSUtils.java:503)
>>>>>>>>>>>         at
>>>>>>>>>>> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.processRequest(JAXRSInInterceptor.java:207)
>>>>>>>>>>>
>>>>>>>>>>
>>>>>

Reply via email to