Openapi-ext getting an error with ApplicationPath = "/"

[rhuan080]

Hi,

The css and javascript from Openapi-ext is getting an error when I configure the ApplicationPath from JAX-RS to "/". This is an example.

@ApplicationPath("/") public class RestApplication extends Application {}

These are the URL is getting error (404):

http://localhost:8080/webjars/swagger-ui-themes/*

I have seen the CSS and JS come from a swagger-ui jar that is dependency.

I have seen the openapi-ext has the OpenApiService that read html template and css from classloader. I think the same can be done to fix this problem.

[phillip-kruger]

Hi Rhuan. Thanks for the bug, a fix would be appreciated :)

[rhuan080]

Hi,

Thank you! :)

I will work on it.

[phillip-kruger]

What implementation are you using when you get this bug ?

[rhuan080]

Thorntail.

[phillip-kruger]

So this is a combination of context-root being / and application path being /

You will see in the example app in the pom under the thorntail profile that I explicitly set the context root:

                        <configuration>
                            <properties>
                                <thorntail.context.path>/${project.build.finalName}</thorntail.context.path>
                            </properties>
                        </configuration>

But if you have no context root and JAX-RS monitor all trafic under /, webjars can not 'kick in'.

You PR is the right approach, meaning that we server that static content via the server, but I would rather use JAX-RS to do that, than using Servlet. We are already using JAX-RS to serve the HTML UI page.

So I added this peace of code (also please see the PR and let me know there:

@Path("{path: ^webjars\\/.*}")
public class StaticResourcesService {

    @GET
    public Response staticJsResources(@PathParam("path") final String path) {
        try (InputStream inputStream = this.getClass().getClassLoader().getResourceAsStream(String.format("META-INF/resources/%s", path));
                BufferedReader buffer = new BufferedReader(new InputStreamReader(inputStream));
                StringWriter stringWriter = new StringWriter()) {
            buffer.lines().forEach(stringWriter::write);

            String response = stringWriter.toString();
            if(response!=null && !response.isEmpty()){
                return Response.ok(response).build();
            }
        } catch (IOException ex) {
            log.severe(ex.getMessage());
            return Response.status(Response.Status.INTERNAL_SERVER_ERROR).build();
        }
        log.log(Level.WARNING, "Could not find resource [{0}]", path);
        return Response.status(Response.Status.NOT_FOUND).build();
    }

[phillip-kruger]

See #9

[rhuan080]

Hi @phillip-kruger

The problem is the JAX-RS works with an Application that could change the path. Look this example.

@ApplicationPath("/api") public class RestApplication extends Application {}

Thus the URL will be {server}/{contextRoot}/{applicationPath}/webjars/*

Then I used Servlet to solve that.

Another question is this peace of code does not treat requests to Files (such as PNG).

[phillip-kruger]

This:

Thus the URL will be {server}/{contextRoot}/{applicationPath}/webjars/*

still works fine. (default webjars behaviour) - You can test to confirm, but that is what the example is doing

There is not PNG in the webjars (that we are interested in at least) - only css and js.

Do the above code work for your Use-case ?

[rhuan080]

--> still works fine. (default webjars behaviour) - You can test to confirm, but that is what the example is doing

I think all requests could be answered in the same way. I think it make the maintenance easier.

About my user case I will make tests soon.

About the PNG, I have seen some PNGs inside org.webjars.swagger-ui.{version}.

[phillip-kruger]

There is no maintenance in the default webjars case as ot works out of the box. The images in the jars are screenshots from the project and we do not need them. In fact we should get rid of them as they just make the artifact very fat

[rhuan080]

@phillip-kruger Ok.

[phillip-kruger]

Thanks for you help. I appreciate it.