Merge pull request #151 from akka/wip-merge-main-13b69e0

Merge main to java-spi

Makefile

@@ -44,7 +44,7 @@ attributes: prepare
 		> "${managed_partials}/attributes.adoc"
 	docs/bin/version.sh | xargs -0  printf ":akka-javasdk-version: %s" \
 		> "${managed_partials}/attributes.adoc"
-	echo ":akka-cli-version: 3.0.8"     >> "${managed_partials}/attributes.adoc"
+	echo ":akka-cli-version: 3.0.9"     >> "${managed_partials}/attributes.adoc"
 	echo ":akka-cli-min-version: 3.0.4" >> "${managed_partials}/attributes.adoc"
 	# see https://adoptium.net/marketplace/
 	echo ":java-version: 21" \

docs/src/modules/ROOT/pages/index.adoc

@@ -34,7 +34,7 @@ Developers can access a local console that replicates runtime observability, tra
 
 == DevOps Operations
 Operators can configure application elasticity without deep architectural knowledge. Akka automates instance management to meet traffic needs while preserving performance SLAs. Services can be replicated across multiple regions, spanning different geographies and environments.
-Stateful services can be read-replicated or write-replicated (Q1 2025) with conflict resolution options. Services can migrate between locations without downtime and can be restarted from specific points in time.
+Stateful services can be read-replicated or write-replicated with conflict resolution options. Services can migrate between locations without downtime and can be restarted from specific points in time.
 Developers have access to a component library for creating various application types, including transactional, durable, Artificial Intelligence (AI) Retrieval-Augmented Generation (RAG), analytics, edge, event-sourced, and streaming applications.
 
 == Key Components

docs/src/modules/concepts/pages/declarative-effects.adoc

@@ -1,5 +1,5 @@
 [#_declarative_effects]
-= Declarative Effects
+= Declarative effects
 
 Effects are declarative APIs that describes the actions the Akka runtime needs to perform. It is inherently lazy, acting as a blueprint of operations to be executed. Once passed to the Akka runtime, the Effect is executed, resulting in the requested system changes. Effect APIs are essential for implementing components, bridging your application logic with the Akka runtime.
 

docs/src/modules/concepts/pages/development-process.adoc

@@ -53,7 +53,7 @@ Services can interact asynchronously with other services and with external syste
 
 === Workflows
 
-Akka Workflows are high-level descriptions to easily align business requirements with their implementation in code. Orchestration across multiple services with support for failure scenarios and compensating actions is simple with xref:java:workflows.adoc[Workflows].
+Akka Workflows are high-level descriptions to easily align business requirements with their implementation in code. Orchestration across multiple services including failure scenarios and compensating actions is simple with xref:java:workflows.adoc[Workflows].
 
 === Views
 

docs/src/modules/concepts/pages/multi-region.adoc

@@ -1,21 +1,24 @@
-= Multi-region support
+= Multi-region operations
 
 include::ROOT:partial$include.adoc[]
 
-Akka's opinionated approach to domain modelling allow for applications to run in multiple regions without modification. An Akka application written as a single region application can be turned into a multi-region application with nothing more than a change in deployment configuration.
+Akka applications run in multiple regions with their data transparently and continuously replicated even across multiple cloud providers.
+Akka applications do not require code modifications to run within multiple regions. Operators define controls to determine which regions
+an application will operate within and whether that application's data is pinned to one region or replicated across many.
 
-The multi-region use cases that Akka's multi-region support encompasses include:
+Akka ensures regardless of which region receives a request, the request can be serviced. Multiple replication strategies can be configured, with each offering varying features for different use cases.
 
+Multi-region operations are ideal for:
+
+* Applications that require 99.9999% availability
 * Geographic failover
 * Geo-homing of data for low latency access
 * Low latency global reads
-* Low latency global writes (coming soon)
-
-Akka ensures that no matter which region receives a request, the request can be serviced. Multiple replication strategies can be configured, with each offering varying features for different use cases.
+* Low latency global writes
 
 == Examples
 
-The two main replication strategies that Akka offers are replicated reads, and replicated writes (coming soon).
+The two main replication strategies that Akka offers are replicated reads, and replicated writes.
 
 === Replicated reads
 
@@ -47,6 +50,6 @@ image:geo-d.svg[Geo data replication, width=600]
 
 When Bob travels to the USA, read requests that Bob makes on his data are handled locally, while write requests are forwarded to the UK. Meanwhile, write requests made by Alice on her data is all handled locally, with writes being replicated to the UK.
 
-=== Replicated writes (coming soon)
+=== Replicated writes
 
 The replicated write replication strategy allows every region to be capable of handling writes for all entities. This is done through the use of CRDTs, which can be modified concurrently in different regions, and their changes safely merged without conflict.

docs/src/modules/concepts/pages/state-model.adoc

@@ -6,7 +6,7 @@ Entities are used to store the data defined in the xref:concepts:architecture-mo
 
 Entities have operations that can change their state. These operations are triggered asynchronously and implemented via methods that return xref:concepts:declarative-effects.adoc[`Effect`]. Operations allow entities to be dynamic and reflect the most up-to-date information and this all gets wired together for you.
 
-Akka supports two state models: _Event Sourced Entity_ and _Key Value Entity_. Event Sourced Entities build their state incrementally by storing each update as an event, while Key Value Entities store their entire state as a single entry in a Key/Value store. To replicate state across clusters and regions, Akka uses specific conflict resolution strategies for each state model.
+Akka offers two state models: _Event Sourced Entity_ and _Key Value Entity_. Event Sourced Entities build their state incrementally by storing each update as an event, while Key Value Entities store their entire state as a single entry in a Key/Value store. To replicate state across clusters and regions, Akka uses specific conflict resolution strategies for each state model.
 
 NOTE: Although Key Value Entities are planned to support a Last Writer Wins (LWW) mechanism, this feature is not yet available.
 

docs/src/modules/java/pages/access-control.adoc

@@ -7,11 +7,13 @@ specify lists of what can access your services, at multiple granularity. For exa
 initiates a payment on a payment service to only accept requests from the shopping cart service. You can also control
 whether services or methods can be invoked from the Internet.
 
+For a conceptual introduction, see xref:security:acls.adoc[] in the **Security** section.
+
 ==  Principals
 
 A principal in Akka is an abstract concept that represents anything that can make or be the source of a request.
 Principals that are currently supported by Akka include other services, and the internet. Services are identified
-by the service name chosen when deployed. Akka uses mTLS support to associate requests with one or more principals.
+by the service name chosen when deployed. Akka uses mutual TLS (mTLS) to associate requests with one or more principals.
 
 Note that requests that have the internet principal are requests that Akka has identified as coming through the Akka
 ingress route. This is identified by mTLS, however it does not imply that mTLS has been
@@ -117,9 +119,12 @@ can be overwritten on a per method base.
 
 == Backoffice and self invocations
 
-Invocations of methods from the same service, or from the backoffice using the `akka services proxy` command, are always
+Invocations of methods from the same service, or from via the backoffice proxy that is available to developers, are always
 permitted, regardless of what ACLs are defined on them.
 
+TIP: The `akka service proxy` command creates an HTTP proxy that forwards all
+traffic to a service. This allows you to interact with the service as if it was running locally.
+
 == Local development with ACLs
 
 When testing or running in development, by default, all calls to your service will be blocked as ACLs are enabled by default.

docs/src/modules/java/pages/auth-with-jwts.adoc

@@ -101,7 +101,7 @@ include::example$endpoint-jwt/src/main/java/hellojwt/api/HelloJwtEndpoint.java[t
 <2> Note that while calling `Optional#get()` is generally a bad practice, here we know the claims must be present given the `@JWT` configuration.
 
 
-== Running locally with JWT support
+== Running locally with JWTs enabled
 
 When running locally, by default, a dev key with id `dev` is configured for use. This key uses the JWT `none` signing algorithm, which means the signature of the received JWT tokens is not validated. Therefore, when calling an endpoint with a bearer token, only the presence and values of the claims are validated.
 

docs/src/modules/java/pages/author-your-first-service.adoc

@@ -22,9 +22,22 @@ include::ROOT:partial$local-dev-prerequisites.adoc[]
 
 The Maven archetype template prompts you to specify the project's group ID, name and version interactively. Run it using the commands shown for your operating system.
 
-[sidebar]
-In IntelliJ, you can skip the command line. Open the IDE, select
-*File > New > Project*, and click to activate *Create from archetype*. Use the UI to locate the archetype and fill in the blanks.
+****
+If you are using IntelliJ, you can skip the command line entirely. Simply open the IDE and follow these steps:
+
+. Go to *File > New > Project*.
+. Select *Maven Archetype* from the list of Generators.
+. Fill out the project details:
+  * *Name*: Enter the desired project name, such as `helloworld`.
+  * *Location*: Specify the directory where you want the project to be created.
+  * *JDK*: Select Java {java-version} or a later version.
+. Under *Catalog*, ensure "Maven Central" is selected.
+. In the *Archetype* section, click the dropdown and select `io.akka:akka-javasdk-archetype`.
+. Set the *Version* to `{akka-javasdk-version}`.
+. Click *Create*.
+
+IntelliJ will handle the project generation and setup for you, allowing you to begin development immediately.
+****
 
 Follow these steps to generate and build your project:
 
@@ -190,7 +203,7 @@ Restart the service and curl this command:
 
 [source, command line]
 ----
-curl localhost:9000/hello/hello/Bob/30
+curl localhost:9000/hello/hello-response/Bob/30
 ----
 
 == Explore the local console

docs/src/modules/java/pages/http-endpoints.adoc

@@ -248,13 +248,18 @@ include::example$doc-snippets/src/main/java/com/example/api/ExampleEndpoint.java
 
 === Accessing request headers ===
 
- Accessing request headers is done through the link:_attachments/api/akka/javasdk/http/RequestContext.html[RequestContext] methods `requestHeader(String headerName)` and `allRequestHeaders()`.
+Accessing request headers is done through the link:_attachments/api/akka/javasdk/http/RequestContext.html[RequestContext] methods `requestHeader(String headerName)` and `allRequestHeaders()`.
 
- By letting the endpoint extend link:_attachments/api/akka/javasdk/http/AbstractHttpEndpoint.html[AbstractHttpEndpoint] request context is available through the method `requestContext()`.
+By letting the endpoint extend link:_attachments/api/akka/javasdk/http/AbstractHttpEndpoint.html[AbstractHttpEndpoint] request context is available through the method `requestContext()`.
 
- [source,java]
- .{sample-base-url}/doc-snippets/src/main/java/com/example/api/ExampleEndpoint.java[ExampleEndpoint.java]
- ----
- include::example$doc-snippets/src/main/java/com/example/api/ExampleEndpoint.java[tag=header-access]
- ----
- <1> `requestHeader(headerName)` returns an `Optional` which is empty if the header was not present.
+[source,java]
+.{sample-base-url}/doc-snippets/src/main/java/com/example/api/ExampleEndpoint.java[ExampleEndpoint.java]
+----
+include::example$doc-snippets/src/main/java/com/example/api/ExampleEndpoint.java[tag=header-access]
+----
+<1> `requestHeader(headerName)` returns an `Optional` which is empty if the header was not present.
+
+== See also
+
+- xref:java:access-control.adoc[]
+- xref:security:tls-certificates.adoc[]

docs/src/modules/operations/pages/projects/manage-project-access.adoc

@@ -12,7 +12,7 @@ Access to projects is controlled by assigning specific roles to users. The avail
 |View services                     |✅     |✅        |✅     |❌
 |Deploy services                   |✅     |✅        |❌     |❌
 |Update services                   |✅     |✅        |❌     |❌
-|Delete services                   |✅     |❌        |❌     |❌
+|Delete services                   |✅     |✅        |❌     |❌
 |View routes                       |✅     |✅        |✅     |❌
 |Manage routes                     |✅     |✅        |❌     |❌
 |View secrets                      |✅     |✅        |✅     |❌

docs/src/modules/reference/pages/release-notes.adoc

@@ -10,6 +10,16 @@ Current versions
 * Akka CLI {akka-cli-version}
 * A glance of all Akka libraries and their current versions is presented at https://doc.akka.io/libraries/akka-dependencies/current[Akka library versions].
 
+== January 2025
+
+* Akka CLI 3.0.9
+    - Fixes listing of user role bindings
+
+* Platform update 2025-01-13
+    - updates to internal libraries for security fixes
+    - switch of internal framework to apply environment configuration
+    - minor updates to the Console
+
 == December 2024
 
 * Akka CLI 3.0.8

docs/src/modules/security/pages/acls.adoc

@@ -1,4 +1,4 @@
-= Access Control Lists (ACLs)
+= Access Control List concepts
 
 include::ROOT:partial$include.adoc[]