Port concept overloaded on Heroku

[GoogleCodeExporter]

Applications on Heroku are expected to bind to a port on the interface where 
they are running, and this private & dynamic port is provided to the 
application via the $PORT environment variable. Heroku's routing infrastructure 
then routes connections on the standard port 80 to the application running on 
that private port. So the application is binding to the private & dynamic port, 
but any external client must send requests to port 80.

Unfortunately, WattDepot's underlying assumption is that the configured port is 
used both for binding and for connections from clients. This causes problems 
because the port number is used in at least 3 places: by the Server to decide 
what port number to bind to (on Heroku this is the private port # given by the 
$PORT environment variable), the announced URL of the server to the public 
(always 80 on Heroku, though usually left out of URI to default to 80), and the 
URI of parent resources such as a Source in a SensorData resource (should be
the public port on Heroku). If the URI given inside the SensorData resource 
does not match the URI used in the PUT of the resource, WattDepot will complain.

This is confusing and requires kludges like a special case in the 
ServerProperties.getFullHost() method. These two concepts should be separated 
for Heroku: the private port which is only used to bind the Server, and the 
public port, which is always 80.

Original issue reported on code.google.com by rbre...@gmail.com on 20 Aug 2012 at 3:45