Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -277,6 +277,7 @@ public final class io/ktor/server/plugins/di/DependencyRegistry$KeyContext {
public final class io/ktor/server/plugins/di/DependencyRegistryKt {
public static final fun dependencies (Lio/ktor/server/application/Application;Lkotlin/jvm/functions/Function1;)Ljava/lang/Object;
public static final fun getDependencies (Lio/ktor/server/application/Application;)Lio/ktor/server/plugins/di/DependencyRegistry;
public static final fun getDependencies (Lio/ktor/server/routing/Route;)Lio/ktor/server/plugins/di/DependencyRegistry;
public static final fun setDependencies (Lio/ktor/server/application/Application;Lio/ktor/server/plugins/di/DependencyRegistry;)V
}

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -397,6 +397,8 @@ final val io.ktor.server.plugins.di/Supertypes // io.ktor.server.plugins.di/Supe
final fun <get-Supertypes>(): io.ktor.server.plugins.di/DependencyKeyCovariance // io.ktor.server.plugins.di/Supertypes.<get-Supertypes>|<get-Supertypes>(){}[0]
final val io.ktor.server.plugins.di/Unnamed // io.ktor.server.plugins.di/Unnamed|{}Unnamed[0]
final fun <get-Unnamed>(): io.ktor.server.plugins.di/DependencyKeyCovariance // io.ktor.server.plugins.di/Unnamed.<get-Unnamed>|<get-Unnamed>(){}[0]
final val io.ktor.server.plugins.di/dependencies // io.ktor.server.plugins.di/dependencies|@io.ktor.server.routing.Route{}dependencies[0]
final fun (io.ktor.server.routing/Route).<get-dependencies>(): io.ktor.server.plugins.di/DependencyRegistry // io.ktor.server.plugins.di/dependencies.<get-dependencies>|<get-dependencies>@io.ktor.server.routing.Route(){}[0]

final var io.ktor.server.plugins.di/dependencies // io.ktor.server.plugins.di/dependencies|@io.ktor.server.application.Application{}dependencies[0]
final fun (io.ktor.server.application/Application).<get-dependencies>(): io.ktor.server.plugins.di/DependencyRegistry // io.ktor.server.plugins.di/dependencies.<get-dependencies>|<get-dependencies>@io.ktor.server.application.Application(){}[0]
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -5,6 +5,7 @@
package io.ktor.server.plugins.di

import io.ktor.server.application.*
import io.ktor.server.routing.*
import io.ktor.utils.io.*
import kotlinx.coroutines.Deferred
import kotlin.properties.ReadOnlyProperty
Expand Down Expand Up @@ -189,6 +190,9 @@ public var Application.dependencies: DependencyRegistry
attributes.put(DependencyRegistryKey, value)
}

public val Route.dependencies: DependencyRegistry
get() = application.attributes[DependencyRegistryKey]

Comment on lines +193 to +195
Copy link
Contributor

@coderabbitai coderabbitai bot Aug 13, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛠️ Refactor suggestion

Delegate to Application.dependencies to auto-install DI and avoid NoSuchElementException

Accessing application.attributes[DependencyRegistryKey] will throw if the DI plugin isn’t installed. The Application-level property already handles auto-install (install(DI)), so delegate to it for consistent and safer behavior.

Additionally, this is a new public API; it should have KDoc like the rest of this file.

Apply this diff to fix the getter:

-public val Route.dependencies: DependencyRegistry
-    get() = application.attributes[DependencyRegistryKey]
+public val Route.dependencies: DependencyRegistry
+    get() = application.dependencies

Add KDoc above the property (outside the changed lines):

/**
 * Provides route-scoped access to the application's [DependencyRegistry].
 *
 * For use inside routing builders and extension functions:
 *   val service: MyService by dependencies
 *
 * This forwards to [Application.dependencies] and will install the DI plugin if missing.
 *
 * [Report a problem](https://ktor.io/feedback/?fqname=io.ktor.server.plugins.di.Route.dependencies)
 */
🤖 Prompt for AI Agents
In
ktor-server/ktor-server-plugins/ktor-server-di/common/src/io/ktor/server/plugins/di/DependencyRegistry.kt
around lines 193 to 195, the Route.dependencies getter currently accesses
application.attributes[DependencyRegistryKey] which can throw if the DI plugin
isn't installed and is inconsistent with Application.dependencies; change the
getter to delegate to application.dependencies so it will auto-install the DI
plugin and avoid NoSuchElementException, and add the provided KDoc block above
the public property (outside the changed lines) describing route-scoped access,
usage example, that it forwards to Application.dependencies and will install DI
if missing, and include the feedback URL.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The rabbit is correct in this matter ☝️

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bjhham Thank you for confirming! I'm glad the suggestion to delegate to Application.dependencies and add proper KDoc makes sense. This will indeed make the Route-level dependency access more robust and consistent with the existing Application-level behavior.

( ˶ᵔ ᵕ ᵔ˶ )

Copy link
Contributor Author

@solonovamax solonovamax Aug 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The rabbit is correct in this matter ☝️

having it throw is intentional, as dependencies should be configured at an application-level rather than at a route level (as if you configured it at a route level, you would expect it to be scoped to the route, however it is not, as doing so is rather out of scope for the PR)

also, because Application.dependencies does not have any documentation, I omitted documentation on this.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like the humans are having a chat. I'll hop back into my burrow for now. If you need me again, just tag @coderabbitai in a new comment, and I'll come hopping out!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am thinking now that we may want to avoid introducing this extension. It is better to always resolve dependencies during application startup, because it allows for validation during startup and avoids unnecessary lookups. I'm concerned this would encourage people to resolve dependencies during request processing, which is not ideal.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it might be okay to introduce Route.dependencies, but not RoutingContext.dependencies. After fixing DSL scope annotations (#5058) usage of this extension in RoutingContext scope will throw a compilation error. So all dependencies will be resolved at the moment of routing initialization. @bjhham wdyt?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am thinking now that we may want to avoid introducing this extension. It is better to always resolve dependencies during application startup, because it allows for validation during startup and avoids unnecessary lookups. I'm concerned this would encourage people to resolve dependencies during request processing, which is not ideal.

they are resolved at application startup. can routes even be added at any point after that? and you could even already do it at runtime by just doing like

fun Application.whatever() {
    routing {
        get("/") {
            val myService: MyService by dependencies
        }
    }
}

however, I do actually think it would be actually useful to be able to resolve it at runtime

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah this is true, I mixed up Route and RoutingContext. The naming is a bit confusing in my defense. @solonovamax that snippet is valid currently in 3.0, but we're planning on fixing the DSL scope annotations so application references will need to be explicit. There can be uses for accessing dependencies after startup, but in general it's better practice to validate everything as early as possible. The routing DSL generally runs at the same time as the modules so we should be good to go there 👍

/**
* Used for tracing references to dependency keys in the application.
*
Expand Down