Details
Improvement Request
Resolved
Major
-
- Environment:
- -
Issue Links
| Depends | |||
|---|---|---|---|
|
|
|
||
Activity
| Field | Original Value | New Value |
|---|---|---|
| Status | New [ 10000 ] | Open [ 10002 ] |
| Priority | Major [ 3 ] | |
| Assignee | Christophe DENEUX [ cdeneux ] | Victor NOËL [ vnoel ] |
| Description |
Instead of relying on hazelcast and the embedded registry for standalone domain, we should provide a simpler lightweight in-memory implementation of the shared area.
It would used in two cases: # When a container is detached from a domain. # When a container is started with a topology configuration that contains only the said container AND is static. Note: dynamic topologies will always be used with Hazelcast (or the available default in the classpath). |
Instead of relying on hazelcast and the embedded registry for standalone domain, we should provide a simpler lightweight in-memory implementation of the shared area.
It would used in two cases: # When a container is detached from a domain. # When a container is started with a topology configuration that contains only the said container AND is static. \\ Note: dynamic topologies will always be used with Hazelcast (or the available default in the classpath). |
| Status | Open [ 10002 ] | In Progress [ 10003 ] |
| Description |
Instead of relying on hazelcast and the embedded registry for standalone domain, we should provide a simpler lightweight in-memory implementation of the shared area.
It would used in two cases: # When a container is detached from a domain. # When a container is started with a topology configuration that contains only the said container AND is static. \\ Note: dynamic topologies will always be used with Hazelcast (or the available default in the classpath). |
Instead of relying on hazelcast and the embedded registry for standalone domain, we should provide a simpler lightweight in-memory implementation of the shared area.
It would used in two cases: # When a container is detached from a domain. # When a container is started with a topology configuration that contains only the said container AND is static. \\ Note: dynamic topologies will always be used with Hazelcast (or the available default in the classpath). This also means that the embedded Registry Overlay will be started only if: * There is no shared area implementation specified in topology.xml, and * The topology is dynamic, and * There is only one container in the topology. Actually, the embedded registry overlay becomes less than needed for its current purpose (aka standalone topologies) and maybe it would make sense to: # move it to petals-esb-default-zip instead of petals-esb-minimal-zip # start using it for other things that standalone topology, for example to have multi-container topologies where some of the registry members are embedded directly within Petals... |
| Description |
Instead of relying on hazelcast and the embedded registry for standalone domain, we should provide a simpler lightweight in-memory implementation of the shared area.
It would used in two cases: # When a container is detached from a domain. # When a container is started with a topology configuration that contains only the said container AND is static. \\ Note: dynamic topologies will always be used with Hazelcast (or the available default in the classpath). This also means that the embedded Registry Overlay will be started only if: * There is no shared area implementation specified in topology.xml, and * The topology is dynamic, and * There is only one container in the topology. Actually, the embedded registry overlay becomes less than needed for its current purpose (aka standalone topologies) and maybe it would make sense to: # move it to petals-esb-default-zip instead of petals-esb-minimal-zip # start using it for other things that standalone topology, for example to have multi-container topologies where some of the registry members are embedded directly within Petals... |
Instead of relying on hazelcast and the embedded registry for standalone domain, we should provide a simpler lightweight in-memory implementation of the shared area.
It would used in two cases: # When a container is detached from a domain. # When a container is started with a topology configuration that contains only the said container AND is static. \\ Note: dynamic topologies will always be used with Hazelcast (or the available default in the classpath). This also means that the embedded Registry Overlay will be started only if: * There is no shared area implementation specified in topology.xml, and * The topology is dynamic, and * There is only one container in the topology. Actually, the embedded registry overlay becomes less than needed for its current purpose (aka standalone topologies) and maybe it would make sense to: # move it to petals-esb-default-zip instead of petals-esb-minimal-zip (see # start using it for other things that standalone topology, for example to have multi-container topologies where some of the registry members are embedded directly within Petals... |
| Link |
This issue blocks |
| Status | In Progress [ 10003 ] | Resolved [ 10004 ] |
| Fix Version/s | 5.0.2 [ 10661 ] | |
| Resolution | Fixed [ 1 ] |
| Transition | Status Change Time | Execution Times | Last Executer | Last Execution Date | |||||||||
|
|
|
|
|
|||||||||
|
|
|
|
|
|||||||||
|
|
|
|
|
The documentation should be updated once we decided on all these points: