Apologies for not being across all the discussions but are other implementations also failing the relevant tests or is this a GlassFish issue?
It's nearly 100% a matter of the tests not being properly refactored, and so it's not a GlassFish issue. I've gone through a few hundred EJB tests myself, and zero changes in GlassFish were needed to make those eventually pass again.
What happened is that tests were automatically refactored using OpenRewrite and some other tooling. For thousands of tests this worked perfectly, but in several hundreds of them they failed after the refactoring.
The causes are mostly small things like a double slash in some URL paths, or a trailing comma somewhere. Also some descriptor files got the wrong names after the automatic refactoring, or some classes were missing in the generated archives. Sometimes you recognize patterns, and a new failing test is easily fixed. At other times things are completely new or unique. E.g. a Javatest that deployed two wars which worked fine using Javatest, but using Arquillian if you deploy two wars you can't obtain something called a "deployment context", and one of the custom Arquillian protocols depends on exactly that.
Kind regards,
Arjan Tijms
--
|
Steve
Millidge
Founder
&
CEO
|
Looks like even in Jakarta EE 11 platform, we could make App Client and Remote EJB optional. If we do that, the TCKs for these areas would be eliminated.
And, even if they were allowed, they would still need to be covered by the TCK and implemented by at least one implementation.
It is, however, possible to deprecate the app client, and by that (sort of) making the test coverage less relevant.
Anyway, as we learned in the Platform call yesterday, it is _not_ testing the app client itself that is the issue. Those tests pass and are fine.
The issue is the _usage_ of the app client in the TCK for testing other areas (such as JPA).
Thanks for confirming. This indicates another endorsement of being able to release Web Profile separately from Platform Profile.
The only references are in the CDI EE integration part of the specification that is now part of the platform spec.
Please do that and get back to us.
I believe that app client is entirely in the platform, but need to double check CDI for mentions.
At the 2024-11-26 Platform Project call, an idea was surfaced, I think originally by Ivar, to not wait until EE 12 to mark the Application Client as deprecated in the Platform Profile.
This thread is intended to discuss and determine the feasibility of this idea.
The most important questions seem to be:
·
Can this be done without making any changes to any of the component specifications?
·
Can this be done entirely and completely by making changes only to the Platform Profile specification text?
_______________________________________________
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
--
Ivar Grimstad
Jakarta EE Developer Advocate |
Eclipse Foundation
Eclipse Foundation - Community. Code.
Collaboration.
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev