feat: JDK 17+ persistence APIs #32420
Conversation
| * Behavior | ||
| * For Java versions before 17, see [[EventSourcedBehavior]] | ||
| */ | ||
| abstract class EventSourcedOnCommandBehavior[Command, Event, State]( |
There was a problem hiding this comment.
do we need one for EventSourcedBehaviorWithEnforcedReplies too?
There was a problem hiding this comment.
Yep, soon in a new push.
| * | ||
| * Use [[EventSourcedBehavior#newSignalHandlerBuilder]] to define the signal handler. | ||
| */ | ||
| protected def signalHandler(): SignalHandler[State] = SignalHandler.empty[State] |
There was a problem hiding this comment.
Should this be onSignal without the SignalHandler?
There was a problem hiding this comment.
I think the signal handler is more like a partial function, so might be nicer with a builder kind of thing still, rather than have to catch-all-behavior-unhandled
| case EmptyEventsListAndThenLog emptyEventsListAndThenLog -> emptyEventsListAndThenLog(state, emptyEventsListAndThenLog); | ||
| case StopThenLog stopThenLog -> stopThenLog(state, stopThenLog); | ||
| case IncrementTwiceAndLog incrementTwiceAndLog -> incrementTwiceAndLog(state, incrementTwiceAndLog); | ||
| }; |
|
Not sure if we maybe need one of each for the WithEnforcedReplies as well, maybe good enough with these? |
johanandren
force-pushed
the
wip-jdk21-persistence
branch
from
2ea05dc
to
5360000
Compare
|
I put the examples under the respective "Style Guide", not entirely happy with that but better than nothing. Didn't showcase the replicated API anywhere yet. |
johanandren
changed the title
|
I believe replication with akka-projection-grpc will just work (tm) since the API there expect a |
|
Ready for final review |
Um, some people (read @octonato ) think that is very important, or at least that was the opinion when we introduced it. |
| @@ -14,6 +14,8 @@ import akka.persistence.typed.internal.ReplicationContextImpl | |||
|
|
|||
| /** | |||
| * Base class for replicated event sourced behaviors. | |||
| * | |||
| * For projects using Java 17 and newer, also see [[EventSourcedOnCommandBehavior]] | |||
There was a problem hiding this comment.
ReplicatedEventSourcedOnCommandBehavior
|
|
||
| ## Leveraging Java 21 features | ||
|
|
||
| When building durable state entities in a project using Java 21 or newer, the @javadoc[DurableStateOnCommandBehavior](akka.persistence.typed.statejavadsl.DurableStateOnCommandBehavior) |
There was a problem hiding this comment.
The whole naming with OnCommand is pretty weird, but I don't have any other suggestion than following the track of OnMessage
There was a problem hiding this comment.
The reason I went with that is that there never is an onMessage method here, what you define is onCommand and onEvent. The choice is if we are inconsistent with this API itself, or with another class further away.
There was a problem hiding this comment.
I mean that the OnMessage naming is not great to begin with, but I see no other option than continue and here the corresponding would be OnCommand as you have done.
| * @param allReplicasAndQueryPlugins All replica ids and a query plugin per replica id. These need to be known to receive events from all replicas | ||
| * and configured with the query plugin for the journal that each replica uses. | ||
| */ | ||
| def onCommandPerReplicaJournalConfig[Command, Event, State]( |
There was a problem hiding this comment.
Mouthful, but could be good with same prefix:
perReplicaJournalConfigForEventSourcedOnCommandBehavior
similar with commonJournalConfig
Allright, I better add an |
No description provided.