Yes https://github.com/apache/bval/blob/master/bval-tck/src/main/java/org/apache/bval/arquillian/BValArquillianExtension.java or https://github.com/apache/geronimo-opentracing/blob/master/geronimo-opentracing/src/test/java/org/apache/geronimo/microprofile/opentracing/tck/setup/SkipOpentracingApiSetup.java
To hack the container I guess the easiest is to override default tomcat one to force a context class and then hack the autoconfig in the custom context. If needed i can do a poc to explain more next week if it helps and you point me a pom setup you use for deps to ensure I use the same ones. Le ven. 16 juin 2023 à 18:12, Mark Thomas <ma...@apache.org> a écrit : > Do you have a pointer for an example of the custom TCK loadable > extension? That sounds like it might be all we need. If the plumbing is > already in place in Arquillian then I'm happy not to reinvent the wheel. > > Mark > > > > On 16/06/2023 16:34, Romain Manni-Bucau wrote: > > 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 > >> > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
