+1

Kind Regards,
Chandan Khandelwal



On Sat, Jul 4, 2026 at 11:10 AM Arun Patidar <[email protected]> wrote:

> +1
>
> Thanks
> ---
> Arun Patidar
>
>
>
> On Fri, Jul 3, 2026 at 8:03 PM Ashish Vijaywargiya <
> [email protected]> wrote:
>
> > +1
> >
> > --
> > Kind Regards,
> > Ashish Vijaywargiya
> > Vice President of Operations
> > *HotWax Systems*
> > *Enterprise open source experts*
> > http://www.hotwaxsystems.com
> >
> >
> >
> > On Fri, Jul 3, 2026 at 6:22 PM Anil Patel <[email protected]>
> > wrote:
> >
> > > Hi all,
> > >
> > > I would like to open a discussion about removing SOAP support from
> OFBiz
> > -
> > > both the SOAP endpoint that exposes our services and the soap service
> > > engine that calls external SOAP services - and I would like to hear
> where
> > > everyone stands before we do anything.
> > >
> > >
> > > Here is where we already are. SOAP is effectively switched off out of
> the
> > > box. The SOAPService endpoint in webtools was commented out in 2021 as
> > part
> > > of OFBIZ-12212 (CVE-2021-30128), alongside the HTTP engine, for
> security
> > > reasons - the same way the RMI engine was commented out back in 2016
> > > (OFBIZ-6942) over the Java deserialization issue. The soap service
> engine
> > > in serviceengine.xml is commented out as well. So on a default build
> > there
> > > is no SOAP in either direction today: we ship the code, but nobody can
> > use
> > > it without deliberately turning it back on against that security
> > guidance.
> > >
> > >
> > > Because it is off and unused, the SOAP and WSDL code has quietly
> > > accumulated a backlog of bugs that nobody fixes. OFBIZ-743 (2007),
> > > OFBIZ-3300 (2009), OFBIZ-4245 (2011) and OFBIZ-6921 (2016) are all
> still
> > > open, some for well over a decade. That is a fair signal in itself: a
> > > subsystem that is disabled, unmaintained, and security-sensitive is a
> > > liability to carry.
> > >
> > >
> > > The wider picture is even clearer. The industry has moved off SOAP,
> > > including the very services OFBiz has historically integrated with.
> FedEx
> > > is retiring its legacy SOAP web services entirely, with the last
> > endpoints
> > > going away in mid-2026, in favor of REST. UPS already turned off its
> > legacy
> > > XML/SOAP APIs in June 2024 and now requires REST with JSON and OAuth
> 2.0.
> > > eBay ended support for its SOAP-era Trading API back in 2021 and points
> > > everyone at its REST APIs. The common thread is REST and JSON with
> OAuth
> > -
> > > lighter, faster, better tooled, and far simpler to consume than SOAP
> > > envelopes and WSDLs. OFBiz has moved the same way, with the REST API
> > plugin
> > > now the modern path for remote access.
> > >
> > >
> > > So my question to the community: is it time to remove SOAP from OFBiz
> > > entirely - the SOAP event handler, the soap service engine, the SOAP
> > > serializer, the WSDL generation, and the related test services - rather
> > > than keep carrying a disabled, unmaintained, security-sensitive
> subsystem
> > > that talks a protocol the ecosystem has left behind? RMI is in a
> similar
> > > disabled-but-still-present state and could reasonably be part of the
> same
> > > cleanup conversation.
> > >
> > >
> > > If anyone is actively using SOAP with OFBiz, or has a reason we should
> > keep
> > > it even in its disabled form, please speak up - that is exactly what I
> > want
> > > to understand before proposing a removal. If we agree it has run its
> > > course, I will raise a Jira issue and take it forward the same way we
> > have
> > > handled other dead code recently.
> > >
> > >
> > > Thanks and Regards
> > > Anil Patel
> > > CEO
> > > HotWax Systems
> > > http://www.hotwaxsystems.com
> > >
> >
>

Reply via email to