Add minimal configuration for integration tests

[BalusC]

Also added IT tests for #5460 and #5464 and spotted one more place where #5464 should be fixed.

NOTE: the technical reason for adding back the IT config to Mojarra project is because we CANNOT add new tests to the TCK of an already-released Faces version. We can only add them for the next Faces version. But this also means that these won't be executed when the current version is being patched/bugfixed. Hence we can only add them to the Mojarra project. Once a next TCK version is to be prepared we can simply move them from Mojarra into Faces project for TCK.

[mnriem]

Would you consider using Playwright instead of Selenium?

[BalusC]

Would you consider using Playwright instead of Selenium?

I wasn't aware of this possibility. I'm familiar with Playwright itself, but only in Node.js projects. I'll therefore need more time to figure out how to use it in Java projects.

[pizzi80]

I tried Playwright with Java yesterday after reading this conversation... prepare 2 Gbyte of free space... it needs a whole Ubuntu 20.x + many other libraries 😲

[BalusC]

Can we please move forward and decide whether to use Selenium or Playwright? I don't want being unable to add tests for Faces for a long time again. I've already been waiting almost one year for a working 5.0 TCK jakartaee/faces#1852 I simply picked Selenium because it's also being used in TCK so we can easily move integration tests from Mojarra to Faces project without changes when a next TCK version is to be released. If we decide to use Playwright then TCK must be adjusted to support it as well else we need to rewrite tests from Playwright to Selenium while moving them from Mojarra to Faces project. I was since the API/TCK split already forced to do Mojarra bugfixes without being able to verify them with new integration tests in CI and it's really putting me off now.

[mnriem]

I mentioned Playwright merely because I like the Trace Viewer. If Selenium has something as capable then sure go with Selenium

[BalusC]

Selenium uses OpenTelemetry.

I'll move forward and merge nonetheless. The long term goal is that any new tests added here should be able to run in TCK project as well without further modification. If we want to use PlayWright then TCK has to be migrated first.

[mnriem]

Does OpenTelemetry with Selenium have the ability to step through the request like Trace Viewer?

[BalusC]

Unsure. I've never used it. I normally just use the IDE debugger.

[pizzi80]

My 2 cents:
"Keep it simple" ... Selenium it's a simple Java dependency and it works out of the box ...
PlayWright seems like a Microsoft product... don't know what will be in the next 10 years

[mnriem]

And so is Playwright:

         <dependency> 
            <groupId>com.microsoft.playwright</groupId>
            <artifactId>playwright</artifactId>
            <version>${playwright.version}</version>
            <scope>test</scope>
        </dependency>

It is open-source just like Selenium

[arjantijms]

I personally don't care much about using either Selenium or Playwright. At the time someone just started using Selenium, and it does the job AFAIK.

We did had issues with Chrome/Chromium on the (Eclipse) CI, which were eventually resolved by using a custom pipeline based on the eclipsecbijenkins/basic-ubuntu-chrome:latest image. See https://ci.eclipse.org/jakartaee-tck/view/EFTL-Certification-Jobs-11/job/11/job/standalone-tck/job/jakarta-faces-tck-glassfish/configure

For Playwright to be used instead we have to see if it will run on that particular image and it doesn't use another image. We also have to rewrite the existing tests that use Selenium to use Playwright then.

I'm not deep enough in the actual frontend tests to be able to say how much work that will be, but obviously someone needs to do that. It's not a simple change of a dependency, is it?

[pizzi80]

This PR is not only about test,
I found that the original ticket was about special char problems
during ajax request

https://stackoverflow.com/questions/78770904/browsers-behavior-utf-8-page-with-extra-character-like-ufffe-error-by-ajax-x

but, this fix has the downside that is no more possible to save
a String with emojis because the following function removes them from xml response:

I think that the root cause is inside HtmlUtils:

HtmlUtils.isAllowedXmlCharacter <-- blocks emoji

[pizzi80]

I've fixed it on my fork

but it fails the following sub-test,
I don't know what kind of special chars are they...

for (int c = 0xD800; c <= 0xDFFF; c++) {
  assertFalse(isAllowedXmlCharacter(c));
}