brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (BROOKLYN-154) NoSuchMethodError:
Date Thu, 02 Jul 2015 09:48:04 GMT


ASF GitHub Bot commented on BROOKLYN-154:

Github user aledsage commented on a diff in the pull request:
    --- Diff: usage/rest-client/src/main/java/brooklyn/util/http/
    @@ -62,7 +64,8 @@ public BuiltResponsePreservingError(int status, Headers<Object>
headers, Object
                 return new BuiltResponsePreservingError(status, headers, entity, new Annotation[0],
             } finally {
    -            source.close();
    +            if (source instanceof BaseClientResponse)
    --- End diff --
    Why only call `close()` if it's an instance of `BaseClientResponse`? The close method
is on ``, so should we always call close?

> NoSuchMethodError:
> -----------------------------------------------------
>                 Key: BROOKLYN-154
>                 URL:
>             Project: Brooklyn
>          Issue Type: Bug
>    Affects Versions: 0.7.0-SNAPSHOT
>            Reporter: Richard Downer
> While attempting to use brooklyn-rest-client in my project, I came across this error:
> ava.lang.NoSuchMethodError:
> 	at brooklyn.util.http.BuiltResponsePreservingError.copyResponseAndClose(
> 	at$1.invoke( ~[brooklyn-rest-client-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT]
> 	at com.sun.proxy.$Proxy75.createFromYaml(Unknown Source) ~[na:na]
> On examining the problem, the implementation of that was being
picked up did indeed *not* have a close() method.
> I examined the dependencies of the brooklyn-rest-client module. It turns out that there
are *three* dependencies that provide
>   *
>   * com.sun.jersey:jersey-core:jar:1.18.1:compile
>   * org.jboss.resteasy:jaxrs-api:jar:3.0.8.Final:compile
> Of these, only the last one provides a close() method - the other two are both much smaller
classes. So this project has transitive dependencies that are mutually exclusive!
> It seems that in many cases the JVM is putting the last one in the right place to enable
this class to compile and execute. But in some cases at runtime the wrong one appears in its
place and causes runtime errors like this.

This message was sent by Atlassian JIRA

View raw message