From 8aa0647cffc8dfceab7f1c30a0ddd25f79597c3b Mon Sep 17 00:00:00 2001 From: navaneethsnair1 Date: Wed, 18 Mar 2026 11:46:06 +0530 Subject: [PATCH 1/4] first draft - 26.0.0.3-blog --- posts/2026-03-24-26.0.0.3.adoc | 316 +++++++++++++++++++++++++++++++++ 1 file changed, 316 insertions(+) create mode 100644 posts/2026-03-24-26.0.0.3.adoc diff --git a/posts/2026-03-24-26.0.0.3.adoc b/posts/2026-03-24-26.0.0.3.adoc new file mode 100644 index 000000000..07f113fba --- /dev/null +++ b/posts/2026-03-24-26.0.0.3.adoc @@ -0,0 +1,316 @@ +--- +layout: post +title: "Java Toolchains in Liberty Build Plugins in 26.0.0.3" +# Do NOT change the categories section +categories: blog +author_picture: https://avatars3.githubusercontent.com/navaneethsnair1 +author_github: https://github.com/navaneethsnair1 +seo-title: Java Toolchains in Liberty Build Plugins in 26.0.0.3- OpenLiberty.io +seo-description: This release introduces UserRegistry Attribute Reader APIs for retrieving user attributes from LDAP and custom registries, and adds support for Jandex index formats 11-13 to improve application startup performance. +blog_description: This release introduces UserRegistry Attribute Reader APIs for retrieving user attributes from LDAP and custom registries, and adds support for Jandex index formats 11-13 to improve application startup performance. +open-graph-image: https://openliberty.io/img/twitter_card.jpg +open-graph-image-alt: Open Liberty Logo +--- += Java Toolchains in Liberty Build Plugins in 26.0.0.3 +Navaneeth S Nair +:imagesdir: / +:url-prefix: +:url-about: / +//Blank line here is necessary before starting the body of the post. + +// // // // // // // // +// In the preceding section: +// Do not insert any blank lines between any of the lines. +// Do not remove or edit the variables on the lines beneath the author name. +// +// "open-graph-image" is set to OL logo. Whenever possible update this to a more appropriate/specific image (For example if present a image that is being used in the post). However, it +// can be left empty which will set it to the default +// +// "open-graph-image-alt" is a description of what is in the image (not a caption). When changing "open-graph-image" to +// a custom picture, you must provide a custom string for "open-graph-image-alt". +// +// Replace TITLE with the blog post title eg: MicroProfile 3.3 is now available on Open Liberty 20.0.0.4 +// Replace navaneethsnair1 with your GitHub username eg: lauracowen +// Replace DESCRIPTION with a short summary (~60 words) of the release (a more succinct version of the first paragraph of the post). +// Replace Navaneeth S Nair with your name as you'd like it to be displayed, eg: Laura Cowen +// +// Example post: 2020-04-09-microprofile-3-3-open-liberty-20004.adoc +// +// If adding image into the post add : +// ------------------------- +// [.img_border_light] +// image::img/blog/FILE_NAME[IMAGE CAPTION ,width=70%,align="center"] +// ------------------------- +// "[.img_border_light]" = This adds a faint grey border around the image to make its edges sharper. Use it around screenshots but not +// around diagrams. Then double check how it looks. +// There is also a "[.img_border_dark]" class which tends to work best with screenshots that are taken on dark +// backgrounds. +// Change "FILE_NAME" to the name of the image file. Also make sure to put the image into the right folder which is: img/blog +// change the "IMAGE CAPTION" to a couple words of what the image is +// // // // // // // // + +This release introduces UserRegistry Attribute Reader APIs for retrieving user attributes from LDAP and custom registries, and adds support for Jandex index formats 11-13 to improve application startup performance. + +// // // // // // // // +// In the preceding section: +// Leave any instances of `tag::xxxx[]` or `end:xxxx[]` as they are. +// +// Replace RELEASE_SUMMARY with a short paragraph that summarises the release. Start with the lead feature but also summarise what else is new in the release. You will agree which will be the lead feature with the reviewers so you can just leave a placeholder here until after the initial review. +// // // // // // // // + +// // // // // // // // +// Replace the following throughout the document: +// Replace 26.0.0.3 with the version number of Open Liberty, eg: 22.0.0.2 +// Replace 26001 with the version number of Open Liberty wihtout the periods, eg: 22002 +// // // // // // // // + +In link:{url-about}[Open Liberty] 26.0.0.3: + +* <> +* <> +* <> + +View the list of fixed bugs in link:https://github.com/OpenLiberty/open-liberty/issues?q=label%3Arelease%3A26003+label%3A%22release+bug%22[26.0.0.3]. + +Check out link:{url-prefix}/blog/?search=release&search!=beta[previous Open Liberty GA release blog posts]. + + +[#run] + +// // // // // // // // +// LINKS +// +// OpenLiberty.io site links: +// link:{url-prefix}/guides/maven-intro.html[Maven] +// +// Off-site links: +//link:https://openapi-generator.tech/docs/installation#jar[Download Instructions] +// +// IMAGES +// +// Place images in ./img/blog/ +// Use the syntax: +// image::/img/blog/log4j-rhocp-diagrams/current-problem.png[Logging problem diagram,width=70%,align="center"] +// // // // // // // // + +== Develop and run your apps using 26.0.0.3 + +If you're using link:{url-prefix}/guides/maven-intro.html[Maven], include the following in your `pom.xml` file: + +[source,xml] +---- + + io.openliberty.tools + liberty-maven-plugin + 3.12.0 + +---- + +Or for link:{url-prefix}/guides/gradle-intro.html[Gradle], include the following in your `build.gradle` file: + +[source,gradle] +---- +buildscript { + repositories { + mavenCentral() + } + dependencies { + classpath 'io.openliberty.tools:liberty-gradle-plugin:4.0.0' + } +} +apply plugin: 'liberty' +---- +// // // // // // // // +// In the preceding section: +// Replace the Maven `3.11.5` with the latest version of the plugin: https://search.maven.org/artifact/io.openliberty.tools/liberty-maven-plugin +// Replace the Gradle `3.9.5` with the latest version of the plugin: https://search.maven.org/artifact/io.openliberty.tools/liberty-gradle-plugin +// TODO: Update GHA to automatically do the above. If the maven.org is problematic, then could fallback to using the GH Releases for the plugins +// // // // // // // // + +Or if you're using link:{url-prefix}/docs/latest/container-images.html[container images]: + +[source] +---- +FROM icr.io/appcafe/open-liberty +---- + +Or take a look at our link:{url-prefix}/start/[Downloads page]. + +If you're using link:https://plugins.jetbrains.com/plugin/14856-liberty-tools[IntelliJ IDEA], link:https://marketplace.visualstudio.com/items?itemName=Open-Liberty.liberty-dev-vscode-ext[Visual Studio Code] or link:https://marketplace.eclipse.org/content/liberty-tools[Eclipse IDE], you can also take advantage of our open source link:https://openliberty.io/docs/latest/develop-liberty-tools.html[Liberty developer tools] to enable effective development, testing, debugging and application management all from within your IDE. + +[link=https://stackoverflow.com/tags/open-liberty] +image::img/blog/blog_btn_stack.svg[Ask a question on Stack Overflow, align="center"] + +// // // // DO NOT MODIFY THIS COMMENT BLOCK // // // // +// Blog issue: https://github.com/OpenLiberty/open-liberty/issues/34074 +// Contact/Reviewer: karel-harjono +// // // // // // // // +[#userregistry] +== UserRegistry Attribute Reader Enhancement + +The UserRegistry Attribute Reader APIs feature enables applications to retrieve specific user attributes and search for users based on attribute values directly from LDAP and custom user registries. + +=== What's New? + +Previously, the UserRegistry API provided basic user lookups such as searching by `userSecurityName` or wildcard pattern matching. However, it did not allow applications to retrieve specific user attributes or search for users based on attribute values. The capabilities of these two methods are similarly available in Traditional WebSphere under the VMM API. The addition of these two APIs allows applications to search and read attributes from their LDAP and custom user registries. + +With this change, you can now retrieve specific attributes for a user (such as email, phoneNumber, or "*" for all attributes) using `getAttributesForUser()` and search for users by attribute values using `getUsersByAttribute()`. These new methods are supported for LDAP user registries. A custom user registry implementation can also implement these methods. + +=== How to Use It + +New API methods (added in UserRegistry.java): + +. `default Map getAttributesForUser(String userSecurityName, Set attributeNames)` ++ +*Description:* Returns a Map of the `attributesNames` and values for `userSecurityName` configured in the LDAP user registry. ++ +[source,java] +---- +UserRegistry ur = RegistryHelper.getUserRegistry("realmName"); + +// valid ldap attribute names +Set attributeNames = Set.of("telephoneNumber", "uid", "mail"); // or "*" for retrieving all attributes +Map result = ur.getAttributesForUser("testuser", attributeNames); + +// output in trace.log +> getAttributesForUser Entry + testuser + [telephoneNumber, uid, mail] + +< getAttributesForUser Exit + {uid=testuser, mail=testuser@example.com, telephoneNumber=} +---- + +. `default SearchResult getUsersByAttribute(String attributeName, String value, int limit)` ++ +*Description:* Returns a `SearchResult` object that contains a list of users that match an `attributeName` with specified `value` configured in the LDAP user registry. ++ +[source,java] +---- +UserRegistry ur = RegistryHelper.getUserRegistry("realmName"); + +SearchResult searchResult = ur.getUsersByAttribute("email", "testuser@example.com", 1); + +// output in trace.log +> getUsersByAttribute Entry + kerberosId + testuser@example.com + 0 + +< getUsersByAttribute Exit + SearchResult hasMore=false [testuser] +---- + +To learn more about user registry, see the following resources: + +* link:https://www.ibm.com/docs/en/was-liberty/base?topic=infrastructure-customizing-user-registries-repositories-liberty[Open Liberty Custom User Registry Documentation] +* link:https://openliberty.io/docs/modules/reference/24.0.0.3/com.ibm.websphere.appserver.api.securityClient_1.1-javadoc/com/ibm/websphere/security/UserRegistry.html[UserRegistry API Javadoc] +* link:https://openliberty.io/docs/latest/user-registries-application-security.html#_federated_user_registries[Federated User Registry Configuration] + +// DO NOT MODIFY THIS LINE. + +// // // // DO NOT MODIFY THIS COMMENT BLOCK // // // // +// Blog issue: https://github.com/OpenLiberty/open-liberty/issues/34231 +// Contact/Reviewer: benjamin-confino, tbitonti +// // // // // // // // +[#jandex] +== Jandex Index Format Support Update + +Open Liberty now supports the current latest Jandex index formats, enabling you to use Jandex indexes created with Jandex versions 3.1.0 and higher. Jandex is a space-efficient Java annotation indexer and offline reflection library that significantly improves application startup performance by pre-indexing class metadata. + +This feature is intended for Application developers and DevOps engineers working with Jakarta EE and MicroProfile applications who want to optimize their application startup times and reduce runtime overhead. + +=== What's New? + +With this update, Open Liberty supports Jandex index formats *11, 12, and 13*. Indexes that use these index format versions are generated by Jandex versions 3.1.0 up to and including the current latest Jandex version 3.5.3. + +Previously, Open Liberty only supported Jandex index format versions up to and including index format version 10. The index format limitation meant applications that were packaged with Jandex indexes could not use an index format version higher than 10 and continue to obtain expected performance improvements. To maintain performance improvements, build tooling was required to continue using a Jandex version prior to 3.1.0, or to add explicit parameters to Jandex index generation steps to force the generation of indexes using index format 10 or lower. + +=== Benefits + +The added support for Jandex index formats has several benefits: + +* *Improved Compatibility:* Seamlessly work with the latest versions of build tools and frameworks that use newer Jandex versions +* *Faster Startup Times:* Continue to benefit from Jandex's efficient annotation indexing without version constraints +* *Reduced Maintenance:* No need to maintain multiple Jandex versions or regenerate indexes for compatibility +* *Future-Proof:* Stay current with the Jandex ecosystem as it evolves + +=== Limitations + +*When using Jandex indexes, you must ensure that up-to-date index files are provided together with your application classes.* When a Jandex index is not up to date with application classes, incorrect annotation data is used. This might cause the application to function incorrectly. Out-of-date Jandex indexes cannot be reliably detected. + +Open Liberty does not read index formats higher than index format 13. If a new version of Jandex adds a higher index format version, Open Liberty requires an update before it can read Jandex indexes which use that index format version. + +The Open Liberty feature "mpGraphQL", which is obtained from an external source, is limited to reading Jandex index formats no higher than index format 10. If the feature "mpGraphQL" is used, Jandex indexes should be generated using index format 10. This limitation applies to all current versions of "mpGraphQL", including the current highest version, "mpGraphQL-2.0". + +=== Lifting Restriction + +Previously, if Jandex use was enabled and an index of formats 11 through 13 was present in an application, an error message would be displayed and that Jandex index would be ignored. Annotation scans would be performed using Liberty's internal annotation scan code. + +With the addition of support for Jandex index formats 11 through 13, the indexes that use those index formats is now used. The indexes must be up to date with application classes. Ensure that the Jandex indexes that are packaged with your application are up to date with application classes. + +=== How to Use + +No configuration changes are required in your `server.xml` file to enable reads of the new index formats. Open Liberty detects the Jandex index format and uses an index reader that is appropriate for the index format. Open Liberty automatically reads indexes that use index formats 11, 12, and 13, and still continues to read indexes that use index formats 10 or less. + +Use of Jandex is disabled by default. To enable use of Jandex, you must specify the property `useJandex` with a value of `true` within any application element or within the application manager element. + +If you are generating Jandex indexes as part of your build process, you can now use the latest Jandex Maven plugin or Gradle plugin versions: + +*Maven Example:* + +[source,xml] +---- + + io.smallrye + jandex-maven-plugin + 3.5.3 + + + make-index + + jandex + + + + +---- + +*Gradle Example:* + +[source,gradle] +---- +plugins { + id 'org.kordamp.gradle.jandex' version '2.3.0' +} +---- + +The generated `META-INF/jandex.idx` file is automatically recognized by Open Liberty, regardless of which supported format version is used. + +To learn more, see the link:https://smallrye.io/jandex/jandex/3.5.3/index.html[Jandex Documentation] + +// DO NOT MODIFY THIS LINE. + +[#bugs] +== Notable bugs fixed in this release + + +We’ve spent some time fixing bugs. The following sections describe some of the issues resolved in this release. If you’re interested, here’s the link:https://github.com/OpenLiberty/open-liberty/issues?q=label%3Arelease%3A26003+label%3A%22release+bug%22[full list of bugs fixed in 26.0.0.3]. + +* link:https://github.com/OpenLiberty/open-liberty/issues/34017[Missing error message in JMX REST client] +* link:https://github.com/OpenLiberty/open-liberty/issues/34052[NullPointerException resurfaced in Open Liberty due to removal of EclipseLink 2.7.16 fix] +* link:https://github.com/OpenLiberty/open-liberty/issues/34171[IBM WebSphere Application Server Liberty is affected by a denial of service due to jose4j (CVE-2024-29371 CVSS 7.5)] + +// // // // // // // // +// In the preceding section: +// For this section ask either Michal Broz or Tom Evans or the #openliberty-release-blog channel for Notable bug fixes in this release. +// Present them as a list in the order as provided, linking to the issue and providing a short description of the bug and the resolution. +// If the issue on Github is missing any information, leave a comment in the issue along the lines of: +// "@[issue_owner(s)] please update the description of this `release bug` using the [bug report template](https://github.com/OpenLiberty/open-liberty/issues/new?assignees=&labels=release+bug&template=bug_report.md&title=)" +// Feel free to message the owner(s) directly as well, especially if no action has been taken by them. +// For inspiration about how to write this section look at previous blogs e.g- 20.0.0.10 or 21.0.0.12 (https://openliberty.io/blog/2021/11/26/jakarta-ee-9.1.html#bugs) +// // // // // // // // + +== Get Open Liberty 26.0.0.3 now + +Available through <>. \ No newline at end of file From ff0cb0c07db98e0499ee4ea201704c4a7f620234 Mon Sep 17 00:00:00 2001 From: navaneethsnair1 Date: Wed, 18 Mar 2026 20:59:24 +0530 Subject: [PATCH 2/4] update 26.0.0.3 blog --- posts/2026-03-24-26.0.0.3.adoc | 48 ++++++++++++++++++---------------- 1 file changed, 25 insertions(+), 23 deletions(-) diff --git a/posts/2026-03-24-26.0.0.3.adoc b/posts/2026-03-24-26.0.0.3.adoc index 07f113fba..3044234a4 100644 --- a/posts/2026-03-24-26.0.0.3.adoc +++ b/posts/2026-03-24-26.0.0.3.adoc @@ -148,21 +148,23 @@ image::img/blog/blog_btn_stack.svg[Ask a question on Stack Overflow, align="cent [#userregistry] == UserRegistry Attribute Reader Enhancement -The UserRegistry Attribute Reader APIs feature enables applications to retrieve specific user attributes and search for users based on attribute values directly from LDAP and custom user registries. +The UserRegistry Attribute Reader APIs feature provide applications with the ability to retrieve specific user attributes and search for users based on attribute values directly from LDAP and custom user registries. === What's New? -Previously, the UserRegistry API provided basic user lookups such as searching by `userSecurityName` or wildcard pattern matching. However, it did not allow applications to retrieve specific user attributes or search for users based on attribute values. The capabilities of these two methods are similarly available in Traditional WebSphere under the VMM API. The addition of these two APIs allows applications to search and read attributes from their LDAP and custom user registries. +Previously, the UserRegistry API supported only basic user lookups such as searching by `userSecurityName` or by using wildcard pattern matching. However, it did not allow applications to retrieve specific user attributes or search for users based on attribute values. These capabilities were available in Traditional WebSphere through the VMM API. The introduction of these two new APIs now enables applications to search for users and retrieve attributes from LDAP and custom user registries. -With this change, you can now retrieve specific attributes for a user (such as email, phoneNumber, or "*" for all attributes) using `getAttributesForUser()` and search for users by attribute values using `getUsersByAttribute()`. These new methods are supported for LDAP user registries. A custom user registry implementation can also implement these methods. +With this enhancement, you can now retrieve specific attributes for a user by using the `getAttributesForUser()` method. This method supports retrieval of individual attributes such as email or phoneNumber, or "*" to retrieve all available attributes for a user. + +You can also search for users based on attribute values by using the `getUsersByAttribute()` method, enabling applications to locate users by matching specific attribute criteria. These methods are supported for LDAP user registries. Custom user registry implementations can also implement and support these methods. === How to Use It -New API methods (added in UserRegistry.java): +New API methods added to `UserRegistry.java`: . `default Map getAttributesForUser(String userSecurityName, Set attributeNames)` + -*Description:* Returns a Map of the `attributesNames` and values for `userSecurityName` configured in the LDAP user registry. +*Description:* Returns a Map containing the specified `attributesNames` and their corresponding values for the given `userSecurityName`, as configured in the LDAP user registry. + [source,java] ---- @@ -183,7 +185,7 @@ Map result = ur.getAttributesForUser("testuser", attributeNames) . `default SearchResult getUsersByAttribute(String attributeName, String value, int limit)` + -*Description:* Returns a `SearchResult` object that contains a list of users that match an `attributeName` with specified `value` configured in the LDAP user registry. +*Description:* Returns a `SearchResult` object that contains a list of users that match an `attributeName` with specified `value` that is configured in the LDAP user registry. + [source,java] ---- @@ -201,11 +203,11 @@ SearchResult searchResult = ur.getUsersByAttribute("email", "testuser@example.co SearchResult hasMore=false [testuser] ---- -To learn more about user registry, see the following resources: +To learn more about the user registry, see the following resources: -* link:https://www.ibm.com/docs/en/was-liberty/base?topic=infrastructure-customizing-user-registries-repositories-liberty[Open Liberty Custom User Registry Documentation] +* link:https://www.ibm.com/docs/en/was-liberty/base?topic=infrastructure-customizing-user-registries-repositories-liberty[Open Liberty Custom User Registry documentation] * link:https://openliberty.io/docs/modules/reference/24.0.0.3/com.ibm.websphere.appserver.api.securityClient_1.1-javadoc/com/ibm/websphere/security/UserRegistry.html[UserRegistry API Javadoc] -* link:https://openliberty.io/docs/latest/user-registries-application-security.html#_federated_user_registries[Federated User Registry Configuration] +* link:https://openliberty.io/docs/latest/user-registries-application-security.html#_federated_user_registries[Federated User Registry configuration] // DO NOT MODIFY THIS LINE. @@ -216,44 +218,44 @@ To learn more about user registry, see the following resources: [#jandex] == Jandex Index Format Support Update -Open Liberty now supports the current latest Jandex index formats, enabling you to use Jandex indexes created with Jandex versions 3.1.0 and higher. Jandex is a space-efficient Java annotation indexer and offline reflection library that significantly improves application startup performance by pre-indexing class metadata. +Open Liberty now supports the latest Jandex index formats, allowing the use of Jandex indexes that are created with Jandex version 3.1.0 and later. Jandex is a space‑efficient Java annotation indexer and offline reflection library that improves application startup performance by pre‑indexing class metadata. -This feature is intended for Application developers and DevOps engineers working with Jakarta EE and MicroProfile applications who want to optimize their application startup times and reduce runtime overhead. +This feature targets application developers and DevOps engineers who work with Jakarta EE and MicroProfile applications. It is designed to optimize application startup times and reduce runtime costs. === What's New? -With this update, Open Liberty supports Jandex index formats *11, 12, and 13*. Indexes that use these index format versions are generated by Jandex versions 3.1.0 up to and including the current latest Jandex version 3.5.3. +With this update, Open Liberty supports Jandex index formats *11, 12, and 13*. Jandex versions 3.1.0 through the current latest version, 3.5.3, generate indexes that use these formats. -Previously, Open Liberty only supported Jandex index format versions up to and including index format version 10. The index format limitation meant applications that were packaged with Jandex indexes could not use an index format version higher than 10 and continue to obtain expected performance improvements. To maintain performance improvements, build tooling was required to continue using a Jandex version prior to 3.1.0, or to add explicit parameters to Jandex index generation steps to force the generation of indexes using index format 10 or lower. +Previously, Open Liberty supported Jandex index format versions only up to and including version 10. This index format limitation meant that applications packaged with Jandex indexes could not use index formats beyond version 10 while retaining the expected performance improvements. To preserve these performance benefits, build tooling had to continue using a Jandex version prior to 3.1.0, or explicitly configure Jandex index generation to produce indexes that use index format up to and including version 10. === Benefits The added support for Jandex index formats has several benefits: -* *Improved Compatibility:* Seamlessly work with the latest versions of build tools and frameworks that use newer Jandex versions +* *Improved Compatibility:* Works seamlessly with the latest versions of build tools and frameworks that use newer Jandex versions * *Faster Startup Times:* Continue to benefit from Jandex's efficient annotation indexing without version constraints * *Reduced Maintenance:* No need to maintain multiple Jandex versions or regenerate indexes for compatibility * *Future-Proof:* Stay current with the Jandex ecosystem as it evolves === Limitations -*When using Jandex indexes, you must ensure that up-to-date index files are provided together with your application classes.* When a Jandex index is not up to date with application classes, incorrect annotation data is used. This might cause the application to function incorrectly. Out-of-date Jandex indexes cannot be reliably detected. +*When using Jandex indexes, ensure that the index files are kept up to date with the application classes.* If a Jandex index is not synchronized with the application classes, it can contain incorrect annotation data, which can cause the application to function incorrectly. Out‑of‑date Jandex indexes cannot be reliably detected. -Open Liberty does not read index formats higher than index format 13. If a new version of Jandex adds a higher index format version, Open Liberty requires an update before it can read Jandex indexes which use that index format version. +Open Liberty does not read index formats higher than index format 13. If a new version of Jandex adds a higher index format version, Open Liberty requires an update before it can read Jandex indexes, which use that index format version. -The Open Liberty feature "mpGraphQL", which is obtained from an external source, is limited to reading Jandex index formats no higher than index format 10. If the feature "mpGraphQL" is used, Jandex indexes should be generated using index format 10. This limitation applies to all current versions of "mpGraphQL", including the current highest version, "mpGraphQL-2.0". +The Open Liberty feature `mpGraphQL`, which is obtained from an external source, is limited to reading Jandex index formats no higher than index format 10. If the feature `mpGraphQL` is used, Jandex indexes should be generated by using index format 10. This limitation applies to all current versions of `mpGraphQL`, including the current highest version, `mpGraphQL-2.0``. === Lifting Restriction -Previously, if Jandex use was enabled and an index of formats 11 through 13 was present in an application, an error message would be displayed and that Jandex index would be ignored. Annotation scans would be performed using Liberty's internal annotation scan code. +PPreviously, when Jandex usage was enabled and an application included Jandex indexes that used formats 11 through 13, Open Liberty displayed an error message and ignored those indexes. In such cases, annotation scanning was performed by using Liberty’s internal annotation scanning mechanism. -With the addition of support for Jandex index formats 11 through 13, the indexes that use those index formats is now used. The indexes must be up to date with application classes. Ensure that the Jandex indexes that are packaged with your application are up to date with application classes. +With the addition of support for Jandex index formats 11 through 13, Open Liberty now uses indexes that are generated in these formats. These indexes must be kept up to date with the application classes. Ensure that the Jandex indexes packaged with your application accurately reflect the current application classes. === How to Use -No configuration changes are required in your `server.xml` file to enable reads of the new index formats. Open Liberty detects the Jandex index format and uses an index reader that is appropriate for the index format. Open Liberty automatically reads indexes that use index formats 11, 12, and 13, and still continues to read indexes that use index formats 10 or less. +No configuration changes are required in the `server.xml` file to enable support for the new Jandex index formats. Open Liberty automatically detects the Jandex index format and selects the appropriate index reader for that format. It reads indexes that use formats 11, 12, and 13, and continues to support indexes that use format up to version 10. -Use of Jandex is disabled by default. To enable use of Jandex, you must specify the property `useJandex` with a value of `true` within any application element or within the application manager element. +By default, Jandex usage is disabled. To enable Jandex, set the `useJandex` property to `true` in either an `application` element or the `applicationManager` element. If you are generating Jandex indexes as part of your build process, you can now use the latest Jandex Maven plugin or Gradle plugin versions: @@ -285,9 +287,9 @@ plugins { } ---- -The generated `META-INF/jandex.idx` file is automatically recognized by Open Liberty, regardless of which supported format version is used. +Open Liberty automatically detects and recognizes the generated `META-INF/jandex.idx` file for any supported index format version. -To learn more, see the link:https://smallrye.io/jandex/jandex/3.5.3/index.html[Jandex Documentation] +For more information, see the link:https://smallrye.io/jandex/jandex/3.5.3/index.html[Jandex Documentation] // DO NOT MODIFY THIS LINE. From ad236f95d17bcb827cb9caa8c26074dcfd26eee7 Mon Sep 17 00:00:00 2001 From: navaneethsnair1 Date: Thu, 19 Mar 2026 11:28:58 +0530 Subject: [PATCH 3/4] added blog tags and updates to blog --- blog_tags.json | 20 +++++++++++++------- posts/2026-03-24-26.0.0.3.adoc | 6 +++--- 2 files changed, 16 insertions(+), 10 deletions(-) diff --git a/blog_tags.json b/blog_tags.json index e183102f5..fa673c172 100644 --- a/blog_tags.json +++ b/blog_tags.json @@ -2,7 +2,8 @@ "blog_tags": [ { "name": "announcements", - "posts": ["26.0.0.3-beta", "26.0.0.2", "26.0.0.2-beta", + "posts": ["26.0.0.3", "26.0.0.3-beta", + "26.0.0.2", "26.0.0.2-beta", "26.0.0.1", "26.0.0.1-beta", "25.0.0.12", "25.0.0.12-beta", "25.0.0.11", "25.0.0.11-beta", @@ -99,7 +100,7 @@ "featured": "true" },{ "name": "microprofile", - "posts": ["25.0.0.8", "25.0.0.7-beta", + "posts": ["26.0.0.3", "25.0.0.8", "25.0.0.7-beta", "25.0.0.6", "25.0.0.6-beta", "25.0.0.5", "25.0.0.4", "25.0.0.4-beta", "microprofile-telemetry-20", @@ -174,7 +175,9 @@ }, { "name": "java-se", - "posts": ["25.0.0.10", "25.0.0.10-beta", "25.0.0.6", "25.0.0.6-beta", "25.0.0.4", + "posts": ["26.0.0.3", "25.0.0.10", + "25.0.0.10-beta", "25.0.0.6", + "25.0.0.6-beta", "25.0.0.4", "25.0.0.4-beta", "24.0.0.10", "24.0.0.10-beta", "24.0.0.4", "24.0.0.4-beta", "24.0.0.3", @@ -193,7 +196,9 @@ }, { "name": "release", - "posts": ["26.0.0.3-beta", "26.0.0.2", "26.0.0.2-beta", "26.0.0.1", "26.0.0.1-beta", + "posts": ["26.0.0.3", "26.0.0.3-beta", + "26.0.0.2", "26.0.0.2-beta", + "26.0.0.1", "26.0.0.1-beta", "25.0.0.12", "25.0.0.12-beta", "25.0.0.11", "25.0.0.11-beta", "25.0.0.10", "25.0.0.10-beta", @@ -325,7 +330,7 @@ }, { "name": "security", - "posts": ["25.0.0.12", "25.0.0.12-beta", + "posts": ["26.0.0.3", "25.0.0.12", "25.0.0.12-beta", "25.0.0.9", "25.0.0.9-beta", "25.0.0.3", "25.0.0.3-beta", "25.0.0.2", "25.0.0.1-beta", @@ -420,7 +425,8 @@ }, { "name": "jakarta-ee", - "posts": ["25.0.0.12-beta", "24.0.0.12-beta", "rethinking-microservices", + "posts": ["26.0.0.3", "25.0.0.12-beta", + "24.0.0.12-beta", "rethinking-microservices", "24.0.0.8", "liberty-developer-essentials-badge", "24.0.0.8-beta", "24.0.0.7-beta", "24.0.0.6-beta", "simplifying-nosql-database-integration-with-jakarta-nosql", @@ -619,7 +625,7 @@ }, { "name": "performance-enhancements", - "posts": ["25.0.0.12-beta", "25.0.0.11-beta", + "posts": ["26.0.0.3", "25.0.0.12-beta", "25.0.0.11-beta", "25.0.0.1", "25.0.0.1-beta", "24.0.0.11", "24.0.0.11-beta", "five-java-dev-musthaves-fast-startup", "rapid-startup-without-compromise", diff --git a/posts/2026-03-24-26.0.0.3.adoc b/posts/2026-03-24-26.0.0.3.adoc index 3044234a4..837be3aa2 100644 --- a/posts/2026-03-24-26.0.0.3.adoc +++ b/posts/2026-03-24-26.0.0.3.adoc @@ -1,17 +1,17 @@ --- layout: post -title: "Java Toolchains in Liberty Build Plugins in 26.0.0.3" +title: "UserRegistry Attribute Reader Enhancement and Jandex Index Format Support Update in 26.0.0.3" # Do NOT change the categories section categories: blog author_picture: https://avatars3.githubusercontent.com/navaneethsnair1 author_github: https://github.com/navaneethsnair1 -seo-title: Java Toolchains in Liberty Build Plugins in 26.0.0.3- OpenLiberty.io +seo-title: UserRegistry Attribute Reader Enhancement and Jandex Index Format Support Update in 26.0.0.3- OpenLiberty.io seo-description: This release introduces UserRegistry Attribute Reader APIs for retrieving user attributes from LDAP and custom registries, and adds support for Jandex index formats 11-13 to improve application startup performance. blog_description: This release introduces UserRegistry Attribute Reader APIs for retrieving user attributes from LDAP and custom registries, and adds support for Jandex index formats 11-13 to improve application startup performance. open-graph-image: https://openliberty.io/img/twitter_card.jpg open-graph-image-alt: Open Liberty Logo --- -= Java Toolchains in Liberty Build Plugins in 26.0.0.3 += UserRegistry Attribute Reader Enhancement and Jandex Index Format Support Update in 26.0.0.3 Navaneeth S Nair :imagesdir: / :url-prefix: From b9feee2fdb7c4ad5caf4d31bd24036064ce9a9bd Mon Sep 17 00:00:00 2001 From: navaneethsnair1 Date: Fri, 20 Mar 2026 15:24:45 +0530 Subject: [PATCH 4/4] fixing typo error --- posts/2026-03-24-26.0.0.3.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/posts/2026-03-24-26.0.0.3.adoc b/posts/2026-03-24-26.0.0.3.adoc index 837be3aa2..487a59be8 100644 --- a/posts/2026-03-24-26.0.0.3.adoc +++ b/posts/2026-03-24-26.0.0.3.adoc @@ -247,7 +247,7 @@ The Open Liberty feature `mpGraphQL`, which is obtained from an external source, === Lifting Restriction -PPreviously, when Jandex usage was enabled and an application included Jandex indexes that used formats 11 through 13, Open Liberty displayed an error message and ignored those indexes. In such cases, annotation scanning was performed by using Liberty’s internal annotation scanning mechanism. +Previously, when Jandex usage was enabled and an application included Jandex indexes that used formats 11 through 13, Open Liberty displayed an error message and ignored those indexes. In such cases, annotation scanning was performed by using Liberty’s internal annotation scanning mechanism. With the addition of support for Jandex index formats 11 through 13, Open Liberty now uses indexes that are generated in these formats. These indexes must be kept up to date with the application classes. Ensure that the Jandex indexes packaged with your application accurately reflect the current application classes.