Hi Mark, On TomEE side (and other spec impl ones) we had a hybrid approach:
* Add arquillian container properties when reusable (ex: context customization for tomcat for ex) * Add a custom tck loadableextension (ServiceLoader for arquillian) which overrides the container for the specific tck suite Overall any scanning must be hybrid between container and app with embedded container in arquillian approach (in openwebbeans/tomee we configure the resources we can read from container or not for ex!). So I think the easiest would be to just make the context and loader configurable from arquillian.xml for this particular case or if not willed, let tomcat-tck module patch the default container to do it programmatically specifically for tck runner. Kind of least worse compromise IMHO. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le ven. 16 juin 2023 à 17:11, Mark Thomas <ma...@apache.org> a écrit : > Hi all, > > The Jakarta TCK project is in the process of refactoring the TCKS to run > with JUnit 5 and Arquillian. I have tested early versions of the > refactored EL and WebSocket and things are very promising. The TCKs > complete a LOT faster. > > I hit upon a small niggle with the WebSocket TCK and wanted to get some > feedback on solutions. > > The way the WebSocket TCK is constructed, it exposes the entire > testsuite on the class path, as well as the current WAR file under test. > The annotation scanning therefore picks up all the tests, attempts to > deploy them all which - unsurprisingly - fails due to path conflicts. > The fix is to set StandardJarScanner.scanClassPath to false. The > question is how best to do this long term. > > My current solution is to change the default, rebuild Tomcat 10.1.x > snapshot, deploy it to my local Maven repository and then run the TCK > with the snapshot. That works but isn't a viable long-term solution. > > Other ideas I have had: > > Add a system property (yuck) to set the default for > StandardJarScanner.scanClassPath. I don;t like this because a) it adds a > system property and b) it isn't scalable if there are other settings we > need to configure for the TCKs. > > Update the Arquillian containers to add new configuration properties. > Better, but dependent on the Arquillian project for Tomcat containers > that is looking dormant. Forking is an option but there is still the > issue of adding more and more settings over time. My fear is this ends > up like the admin app and never keeps up with newly added features. > > Use the ServiceLoader mechanism on Tomcat instance creation to load > LifecycleListener instances that are then attached to the Server > instance and can be used to configure it. Use some new class like > EmbeddedConfigurationLifecycleListener for this. For security, disable > this behaviour by default unless enabled with (yuck) a system property. > > I'm leaning towards the ServiceLoader approach as it gives us maximum > flexibility and maximum control. It also provides a way for folks to > configure Tomcat when it is embedded in other products with the > necessary configuration being exposed. > > Thoughts? > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
