Okay, so I think I've figured out how to do this, based on a hint in this article here. You actually need to use a proxy server. This will be different for people running different servers, but since mine is Apache2, I was able to find a relatively simple guide here. What I did was set up a proxy server on port 9000, which redirects to port 9999 (where Blazegraph is located). After doing this, the Wikidata Query Service GUI actually returns results! However, the links are a bit wonky still, so some formatting needs to be done.

After finally figuring out the other error, as documented here, I'm back at this error again, with the CORS issue. Any thoughts?

So it appears that there was something, somewhere which was still connected to the previous Maven instance, and resetting the whole server worked in order to get Blazegraph itself running... however, I'm just back at square one, being unable to set CORS so that the Wikidata Query GUI can access the Wikidata Query Service. It's the same as what I've documented here, so I'll return over to that thread.

I haven't found a solution. I have tried rebuilding things from scratch multiple times encountering different, seemingly unrelated, errors each time. I think it's still useful for this to be considered, however, so a solution should still be sought after. For the time being, I am focused on one of those different errors which I've documented here.

This bug continues to be pervasive... just in case, I've attempted several tests with mvn install, mvn clean install, and mvn package. mvn package runs without error, but the other two each produce the following error:

So I've pulled apart the logs of mvn install clean, mvn install, and mvn package in the ./wikidata-query-rdf directory, and it turns out that it is deleting the jetty-servlets-9.4.12.v20180830.jar in ./wikidata-query-rdf/war/target/blazegraph-service-0.3.111-SNAPSHOT/WEB-INF/lib, as indicated with the following trace output:

Attempted another solution, listed here, still no dice. This potential solution involved:

I tried one other potential solution, as listed here:

I have attempted to change each web.xml to include the following, but it still isn't functional (same errors):

Additional information: so when I copy and paste the URL http://localhost:9999/bigdata/sparql?query=SELECT%20*%20where%20%7B%3Fa%20%3Fb%20%3Fc%7D%20LIMIT%2010 into the browser, it spits out valid XML, it just doesn't when the request is made from the GUI, which results in a net::ERR_FAILED 200, which I believe is a CORS issue.

For the most part, this is now resolved. Because I was tunneling into the instance remotely, I needed to use:

@Addshore I'm confused by your link (https://doc.wikimedia.org/Wikibase/master/php/md_docs_topics_options.html#conceptBaseUri); so if I want to change the URIs from the default http://wikibase.svc/entity/Q39 to localhost:8181/entity/Q39, I do this by adding something to LocalSettings.php?

This is my current YAML (it still isn't working):

Okay, wow I'm dumb. Running this inside the wikibase WDQS docker container made queries work:

@Addshore so sorry to keep bothering, I'm just trying to make sure I'm following everything correctly.

@Addshore yeah so I was so knee deep in errors, I deleted everything with my first try and attempted to use this Git directory instead: https://github.com/wmde/wikibase-docker/blob/master/README-compose.md

@Addshore thank you so much for the response. I ended up deleting everything and attempted to follow a different set of Wikibase install instructions (except now post-load runUpdate.sh just runs forever (even though there is very little that I added to the database); localhost:8282 queries are stall forever.

@Addshore thank you so much for responding!

@Louperivois I've run into the issue of docker_compose_files_wdqs-updater_1 crashing and restarting constantly as well.