[
https://issues.apache.org/jira/browse/IGNITE-28766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-28766:
--------------------------------------
Description:
{*}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 and other modules
if they don't depend on module `{_}core{_}`.
{+}Example{+}:
`{_}Message{_}` is required for `{_}OperationContext{_}` propagation
(#IGNITE-28723). As we discussed with [~mpetrov] , _Context_ _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`{_}.
was:
{*}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 and other modules
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`{_}.
> 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
> and other modules if they don't depend on module `{_}core{_}`.
>
> {+}Example{+}:
> `{_}Message{_}` is required for `{_}OperationContext{_}` propagation
> (#IGNITE-28723). As we discussed with [~mpetrov] , _Context_ _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)
