Right. A cookie has only one domain. And the static or dynamic method you mentioned is wonderful if your web app only works on 1 domain but do not solve my problem / question.
In addition, IMO logically there is no reason why GlassFIsh or any product should have this restriction. Incoming requests should be able to come through whatever domains are mapped to the server + port and GlassFish listens to... .
Sun OpenSSO which was formerly Sun Java System Access Manager allows for the user to specify multiple domains and either:
a) Matches the best match to those domains of the request when constructing its cookie
OR
b) Sets cookies for all the domains (and the web browser would reject the ones were in the domain does not match the request server name)
I am not sure if the product does a) OR b) but what surprises me a bit is that GlassFish isn't more robust in allowing you to support multiple different domains for the same web app.
In any event, I have the source now and am looking to develop a tweaked version of the request.java class in 3.0.1 b22 that allows us to support our requirements. It's either that or having to figure out a Sun Web Server 7.0 RP funky rule to re-write the jsessionid header.
Thoughts welcome... .
[Message sent by forum member 'ngsunw']
http://forums.java.net/jive/thread.jspa?messageID=477305