Congrats for the achievement, +1 to follow tomcat versions, tag and run at least daily if possible, it is a huge step for tomcat and tck IMHO.
Le mer. 21 juin 2023 à 11:10, Mark Thomas <ma...@apache.org> a écrit : > On 21/06/2023 09:54, Rémy Maucherat wrote: > > 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. > > Did I mention the TCKs are at least an order of magnitude faster? :) > > The full WebSocket TCK (minus the signature tests which haven't been > migrated yet) run in just over 5 mins and I haven't even looked at > tuning (parallel) options yet. > > Mark > > > > > 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 > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
