Skip to content

Commit

Permalink
Feedback updates
Browse files Browse the repository at this point in the history
  • Loading branch information
JamesHazelcast committed Feb 6, 2025
1 parent 1049807 commit 4c40783
Showing 1 changed file with 4 additions and 4 deletions.
8 changes: 4 additions & 4 deletions docs/modules/clusters/pages/ucn-migrate-ucd.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -10,8 +10,8 @@ To migrate your existing {ucd}, enable {ucn} and complete the configuration as d
There are several differences between {ucd} and {ucn} that you must account for when migrating:

* {ucn} does not have any configuration elements for Hazelcast Clients: all static configuration is managed in member configurations.
This means that resources deployed statically need to be referenceable by all members of the cluster. See xref:clusters:ucn-member-side.adoc[] for more information.
* Resources deployed with {ucd} are added to the member classpath, however {ucn} introduces namespaces, which allows resources to be separated. This separation allows conflicting classes to exist in separate namespaces without issue. However, data structures will need to reference the correct namespace to access the relevant resources. If you want to achieve similar behaviour to {ucd} in {ucn}, configure your resources in the `default` namespace, which means they will be available to all data structures that do not explicitly define a namespace.
* {ucn} does not support loading resources from the classpath and they should be defined from static locations instead. Resources, including classpath classes, can still be uploaded by clients to the cluster, but this will need to be done through the programmatic API. See xref:clusters:ucn-dynamic-client.adoc[] for more information.
This means that resources deployed statically need to be referenceable by all members of the cluster. For more information, see xref:clusters:ucn-member-side.adoc[].
* Resources deployed with {ucd} are added to the member classpath. In contrast, {ucn} introduces namespaces, which allows resources to be separated. This separation allows conflicting classes to exist in separate namespaces without issue. However, data structures will need to reference the correct namespace to access the relevant resources. If you want to achieve similar behaviour to {ucd} in {ucn}, configure your resources in the `default` namespace, which means they will be available to all data structures that do not explicitly define a namespace.
* {ucn} does not support loading resources from the classpath and they should be defined from static locations instead. Resources, including classpath classes, can still be uploaded by clients to the cluster, but you will need to do this using the programmatic API. For more information, see xref:clusters:ucn-dynamic-client.adoc[].
* Resources in {ucn} can be dynamically added or replaced at runtime. This provides various benefits, but you must ensure that
resources are not removed from actively running operations, as this could cause errors. See xref:clusters:ucn-dynamic-config.adoc[] for more information.
resources are not removed from actively running operations, as this could cause errors. For more information, see xref:clusters:ucn-dynamic-config.adoc[].

0 comments on commit 4c40783

Please sign in to comment.