On Wed, Jun 21, 2023 at 10:33 AM Mark Thomas <ma...@apache.org> wrote: > > Thanks again for the pointers. I can run the refactored WebSocket TCK now. > > I think we need to setup a new Git project to hold the Tomcat > configuration for the refactored TCKs. This would be a multi-module > Maven project with one module for each TCK. I have the basis for this > locally but it needs some clean-up. > > One issue in particular is that there are some dependencies that might > not be available on Maven central yet. That might delay some of what we > want to do or require that folks need to build stuff locally and publish > to their local repository to use this - at least while the refactoring > is still in progress. > > A couple of questions. > > Would we ever release this? Or would it just be a vehicle for running > the TCK? I'm not seeing a need to release but we might tag from time to > time (e.g. when a Tomcat version passes all the TCKs). > > Will we (ultimately) want branches for each Tomcat version? I think we > will. Currently, the Jakarta EE 10 TCK is being refactored. I'm not sure > of the plan but I assume there will be a refactored release for Jakarta > EE 10 and then work will start on Jakarta EE 11. > > What version scheme should we use? Not hugely important if we aren't > releasing. Do we leave it on 0.0.1-SNAPSHOT, align it with the TCK > version, the Tomcat version or something else? My current thinking is > set it to 0.0.1-SNAPSHOT and revisit if we need to. > > Do we want to configure GitHub actions to run the TCKs after a commit? I > think we do as this gives us an easy way to run the TCKs. Update the > Tomcat version. Commit. Push. Wait. Done. > > Thoughts?
It would be quite impressive if this becomes just another testsuite. Given how resource and annoyance intensive the previous TCK was, I mean. Rémy > Mark > > > > On 16/06/2023 20:18, Mark Thomas wrote: > > Thanks, those are really helpful. I'll try and find some time to look at > > this some more next week. > > > > Mark > > > > > > On 16/06/2023 17:59, Romain Manni-Bucau wrote: > >> 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 > >>> > >>> > >> > > > > --------------------------------------------------------------------- > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
