You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Anil Patel <an...@hotwaxsystems.com> on 2026/07/03 12:52:20 UTC
Proposal for discussion: retiring SOAP support in OFBiz
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
Re: Proposal for discussion: retiring SOAP support in OFBiz
Posted by Chandan Khandelwal <ch...@hotwaxsystems.com>.
+1
Kind Regards,
Chandan Khandelwal
On Sat, Jul 4, 2026 at 11:10 AM Arun Patidar <ar...@hotwax.co> wrote:
> +1
>
> Thanks
> ---
> Arun Patidar
>
>
>
> On Fri, Jul 3, 2026 at 8:03 PM Ashish Vijaywargiya <
> ashish.vijaywargiya@hotwaxsystems.com> 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 <an...@hotwaxsystems.com>
> > 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
> > >
> >
>
Re: Proposal for discussion: retiring SOAP support in OFBiz
Posted by Chandan Khandelwal <ch...@hotwaxsystems.com>.
+1
Kind Regards,
Chandan Khandelwal
On Sat, Jul 4, 2026 at 11:10 AM Arun Patidar <ar...@hotwax.co> wrote:
> +1
>
> Thanks
> ---
> Arun Patidar
>
>
>
> On Fri, Jul 3, 2026 at 8:03 PM Ashish Vijaywargiya <
> ashish.vijaywargiya@hotwaxsystems.com> 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 <an...@hotwaxsystems.com>
> > 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
> > >
> >
>
Re: Proposal for discussion: retiring SOAP support in OFBiz
Posted by Arun Patidar <ar...@hotwax.co>.
+1
Thanks
---
Arun Patidar
On Fri, Jul 3, 2026 at 8:03 PM Ashish Vijaywargiya <
ashish.vijaywargiya@hotwaxsystems.com> 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 <an...@hotwaxsystems.com>
> 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
> >
>
Re: Proposal for discussion: retiring SOAP support in OFBiz
Posted by Arun Patidar <ar...@hotwax.co>.
+1
Thanks
---
Arun Patidar
On Fri, Jul 3, 2026 at 8:03 PM Ashish Vijaywargiya <
ashish.vijaywargiya@hotwaxsystems.com> 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 <an...@hotwaxsystems.com>
> 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
> >
>
Re: Proposal for discussion: retiring SOAP support in OFBiz
Posted by Ashish Vijaywargiya <as...@hotwaxsystems.com>.
+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 <an...@hotwaxsystems.com>
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
>
Re: Proposal for discussion: retiring SOAP support in OFBiz
Posted by Ashish Vijaywargiya via user <us...@ofbiz.apache.org>.
Thank you Mridul!
Thanks,
Ashish
On Thu, 12 Nov 2026 at 06:50, Mridul Pathak via dev <de...@ofbiz.apache.org>
wrote:
> Hi all,
>
> To close the loop on this thread: SOAP and RMI are now removed from trunk
> under OFBIZ-13821 (https://github.com/apache/ofbiz-framework/pull/2617 and
> https://github.com/apache/ofbiz-plugins/pull/520), as part of the wider
> retirement discussed in
> https://lists.apache.org/thread/gsdtr4s6ry2g6v87k8t8xbjlvwhpyg73. The
> upgrade notes in UPGRADING.md cover what changed, including the removed
> namespace element of service definitions, and the REST API is the
> replacement for calling services remotely. Both stay, disabled as before,
> in release24.09.
>
> Thanks,
> Mridul Pathak
>
> On Fri, Jul 3, 2026 at 6:22 PM Anil Patel <an...@hotwaxsystems.com>
> 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
> >
>
Re: Proposal for discussion: retiring SOAP support in OFBiz
Posted by Ashish Vijaywargiya via dev <de...@ofbiz.apache.org>.
Thank you Mridul!
Thanks,
Ashish
On Thu, 12 Nov 2026 at 06:50, Mridul Pathak via dev <de...@ofbiz.apache.org>
wrote:
> Hi all,
>
> To close the loop on this thread: SOAP and RMI are now removed from trunk
> under OFBIZ-13821 (https://github.com/apache/ofbiz-framework/pull/2617 and
> https://github.com/apache/ofbiz-plugins/pull/520), as part of the wider
> retirement discussed in
> https://lists.apache.org/thread/gsdtr4s6ry2g6v87k8t8xbjlvwhpyg73. The
> upgrade notes in UPGRADING.md cover what changed, including the removed
> namespace element of service definitions, and the REST API is the
> replacement for calling services remotely. Both stay, disabled as before,
> in release24.09.
>
> Thanks,
> Mridul Pathak
>
> On Fri, Jul 3, 2026 at 6:22 PM Anil Patel <an...@hotwaxsystems.com>
> 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
> >
>
Re: Proposal for discussion: retiring SOAP support in OFBiz
Posted by Mridul Pathak via user <us...@ofbiz.apache.org>.
Hi all,
To close the loop on this thread: SOAP and RMI are now removed from trunk
under OFBIZ-13821 (https://github.com/apache/ofbiz-framework/pull/2617 and
https://github.com/apache/ofbiz-plugins/pull/520), as part of the wider
retirement discussed in
https://lists.apache.org/thread/gsdtr4s6ry2g6v87k8t8xbjlvwhpyg73. The
upgrade notes in UPGRADING.md cover what changed, including the removed
namespace element of service definitions, and the REST API is the
replacement for calling services remotely. Both stay, disabled as before,
in release24.09.
Thanks,
Mridul Pathak
On Fri, Jul 3, 2026 at 6:22 PM Anil Patel <an...@hotwaxsystems.com>
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
>
Re: Proposal for discussion: retiring SOAP support in OFBiz
Posted by Ashish Vijaywargiya <as...@hotwaxsystems.com>.
+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 <an...@hotwaxsystems.com>
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
>
Re: Proposal for discussion: retiring SOAP support in OFBiz
Posted by Mridul Pathak via dev <de...@ofbiz.apache.org>.
Hi all,
To close the loop on this thread: SOAP and RMI are now removed from trunk
under OFBIZ-13821 (https://github.com/apache/ofbiz-framework/pull/2617 and
https://github.com/apache/ofbiz-plugins/pull/520), as part of the wider
retirement discussed in
https://lists.apache.org/thread/gsdtr4s6ry2g6v87k8t8xbjlvwhpyg73. The
upgrade notes in UPGRADING.md cover what changed, including the removed
namespace element of service definitions, and the REST API is the
replacement for calling services remotely. Both stay, disabled as before,
in release24.09.
Thanks,
Mridul Pathak
On Fri, Jul 3, 2026 at 6:22 PM Anil Patel <an...@hotwaxsystems.com>
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
>