| Re: [jakartaee-tck-dev] Platform TCK run started |
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 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/317 that 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/316 is for updating to the EE 9 XSDs in the tests.
pull/316 is merged. Once https://github.com/eclipse-ee4j/jakartaee-schemas/pull/9 is merged, we can also replace http://java.sun.com/xml/ns/j2ee/web-jsptaglibrary_2_0.xsd with 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/313 is 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-642359469 that 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/auth but Subject is not there. Subject is still in SE 11+, so any issue here?
Scott