edison-microservice

Collection of independent libraries on top of Spring Boot to provide a faster setup of jvm microservices.

"I never did anything by accident, nor did any of my inventions come by accident; they came by work." - Thomas Edison

Status

Have a look at the release notes for details about updates and changes.

About

This project contains a number of independent libraries on top of Spring Boot to provide a faster setup of JVM microservices. The libraries are used in different projects at OTTO. Its purpose is to provide a common implementation for cross-cutting requirements like:

• Health checks that are used to tell the load balancer whether or not a service is healthy.
• A status page/document that is used to give information about the current state of the service. Status information also include details about sub-components, background jobs like imports, and so on.
• A simple job handling library that is used to run asynchronous background jobs, which for example can be used to run data imports from other systems.
• An optional MongoDB-based implementation of a JobRepository
• Support for MongoDB-based repositories in case you do not like Spring Data
• Support for feature toggles based on Togglz

... plus all the features of Spring Boot.

Releases

Semantic Versioning v2.0.0 is generally used to specify the version numbers. We add a fourth number for hotfixes to keep the main version in sync with the included Spring Boot version. So 4.0.3.1 is the first hotfix of the Edison version that contains Spring Boot 4.0.3.

This project maintains its roadmap with issues and milestones.

4.0.x: Edison Microservices for Spring Boot 4.0.x ✔ - Compatible with Java 17 and greater

3.5.x: Edison Microservices for Spring Boot 3.5.x ✔ - Compatible with Java 17 and greater

2.7.x (EOL): Edison Microservices for Spring Boot 2.7.x ✔ - Compatible with Java 11 and greater - End of Life, not updated any more

3.2.x (EOL): Edison Microservices for Spring Boot 3.2.x ✔ - Compatible with Java 17 and greater - End of Life, not updated any more

Migration from Edison 3 to Edison 4

You should be fine if you follow the Spring Boot 3 → 4 migration guide: https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-4.0-Migration-Guide

If you have custom frontend templates you have to migrate them from Bootstrap 3 to Bootstrap 5. The biggest changes were introduced with Bootstrap 4, which was skipped by Edison. Please have a look into Boostrap 3 → 4 migration guide for details: https://getbootstrap.com/docs/4.0/migration/ Update everything to Bootstrap 5 afterwards: https://getbootstrap.com/docs/5.0/migration/

Migration from Edison 2 to Edison 3

In edison-ldap, whitelisted-paths was replaced with allowlisted-paths. Everything else should be ok if you follow the Spring Boot 2 -> 3 migration guide: https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.0-Migration-Guide

Migration from Edison 1.x to Edison 2

Edison 2 has several breaking changes that will make a refactoring of your current application necessary. For a list of the actual changes, please take a look at the Changelog.

When migrating, take care of the following adjustments:

• Follow the Spring Boot 2.0 Migration Guide to fix the most common problems.

  • If you want to use the behaviour of Edison 1.x, which hosts all management endpoints below /internal, you have to configure management.endpoints.web.base-path=/internal in your application.yml

• Remove dependencies to the edison-aws Project, which will be deprecated some time in the future. Necessary functionality was transferred to a submodule of edison-microservice (named edison-aws).

• If you have used gradlew bootRepackage for packaging your application so far, you have to migrate this to gradlew bootJar.

• Refactor calls made through the AWS SDK, which got updated in the process of the new major version of edison and this will most probably break prior code that relied on the AWS SDK.

• To use @Timed-Annotations, you need to configure Micrometer accordingly. See the following Example for a configuration that covers the annotation and naming of all metrics:

    @Configuration
    @EnableAspectJAutoProxy
    public class MicrometerConfiguration {
    
        @Bean
        public PrometheusNamingConvention prometheusNamingConvention() {
            return new PrometheusNamingConvention();
        }
    
        @Bean
        public MeterRegistryCustomizer<MeterRegistry> metricsCommonTags(@Value("${service.vertical}") final String vertical,
                                                                        @Value("${service.name}") final String serviceName,
                                                                        final PrometheusNamingConvention prometheusNamingConvention) {
            return registry -> registry
                    .config()
                    .namingConvention(new NamingConvention() { 
                        // Set naming convention that gets applied to all metrics, in this  example explicitly using a Prometheus naming convention
                        @Override
                        public String name(final String name, final Meter.Type type, final String baseUnit) {
                            return prometheusNamingConvention.name(String.format("%s.%s.%s", vertical, serviceName, name), type, baseUnit);
                        }
                    })
                    .meterFilter(new MeterFilter() { // Configure generally applicable configurations, like percentiles
                        @Override
                        public DistributionStatisticConfig configure(final Meter.Id id,
                                                                     final DistributionStatisticConfig config) {
                            return config.merge(DistributionStatisticConfig.builder()
                                    .percentiles(0.5, 0.9, 0.95, 0.98, 0.99, 0.999)
                                    .build());
                        }
                    });
        }
    
        // Create a `TimedAspect` to enable `@Timed`-Annotations
        @Bean
        public TimedAspect timedAspect(final MeterRegistry registry) {
            return new TimedAspect(registry);
        }
    }

Documentation

Edison Modules:

• edison-core: Main library of Edison microservices.
• edison-jobs: Optional module providing a simple job library.
• edison-mongo: Auto-configuration for MongoDB repositories plus implementation of MongoJobRepository and Togglz StateRepository.
• edison-oauth: Auto-configuration for OAuth Public Key repositories with autofetching and a simple JWT Token Validation.
• edison-togglz: Optional support for feature toggles for Edison microservices based on Togglz.
• edison-testsupport: Test support for feature toggles plus utilities.
• edison-validation: Optional module for validation in Spring with a specific response format.

Examples:

• example-status: Service only relying on edison-core to show the usage of health and status features.
• example-jobs: Edison service using edison-jobs to run background tasks.
• example-togglz: Example using `edison-togglz´ to implement feature toggles.
• example-togglz-mongo: Same edison-toggz, but with a MongoDB configuration to auto-configure persistence of feature toggles.

Setup

Make sure you have Java 17 or later installed on your computer.

Testing

Test and create coverage report

gradle check

Dependency Update

Determine possible dependency updates

gradle dependencyUpdates -Drevision=release

Publishing

Releases are published to both GitHub Packages (snapshots and releases) and Maven Central (releases only) via the Release workflow using JReleaser.

Step-by-step release process

1. Set the release version in build.gradle — remove the -SNAPSHOT suffix:

   def edison_version = "4.1.1"
   

2. Update CHANGELOG.md with the release notes for this version. The entry must start with a heading of the exact form ## <version>, e.g.:

   ## 4.1.1
   * **[core]**: Some fix
   * **[all]**: Update to Spring Boot 4.1.1

   This section is extracted verbatim and used as the GitHub release body.

3. Commit and push:

   git commit -am "chore: prepare release 4.1.1"
   git push

4. Trigger the release workflow, passing the version and the branch to release from:

   # Release from main
   gh workflow run release.yml -f version=4.1.1 -f branch=main
   
   # Release from 3.5.x
   gh workflow run release.yml -f version=3.5.11 -f branch=3.5.x

   Alternatively, use the GitHub Actions UI: Actions → Release → Run workflow.

   The workflow will:

   • Validate that the version matches build.gradle and is not a SNAPSHOT
   • Extract the ## <version> section from CHANGELOG.md as the GitHub release body
   • Run all tests
   • Publish artifacts to GitHub Packages and Maven Central
   • Create a GitHub release with the changelog entry as release notes

5. Bump to the next snapshot version after a successful release:

   def edison_version = "4.1.2-SNAPSHOT"
   

   git commit -am "chore: bump to 4.1.2-SNAPSHOT"
   git push

For local releases (e.g. testing the release process), you can still use ./release.sh, which requires credentials configured in ~/.jreleaser/config.toml.

Examples

There are a few examples that may help you to start your first microservice based on Edison and Spring Boot. Because Spring Boot itself has some complexity, it is recommended to first read its documentation before starting with Edison.

The examples can be started with gradle:

gradle examples:example-status:bootRun
gradle examples:example-jobs:bootRun
gradle examples:example-togglz:bootRun
gradle examples:example-togglz-mongo:bootRun

Open in your browser http://localhost:8080/

Note: Every example is configured to use port 8080, so make sure to run only one example at a time or to reconfigure the ports.

Contributing

Have a look at our contribution guidelines.