| Re: [servlet-dev] 6.0.0 release |
_______________________________________________On Fri, 12 Nov 2021 at 03:12, arjan tijms <arjan.tijms@xxxxxxxxx> wrote:Hi,A relatively small thing to consider still; remove the requirement for the getters to go into what I called "tainted mode" here:At least the getters should be fairly easy.Kind regards,Arjan_______________________________________________On Thu, Nov 11, 2021 at 4:00 PM Scott Marlow <smarlow@xxxxxxxxxx> wrote:_______________________________________________
The main task is to provide a PR for the Servlet TCK.
Great to hear!
https://github.com/eclipse-ee4j/jaxrs-api started working on a TCK that has some Java SE tests but also many tests using servlet, some of which require users to supply vendor specific deployment descriptors [1] (much like we are used to with the Platform TCK).
The intention of [1] is to come up with a way that we can deal with vendor deployment descriptors in any of our SPEC API TCKs. [2] mentions a few options for solving [1] which I will paste here:
"
What are the best ways to integrate the Vendor specific deployment descriptors in?
Perhaps we could allow the user running the TCK to specify their integration jar and their (user) handling class name.
The (user) handling class could:
- User implements org.jboss.arquillian.core.spi.LoadableExtension in which case the TCK would have its own LoadableExtension implementation that when its register(ExtensionBuilder builder) is invoked, it in turn calls the user LoadableExtension allowing the user full access to register its own ExtensionBuilder so the user can solve whatever they need to (like adding additional vendor deployment descriptors before a test archive is deployed).
- User implements a TBD interface that contains methods for returning a set of (vendor specific) deployment descriptors java.io.File to be added to the specified test archive.
"
I am thinking that #1 is the way to allow the TCK user to provide their own ArquillianExtension (to be registered by our jax-rs or servlet TCK's ArquillianExtension, kind of like a bridge). This means the user would depend on the ArquillianExtension.
I am thinking that #2 is the way to allow the TCK user to simply add their vendor specific deployment descriptors in a prescribed fashion.
[3] is a list of the GlassFish deployment descriptors currently used for Servlet TCK testing by GlassFish but possibly by other EE implementations also.
Scott
[1] https://github.com/eclipse-ee4j/jaxrs-api/issues/1039
[2] https://github.com/eclipse-ee4j/jaxrs-api/issues/1039#issuecomment-959158557
[3] https://github.com/eclipse-ee4j/jakartaee-tck/tree/master/src/com/sun/ts/tests/servlet contains the following GlassFish deployment descriptors:
./ee/spec/security/runAs/servlet_ee_spec_security_runAs.ear.sun-application.xml
./ee/spec/security/runAs/servlet_ee_spec_security_runAs_ejb.jar.sun-ejb-jar.xml
./ee/spec/security/runAs/servlet_ee_spec_security_runAs_first_module_web.war.sun-web.xml
./ee/spec/security/runAs/servlet_ee_spec_security_runAs_second_module_web.war.sun-web.xml
./ee/spec/security/permissiondd/servlet_ee_spec_security_permissiondd_web.war.sun-web.xml
./ee/spec/security/permissiondd/servlet_ee_spec_security_permissiondd.ear.sun-application.xml
./ee/platform/deploy/ejbref/single/servlet_ee_platform_deploy_ejbref_single_client.jar.sun-application-client.xml
./ee/platform/deploy/ejbref/single/servlet_ee_platform_deploy_ejbref_single_web.war.sun-web.xml
./ee/platform/deploy/ejbref/single/servlet_ee_platform_deploy_ejbref_single_ejb.jar.sun-ejb-jar.xml
./ee/platform/deploy/ejbref/single/servlet_ee_platform_deploy_ejbref_single_ejb.jar.sun-cmp-mappings.xml
./ee/platform/deploy/ejblink/single/servlet_ee_platform_deploy_ejblink_single_ejb.jar.sun-ejb-jar.xml
./ee/platform/deploy/ejblink/single/servlet_ee_platform_deploy_ejblink_single_client.jar.sun-application-client.xml
./ee/platform/deploy/ejblink/single/servlet_ee_platform_deploy_ejblink_single_ejb.jar.sun-cmp-mappings.xml
./ee/platform/deploy/ejblink/single/servlet_ee_platform_deploy_ejblink_single_web.war.sun-web.xml
./ee/platform/deploy/resref/single/servlet_ee_platform_deploy_resref_single_web.war.sun-web.xml
./pluggability/api/jakarta_servlet_http/httpservletrequest/servlet_pluh_httpservletrequest_web.war.sun-web.xml
./pluggability/api/jakarta_servlet_http/httpservletrequestwrapper/servlet_pluh_HSReqWrapper_web.war.sun-web.xml
./spec/serverpush/servlet_spec_serverpush_web.war.sun-web.xml
./spec/security/clientcert/clientcert.ear.sun-application.xml
./spec/security/clientcert/clientcert_web.war.sun-web.xml
./spec/security/denyUncovered/servlet_sec_denyUncovered_web.war.sun-web.xml
./spec/security/denyUncovered/servlet_sec_denyUncovered.ear.sun-application.xml
./spec/security/metadatacomplete/servlet_sec_metadatacomplete_web.war.sun-web.xml
./spec/security/metadatacomplete/servlet_sec_metadatacomplete.ear.sun-application.xml
./spec/security/clientcertanno/clientcertanno.ear.sun-application.xml
./spec/security/clientcertanno/clientcertanno_web.war.sun-web.xml
./spec/security/secbasic/servlet_sec_secbasic_web.war.sun-web.xml
./spec/security/secbasic/servlet_sec_secbasic.ear.sun-application.xml
./spec/security/annotations/servlet_sec_annotations_web.war.sun-web.xml
./spec/security/annotations/servlet_sec_annotations.ear.sun-application.xml
./spec/security/secform/servlet_sec_secform_web.war.sun-web.xml
./spec/security/secform/servlet_sec_secform.ear.sun-application.xml
servlet-dev mailing list
servlet-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/servlet-dev
servlet-dev mailing list
servlet-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/servlet-dev
servlet-dev mailing list
servlet-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/servlet-dev