Multiple Application classes in one project?

[tjquinno]

(transplanted from the old Google group)

Some time ago on an older release of SmallRye OpenAPI, we noticed trouble when multiple JAX-RS Aoplication classes were present. IIRC we would see only one represented in the OpenAPI document produce, and which one could vary from run to run.

I've been doing some things with 2.0.26 recently and it seems as if the scanner and related code are handling multiple apps just fine (see below for a definition of "just fine"). I have seen at least one issue opened about this and closed as not supported (#645).

Does this in fact work and, if so, is this supported?

I've been working recently with a simple two-application project. I see all endpoints from both apps represented in the OpenAPI document, and the components section contains entries for POJOs used from all endpoints.

Certainly the document can contain only one info section, even if all apps bear the @OpenAPIDefinition, for example. But as stated in #645, the MP OpenAPI spec hints at but doesn't define the "correct" behavior in such cases. So it's developer beware (at least with respect to multiple classes with @OpenAPIDefinition) and that seems fine to me.

[phillip-kruger]

Hi @tjquinno .
@MikeEdgar please jump in here, as I do not have all the history.

As far as I know, the spec targets microservices (hence also the /openapi url) and thus expects a merged openapi document. The same way that you can also supply a document and merge it with the annotation scanned document.

In smallrye, this is not really enforced, as the implementations (Quarkus/Wildfly etc) can decide to create multiple separate documents and make them available under a context root. SmallRye allow the scanning of annotations (but the scope / jandex index is supplied by the implementation) and the merging of static documents. So a implementation can basically create a document per application by controlling the jandex index it provides to be scanned.

Not sure if this makes sense. @MikeEdgar @EricWittmann please comment.

[MikeEdgar]

At high-level, scanning multiple times with different class/package filters sounds like it will work. Be aware that some top-level items are always scanned (e.g. @Schema annotations), so you'll want to also exclude types/beans that may not apply to a particular Application (if needed).

[tjquinno]

I think I found a problem, at least with one particular use case. We're using 2.0.26.

We have a test project that contains several Application classes. Several of them implement getClasses and return the same resource class to reflect that they expose the same API but under different paths according to different @ApplicationPath settings on each.

JaxRsAnnotationScanner$scan invokes processApplicationClasses (which gathers annotation information from the app class) and then invokes processResourceClasses which processes our two resource classes. I have not stepped through every last line of code, but it looks as if the resource class (I've looked at the paths part of the model in particular) is associated with the most recently-processed application class (saved in the context, maybe??).

The resulting OpenAPI model contains paths entries only for that last application.

Two quick comments:

1. Having multiple applications in the project might be a bit odd, and the MP OpenAPI spec explicitly washes it hands of this case. Still, it's not impossible that users would do this.
2. Even without multiple applications in the project, the Application might implement getClasses precisely to limit the resources it wants to expose, even if there are additional ones discoverable in the project. But as written (IIUC) the model associates ALL resources with the one app, despite the getClasses return value.

[phillip-kruger]

Yes I don't think we look at the getClasses at all. We just scan all in the classpath. It might be difficult to implement as we would need to get the classes at runtime. @MikeEdgar w.d.y.t ?

[tjquinno]

In fact, we did something similar in our code which drives the SmallRye OpenAPI code -- we invoke the application's getClasses (and also getSingletons to get their classes as well) and drive SmallRye once for each app and use the config to limit the scanning for each invocation of SmallRye.

The problem we ran into is that our code did not also check the resource methods for POJOs used as input or output parameters. So when we built the include pattern we accidentally hid those POJOs from the scanning and so the model did not include them. I was hoping there was a clever way to just let SmallRye's scanning do its thing in one invocation, rather than invoking once for each app and having to add yet more logic to handle the POJO parameter situation.

This seems like a tricky problem regardless of whether SmallRye itself would handle it or whether the caller would be responsible.

[phillip-kruger]

If we can do it in SmallRye then that would be great. you are welcome to give it a try and do a PR ? The other option is to do this at runtime (like we do the filters).