Overview
ConfigurableService extends the Service class to support services that can have multiple deployment configurations. It provides a typed configuration object that can be customized before service initialization.
It’s not recommended to use ConfigurableService with ReusableOpenshiftDeployable, as different configurations in the same test run may cause deployment conflicts.
Class signature
software.tnb.common.service
Type parameters:
A- Account type that extendsAccountC- Client type (service-specific)V- Validation type that extendsValidationS- Service configuration type that extendsServiceConfiguration
Properties
The configuration instance for this service, automatically instantiated based on the generic type parameter
account- The account instanceclient- The client instancevalidation- The validation instance
Methods
getConfiguration()
Returns the configuration instance for this service.The ServiceConfiguration instance for customizing service behavior
defaultConfiguration()
Abstract method that must be implemented to define default configuration values. Called automatically by ServiceFactory after instantiation.account()
Overrides the Service method to use ConfigurableService’s generic type resolution.The Account instance for this service
Implementation example
Here’s how to implement a ConfigurableService:Configuration patterns
Configuration classes
Service configurations extendServiceConfiguration:
Common configurable services
Many TNB services extend ConfigurableService:- AWS services - Configure region, localstack usage
- Database services - Configure connection pools, schemas
- Message brokers - Configure topics, queues, clusters
- HTTP services - Configure ports, routes, authentication
Configuration lifecycle
- Service creation - ConfigurableService instantiated
- Configuration instantiation - Configuration object created via reflection
- Default configuration -
defaultConfiguration()called by ServiceFactory - Custom configuration - User’s configuration Consumer applied (if provided)
- Service initialization -
beforeAll()uses configuration values
Configuration must be set before calling
beforeAll(). Changes after initialization may not take effect.Best practices
Do
- Define sensible defaults in
defaultConfiguration() - Make configuration immutable after
beforeAll() - Validate configuration values in
beforeAll() - Document configuration options clearly
Don’t
- Don’t modify configuration after service initialization
- Don’t use ConfigurableService with ReusableOpenshiftDeployable
- Don’t skip
defaultConfiguration()implementation - Don’t make configuration changes thread-unsafe
Related
- Service - Base class for all services
- ServiceFactory - Factory for creating configured services
- AccountFactory - Factory for creating accounts