We do want to encourage compatible implementations, but we
also want a consistent definition of compatibility. If you're not
actually passing the approved TCK, you're not compatible, no matter
whether you disclose your workarounds or not.
Clearly we want Open Liberty to be Jakarta EE 8 compatible, but I'm
trying to understand what's preventing it from being compatible when
WebSphere Liberty is Java EE 8 compatible. Did we make a mistake
somewhere in our TCKs? Are we applying different criteria? Or is
there some technical difference between Open Liberty and WebSphere
Liberty that's exposing flaws in the Jakarta EE TCKs?
Kevin Sutter wrote on 9/3/19 10:18 PM:
We put the
additional
Challenge information in the Certification Request because I
thought it
completed the informational package. We could have left that
information
out and nobody would have questioned anything. All of the
posted
results would still have indicated zero failures. Should we
just
remove that challenge information from the CR? We provided this
information
to be open, not to invite scrutiny. I would think we want to
encourage
compatible implementations...
---------------------------------------------------
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:
Bill
Shannon <bill.shannon@xxxxxxxxxx>
To:
Jakarta
specification committee
<jakarta.ee-spec.committee@xxxxxxxxxxx>,
Kevin Sutter <sutter@xxxxxxxxxx>
Date:
09/03/2019
06:12 PM
Subject:
[EXTERNAL]
Re: [jakarta.ee-spec.committee] Open Liberty compatibility
issues
Did you submit test challenges
against
Java EE 8 that were approved?
Has the Java EE 8 TCK moved forward since we contributed it to
Jakarta
EE and so we're just out of sync?
I don't know what you mean by "Weld performed that testing".
Do you mean that the standalone version of Weld was tested with
the Dependency
Injection TCK, and you just incorporated that already tested
version of
Weld?
If you're just using Weld unchanged, you should be able to run
the Dependency
Injection TCK against it yourself. Does that not work?
Of course, if you're using Weld unchanged, and Weld was already
tested
with the Dependency Injection TCK, there's not much point in you
testing
it again.
Kevin Sutter wrote on 9/3/19 3:22
PM:
Bill and
others,
The first two (JSF and JSON-B) are just documenting the same
issues that
we ran into with testing Java EE 8 with WebSphere Liberty. The
issues
were "lost" in the move, so we wanted to document the problems.
We fully understand that these can't be real TCK Challenges yet
since
none of this is final. We just wanted to document the issues
and
indicate that we're following the same workarounds that we did
for WebSphere
Liberty.
The third one is new and kind of unique. Open Liberty uses Weld
(RI
for Java EE CDI). We did not run the standalone DI TCK in the
past
because Weld performed that testing. So, I would assume that
this
approach would be sufficient for Jakarta EE as well. Because as
you
said, getting this DI TCK to run in a Jakarta EE container would
be a non-trivial
task.
---------------------------------------------------
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: Bill
Shannon <bill.shannon@xxxxxxxxxx>
To: Jakarta
specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Date: 09/03/2019
04:29 PM
Subject: [EXTERNAL]
[jakarta.ee-spec.committee] Open Liberty compatibility issues
Sent by: jakarta.ee-spec.committee-bounces@xxxxxxxxxxx
I'm not sure this is the right place for this discussion.
Please
let me know if you think this should be moved to the
platform-dev mailing
list or elsewhere.
At the end of the Compatibility
Certification Request for Open Liberty,
it lists these issues:
Relevant challenges & resolution:
Signaturetest - Implemented work around to allow testing of
remaining packages.
eclipse-ee4j/faces-api#1474
JSONB - Excluded tests.
eclipse-ee4j/jsonb-api#180
DI TCK requires SeContainer
javax-inject/javax-inject#39
Since we've committed that the Jakarta EE 8 TCKs will be
identical to the
Java EE 8 TCKs, we can't fix any of these issues in the TCKs for
the Jakarta
EE 8 release. We can consider these as TCK challenges after the
Jakarta
EE 8 release is approved, and release updated TCKs to address
the challenges
per our process, soon after Jakarta EE 8.
Do you agree?
The first item in the list above is problematic...
It's a signature test issue. For Java EE, we would release an
alternate
signature test, to allow products to pass either the original or
updated
signature test. For Jakarta EE we decide we would not create
alternate
tests. We can't exclude the signature test. If we update the
signature test, products that have passed the existing Jakarta
EE 8 TCKs,
and all Java EE 8 products, will fail the updated test and thus
won't be
Jakarta EE 8 compatible.
How would you like to handle such a case?
For the second item in the list above, it seems that we've
agreed to exclude
the challenged tests. An updated version of the JSONB TCK can
be
produced soon after Jakarta EE 8. We can use this as a test
case
for how to approve an update to a TCK without a corresponding
spec update.
Can someone describe the process for approving a TCK update
without a corresponding
spec update?
The third item in the list above was filed only recently and
hasn't been
evaluated. If I understand it correctly, the Dependency
Injection
TCK assumes that you have a "standalone" implementation of
Dependency
Injection, and can thus test it outside of a Jakarta EE
container.
That's clearly not a requirement of Jakarta EE, nor of Java EE.
I
assume this challenge was filed for Open Liberty because it
doesn't not
include a Dependency Injection implementation that can be used
outside
of the Jakarta EE containers.
WebSphere Liberty is Java EE 8 compatible, how did it run the
Dependency
Injection TCK? Is Open Liberty using a different Dependency
Injection
implementation?
Converting the Dependency Injection TCK to be able to work
inside a Jakarta
EE container is likely a non-trivial task. Excluding all of the
Dependency
Injection tests seems unacceptable.
How would you recommend that we address this test challenge?
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
|
