Jakarta EE Platform Call

Date: 2022-07-12

Present:

• Ivar Grimstad (Eclipse Foundation)
• Jan Westerkamp (iJUG)
• James Perkins (Red Hat)
• John Clingan (Red Hat)
• Emily Jiang (IBM)
• Jared Anderson (IBM)
• Brian Decker (IBM)
• Jim Krueger (IBM)
• Nathan Rauh (IBM)
• Thomas Watson (IBM)
• Petr Aubrecht (Payara)
• Scott Marlow (Red Hat)
• Lukas Jungmann (Oracle)
• Ed Bratt (Oracle)
• Werner Keil (Individual, Ambassador)
• Jesse McConnell (Webtide)
• BJ Hargrave (IBM)
• Kenji Kazumura (Fujitsu)

Agenda and Minutes

Jakarta EE 10 Status (standing agenda item)

• CDI Language Model TCK
  • Glassfish fixed the issue
• CCR submitted for GlassFish and the full profile: https://github.com/eclipse-ee4j/jakartaee-platform/issues/514
  • Comments on mailing list
  • Updates required for some links to TCKs and matching SHA values
    • Faces
      • PR for updating spec page - done
      • TCK must be moved/signed from promoted to main download
      • Ed will help out with this
    • Authentication
      • 4.0.0 or 4.0.1?
      • Push the 4.0.1 TCK file, or update the CCR links
    • Activation
      • CCR based on staged TCK
      • SHA does not match the published TCK
      • Arjan will update the result page for GlassFish, check with Lukas
    • REST
      • Broken links
      • PR to be merged
• Concurrency TCK results are still failing on Web Profile as per TCK results wiki
  • Open issue https://github.com/jakartaee/concurrency/issues/244
  • Pull request https://github.com/jakartaee/concurrency/pull/250
  • Current consensus is to include the test. On mailing list.
  • Next step: Approve PR, merge, build and stage new TCK
  • Run TCK with GlassFish
• Core Profile: Jakarta REST TCK (with Jakarta XML Binding)
  • https://github.com/jakartaee/rest/issues/1109 \
• Core Profile TCK
  • Arquillian Servlet support require full Servlet support on the server under test
  • Servlet is not part of Core Profile
  • Running the Core Profile TCK on a runtime without Servlet cause the majority of tests to fail
  • Work-around by enabling servlet kind of defeats the purpose
  • Action: Open Liberty team to create TCK issue for eliminating use of Servlet in Core Profile.
    • May require changes in Arquillian, or could be solved by an Adapter (hosted at EE4J?)
  • Action: CDI Lite TCK also depends on Servlet, Open Liberty passed but only due to adding Servlet api/impl to what they were testing. Open Liberty team to create Core Profile TCK issue for this.
• Example of CDI TCK test:

@SpecVersion(spec = "cdi", version = "2.0")
public class BeanContainerTest extends AbstractTest {

    @SuppressWarnings("unchecked")
    @Deployment
    public static WebArchive createTestArchive() {
        return new WebArchiveBuilder().withTestClassPackage(BeanContainerTest.class)
                .withClasses(RetentionLiteral.class, TargetLiteral.class).build();
    }

    @Test
    @SpecAssertion(section = BM_RESOLVE_AMBIGUOUS_DEP, id = "a")
    public void testAmbiguousDependencyResolved() {
        Set<Bean<?>> beans = getCurrentBeanContainer().getBeans(Food.class);
        assertEquals(beans.size(), 2);
        Bean<?> bean = getCurrentBeanContainer().resolve(beans);
        assertNotNull(bean);
        assertTrue(bean.isAlternative());
        assertTrue(typeSetMatches(bean.getTypes(), Food.class, Soy.class, Object.class));
    }
}

Servlet Lite suggestion

• Discuss on the Servlet list?
• For future releases, not for Jakarta EE 10