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
>
>

Reply via email to