500 Error On README link

[mootzville]

Good Day,

I am interested in testing this project, so cloned it and built it on my dev box (CentOS 8 Stream). I had a few issues getting it to build, but was able to resolve to the point it gets the containers running. Having said that, when I try to hit the link you provide for localhost (I am running on localhost) the server returns a 500. CentOS 8 runs podman by default, so I thought maybe whatever differences there are between podman and docker might be causing the issue, so I spun up an Ubuntu 20.04, and added the 3 dependencies you mention: maven, docker-compose (docker too, obviously), and wget/curl. I was able to build on Ubuntu just fine, yet I still get a 500 error when hitting the link: http://localhost:8080/RESOservice-1.0/$metadata

My best guess is it's a config issue on my end, so wanted to ask are there other dependencies or configurations not documented that may help?

I haven't actually had a chance to shell into the containers yet, so may be able to find some answers there, but I did notice i can't connect to the mysql container using the client on the host. I also noticed the port binding seems to be tcp6, so maybe I need to disable ipv6, so it only binds to ipv4? I wouldn't' think that would make a difference, but exploring all possibilities.

I appreciate your feedback, and can provide better info like debug info once I'm in the office today.

Best Regards!

[darnjo]

Thanks for opening a ticket. We'll look into it and follow up soon.

[michaelpede]

A 500 Error? Interesting. That means there's something listening on port 8080 that would give a 500 error.
Do you have a local webserver running on that port already?

Also, if you're running the build process in a Ubuntu 20.04. Is this another machine, or is it inside Docker?
If it's a Docker container, then that docker container isn't having any of its ports mapped to your localhost by default, you would have to either set that up or use command-line tools in the docker container to verify ITS: http://localhost:8080/RESOservice-1.0/$metadata

Another option would be to use PUTTY / SSH top map ports from your Ubuntu machine to your local machine. (Assuming it's not the same thing)

[mootzville]

@michaelpede To clarify, I installed Ubuntu 20.04 in VirtualBox, and bridged the network connecction to my host machine. Then, I did the following:

1. Install maven
2. Install docker-composer (and docker as well)
3. Installed curl (wget was there by default)
4. Inside the project folder I did 'chmod +x *.sh' for the build.sh and run.sh scripts
5. Ran build.sh
6. Ran run.sh

Once I did all that, it loaded, and the final line from the stdout said the database was connected. So, I did a netstat -tulpn and it showed all the port bindings were there for docker-composer including the 8080 port for hitting the app.

After checking all that, I then tried to open the link provided in the README, and get the 500 message, so I at least know I'm hitting the web server, but I think there is something else wrong that might have something to do with the bash scripts. What distro(s) have you successfully built and ran this on host-wise? I know it shouldn't matter because it's docker, but there may be some subtleties between distros causing the scripts to.fail silently.

Whenever I run into things like this, my first test is to disable selinux and firewalld (I'm usually on RHEL/CentOS), and still got the same result.

I noticed mvn install never seems to get called during the build process either which was showing up in the console output, so I did that manually, and ended up with a target folder and the war file, but there also seems to be a json file missing.

I ran gradle build which completed ok, but thta didn't change the outcome either.

Each time I make a change I delete all containers and iamges, and re-run from scratch, but still haven't figured it out just yet.

I saw an email from you as well, so I'll respond to that also.

Thanks for the help.

[michaelpede]

@mootzville I got your email as well, so will respond to that separately.
I haven't used VirtualBox for a few years, so I'm just getting it going again now.

It seems on my Windows 10 box VirtualBox and Docker are mutually exclusive (VirtualBox hates Hyper-V or something, Docker requires it)

I am using this configuration to run through the install steps, and will let you know what I find.

[michaelpede]

Ok, I'm not sure if this is your problem, but it is a problem.

There seems to be a problem in the DB generation scripts the puts an error message at the top of the file it creates in the sql folder.

that's the command:
java -jar temp/web-api-commander.jar --generateReferenceDDL --useKeyNumeric >sql/reso-reference-ddl-dd-1.7.numeric-keys.sql

is putting:
WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will impact performance. ^M/
At the top of the file: sql/reso-reference-ddl-dd-1.7.numeric-keys.sql

So, before you run ./run.sh check to see if that line is there and get rid of it.

I'll either have to find a way to prune that, or work with the maintainer of the commander to suppress that warning.

That said, the build on a fresh Ubuntu 20.04 (ubuntu-20.04.3-desktop-amd64.iso from Torrent download from Ubuntu website) on VirtualBox can work.

I see it building the files.

One thing that needs to be done is when you install Docker, you should make sure to add the user you will be running the scripts as into the docker group.

The command I used was:
sudo usermod -aG docker $USER

Although I manually replaced $USER with the user I wanted explicitly, since it wasn't the current logged in user.

I also had to wait for ./run.sh to complete, then break it and re-run it a second time, because the DB took too long to import the SQL before the web server tried to access it. Another thing I should try and fix in code.

I'm anticipating this won't solve your issues, however.

In short, after ./build.sh is run it should make a target folder with the following files:
RESODataDictionary-1.7.metadata-report.json
RESOservice-1.0.war

If there's more files, it's because something went right and tomcat expanded the WAR file in there.

[mootzville]

Good Morning, Just wanted to follow up. I have been busy so far this week, but am hoping to get a chance to jump back in on this in the next day or two. I did get things to a point where everything is built properly, and am no getting back a JSON response when I hit the link in the README. The JSON returned is: { "error": "authorization required" } It's not in front of me, so it might not be the exact working in value. So, I'm thinking everything works except the web server container is not completing the authorization when initializing the db connection. I am able to go in and poke around the database, and all the tables seem correct. My next step will probably be to look at the Java to see how the connection is established, and see if hardcoding the auth works instead of pulling from the environment variables. I did follow all the instructions in your previous email, so that all did work to get things built, and I also had noticed the database build issue where you have to kill the containers and restart to get it to load properly. Now just need to figure out this one last piece -- I think... I appreciate the help, and will provide another update once I jump back in. Best Regards, Levi Mootz

…

On Sat, Nov 6, 2021 at 6:39 PM michaelpede ***@***.***> wrote: Ok, I'm not sure if this is *your* problem, but it is *a* problem. There seems to be a problem in the DB generation scripts the puts an error message at the top of the file it creates in the sql folder. that's the command: java -jar temp/web-api-commander.jar --generateReferenceDDL --useKeyNumeric >sql/reso-reference-ddl-dd-1.7.numeric-keys.sql is putting: WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will impact performance. ^M/ At the top of the file: sql/reso-reference-ddl-dd-1.7.numeric-keys.sql So, before you run ./run.sh check to see if that line is there and get rid of it. I'll either have to find a way to prune that, or work with the maintainer of the commander to suppress that warning. That said, the build on a fresh Ubuntu 20.04 ( ubuntu-20.04.3-desktop-amd64.iso from Torrent download from Ubuntu website) on VirtualBox can work. I see it building the files. One thing that needs to be done is when you install Docker, you should make sure to add the user you will be running the scripts as into the docker group. The command I used was: sudo usermod -aG docker $USER Although I manually replaced $USER with the user I wanted explicitly, since it wasn't the current logged in user. I also had to wait for ./run.sh to complete, then break it and re-run it a second time, because the DB took too long to import the SQL before the web server tried to access it. Another thing I should try and fix in code. I'm anticipating this won't solve your issues, however. In short, after ./build.sh is run it should make a target folder with the following files: RESODataDictionary-1.7.metadata-report.json RESOservice-1.0.war If there's more files, it's because something went right and tomcat expanded the WAR file in there. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#14 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA5UCKF443P5VTFE5I33F3LUKXDDRANCNFSM5HNPWTNQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[michaelpede]

{ "error": "authorization required" }

Is correct.
At this point, you need to use a OAUTH 2.0 bearer token.

I am using Specifications derived from:
https://2xx2gy2ovf3r21jclkjio3x8-wpengine.netdna-ssl.com/wp-content/uploads/2020/11/RESO-Web-API-Core-Testing-Specification.pdf

And we do intend to include Postman documentation for the API to make it easy to run against our server, or your own.
Sharing some of mine with:
https://go.postman.co/workspace/My-Workspace~809fdd38-e312-4c9c-875e-b67433767f94/collection/6011818-aa993ffe-228d-40c7-ba99-a669c58bd307

Although I add Environments => Global variables to make these work, it should be fairly straightforward.

The access token you should be able to get is:
reso-test-token

OAUTH 2 credentials:
And the client_is is "reso"
and secret is "secret"

Not meant to be secure...

Hopefully this helps, and please continue to watch this space for more documentation and features.