| Re: [jakartaee-tck-dev] Platform TCK run started |
Kevin, I was responding to the general comment about supporting legacy applications. Seems that is a broader question than EJB (to me anyway).
-- Ed
Scott,
Since your questions are specific to the EJB tests, I think you should start with the EJB dev team and how they wish to maintain their test buckets. Although there is some overlap between the EJB and Platform teams, this question about the EJB tests should be started with them.
https://accounts.eclipse.org/mailing-list/ejb-dev
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect @ IBM
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
From: Ed Bratt <ed.bratt@xxxxxxxxxx>
To: Scott Marlow <smarlow@xxxxxxxxxx>
Cc: jakartaee-tck developer discussions <jakartaee-tck-dev@xxxxxxxxxxx>
Date: 06/11/2020 09:46
Subject: [EXTERNAL] Re: [jakartaee-tck-dev] Platform TCK run started
Sent by: jakartaee-tck-dev-bounces@xxxxxxxxxxx
I believe we should check with the Platform Committer team. I think that it was concluded that directly migrating legacy applications won't supported without some kind of transformative action.
That could be using the results of the Eclipse Transformer project or it could be something else. Perhaps, for now, we should file an issue and disable these tests until we know what the consensus solution should be. If the answer is do nothing and leave them out, we can just remove the tests and close the issue(s).
Scott, can you summarize the issue(s) here and raise it to the Platform committer (jakartaee-platform-dev@xxxxxxxxxxx) team?
-- Ed
On 6/11/2020 7:11 AM, Scott Marlow wrote:
On Wed, Jun 10, 2020 at 10:22 PM Scott Marlow <smarlow@xxxxxxxxxx> wrote:
On Wed, Jun 10, 2020 at 9:33 PM Ed Bratt <ed.bratt@xxxxxxxxxx> wrote:
I don't know. Since we are trying to get all the name-space issues ironed out --
I created https://github.com/eclipse-ee4j/jakartaee-tck/issues/317that includes validating that any remaining javax.* classes referenced are correct.
I am not sure it will be very worthwhile to try and diagnose problems that crop up after we find there are still name-space issues in the packages. I'd try to get those issues corrected first since they suggest that the Jakartification work isn't quite finished yet.
https://github.com/eclipse-ee4j/jakartaee-tck/pull/316is for updating to the EE 9 XSDs in the tests.
pull/316 is merged. Once https://github.com/eclipse-ee4j/jakartaee-schemas/pull/9is merged, we can also replace http://java.sun.com/xml/ns/j2ee/web-jsptaglibrary_2_0.xsdwith http://jakarta.ee/xml/ns/jakartaee/web-jsptaglibrary_3_0.xsd.
I'll start a new TCK run so we can see if there is any improvement.
https://github.com/eclipse-ee4j/jakartaee-tck/issues/313is open for updating the application archives that contain javax.ejb.SessionBean class references, to use jakarta.ejb.SessionBean. Please also refer to comment https://github.com/eclipse-ee4j/jakartaee-tck/issues/313#issuecomment-642359469that explains how these archives are testing backward compatibility with older EE versions.
In theory, we could run these archives through a bytecode transformer (statically or during the test run), but IMO that isn't really required to be done. For discussion, should we:
a. Transform or rebuild the legacy application archives to reference jakarta.ejb.SessionBean?
b. Remove the testing of these legacy application archives?
c. Something else?
Imo, I think that we have to look deeper to see what we would be losing if we did (b). Is there a viable (c) option?
See discussion on https://github.com/eclipse-ee4j/jakartaee-tck/issues/313. I think that we need to understand if pruning/removing the tests for (c), would require us to open issues for any of the underlying specifications that are tested with any of the mentioned (not built for EE 9) archives, to notify those specification teams that the tests are being removed.
Also, I am wondering if any of Common Applications Deployments can actually be deployed by TSDeploymentInterface deployment mechanism (related documentation stated that TSDeploymentInterface2 is needed). When we removed the Jakarta Deployment tests, we considered whether we need to also remove the Common Applications Deployment support and decided to keep that in place, until we see reasons to fix or remove them.
Scott
-- Ed
On 6/10/2020 2:22 PM, Scott Marlow wrote:
On Wed, Jun 10, 2020 at 4:54 PM Ed Bratt <ed.bratt@xxxxxxxxxx> wrote:
Scott,
In the domain log, of [1], the very first exception trace at line 335 includes javax.security which is probably not correct.
If this isn't expected, I would posit that it could be difficult to interpret results while there are still name-space errors.
Ed,
In that first exception trace, I do see javax.security.auth.Subject, which has almost the same package as https://github.com/eclipse-ee4j/authentication/tree/master/api/src/main/java/jakarta/security/authbut Subject is not there. Subject is still in SE 11+, so any issue here?
Scott
-- Ed
[1] https://ci.eclipse.org/jakartaee-tck/job/jakartaee-tck/job/master/682/artifact/connector-results.tar.gz_______________________________________________
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