![]() Virtual URIĪnother thought is to use something like this is as an additional URL that shows up in the TD, properties and forms, but isn't actually it's own listener. No matter which interface you came in and got the TD on, the official location is CanonicalURIBase + path.įor container-container access, it would work, but be inefficient since it would loop around the external interface. If all URLs had that prefix because it was "the official" consumer facing location, that would make sense to be present in all listeners in a servient. One thought I had is if perhaps a "CanonicalURIBase" property would be clearer. eg, it tried to resolve the hostname to an IP address, expecting the IP to be a local interface that it could bind a listen socket to. When I tried to use address as a custom URL, eg '", it failed with EADDRNOTAVAIL. The other challenge, which I think many will run into when using docker or other heroku type systems, is making the servient provide the right URLs in the TD et al. ![]() I added a WOT_PORT so the preference is WOT_PORT (wot specific) | PORT (heroku style generic) | _this.port (wot http config) Base URL Public start ( servient: Servient ): Promise ` ) To make my project work, I changed the code from ![]() So it's actually bound to 5000, wining the race, leaving express to get the error. In the start method of http-server, it's logging that it is going to use the port specified in the http config (8081), but later in the code, in line 121 it gives preference to the PORT env variable if it is present. When I did a curl to 8081, it wouldn't connect.Īfter troubleshooting, it turns out that WOT is fooling us. (this is the same as the rails and other build-packs) When I did a curl to port 5000, i got back the wot servient response, where I expected the Node Express app to be.Ĩ081 is the port I specified in the WOT http config, and where I expected the WOT to be. Port 5000 is the port the build-pack sets in an environment variable that the application will use. (The full heroku buildpack output is here: ) It is heroku compatible and uses the heroku build-packs. In the cloud, I use Dokku, which is a docker based "heroku in a box" that you can run on your own ec2 instance. This all worked fine on my development system, 3000 (express) and 8081 (wot) With the thing embedded in NodsJS, there's two http listeners i a single process. If there's consensus on how to address these, I'm happy to create a PR. When deploying it in the cloud, I ran in to issues with HTTP PORT mapping and the BASE URL for the TD URLs, which required changes to the http-binding to get it working. I wrote an example exposed thing that is hosted in a NodeJS application, using express for the browser UI, and wot for the exposed thing, which is controlled by browserified node-wot. It's really more than a reference implementation. FYI The wot library has a lot of depth to it, it was neat to see the event subscription using the plain http binding just work out of the box.
0 Comments
Leave a Reply. |