Investigate what Arquillian extensions are needed to replace the EE10 porting lib

[starksm64]

We need to defined what arquillian loadable extension requirements are needed to replace the EE10 CTS porting lib classes. The deployment related classes will be taken care of by the arquillian @deployment method on the test class, but vendor specific descriptors and classes will need an ArquillianDeploymentAppender.

It may be useful to add base class implementations to simplify vendor implementations.

The current porting lib section of the TCK user guild will need to be replaced to document requirements/usage.
Update the TCK user guide

[starksm64]

After looking into the often used ApplicationArchiveProcessor approach to supproriting inclusions of vendor descriptors, this was seen as too cumbersome as you are presented with the top level archive and then have to go looking through it for child archives and sun xml descriptors.

With the release of Arquillian core 1.9.1.Final, the static class deployment methods are able to accepts @ArquillianResource annotated paramters. What I have prototyped is the following where the test deployment methods accept a TestArchiveProcessor instance that can be used to augment the individual archives as they are built:

@ExtendWith(ArquillianExtension.class)
public class ClientTest extends com.sun.ts.tests.ejb30.misc.sameejbclass.Client {

    @TargetsContainer("tck-javatest")
    @OverProtocol("javatest")
    @Deployment(name = "misc_sameejbclass")
    public static EnterpriseArchive createDeployment(@ArquillianResource TestArchiveProcessor archiveProcessor) {
        // War
...
        // The sun-web.xml descriptor
        warResURL = Client.class.getResource("/com/sun/ts/tests/ejb30/misc/sameejbclass/misc_sameejbclass_web.war.sun-web.xml");
        if(warResURL != null) {
            misc_sameejbclass_web.addAsWebInfResource(warResURL, "sun-web.xml");
            archiveProcessor.processWebArchive(misc_sameejbclass_web, ClientTest.class, warResURL);
        }
...

The proposed TestArchiveProcessor is:

/**
 * Interface that vendors implement to augment test archives with vendor specific deployment content.
 */
public interface TestArchiveProcessor {
    void processClientArchive(JavaArchive clientArchive, Class<?> testClass, URL sunXmlUrl);
    void processEjbArchive(JavaArchive ejbArchive, Class<?> testClass, URL sunXmlUrl);
    void processWebArchive(WebArchive webArchive, Class<?> testClass, URL sunXmlUrl);
    void processRarArchive(JavaArchive warArchive, Class<?> testClass, URL sunXmlUrl);
    void processEarArchive(EnterpriseArchive earArchive, Class<?> testClass, URL sunXmlUrl);
}

[starksm64]

A question is, should this be called regardless of whether there is a sun*.xml descriptor, or only when there is such a descriptor? I'm leaning toward the later, but I'm not sure what all vendors need to customize.

[starksm64]

The proposed interface has been updated to support persistence unit archives:

package tck.arquillian.porting.lib.spi;

import org.jboss.shrinkwrap.api.spec.EnterpriseArchive;
import org.jboss.shrinkwrap.api.spec.JavaArchive;
import org.jboss.shrinkwrap.api.spec.WebArchive;

import java.net.URL;

/**
 * Interface that vendors implement to augment test archives with vendor specific deployment content.
 */
public interface TestArchiveProcessor {
    /**
     * Called to process a client archive (jar) that is part of the test deployment.
     * @param clientArchive - the appclient archive
     * @param testClass - the TCK test class
     * @param sunXmlUrl - the URL to the sun-application-client.xml file
     */
    void processClientArchive(JavaArchive clientArchive, Class<?> testClass, URL sunXmlUrl);
    /**
     * Called to process a ejb archive (jar) that is part of the test deployment.
     * @param ejbArchive - the ejb archive
     * @param testClass - the TCK test class
     * @param sunXmlUrl - the URL to the sun-ejb-jar.xml file
     */
    void processEjbArchive(JavaArchive ejbArchive, Class<?> testClass, URL sunXmlUrl);
    /**
     * Called to process a web archive (war) that is part of the test deployment.
     * @param webArchive - the web archive
     * @param testClass - the TCK test class
     * @param sunXmlUrl - the URL to the sun-web.xml file
     */
    void processWebArchive(WebArchive webArchive, Class<?> testClass, URL sunXmlUrl);
    /**
     * Called to process a resource adaptor archive (rar) that is part of the test deployment.
     * @param rarArchive - the resource archive
     * @param testClass - the TCK test class
     * @param sunXmlUrl - the URL to the sun-ra.xml file
     */
    void processRarArchive(JavaArchive rarArchive, Class<?> testClass, URL sunXmlUrl);
    /**
     * Called to process a persistence unit archive (par) that is part of the test deployment.
     * @param parArchive - the resource archive
     * @param testClass - the TCK test class
     * @param persistenceXmlUrl - the URL to the sun-ra.xml file
     */
    void processParArchive(JavaArchive parArchive, Class<?> testClass, URL persistenceXmlUrl);
    /**
     * Called to process an enterprise archive (ear) that is part of the test deployment.
     * @param earArchive - the application archive
     * @param testClass - the TCK test class
     * @param sunXmlUrl - the URL to the sun-application.xml file
     */
    void processEarArchive(EnterpriseArchive earArchive, Class<?> testClass, URL sunXmlUrl);
}

[brideck]

A question is, should this be called regardless of whether there is a sun*.xml descriptor, or only when there is such a descriptor? I'm leaning toward the later, but I'm not sure what all vendors need to customize.

I can confirm that in Open Liberty we do provide something in a binding or extension descriptor for at least one test that doesn't have a sun*.xml file provided by the TCK. Whether or not those files are strictly necessary is an open question, I suppose, but not one I'm able to research deeply at the moment. Given that, I'd appreciate this being called all the time. Hopefully that won't prove to be a colossal performance degradation.

[starksm64]

Ok, I doubt it should matter in the scheme of other activities, and the generated code has already been updated to always call the archive processor for each generated archive type.

…

On Wed, Jul 31, 2024 at 9:10 AM Brian Decker ***@***.***> wrote: A question is, should this be called regardless of whether there is a sun*.xml descriptor, or only when there is such a descriptor? I'm leaning toward the later, but I'm not sure what all vendors need to customize. I can confirm that in Open Liberty we do provide something in a binding or extension descriptor for at least one test that doesn't have a sun*.xml file provided by the TCK. Whether or not those files are strictly necessary is an open question, I suppose, but not one I'm able to research deeply at the moment. Given that, I'd appreciate this being called all the time. Hopefully that won't prove to be a colossal performance degradation. — Reply to this email directly, view it on GitHub <#1355 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACRDMVESDXPNKOCSOB4GSDZPD44ZAVCNFSM6AAAAABKVMYY7GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRQG42TIMBZHE> . You are receiving this because you were assigned.Message ID: ***@***.***>