Sterling Greene <******@****.***> 1762903390 -0500

                  <project path="$PROJECT_DIR$/build-logic/cleanup" />
                  <project path="$PROJECT_DIR$/build-logic/dependency-modules" />
                  <project path="$PROJECT_DIR$/build-logic/documentation" />
                  <project path="$PROJECT_DIR$/build-logic/idea" />
                  <project path="$PROJECT_DIR$/build-logic/integration-testing" />

# Lifespan Events { #lifespan-events }

You can define logic (code) that should be executed before the application **starts up**. This means that this code will be executed **once**, **before** the application **starts receiving requests**.

The same way, you can define logic (code) that should be executed when the application is **shutting down**. In this case, this code will be executed **once**, **after** having handled possibly **many requests**.

val javaParserVersion = "3.18.0"
// Note: this currently still contains 3/4 logic as we will temporarily have Groovy 3 for the build itself until we move to a Gradle built with Groovy 4
// It can be removed or changed to 4/5 logic (if necessary) at that point.
val groovyVersion = GroovySystem.getVersion()
val isGroovy4 = VersionNumber.parse(groovyVersion).major >= 4

class BuildLogicTest(
    model: CIBuildModel,
    stage: Stage,
) : OsAwareBaseGradleBuildType(os = Os.LINUX, stage = stage, init = {
        id(buildTypeId(model))
        name = "Build-logic checks"
        description = "Run check on all build-logic builds"

        features {
            publishBuildStatusToGithub(model)
        }

        applyDefaults(
            model,
            this,
            "checkBuildLogic",

    id("com.gradle.develocity").version("4.3") // Run `java build-logic-settings/UpdateDevelocityPluginVersion.java <new-version>` to update
    id("io.github.gradle.develocity-conventions-plugin").version("0.12.1")
    id("org.gradle.toolchains.foojay-resolver-convention").version("1.0.0")
}

include("build-environment")
include("configuration-cache-compatibility")

# Custom Request and APIRoute class { #custom-request-and-apiroute-class }

In some cases, you may want to override the logic used by the `Request` and `APIRoute` classes.

In particular, this may be a good alternative to logic in a middleware.

For example, if you want to read or manipulate the request body before it is processed by your application.

/// danger

This is an "advanced" feature.

├── FessBoot.java              # Application entry point
├── app/
│   ├── web/                   # User-facing controllers
│   ├── web/admin/             # Admin controllers
│   ├── service/               # Business logic
│   └── job/                   # Background jobs
├── api/                       # REST API endpoints
├── opensearch/                # OpenSearch integration
│   ├── config/                # Config index (crawl configs, schedules)

        assertTrue("OnConnectListener list should be thread-safe",
                fesenClient.onConnectListenerList instanceof java.util.concurrent.CopyOnWriteArrayList);
    }

    /**
     * Test: Retry logic correctly enforces maxRetryCount
     * Verifies that with maxRetryCount=5, the operation is tried exactly 6 times (initial + 5 retries)
     */
    @Test
    public void testRetryLogicMaxRetryCount() throws Exception {

        void shouldInheritBehaviorFromAbstractUpgradeGoal() {
            // This test verifies that Apply inherits the model version logic from AbstractUpgradeGoal
            // The actual logic is tested in AbstractUpgradeGoalTest
            // Here we just verify that Apply is properly configured as a subclass