Questions regarding OASFilter implemations

[dhoffer]

We have an OASFilter implementation and that class is specified in the application.yml configs. We are observing, starting today on one developer laptop two bad behaviors. I'm just hoping you can shed some light on this.

1. Our OASFilter implementation is never being called.
2. Our OASFilter implementation is being called but is being called too late. We use the results of our OASFilter as config options in many of our JAX-RS services so the OASFilter must be complete before JAX-RS endpoints are called. I was hoping I could control the order of OASFilter but I see that is not CDI managed so I can't set Priority/etc.

Do you have any insights regarding these two issues?

[MikeEdgar]

Generally speaking, the OASFilter runs after all other OpenAPI processing (reader, static file, and annotation scanning) is completed. Depending on your runtime, the timing could differ a bit.

If you're using Quarkus, the filter will run once when the application builds, then once again when it is started. If you have a reproducer, maybe I can help identify why it's not running when you expect.

[Postremus]

A few tests.
I created a sample quarkus app using code.quarkus.io (just rest, and openapi).
Filter Impl:

@OpenApiFilter(OpenApiFilter.RunStage.BOTH)
public class MyFilter implements OASFilter {
    @Override
    public Operation filterOperation(Operation operation) {
        System.out.println("Hello from CL: %s. TCCL: %s".formatted(this.getClass().getClassLoader().getName(), Thread.currentThread().getContextClassLoader().getName()));
        return OASFilter.super.filterOperation(operation);
    }
}

Causes the following logs at given RunStage:

RUN causes 1 log:
Hello from CL: Deployment Class Loader: DEV for soapi-filter-1.0.0-SNAPSHOT. TCCL: Deployment Class Loader: DEV for soapi-filter-1.0.0-SNAPSHOT

And another Log when opening the swagger-ui:

Hello from CL: Quarkus Runtime ClassLoader: DEV for soapi-filter-1.0.0-SNAPSHOT restart no:3. TCCL: Quarkus Runtime ClassLoader: DEV for soapi-filter-1.0.0-SNAPSHOT restart no:3

BOTH causes 2 logs:
Hello from CL: Deployment Class Loader: DEV for soapi-filter-1.0.0-SNAPSHOT. TCCL: Deployment Class Loader: DEV for soapi-filter-1.0.0-SNAPSHOT                                                                                                                                                                     
Hello from CL: Deployment Class Loader: DEV for soapi-filter-1.0.0-SNAPSHOT. TCCL: Deployment Class Loader: DEV for soapi-filter-1.0.0-SNAPSHOT


And another Log when opening the swagger-ui:
Hello from CL: Quarkus Runtime ClassLoader: DEV for soapi-filter-1.0.0-SNAPSHOT restart no:4. TCCL: Quarkus Runtime ClassLoader: DEV for soapi-filter-1.0.0-SNAPSHOT restart no:4

BUILD causes 1 log: 
Hello from CL: Deployment Class Loader: DEV for soapi-filter-1.0.0-SNAPSHOT. TCCL: Deployment Class Loader: DEV for soapi-filter-1.0.0-SNAPSHOT

Definitly seems fishy.

After a bit of debugging, found out that io.quarkus.smallrye.openapi.deployment.SmallRyeOpenApiProcessor#getUserDefinedBuildtimeFilters returns the same filter multiple times.

Same for #getUserDefinedRuntimeFilters.

In getUserDefinedFilters,

index.getAnnotations(OpenApiFilter.class)

returns the same filter twice already. Even for RUN.

Seems strange, returning the same filter multiple times from the index already.
But, does not seem related. The log indicates that the filter is first called at build time, and then later when opening swagger-ui.
Needs to be looked at anyway maybe.

@dhoffer Is something in your app automatically requesting the openapi definition? This would explain why the filter is run twice.

@MikeEdgar What exactly does the RunStage.RUN mean? Are filters with RUN only supposed to be called on initial load of the openapi doc, or after quarkus starts?

And another interesting point, the first log for the RUN filter is coming from this filter invocation:
https://github.com/quarkusio/quarkus/blob/main/extensions/smallrye-openapi/deployment/src/main/java/io/quarkus/smallrye/openapi/deployment/SmallRyeOpenApiProcessor.java#L943-L950
Why are runtime filters run in a build step? I guess just to have the stored openapi document as "filtered" as possible. But seems strange that filters explicitly marked with RUN are also included in this.

The second log, when opening swagger-ui, is caused by OpenApiDocumentService, which seems fine.

[dhoffer]

Yes we make a call to get the openapi at app startup, this is to store the 'static' part of the openapi so it's just done once. Then when users make a request to get the openapi we do some additional user filtering based on their permissions/etc. The user filter is just a pojo not an OASFilter. We do have one OASFilter that is annotated with @OpenApiFilter(OpenApiFilter.RunStage.RUN). We use this class to modify the static openapi per our customizations.

[MikeEdgar]

What exactly does the RunStage.RUN mean? Are filters with RUN only supposed to be called on initial load of the openapi doc, or after quarkus starts?

They will be run against the hosted OpenAPI when the server starts, but against the stored OpenAPI when the application builds. The stored OpenAPI is not the same one that is hosted at /q/openapi. As you said, the purpose is so that the stored document takes into account all the filters available.

[dhoffer]

@MikeEdgar @Postremus Our main concern is that we think we have found a latent bug in Quarkus/Smallrye-Openapi that causes classes to be loaded by different class loaders, so a Pojo Singleton is not really a Singleton at all as the 2 class loaders each loaded their own Singleton instance, obviously this breaks everything as it's not a Singleton anymore. So far we can only duplicate this issue on one developer laptop. Where so we start to track this down and resolve? I am concerned this bug could manifest at any time on any production server causing the application to fail.

[MikeEdgar]

Do you see the singleton loaded twice when running with java -jar yourapp.jar or with mvn quarkus:dev ?

[dhoffer]

Running with fat/uber jat, not dev mode.

…

On Mon, Jan 27, 2025, 7:42 AM Michael Edgar ***@***.***> wrote: Do you see the singleton loaded twice when running with java -jar yourapp.jar or with mvn quarkus:dev ? — Reply to this email directly, view it on GitHub <#2173 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAL7BLYHLFAFZU2EPYLJBAD2MZAUDAVCNFSM6AAAAABVYVJJWWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCOJXGA3TEMQ> . You are receiving this because you were mentioned.Message ID: ***@***.*** .com>

[Postremus]

I was not able to reproduce this when running as a uberjar with a simple filter.

Please provide a reproducer.

As a starting point to figure out if a problem exists, maybe take a look at what this filter outputs:

@OpenApiFilter(OpenApiFilter.RunStage.RUN)
public class MyFilter implements OASFilter {
    @Override
    public Operation filterOperation(Operation operation) {
        System.out.printf("Hello from Thread: %s CL: %s. TCCL: %s%n", Thread.currentThread().getName(), this.getClass().getClassLoader().getName(), Thread.currentThread().getContextClassLoader().getName());
        new Exception().printStackTrace();

        return OASFilter.super.filterOperation(operation);
    }
}

You can simply add this filter alongside your existing ones (multiple @OpenApiFilter are supported), or add the content into your existing one.

[dhoffer]

@MikeEdgar @Postremus I have a major apology to make. The developer thought he was running with a fat jar but in fact he was running in Quarkus DEV mode. Some of the new devs are configuring systems for DEV mode when they need to have both. In cases like this DEV modes just does not work and must run with production deployment type builds. Very sorry for the false alarm, it works fine with fat/uber jar!