Kevin Sutter wrote on 11/25/19 1:14 PM:
> It
should really be all or nothing.
Does that
include
JAXB? I think that's what is pulling in the SOAP web services
support
due to the tight coupling between JAX-WS and JAXB. If we do not
include
JAX-WS, then existing app servers need to support multiple
versions of
the JAXB APIs.
No, XML is independent of and useful without SOAP.
> Perhaps
those who feel a strong market need for SOAP web services should
propose
a SOAP profile as a superset of Jakarta EE 9 and add the SOAP
support there?
Maybe there's
a compromise here... Could this SOAP profile come after Jakarta
EE
9?
Yes.
What if we
continue with the proposals as currently defined to
basically drop all of the SOAP Web Services Specs for Jakarta EE
9. Then,
if a need is determined, then allow someone to propose a SOAP
web services
profile for Jakarta EE 10 to add these back in?
In theory, they could even propose a profile based on Jakarta EE 9,
assuming nothing in the base Jakarta EE 9 full platform spec would
need to change in order to support that profile. It could just be a
complete layer on top of Jakarta EE 9.
Fully understand
the resource burden with maintaining the artifacts associated
with SOAP
web services. Even bringing the TCKs up to snuff with the
current
Jakarta EE TCK execution requirements would be a large effort.
Yup. Who wants it bad enough to do all that work?
To be clear, some of us are going to need to support JAX-WS et. al.
in our Jakarta EE 9 products, and will do so using the code
contributed to EE4J. The difference is between maintaining the
existing code to support existing customers, vs. enhancing the
specs, TCK, and code to support new customers. It's the latter that
requires new Jakarta specs, and for which I don't see a lot of
interest.
|
