binarywang/WxJava · error · IllegalArgumentException

不支持的http执行器类型：{requestType}

Error message

不支持的http执行器类型：{requestType}

What it means

CommonUploadRequestExecutor.create handles all four HttpClientType values (APACHE_HTTP, JODD_HTTP, OK_HTTP, HTTP_COMPONENTS), so the default branch is a forward-compatibility guard. It only fires if a new HttpClientType enum constant is added without a matching case, or a custom RequestHttp returns an unrecognised type.

Source

Thrown at weixin-java-common/src/main/java/me/chanjar/weixin/common/executor/CommonUploadRequestExecutor.java:55

   *
   * @param requestHttp 请求信息
   * @return 执行器
   */
  @SuppressWarnings("unchecked")
  public static RequestExecutor<String, CommonUploadParam> create(RequestHttp<?, ?> requestHttp) {
    switch (requestHttp.getRequestType()) {
      case APACHE_HTTP:
        return new CommonUploadRequestExecutorApacheImpl(
          (RequestHttp<org.apache.http.impl.client.CloseableHttpClient, org.apache.http.HttpHost>) requestHttp);
      case JODD_HTTP:
        return new CommonUploadRequestExecutorJoddHttpImpl((RequestHttp<HttpConnectionProvider, ProxyInfo>) requestHttp);
      case OK_HTTP:
        return new CommonUploadRequestExecutorOkHttpImpl((RequestHttp<OkHttpClient, OkHttpProxyInfo>) requestHttp);
      case HTTP_COMPONENTS:
        return new CommonUploadRequestExecutorHttpComponentsImpl(
          (RequestHttp<org.apache.hc.client5.http.impl.classic.CloseableHttpClient, org.apache.hc.core5.http.HttpHost>) requestHttp);
      default:
        throw new IllegalArgumentException("不支持的http执行器类型：" + requestHttp.getRequestType());
    }
  }
}

View on GitHub (pinned to 1c43293a3c)

Solutions

1. Keep WxJava modules in sync (same version across all modules and BOM) so executor factories and enum stay aligned.
2. Avoid custom RequestHttp subclasses that return fabricated RequestType values; use the built-in client types.
3. If hit on upgrade, update all modules to the matching release that includes the new case.

Example fix

// before — mixed versions
// common 4.6 + an older module that only knows 3 client types

// after — align via BOM
<dependencyManagement>
  <dependency>
    <groupId>com.github.binarywang</groupId>
    <artifactId>wx-java-bom</artifactId>
    <version>${wx-java.version}</version>
    <type>pom</type>
    <scope>import</scope>
  </dependency>
</dependencyManagement>

// Keep all WxJava modules on the same version via the BOM so the switch and enum stay in sync.
// No runtime validation needed unless you use a custom RequestHttp.

private static boolean knownUploadExecutorType(RequestHttp<?,?> http) {
  HttpClientType t = http.getRequestType();
  return t == HttpClientType.APACHE_HTTP || t == HttpClientType.JODD_HTTP
      || t == HttpClientType.OK_HTTP || t == HttpClientType.HTTP_COMPONENTS;
}

try {
  service.upload(param);
} catch (IllegalArgumentException e) {
  if (e.getMessage().contains("不支持的http执行器类型")) {
    // align WxJava module versions via BOM, or stop using custom RequestHttp
  }
  throw e;
}

When it happens

Trigger: A future WxJava version adds a new HttpClientType without updating this switch; or a custom RequestHttp subclass returns a type string/enum not among the four known values.

Common situations: Upgrading WxJava to a version that introduced a new client type while your code still pins an older executor; subclassing RequestHttp in a non-standard way.

Related errors

• 不支持的http执行器类型：{requestType}
• 不支持的http执行器类型：{requestType}
• 不支持的http执行器类型：
• 表单字段名不能为空
• 表单字段值不能为null

AI-assisted analysis of binarywang/WxJava@1c43293a3c (2026-08-14). Data as JSON: /api/errors/a4f723cbc240e2ef. Report an issue: GitHub.