Published latest aggregated blog posts

src/content/posts-aggregator/1.json

@@ -1,13 +1,13 @@
 {
-  "title": "How to initialize an Array in Java in 4 simple ways",
-  "link": "http://www.mastertheboss.com/java/4-ways-to-initialize-an-array-in-java/",
+  "title": "Improvements to the GraphQL-Java integration",
+  "link": "https://vertx.io/blog/vertx-web-graphql-java-improvements",
   "author": [
     {
-      "name": "F.Marchioni",
+      "name": "Thomas Segismont",
       "avatar": null
     }
   ],
-  "date": "2023-02-15T07:17:47.000Z",
-  "feed_title": "Mastertheboss",
-  "content": "This article discusses about array initialization in Java, showing multiple ways to initialize an array, some of them you probably don’t know! How to declare an array in Java Firstly, some background. Java classifies types as primitive types, user-defined types, and array types. An array type is a region of memory that stores values in ...  The post appeared first on ."
+  "date": "2023-03-09T00:00:00.000Z",
+  "feed_title": "Vert.x",
+  "content": "Vert.x 4.4 ships several improvements to the GraphQL-Java integration."
 }

src/content/posts-aggregator/10.json

@@ -1,13 +1,13 @@
 {
-  "title": "Synchronize your KIE Sandbox workspace with Bitbucket or GitHub",
-  "link": "https://blog.kie.org/2023/02/synchronize-your-kie-sandbox-workspace-with-bitbucket-or-github.html",
+  "title": "Configuring OpenId Authorization with Keycloak",
+  "link": "http://www.mastertheboss.com/keycloak/configuring-openid-authorization-with-keycloak/",
   "author": [
     {
-      "name": "Jan Stastny",
+      "name": "F.Marchioni",
       "avatar": null
     }
   ],
-  "date": "2023-02-08T18:31:37.000Z",
-  "feed_title": "KIE Community",
-  "content": "1 INTRODUCTION   KIE Sandbox now brings the possibility to synchronize your changes not only with GitHub, but also Bitbucket.   > Bitbucket has several variants of their offering. Only support for Bitbucket > Cloud is available, namely bitbucket.org – a publicly hosted instance. Other > Bitbucket variants, being it Bitbucket Server or Bitbucket Data Center are not > supported, due to significant differences in provided APIs.  Support for enterprise instances of Bitbucket Cloud will arrive in future.    2 CONNECTING TO AN ACCOUNT   AUTHORIZATION   For KIE Sandbox to be able to communicate with a given git instance, it needs to be provided a way to authenticate with. In the case of Bitbucket, the supported way is to use a so-called App password, in the case of GitHub, its name is Personal Access Token. They are long-lasting OAuth2 tokens with selected scopes that enable the actions in KIE Sandbox when working with our workspace.   List of related OAuth2 scopes:   --------------------------------------------------------------------------------  Bitbucket scopeDescriptionFor the initial authentication and user details retrieval (e.g., uuid of the user)  Read access to repositories of given user.Write access to all the repositories the authorizing user has access to. To create repositories Read access to all the snippets the authorizing user has access to.  Write access to all the snippets the authorizing user can edit  Required Bitbucket OAuth2 scopes ()    --------------------------------------------------------------------------------  GitHub scopeDescription(no-scope)Implicit read access to public repositories and Gists. repoFull access to public and private repositories.gistGrants write access to Gists.   Required GitHub OAuth2 scopes ()  --------------------------------------------------------------------------------  KIE SANDBOX CONNECTED ACCOUNTS   Once we have a token, we need to configure the KIE Sandbox to make it available in there.    You can configure the authentication in advance by visiting the Connected Accounts section in the top panel. KIE Sandbox serves as a modal where the user needs to specify required values. In the case of Bitbucket, it is a username and the app password OAuth2 token. This is a difference compared to GitHub, where the token itself carries the user information and is sufficient for authentication on its own.     After the addition, you should see the account information together with usage statistics in your current instance of KIE Sandbox.    Once you connect the account, it’s available in your workspaces through the Authentication source section in the Share dropdown. Where you can also connect to another account by using the respective link from the dropdown, which serves as a shortcut to the Connected Accounts section mentioned earlier.      3 COLLABORATION IS KEY (KIE)   It’s always better to share. And with KIE Sandbox sharing is as easy as a single click to synchronize your changes with the remote location.   > KIE Sandbox does not aspire at replacing the interaction with the existing git > tools or git vendor UI, rather it simplifies most common operations vital for > the smooth experience when modelling your assets.   COLLABORATE OVER AN EXISTING REPOSITORY   The ability to import projects and later synchronize your local changes back into the original location makes KIE Sandbox collaborative experience a breeze.     IMPORT FROM URL   It all starts with a URL. You can import existing projects on KIE Sandbox main screen by pasting their respective URL into the From URL widget. Once it’s confirmed as supported, the widget itself queries git-related information to be used and presents it to the user allowing to override the identified defaults, e.g., to change a branch to be checked out (click Change… if you want to do so).     After the project is imported, you’re taken into its workspace which is readily configured with the respective Authentication source, so you’re ready to Push or Pull without any further action.   SUPPORTED IMPORT URL OPTIONS   HostnameURL Contextbitbucket.org /:workspace/:repo   /:workspace/:repo/src/:tree   /:workspace/:repo/src/:tree/:path  /:workspace/workspace/snippets/:snippet_id/:snippet_name  /:workspace/workspace/snippets/:snippet_id/:snippet_name#file-:path  /snippets/:workspace/:snippet_id/:snippet_name.git github.com /:org/:repo  /:org/:repo/tree/:tree  /:org/:repo/tree/:tree/:path* raw.githubusercontent.com/:org/:repo/:tree/:path* gist.github.com or gist.githubusercontent.com /:user/:gistId/  /:user/:gistId/raw/:fileId/:fileName  /:gistId   SHARING LOCAL PROJECTS WITH THE WORLD   Having created a complex project including several models, now you wonder how to get those to your colleagues? No need to download and send by email, just create a brand-new git repository based on your workspace contents. By picking a different Authentication source, you can select between all your connected git vendor accounts.   PICK AN AUTHENTICATION SOURCE   The first step is to decide which Authentication source we’d like to use to share our workspace. Choice defines the actions allowed with the workspace further on.   Editor toolbar reflects this decision in its Share dropdown, where only actions applicable to your setup are available upon Authentication source selection.         Once you pick any of these options, your project is transformed into git-based workspace. Though there are some differences in how you can synchronize the contents, see them described below.   CREATE A GIT REPOSITORY   Create a repository by clicking on the respective button provided in the Share dropdown. Afterwards a modal appears where you can specify an intended location, repository name, and its visibility.   Location must be specified using a dynamically populated select field. The list of options is possible to be reload using the sync icon to its right.       In the case of GitHub, we can choose between creating the repository under our user location and creating in a GitHub organization that we are members of.       In the case of Bitbucket we select from either personal or shared workspaces.    The repository name text field is populated with the value matching your workspace name, so if you’ve configured your workspace thoroughly, you should be all set. Though you are free to specify the name that suits your needs, with just a few limitations on the characters allowed guarded by validation.    The Public and Private checkboxes define the repository visibility.   After the repository is created, you’re taken back into workspace, which is readily configured with the respective Authentication source, so you’re ready to Push or Pull without any further action.   CREATE A BITBUCKET SNIPPET OR GITHUB GIST   Do you hesitate to create a separate repository for something you were just doodling? Then share it just as a Bitbucket Snippet or GitHub Gist. Both these options provide you with the ability to push or pull changes, share by URL, etc.   After clicking the respective button, a new Modal dialog is displayed.    We must specify    * a location under which the item will be created.    * In the case of GitHub Gist, the only option is the user account itself, it is    not supported by GitHub to create a Gist in an organization. The select field    is thus displayed as disabled.   * On the other hand, Bitbucket allows us to create Snippets generally in any    workspace, as long as we have necessary permissions.    * Visibility of the item being created.   After confirming the dialog, the modal stays displayed until the operation is completed. After that notification alert with the newly created item is displayed.    When the creation succeeds, you’re taken back into the workspace, which is now configured accordingly.   In comparison to the regular git repository Sync options above, you now have just a single operation listed there – update.   This action allows you to promote the changes back into the original location.     There is no choice to pull, i.e., update your workspace based on changes done either in Gist or Snippet. If you need a more flexible approach, let’s head for the following section.   TURN GIST OR SNIPPET INTO A REGULAR GIT REPOSITORY   Working with a Snippet or Gist and you’re finally satisfied with the models? Or do you want a more flexible workflow requiring updating your workspace with remote changes?   Turn your project into a regular git repository – the Share dropdown option is still there for Gist or Snippet–based workspaces. You’re not even limited to the same Authentication source here, e.g., for a GitHub Gist based workspace, you can easily share it as a Bitbucket repository afterwards, given that you have both accounts connected.      SUMMARY    * ✅We’ve seen how users can integrate KIE Sandbox into their git-based    workflow.   * 💥KIE Sandbox now supports GitHub and Bitbucket Cloud.   * 💥Toolbar buttons now reflect the currently selected Authentication    provider.   * 💥GitHub Repositories can also be created in GitHub organizations.   The post appeared first on ."
+  "date": "2023-03-01T16:50:13.000Z",
+  "feed_title": "Mastertheboss",
+  "content": "OpenID Connect is a widely-used authentication protocol that allows users to authenticate themselves to a relying party (RP) website or application using their existing credentials from an identity provider (IDP). While OpenID Connect is primarily an authentication protocol, it also provides some support for authorization through the use of client resources and policies. In this ...  The post appeared first on ."
 }

src/content/posts-aggregator/11.json

@@ -1,13 +1,14 @@
 {
-  "title": "CloudEvents labeling and classification with Drools",
-  "link": "https://blog.kie.org/2023/02/cloudevents-labeling-and-classification-with-drools.html",
+  "title": "Keycloak 21.0.1 released",
+  "link": "https://www.keycloak.org/2023/03/keycloak-2101-released",
   "author": [
     {
-      "name": "Matteo Mortari",
+      "name": null,
       "avatar": null
     }
   ],
-  "date": "2023-02-08T15:40:00.000Z",
-  "feed_title": "KIE Community",
-  "content": "This blog post is a quick update on a demo in labeling CNCF’s CloudEvents.   INTRODUCTION  Categorizing events is a general, common use-case; in the context of this post, we will delve into labeling CNCF’s CloudEvents for Intelligent Response Management (IRM) which can find application in several ways.  One way is to categorize and prioritize different types of events based on their urgency or importance; for example: a SRE team might label an event as \"critical\" if it involves a major service outage, or \"low priority\" if it is a minor issue of a sub-system that can be resolved at a later time. This allows the team to quickly respond to the most pressing issues and allocate resources accordingly.  Additionally, labeling events can also be used to track and analyze patterns in a system (or cluster) behaviors, which can help to identify potential problems before they occur and improve the overall reliability of the system by implementing corrective actions preventively.  This demo make use of several technologies:   * and YaRD for the rule definition and evaluation  * for cloud native based decisioning  * for cloud native Java development on top of Kubernetes  * –this is the format of the event data that we want to process  * Kafka as an event broker  * PostgreSQL as our data store; we’re using specifically PostgreSQL for very    interesting query capabilities that this RDBMS can offer  * to define our custom types on top of PostgreSQL  * extension  * for the web-based GUI   ARCHITECTURE  The following is a high level diagram of the overall architecture for this demo:  On the left hand side, the incoming CloudEvents instance that we want to process by labeling, is received by the endpoint which represents one of the possible inputs for this application. The CloudEvents instance is then immediately placed on a kafka topic, which is used to better isolate the ingress portion of this application from the rest of the processing pipeline.  The processing pipeline starts with a labeling processor: this is the component responsible for applying the rules to enrich the CloudEvents instance with the required and applicable labels. As a result, the received message is now enriched with labeling and it gets persisted inside the data store.  PostgreSQL is used specifically here as it provides hierarchical labels via ltree data type and related query capabilities, which are very useful in categorization applications such as this one. These advanced query capabilities are also foundational to potentially re-process the same CloudEvents instance, after some further augmentation or additional manual labeling.  In the context of this article, the web-based GUI is provisional and will be used only as a practical demonstrator for the rich query capabilities.   WALKTHROUGH  A CloudEvents instance is submitted to this application, for example:  {   \"specversion\": \"1.0\",   \"id\": \"matteo-8eb9-43b2-9313-22133f2c747a\",   \"source\": \"example\",   \"type\": \"demo20220715contextlabel.demotype\",   \"data\": {     \"host\": \"basedidati.milano.local\",     \"diskPerc\": 70,     \"memPerc\": 50,     \"cpuPerc\": 20   } }  The data context of the CloudEvents instance pertains to some host which came under supervision due to resource load. We now want to classify this context/case, using some labels. We may have more than one label. Each label is hierarchical (root.branch1.branch2.leaf).  We want to classify the hostname based on its relevance to the department, unit, person or team responsible for it. To do so, a simple decision table provides an easy solution. For example, we can classify the hostname based on geographical location or determine the type of server based on the hostname. Ultimately, we might want to setup a labeling rule for who’s on call, something like the following decision table using :     type: DecisionTable     inputs: ['.location', '.type']     rules:     - when: ['startswith(\"location.emea\")', '. == \"type.db\"']       then: '\"oncall.EMEA.dbadm\"'     - when: ['startswith(\"location.emea\") | not', '. == \"type.db\"']       then: '\"oncall.CORP.dbadm\"'     - when: ['true', '. == \"type.nas\"']       then: '\"oncall.CORP.it\"'  For example, a CloudEvents context may be labeled as follows:   * type.db  * location.emea.italy.milan  * oncall.EMEA.dbadm  For the PostgreSQL DDL we currently have:                        Table \"public.cecase\"  Column  |          Type          | Collation | Nullable | Default  ---------+------------------------+-----------+----------+---------  id      | bigint                 |           | not null |   ceuuid  | character varying(255) |           |          |   context | jsonb                  |           |          |   mytag   | ltree[]                |           |          |  Indexes:     \"cecase_pkey\" PRIMARY KEY, btree (id)     \"mytag_gist_idx\" gist (mytag)     \"mytag_idx\" btree (mytag)  Please notice we’re taking advantage here of PostgreSQL’s jsonb for storing the original CloudEvents context, and ltree[] data type for searching ad-hoc with indexing the hierarchical labels.  The latter is extremely helpful also to setup queries making use of and ~ operators for PostgreSQL which performs on the ltree data type, showcased below.  As the data flows into the application, we can use the provisional web-based GUI which provide a convenient way to consume the backend REST API(s) developed on Quarkus:  In the screenshot above, you can access all the records from the table, where the labels have been applied by the rule definition.  We can browse by having at least one label having the specified parent, with a query like:  SELECT * FROM cecase WHERE mytag <@ 'oncall.CORP'  For example, if we want all the records having at least a label for the oncall.CORP rooting:  We can browse by having at least one label having the specified ltree, with a query like”  SELECT * FROM cecase WHERE mytag ~ *.emea.*  For example, if we want all the records having at least a label for the .emea. (a branch named emea in any point in the hierarchical label):  Don’t forget to check out the video linked above, as it demonstrates the demo working live as the data is being sent to the application!  If you want to checkout the source, here is the code repo:    These advanced query capabilities offered by PostgreSQL can be used as a foundation to identify events due to reprocessing, manual inspection, triggering a workflow, etc. …but that is maybe subject for a second iteration on this demo…   CONCLUSIONS  This demo showcases the power of combining declarative logic, persistence and other technologies to process and label CloudEvents effectively! We defined our logic using a combination of expression and rules in the form of decision tables, combined with the use of PostgreSQL as a data store thanks to its advanced query capabilities, allowing for a more efficient and effective handling of the events.  We hope you enjoyed our demo and look forward to hearing your feedback!  The post appeared first on ."
+  "date": "2023-03-01T00:00:00.000Z",
+  "feed_title": "Keycloak Blog",
+  "feed_avatar": "https://www.gravatar.com/avatar/87fe00619f08c241da8dfb23d907ffa2?s=50",
+  "content": "To download the release go to .   MIGRATION FROM 20.0  Before you upgrade remember to backup your database. If you are not on the previous release refer to for a complete list of migration changes.   ALL RESOLVED ISSUES   BUGS   * Duplicated set-cookie headers sent causing issues with proxies keycloak    authentication  * MigrateT021_0_0 fails with NPE if adminTheme is not configured explictly    keycloak core  * When upgrading from v20.0.2 to v21.0.0 I get a NPE on Theme keycloak core   UPGRADING  Before you upgrade remember to backup your database and check the for anything that may have changed."
 }