Webapp usage

[elopez]

Hi! This is more of a question than an issue. I've been running the development (v2) version and so far it has been working nicely 😄 I do wonder though, how does one use the webapp that is built with rust? I see sometimes the bot gives links (e.g. on queue command), is that it? I also see that the bot listens on two http ports, one always 404's and the other one has those pages. Should I be doing something else to use the webapp?

Thanks for the great bot!

[robinfriedli]

No, the links provided by the queue or search commands (i.e. the paths configured in httpHandlers.xml) are legacy botify 1 http handlers. These run on the port specified by the botify.server.port property. This includes everything in the net.robinfriedli.botify.servers package and will be removed in the final release of botify 2 and fully replaced by the new web app in src/main/webapp and spring rest endpoints in the net.robinfriedli.botify.rest package. The new webapp is running on the port specified by server.port and the index.html file is mapped to the path specified by server.servlet.context-path. Relevant are the following log entries:

INFO  2021-01-04 02:05:27,108 [main] org.springframework.boot.autoconfigure.web.servlet.WelcomePageHandlerMapping: Adding welcome page: ServletContext resource [/index.html]
INFO  2021-01-04 02:05:27,252 [main] org.springframework.boot.web.embedded.tomcat.TomcatWebServer: Tomcat started on port(s): 8080 (http) with context path ''

So when running everything with default settings locally using a properly built jar file or the gradle bootRun task the new webapp should be reachable on http://localhost:8080/. Make sure your browser supports webassembly and webassembly is enabled (Chrome and I presume any chromium based browser / Firefox / Safari should word) and that you've compiled the webapp before building the jar as it is built into the classpath. The authentication page should be reachable (see the instance running on my server) but not much else is implemented as of now.

[elopez]

Thanks for the information! It made things a bit more clear.

I checked again and I see no mentions of WelcomePageHandlerMapping on my logs. I played a bit more on the 8080 port and I see the REST endpoints respond, but it's not serving the static files (src/main/webapp/index.html & the stuff in src/main/webapp/pkg/, right?). From my understanding these end up in src/main/resources in the jar (eg. src/main/resources/index.html) and so the resource handler is not able to find them, as it looks in src/main/resources/resources, src/main/resources/public, etc.)

I now did a quick test with the following, making a public/ folder inside webapp and putting the static resources there, before building the jar:

cd src/main/webapp
cargo make build
mkdir public
cp -r index.html pkg img css public/

And it appears to be working fine 😄 Authentication works fine as well.

[robinfriedli]

No, index.html ends up in /index.html in the classpath root (BOOT-INF/classes/index.html in the jar file). All files in src/main/java, src/main/resources (default for maven / gradle) and src/main/webapp (since it is added to srcDirs in build.gradle) are compiled into the classpath root. Moving the index.html file to a different directory should definitely not be required. WebMvcAutoConfiguration#getResourceLocations also copies SERVLET_LOCATIONS into the array, which is "/", so resources in the classpath root should definitely be found. You can check that index.html is in the classpath root by using the eval command: eval $privileged getClass().getResource('/index.html') should return something like jar:file:/home/botify/botify2/build/libs/botify-1.0-SNAPSHOT.jar!/BOOT-INF/classes!/index.html in which case WebMvcAutoConfiguration$EnableWebMvcConfiguration#getWelcomePage should find the resource /index.html.

[elopez]

Hmm, running that command replies jar:file:/app/botify.jar!/BOOT-INF/classes!/index.html, so the file is there in the jar 🤔 I have no idea why it's not picking it up then. I noticed WebConfig.java doesn't have a @EnableWebMvc like the rest of the Spring examples I find online, is that intended?

[robinfriedli]

Botify uses spring boot, not plain spring. Spring boot provides auto configuration for those things and usage of the @EnableWebMvn annotation would disable the auto config in favour of traditional spring config. From the spring boot documentation:

If you want to keep those Spring Boot MVC customizations and make more MVC customizations (interceptors, formatters, view controllers, and other features), you can add your own @Configuration class of type WebMvcConfigurer but without @EnableWebMvc.

If that was the problem authentication would not have worked as the RestController SessionManagementEndpoint would not have functioned since those beans don't register without spring mvc. Does it not work if you put everything back to where it was, rebuild the webapp and then rebuild the jar? Tried the latest build on macOS, Linux and Windows on Firefox, Chrome and Safari and could not reproduce the issue.

[elopez]

Just tried again, just in case, but it isn't. I'm attaching a log, maybe you can spot something I'm missing. This is with

logging.level.org.springframework.web=DEBUG
log4j.logger.org.springframework.web=DEBUG

botify.txt

The only thing that looks a bit strange to me is this bit, the "/" doesn't have classpath: like the rest of them:

DEBUG 2021-01-05 01:34:15,011 [http-nio-8001-exec-1] org.springframework.web.servlet.handler.AbstractHandlerMapping: Mapped to ResourceHttpRequestHandler ["classpath:/META-INF/resources/", "classpath:/resources/", "classpath:/static/", "classpath:/public/", "/"]

eval $privileged getClass().getResource('/index.html') is still returning jar:file:/app/botify.jar!/BOOT-INF/classes!/index.html so I know the files are there.

[robinfriedli]

Have you tried setting a breakpoint in WebMvcAutoConfiguration$EnableWebMvcConfiguration#getWelcomePage to see what that returns?

[robinfriedli]

Did you get the chance to try it out?

[elopez]

I haven't had the chance yet, I need to set up a new java environment to do that. During my tests so far I have been using the bot I built and ran with docker and kubernetes. I'll see if I can do it this next week, or I can push a branch with the Dockerfile and such that I used if you want to take a look.

[robinfriedli]

Oh you're using Docker? That is indeed something I haven't tested but since I plan and distributing botify 2 as a Docker image it is something I'll look into either way. However, as long as the jar contains the file I still don't see that as a reason why it won't work. Would still be good to know your results when running the application outside of Docker when you get the chance. I'm probably gonna try setting up a Docker environment soon but I've got exams coming up.