back to all blogsSee all blog posts

Use Jakarta EE 9.1 dependencies with MicroProfile GraphQL 2.0 in Open Liberty 22.0.0.6

image of author
Ryan Storey on Jun 7, 2022
announcements , microprofile , release , security , jakarta-ee , data-sources ,
Post available in languages:

Open Liberty 22.0.0.6 offers MicroProfile GraphQL 2.0, which incorporates Jakarta EE 9.1 dependencies, allowing the use of updated Jakarta components such as CDI 3.0, Jakarta REST 3.0, JSON-B 2.0 and more. An enhancement to JPA 2.1 provides improved Db2 query performance by altering parameter binding behavior. This release also contains a number of significant bug fixes as well as important security vulnerability (CVE) fixes.

In Open Liberty 22.0.0.6:

View the list of fixed bugs in 22.0.0.6.

Run your apps using 22.0.0.6

If you’re using Maven, here are the coordinates:

<dependency>
    <groupId>io.openliberty</groupId>
    <artifactId>openliberty-runtime</artifactId>
    <version>22.0.0.6</version>
    <type>zip</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty', name: 'openliberty-runtime', version: '[22.0.0.6,)'
}

Or if you’re using Docker:

FROM open-liberty

Or take a look at our Downloads page.

Ask a question on Stack Overflow

Use Jakarta EE 9.1 dependencies with MicroProfile GraphQL 2.0

GraphQL is an open source data query and manipulation language for APIs and a runtime that fulfills queries with existing data. You can use a GraphQL service to obtain data from multiple sources (such as APIs, databases, and other services) by making only a single request. The GraphQL service can then collate this data into a single object, which simplifies the data retrieval. This results in faster application load times and lower data transfer costs. GraphQL enables clients to better customize requests to the server. Many enterprise companies use GraphQL, including Atlassian, Coursera, Facebook, GitHub, PayPal, and Twitter.

You can implement GraphQL support for applications that run on Open Liberty by enabling the MicroProfile GraphQL feature. When this feature is enabled, you can define GraphQL endpoints by using annotations, similar to how you create RESTful Web Services (formerly JAX-RS) resources.

MicroProfile GraphQL 2.0 incorporates Jakarta EE 9.1 dependencies. If you have been using MicroProfile GraphQL 1.0 in your application running on Open Liberty, you can continue to do so but with the updated Jakarta features such as CDI 3.0, restfulWS 3.0, JSON-B 2.0, etc. Functionally, version 2.0 behaves the same as 1.0 because it uses the same version of the underlying implementation (SmallRye GraphQL).

If you’d like to learn more about MicroProfile GraphQL:

To enable the MicroProfile GraphQL 2.0 feature, add it to your server.xml:

<featureManager>
  <feature>mpGraphQL-2.0</feature>
</featureManager>

Improved Db2 query performance

This new JPA enhancement improves EclipseLink’s Db2 and Db2 z/OS support by enabling parameter binding for JPA specification-defined functions.

For Db2 and Db2 for z/OS, EclipseLink’s JPQL parameter binding is disabled when function expressions (SQRT, ABS, SUBSTR, COALESCE, etc.) exist within a JPQL query. This update allows EclipseLink to bind JPQL parameters for function expressions that accept untyped parameter markers on Db2 and Db2 z/OS. This update also allows EclipseLink to enable and disable parameter binding per expression within a query, rather than for the entirety of the query.

For Db2 and Db2 for z/OS, EclipseLink does not bind JPQL literal values as SQL parameter values. The "shouldBindLiterals=true" EclipseLink-specific persistence property allows EclipseLink users to bind all literal values as parameter values. However, this property is currently ignored by EclipseLink for Db2 and Db2 for z/OS. This enhancement allows you to use the "shouldBindLiterals=true" EclipseLink persistence property to bind literals values as parameters on Db2 and Db2 z/OS; assuming this binding is legal according to the database.

Enabling parameter binding

To start using the new function, add the new eclipselink.jdbc.allow-partial-bind-parameters persistence property to your persistence.xml properties:

<persistence ... >
    <persistence-unit ... >
        <properties>
            <property name="eclipselink.jdbc.allow-partial-bind-parameters" value="true"/>
        </properties>
     </persistence-unit>
</persistence>

Alternatively, in Liberty 22.0.0.2 and later, you can add the new <defaultProperties> configuration to the <jpa> configuration in your server.xml file. This applies the eclipselink.jdbc.allow-partial-bind-parameters persistence property to all persistence units within applications that run on this server. For example:

<server>
    <featureManager>
        <feature>jpa-2.1</feature>
    </featureManager>
    ...
    <jpa>
        <defaultProperties>
            <property name="eclipselink.jdbc.allow-partial-bind-parameters" value="true"/>
        </defaultProperties>
    </jpa>
</server>

Using parameter binding

In the application, you can take advantage of this feature with JPA JPQL queries and CriteriaBuilder API queries.

Example 1:

    Query query = em.createQuery("SELECT g FROM Guest g WHERE LENGTH(?1) > 2 AND g.lastName = TRIM(?1)");
    query.setParameter(1, "Crusher");

By default, EclipseLink generates the following SQL prepared statement on Db2 and Db2 z/OS:

    SELECT FIRSTNAME, LASTNAME FROM GUEST WHERE ((LENGTH('Crusher') > 2) AND (LASTNAME = TRIM('Crusher')))

With the new property eclipselink.jdbc.allow-partial-bind-parameters = "true", EclipseLink generates the following SQL prepared statement on Db2:

    SELECT FIRSTNAME, LASTNAME FROM GUEST WHERE ((LENGTH('Crusher') > 2) AND (LASTNAME = TRIM(?)))

and DB2 z/OS:

    SELECT FIRSTNAME, LASTNAME FROM GUEST WHERE ((LENGTH('Crusher') > 2) AND (LASTNAME = TRIM('Crusher')))

Even though the property is enabled, no change is apparent for Db2 z/OS, because using an untyped parameter marker in the LENGTH or TRIM functions is illegal on Db2 z/OS. However, many other functions exist where it is legal to use parameter markers on Db2 z/OS. This example was chosen to show the differences between the Db2 and Db2 z/OS platforms. When the property is enabled, EclipseLink knows what is legal on what platform.

Example 2:

    Query query = em.createQuery("SELECT g FROM Guest g WHERE LENGTH(?1) > 2 AND g.lastName = TRIM(?1)");
    query.setParameter(1, "Crusher");

By default, EclipseLink generates the following SQL prepared statement on Db2 and Db2 z/OS:

    SELECT FIRSTNAME, LASTNAME FROM GUEST WHERE ((LENGTH('Crusher') > 2) AND (LASTNAME = TRIM('Crusher')))

With the new property eclipselink.jdbc.allow-partial-bind-parameters = "true", EclipseLink generates the following SQL prepared statement on Db2:

    SELECT FIRSTNAME, LASTNAME FROM GUEST WHERE ((LENGTH('Crusher') > 2) AND (LASTNAME = TRIM(?)))

and Db2 z/OS:

    SELECT FIRSTNAME, LASTNAME FROM GUEST WHERE ((LENGTH('Crusher') > 2) AND (LASTNAME = TRIM('Crusher')))

However, with the addition of an existing EclipseLink property

    <property name="eclipselink.target-database-properties" value="shouldBindLiterals=true"/>

EclipseLink generates the following SQL prepared statement on Db2:

    SELECT FIRSTNAME, LASTNAME FROM GUEST WHERE ((LENGTH('Crusher') > ?) AND (LASTNAME = TRIM(?)))

and Db2 z/OS:

    SELECT FIRSTNAME, LASTNAME FROM GUEST WHERE ((LENGTH('Crusher') > ?) AND (LASTNAME = TRIM('Crusher')))

Notice that with the addition of the shouldBindLiterals property, the literal value 2 is bound as a parameter in the SQL string. Without the feature enabled, EclipseLink cannot enable binding for some parts of the query and instead only enables or disables for the whole query. As we can see in this example, EclipseLink can enable some parameter binding while also respecting what is legal or illegal on Db2 and Db2 z/OS.

Security vulnerability (CVE) fixes in this release

CVE CVSS Score Vulnerability Assessment Versions Affected Notes

CVE-2022-22475

5

Identity spoofing

17.0.0.3 - 22.0.0.5

Affects the App Security 1.0, App Security 2.0, App Security 3.0 and App Security 4.0 features

CVE-2022-22393

3.1

Information disclosure

17.0.0.3 - 22.0.0.5

Affects the Admin Center 1.0 feature

For a list of past security vulnerability fixes, reference the Security vulnerability (CVE) list.

Notable bugs fixed in this release

We’ve spent some time fixing bugs. The following sections describe just some of the issues resolved in this release. If you’re interested, here’s the full list of bugs fixed in 22.0.0.6.

  • Liberty OIDC error is being returned with incorrect characters

    Previously, Liberty’s OIDC error was returned with incorrect characters. When invoking the OP’s /authorize endpoint with missing or incorrect parameters in traditional Chinese, the returned error message had a number of ???? instead of Chinese characters. The same happened for other non-ascii languages.

    The error page showed:

    "Accept-Language: zh-TW"
HTTP/1.1 200 OK
X-Powered-By: Servlet/3.0
Content-Language: en-DE
Transfer-Encoding: chunked
Date: Fri, 06 May 2022 08:42:36 GMT

CWOAU0033E: ????????????client_id

    This issue has now been fixed and the page should contain the properly translated error message instead of ????????????.

  • Refresh token is not cleaned up when a JWT access_token had been issued

    The refresh_token cleanup for an OIDC end_session instance is different depending on the type of access_token issued. The Liberty OP can issue opaque or JWT access_tokens. When running end_session, the refresh_token is removed from the cache when creating opaque access_tokens, however when creating JWT access_tokens, the refresh_token was NOT removed. This issue has been resolved and running end_session on providers that generate JWT access_tokens should invalidate the refresh_token.

  • Custom claims not passed to the back end

    When using MicroProfile Starter start.microprofile.io to generate service-a and service-b running on Open Liberty, the invocation to the service b no longer sent out the custom claim on invoking the JWT backend via localhost:9080. This defect was caused by the changes which exposed a hidden problem in the Claims.putAll method when there were claims with a null value and has since been fixed.

  • Bump netty dependencies to 4.1.77.Final

    Netty components in Open Liberty were of the version 4.1.75.Final released in March 2022. The latest version 4.1.77.Final contains various bug fixes and improvements over the current version. These components have been updated to ensure that Open Liberty stays up to date with upstream fixes and improvements.

  • Default session meta cache name failed with RH DataGrid

    When Liberty created infinispan caches name with percent encoding, Datagrid Administration GUI Console failed to retrieve the cache name. An example would be:

    com.ibm.ws.session.meta.default_host%2FGestionPedidos

    Where GestionPedidos is the application web context, %2F is the encoded character for /. RH DataGrid failed to retrieve the above cache name.

Get Open Liberty 22.0.0.6 now

Available through Maven, Gradle, Docker, and as a downloadable archive.