I'm assuming you followed this tutorial.
If you mean good old trusty Apache httpd, you won't be able to deploy the project you created to that server, what you create is a Java Enterprise application (and more specifically a WAR, a Webapplication ARchive), and you will need a server capable of deploying that type of applications - like of course Glassfish, but also Apache Tomcat, jetty or any of the Java Enterprise Edition servers
Still assuming that you're talking about Apache httpd, that one and Glassfish are entirely different beasts that serve different purposes, Glassfish is indeed capable of serving up content over http but it contains much more functionality than that, see the above Wikipedia link on Java EE for more links and pointers.
EDIT: you cannot run a servlet container like Tomcat or a Java EE server like GlassFish "inside" an Apache server like you would run php "inside" Apache with mod_php, but it's quite easy to run them alongside each other, where the Apache httpd server is the one that faces outward and basically forwards calls to the backend Java server. There are several techniques to achieve this result, the most popular is probably using mod_jk as explained here for Tomcat and here for Glassfish. Alternatively you could setup mod_proxy, a comparison of these two scenarios here on SO.
Anyways, it's not always necessary to front a Tomcat or Glassfish with an Apache but it may be needed e.g. if the website is serving hybrid content partially written in php or another apache-hosted scripting language or useful to avoid using the servlet container to serve up massive quantities of static content, often not their strongest point. For many applications it's perfectly OK to have a Tomcat or a Glassfish serve up all content avoiding the extra complications introduced by mod_proxy or mod_jk and the dual management of both servers.