Published latest aggregated blog posts

Author: jbossorg-bot

src/content/posts-aggregator/1.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 free 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.000Z",
+  "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/10.json

@@ -1,13 +1,14 @@
 {
-  "title": "Quarkus 3.19.2 - Maintenance release",
-  "link": "https://quarkus.io/blog/quarkus-3-19-2-released/",
+  "title": "Introducing the Keycloak Austria User Group",
+  "link": "https://www.keycloak.org/2025/03/austria-user-group",
   "author": [
     {
-      "name": "Guillaume Smet",
+      "name": "Christoph Kofler",
       "avatar": null
     }
   ],
   "date": "2025-03-05T00:00:00.000Z",
-  "feed_title": "Quarkus",
-  "content": "We released Quarkus 3.19.2, the first (we skipped 3.19.0) maintenance release for our 3.19 release train.  If you have bugs lurking around, please report them as we aim at stabilizing everything before the next LTS.   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 ."
+  "feed_title": "Keycloak Blog",
+  "feed_avatar": "https://www.gravatar.com/avatar/87fe00619f08c241da8dfb23d907ffa2?s=50",
+  "content": "Join the event on March 11th to , and subscribe to the Meetup to get invitations for future events. Read on to find out about previous topics that have been recorded and upcoming events.  --------------------------------------------------------------------------------  It happened to me several times that I was sitting in a workshop about any topic and the term “Keycloak” was used. Not in a spectacular tone, but rather like “We have Keycloak for this and that, and it just works!” Christoph Kofler, COO at Gepardec, had similar experiences. Thus, we already discussed some years ago that Keycloak is somehow an unsung hero, a hidden star, very much appreciated, but not in the spotlight of any encountering or events.  End of 2023, we concluded that we want to establish a local community in Austria, very informal, very technical - just for like-minded people to meet, give and take experiences and have a good time together. It was easy to set up the group in the meetup platform () and also announced the in March 2024 at the Red Hat Office in Vienna. To our positive surprise, we almost immediately jumped to 100 members and had 40+ participants on-site. The meeting was framed by a very nice greeting note from the Keycloak founder . We had two great sessions about and from the community and afterward beer and original Leberkäse from . The feedback was overwhelmingly positive, participants talked, laughed and connected till 9 pm.    This has motivated us to have two more gatherings in 2024, one at Posedio and one at ÖBB (“Austrian Railway systems”) who kindly offered to provide location, food and beverages. Again, the talks lead to lots of questions and discussions which lasted till the late evening. Moreover, we also have established a with all recorded sessions and many members from the local Austrian Keycloak community have participated in in September 2024, organized by .  We are looking forward to another which are already planned. If you are interested to participate and/or contribute a talk, please get in touch with us:  ,"
 }

src/content/posts-aggregator/11.json

@@ -1,13 +1,13 @@
 {
-  "title": "WildFly and Red Hat's middleware strategy",
-  "link": "https://wildfly.org//news/2025/03/05/WildFly_and_Red_Hat_strategy/",
+  "title": "Quarkus 3.19.2 - Maintenance release",
+  "link": "https://quarkus.io/blog/quarkus-3-19-2-released/",
   "author": [
     {
-      "name": "Brian Stansberry",
+      "name": "Guillaume Smet",
       "avatar": null
     }
   ],
   "date": "2025-03-05T00:00:00.000Z",
-  "feed_title": "WildFly",
-  "content": "Hi,  Red Hat announced significant changes to its middleware strategy last month, and I wanted to give the WildFly community some context about those changes and how they affect WildFly.  The Red Hat announcement can be found on the Red Hat blog:    Some key points there are:   * Red Hat’s Middleware and Integration Engineering and Products teams are    moving to IBM in May 2025.   * Red Hat will continue to sell and support its Middleware and Integration    offerings as they do today; this will not be impacted.   * All transitioning Red Hat technology will remain open source and continue to    follow an upstream-first development model.  Red Hat has sponsored the WildFly project (fka JBoss AS) since 2006, when it bought JBoss, Inc. Now, Red Hat’s participation in and support for WildFly is being transferred to IBM.  WildFly has a vibrant, healthy community with different kinds of contributions from people from various companies all over the world. Still, it’s undoubtedly the case that the bulk of our code contributions come from Red Hat employees working on the middleware product teams that are moving to IBM.  However, I don’t expect this change to have a significant impact on the WildFly project, beyond the inevitable temporary disruption as the people who are moving focus some of their energy on the move.  WildFly is the upstream project for Red Hat’s JBoss Enterprise Application Platform (EAP) product. EAP will continue to be sold and supported through Red Hat, and will continue to be developed following an upstream-first development model. That model means that features and fixes for EAP will land first in WildFly’s main branch or in the main branches of the components integrated into WildFly.  IBM and Red Hat leaders have clearly stated that current and future contributions to WildFly are a key component of their middleware strategy.  So, we’ll continue to work on behalf of the WildFly community, striving to improve WildFly. Some things we’ll be doing:   * We’ll have another soon. Watch this space for more details!   * We’re hard at work on WildFly 36, with its final release expected around    April 10.   * After that, we move on to WildFly 37, which is expected in July. We intend to    continue producing feature releases quarterly, followed by a bug fix release    about a month later.   * Work continues on EE 11 support in WildFly Preview and eventually in standard    WildFly.   * We’ll continue to innovate outside of the Jakarta and MicroProfile areas,    including and .   * We’ll continue to keep up with advancements in Java SE, with an aspiration of    having each WildFly feature release run well on the latest SE release    available when it comes out, and being able to recommend the latest LTS SE    release as the preferred option as soon as possible after it comes out.  Last month, I posted about . I intend to continue with this process. Note that our interest in moving to an open source foundation was not triggered by Red Hat’s strategy change. We’d been thinking about a move to a foundation since well before we learned about the move to IBM.  Personally, I’ll be sorry to leave Red Hat, which has been a fantastic place to work. Back in 2006, I was sorry to leave JBoss, Inc for the much bigger Red Hat, too, but it worked out very well. I think combining forces with Java teams at IBM makes a lot of sense and will be good for the middleware projects and products. There’s a lot of growth and innovation potential in the middleware technologies we offer and I’m looking forward to being part of a larger team excited about and focused on that potential.  Best regards,  Brian Stansberry WildFly Project Lead"
+  "feed_title": "Quarkus",
+  "content": "We released Quarkus 3.19.2, the first (we skipped 3.19.0) maintenance release for our 3.19 release train.  If you have bugs lurking around, please report them as we aim at stabilizing everything before the next LTS.   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/12.json

@@ -1,14 +1,13 @@
 {
-  "title": "Keycloak 26.1.3 released",
-  "link": "https://www.keycloak.org/2025/02/keycloak-2613-released",
+  "title": "WildFly and Red Hat's middleware strategy",
+  "link": "https://wildfly.org//news/2025/03/05/WildFly_and_Red_Hat_strategy/",
   "author": [
     {
-      "name": null,
+      "name": "Brian Stansberry",
       "avatar": null
     }
   ],
-  "date": "2025-02-28T00:00:00.000Z",
-  "feed_title": "Keycloak Blog",
-  "feed_avatar": "https://www.gravatar.com/avatar/87fe00619f08c241da8dfb23d907ffa2?s=50",
-  "content": "To download the release go to .   HIGHLIGHTS   SEND RESET EMAIL FORCE LOGIN AGAIN FOR FEDERATED USERS AFTER RESET CREDENTIALS  In a new configuration option was added to the reset-credential-email (Send Reset Email) authenticator to allow changing the default behavior after the reset credentials flow. Now the option force-login (Force login after reset) is adding a third configuration value only-federated, which means that the force login is true for federated users and false for the internal database users. The new behavior is now the default. This way all users managed by user federation providers, whose implementation can be not so tightly integrated with Keycloak, are forced to login again after the reset credentials flow to avoid any issue. This change in behavior is due to the secure by default policy.  For more information, see .   UPGRADING  Before upgrading refer to for a complete list of changes.   ALL RESOLVED ISSUES   BUGS   * Invalid migration export for empty database core  * Redirect after linking account account/ui  * Viewing user events requires `view-realm`-role admin/ui  * Keycloak user attribute key broken in Keycloak 26.1.0 admin/ui  * When linking IDP to an organization hide on login sets as off admin/ui  * SAML2 Client Signing Keys Config does not accept PEM import admin/ui  * Comboxes do not display selected option after reset admin/ui  * MeterFilter is configured after a Meter has been registered dist/quarkus  * CVE-2025-0736 Error during JGroups channel creation may reveal secure    information  * Admin console: unable to edit user profile attribute either on the form or    the JSON editor. admin/ui  * CI fails with \"Problem creating zip: Execution exception: Java heap space\" ci  * Error on import of a public key (pem) authentication  * Customized quarkus.properties for MySQL cause \"Unable to find the JDBC driver    (org.h2.Driver)\"，The server fails to start. storage  * Wrong organization claim assignment in JWT access token organizations  * Change default value for force-login option in reset-credential-email    authentication  * Login form can be used to determine which email addresses / usernames are in    the system login/ui  * Problems changing pre-defined user profile attributes admin/ui  * Upgrade to latest JGroups patch version  * CVE-2024-47072 - XStream is vulnerable to a Denial of Service attack due to    stack overflow from a manipulated binary input stream  * Password policies like NoUsername consider case-sensitivity authentication  * External Link Test failing docs  * Property Name Casing Mismatch in ProtocolMapperUtils saml"
+  "date": "2025-03-05T00:00:00.000Z",
+  "feed_title": "WildFly",
+  "content": "Hi,  Red Hat announced significant changes to its middleware strategy last month, and I wanted to give the WildFly community some context about those changes and how they affect WildFly.  The Red Hat announcement can be found on the Red Hat blog:    Some key points there are:   * Red Hat’s Middleware and Integration Engineering and Products teams are    moving to IBM in May 2025.   * Red Hat will continue to sell and support its Middleware and Integration    offerings as they do today; this will not be impacted.   * All transitioning Red Hat technology will remain open source and continue to    follow an upstream-first development model.  Red Hat has sponsored the WildFly project (fka JBoss AS) since 2006, when it bought JBoss, Inc. Now, Red Hat’s participation in and support for WildFly is being transferred to IBM.  WildFly has a vibrant, healthy community with different kinds of contributions from people from various companies all over the world. Still, it’s undoubtedly the case that the bulk of our code contributions come from Red Hat employees working on the middleware product teams that are moving to IBM.  However, I don’t expect this change to have a significant impact on the WildFly project, beyond the inevitable temporary disruption as the people who are moving focus some of their energy on the move.  WildFly is the upstream project for Red Hat’s JBoss Enterprise Application Platform (EAP) product. EAP will continue to be sold and supported through Red Hat, and will continue to be developed following an upstream-first development model. That model means that features and fixes for EAP will land first in WildFly’s main branch or in the main branches of the components integrated into WildFly.  IBM and Red Hat leaders have clearly stated that current and future contributions to WildFly are a key component of their middleware strategy.  So, we’ll continue to work on behalf of the WildFly community, striving to improve WildFly. Some things we’ll be doing:   * We’ll have another soon. Watch this space for more details!   * We’re hard at work on WildFly 36, with its final release expected around    April 10.   * After that, we move on to WildFly 37, which is expected in July. We intend to    continue producing feature releases quarterly, followed by a bug fix release    about a month later.   * Work continues on EE 11 support in WildFly Preview and eventually in standard    WildFly.   * We’ll continue to innovate outside of the Jakarta and MicroProfile areas,    including and .   * We’ll continue to keep up with advancements in Java SE, with an aspiration of    having each WildFly feature release run well on the latest SE release    available when it comes out, and being able to recommend the latest LTS SE    release as the preferred option as soon as possible after it comes out.  Last month, I posted about . I intend to continue with this process. Note that our interest in moving to an open source foundation was not triggered by Red Hat’s strategy change. We’d been thinking about a move to a foundation since well before we learned about the move to IBM.  Personally, I’ll be sorry to leave Red Hat, which has been a fantastic place to work. Back in 2006, I was sorry to leave JBoss, Inc for the much bigger Red Hat, too, but it worked out very well. I think combining forces with Java teams at IBM makes a lot of sense and will be good for the middleware projects and products. There’s a lot of growth and innovation potential in the middleware technologies we offer and I’m looking forward to being part of a larger team excited about and focused on that potential.  Best regards,  Brian Stansberry WildFly Project Lead"
 }