Hi Chuck, > The more I think about this, the more it seems that something > is fundamentally wrong here. :-/
> According to AWWW[1], "Assign distinct URIs to distinct resources." > > So if an application is the thing that manages a set of > resources (i.e,. a URI space), having it attached to multiple > virtual hosts guarantees that your resources will not have > distinct URIs. REST/HTTP perfectly allows multiple URIs to point to the same resource. For example, you could have a virtual host accepting translated domain names like www.mysite.org and www.monsite.org. Other useful cases are when you want to support "localhost" access by IP address, etc. This is useful to flexible in these cases for development and pre-production. > I'm also wondering if the baby's being thrown out with the > bathwater here. Just because some people want to attach an > application to multiple virtual hosts doesn't rule out the > case the some people will only ever attach an application to > a single virtual host. Actually, the virtual hosting we support is even more flexible as we take into account the following attributes when determining if a request matches a given virtual host: - hostRef (hostDomain + hostPort + hostScheme) - resourceRef (resourceDomain + resourcePort + resourceScheme) - serverInfo (serverAddress + serverPort) As a result, we are even able to properly route requests for resources with URIs like "urn:isbn:..." submitted via HTTP. This is more flexible than Apache HTTP Server's virtual hosting support, and hopefully it doesn't compromise RESTful design. > Perhaps its worth revisiting the way virtual hosting is being > handled. Or maybe I'm misunderstanding who is repsonsible > for managing an application's URI space. The URI space is managed by both the virtual hosts and then by the applications. If the resource URIs don't match the host URI (like for the URN example given above), then the resource URI space is entirely managed by the application. > As for using the application's context in web.xml - that's > just plain ugly; everytime I deploy, I have to unwrap my war > so I can modify web.xml to change hostname and port info. > (Deployment-specific config info just shouldn't be in web.xml) Hmm, that's true. > Oh well, for now web.xml will have to do for a temporary solution. Another strategy would be to initialize your application upon first request. You can override the "init(Request, Response)" method on your Application class for this purpose. Just remember to check whether the application is already started and to call super.init() when you are done with your initialization. Hope this helps, Jerome
