You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Vladimir Steshin (Jira)" <ji...@apache.org> on 2026/06/11 08:47:00 UTC

[jira] [Updated] (IGNITE-28766) Move Message to module 'commons'.

     [ https://issues.apache.org/jira/browse/IGNITE-28766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vladimir Steshin updated IGNITE-28766:
--------------------------------------
    Summary: Move Message to module 'commons'.  (was: Move Message to module 'commos'.)

> Move Message to module 'commons'.
> ---------------------------------
>
>                 Key: IGNITE-28766
>                 URL: https://issues.apache.org/jira/browse/IGNITE-28766
>             Project: Ignite
>          Issue Type: Sub-task
>            Reporter: Vladimir Steshin
>            Priority: Major
>
> {*}Suggestions{*}:
>  # Let's move `{_}Message{_}` to module `{_}commons{_}`.
>  # Optionally, let's rename its package (public API).
>  
> {*}Motivations{*}:
> Ignite nodes conversation relies on the interface `{_}Message{_}`. Both `{_}Discovery{_}` and `{_}Communication{_}` depend on it. But its package is still `{_}org.apache.ignite.plugin.extensions.communication{_}`. This is incorrect. `{_}Message{_}` is not a plugin or an extension. It is part of the core functionality. And it relates also to `{_}Discovery{_}`. +We should move it to package+ like `{_}org.apache.ignite.messaging{_}`.  
>  
> But the *main problem* is that `{_}Message{_}` resides in module `{_}core{_}`. That hinders using additional messages in plugins, extensions if they don't depend on module `{_}core{_}`.
>  
> {+}Example{+}:
> `{_}Message{_}` is required for `{_}OperationContext{_}` propagation (#IGNITE-28723). As we discussed with [~mpetrov] , {_}Context{_}'s attributes have to be a `{_}Message{_}`. This expects `{_}Message{_}` be in module `{_}commons{_}`, not in `{_}core{_}`.
>  
> {+}Another example{+}:
> `{_}MetadataUpdateProposedMessage{_}` should not be `{_}MarshallableMessage{_}`. One of its field is a `{_}BinaryMetadata{_}`. It could be `{_}Message{_}` too. Just like `{_}BinaryFieldMetadata{_}` and `{_}BinarySchema{_}`. Then, we could just declare:
> {code:java}
> @Order(1)
> BinaryMetadata metadata; {code}
> in `{_}MetadataUpdateProposedMessage`{_} and do not
> {code:java}
> MetadataUpdateProposedMessage implements MarshallableMessage {code}
> But {_}`BinaryMetadata`{_}, `{_}BinaryFieldMetadata`{_} and `{_}BinarySchema`{_} are in module `{_}binary`{_}. It has dependency of module `{_}commons{_}`, but has no dependency of module `{_}core{_}`. So, {_}`BinaryMetadata{_}`, `{_}BinaryFieldMetadata`{_} and `{_}BinarySchema`{_} cannot implement `{_}Message`{_}.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)