Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Let's use Cache as an example; Cache is located in geode-core, which is loaded as a module, as shown above, and is inaccessible from the system ClassLoader. In order to access classes from modules, they must implement an interface that is accessible from the system ClassLoader, so they can be service-loaded. While Cache is an interface, it requires several other classes from geode-core making it difficult to decouple and move to a separate sub-project. This is the case for more components than just Cache and impacts more modules that than just geode-core. Without an external interface to use to load the implementation from the relevant module, we have no way of creating or managing components.

...

The ComponentManagementService should be responsible for holding on to instances of the components it creates so they can later be accessed or destroyed by name.

Use Cases

Scenario 1: A ComponentManagementService is asked if it can create a certain type of component (Cache, Region, etc.). The ComponentManagementService can create the given type.

Expected Behavior: The ComponentManagementService sees that the type name matches the type it creates and returns true.


Scenario 2: A ComponentManagementService is asked if it can create a certain type of component (Cache, Region, etc.). The ComponentManagementService can not create the given type.

Expected Behavior: The ComponentManagementService sees that the type name does not match the type it creates and returns false.


Scenario 3: A ComponentManagementService is asked to create a component using some arguments.

Expected Behavior: The ComponentManagementService takes the arguments and uses them to create a component, which is then stored.


Scenario 4: A ComponentManagementService is asked to create a component that already exists.

Expected Behavior: The ComponentManagementService will not overwrite the existing component and will report failure.


Scenario 5: A ComponentManagementService is asked to create a component using some arguments, but is given an invalid set of arguments (missing required parameters, wrong order, wrong types, etc.).

Expected Behavior: The ComponentManagementService will report that it failed to create the component.


Scenario 6: A ComponentManagementService is asked to destroy a component that has been created, given some arguments.

Expected Behavior: The component will be destroyed.


Scenario 7: A ComponentManagementService is asked to destroy a component that has been created, but is given an invalid set of arguments (missing required parameters, wrong order, wrong types, etc.).

Expected Behavior: The ComponentManagementService will report that it failed to destroy the component.


Scenario 8: A ComponentmanagementService is asked to destroy a component that has not been created or has already been destroyed.

Expected Behavior: Since no component instance exists, nothing will be destroyed and the ComponentManagementService will report failure.


Scenario 9: A ComponentmanagementService is asked to return a component that has been created.

Expected Behavior: The matching component instance is returned.


Scenario 10: A ComponentmanagementService is asked to return a component that has not been created or has already been destroyed.

Expected Behavior: Since no matching component instance can be found, the ComponentManagementService reports failure.

Changes and Additions to Public Interfaces

Addition of ComponentManagementService and ComponentIdentifier. No changes to existing pubic interfaces.

Gliffy Diagram
size600
namePublic API Additions
pagePin2

Performance Impact

No anticipated performance impact.

...