Configuration

This document provides a comprehensive guide to configuring the IT Ticketing Service application. A core design principle of this service is its reliance on externalized configuration, which is critical for its migration strategy from on-premises to Google Cloud Platform. Understanding these configuration options is essential for local development, deployment, and maintenance.

Application Properties

The application leverages the Spring Boot externalized configuration framework, primarily using .properties files located in src/main/resources. This approach allows the application artifact (JAR file) to be environment-agnostic, with runtime behavior controlled entirely by external properties.

Overview of application.properties

The primary configuration file is application.properties. This file contains the default settings, which are configured for the legacy on-premises environment.

# src/main/resources/application.properties

# Application Configuration
spring.application.name=it-ticketing-service
server.port=8080

# MySQL Database Configuration (On-Premises)
spring.datasource.url=jdbc:mysql://legacydb.next26.slalomlab.com:3306/ticketing
spring.datasource.username=ticketing_user
spring.datasource.password=changeme
spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver

# RabbitMQ Configuration
spring.rabbitmq.host=localhost
# ... other properties

# Actuator Configuration
management.endpoints.web.exposure.include=health,info
management.endpoint.health.show-details=always

# Logging Configuration
logging.level.com.slalom.demo.ticketing=INFO
logging.level.org.springframework.amqp=INFO
logging.level.org.springframework.web=INFO

Configuration Profiles

Spring Profiles are used to provide environment-specific configuration that overrides the defaults in application.properties.

Local Profile (local)

For local development, a profile named local is provided via application-local.properties. This profile is designed to connect to local instances of dependencies and enable more verbose logging for easier debugging.

To activate this profile, set the spring.profiles.active property when running the application:

# Using Maven
mvn spring-boot:run -Dspring-boot.run.profiles=local

# Using java -jar
java -jar -Dspring.profiles.active=local target/it-ticketing-service-1.0.0.jar

The application-local.properties file overrides several key settings:

# src/main/resources/application-local.properties

# Local MySQL Database Configuration
spring.datasource.url=jdbc:mysql://localhost:3306/ticketing?createDatabaseIfNotExist=true
spring.datasource.username=root
spring.datasource.password=password

# JPA/Hibernate Configuration for Development
spring.jpa.hibernate.ddl-auto=update
spring.jpa.show-sql=true # Enables SQL logging

# Local RabbitMQ Configuration
spring.rabbitmq.host=localhost
spring.rabbitmq.port=5672
spring.rabbitmq.username=guest
spring.rabbitmq.password=guest

# Actuator Configuration for Local Development
management.endpoints.web.exposure.include=health,info,metrics

# Verbose Logging for Debugging
logging.level.com.slalom.demo.ticketing=DEBUG
logging.level.org.springframework.amqp=DEBUG
logging.level.org.springframework.web=DEBUG

Externalized Configuration Philosophy

As outlined in the project's architectural guidelines, the configuration strategy is paramount. The primary goal is to facilitate migration to GCP with minimal to zero code changes.

• Environment Agnosticism: The Java code is written to be unaware of the environment it's running in. It relies on abstractions like Spring Data JPA and Spring AMQP, whose concrete implementations are configured externally.
• 12-Factor App Principles: The application adheres to the "Config" principle of the 12-Factor App methodology, storing configuration in the environment.
• Migration via Configuration: The migration from the on-premises VMware environment to Google Cloud will be achieved by providing a new configuration profile (e.g., gcp) or by setting environment variables in the target platform (e.g., Cloud Run, GKE). For more details on this strategy, see the GCP Migration Plan.

Database Configuration

The application uses Spring Data JPA with Hibernate as the persistence provider to connect to a MySQL database. All connection and behavior properties are externalized.

For more details on the data access layer implementation, see the Database Integration documentation.

MySQL Connection Settings

The following table details the primary datasource properties.

Property	application.properties (Default)	application-local.properties (Local)	Description
spring.datasource.url	jdbc:mysql://legacydb.next26.slalomlab.com:3306/ticketing	jdbc:mysql://localhost:3306/ticketing	The JDBC URL for the MySQL database.
spring.datasource.username	ticketing_user	root	The username for the database connection.
spring.datasource.password	changeme	password	The password for the database connection. This should be externalized via environment variables.
spring.datasource.driver-class-name	com.mysql.cj.jdbc.Driver	com.mysql.cj.jdbc.Driver	The fully qualified name of the JDBC driver. Auto-detection is usually sufficient but specified for clarity.

JPA/Hibernate Settings

These properties control the behavior of the Object-Relational Mapping (ORM) layer.

Property	Value (Default / Local)	Description
spring.jpa.hibernate.ddl-auto	update	Controls the schema generation strategy. update automatically modifies the schema based on entity definitions. Caution: While convenient for development, this is risky for production. Production environments should use a dedicated database migration tool like Flyway or Liquibase.
spring.jpa.show-sql	false / true	If true, Hibernate will log all executed SQL statements to the console. This is enabled in the local profile for debugging and disabled by default to reduce log noise and improve performance.
spring.jpa.properties.hibernate.dialect	org.hibernate.dialect.MySQLDialect	Specifies the SQL dialect for Hibernate to use, ensuring compatibility with MySQL-specific syntax.
spring.jpa.properties.hibernate.format_sql	true	When spring.jpa.show-sql is enabled, this property formats the logged SQL for better readability.

RabbitMQ Configuration

The application integrates with a RabbitMQ message broker using Spring AMQP for asynchronous event publishing.

For more details on the messaging architecture, see the RabbitMQ Integration documentation.

Message Broker Connection Settings

These properties configure the connection to the RabbitMQ broker.

# Default values from application.properties
spring.rabbitmq.host=localhost
spring.rabbitmq.port=5672
spring.rabbitmq.username=guest
spring.rabbitmq.password=guest

Note: The default configuration points to localhost. In a real on-premises deployment, spring.rabbitmq.host would be set to the fully qualified domain name (FQDN) of the RabbitMQ server. This value is a placeholder for the demo environment.

Queue and Exchange Configuration

In addition to standard Spring AMQP properties, the application defines custom properties to externalize the names of messaging components. This is a best practice that allows infrastructure topology to be changed without modifying code.

These properties are consumed within the application, likely via @Value annotations or a @ConfigurationProperties class, to programmatically declare queues, exchanges, and bindings.

# Custom properties from application.properties
rabbitmq.exchange.name=ticket.exchange
rabbitmq.queue.name=ticket.queue
rabbitmq.routing.key=ticket.routing.key

Property	Default Value	Description
rabbitmq.exchange.name	ticket.exchange	The name of the AMQP exchange to which ticket events are published.
rabbitmq.queue.name	ticket.queue	The name of the durable queue that will receive ticket events.
rabbitmq.routing.key	ticket.routing.key	The routing key used for publishing and binding the queue to the exchange.

Environment Variables

To adhere to the 12-factor app methodology and securely manage secrets, all properties defined in the application.properties files can and should be overridden by environment variables.

Using Environment Variables for Sensitive Data

Spring Boot automatically maps environment variables to configuration properties. The mapping rule is to convert the property name to uppercase and replace dots (.) with underscores (_).

For example, to override the database password, you would set an environment variable like this:

# Example for a Linux/macOS shell
export SPRING_DATASOURCE_PASSWORD="a-very-secure-password-from-secrets-manager"

# Now run the application
java -jar target/it-ticketing-service-1.0.0.jar

This is the recommended approach for injecting secrets like database passwords and API keys into the application, especially in containerized environments like Cloud Run or GKE.

Configuration Precedence

It is critical to understand the order in which Spring Boot applies configuration sources. A simplified view of the precedence order (from highest to lowest) is:

1. Environment Variables: Have the highest priority and will override all other sources.
2. application-{profile}.properties: Profile-specific properties files.
3. application.properties: The default properties file.

This hierarchy ensures that environment-specific settings (like those from environment variables or a gcp profile) will always take precedence over the default and local development configurations.

Best Practices for Secrets Management

• Never Commit Secrets: The changeme and password values in the repository's property files are for demonstration purposes only. In a production-grade project, these properties should be omitted from version control entirely.
• Use a Secrets Manager: For deployed environments (staging, production), secrets should be stored in a dedicated service like Google Secret Manager, AWS Secrets Manager, or HashiCorp Vault.
• Inject Secrets at Runtime: The deployment platform should be configured to fetch secrets from the secrets manager and inject them into the application container as environment variables at runtime. This is a standard practice supported by Google Cloud Run and GKE. For more context, see the GCP Migration Plan.