> The VirtualHost Support of GlassFish is obviously an
> administrator's burden no one can take. This is to
> the fact, that GlassFish is full of bugs.
You mean that Virtual Server Support in GlassFish is full of bugs? GF v2.1 or GF v3?
> The V2.1 only appends the jsessionid to the url, if
> the particular app runs either in context root / or
> if the main applett carries the same name as the
> package itself (war-file-name).
>
> If you have to deny cookies for security reasons
> you'll go precisely through a surprise.
What does this have to do with virtual servers? How is this a bug? How is this a security issue?
In my experience, Virtual Servers in GF v2 Just Works, and that's what Wolfram is talking about for your issue.
Virtual Servers are where you have a single GF instance serving up content as different Hosts. HTTP v1.1 includes a Host header field on every request, and GF (among other servers) uses that to route requests to the proper "virtual host". You don't need to set up any extra instances or ports or anything.
You create a new Virtual Server, and you tell it what domain, or list of domains, it will be responding too (e.g. example.com).
You then tell that Virutal Server which listener (or listeners) to use, and here you would likely use the default http-listener-1 (which listens to 0.0.0.0:8080 by default, or if you changed it, likely 0.0.0.0:80, which means "all IP addresses for this host on port 80").
Once you have the Virtual Server configured, you can then deploy your web apps.
When you deploy a web app, if you don't specify a Virtual Server, GF deploys it to "all of them". If you happen to deploy 2 Web Apps both configured for the Root context, you will get an error when you try to deploy the second one, since the root context is "already taken".
Thus, you need to target your WAR deployment to a specific Virtual Server.
And, that's it! GF handles the rest.
No new IPs, no new ports, nothin. Works a treat. It's simple and straightforward to configure.
Two issues that I've had in the past is that GF won't let you put a "non-exisitent" host in the list of host for the Virtual Server (i.e. if DNS doesn't know about that host, you'll get an error). Also, that list of hosts couldn't have any white space (i.e. "example1.com,example2.com" was OK, but "example1.com, example2.com" was not).
The first issue is an FYI, I won't call it a bug, just, perhaps, a feature I don't care for. The second is a "bug", and I recall logging it, and it may well be fixed by now. If not, it's not a big deal. Just FYI on that.
JSESSIONID shouldn't be a problem, but I don't know. If you can "share" a JSESSIONID across Virtual Servers, then I'd log that as a bug. I doubt that's happening (since JSESSIONID is tied to the actual web app which is a different layer of the server), but if it is, that would be interesting information. I haven't tested it so I can't say.
[Message sent by forum member 'whartung' (whartung)]
http://forums.java.net/jive/thread.jspa?messageID=349214