Published latest aggregated blog posts

Author: jbossorg-bot

src/content/posts-aggregator/10.json

@@ -1,13 +1,13 @@
 {
-  "title": "Sender-constraining access tokens with Quarkus OIDC",
-  "link": "https://quarkus.io/blog/sender-constraining-tokens/",
+  "title": "Save the Date: WildFly Mini Conference on March 25th, 2025",
+  "link": "https://wildfly.org//news/2025/03/19/WildFly-mini-conference-2025-save-the-date/",
   "author": [
     {
-      "name": "Sergey Beryozkin",
+      "name": "Ranabir Chakraborty",
       "avatar": null
     }
   ],
   "date": "2025-03-19T00:00:00.000Z",
-  "feed_title": "Quarkus",
-  "content": "INTRODUCTION  Single-page application (SPA) runs in the browser and uses to log-in users, without depending on Quarkus OIDC. When the authentication is complete, SPA sends the access token to access Quarkus on behalf of the authenticated user.  Have a look at the simple diagram showing how this process works, copied to this post from the :    As illustrated in the picture above, the OIDC provider authenticates the current user, SPA receives ID and access tokens and uses the access token to access the Quarkus endpoint.  The security challenge that the OAuth2 experts have been trying to address is how to prove that the client such as SPA which is sending the token actually owns this token ? There is nothing in the HTTP Authorization: Bearer <token> header that proves that SPA did not leak the token.  Two specifications for sender-constraining access tokens have emerged over the years, and .   MUTUAL TLS CLIENT AUTHENTICATION AND CERTIFICATE-BOUND ACCESS TOKENS  specification describes how access tokens can be cryptographically bound to the MTLS client certificate.  By proving that the access token is bound to the client certificate, the Quarkus application can get a high degree of confidence that the current access token is constrained to, owned by the client which authenticated to Quarkus over MTLS.    Implementing the cryptographic binding is not complex in this case. The current access token is expected to contain a confirmation with the SHA-256 certificate thumbprint and it must match the thumbprint of the current MTLS client certificate. If the token is in JWT format, then it must include a confirmation claim. If the token is binary then the confirmation must be included in the remote token introspection response.  Such a binding can only be successful if the OpenId Connect provider has access to the same client certificate which is used during the MTLS authentication to Quarkus.  The downside of using the MTLS token binding is that correctly configuring the OpenId Connect provider, ensuring that browsers can request an X509 certiticate authentication when SPA redirects the user to authenticate to the OIDC provider is complex.  If you are a Keycloak user, check the in the Advanced Configuration section of the and the community blog post.  As far as Quarkus is concerned, you only need to set a single OIDC configuration property, quarkus.oidc.token.binding.certificate=true, in addition to the Vert.x HTTP MTLS configuration, to enforce the MTLS token binding.  See the documentation for more details.   DEMONSTRATING PROOF-OF-POSSESSION (DPOP)  specification describes how access tokens can be cryptographically bound to special JWT tokens called DPoP proofs.    The SPA client generates a private and public key pair, and creates a DPoP proof token to complete the access token acquisition from the OIDC provider. It then forwards this DPoP token to Quarkus with a new DPoP proof. The access token must be bound to the DPoP proof by containing a public JSON Web Key (JWK) key thumbprint which matches the thumbprint of the public JWK key contained in the DPoP proof.  This binding can only be successful if the client uses the same public and private key pair for creating the DPoP proof to request the access token in the previous step and creating another DPoP proof for submitting it alongside the DPoP access token to Quarkus.  Quarkus OIDC will also enforce . Support for custom is also planned.  Adoption of DPoP, compared to that of the MTLS token binding, is expected to progress faster, because DPoP is an application-level protocol, with no expectation that the transport-level MTLS authentication takes place. However, correctly creating DPoP proofs at the SPA level is not straightforward and requires care.  If you are a Keycloak user, then enabling an experimental dpop feature is sufficient to get started. Also check the in the Advanced Configuration section of the and the community blog post.  As far as Quarkus is concerned, you only need to set a single OIDC configuration property, quarkus.oidc.token.authorization-scheme=dpop to accept DPoP tokens and enforce their binding to the accompanying DPoP proofs.  See the documentation for more details.   FINANCIAL-GRADE API (FAPI)  is a general high-security API profile built on top of OAuth2.  Both and specifications are included in the Financial-Grade API 2.0 .   CONCLUSION  In this article, we have discussed two important OAuth2 specifications for sender-constraining access tokens, and .  Both of these token security elevation technologies can be easily supported in Quarkus OIDC, by using a single configuration property only, without having to write a lot of custom code and configuration.  Please experiment with and in Quarkus and let us know what you think."
+  "feed_title": "WildFly",
+  "content": "Hello, WildFly Community!  We are excited to announce that the WildFly Mini Conference is scheduled for March 25th, 2025! Building on the success of our previous events, we’re looking forward to another day of insightful discussions, community engagement, and deep dives into the latest in enterprise Java and WildFly development.  This year’s conference will focus on key topics shaping the future of WildFly and enterprise Java, including:   * Quick Prototyping with WildFly – Learn how to efficiently build and test    applications using WildFly.   * WildFly Day One Operations with Ansible Automation – Discover best practices    for deploying and managing WildFly with Ansible.   * Everything about Jakarta EE TCKs in twenty minutes – A concise session    covering the essentials of Jakarta EE compatibility testing.   * WildFly in a Vendor-Neutral Foundation – Exploring the ecosystem and    collaboration opportunities for WildFly.   * WildFly AI Feature Pack: Deploying an MCP Server – Learn how the WildFly AI    Feature Pack enables intelligent middleware capabilities and enhances    application deployments with AI-driven optimizations.  📅 DATE: TUESDAY, MARCH 25, 2025  ⏰ TIME: 14:00 - 18:00 UTC  🔗 LIVE STREAM:  Make sure to click \"Notify me\" on YouTube to receive reminders before the event starts.  This conference is a great opportunity for Java developers, middleware engineers, and open-source enthusiasts to explore the future of WildFly and enterprise Java. For more details, checkout our . We look forward to seeing you online for another great WildFly Mini Conference!"
 }

src/content/posts-aggregator/11.json

@@ -1,13 +1,13 @@
 {
-  "title": "How Orange leverages Quarkus for seamless access to Telco network capabilities",
-  "link": "https://quarkus.io/blog/orange-telco-core-network-api-management-with-quarkus/",
+  "title": "Sender-constraining access tokens with Quarkus OIDC",
+  "link": "https://quarkus.io/blog/sender-constraining-tokens/",
   "author": [
     {
-      "name": "Thomas Segismont",
+      "name": "Sergey Beryozkin",
       "avatar": null
     }
   ],
-  "date": "2025-03-18T00:00:00.000Z",
+  "date": "2025-03-19T00:00:00.000Z",
   "feed_title": "Quarkus",
-  "content": "INTRODUCTION  As a global telecommunications leader, has always been at the forefront of innovation. Along with Deutsche Telekom, Telefónica, and Vodafone, Orange co-founded the , an initiative aimed at simplifying the consumption of 5G APIs for third-party application developers.  To achieve this goal, Orange needed a flexible and lightweight framework capable of handling constrained API exposure while ensuring compatibility with existing network core systems.  After a rigorous evaluation of multiple frameworks and toolkits — including Quarkus, Ktor, Micronaut, and Vert.x — Orange selected Quarkus as the ideal solution.  , software craftsman at Orange, told us why.   WHY QUARKUS? A FRAMEWORK EVALUATION  The team at Orange identified application startup time as a barrier to dynamic Kubernetes pod management. So they embarked on a comparative study to test alternatives to Spring Boot in a well-defined API wrapper exposure context. Key evaluation criteria included:   * Learning Curve: How easily could a Spring developer transition?   * Kotlin Compatibility: Could the framework work seamlessly with Kotlin?   * Runtime footprint: Could it operate efficiently in a constrained environment?   * Ease of Deployment: How smoothly could it be deployed on Kubernetes?  After extensive testing, Quarkus stood out for multiple reasons:   * Simplicity: A relatively simple learning curve, especially for those familiar    with JAX-RS / Jakarta REST.   * Dev Mode: Very fast startup, live reload and zero configuration Dev Services    (Vault, Redis) result in great developer productivity.   * Modularity: Only required dependencies were embedded, keeping applications    lean.   * Documentation: Well-organized, versioned documentation with working examples.   * Native Compilation: The ability to generate compact native binaries for    Kubernetes deployment.  Despite the strong competition from a vibrant JVM ecosystem, these advantages made Quarkus the preferred choice for exposing 5G APIs at Orange.   LESSONS LEARNED FROM ADOPTING QUARKUS   MIGRATION & DEVELOPMENT EXPERIENCE  Transitioning from Spring to Quarkus was not overly complex, especially for those familiar with JAX-RS / Jakarta REST.  The significantly enhanced productivity in dev and test modes, but required careful consideration for their CI/CD environments, where no container runtime is available.  The modular approach ensured applications remained lightweight but introduced a large number of small dependencies to manage.   SPEC-FIRST API DEVELOPMENT  As spec-first practitioners, integrating OpenAPI specification generation was a crucial requirement that Quarkus handled effectively.   JAVA & KOTLIN INTEROPERABILITY  While Quarkus supports Kotlin, writing full Kotlin extensions proved challenging at times. The team retained some Java code, and Java-Kotlin interoperability worked smoothly.   NATIVE COMPILATION & PERFORMANCE  Native compilation produced compact native executables, but the process of producing them was lengthy. The team reserved it for the final build stage when absolutely necessary.  Some fine-tuning was required to prevent class pruning issues.  When building native executables, the call tree is analyzed to determine which classes and methods are used. Everything that is not used is pruned to reduce the size of the executable and the RSS usage.  In some cases, e.g. when using reflection, you will have to declare explicitly that a class is used so that it ends up being included in the native executable.  Quarkus provides tooling to simplify this configuration.   REACTIVE PROGRAMMING & MUTINY  Having worked extensively with Reactor, the transition to Mutiny had a learning curve.  While effective and more intuitive thanks to its navigable API, it was perceived as more verbose for the simple cases.   ARCHITECTURE OVERVIEW  Orange designed a microservices-based architecture to expose 5G APIs efficiently.   MICROSERVICES & API WRAPPERS  Each API wrapper was implemented as a dedicated microservice for better version control. The team leveraged Reactive APIs wherever possible, since there are a lot of time-consuming asynchronous tasks to be performed on the core network side and saving resources is a business goal.   CI/CD & DEPLOYMENT  Each microservice had its own GitLab repository with an independent build pipeline for its Docker image.  Renovate was used to automate dependency upgrades. A dedicated deployment project pushed new Docker images to an OpenShift cluster using Kustomize + ArgoCD.   INFRASTRUCTURE COMPONENTS  Additional services included:   * Vault for secrets management   * Redis for caching   * Neo4j for database operations   * Kafka for messaging  Vert.x HTTP Proxy was used for routing and backend protection.   RESULTS & IMPACT  After implementing Quarkus in production, Orange successfully deployed ten APIs across various 4G/5G network cores. Over time, the team performed multiple Quarkus version upgrades (2.11 → 3.14), all well-managed through Renovate with minimal code adaptation—except for necessary adjustments during the migration to Jakarta EE."
+  "content": "INTRODUCTION  Single-page application (SPA) runs in the browser and uses to log-in users, without depending on Quarkus OIDC. When the authentication is complete, SPA sends the access token to access Quarkus on behalf of the authenticated user.  Have a look at the simple diagram showing how this process works, copied to this post from the :    As illustrated in the picture above, the OIDC provider authenticates the current user, SPA receives ID and access tokens and uses the access token to access the Quarkus endpoint.  The security challenge that the OAuth2 experts have been trying to address is how to prove that the client such as SPA which is sending the token actually owns this token ? There is nothing in the HTTP Authorization: Bearer <token> header that proves that SPA did not leak the token.  Two specifications for sender-constraining access tokens have emerged over the years, and .   MUTUAL TLS CLIENT AUTHENTICATION AND CERTIFICATE-BOUND ACCESS TOKENS  specification describes how access tokens can be cryptographically bound to the MTLS client certificate.  By proving that the access token is bound to the client certificate, the Quarkus application can get a high degree of confidence that the current access token is constrained to, owned by the client which authenticated to Quarkus over MTLS.    Implementing the cryptographic binding is not complex in this case. The current access token is expected to contain a confirmation with the SHA-256 certificate thumbprint and it must match the thumbprint of the current MTLS client certificate. If the token is in JWT format, then it must include a confirmation claim. If the token is binary then the confirmation must be included in the remote token introspection response.  Such a binding can only be successful if the OpenId Connect provider has access to the same client certificate which is used during the MTLS authentication to Quarkus.  The downside of using the MTLS token binding is that correctly configuring the OpenId Connect provider, ensuring that browsers can request an X509 certiticate authentication when SPA redirects the user to authenticate to the OIDC provider is complex.  If you are a Keycloak user, check the in the Advanced Configuration section of the and the community blog post.  As far as Quarkus is concerned, you only need to set a single OIDC configuration property, quarkus.oidc.token.binding.certificate=true, in addition to the Vert.x HTTP MTLS configuration, to enforce the MTLS token binding.  See the documentation for more details.   DEMONSTRATING PROOF-OF-POSSESSION (DPOP)  specification describes how access tokens can be cryptographically bound to special JWT tokens called DPoP proofs.    The SPA client generates a private and public key pair, and creates a DPoP proof token to complete the access token acquisition from the OIDC provider. It then forwards this DPoP token to Quarkus with a new DPoP proof. The access token must be bound to the DPoP proof by containing a public JSON Web Key (JWK) key thumbprint which matches the thumbprint of the public JWK key contained in the DPoP proof.  This binding can only be successful if the client uses the same public and private key pair for creating the DPoP proof to request the access token in the previous step and creating another DPoP proof for submitting it alongside the DPoP access token to Quarkus.  Quarkus OIDC will also enforce . Support for custom is also planned.  Adoption of DPoP, compared to that of the MTLS token binding, is expected to progress faster, because DPoP is an application-level protocol, with no expectation that the transport-level MTLS authentication takes place. However, correctly creating DPoP proofs at the SPA level is not straightforward and requires care.  If you are a Keycloak user, then enabling an experimental dpop feature is sufficient to get started. Also check the in the Advanced Configuration section of the and the community blog post.  As far as Quarkus is concerned, you only need to set a single OIDC configuration property, quarkus.oidc.token.authorization-scheme=dpop to accept DPoP tokens and enforce their binding to the accompanying DPoP proofs.  See the documentation for more details.   FINANCIAL-GRADE API (FAPI)  is a general high-security API profile built on top of OAuth2.  Both and specifications are included in the Financial-Grade API 2.0 .   CONCLUSION  In this article, we have discussed two important OAuth2 specifications for sender-constraining access tokens, and .  Both of these token security elevation technologies can be easily supported in Quarkus OIDC, by using a single configuration property only, without having to write a lot of custom code and configuration.  Please experiment with and in Quarkus and let us know what you think."
 }

src/content/posts-aggregator/12.json

@@ -1,13 +1,13 @@
 {
-  "title": "Quarkus 3.15.4 released - LTS maintenance release",
-  "link": "https://quarkus.io/blog/quarkus-3-15-4-released/",
+  "title": "How Orange leverages Quarkus for seamless access to Telco network capabilities",
+  "link": "https://quarkus.io/blog/orange-telco-core-network-api-management-with-quarkus/",
   "author": [
     {
-      "name": "Jan Martiška",
+      "name": "Thomas Segismont",
       "avatar": null
     }
   ],
   "date": "2025-03-18T00:00:00.000Z",
   "feed_title": "Quarkus",
-  "content": "Today, we released Quarkus 3.15.4, our next maintenance release for the 3.15 LTS stream.  This release contains bugfixes and documentation improvements.  It should be a safe upgrade for anyone already using 3.15. However, as part of fixing a security issue, one small potentially breaking change had to be applied: . This may affect you if you consume Netty allocator metrics.   UPDATE  To update to Quarkus 3.15, we recommend updating to the latest version of the Quarkus CLI and run:  quarkus update --stream=3.15  Note that quarkus update can update your applications from any version of Quarkus (including 2.x) to Quarkus 3.15.   FULL CHANGELOG  You can get .   COME JOIN US  We value your feedback a lot so please report bugs, ask for improvements… Let’s build something great together!  If you are a Quarkus user or just curious, don’t be shy and join our welcoming community:   * provide feedback on ;   * craft some code and ;   * discuss with us on and on the ;   * ask your questions on ."
+  "content": "INTRODUCTION  As a global telecommunications leader, has always been at the forefront of innovation. Along with Deutsche Telekom, Telefónica, and Vodafone, Orange co-founded the , an initiative aimed at simplifying the consumption of 5G APIs for third-party application developers.  To achieve this goal, Orange needed a flexible and lightweight framework capable of handling constrained API exposure while ensuring compatibility with existing network core systems.  After a rigorous evaluation of multiple frameworks and toolkits — including Quarkus, Ktor, Micronaut, and Vert.x — Orange selected Quarkus as the ideal solution.  , software craftsman at Orange, told us why.   WHY QUARKUS? A FRAMEWORK EVALUATION  The team at Orange identified application startup time as a barrier to dynamic Kubernetes pod management. So they embarked on a comparative study to test alternatives to Spring Boot in a well-defined API wrapper exposure context. Key evaluation criteria included:   * Learning Curve: How easily could a Spring developer transition?   * Kotlin Compatibility: Could the framework work seamlessly with Kotlin?   * Runtime footprint: Could it operate efficiently in a constrained environment?   * Ease of Deployment: How smoothly could it be deployed on Kubernetes?  After extensive testing, Quarkus stood out for multiple reasons:   * Simplicity: A relatively simple learning curve, especially for those familiar    with JAX-RS / Jakarta REST.   * Dev Mode: Very fast startup, live reload and zero configuration Dev Services    (Vault, Redis) result in great developer productivity.   * Modularity: Only required dependencies were embedded, keeping applications    lean.   * Documentation: Well-organized, versioned documentation with working examples.   * Native Compilation: The ability to generate compact native binaries for    Kubernetes deployment.  Despite the strong competition from a vibrant JVM ecosystem, these advantages made Quarkus the preferred choice for exposing 5G APIs at Orange.   LESSONS LEARNED FROM ADOPTING QUARKUS   MIGRATION & DEVELOPMENT EXPERIENCE  Transitioning from Spring to Quarkus was not overly complex, especially for those familiar with JAX-RS / Jakarta REST.  The significantly enhanced productivity in dev and test modes, but required careful consideration for their CI/CD environments, where no container runtime is available.  The modular approach ensured applications remained lightweight but introduced a large number of small dependencies to manage.   SPEC-FIRST API DEVELOPMENT  As spec-first practitioners, integrating OpenAPI specification generation was a crucial requirement that Quarkus handled effectively.   JAVA & KOTLIN INTEROPERABILITY  While Quarkus supports Kotlin, writing full Kotlin extensions proved challenging at times. The team retained some Java code, and Java-Kotlin interoperability worked smoothly.   NATIVE COMPILATION & PERFORMANCE  Native compilation produced compact native executables, but the process of producing them was lengthy. The team reserved it for the final build stage when absolutely necessary.  Some fine-tuning was required to prevent class pruning issues.  When building native executables, the call tree is analyzed to determine which classes and methods are used. Everything that is not used is pruned to reduce the size of the executable and the RSS usage.  In some cases, e.g. when using reflection, you will have to declare explicitly that a class is used so that it ends up being included in the native executable.  Quarkus provides tooling to simplify this configuration.   REACTIVE PROGRAMMING & MUTINY  Having worked extensively with Reactor, the transition to Mutiny had a learning curve.  While effective and more intuitive thanks to its navigable API, it was perceived as more verbose for the simple cases.   ARCHITECTURE OVERVIEW  Orange designed a microservices-based architecture to expose 5G APIs efficiently.   MICROSERVICES & API WRAPPERS  Each API wrapper was implemented as a dedicated microservice for better version control. The team leveraged Reactive APIs wherever possible, since there are a lot of time-consuming asynchronous tasks to be performed on the core network side and saving resources is a business goal.   CI/CD & DEPLOYMENT  Each microservice had its own GitLab repository with an independent build pipeline for its Docker image.  Renovate was used to automate dependency upgrades. A dedicated deployment project pushed new Docker images to an OpenShift cluster using Kustomize + ArgoCD.   INFRASTRUCTURE COMPONENTS  Additional services included:   * Vault for secrets management   * Redis for caching   * Neo4j for database operations   * Kafka for messaging  Vert.x HTTP Proxy was used for routing and backend protection.   RESULTS & IMPACT  After implementing Quarkus in production, Orange successfully deployed ten APIs across various 4G/5G network cores. Over time, the team performed multiple Quarkus version upgrades (2.11 → 3.14), all well-managed through Renovate with minimal code adaptation—except for necessary adjustments during the migration to Jakarta EE."
 }

src/content/posts-aggregator/13.json

@@ -1,13 +1,13 @@
 {
-  "title": "Narayana and its relationship to Red Hat middleware strategy",
-  "link": "https://jbossts.blogspot.com/2025/03/narayana-and-its-relationship-to-red.html",
+  "title": "Quarkus 3.15.4 released - LTS maintenance release",
+  "link": "https://quarkus.io/blog/quarkus-3-15-4-released/",
   "author": [
     {
-      "name": "Tom Jenkinson",
+      "name": "Jan Martiška",
       "avatar": null
     }
   ],
-  "date": "2025-03-17T16:55:00.001Z",
-  "feed_title": "Narayana team blog",
-  "content": "  Hi everyone,   You might have already seen that Red Hat announced significant changes to its middleware strategy last month (if not, please do check out the relevant “Red Hat Blog” article: Evolving our middleware strategy [1]) and so I want to speak a little to the change and its relevance to our Narayana project.   As you may know, Narayana is a part of a number of Red Hat products, in particular Red Hat’s JBoss Enterprise Application Platform product and so this makes the strategic decision relevant to the Narayana project. That said, a key point in that article from the “Red Hat Blog” with regards to our Narayana project is that all transitioning Red Hat technology will remain open source and continue to follow an upstream-first development model. So as well as the technology still relying on being able to upstream-first (in projects like Narayana), it’s also that this upstream should remain open source (you can find what open source means at Red Hat over here [2]). Not only is the Narayana source code open source, but moreover its project operates in an open source manner, exhibiting the principles of open source and gratefully benefits from a healthy community of users and contributors. This will help us to keep innovating in the area of transactions as we move forwards.   I will also take this opportunity to add a “Thank you” for being part of our Narayana community - I am excited to see the results of what we achieve together next!    Tom Jenkinson   [1] https://www.redhat.com/en/blog/evolving-our-middleware-strategy  [2] https://www.redhat.com/en/about/open-source "
+  "date": "2025-03-18T00:00:00.000Z",
+  "feed_title": "Quarkus",
+  "content": "Today, we released Quarkus 3.15.4, our next maintenance release for the 3.15 LTS stream.  This release contains bugfixes and documentation improvements.  It should be a safe upgrade for anyone already using 3.15. However, as part of fixing a security issue, one small potentially breaking change had to be applied: . This may affect you if you consume Netty allocator metrics.   UPDATE  To update to Quarkus 3.15, we recommend updating to the latest version of the Quarkus CLI and run:  quarkus update --stream=3.15  Note that quarkus update can update your applications from any version of Quarkus (including 2.x) to Quarkus 3.15.   FULL CHANGELOG  You can get .   COME JOIN US  We value your feedback a lot so please report bugs, ask for improvements… Let’s build something great together!  If you are a Quarkus user or just curious, don’t be shy and join our welcoming community:   * provide feedback on ;   * craft some code and ;   * discuss with us on and on the ;   * ask your questions on ."
 }

src/content/posts-aggregator/14.json

@@ -1,14 +1,13 @@
 {
-  "title": "Submit to KeyConf25 Japan Call-for-Papers!",
-  "link": "https://www.keycloak.org/2025/03/keyconf-25-japan-call-for-papers",
+  "title": "Narayana and its relationship to Red Hat middleware strategy",
+  "link": "https://jbossts.blogspot.com/2025/03/narayana-and-its-relationship-to-red.html",
   "author": [
     {
-      "name": "Alexander Schwartz",
+      "name": "Tom Jenkinson",
       "avatar": null
     }
   ],
-  "date": "2025-03-17T00:00:00.000Z",
-  "feed_title": "Keycloak Blog",
-  "feed_avatar": "https://www.gravatar.com/avatar/87fe00619f08c241da8dfb23d907ffa2?s=50",
-  "content": "The call for papers for is now open! Submit your talks to the first-ever KeyConf in Japan.  KeyConf 2025 Japan is a half-day meetup in Tokyo, Japan on June 13 where the community of Keycloak gathers. It provides opportunities for technical lectures, growth, and networking with talks related Identity and Access Management (IAM) and Single Sign On (SSO).  This event is designed to share insights from developers and maintainers, as well as the latest features, updates, and real-world use cases of Keycloak. Participants will have the valuable opportunity to interact directly with Keycloak experts and other users, deepening their knowledge.     RELATED EVENTS  A few days later, on June 16-17, takes place in Tokyo as well. The Keycloak team will be on-site for KubeCon Japan, so join us and a lot of other CNCF projects for this event as well.  See you in Tokyo!"
+  "date": "2025-03-17T16:55:00.001Z",
+  "feed_title": "Narayana team blog",
+  "content": "  Hi everyone,   You might have already seen that Red Hat announced significant changes to its middleware strategy last month (if not, please do check out the relevant “Red Hat Blog” article: Evolving our middleware strategy [1]) and so I want to speak a little to the change and its relevance to our Narayana project.   As you may know, Narayana is a part of a number of Red Hat products, in particular Red Hat’s JBoss Enterprise Application Platform product and so this makes the strategic decision relevant to the Narayana project. That said, a key point in that article from the “Red Hat Blog” with regards to our Narayana project is that all transitioning Red Hat technology will remain open source and continue to follow an upstream-first development model. So as well as the technology still relying on being able to upstream-first (in projects like Narayana), it’s also that this upstream should remain open source (you can find what open source means at Red Hat over here [2]). Not only is the Narayana source code open source, but moreover its project operates in an open source manner, exhibiting the principles of open source and gratefully benefits from a healthy community of users and contributors. This will help us to keep innovating in the area of transactions as we move forwards.   I will also take this opportunity to add a “Thank you” for being part of our Narayana community - I am excited to see the results of what we achieve together next!    Tom Jenkinson   [1] https://www.redhat.com/en/blog/evolving-our-middleware-strategy  [2] https://www.redhat.com/en/about/open-source "
 }

src/content/posts-aggregator/15.json

@@ -1,14 +1,14 @@
 {
-  "title": "Keycloak 26.1.4 released",
-  "link": "https://www.keycloak.org/2025/03/keycloak-2614-released",
+  "title": "Submit to KeyConf25 Japan Call-for-Papers!",
+  "link": "https://www.keycloak.org/2025/03/keyconf-25-japan-call-for-papers",
   "author": [
     {
-      "name": null,
+      "name": "Alexander Schwartz",
       "avatar": null
     }
   ],
-  "date": "2025-03-14T00:00:00.000Z",
+  "date": "2025-03-17T00:00:00.000Z",
   "feed_title": "Keycloak Blog",
   "feed_avatar": "https://www.gravatar.com/avatar/87fe00619f08c241da8dfb23d907ffa2?s=50",
-  "content": "To download the release go to .   UPGRADING  Before upgrading refer to for a complete list of changes.   ALL RESOLVED ISSUES   ENHANCEMENTS   * Allow admin to disable automatic refresh of event views admin/ui  * Upgrade to Infinispan 15.0.14   BUGS   * Cannot fetch realm role that was renamed admin/api  * When calling the token revoke endpoint multiple times with the same token, a    database REVOKED-TOKEN constraint error is reported storage  * Admin events: resource type filter does not work admin/ui  * Unwanted placeholder texts in user profile fields admin/ui  * KC_HTTPS_TRUST_STORE_TYPE not working dist/quarkus  * The default setting of the client request object parameter is empty admin/ui"
+  "content": "The call for papers for is now open! Submit your talks to the first-ever KeyConf in Japan.  KeyConf 2025 Japan is a half-day meetup in Tokyo, Japan on June 13 where the community of Keycloak gathers. It provides opportunities for technical lectures, growth, and networking with talks related Identity and Access Management (IAM) and Single Sign On (SSO).  This event is designed to share insights from developers and maintainers, as well as the latest features, updates, and real-world use cases of Keycloak. Participants will have the valuable opportunity to interact directly with Keycloak experts and other users, deepening their knowledge.     RELATED EVENTS  A few days later, on June 16-17, takes place in Tokyo as well. The Keycloak team will be on-site for KubeCon Japan, so join us and a lot of other CNCF projects for this event as well.  See you in Tokyo!"
 }

src/content/posts-aggregator/16.json

@@ -1,13 +1,14 @@
 {
-  "title": "Quarkus & Red Hat's evolving middleware strategy",
-  "link": "https://quarkus.io/blog/quarkus-redhat-strategy/",
+  "title": "Keycloak 26.1.4 released",
+  "link": "https://www.keycloak.org/2025/03/keycloak-2614-released",
   "author": [
     {
-      "name": "Max Rydahl Andersen",
+      "name": null,
       "avatar": null
     }
   ],
-  "date": "2025-03-13T00:00:00.000Z",
-  "feed_title": "Quarkus",
-  "content": "Over the past weeks, we’ve received questions about the that Red Hat’s Middleware engineering and product teams, which include Quarkus, are moving to IBM.  We want to take this opportunity to acknowledge this change while reaffirming what has always been true:  Quarkus is an open-source project driven by a global community of contributors, spanning companies, individuals, and open-source enthusiasts.  From its inception, Quarkus has been shaped by real-world adoption across industries, with companies , leveraging Quarkus’s unmatched performance and developer joy in the Java ecosystem. We recently celebrated our , a testament to the strength of this diverse and thriving community.  Speaking as Quarkus contributors employed by Red Hat and soon IBM, we love our project and intend to keep making it awesome. IBM and Red Hat have clearly communicated that the current and future contributions to Quarkus are a key component of the middleware strategy. IBM has already been an active contributor to Quarkus, and we look forward to increased contribution - alongside the many other individuals and companies who contribute, innovate, and drive Quarkus forward.  Additionally, Quarkus is already on the path to becoming part of an open-source foundation, further ensuring its long-term independence and success as a truly community-driven project. The move to the foundation and the Red Hat/IBM move could look suspicious timing-wise, but the two are unrelated. We described our reasons in a , but if anything, this announcement reaffirms the importance of a foundation-hosted project for its stability.  To our contributors and users: your involvement has always been what makes Quarkus thrive. Keep building, experimenting, and shaping the future of Java with us.  -- The Quarkus Team"
+  "date": "2025-03-14T00:00:00.000Z",
+  "feed_title": "Keycloak Blog",
+  "feed_avatar": "https://www.gravatar.com/avatar/87fe00619f08c241da8dfb23d907ffa2?s=50",
+  "content": "To download the release go to .   UPGRADING  Before upgrading refer to for a complete list of changes.   ALL RESOLVED ISSUES   ENHANCEMENTS   * Allow admin to disable automatic refresh of event views admin/ui  * Upgrade to Infinispan 15.0.14   BUGS   * Cannot fetch realm role that was renamed admin/api  * When calling the token revoke endpoint multiple times with the same token, a    database REVOKED-TOKEN constraint error is reported storage  * Admin events: resource type filter does not work admin/ui  * Unwanted placeholder texts in user profile fields admin/ui  * KC_HTTPS_TRUST_STORE_TYPE not working dist/quarkus  * The default setting of the client request object parameter is empty admin/ui"
 }

src/content/posts-aggregator/17.json

@@ -1,13 +1,13 @@
 {
-  "title": "Quarkus Newsletter #54 - March",
-  "link": "https://quarkus.io/blog/quarkus-newsletter-54/",
+  "title": "Quarkus 3.19.3 - Maintenance release",
+  "link": "https://quarkus.io/blog/quarkus-3-19-3-released/",
   "author": [
     {
-      "name": "James Cobb",
+      "name": "Guillaume Smet",
       "avatar": null
     }
   ],
   "date": "2025-03-12T00:00:00.000Z",
   "feed_title": "Quarkus",
-  "content": "Make sure you read Mario Fusco’s two-part blog about Agentic AI with Quarkus, where he discusses common workflows and agentic AI patterns and architectures, with practical examples using Quarkus and LangChain4j. Learn about the power of intelligent applications by combining the robustness of Java, the efficiency of Quarkus, and the advanced capabilities of RAG in a great article by Daniel Oh. Emil Lefkof gives a real-world example of how LangChain4j and AI can be leveraged to automatically extract structured metadata from PDF documents. Leveraging the combination of LangChain4j and Google Gemini AI proves to be a powerful approach for automating document analysis workflows. \"Performance & Productivity: Rethinking Java Dependencies for the Cloud Era\" by Markus Eisele discusses how Quarkus extensions are curated, lightweight, and optimized for microservices and serverless.  You will also see the latest Quarkus Insights episodes, top tweets/discussions and upcoming Quarkus attended events.  Check out !  Want to get newsletters in your inbox? using the on page form."
+  "content": "We released Quarkus 3.19.3, the second (we skipped 3.19.0) maintenance release for our 3.19 release train.  We also released two candidate releases:   * Quarkus 3.20.0.CR1 LTS - it is going to be our next LTS, it is based on 3.19   * Quarkus 3.21.0.CR1 - a regular minor release with new features   UPDATE  To update to Quarkus 3.19, we recommend updating to the latest version of the Quarkus CLI and run:  quarkus update  Note that quarkus update can update your applications from any version of Quarkus (including 2.x) to Quarkus 3.19.  For more information about the adjustments you need to make to your applications, please refer to the .   FULL CHANGELOG  You can get the full changelog of on GitHub.   COME JOIN US  We value your feedback a lot so please report bugs, ask for improvements… Let’s build something great together!  If you are a Quarkus user or just curious, don’t be shy and join our welcoming community:   * provide feedback on ;   * craft some code and ;   * discuss with us on and on the ;   * ask your questions on ."
 }

src/content/posts-aggregator/18.json

@@ -1,13 +1,13 @@
 {
-  "title": "Running SQLite in Pure Java with Quarkus",
-  "link": "https://quarkus.io/blog/sqlite4j-pure-java-sqlite/",
+  "title": "Quarkus Newsletter #54 - March",
+  "link": "https://quarkus.io/blog/quarkus-newsletter-54/",
   "author": [
     {
-      "name": "Andrea Peruffo",
+      "name": "James Cobb",
       "avatar": null
     }
   ],
   "date": "2025-03-12T00:00:00.000Z",
   "feed_title": "Quarkus",
-  "content": "What if you could run a C-based database in pure Java, with zero configuration, and even compile it to a native image effortlessly? With the new Quarkiverse extension , you can do exactly that.  Traditionally, embedded databases in Java require reimplementing their C counterparts, often leading to differences in behavior, missing optimizations, and delayed bug fixes. However, provides a JDBC driver that leverages the original SQLite C implementation while running safely inside a sandbox.   HANDS-ON EXAMPLE  To see in action, you can start with any existing Quarkus application or one of the . If you prefer a ready-made example, check out , which integrates SQLite within a Quarkus application using Hibernate ORM.  By simply changing the JDBC driver dependency, you can embed a fully functional SQLite database inside your application while retaining all the benefits of the native SQLite implementation.  To get started, add the extension dependency to your pom.xml:  <dependency>     <groupId>io.quarkiverse.jdbc</groupId>     <artifactId>quarkus-jdbc-sqlite4j</artifactId> </dependency>  Then, configure your Quarkus application to use SQLite with standard JDBC settings:  quarkus.datasource.db-kind=sqlite quarkus.datasource.jdbc.url=jdbc:sqlite:sample.db quarkus.datasource.jdbc.min-size=1  You can now use your datasource as you normally would with Hibernate and Panache. Note that we keep a minimum connection pool size > 0 to avoid redundant copies from disk to memory of the database.   RUNNING IN A SECURE SANDBOX  Under the hood, SQLite runs in a fully in-memory sandboxed environment, ensuring security and isolation.    When a connection to a local file is opened, the following occurs:   1. The database file is copied from disk to an in-memory Virtual FileSystem.   2. A connection is established to the in-memory database.  While this approach is highly secure, many users need to persist database changes. One recommended solution is to periodically back up the in-memory database to disk. This can be achieved through a scheduled job that:   1. Backs up the in-memory database to a new file.   2. Copies the backup to the host file system.   3. Atomically replaces the old database file with the new backup.  This setup ensures a seamless experience while maintaining SQLite’s sandboxed security. You can adapt this approach to fit your specific needs.  Here’s a sample implementation:  @ApplicationScoped public class SQLiteBackup {     @ConfigProperty(name = \"quarkus.datasource.jdbc.url\")     String jdbcUrl;      @Inject     AgroalDataSource dataSource;      // Execute a backup every 10 seconds     @Scheduled(delay=10, delayUnit=TimeUnit.SECONDS, every=\"10s\")     void scheduled() { backup(); }      // Execute a backup during shutdown     public void onShutdown(@Observes ShutdownEvent event) { backup(); }      void backup() {         String dbFile = jdbcUrl.substring(\"jdbc:sqlite:\".length());          var originalDbFilePath = Paths.get(dbFile);         var backupDbFilePath = originalDbFilePath                                     .toAbsolutePath()                                     .getParent()                                     .resolve(originalDbFilePath.getFileName() + \"_backup\");          try (var conn = dataSource.getConnection();                 var stmt = conn.createStatement()) {             // Execute the backup             stmt.executeUpdate(\"backup to \" + backupDbFilePath);             // Atomically replace the DB file with its backup             Files.move(backupDbFilePath, originalDbFilePath,                 StandardCopyOption.ATOMIC_MOVE,                 StandardCopyOption.REPLACE_EXISTING);         } catch (IOException | SQLException e) {             throw new RuntimeException(\"Failed to back up the database\", e);         }     } }   TECHNICAL DEEP DIVE  compiles the official SQLite C to WebAssembly (Wasm), which is then translated into Java bytecode using the . This enables SQLite to run in a pure Java environment while maintaining its full functionality.     SECURITY AND ISOLATION  One of the key benefits of this approach is security. Running SQLite inside a Wasm sandbox ensures memory safety and isolates it from the host system, making it an excellent choice for applications that require embedded databases while avoiding the risks of native code execution.   CONCLUSION  With the new extension, you get the best of both worlds: the power and reliability of SQLite combined with the safety and portability of Java. This extension seamlessly integrates SQLite into Quarkus applications while maintaining a lightweight and secure architecture. Best of all, everything compiles effortlessly with native-image.  Ready to try it out? Give a spin in your projects and experience the benefits of running SQLite in pure Java with Quarkus!   PRIOR ART   *    * "
+  "content": "Make sure you read Mario Fusco’s two-part blog about Agentic AI with Quarkus, where he discusses common workflows and agentic AI patterns and architectures, with practical examples using Quarkus and LangChain4j. Learn about the power of intelligent applications by combining the robustness of Java, the efficiency of Quarkus, and the advanced capabilities of RAG in a great article by Daniel Oh. Emil Lefkof gives a real-world example of how LangChain4j and AI can be leveraged to automatically extract structured metadata from PDF documents. Leveraging the combination of LangChain4j and Google Gemini AI proves to be a powerful approach for automating document analysis workflows. \"Performance & Productivity: Rethinking Java Dependencies for the Cloud Era\" by Markus Eisele discusses how Quarkus extensions are curated, lightweight, and optimized for microservices and serverless.  You will also see the latest Quarkus Insights episodes, top tweets/discussions and upcoming Quarkus attended events.  Check out !  Want to get newsletters in your inbox? using the on page form."
 }

src/content/posts-aggregator/19.json

@@ -1,13 +1,13 @@
 {
-  "title": "Quarkus 3.20 - new LTS version",
-  "link": "https://quarkus.io/blog/quarkus-3-20-0-released/",
+  "title": "WildFly 36 Beta is released!",
+  "link": "https://wildfly.org//news/2025/03/27/WildFly36Beta-released/",
   "author": [
     {
-      "name": "Guillaume Smet",
+      "name": "Darran Lofthouse",
       "avatar": null
     }
   ],
-  "date": "2025-03-26T00:00:00.000Z",
-  "feed_title": "Quarkus",
-  "content": "It is our pleasure to announce the release of Quarkus 3.20, which is our new LTS (Long Term Support) version.  This version is built on the top of Quarkus 3.19 with some additional bugfixes. New features landed in , which was also released today.  If you want to know more about our LTS policy, the is a must read.  LTS releases are supported for 12 months.  If you are coming from the previous LTS, Quarkus 3.15, there are a lot of exciting new features and we recommend reading the following announcements:   *    *    *    *    UPDATE  To update to Quarkus 3.20, we recommend updating to the latest version of the Quarkus CLI and run:  quarkus update  Note that quarkus update can update your applications from any version of Quarkus (including 2.x) to Quarkus 3.20 LTS.  If you are upgrading from 3.19, there’s nothing to do as 3.20 is the direct continuation of 3.19.  If you are upgrading from the previous LTS, Quarkus 3.15, please refer to the following migration guides:   *    *    *    *    * - this one is empty as 3.20 is the continuation of 3.19  Note that quarkus update should handle most of the heavy lifting for you, but there are still cases that should be handled manually and we recommend reading these migration guides carefully.   WHAT’S NEW?   PLATFORM COMPONENT UPGRADES  CAMEL QUARKUS  Camel Quarkus has been updated to 3.20.0. You can find everything you need to know about it in the .  QUARKUS CXF  Quarkus CXF 3.20 was released and is now available in . Check the release notes for more information about what is new in this release.  AMAZON SERVICES  The Amazon Services extensions have been upgraded to version 3.3.1.   FULL CHANGELOG  The core part of Quarkus 3.20.0 is a rebadged release of Quarkus 3.19.4 so nothing new here.   CONTRIBUTORS  The Quarkus community is growing and has now . Many many thanks to each and everyone of them.  In particular for the 3.20 release, thanks to Ales Justin, Alexey Loubyansky, Andreas Maechler, Andy Damevin, Auri Munoz, brunobat, Clement Escoffier, cmoulliard, David Cotton, Dennis Kronbügel, Fabian, Foivos Zakkak, Georg Leber, George Gastaldi, Georgios Andrianakis, Guillaume Smet, Jakub Jedlicka, Jan Martiska, jcjveraa, Karm Michal Babacek, Katia Aresti, Ladislav Thon, Marco Belladelli, Martin Kouba, Martin Panzer, masecla22, Maximilian Zellhofer, melloware, Michal Maléř, Michal Vavřík, Ozan Gunalp, Peter Palaga, Phillip Kruger, Robert Stupp, Roberto Cortez, Rolfe Dlugy-Hegwer, Ryan Dens, Rüdiger zu Dohna, Sergey Beryozkin, shjones, Stephan Strate, Steve Hawkins, Stuart Douglas, Thomas Canava, w0pp, Welton Rodrigo Torres Nascimento, Willem Jan Glerum, xstefank, and Yoshikazu Nojima.  The list is a bit smaller than usual as 3.20 only contains bugfixes on top of 3.19.   COME JOIN US  We value your feedback a lot so please report bugs, ask for improvements… Let’s build something great together!  If you are a Quarkus user or just curious, don’t be shy and join our welcoming community:   * provide feedback on ;   * craft some code and ;   * discuss with us on and on the ;   * ask your questions on ."
+  "date": "2025-03-27T00:00:00.000Z",
+  "feed_title": "WildFly",
+  "content": "I’m pleased to announce that the new WildFly 36.0.0.Beta1 release is available for download at .  As can be seen from the a lot of issues were resolved in this release but I would also like to call out some of the following highlights:   * [] — Add a prometheus endpoint to the micrometer extension   * [] — Support remote+tls with EJBClient and remote-outbound-connection   * [] — Promote ajp-listener AJP_ALLOWED_REQUEST_ATTRIBUTES_PATTERN to community    stability   * [] — Promote undertow subsystem’s reuse-x-forwarded and rewrite-host header    configurability to community stability  Within the WildFly Preview distribution we also .  We’ve also enhanced , so it is now possible to using !  Please try out this release and let us know how you get on."
 }

src/content/posts-aggregator/20.json

@@ -1,6 +1,6 @@
 {
-  "title": "Quarkus 3.21 - TLS Registry support for MongoDB Client",
-  "link": "https://quarkus.io/blog/quarkus-3-21-0-released/",
+  "title": "Quarkus 3.20 - new LTS version",
+  "link": "https://quarkus.io/blog/quarkus-3-20-0-released/",
   "author": [
     {
       "name": "Guillaume Smet",
@@ -9,5 +9,5 @@
   ],
   "date": "2025-03-26T00:00:00.000Z",
   "feed_title": "Quarkus",
-  "content": "Today, together with , we released Quarkus 3.21.  Whereas Quarkus 3.20 LTS is the direct continuation of Quarkus 3.19, Quarkus 3.21 comes with new features.  It comes with a lot of small enhancements and the support for the TLS Registry in the MongoDB Client extension.   UPDATE  To update to Quarkus 3.21, we recommend updating to the latest version of the Quarkus CLI and run:  quarkus update  Note that quarkus update can update your applications from any version of Quarkus (including 2.x) to Quarkus 3.21.  For more information about the adjustments you need to make to your applications, please refer to the .   WHAT’S NEW?   TLS REGISTRY SUPPORT FOR MONGODB CLIENT  We continue to deploy the TLS registry we included a while ago to centralize and simplify the TLS configuration.  In this version, we added TLS registry support to the MongoDB Client extension.   PLATFORM COMPONENT UPGRADES  QUARKUS CXF  Quarkus CXF 3.21 was released and is now available in . Check the release notes for more information about what is new in this release.  CAMEL QUARKUS  Camel Quarkus has been upgraded to 3.20.0. You can consult the for more information.  AMAZON SERVICES  The Amazon Services extensions have been upgraded to version 3.3.1.   FULL CHANGELOG  You can get the full changelog of and on GitHub.   CONTRIBUTORS  The Quarkus community is growing and has now . Many many thanks to each and everyone of them.  In particular for the 3.21 release, thanks to Ales Justin, Alexander Schwartz, Alexey Loubyansky, Andrea Boriero, Andreas Maechler, Andy Damevin, Auri Munoz, Bill Burke, Bruno Baptista, Clement Escoffier, cmoulliard, David Cotton, dc1248, Dennis Kronbügel, Fabian, Felix König, Foivos Zakkak, Francesco Nigro, Georg Leber, George Gastaldi, Georgios Andrianakis, Giancarlo Calderón Cárdenas, Guillaume Nodet, Guillaume Smet, Holly Cummins, i10320, Ioannis Canellos, Jakub Jedlicka, Jan Martiska, jcjveraa, Jose Carvajal, Karm Michal Babacek, Katia Aresti, Khosbilegt Bilegsaikhan, Ladislav Thon, Loïc Mathieu, Luis Rubiera, Marco Belladelli, marko-bekhta, Martin Kouba, Martin Panzer, masecla22, Matej Novotny, Matheus Cruz, Maximilian Zellhofer, Melloware, Michal Maléř, Michal Vavřík, Ozan Gunalp, Peter Palaga, PhilKes, Phillip Krüger, Robert Stupp, Robert Toyonaga, Roberto Cortez, Rolfe Dlugy-Hegwer, Ryan Dens, Rüdiger zu Dohna, Sanne Grinovero, Sergey Beryozkin, Severin Gehwolf, shjones, SpaceFox, Stephan Strate, Steve Hawkins, Stuart Douglas, Tamas Cservenak, Thom Castermans, Thomas Canava, Thomas Segismont, w0pp, Welton Rodrigo Torres Nascimento, Willem Jan Glerum, xstefank, Yoann Rodière, and Yoshikazu Nojima.   COME JOIN US  We value your feedback a lot so please report bugs, ask for improvements… Let’s build something great together!  If you are a Quarkus user or just curious, don’t be shy and join our welcoming community:   * provide feedback on ;   * craft some code and ;   * discuss with us on and on the ;   * ask your questions on ."
+  "content": "It is our pleasure to announce the release of Quarkus 3.20, which is our new LTS (Long Term Support) version.  This version is built on the top of Quarkus 3.19 with some additional bugfixes. New features landed in , which was also released today.  If you want to know more about our LTS policy, the is a must read.  LTS releases are supported for 12 months.  If you are coming from the previous LTS, Quarkus 3.15, there are a lot of exciting new features and we recommend reading the following announcements:   *    *    *    *    UPDATE  To update to Quarkus 3.20, we recommend updating to the latest version of the Quarkus CLI and run:  quarkus update  Note that quarkus update can update your applications from any version of Quarkus (including 2.x) to Quarkus 3.20 LTS.  If you are upgrading from 3.19, there’s nothing to do as 3.20 is the direct continuation of 3.19.  If you are upgrading from the previous LTS, Quarkus 3.15, please refer to the following migration guides:   *    *    *    *    * - this one is empty as 3.20 is the continuation of 3.19  Note that quarkus update should handle most of the heavy lifting for you, but there are still cases that should be handled manually and we recommend reading these migration guides carefully.   WHAT’S NEW?   PLATFORM COMPONENT UPGRADES  CAMEL QUARKUS  Camel Quarkus has been updated to 3.20.0. You can find everything you need to know about it in the .  QUARKUS CXF  Quarkus CXF 3.20 was released and is now available in . Check the release notes for more information about what is new in this release.  AMAZON SERVICES  The Amazon Services extensions have been upgraded to version 3.3.1.   FULL CHANGELOG  The core part of Quarkus 3.20.0 is a rebadged release of Quarkus 3.19.4 so nothing new here.   CONTRIBUTORS  The Quarkus community is growing and has now . Many many thanks to each and everyone of them.  In particular for the 3.20 release, thanks to Ales Justin, Alexey Loubyansky, Andreas Maechler, Andy Damevin, Auri Munoz, brunobat, Clement Escoffier, cmoulliard, David Cotton, Dennis Kronbügel, Fabian, Foivos Zakkak, Georg Leber, George Gastaldi, Georgios Andrianakis, Guillaume Smet, Jakub Jedlicka, Jan Martiska, jcjveraa, Karm Michal Babacek, Katia Aresti, Ladislav Thon, Marco Belladelli, Martin Kouba, Martin Panzer, masecla22, Maximilian Zellhofer, melloware, Michal Maléř, Michal Vavřík, Ozan Gunalp, Peter Palaga, Phillip Kruger, Robert Stupp, Roberto Cortez, Rolfe Dlugy-Hegwer, Ryan Dens, Rüdiger zu Dohna, Sergey Beryozkin, shjones, Stephan Strate, Steve Hawkins, Stuart Douglas, Thomas Canava, w0pp, Welton Rodrigo Torres Nascimento, Willem Jan Glerum, xstefank, and Yoshikazu Nojima.  The list is a bit smaller than usual as 3.20 only contains bugfixes on top of 3.19.   COME JOIN US  We value your feedback a lot so please report bugs, ask for improvements… Let’s build something great together!  If you are a Quarkus user or just curious, don’t be shy and join our welcoming community:   * provide feedback on ;   * craft some code and ;   * discuss with us on and on the ;   * ask your questions on ."
 }

src/content/posts-aggregator/3.json

@@ -1,13 +1,13 @@
 {
-  "title": "RESTEasy and Red Hat's Middleware Strategy",
-  "link": "https://resteasy.dev/2025/03/19/red-hat-ibm/",
+  "title": "Vlog: WildFly AI - monitor and troubleshoot a WildFly server with the WildFly chatbot.",
+  "link": "https://youtu.be/crSKeeBsXoE",
   "author": [
     {
-      "name": null,
+      "name": "Jean-François Denise",
       "avatar": null
     }
   ],
-  "date": "2025-03-19T18:11:11.000Z",
-  "feed_title": "RESTEasy",
-  "content": ""
+  "date": "2025-03-21T00:00:00.000Z",
+  "feed_title": "WildFly",
+  "content": "This video demonstrates how you can interact with a WildFly server using natural language."
 }

src/content/posts-aggregator/4.json

@@ -1,13 +1,13 @@
 {
-  "title": "Quarkus 3.19.4 - Maintenance release",
-  "link": "https://quarkus.io/blog/quarkus-3-19-4-released/",
+  "title": "RESTEasy and Red Hat's Middleware Strategy",
+  "link": "https://resteasy.dev/2025/03/19/red-hat-ibm/",
   "author": [
     {
-      "name": "Guillaume Smet",
+      "name": null,
       "avatar": null
     }
   ],
-  "date": "2025-03-19T00:00:00.000Z",
-  "feed_title": "Quarkus",
-  "content": "We released Quarkus 3.19.4, the third (we skipped 3.19.0) maintenance release for our 3.19 release train.  Next week, we will release both:   * Quarkus 3.20 LTS, our next LTS release with 1-year maintenance - it is based    on 3.19   * Quarkus 3.21, a regular release including new features   UPDATE  To update to Quarkus 3.19, we recommend updating to the latest version of the Quarkus CLI and run:  quarkus update  Note that quarkus update can update your applications from any version of Quarkus (including 2.x) to Quarkus 3.19.  For more information about the adjustments you need to make to your applications, please refer to the .   FULL CHANGELOG  You can get the full changelog of on GitHub.   COME JOIN US  We value your feedback a lot so please report bugs, ask for improvements… Let’s build something great together!  If you are a Quarkus user or just curious, don’t be shy and join our welcoming community:   * provide feedback on ;   * craft some code and ;   * discuss with us on and on the ;   * ask your questions on ."
+  "date": "2025-03-19T18:11:11.000Z",
+  "feed_title": "RESTEasy",
+  "content": ""
 }

src/content/posts-aggregator/5.json

@@ -1,13 +1,13 @@
 {
-  "title": "Save the Date: WildFly Mini Conference on March 25th, 2025",
-  "link": "https://wildfly.org//news/2025/03/19/WildFly-mini-conference-2025-save-the-date/",
+  "title": "Quarkus 3.19.4 - Maintenance release",
+  "link": "https://quarkus.io/blog/quarkus-3-19-4-released/",
   "author": [
     {
-      "name": "Ranabir Chakraborty",
+      "name": "Guillaume Smet",
       "avatar": null
     }
   ],
   "date": "2025-03-19T00:00:00.000Z",
-  "feed_title": "WildFly",
-  "content": "Hello, WildFly Community!  We are excited to announce that the WildFly Mini Conference is scheduled for March 25th, 2025! Building on the success of our previous events, we’re looking forward to another day of insightful discussions, community engagement, and deep dives into the latest in enterprise Java and WildFly development.  This year’s conference will focus on key topics shaping the future of WildFly and enterprise Java, including:   * Quick Prototyping with WildFly – Learn how to efficiently build and test    applications using WildFly.   * WildFly Day One Operations with Ansible Automation – Discover best practices    for deploying and managing WildFly with Ansible.   * Everything about Jakarta EE TCKs in twenty minutes – A concise session    covering the essentials of Jakarta EE compatibility testing.   * WildFly in a Vendor-Neutral Foundation – Exploring the ecosystem and    collaboration opportunities for WildFly.   * WildFly AI Feature Pack: Deploying an MCP Server – Learn how the WildFly AI    Feature Pack enables intelligent middleware capabilities and enhances    application deployments with AI-driven optimizations.  📅 DATE: TUESDAY, MARCH 25, 2025  ⏰ TIME: 14:00 - 18:00 UTC  🔗 LIVE STREAM:  Make sure to click \"Notify me\" on YouTube to receive reminders before the event starts.  This conference is a great opportunity for Java developers, middleware engineers, and open-source enthusiasts to explore the future of WildFly and enterprise Java. For more details, checkout our . We look forward to seeing you online for another great WildFly Mini Conference!"
+  "feed_title": "Quarkus",
+  "content": "We released Quarkus 3.19.4, the third (we skipped 3.19.0) maintenance release for our 3.19 release train.  Next week, we will release both:   * Quarkus 3.20 LTS, our next LTS release with 1-year maintenance - it is based    on 3.19   * Quarkus 3.21, a regular release including new features   UPDATE  To update to Quarkus 3.19, we recommend updating to the latest version of the Quarkus CLI and run:  quarkus update  Note that quarkus update can update your applications from any version of Quarkus (including 2.x) to Quarkus 3.19.  For more information about the adjustments you need to make to your applications, please refer to the .   FULL CHANGELOG  You can get the full changelog of on GitHub.   COME JOIN US  We value your feedback a lot so please report bugs, ask for improvements… Let’s build something great together!  If you are a Quarkus user or just curious, don’t be shy and join our welcoming community:   * provide feedback on ;   * craft some code and ;   * discuss with us on and on the ;   * ask your questions on ."
 }