| Here is some feedback I am getting from our various server leads with respect to these ballots:
JSR 109 - they would like this be retained as an optional specification. It defines behavior and has no actual API so the javax->jakarta transition is not relevant to as you said, but it's related to JAX-WS so treat the whole set the same and b) the platform TCK provides value to us.
On the addition of JAXB and JAF, It's either a No because we don't want any additions, or a No because we also want the WS specs added as optional since their dependency on JAXB/JAF creates the potential for inconsistent handling across vendors.
Hi Mohamed,Those are fair
questions/concerns. We know there are many, many customers that use
JAX-WS and SOAP. The question at hand is whether these APIs are expected
to evolve. If these APIs will need to be updated in the future, then
they will have to move to the jakarta.* namespace. We can no longer
evolve any of the javax.* APIs. So, we're trying to figure out whether
some of these APIs can be "capped" at their current level of
functionality.Application Servers
can continue to provide solutions based on JAX-WS and SAAJ (SOAP), but
they will be based on the current javax.* API. They are not being
proposed to move to the jakarta.* namespace.Your other question
about which APIs are actually being discussed is also valid. We've
had several discussions within IBM to ensure that we're all on the same
page... :-)- javax.xml.ws (JAX-WS),
JSR 224
- javax.xml.soap
(SAAJ, SOAP), JSR 67
- javax.jws (Metadata),
JSR 181
Also, note that
JSR 109, Enterprise Web Services, is currently part of Jakarta EE 8. This
Spec doesn't have a corresponding API, so there's no package name to point
at. This Spec is part of the discussion to prune/remove from Jakarta
EE 9.Hope this helps.
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutterFrom:
"Mohamed
M. El-Beltagy" <melbeltagy@xxxxxxxxx>To:
jakartaee-platform
developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>Date:
11/21/2019
18:31Subject:
[EXTERNAL]
Re: [jakartaee-platform-dev] VOTE: Specifications to add in Jakarta EE
9Sent
by: jakartaee-platform-dev-bounces@xxxxxxxxxxx
Just for clarification,
by saying JAX-WS to include/drop from Jakarta EE 9, we are actually talking
about Jakarta XML Web Services (https://projects.eclipse.org/projects/ee4j.jaxws)Or, to be
more specific, we are talking about dropping SOAP web services (as I keep
reading that this is the dream)?If SOAP is
not being dropped, please accept my apology and skip the rest of this email.If dropping
SOAP is actually what we are talking about here, then:Without going
into much details that I am not allowed to talk about, I know for a fact
that SOAP is heavily used in Middle East (Egypt, KSA, Oman, UAE and others).
Most of those projects are monstrous systems (not just products) in place
that took years to build using multiple products of multiple vendors and
I doubt that they will go away anytime soon.Since I do
not have exact data, all I can do is ask a specific question targeting
vendors with major clients in those areas. Based on the nature of the clients
I am talking about, my question is targeting Oracle, IBM and SAP with the
application servers and integration tools they provide (IBM WAS, BPM, IIB
and SOA Suite to name a few).You know,
roughly, how many clients you have in those regions that still rely on
SOAP heavily.Based on that
info, do you still think that dropping SOAP support from Jakarta EE will
be the correct decision for those customers?I am not talking
from vendor's perspective. I am talking from end-users perspective.And to be
fair, most of those clients will follow what ever direction vendors tells
them, some out of trust and other out of having no choice.And yes, I
meant vendors as they, unfortunately, don't know about the community
or the specs. They just care about the end product.If you think
that my question is irrelevant or stating wrong facts, please accept my
apology for wasting your time. Best regards,Mohamed ElbeltagyOn
Friday, November 22, 2019, 12:21:01 AM GMT+2, Ondro Mihályi <ondrej.mihalyi@xxxxxxxxx>
wrote: If
the consensus is that JAX-WS shouldn't be a required spec for JakartaEE
9, is there a problem to evolve JAX-WS as an optional spec? We can migrate
JAX-WS to the jakarta namespace and still keep it outside of JakartaEE
umbrella, am I wrong?I
think that way all the legacy solutions could adopt JakartaEE 9 and still
support their current users/customers with JAX-WS, while at the same time
new JakartaEE implementations wouldn't need to support it. OndroDňa
št 21. 11. 2019, 15:11 Kevin Sutter <sutter@xxxxxxxxxx>
napísal(a):Scott,
This is exactly what we're struggling with in our discussions at IBM. We
have many existing JAX-WS customers. So, if we move JAXB to the jakarta
namespace, but not JAX-WS, then we will have two different JAXB APIs to
support. But, we also recognize that JAX-WS is a legacy technology
that probably shouldn't be part of the long term plans for Jakarta.
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
From: Scott
Stark <starksm64@xxxxxxxxx>
To: jakartaee-platform
developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Date: 11/21/2019
03:04
Subject: [EXTERNAL]
Re: [jakartaee-platform-dev] VOTE: Specifications to add in Jakarta EE
9
Sent by: jakartaee-platform-dev-bounces@xxxxxxxxxxx
There still could be an update of JAX-WS to match the JAXB package changes
without JAX-WS being an official part of EE 9 I suppose. JAX-WS is certainly
a legacy tech that I would not expect customers to want to have to update
their use for JAXB changes, but it could be beneficial to porting layers
to have a JAX-WS release that allows for a runtime to make use of a single
EE 9 based JAXB implementation.
> On Nov 20, 2019, at 1:58 PM, Bill Shannon <bill.shannon@xxxxxxxxxx>
wrote:
>
> If JAX-WS is not in EE 9, and a product that implements EE 9 wants
to also support JAX-WS, that that product would need to satisfy the dependency
on JAXB. It could provide both javax.xml.bind and jakarta.xml.bind
APIs, or it could use one of the backwards compatibility approaches to
map javax.axml.bind APIs to jakarta.xml.bind APIs.
>
> But yes, having two implementations would make it hard to share binding
classes.
>
> Andy McCright wrote on 11/20/19 11:19 AM:
>> Would this also require adding the JAX-WS APIs to the EE9 spec?
>>
>> The JAX-WS APIs that have been removed from the JDK currently
have a dependency on JAXB. If we evolve JAXB in EE9 (or just rename
the packages), then we have some specs (like JAX-RS and maybe JPA, etc.)
that depend on the jakarta.xml.bind.* packages while others (JAX-WS) that
would depend on the javax.xml.bind.* packages. That would certainly make
it difficult for EE9 applications to use both a JAX-RS and JAX-WS frontend
that shares the same XML binding classes.
>>
>> Thanks, Andy
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________ jakartaee-platform-dev mailing list jakartaee-platform-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
|
