[COMMUNITY]  Jakarta Data support at 'community' stability

In  ee
Tracked by https://github.com/wildfly/wildfly-proposals/issues/702

Overview

In WildFly 34 we introduced preview stability support for Jakarta Data into WildFly Preview. In WildFly 35 we incorporated the same preview stability support in standard WildFly. We should now move this feature to community stability to make it available in standard WildFly without requiring users to enable preview stability when provisioning or starting their server.

While Jakarta Data first appeared in Jakarta EE as part of EE 11, its API is not bound to the EE 11 variants of other EE APIs, and our standard WildFly implementation, Hibernate Data Repositories, is part of Hibernate ORM 6.6, which implements the EE 10 Jakarta Persistence 3.1 specification.

User Stories

I’m an application developer and I’d like to be less concerned with the mechanics of manipulating persistent data. I’d like to define my entities and then write an interface that describes the CRUD and data access operations I need. I code against that interface and let WildFly take care of generating the interface implementation that deals with the DB. I’m fine with having less flexibility with the portions of my app that work this way, including limitations like:

  • A simpler query language.

  • No lazy loading  — or only explicit lazy loading by using Hibernate ORM native APIs.

  • More limited support for dynamic queries than is available with alternatives like the Criteria API.

  • And so on. I recognize that for portions of my application where these limitations are unacceptable I can still use standard Jakarta Persistence or native Hibernate ORM APIS.

I’m an application developer and am familiar with the Repository pattern from use of Spring Data. I’d like to use that pattern in WildFly in non-Spring applications.

I’m an application developer who’s used Deltaspike Data, which uses a repository pattern. But it doesn’t support EE > 8, so I’m looking for a similar technology to run on the latest WildFly releases.

I’m responsible for server provisioning, configuration and administration and I would like to be allow Jakarta Data support in WildFly servers without making it possible to enable preview stability features.

Issue Metadata

Affected Projects or Components

Other Interested Projects

Hibernate ORM

Relevant Installation Types

  • Traditional standalone server (unzipped or provisioned by Galleon)

  • Managed domain

  • OpenShift Source-to-Image (S2I)

  • Bootable jar

Requirements

  • The JBoss Modules modules required for the jakarta-data subsystem and the Jakarta Data API will be provisionable even if the provisioning tooling is configured to only allow community stability packages.

  • The org.wildfly.extension.jakarta.data extension and the jakarta-data subsystem will be usable in the configuration of a standard WildFly or WildFly Preview server running at community stability.

  • The TCK runner for Jakarta Data will be merged into the wildfly-tck-runners branches used for both EE 10 and EE 11 testing.

    • Execution of it will become part of the standard set of jobs used for EE 11 testing.

    • Execution of it against an EE 10 server will be added as a release task requirement.

  • There will be a quickstart demonstrating use of Jakarta Data.

  • The extension will be listed in the OOTB domain mode host-excludes settings.

  • When our OOTB configuration files are provisioned using a feature pack that provides Jakarta EE 11 support, the jakarta-data subsystem will be present in the standalone.xml, standalone-full.xml, standalone-ha.xml and standalone-full-ha.xml, standalone-microprofile.xml and standalone-microprofile-ha.xml configuration files, and also in any domain.xml profiles whose intended feature set aligns with one of those standalone variant.

Changed requirements

  • The Jakarta Data API artifact must be part of both the standard WildFly and the WildFly Preview user boms.

Non-Requirements

  • Inclusion of the jakarta-data subsystem in any OOTB standard configuration file when the configuration is provisioned using a feature pack that provide EE 10.

  • HAL console support beyond the generic model browser.

Future Work

  • Support for other Jakarta Data providers, e.g. Jakarta NoSQL implementations, if general support for those implementations is added to WildFly.

  • HAL support at least equivalent to other simple configuration subsystems, i.e. ones that expose no attributes or child resources.

Backwards Compatibility

Default Configuration

For installations that support EE 11, the default configuration will include the jakarta-data subsystem. This is not an incompatible change for standalone servers. For domain mode users running a mixed-domain, the subsystem will need to be removed from any domain.xml profiles that are used by servers running older WildFly versions.

Importing Existing Configuration

An existing configuration that has the jakarta-data subsytem in it will be using a preview stability xml namespace. Before booting a server at preview stability, that namespace will need to be updated to the new community stability namespace introduced as part of this feature.

Deployments

No incompatible changes.

Interoperability

No interoperability impact.

Admin Clients

No impact on the CLI. Low level operations related to this subsystem will work the same as any others. No existing high level commands will be impacted. No new high level commands are needed.

HAL impact needs discussion. The only hard requirement is generic model browser support, with Future Work to go beyond that. Eventually (i.e. with Future Work), HAL support should be at least equivalent to other simple configuration subsystems, i.e. ones that expose no attributes or child resources. If HAL exposes nothing for such subsystems beyond the generic model browser, discuss whether this subsystem justifies something more.

Security Considerations

Under the covers this is just another way of interacting with a database via Hibernate ORM, so it doesn’t introduce anything fundamentally new.

Test Plan

  • Standard subsystem tests.

  • Primary runtime behavior tests will be via the Jakarta Data TCK.

  • Smoke test that demonstrates behavior in an ear with multiple wars

    • Repository packaged in the ear lib and in each war. (Different ones.)

    • @ApplicationScoped bean in the ear lib and in each war that interacts with the equivalently packaged Repository.

    • Jakarta REST resources in each war are able to use the Repository packaged in their war as well as the one packaged in ear/lib.

    • This test also tests for correct handling of other usage subtleties where users have reported issues since the initial introduction of Jakarta Data support in WildFly Preview 34.

  • Basic test in the quickstart.

Community Documentation

The existing Jakarta Data coverage in the WildFly docs is sufficient. Update it to reflect that our support is now at community stability.

The new Quickstart of course is a new form of documentation.

Release Note Content

WildFly’s Jakarta Data support is now available at the community stability level. This means it can now be enabled in a standard WildFly server without including the --stability-level=preview flag in the server launch command.