You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A temporary option introduced to avoid a logging warning when `-Dquarkus.bootstrap.incubating-model-resolver` is added to the build command line. This option enables an incubating implementation of the Quarkus Application Model resolver. This option will be removed as soon as the incubating implementation becomes the default one.
4551
+
A temporary option introduced to avoid a logging warning when `-Dquarkus.bootstrap.legacy-model-resolver` is added to the build command line. This option enables the legacy implementation of the Quarkus Application Model resolver. This option will be removed once the legacy `ApplicationModel` resolver implementation gets removed.
A temporary option introduced to avoid a logging warning when `-Dquarkus.bootstrap.incubating-model-resolver` is added to the build command line. This option enables an incubating implementation of the Quarkus Application Model resolver. This option will be removed as soon as the incubating implementation becomes the default one.
102
+
A temporary option introduced to avoid a logging warning when `-Dquarkus.bootstrap.legacy-model-resolver` is added to the build command line. This option enables the legacy implementation of the Quarkus Application Model resolver. This option will be removed once the legacy `ApplicationModel` resolver implementation gets removed.
Copy file name to clipboardExpand all lines: _versions/main/guides/maven-tooling.adoc
+3Lines changed: 3 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1057,6 +1057,9 @@ Here is a list of system properties the Quarkus bootstrap Maven resolver checks
1057
1057
| `false`
1058
1058
| By default, the Quarkus Maven resolver is reading project's POMs directly when discovering the project's layout. While in most cases it works well enough and relatively fast, reading raw POMs has its limitation. E.g. if a POM includes modules in a profile, these modules will not be discovered. This system property enables project's layout discovery based on the effective POM models, that are properly interpolated, instead of the raw ones. The reason this option is not enabled by default is it may appear to be significantly more time-consuming that could increase, e.g. CI testing times. Until there is a better approach found that could be used by default, projects that require it should enable this option.
1059
1059
1060
+
| `quarkus.bootstrap.legacy-model-resolver`
1061
+
| `false`
1062
+
| This *system* or *POM* property can be used to enable the legacy `ApplicationModel` resolver implementation. The property was introduced in Quarkus 3.19.0 and will be removed once the legacy implementation is known to be not in demand.
1060
1063
|===
1061
1064
1062
1065
These system properties above could be added to, e.g., a `surefire` and/or `failsafe` plugin configuration as
Copy file name to clipboardExpand all lines: _versions/main/guides/messaging.adoc
-95Lines changed: 0 additions & 95 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -562,7 +562,6 @@ public class StreamProcessor {
562
562
}
563
563
----
564
564
565
-
[[execution_model]]
566
565
== Execution Model
567
566
568
567
Quarkus Messaging sits on top of the xref:quarkus-reactive-architecture.adoc#engine[reactive engine] of Quarkus and leverages link:{eclipse-vertx}[Eclipse Vert.x] to dispatch messages for processing.
@@ -635,100 +634,6 @@ Depending on the broker technology, this can be useful to increase the applicati
635
634
while still preserving the partial order of messages received in different copies.
636
635
This is the case, for example, for Kafka, where multiple consumers can consume different topic partitions.
637
636
638
-
== Context Propagation
639
-
640
-
In Quarkus Messaging, the default mechanism for propagating context between different processing stages is the
This provides a consistent way to pass context information along with the message as it flows through different stages.
643
-
644
-
=== Interaction with Mutiny and MicroProfile Context Propagation
645
-
646
-
Mutiny, which is the foundation of reactive programming in Quarkus, is integrated with the MicroProfile Context Propagation.
647
-
This integration enables automatic capturing and restoring of context across asynchronous boundaries.
648
-
To learn more about context propagation in Quarkus and Mutiny, refer to the xref:context-propagation.adoc[Context Propagation] guide.
649
-
650
-
However, Quarkus Messaging needs to coordinate multiple asynchronous boundaries.
651
-
This is why the default context propagation can result in unexpected behavior in some cases, especially using `Emitters`.
652
-
653
-
To ensure consistent behavior, Quarkus Messaging disables the propagation of any context during message dispatching, through internal channels or connectors.
654
-
This means that Emitters won't capture the caller context, and incoming channels won't dispatch messages by activating a context (ex. the request context).
655
-
656
-
For example, you might want to propagate the caller context from an incoming HTTP request to the message processing stage.
657
-
For emitters, instead of using the regular `Emitter` or `MutinyEmitter`, you can inject the `ContextualEmitter` to make sure the message captures the caller context.
658
-
This ensures consistent and predictable behaviour by relying on the message context handling provided by the framework.
659
-
660
-
For example, let `RequestScopedBean` a request-scoped bean, `ContextualEmitter` can be used to dispatch messages locally through the internal channel `app`:
0 commit comments