Instance Management Strategy

[ambu550]

Each module exposes its user-facing class in the following package:
package net.bugreaper.modules.{module}

Each module provides at least two constructors with distinct initialization strategies:

• Direct construction — creates a new instance of the class using explicitly provided parameters. The resulting object is independently configured and managed by the caller (setters supported).

import net.bugreaper.modules.rabbit.Rabbit;

Rabbit rabbit = new Rabbit("localhost", "5673", "guest","guest_pass");

• Shared-instance construction — creates or retrieves a shared instance initialized from the application configuration file. This instance is intended to be reused across the application rather than creating a separate helper object for each use.

Note: The shared-instance mechanism is not a strict Singleton implementation at this stage. The class constructors are not private, so additional instances can still be created explicitly. The implementation currently provides shared-instance semantics rather than enforcing a single globally unique instance throughout the application's lifecycle.

import net.bugreaper.modules.rabbit.Rabbit;

Rabbit rabbit = Rabbit.getInstance();

Exclusion:

• Some modules implement a multiton pattern instead of, or in addition to, the shared-instance mechanism.

In such cases, the module maintains multiple shared instances, typically distinguished by a unique key or configuration, while ensuring that each key maps to a single shared instance.

Redis module uses a multiton exclusively. A single shared instance is maintained for each Redis data type. For example, separate shared instances may exist for strings, lists, sets, hashes, sorted sets, and streams.All Redis instances use the same YAML configuration section, with the data type determining which shared instance is accessed.

import net.bugreaper.modules.redis.Redis;

Redis listRedis = Redis.getInstance("list");
Redis hashRedis = Redis.getInstance("hash");

CustomDb in the DB module supports both shared-instance and multiton mechanisms. Multiple database connections can be created and reused by defining separate configuration entries using key suffixes in the YAML configuration. Each suffix identifies a distinct database connection and its associated configuration.

import net.bugreaper.modules.db.CustomDb;

CustomDb db = CustomDb.getInstance(); // config from modules:db:custom-db:
CustomDb db2 = CustomDb.getInstance("-2"); // config from  modules:db:custom-db-2:
CustomDb dbClick = CustomDb.getInstance("-clickhouse"); // config from  modules:db:custom-db-clickhouse:

API module supports both shared-instance and multiton mechanisms. Multiple API connections/clients can be created and reused by defining separate configuration entries using key suffixes in the YAML configuration. Each suffix identifies a distinct API instance and its associated configuration.

import net.bugreaper.modules.api.Api;

Api api = Api.getInstance();  // config from modules:api:
Api apiOther = new Api( "-service2"); // config from modules:api-service2:

$\color{red}\text{***Shared-instance and multiton mechanisms promote connection reuse and help}$ $\color{red}\text{prevent excessive resource consumption, reducing the risk of}$ $\color{red}\text{connection-limit errors and performance degradation.}$

YAML configuration using

• Default configuration file: bugreaper.yml (in resources)
• Custom configuration file: using -DbugreaperEnv=test loads bugreaper-test.yml

More information on https://bugreaper.net/ and Wiki pages on GitLab.