* In many cases, it's better to understand their **underlying problem or use case**, because there might be a better way to solve it than what they are trying to do.

### Ask to close

If they reply, there's a high chance you would have solved their problem, congrats, **you're a hero**! 🦸

* Now, if that solved their problem, you can ask them to:

    * In GitHub Discussions: mark the comment as the **answer**.

[[sub:selecting-preferred-capability-provider]]
=== Selecting between different capability candidates

In the relocation example above, Gradle was able to tell you that you have two versions of the same API on classpath: an "old" module and a "relocated" one.

    public String asClickableFileUrl(File path) {
        // File.toURI().toString() leads to a URL like this on Mac: file:/reports/index.html
        // This URL is not recognized by the Mac console (too few leading slashes). We solve
        // this be creating an URI with an empty authority.
        try {
            return new URI("file", "", path.toURI().getPath(), null, null).toASCIIString();
        } catch (URISyntaxException e) {

    // IDE tries to acquire its bytecode via the index, however,
    // the index doesn't cover classfiles from compiler output,
    // so the lowering fails.
    //
    // To solve the problem, we need to find all delegated properties with inline accessors
    // reachable from files that will be compiled, and include files these inline accessors

For that, a plugin called `extra-java-module-info` is defined in the `buildSrc` folder.
This plugin can be copied into another project and adjusted as needed to solve use cases where it is desired to treat every dependency as a Java Module.

The example defines an application that relies on libraries from Maven central where some of them are not available as modules.

## Use Case

Let's start with an example **use case** and then see how to solve it with this.

Let's imagine that you have some **machine learning models** that you want to use to handle requests. 🤖

 *     sourceCompatibility = 1.6
 *     targetCompatibility = 1.5
 *     javaRuntimeName = "J2SE-1.5"
 *
 *     file {
 *       //whenMerged closure is the highest voodoo
 *       //and probably should be used only to solve tricky edge cases.
 *       //the type passed to the closure is {@link Jdt}
 *
 *       //closure executed after jdt file content is loaded from existing file
 *       //and after gradle build information is merged

  - org:foo between versions 1.1 and 1.0"""
        failure.assertHasResolutions("Run with :dependencyInsight --configuration conf " +
            "--dependency org:foo to get more insight on how to solve the conflict.",
            STACKTRACE_MESSAGE,
            INFO_DEBUG,
            SCAN,
            GET_HELP
        )
    }

But because of our changes in `GzipRequest.body`, the request body will be automatically decompressed when it is loaded by **FastAPI** when needed.

## Accessing the request body in an exception handler

!!! tip
    To solve this same problem, it's probably a lot easier to use the `body` in a custom handler for `RequestValidationError` ([Handling Errors](../tutorial/handling-errors.md#use-the-requestvalidationerror-body){.internal-link target=_blank}).

    ```

!!! info
    Notice that we are only declaring one dependency in the *path operation function*, the `query_or_cookie_extractor`.

    But **FastAPI** will know that it has to solve `query_extractor` first, to pass the results of that to `query_or_cookie_extractor` while calling it.

```mermaid
graph TB

query_extractor(["query_extractor"])