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