> Do you have a link for Glassfish virtual hosting
> services?
Look in the Administration Guide regarding HTTP Services.
> Also, who is right--you or the previous reply which
> said to install GlassFish for every domain?
Well, I'm right, of course! :-) I'm always right! Ask anybody...
> I'm confused about how to get GlassFish working for
> each domain. My domains are already set up on a
> managed private server. Installing GlassFish in one
> domain's folder seems logical, desired and
> easier--but how would do what you proposed, access
> applications from existing domains, and get them to
> run GlassFish deployed applications by hitting
> domain-specific URLs? Do I have to modify apache
> files?
I guess I'm confused a little.
By "domain", I assume you mean "example.com" "company.com" "mysite.org", and that you have several of those set up on your current server, correct? That is, you have DNS pointing those domain names to your servers IP address(es), yes?
Glassfish uses the word domain differently. In Glassfish, a domain is an instance of a running server.
So.
Assuming that we're using your definition of domain, as in the DNS name of a host, then this is straightforward.
Each of your domains is pointing to a specific IP address. Some, perhaps all, are pointing to the SAME IP address.
Glassfish has two artifacts that it uses internally to manage domain and hosts: HTTP Listeners and Virtual Hosts.
You bind HTTP listeners to IP addresses and ports, and Virtual Hosts to HTTP Listeners. You can have several Virtual Hosts using the same HTTP Listener.
If you have several domains sharing an IP address, you will create a single HTTP Listener (typically simply leveraging the default one), and several Virtual Hosts.
If you have several domains each with distinct IP addresses, you would have several HTTP Listeners each with a single Virtual Host.
Using a combination of Listeners and Hosts, a single instance of GF can manage several different domains.
Where you will run in to potential problems is if you have several domains hosting similar or identical applications, yet distinct, within Glassfish. The issue is because while Listeners and Virtual hosts break up the namespace for HTTP requests coming in to the server, they do NOT have a similar effect on EJB applications deployed against those hosts. Simply put, the EJB JNDI tree in the server is global and shared across everything deployed within it, regardless of what virtual host that server is connected to (if any -- for example you can deploy an EAR containing nothing but remote Session Beans, and this has no relationship whatsoever to HTTP listeners as, in fact, it's not servicing HTTP requests).
So, that's where deploying several instances of the same application in to the same server can be problematic. A lot of this can be overcome, but it's take a bunch of tweaking of deployment descriptors. But, sometimes, code is written incorrectly and non-portably and can run afoul of this issue.
Finally, if you are not using Apache for anything besides a front door to GF, you can most likely simply eliminate it completely.
For example, say you have Apache running your applications, but it also has some web console on port 10000. If your applications are pure Glassfish (vs a mix of PHP, CGI, and GF), you can tell Apache to stop listening to port 80 but continue hosting port 10000 (your web console), then GF can handle port 80 and all of that traffic.
Really depends on the application mix.
[Message sent by forum member 'whartung' (whartung)]
http://forums.java.net/jive/thread.jspa?messageID=244390