web-dev-qa-db-ja.com

Jersey Clientを使用したPATCHリクエスト

Jerseyクライアントを使用してテストするために、サーバーでサポートされているPATCHリクエストを実行したい。私のコードは以下の通りですが、com.Sun.jersey.api.client.ClientHandlerException: Java.net.ProtocolException: HTTP method PATCH doesn't support output例外。誰かが私に以下のコードの何が問題なのかを教えてもらえますか？

String complete_url = "http://localhost:8080/api/request";
String request = "[{\"op\":\"add\", \"path\":\"/name\", \"value\":\"Hello\"}]";
DefaultClientConfig config = new DefaultClientConfig();
    config.getProperties().put(URLConnectionClientHandler.PROPERTY_HTTP_URL_CONNECTION_SET_METHOD_WORKAROUND, true);
Client client = Client.create(config);
WebResource resource = client.resource(complete_url);
ClientResponse response = resource.header("Authorization", "Basic xyzabCDef")
 .type(new MediaType("application", "json-patch+json"))
 .method("PATCH", ClientResponse.class, request);

ここに完全な例外があります、

com.Sun.jersey.api.client.ClientHandlerException: Java.net.ProtocolException: HTTP method PATCH doesn't support output
    at com.Sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.Java:155)
    at com.Sun.jersey.api.client.Client.handle(Client.Java:652)
    at com.Sun.jersey.api.client.WebResource.handle(WebResource.Java:682)
    at com.Sun.jersey.api.client.WebResource.access$200(WebResource.Java:74)
    at com.Sun.jersey.api.client.WebResource$Builder.method(WebResource.Java:634)
    at com.acceptance.common.PatchTest.patch(PatchTest.Java:42)
    at Sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at Sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.Java:39)
    at Sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.Java:25)
    at Java.lang.reflect.Method.invoke(Method.Java:597)
    at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.Java:47)
    at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.Java:12)
    at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.Java:44)
    at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.Java:17)
    at org.junit.runners.ParentRunner.runLeaf(ParentRunner.Java:271)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.Java:70)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.Java:50)
    at org.junit.runners.ParentRunner$3.run(ParentRunner.Java:238)
    at org.junit.runners.ParentRunner$1.schedule(ParentRunner.Java:63)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.Java:236)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.Java:53)
    at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.Java:229)
    at org.junit.runners.ParentRunner.run(ParentRunner.Java:309)
    at org.Eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.Java:50)
    at org.Eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.Java:38)
    at org.Eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.Java:467)
    at org.Eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.Java:683)
    at org.Eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.Java:390)
    at org.Eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.Java:197)
Caused by: Java.net.ProtocolException: HTTP method PATCH doesn't support output
    at Sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.Java:1021)
    at com.Sun.jersey.client.urlconnection.URLConnectionClientHandler$1$1.getOutputStream(URLConnectionClientHandler.Java:238)
    at com.Sun.jersey.api.client.CommittingOutputStream.commitStream(CommittingOutputStream.Java:117)
    at com.Sun.jersey.api.client.CommittingOutputStream.write(CommittingOutputStream.Java:89)
    at Sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.Java:202)
    at Sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.Java:272)
    at Sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.Java:276)
    at Sun.nio.cs.StreamEncoder.flush(StreamEncoder.Java:122)
    at Java.io.OutputStreamWriter.flush(OutputStreamWriter.Java:212)
    at Java.io.BufferedWriter.flush(BufferedWriter.Java:236)
    at com.Sun.jersey.core.util.ReaderWriter.writeToAsString(ReaderWriter.Java:191)
    at com.Sun.jersey.core.provider.AbstractMessageReaderWriterProvider.writeToAsString(AbstractMessageReaderWriterProvider.Java:128)
    at com.Sun.jersey.core.impl.provider.entity.StringProvider.writeTo(StringProvider.Java:88)
    at com.Sun.jersey.core.impl.provider.entity.StringProvider.writeTo(StringProvider.Java:58)
    at com.Sun.jersey.api.client.RequestWriter.writeRequestEntity(RequestWriter.Java:300)
    at com.Sun.jersey.client.urlconnection.URLConnectionClientHandler._invoke(URLConnectionClientHandler.Java:217)
    at com.Sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.Java:153)
javajerseyjersey-client
17
nilesh

これは、JDK8実装で修正された現在のJDK実装のバグです。詳細については、このリンクをチェックしてください https://bugs.openjdk.Java.net/browse/JDK-715736 。これを回避する方法はありますが、ジャージーチームは修正しないことにしました https://github.com/Eclipse-ee4j/jersey/issues/1639

考えられる2つの解決策

  1. httpPatchメソッドをサポートするApache Httpクライアントを使用する
  2. jersey Client PostReplaceFilterを使用しますが、コンテナーコードを変更し、POSTリクエストを行う際に、PATCHとして値を持つX-HTTP-Method-Overrideヘッダーを含める必要があります。 http://zcox.wordpress.com/2009/06/17/override-the-http-request-method-in-jersey/ を参照してください]
11
Abhijeet Kushe

FYI-誰かがジャージー2でこれに遭遇した場合に備えて：

https://jersey.github.io/apidocs/latest/jersey/org/glassfish/jersey/client/HttpUrlConnectorProvider.html

次のようにSET_METHOD_WORKAROUNDプロパティを使用します。

    Client jerseyClient = ClientBuilder.newClient()
            .property(HttpUrlConnectorProvider.SET_METHOD_WORKAROUND, true)
            ... etc ...

これを見つけるために私を永遠に連れて行った-私は他人の学習曲線を短絡させるのを助けることができると考えました。

46
Kevin Day

HttpsUrlConnectionを使用している場合（'s'に注意）-HttpUrlConnectorProvider.SET_METHOD_WORKAROUNDの設定は機能しません。詳細なソリューションについては、読み続けてください。

私の場合、HttpUrlConnectorProvider.SET_METHOD_WORKAROUNDプロパティを設定するとNoSuchFieldExceptionが発生しました。これは、私のHttpUrlConnectionインスタンスが実際にはSun.net.www.protocol.https.HttpsURLConnectionImplタイプであり、スーパー：javax.net.ssl.HttpsURLConnection（から継承されるため） HttpUrlConnection）。

したがって、Jacksonコードが接続フィールドsuper（javax.net.ssl.HttpsURLConnectionのインスタンス）からメソッドフィールドを取得しようとすると、次のようになります。

/**
 * Workaround for a bug in {@code HttpURLConnection.setRequestMethod(String)}
 * The implementation of Sun/Oracle is throwing a {@code ProtocolException}
 * when the method is other than the HTTP/1.1 default methods. So to use {@code PROPFIND}
 * and others, we must apply this workaround.
 *
 * See issue http://Java.net/jira/browse/JERSEY-639
 */
private static void setRequestMethodViaJreBugWorkaround(final HttpURLConnection httpURLConnection, final String method) {
    try {
        httpURLConnection.setRequestMethod(method); // Check whether we are running on a buggy JRE
    } catch (final ProtocolException pe) {
        try {
            final Class<?> httpURLConnectionClass = httpURLConnection.getClass();
            AccessController.doPrivileged(new PrivilegedExceptionAction<Object>() {
                @Override
                public Object run() throws NoSuchFieldException, IllegalAccessException {
                    final Field methodField = httpURLConnectionClass.getSuperclass().getDeclaredField("method");
                    methodField.setAccessible(true);
                    methodField.set(httpURLConnection, method);
                    return null;
                }
            });
        } catch (final PrivilegedActionException e) {
            final Throwable cause = e.getCause();
            if (cause instanceof RuntimeException) {
                throw (RuntimeException) cause;
            } else {
                throw new RuntimeException(cause);
            }
        }
    }
}

NoSuchFieldExceptionという名前のフィールドが存在しないことを示すmethodを取得します（getDeclaredFields（）は、アクセス可能性に関係なくすべてのフィールドを取得しますが、現在のクラスに対してのみであり、現在のクラスが継承している可能性があります）。

そこで、JavaのHttpUrlConnectionコードを調べたところ、許可されたメソッドがprivate static String []で指定されていることがわかりました。

 /* Adding PATCH to the valid HTTP methods */
 private static final String[] methods = {
     "GET", "POST", "HEAD", "OPTIONS", "PUT", "DELETE", "TRACE"
 };

解決策は、リフレクションを使用してこのメ​​ソッド配列を変更することでした：

 try {
         Field methodsField = HttpURLConnection.class.getDeclaredField("methods");
         methodsField.setAccessible(true);
         // get the methods field modifiers
         Field modifiersField = Field.class.getDeclaredField("modifiers");
         // bypass the "private" modifier 
         modifiersField.setAccessible(true);

         // remove the "final" modifier
         modifiersField.setInt(methodsField, methodsField.getModifiers() & ~Modifier.FINAL);

         /* valid HTTP methods */
         String[] methods = {
                    "GET", "POST", "HEAD", "OPTIONS", "PUT", "DELETE", "TRACE", "PATCH"
         };
         // set the new methods - including patch
         methodsField.set(null, methods);

     } catch (SecurityException | IllegalArgumentException | IllegalAccessException | NoSuchFieldException e) {
      e.printStackTrace();
     }

メソッドフィールドは静的であるため、その値の変更は、HttpUrlConnectionを含むHttpsUrlConnectionを拡張する具体的なインスタンスに対して機能します。

補足：Java PATCHメソッドをJDKに追加するか、Jacksonから追加して、回避策で階層全体のフィールド検索を実行することをお勧めします。

とにかく、私はこの解決策があなたの時間を節約することを願っています。

11
Daniel L.

簡単な答えは：

依存関係

<!-- https://mvnrepository.com/artifact/org.glassfish.jersey.core/jersey-client -->
 <dependency>
     <groupId>org.glassfish.jersey.core</groupId>
     <artifactId>jersey-client</artifactId>
     <version>2.27</version>
 </dependency>

追加する必要がありますHttpUrlConnectorProvider.SET_METHOD_WORKAROUND = true

Client client = ClientBuilder.newClient(clientConfig).property(HttpUrlConnectorProvider.SET_METHOD_WORKAROUND, true);

リクエスト

client.target("base_url").path("end_point").request().headers("your_headers")
       .build("PATCH", Entity.entity("body_you_want_to_pass", "content-type"))
       .invoke();
1
NarendraR