Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [servlet-dev] 6.0.0 release

Hi,

A relatively small thing to consider still; remove the requirement for the getters to go into what I called "tainted mode" here:

https://github.com/eclipse-ee4j/servlet-api/issues/416

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:

  1. 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).
  2. 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

Back to the top