sun-web.xml context-root doesn't work for other WAS

[kuuku123]

Describe the bug

The test ee/jakarta/tck/persistence/ee/packaging/web/scope/ClientTest describes how the application should be deployed:

@TargetContainer("tck-javatest")
@OverProtocol("javatest")
@Deployment(name = "jpa_ee_packaging_web_scope", order = 2)
public static WebArchive createDeployment(@ArquillianResource TestArchiveProcessor archiveProcessor) {
    // War
    WebArchive jpa_ee_packaging_web_scope_web =
        ShrinkWrap.create(WebArchive.class, "jpa_ee_packaging_web_scope_web.war");

    // Classes
    jpa_ee_packaging_web_scope_web.addClasses(
        ee.jakarta.tck.persistence.ee.util.Data.class,
        ee.jakarta.tck.persistence.ee.util.HttpTCKServlet.class,
        ee.jakarta.tck.persistence.ee.packaging.web.scope.ServletTest.class,
        ee.jakarta.tck.persistence.ee.common.Account.class
    );

    // web.xml
    URL warResURL = Client.class.getResource(
        "/ee/jakarta/tck/persistence/ee/packaging/web/scope/jpa_ee_packaging_web_scope_web.xml");
    jpa_ee_packaging_web_scope_web.addAsWebInfResource(warResURL, "web.xml");

    // sun-web.xml
    warResURL = Client.class.getResource(
        "/ee/jakarta/tck/persistence/ee/packaging/web/scope/jpa_ee_packaging_web_scope_web.war.sun-web.xml");
    jpa_ee_packaging_web_scope_web.addAsWebInfResource(warResURL, "sun-web.xml");

    // persistence.xml
    warResURL = Client.class.getResource(
        "/ee/jakarta/tck/persistence/ee/packaging/web/scope/persistence.xml");
    if (warResURL != null) {
        jpa_ee_packaging_web_scope_web.addAsWebResource(
            warResURL, "/WEB-INF/classes/META-INF/persistence.xml");
    }

    // Call the archive processor
    archiveProcessor.processWebArchive(jpa_ee_packaging_web_scope_web, Client.class, warResURL);

    return jpa_ee_packaging_web_scope_web;
}

The sun-web.xml used here contains:

<sun-web-app>
    <context-root>jpa_ee_packaging_web_scope</context-root>
    <class-loader delegate="true"/>
</sun-web-app>

The corresponding client code uses this context root:

public static final String SERVLET_NAME = "ServletTest";
public static final String CONTEXT_ROOT = "/jpa_ee_packaging_web_scope";

On GlassFish this works because sun-web.xml is a GlassFish-specific deployment descriptor that sets the context root.

However, for other Jakarta EE servers, sun-web.xml is not recognized. If the container does not understand sun-web.xml, the WAR is typically deployed with a context root derived from the WAR name, for example:

/jpa_ee_packaging_web_scope_web

As a result, Client tries to access /jpa_ee_packaging_web_scope/ServletTest, while the actually deployed servlet is available at /jpa_ee_packaging_web_scope_web/ServletTest. This causes the test to fail on non-GlassFish servers even if the JPA packaging behavior itself is correct.

Why this is a problem

• sun-web.xml is GlassFish-specific and not part of the Jakarta EE platform.
• The test currently assumes all implementations will honour sun-web.xml for context root configuration.
• There is no standard, container-neutral descriptor for context root in a standalone WAR. Other vendors use their own descriptors or deployment options instead.

This makes the test non-portable and effectively tied to GlassFish behavior.

Suggested fix

The smallest, most portable change would be to align the client’s context root with the WAR name and stop relying on sun-web.xml:

public static final String CONTEXT_ROOT = "/jpa_ee_packaging_web_scope_web";

This would allow all containers to pass the test without needing to implement or emulate support for sun-web.xml while keeping the actual packaging scenario the test is checking intact.

Environment

• TCK: persistence-platform-tck-tests-11.0.0 (and related artifacts)
• Test: ee/jakarta/tck/persistence/ee/packaging/web/scope/ClientTest
• Container: non-GlassFish Jakarta EE implementation (JEUS in my case)

On this container the test fails because the context root defined only in sun-web.xml is not applied.

[kuuku123]

I’ve opened a pull request to address this issue: #2577

[jhanders34]

Do you have this same problem with tcks/apis/persistence/persistence-inside-container/platform-tests/src/main/java/ee/jakarta/tck/persistence/ee/packaging/web/standalone/ClientTest.java? The reason I ask is because with OpenLiberty we use our mechanism to change the context root for that one as well.

[jhanders34]

Initially I thought maybe this was being opened as a challenge instead of a bug. It really matter which one you are opening it. The difference being whether to fix this only in the EE 12 stream or also port the change to EE 11 TCK stream.

[scottmarlow]

Technically a TCK challenge could be opened for EE 11 or this issue could be converted into a challenge. There are just a few missing things like the list of test failures.

In WildFly, we used to map the sun-web.xml deployment descriptor to a WildFly deployment descriptor. For EE 10+ we stopped mapping but others could but I do like the idea of fixing problems like this issue raises.

[kuuku123]

Yes, I see the same issue with
tcks/apis/persistence/persistence-inside-container/platform-tests/src/main/java/ee/jakarta/tck/persistence/ee/packaging/web/standalone/ClientTest.java as well.

I can update PR #2577 (or open an additional PR) to cover this standalone.ClientTest in the same way, if that’s preferred.

I originally ran into this while testing the EE 11 TCK (persistence-platform-tck-tests-11.0.0) on JEUS. I’m happy for this to be treated as a TCK challenge if that makes it easier to port the fix to the EE 11 stream as well.

[jhanders34]

@kuuku123 I would say that the change can be done under the same PR. I do wonder if you are wanting this fixed in the EE 12 stream only or if you want to have this fixed in the EE 11 service stream as well? The former would just be a normal defect for EE 12, but for EE 11, we would want this issue marked as a challenge and update the description with more details.

[arjantijms]

@kuuku123 AFAIK, it's not just these two tests that package a GlassFish proprietary descriptor by default. I think it's a few thousands really.

Instead of fixing this in two arbitray tests, we probably should address all these thousand of tests, and then update all runner jobs (where arguably these proprietary descriptors should be added).

Alternatively, we can just see those GlassFish proprietary descriptors as a hint of what needs to be done / configured for the other servers / runtimes. The extra file in the archive doesn't hurt, and the other servers/runtimes just ignore them. They can then proceed to either add their own file, or (perhaps just for the purpose of the TCK tests) interprete the directions in the GlassFish proprietary descriptor.

As yet another option, we can add jboss-web.xml, ibm-web-ext.xml etc as well.

[jhanders34]

@arjantijms I took a look to what we add for these and these two were the only ones in persistence. In reality if context root is the only thing set in the thousands you are talking about, all of them should be able to be removed because it will default to the archive name and it is redundant to have the sun-web.xml files.

[kuuku123]

I’ve updated PR #2577 (including the standalone ClientTest change).

I’m also fine with having this fixed in both the EE 12 and EE 11 streams and
treating it as a TCK challenge.

For now, JEUS is only being run against the EE 11 TCK on my side, so setting up
and running the EE 12 TCK might take some time (it depends on my boss). I believe the current issue
description already lists the failing tests and environment, but if there are
any additional details you’d like me to add please let me know and I’ll update it.

[arjantijms]

or now, JEUS is only being run against the EE 11 TCK on my side, so setting up
and running the EE 12 TCK might take some time (it depends on my boss)

Oh, you are from JEUS. Nice to meet you btw. I was for a long time in contact with Yoon Kyung Koo (which was around 2013). Good to hear JEUS is going for Jakarta EE 11. For a time JEUS was always the first to certify after GlassFish.