rdf4j
rdf4j copied to clipboard
eclipse-rdf4j
rdf4j server / workbench self-contained executable
Instead of / in addition to the WAR file and the docker image, we should look into distributing Rdf4j Server / Workbench as a self-contained executable that can be downloaded and immediately spun up without having to install a servlet container separately.
Several options I guess, e.g.
- try to use Spring Boot to generate a fat jar
- or replace the current Spring thingies with e.g. something implementing Eclipse MicroProfile
- or Quarkus / Micronaut
- or use GraalVM to build a native app (probably not the best option, native app would be more useful for the console)
Fwiw I've started looking at building a spring boot app in my spare time. My wife hates me but it might come together.
I have a decent amount of experience with spring boot, if you have any questions :)
Ah yes, this dropped by the wayside a bit I'm afraid. I'll see where I left off.
(yet) another somewhat related idea from the gitter chat: using jetty instead of tomcat for the war (https://www.baeldung.com/deploy-to-jetty)
Fwiw I've started looking at building a spring boot app in my spare time. My wife hates me but it might come together.
Jeen, are you still working on it?
Fwiw I've started looking at building a spring boot app in my spare time. My wife hates me but it might come together.
Jeen, are you still working on it?
Not really, as with so many good intentions, this one got overrun by the reality of there only being 24 hours in a day...
Ha, I know this problem. I'm itching to do it, but there's actually no time. However, would there be tests available that test the REST endpoints?
Ha, I know this problem. I'm itching to do it, but there's actually no time. However, would there be tests available that test the REST endpoints?
There are some controller tests available in the rdf4j-http-server and rdf4j-http-server-spring modules, but the more comprehensive testing is probably done in the compliance/integration tests in rdfj4-repository-compliance, which test the HTTPRepository and the SPARQLRepository against a running RDF4J Server.
GraalVM starts to look a bit more interesting since Oracle is contributing the community edition to openjdk, and Spring (6 ?) is actively working on fully supporting it.
That being said, we now also have a spring server, so perhaps this is issue is not that relevant anymore ?
@hmottestad @barthanssens Out of curiosity, what would be the recommended way to go about trying to package a single server executable nowadays? Would it still be some wrapper or rewrite of the server into spring boot, or is there a better way? Very interested in making this happen one way or another for employing a more cloud-native deployment strategy that isn't playing very nicely will the whole "application server" paradigm of Tomcat unfortunately.
Was looking into embedded tomcat or jetty but wasn't quite sure if going down that route would be more troublesome than just sinking the time to make spring boot work.
Spring Boot would be my recommendation. You would end up with a single jar file. I think the amount of work required to migrate the server/workbench to spring boot would probably not make it worth it. Maybe there is some middle ground where we can inject our spring stuff directly into spring boot?
At the moment I would recommend using the docker image if you don't want to mess around with your own Java container stuff. I would think that many use cases for a single executable file could be solved by using docker.
Yea migrating sounds like quite a large undertaking for sure. Ya docker is certainly an option in the future, but at the moment it isn't attainable with the target environment / current deployment + service archetype. I was looking into maybe something even like jetty-runner which still operates on a war but the lifecycle of the application server is still tied to the lifecycle of the servlet.
Eh, I'll try to carve out some time to experiment and update this thread if I get something working!
Well, you could use embedded Jetty for the server (workbench has an issue with 10/11/12, server should work IMHO) or something microprofile-based, but nowadays springboot-in-a-docker-in-the-cloud seems to be "the" way to go (or quarkus in Redhat-environments)
Just a little update. I've been looking into this a bit in my free time and got a (very) hacky test just to see how difficult integrating Spring Boot would actually be. It looks like we can leverage almost all of the current Spring MVC code and hook with @RestController—converting beans to java from xml (you may be able to keep the xml; however, I haven't looked into it).
You can find the code here: https://github.com/benherber/rdf4j/tree/experinment/simple-sb-app (I'm now realizing I cannot spell but alas)
If this is a direction the maintainers would be willing to go in, I'd be happy to do it (it makes my life extending server code MUCH easier :) ). This process would not change the APIs / Protocol version, and should still create war build artifacts to integrate with pre-existing vanilla deployments, but has the added benefit of also creating self-contained executables and being more extensible in the longer run (hopefully 🤞).
The way I would think about going about it would be something akin to the following:
- Simplest MVP delegating request handling from rest controller methods to the original Spring MVC implementations
- Migrate the server tests to use
MockMvcand beef them up to catch any regressions - Slowly migrate controllers to the more Spring-Boot declarative approach (maybe eventually leveraging
springdocto keep the openapi spec up-to-date)
They may be some pie-in-the-sky dreams at the moment, but it's much more achievable than I had first thought it to be. Please let me know any thoughts, comments, or concerns or how you think it best to proceed. Thanks!