[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakartaee-platform-dev] : Re: Review of Platform TCK removal of duplicate Jakarta JSON Binding tests
|
On 3/1/22 12:37 PM, Nathan Rauh wrote:
Scott,
We don’t know understand what the Platform
Specification requirements are here and are trying to learn
that from you and others to identify if we have a gap in our
ability to comply with Jakarta EE 10.
The Platform Specification requirements
are listed here, which I will paste part of:
"
In a full Jakarta EE product, all Jakarta EE
application client containers, web containers, and enterprise
beans containers are
required to support the JSON-B API.
"
The proposed way to meet the above pasted requirements is that
some JSON Binding tests will still be in the Platform TCK. Please
see this
Platform TCK PR/849 commit which shows some of the JSON
Binding tests that may still be run (pending the pull request
being merged).
Your earlier statement that I was asking
about, “every Jakarta EE 10 implementation must pass the
Standalone JSON Binding TCK”, tells me that it will be
necessary for Open Liberty to pass the Standalone JSON Binding
TCK. If that is true, then yes, we need to understand how to
do so because currently Kyle has found it to be impossible.
But if this statement was incorrect and Dmitry’s
interpretation is correct, which we would be fine with, then
there is no need to be able to run the TCK against the EE
server. Please clarify.
The JSON Binding TCK is planning to be a Java SE style TCK. The
instructions for installation can be viewed
via this link (open contained
jsonb-tck/docs/pdf-usersguide/Jakarta-JSON-Binding-TCK-Users-Guide.pdf
file).
Here are some of the
instructions:
"
3. jsonb-impl.groupId
property is set to the Maven Group Id of the CI to test.
4. jsonb-impl.artifactId property is set to the Maven Artifact
Id of the CI to test.
5. jsonb-impl.version property is set to the Maven Version of
the CI to test.
Set the below jars to the classpath
1. JAR file for the JSON Binding 3.0 CI.
jakarta.json.bind-api.jar.
2. JUnit 5 jars (5.7.2+)
3. JSON Binding TCK tests
(jakarta.json.bind:jakarta.json.bind-tck)
And then see configuring the
Maven environment after ^.
IMO, the documentation could
use improvement if anyone is able to contribute to that. For
example, the "Reference Implementation" term should be changed
to "Compatible Implementation (CI)".
Scott
On 3/1/22 11:46 AM, Kyle Aure wrote:
Thanks for your input. You mention
that the Standalone tests can be run against any server,
but from my attempts to get this working in Open Liberty
it seems that all of that functionality has been
removed.
Previously, this TCK was using
Arquillian to deploy tests to an application server for
testing.
Whereas now, all that Arquillian
function has been removed and we just have standard
Junit5 tests that need to be run alongside API and
Implementation dependencies.
If I am missing something please let
me know. Or if you have an example of this TCK running
against an application server please share it with me.
FYI, the Platform TCK will still have a minimal number of
JSON Binding tests but yes, the Standalone JSON Binding TCK
doesn't include EE container tests. Do you see any Platform
Specification requirements that are not being met due to
this? Or is it more that you are trying to understand how to
run Open Liberty against the Standalone JSON Binding TCK?
Scott
Hi,
just to clarify that standalone
tests can be ran against any server thanks the
runner and without any change so I think we cover
all the mentionned case already and implementations
have no blocker at all as already proven by MP and
EE servers.
Scott,
I am not arguing that implementations must run
standalone tests.
Arjan,
standalone JSONB tests are running against the
implementation. It’s the same way how TCK for
MicroProfile specs work.
--
Dmitry
Hi,
It
would be great though if we have easy to run
standalone tests for JSON to test that JSON
works in a Microprofile environment. As far
as I can see, the standalone tests now only
run against the implementation jar, right?
Not against an actual server.
For
instance, if I wanted to test that JSON
works correctly in say Helidon or my own
Piranha Cloud, how would I currently go
about that?
On
2/28/22 7:54 AM, Dmitry Kornilov wrote:
There
are enough JSONB tests in the Platform
TCK to see that integration doesn’t
work.
Dmitry,
Are you arguing that Jakarta EE 10
Platform certification requests should not
include Standalone JSON-B TCK test
results? I agree that there are enough
JSONB tests in the Platform TCK to see
that integration doesn’t work (at all)
but I think the Standlone JSON-B TCK test
could find unexpected problems.
I think that Emily and others have argued
that Jakarta EE 10 Platform certification
requests should include Standalone JSON-B
TCK test results. I think there are more
people in favor of this than those that
are against but we could ask Platform
committers to vote if needed. If the
Platform committers does vote on this
point, it would need to be documented as
so in the Platform TCK User Guide which I
think is the only place where we list
which TCKs must be run for Platform
compatibility certification requests.
From our TCK call, I recall your point
was about eliminating duplicate tests
between Platform TCK and the new
Standalone TCKs, which we are putting into
action via pending Platform TCK pull
requests that need to be reviewed still.
Scott
Thanks,
Dmitry
I
am concerned with this discussion
and the fact that the
implementations do not need to or
can't run the standalone tests in
JSON-B. Let's give you an example.
If
a runtime A uses Yasson for their
JSON-B 3.0 implementation and it
does not integrate well with
Yasson, it should not be able to
claim certification for JSON-B
3.0. However, since JSON-B
standalone TCK is not
required/able to be executed, how
can we verify whether a runtime is
JSON-B 3.0 compatible? As for the
platform integration tests, I
don't think it is sufficient to
cover the full picture as they
focus on how to interact with
other Jakarta EE specs.
On
2/24/22 3:49 PM, Nathan Rauh
wrote:
Scott,
Do
you mean to instead say that
“every
JSON-B 3.0
implementation must pass the
Standalone JSON Binding TCK”
?
When
phrased as, “every
Jakarta EE 10
implementation must pass the
Standalone JSON Binding
TCK”, (below) it is
unachievable for application
servers because the
arquillian support is gone
from the Standalone JSON
Binding TCK leaving no way
to run it in a container
(The issue raised by Kyle).
Every JSON-B 3.0 implementation
must still pass the Standalone
JSON Binding TCK, that is
certainly true and wouldn't
change.
Application servers should be
able to pass the Java SE style
tests in the Standalone JSON
Binding TCK, with the JSON-B
SPEC API + implementation that
they are using.
There will also be a set of
Platform TCK tests that verify
that JSON-B can be used in the
required EE containers. From
the feedback so far, the number
of Platform TCK JSON-B tests
should be small to minimize code
duplication between the TCKs.
Scott
Updated
as per feedback from
Brian Decker:
We need to verify
that the Jakarta
EE 10 Platform
requirements for
use of JSON
Binding API are
met by reviewing
the [1][2] pull
requests. Wiki
[3] has notes on
the Platform
requirements. In
summary, every
Jakarta EE 10
implementation
must pass the
Standalone JSON-B
TCK which
validates that
Application
Client, Servlet,
Server Pages, and
Enterprise Beans
can use the JSON
Binding API
successfully.
Correction:
In summary, every
Jakarta EE 10
implementation must
pass the Standalone
JSON Binding TCK which
validates the JSON
Binding implementation
can pass the JSON
Binding TCK
successfully.
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing
list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list,
visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
--
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
