GO — Healthy across the board

• Last commit 1d ago
• 20 active contributors
• Apache-2.0 licensed
• CI configured
• Tests present
• ⚠ Concentrated ownership — top contributor handles 61% of recent commits

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests}

WxJava is a comprehensive Java SDK for WeChat backend development, supporting payment APIs, official accounts, mini-programs, enterprise WeChat, WeChat Pay, and video accounts. It abstracts WeChat's REST APIs into type-safe Java objects and provides request/response handling for all major WeChat services. Monorepo structure: weixin-java-osgi/ for OSGi bundle support, others/ for configuration templates and shell utilities, docs/ for migration guides and implementation notes. Multiple package groupings under parent pom.xml (com.github.binarywang) handle different WeChat modules (pay, mp, cp, miniapp, etc).

Java backend developers and teams integrating WeChat services into Chinese e-commerce, SaaS, and fintech applications who need production-grade payment processing, message handling, and user management without building HTTP clients from scratch.

Highly mature: 4.6.0 release version, 11.1K LOC, active CI/CD (CircleCI + GitHub Actions), multiple sponsor integrations (ccflow, Jeepay, Mall4j), and broad feature coverage across WeChat's entire ecosystem. Production-ready with strong community adoption evident from sponsorships.

Low risk for core features but moderate risk from WeChat API volatility—the SDK must constantly track WeChat's breaking changes (docs/HTTPCLIENT_UPGRADE_GUIDE.md and docs/NEW_TRANSFER_API_USAGE.md show recent major shifts). Single-maintainer (binarywang) model means release velocity depends on one person; however, multiple mirrors (GitHub, Gitee, GitCode) reduce single-point-of-failure risk.

Recent work includes HttpClient version upgrades (docs/HTTPCLIENT_UPGRADE_GUIDE.md), new transfer API support (docs/NEW_TRANSFER_API_SUPPORT.md and docs/NEW_TRANSFER_API_USAGE.md), message audit SDK improvements (docs/CP_MSG_AUDIT_THREADLOCAL_LIFECYCLE_REFACTOR.md), and Quarkus framework compatibility (docs/QUARKUS_SUPPORT.md). Active maintenance visible in CircleCI build configuration and GitHub workflows.

git clone https://github.com/binarywang/WxJava.git && cd WxJava && mvn clean install -DskipTests (uses Maven via pom.xml in root). For local development, run mvn test or mvn clean package to build all modules including weixin-java-osgi.

Daily commands: This is a library, not a runnable app. Build with: mvn clean package. Run tests with: mvn test. Integrate into your Spring Boot or plain Java app by adding the dependency: <dependency><groupId>com.github.binarywang</groupId><artifactId>weixin-java-XXXX</artifactId><version>4.6.0</version></dependency> (where XXXX is pay, mp, cp, miniapp, etc).

• pom.xml — Root Maven POM defining the multi-module project structure, dependency versions, and build configuration for all WxJava SDK modules
• others/weixin-java-osgi/pom.xml — OSGI bundle packaging configuration that wraps the SDK for enterprise container deployments
• solon-plugins/wx-java-channel-multi-solon-plugin/src/main/java/com/binarywang/solon/wxjava/channel/integration/WxChannelMultiPluginImpl.java — Primary integration point for multi-channel WeChat support in Solon framework, implements plugin lifecycle and configuration loading
• solon-plugins/wx-java-channel-multi-solon-plugin/src/main/java/com/binarywang/solon/wxjava/channel/properties/WxChannelMultiProperties.java — Configuration properties class that binds WeChat channel multi-tenant settings from application configuration files
• solon-plugins/wx-java-channel-solon-plugin/src/main/java/com/binarywang/solon/wxjava/channel/config/WxChannelServiceAutoConfiguration.java — Auto-configuration entry point that instantiates WeChat channel services and manages dependency injection in Solon
• .github/workflows/maven-publish.yml — CI/CD pipeline that automates testing, building, and publishing artifacts to Maven Central Repository
• README.md — Project documentation covering SDK capabilities, supported WeChat services, and usage quickstart

Add Support for a New WeChat Service Module

1. Create a new Maven module directory under the root project alongside existing modules (e.g., weixin-java-miniapp) (pom.xml)
2. Define module pom.xml with parent reference to root wx-java and specify module-specific dependencies (others/weixin-java-osgi/pom.xml)
3. Implement service interfaces following the WxJava SDK patterns used in existing modules (solon-plugins/wx-java-channel-solon-plugin/src/main/java/com/binarywang/solon/wxjava/channel/config/WxChannelServiceAutoConfiguration.java)
4. Create Solon auto-configuration class extending AbstractWxChannelConfiguration to register beans (solon-plugins/wx-java-channel-multi-solon-plugin/src/main/java/com/binarywang/solon/wxjava/channel/configuration/services/AbstractWxChannelConfiguration.java)

Add Multi-Tenant Support for a New Storage Backend

1. Create a new enum value in StorageType to identify the backend (e.g., DYNAMODB, MONGODB) (solon-plugins/wx-java-channel-multi-solon-plugin/src/main/java/com/binarywang/solon/wxjava/channel/enums/StorageType.java)
2. Implement a new configuration class extending AbstractWxChannelConfiguration for the storage backend (solon-plugins/wx-java-channel-multi-solon-plugin/src/main/java/com/binarywang/solon/wxjava/channel/configuration/services/AbstractWxChannelConfiguration.java)
3. Update WxChannelMultiProperties to expose configuration properties for the new backend (solon-plugins/wx-java-channel-multi-solon-plugin/src/main/java/com/binarywang/solon/wxjava/channel/properties/WxChannelMultiProperties.java)
4. Register conditional bean creation in WxChannelMultiPluginImpl based on StorageType selection (solon-plugins/wx-java-channel-multi-solon-plugin/src/main/java/com/binarywang/solon/wxjava/channel/integration/WxChannelMultiPluginImpl.java)

Configure Multi-Account WeChat Integration in a Solon Application

1. Add wx-java-channel-multi-solon-plugin dependency to your application pom.xml (pom.xml)
2. Define configuration properties in application.properties/yml following WxChannelMultiProperties schema (solon-plugins/wx-java-channel-multi-solon-plugin/src/test/resources/app.properties)
3. Inject WxChannelMultiServices bean in your service/controller to access per-account WeChat APIs (solon-plugins/wx-java-channel-multi-solon-plugin/src/main/java/com/binarywang/solon/wxjava/channel/service/WxChannelMultiServices.java)
4. Choose storage backend (MEMORY, JEDIS, REDIS, REDISSON) via StorageType property based on deployment topology (solon-plugins/wx-java-channel-multi-solon-plugin/src/main/java/com/binarywang/solon/wxjava/channel/enums/StorageType.java)

• Maven multi-module project structure — Enables separation of concerns across WeChat services (payment, mini-app, public accounts, enterprise) and framework integrations (Spring Boot, Solon, OSGI)
• Pluggable storage — undefined

WeChat API credentials (appId, appSecret, mchId, certPath) must be injected at runtime via configuration or environment—no defaults are bundled. ThreadLocal lifecycle management for CP (enterprise WeChat) message audit context requires explicit cleanup to prevent memory leaks (see CP_MSG_AUDIT_THREADLOCAL_LIFECYCLE_REFACTOR.md). OSGi deployments require extra dependency bundle wrappers (servicemix bundles) not pulled automatically. HttpClient 5.x upgrades are breaking and must be coordinated across all modules. WeChat API rate limits are not enforced client-side, so aggressive request batching can trigger 429 errors without SDK-level backoff.

• WeChat API Request/Response Marshalling — WxJava abstracts WeChat's XML and JSON API responses into type-safe Java POJOs using XStream annotations; understanding this marshalling layer is critical for extending the SDK with new endpoints.
• OAuth 2.0 Authorization Code Flow — WeChat mini-programs and official accounts use OAuth 2.0 for user login and delegated access; WxJava encapsulates token exchange and scope management across multiple WeChat platforms.
• Message Signature Verification (HMAC-SHA1) — WeChat requires clients to verify message signatures using shared secrets and HMAC-SHA1; WxJava's core validates webhook payloads, preventing injection attacks.
• ThreadLocal Context Propagation — Enterprise WeChat (CP) message audit context uses ThreadLocal for request-scoped state; CP_MSG_AUDIT_THREADLOCAL_LIFECYCLE_REFACTOR.md documents lifecycle risks in high-concurrency scenarios.
• Certificate-Based Mutual TLS (mTLS) for WeChat Pay — WeChat Pay v3 APIs require client-side certificate authentication beyond standard HTTPS; WxJava manages cert loading, keystore setup, and signature validation for payment operations.
• OSGi Bundle Dependency Re-wrapping — weixin-java-osgi module wraps third-party JARs (xmlpull, xpp3) using ServiceMix bundles for deployment in OSGi containers; critical for enterprise Java EE platforms.
• Mini-Program Session Management & Encryption — WeChat mini-apps use AES-128-CBC encryption for user data and session keys; WxJava provides decryption utilities for phone numbers, user info, and payment credentials.

• silenceper/wechat-sdk — Alternative Go-based WeChat SDK; useful for comparing API design choices and understanding WeChat endpoint coverage expectations.
• wechatpay-apiv3/wechatpay-java — Official Tencent WeChat Pay SDK for Java; complement to WxJava's payment module, often used alongside for direct API access and signature verification.
• jeequan/jeepay — Open-source payment aggregation system (listed as sponsor) that heavily depends on WxJava for WeChat Pay integration in production e-commerce.
• macrozheng/mall — Open-source mall/e-commerce platform; reference implementation demonstrating WxJava usage patterns for real-world payment and messaging.
• spring-cloud/spring-cloud-alibaba — Ecosystem companion for cloud-native Java development; users often integrate WxJava payment modules into Spring Cloud microservices.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive unit tests for weixin-java-osgi OSGI bundle module

The weixin-java-osgi module (others/weixin-java-osgi/pom.xml) is a specialized bundle for OSGI environments but appears to lack dedicated test coverage. This module handles critical dependency bundling (xmlpull, xpp3, xstream, httpcomponents) with exclusions that could easily break. Adding tests would ensure the bundle exports/imports are correctly configured and dependencies resolve properly in OSGI containers.

• [ ] Create others/weixin-java-osgi/src/test/java/ directory structure
• [ ] Add OSGi bundle manifest tests to verify correct Export-Package and Import-Package headers in the compiled bundle
• [ ] Add integration tests validating that core WxJava classes are accessible when the bundle is deployed in an OSGi container (e.g., Apache Felix or Eclipse Equinox)
• [ ] Test that excluded dependencies (xmlpull, xpp3_min) are properly handled and don't cause ClassNotFoundException
• [ ] Reference existing test patterns from other modules in the project

Add GitHub Actions workflow for multi-module dependency vulnerability scanning

While .github/workflows/maven-publish.yml exists, there's no dedicated security scanning workflow. Given the project's complex dependency tree (httpclient, xstream, httpcore with specific versions pinned), and the OSGI module managing legacy bundles, a regular vulnerability scan would catch CVEs early. The current .circleci/config.yml suggests CI exists but GitHub Actions security scanning is absent.

• [ ] Create .github/workflows/security-scan.yml with Maven dependency-check plugin or OWASP Dependency-Check
• [ ] Configure workflow to run on schedule (weekly) and on all pull requests modifying pom.xml or version properties
• [ ] Add specific scanning for known vulnerable versions of httpclient (currently ${httpclient.version}) and xstream (1.4.21)
• [ ] Configure failure conditions to block PRs if HIGH/CRITICAL vulnerabilities are detected
• [ ] Document results in CONTRIBUTING.md

Create integration tests for Solon plugin multi-module channel configuration

The solon-plugins/wx-java-channel-multi-solon-plugin/ contains AbstractWxChannelConfiguration, WxChannelInJedisConfiguration, and WxChannelInMemoryConfiguration classes but no visible test coverage in the file listing. These are critical for framework initialization and multi-channel support. Tests validating both memory and Jedis-based channel storage are essential for preventing regressions.

• [ ] Create solon-plugins/wx-java-channel-multi-solon-plugin/src/test/java/ directory
• [ ] Add unit tests for WxChannelInMemoryConfiguration testing concurrent channel registration, retrieval, and cleanup
• [ ] Add integration tests for WxChannelInJedisConfiguration mocking Jedis to verify Redis-backed channel persistence
• [ ] Add tests validating AbstractWxChannelConfiguration abstraction works correctly with both implementations
• [ ] Test channel isolation between multiple WxJava service instances running in same Solon application

• Add integration tests for the new transfer API endpoints documented in docs/NEW_TRANSFER_API_USAGE.md—currently lacking test coverage for refund and balance query operations.
• Expand Quarkus support documentation (docs/QUARKUS_SUPPORT.md) with a runnable example Spring Boot + Quarkus demo showing mini-program login and payment workflows.
• Create ThreadLocal audit context cleanup examples in docs/CP_MSG_AUDIT_THREADLOCAL_LIFECYCLE_REFACTOR.md with Spring annotation-based interceptor patterns to prevent memory leaks in high-volume enterprise WeChat deployments.

The WxJava OSGI module has moderate security concerns primarily around outdated dependencies. The most critical issues are: (1) Apache HttpCore 4.4.1 is severely outdated and lacks security patches, (2) XStream 1.4.21 carries deserialization vulnerability risks requiring careful configuration, and (3) unclear dependency version management through variable references. The use of 'provided' scope for critical dependencies shifts security responsibility to consumers. Recommended actions: immediately upgrade HttpComponents to latest stable versions, update XStream and configure deserialization whitelists, clarify all dependency versions in parent POM, and document security requirements for library consumers.

• High · Outdated Apache HttpComponents Dependencies — weixin-java-osgi/pom.xml - httpcore dependency (version 4.4.1). The OSGI module uses Apache HttpCore 4.4.1 (released 2014) and HttpClient versions that may contain known security vulnerabilities. HttpCore 4.4.1 is severely outdated and lacks security patches for issues like request smuggling and other HTTP protocol vulnerabilities. Fix: Upgrade to the latest stable version of Apache HttpComponents (HttpCore 4.4.13+ and HttpClient 4.5.13+ or use HttpClient 5.x series). Review the migration guide in docs/HTTPCLIENT_UPGRADE_GUIDE.md.
• High · XStream Deserialization Vulnerability Risk — weixin-java-osgi/pom.xml - xstream dependency (version 1.4.21). XStream 1.4.21 is used for XML deserialization. While 1.4.21 includes some security enhancements, XStream has a history of critical deserialization vulnerabilities (CVE-2021-21341, CVE-2021-21342, etc.). If untrusted XML is deserialized without proper configuration, it could lead to remote code execution. Fix: Update to the latest XStream version (1.4.20+) and configure a whitelist of allowed classes for deserialization. Avoid deserializing untrusted XML input. Consider using a safer alternative like Jackson if possible.
• Medium · Incomplete Dependency Exclusion Configuration — weixin-java-osgi/pom.xml - xstream exclusions and servicemix dependencies. The pom.xml excludes xmlpull and xpp3_min from xstream but provides them via Apache ServiceMix bundles. While this ensures OSGI compatibility, the approach may inadvertently introduce version mismatches or bypass security updates if not carefully maintained. Fix: Document the rationale for using ServiceMix bundles versions. Regularly audit these bundled versions for security updates. Consider using dependency management to enforce consistent versions across modules.
• Medium · Missing Dependency Version Management — weixin-java-osgi/pom.xml - httpclient and httpmime with variable version. The pom.xml uses ${httpclient.version} property reference without showing the parent pom definition in the provided context. This creates uncertainty about which exact versions are being used, complicating security audits and making it harder to track vulnerable dependencies. Fix: Verify the parent pom.xml (wx-java 4.6.0) specifies explicit, up-to-date versions for all dependencies. Use dependency:tree Maven command to see all resolved versions. Document all version properties in parent POM.
• Low · Wide Scope Dependencies Set to 'provided' — weixin-java-osgi/pom.xml - multiple provided scope dependencies. Multiple critical dependencies (httpcore, httpclient, httpmime, xstream) are marked with scope='provided'. While appropriate for OSGI modules, this means the security responsibility shifts to consumers. If consumers use outdated versions, vulnerabilities may not be caught. Fix: Clearly document in README or CONTRIBUTING.md the minimum versions consumers should use. Consider adding enforcer rules in parent pom to prevent use of vulnerable dependency versions.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/binarywang/WxJava shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live binarywang/WxJava repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/binarywang/WxJava.

What it runs against: a local clone of binarywang/WxJava — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in binarywang/WxJava | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch develop exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 31 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of binarywang/WxJava. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/binarywang/WxJava.git
#   cd WxJava
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of binarywang/WxJava and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "binarywang/WxJava(\\.git)?\\b" \\
  && ok "origin remote is binarywang/WxJava" \\
  || miss "origin remote is not binarywang/WxJava (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify develop >/dev/null 2>&1 \\
  && ok "default branch develop exists" \\
  || miss "default branch develop no longer exists"

# 4. Critical files exist
test -f "pom.xml" \\
  && ok "pom.xml" \\
  || miss "missing critical file: pom.xml"
test -f "others/weixin-java-osgi/pom.xml" \\
  && ok "others/weixin-java-osgi/pom.xml" \\
  || miss "missing critical file: others/weixin-java-osgi/pom.xml"
test -f "solon-plugins/wx-java-channel-multi-solon-plugin/src/main/java/com/binarywang/solon/wxjava/channel/integration/WxChannelMultiPluginImpl.java" \\
  && ok "solon-plugins/wx-java-channel-multi-solon-plugin/src/main/java/com/binarywang/solon/wxjava/channel/integration/WxChannelMultiPluginImpl.java" \\
  || miss "missing critical file: solon-plugins/wx-java-channel-multi-solon-plugin/src/main/java/com/binarywang/solon/wxjava/channel/integration/WxChannelMultiPluginImpl.java"
test -f "solon-plugins/wx-java-channel-multi-solon-plugin/src/main/java/com/binarywang/solon/wxjava/channel/properties/WxChannelMultiProperties.java" \\
  && ok "solon-plugins/wx-java-channel-multi-solon-plugin/src/main/java/com/binarywang/solon/wxjava/channel/properties/WxChannelMultiProperties.java" \\
  || miss "missing critical file: solon-plugins/wx-java-channel-multi-solon-plugin/src/main/java/com/binarywang/solon/wxjava/channel/properties/WxChannelMultiProperties.java"
test -f "solon-plugins/wx-java-channel-solon-plugin/src/main/java/com/binarywang/solon/wxjava/channel/config/WxChannelServiceAutoConfiguration.java" \\
  && ok "solon-plugins/wx-java-channel-solon-plugin/src/main/java/com/binarywang/solon/wxjava/channel/config/WxChannelServiceAutoConfiguration.java" \\
  || miss "missing critical file: solon-plugins/wx-java-channel-solon-plugin/src/main/java/com/binarywang/solon/wxjava/channel/config/WxChannelServiceAutoConfiguration.java"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 31 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/binarywang/WxJava"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.