You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2023/06/16 15:11:03 UTC
Tomcat, Jakarta TCKs and Arquillian
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat, Jakarta TCKs and Arquillian
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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-unsubscribe@tomcat.apache.org
> >>>>>>> For additional commands, e-mail: dev-help@tomcat.apache.org
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> >>>>> For additional commands, e-mail: dev-help@tomcat.apache.org
> >>>>>
> >>>>>
> >>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> >>> For additional commands, e-mail: dev-help@tomcat.apache.org
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: dev-help@tomcat.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: Tomcat, Jakarta TCKs and Arquillian
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
>>>>>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>>>>
>>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat, Jakarta TCKs and Arquillian
Posted by Rémy Maucherat <re...@apache.org>.
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-unsubscribe@tomcat.apache.org
> >>>>> For additional commands, e-mail: dev-help@tomcat.apache.org
> >>>>>
> >>>>>
> >>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> >>> For additional commands, e-mail: dev-help@tomcat.apache.org
> >>>
> >>>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat, Jakarta TCKs and Arquillian
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>>>>
>>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat, Jakarta TCKs and Arquillian
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat, Jakarta TCKs and Arquillian
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: dev-help@tomcat.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: Tomcat, Jakarta TCKs and Arquillian
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat, Jakarta TCKs and Arquillian
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>