[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakarta.ee-spec.committee] Open Liberty compatibility issues
|
For the record, WebSphere Liberty *did not* successfully challenge the
JSF signature test; that test challenge was rejected. If you believe
you have evidence to the contrary, I would like to see it.
Alasdair Nottingham wrote on 9/4/19 6:53 AM:
> Hi Bill,
>
> WebSphere Liberty successfully challenged both the JSF and the JSON-B tests for Java EE 8 that we are challenging for Jakarta EE 8. Given that Jakarta EE 8 is supposed to be compatible with Java EE 8 I think it is reasonable and fair to have successful Java EE 8 challenges grandfathered into Jakarta EE 8.
>
> With regard to the DI tests it is exactly as you describe in your email from last night. We ship Weld, weld passes the TCK, there is not much point in us testing it again.
>
> Thanks
> Alasdair
>
>> On Sep 4, 2019, at 2:06 AM, Bill Shannon <bill.shannon@xxxxxxxxxx> wrote:
>>
>> 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
>>>
>>>
>>>
>>>
>>
>> _______________________________________________
>> 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
>
