Re: [jakartaee-tck-dev] [External] : Re: Is TCK compliance required by d

[Joakim Erdfelt <joakim.erdfelt@xxxxxxxxx>]

Just an observation that might be relevant.

Most Servlet Container implementations have default configurations that favor compliance to modern protocol specs, up to date browsers, recent ssl/tls settings, and even configuration decisions that favor performance over compliance.

But the Servlet TCK tests for everything, even historical things, just to ensure compliance.

The Eclipse Jetty project has to configure a "non-real-world" scenario to pass the Servlet TCK fully.

IIRC, There are specific elements of the Servlet TCK that are flagged as ambiguous, so that you can pass the TCK even if your interpretation of these specific tests are "mostly correct".

The state that the Servlet TCK is in is mostly a combination of the sheer age of the Servlet Spec and external factors (the rest of the world moving faster than the Servlet Spec and TCK can keep up).

- Joakim

On Wed, Dec 8, 2021 at 5:56 PM Scott Stark <starksm64@xxxxxxxxx> wrote:

I would argue your understanding is correct. I would also argue that any 'default' mode is irrelevant and an obsolete.

On Dec 8, 2021 at 5:50:53 PM, Lukas Jungmann <lukas.jungmann@xxxxxxxxxx> wrote:

On 12/8/21 9:09 PM, Scott Stark wrote:

Where is there a statement that says a project must pass an individual

TCK out of the box?

well, IMO it's more about the opposite case - where it is said, the
project can use custom settings to pass the TCK, since the tck license
in point 2[1] explicitly says:

"Only those modifications expressly permitted by the TCK and its
documentation are permitted. Except in these limited circumstances, no
modifications to the TCK are permitted under this license."


so the answer to my original question seems be always in the UG of the
particular tck. In this case, there is "Set the [..] property to include
any implementation-specific settings that need to be passed to the
provider when the [factory] is created."[2]

And I think that answers my original question as this says nothing about
what these "implementation-specific settings" can or cannot do, so in
this case it is allowed. Is my understanding correct?

Would it make sense to request these "implementation-specific settings"
to be listed in the CCR? Or is it considered enough that "the compatible
mode" is documented on the product's page?

thanks,
--lukas

[1]: https://www.eclipse.org/legal/tck.php
[2]:
https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/user_guides/jpa/src/main/jbake/content/config.inc#L78

The most I ever remember was this being a statement for platform and

profile TCKs.

On Dec 8, 2021 at 1:59:25 PM, Lukas Jungmann <lukas.jungmann@xxxxxxxxxx

<mailto:lukas.jungmann@xxxxxxxxxx>> wrote:

> On 12/8/21 8:56 PM, Scott Marlow wrote:

>>

>> On 12/8/21 1:16 PM, Lukas Jungmann wrote:

>> > On 12/8/21 6:04 PM, Scott Stark wrote:

>> >> I believe this has been relaxed to effectively some configuration as

>> >> there is no discussion of this in the TCK process:

>> >> https://jakarta.ee/committees/specification/tckprocess/

>> <https://urldefense.com/v3/__https://jakarta.ee/committees/specification/tckprocess/__;!!ACWV5N9M2RV99hQ!aluIde86Iogvp9XbuBA4DGONu9s3vzmXScgwfhnGD5xDHrXdvNSUsbmEbNt1JHPVC-w$>

>>

>> >>

>> <https://urldefense.com/v3/__https://jakarta.ee/committees/specification/tckprocess/__;!!ACWV5N9M2RV99hQ!b26NLrg_lDo2FbedfEg1sB7MQVUtbO7oRp61i5676CjynH9BiQhyfWM_EztqHS42Q2M$

>> <https://urldefense.com/v3/__https://jakarta.ee/committees/specification/tckprocess/__;!!ACWV5N9M2RV99hQ!b26NLrg_lDo2FbedfEg1sB7MQVUtbO7oRp61i5676CjynH9BiQhyfWM_EztqHS42Q2M$>>

>> >>

>> >> If the platform user guide says otherwise, I think that should be

>> >> changed.

>> >

>> > there are also standalone TCKs. Do you think it would make sense to

>> > make the "some configuration" explicit in the TCK process or is it

>> > expected that non-platform TCKs can define this differently?

>>

>> Is this for new TCKs that we are creating?

>

>

> no, see the background at:

> https://github.com/eclipse-ee4j/jpa-api/pull/341

> <https://urldefense.com/v3/__https://github.com/eclipse-ee4j/jpa-api/pull/341__;!!ACWV5N9M2RV99hQ!aluIde86Iogvp9XbuBA4DGONu9s3vzmXScgwfhnGD5xDHrXdvNSUsbmEbNt1F01MOFk$>

>

> --lukas

>

>>

>> For existing Standalone TCKs, we already have some variations between

>> configuration property names in the ts.jte files (e.g. typical pattern

>> is to have a `$technologyname.home` variable, such as `jaxws.home` or

>> `javaee.home`) which means we have defined this differently in the past.

>>

>> Scott

>>

>> >

>> > thanks,

>> > --lukas

>> >

>> >>

>> >> On Dec 8, 2021 at 10:36:00 AM, Lukas Jungmann

>> >> <lukas.jungmann@xxxxxxxxxx <mailto:lukas.jungmann@xxxxxxxxxx>

>> <mailto:lukas.jungmann@xxxxxxxxxx

>> <mailto:lukas.jungmann@xxxxxxxxxx>>> wrote:

>> >>> Hi,

>> >>>

>> >>>    under Java EE, there is/was the rule that to claim a

>> compatibility,

>> >>> a product must pass TCKs in product's default configuration. Is there

>> >>> the same requirement to claim compatibility under Jakarta EE or

>> was it

>> >>> relaxed to say "a product must pass TCK in _some_ configuration"? The

>> >>> question is about default vs some configuration of a product to pass

>> >>> TCK

>> >>> tests under Jakarta EE.

>> >>>

>> >>> thanks,

>> >>> --lukas

>>

_______________________________________________

jakartaee-tck-dev mailing list

jakartaee-tck-dev@xxxxxxxxxxx

To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev__;!!ACWV5N9M2RV99hQ!aluIde86Iogvp9XbuBA4DGONu9s3vzmXScgwfhnGD5xDHrXdvNSUsbmEbNt1PLqmQ7A$

_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev

_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev