What It Is#
Soap4R-ng is a maintained fork of the classic soap4r Ruby gem — the de-facto SOAP client/server library for Ruby for many years. When the original project went dormant and Ruby moved past 1.8, a large number of enterprise Rails projects that depended on SOAP web services were left with an unmaintained dependency and growing compatibility debt.
Soap4R-ng was created to close that gap.
What It Does#
- Full Ruby 1.8 → 4.0+ compatibility
- Pluggable XML parser support: Ox and Nokogiri as faster, lower-memory alternatives to the default
- Maintained backward API compatibility so existing soap4r consumers could drop it in without code changes
Why I Built It#
In a previous consulting engagement I was maintaining a large Ruby on Rails back-end that integrated with several legacy enterprise SOAP services — think insurance carriers, healthcare systems, EDI pipelines. When the upstream soap4r gem went abandoned and Ruby 2.x broke it, the options were: rewrite all the integrations, or fix the library. Rewriting wasn’t feasible on the timeline. Fixing it was.
The result became the dependency for several production systems and eventually got published as a gem so other teams in the same boat could use it.
Status#
Most modern Ruby projects have moved on to REST/JSON, so this isn’t in active feature development — but “quiet” doesn’t mean “abandoned.” For years, a Travis CI badge and a Code Climate badge sat at the top of the README — the standard way an OSS Ruby project of that era signaled to prospective users “here’s your evidence this is trustworthy,” covering build status across the version matrix and maintainability/coverage respectively. As Travis’s free OSS tier faded and Code Climate wound down its free quality checks for open source, that signal quietly went dark — not because the tests themselves were wrong, but because the services reporting on them stopped being viable. Release 2.1.0 (July 2026) replaces that with GitHub Actions as the CI/CD platform, and is proof: the test suite now runs green across every Ruby version the gem claims to support — 1.8.7 through 4.0.5, plus JRuby 9.4 and 10.1 — with a small, deliberate, and documented set of exceptions (a shared non-bug quirk on three patch versions, and a couple of known environment differences on 1.8.7 and JRuby) allowed to fail instead of being hidden. Docker is what keeps a local developer workstation honest against that CI: by default, GitHub Actions runs each version — including JRuby — against the standard official Docker Hub Ruby images, so local testing runs against those same images rather than trusting a differently-provisioned runner. For the handful of legacy versions where the standard images don’t work, a proper custom Docker recipe proves it can still be made to work: one Dockerfile builds Ruby 1.9.3 and 2.0.0 from source via rbenv (their official images predate a Docker manifest format modern Docker/containerd no longer knows how to pull), and another builds 1.8.7 from source against a vendored OpenSSL, since 1.8.7 never had an official image at all.
Getting there surfaced two genuine, longstanding bugs — not soap4r bugs, but bugs in how the test suite tore itself down: a Thread#kill race against WEBrick’s own shutdown that could leak a bound port and hang CI intermittently, and an SSL test that spawned its server through an unnecessary shell hop, silently defeating Process.waitpid and adding a spurious 5-second stall to every run. Both are fixed. The release also strips out several classes of deprecation noise that had built up across the version matrix (frozen_string_literal, mutex_m, and default-gem relocation warnings on 3.4/4.0) and adds an options argument to the XSD Mapper/Mapping methods.
A library written for Ruby 1.8 having a matrix that’s green on Ruby 4.0 — with its known exceptions labeled rather than swept under the rug — is exactly the kind of unglamorous work that keeps a 15-year-old dependency trustworthy for whoever still needs it.
Language: Ruby
Repo: github.com/rubyjedi/soap4r
Latest release: 2.1.0