I've thought about this some more and concluded that what you are seeing is the expected behaviour.
Notice that both the "server" and "__asadmin" virtual servers share the same hostname "${com.sun.aas.hostName}", as per their declarations in domain.xml:
<virtual-server hosts="${com.sun.aas.hostName}"
id="server"
http-listeners="http-listener-1,http-listener-2"/>
<virtual-server hosts="${com.sun.aas.hostName}"
id="__asadmin"
http-listeners="admin-listener"/>
The only way the 2 virtual servers are distinguished is via the HTTP listeners they are associated with: If a request with a hostname equal to "${com.sun.aas.hostName}" is received by the "admin-listener", it is forwarded to the "__asadmin" virtual server. Likewise, if a request with the same host name is received by either "http-listener-1" or "http-listener-2", it is forwarded to the "server" virtual server.
Notice that the JSESSIONID cookie, or any cookie for that matter, contains "Host" and "Path" attributes, but no port number.
Therefore, if you login to the admingui (deployed at "/"), a session is created, and a corresponding JSESSIONID cookie with the following attributes is returned to the client:
Name: JSESSIONID
Content: <session id>
Host: "${com.sun.aas.hostName}"
Path: "/"
If you then connect to your own webapp deployed at "/" on the "server" virtual server (by connecting to the port of either "http-listener-1" or "http-listener-2"), the client (browser) will include the above cookie with the request, since it matches both the request's host and path.
However, the session manager associated with your webapp knows nothing about the JSESSIONID specified in the cookie included with the request, so it creates a new session (with a new session id) and returns it to the client, overriding the above cookie that was cached by the client.
If you connect to the admingui again, the client will include the overridden cookie (i.e., the cookie corresponding to your own webapp) with the request, but since the session manager associated with the admingui knows nothing about the JSESSIONID specified in this cookie, it will go ahead and create a new session.
So what you are seeing is caused by a limitation of HTTP cookies, which are distinguished only by a combination of host name and path, but not port number.
Hope this helps.
Jan
[Message sent by forum member 'jluehe' (jluehe)]
http://forums.java.net/jive/thread.jspa?messageID=237893