GlassFish

What Is GlassFish?

GlassFish is an open-source application server for running Java enterprise applications. It is a reference implementation of the Java EE, and now Jakarta EE, platform, meaning it provides a complete, standards-compliant environment for deploying server-side Java applications built on enterprise APIs such as Servlets, JavaServer Pages (JSP), Jakarta Server Faces, Enterprise JavaBeans, persistence, messaging, and web services. In short, GlassFish is the software that sits on a server and executes Java web and enterprise applications, handling the heavy lifting of the application runtime so developers can focus on business logic.

To place GlassFish correctly, it helps to distinguish an application server from a plain web server. A web server like Apache HTTP Server or Nginx serves static files and forwards requests. An application server like GlassFish goes further: it hosts and runs full applications, managing their lifecycle, providing connection pooling to databases, handling transactions, security, messaging, and the many enterprise services that large Java applications depend on. GlassFish bundles a web container (for Servlets and JSP) together with an EJB container and the rest of the Jakarta EE stack in a single product.

GlassFish has a notable lineage. It originated as Sun Microsystems' open-source application server and served as the official reference implementation of Java EE. After Oracle acquired Sun, stewardship of the platform eventually moved to the Eclipse Foundation as part of the transition of Java EE to Jakarta EE, and GlassFish continues as the open-source Jakarta EE reference implementation under that community governance. It is used both as a development and testing server, because it implements the standards faithfully, and in production by organizations running standards-based Java applications.

It is important to be precise about what GlassFish is. It is server-side software, the runtime environment hosting a Java application, not a browser extension, not a front-end library, and not a CMS. It runs on a server (often behind a front-end web server or load balancer), executes application code, and returns responses to clients. From the outside, GlassFish reveals itself through server-oriented signals such as HTTP response headers, session cookies, default ports and paths, and the technologies it serves, which is exactly the kind of evidence a server-side technology scan examines.

It also helps to understand GlassFish's place among Java application servers. The Java enterprise world has several well-known servers, including Apache Tomcat (a lighter servlet container), Eclipse Jetty, WildFly (formerly JBoss), and commercial options like Oracle WebLogic and IBM WebSphere. GlassFish distinguishes itself as the full-platform reference implementation: it is the server against which the specifications are validated. That positioning makes it especially common in development, education, and standards-focused environments, while heavier commercial servers and lighter containers occupy adjacent niches depending on whether an organization prioritizes vendor support, a smaller footprint, or strict standards conformance.

How GlassFish Works

GlassFish runs as a Java process on a server, hosting applications packaged in standard Java archive formats: WAR files for web applications and EAR files for full enterprise applications. An administrator deploys an application to GlassFish, and the server loads it, wires up its components, and makes it available to handle requests. The server provides the containers and services the application's code expects, so the same standards-compliant application can run on GlassFish or any other compliant server with minimal change.

Architecturally, GlassFish bundles several containers and services. The web container executes Servlets and JSP/Jakarta Server Faces pages that produce HTML responses. The EJB container manages enterprise beans, transactions, and concurrency for business logic. Additional services handle persistence (object-relational mapping to databases), messaging, security and authentication, and web services (both SOAP and REST via the relevant Jakarta APIs). Database access is mediated through connection pools that GlassFish manages, improving performance and reliability under load.

Administration is a defining feature. GlassFish provides a web-based Administration Console, by convention reachable on a separate administrative port, along with a command-line tool called asadmin for scripting management tasks. Through these, administrators deploy and undeploy applications, configure resources like JDBC connection pools and JMS destinations, manage security realms, and monitor the server. GlassFish supports domains and, in its full profile, clustering for running multiple server instances together for scalability and high availability.

When a request arrives, it typically reaches GlassFish on its HTTP listener (a default HTTP port is configured at install, with a separate admin port for the console). GlassFish routes the request to the appropriate deployed application and component, the relevant Servlet or framework, which executes, perhaps consulting a database through a connection pool and running within a transaction, and produces a response. For stateful interactions, GlassFish manages HTTP sessions, issuing a session identifier to the client so subsequent requests are associated with the same session.

From a delivery standpoint, these mechanics produce externally observable signals. The server can identify itself in HTTP response headers, the session-management layer issues a recognizable session cookie, and the underlying request comes through the GlassFish HTTP listener, often fronted by Grizzly, the NIO framework GlassFish uses for its networking. The applications GlassFish serves frequently expose Java-oriented URL patterns and file extensions. All of these are visible from the outside, which is why GlassFish, like other Java application servers, is detectable even though it is back-end infrastructure rather than client-side code.

How to Tell if a Website Uses GlassFish

GlassFish exposes several server-side fingerprints. StackOptic inspects these from the server side, and you can verify the same signals by hand with curl, browser DevTools, or a detection extension. Because GlassFish is back-end software, the most reliable clues come from HTTP headers and cookies rather than from rendered page content.

The Server response header. The most direct signal is the HTTP Server header. A GlassFish server may identify itself with a value such as GlassFish Server (sometimes with a version) or, reflecting its networking layer, a Grizzly-based value. Running curl -I and reading the Server header is the first thing to check.

The JSESSIONID cookie. Java application servers, including GlassFish, manage sessions with a cookie named JSESSIONID. Seeing a Set-Cookie: JSESSIONID=... in the response is a strong indicator that a Java servlet container (such as GlassFish) is behind the site, though it does not by itself distinguish GlassFish from Tomcat or other Java servers.

X-Powered-By and related headers. Some Java applications and servers emit an X-Powered-By header advertising a Servlet/JSP capability or framework, which reinforces that a Java application server is in use.

Java URL patterns and extensions. Applications served by GlassFish often expose Java-oriented URLs, for example paths ending in .jsp, .do, or .action, or containing ;jsessionid= appended to the URL when cookies are unavailable. These patterns point to a Java back end.

The admin console and default ports. GlassFish's Administration Console runs on a separate administrative port by default, and the server has conventional default HTTP and admin ports. While production deployments are usually fronted by a web server or firewall that hides these, an exposed admin console or a recognizable default-port banner is a clear GlassFish tell.

Method	What to do	What GlassFish reveals
curl -I	curl -I https://example.com	The Server header (GlassFish/Grizzly), Set-Cookie: JSESSIONID, X-Powered-By
Browser DevTools	Open the Network tab and inspect response headers and cookies	The same headers plus the JSESSIONID cookie under Application/Storage
View Source / URLs	Look at links and form actions	Java extensions like .jsp/.do and any ;jsessionid= in URLs
Wappalyzer	Run the extension on the live page	Identifies GlassFish (or a Java application server) under web servers
BuiltWith	Look up the domain	Current and historical Java application-server detection

A fast terminal check is curl -sI https://example.com | grep -i "server\|jsessionid". A GlassFish or Grizzly value in the Server header is strong evidence, and a JSESSIONID cookie confirms a Java servlet container is present. For the full approach, see our guides on how to find out what server software a website runs and how to read a website's HTTP headers. Because GlassFish runs Java, the techniques in how to find out what programming language a website uses help confirm the back end as well.

A few practical caveats matter here. Security-conscious operators frequently suppress or rewrite the Server header and strip X-Powered-By to avoid advertising their stack, and most production GlassFish deployments sit behind a reverse proxy (Nginx, Apache, or a load balancer) whose headers may mask the application server entirely. In those cases the JSESSIONID cookie and Java URL patterns become the more durable clues, since the application still relies on them. No single signal is guaranteed, so the strongest approach combines several: a Java session cookie, a Java-flavored URL or extension, and any surviving server-identifying header together build a confident verdict. Server-side analysis is well suited to this because it fetches the raw headers and cookies directly, where these back-end fingerprints live, rather than depending on rendered page content.

Key Features

• Full Jakarta EE platform. A complete, standards-compliant implementation of the enterprise Java APIs, serving as the reference implementation.
• Web and EJB containers. Runs Servlets, JSP/Jakarta Server Faces, and Enterprise JavaBeans in one server.
• Administration Console and asadmin. A web-based admin UI plus a scriptable command-line tool for deployment and configuration.
• Connection pooling and resources. Managed JDBC connection pools, JMS messaging destinations, and other enterprise resources.
• Clustering and high availability. Support for multiple instances and clustering in the full profile for scalability.
• Standards conformance. Faithful implementation of the specifications, ideal for development, testing, and standards-based production.
• Open source. Community-governed under the Eclipse Foundation with no licensing fees.

Pros and Cons

Pros

• A complete, standards-compliant Jakarta EE environment in a single open-source package.
• Excellent for developing and testing against the official reference implementation.
• Built-in administration tooling, connection pooling, and enterprise services.
• No licensing fees, with community governance under the Eclipse Foundation.

Cons

• Heavier than a lightweight servlet container like Tomcat for simple web applications.
• A smaller production footprint and community than some alternatives such as Tomcat or WildFly.
• Full enterprise capabilities add configuration and operational complexity.
• Organizations needing vendor support often turn to commercial servers or supported distributions.

GlassFish vs Alternatives

GlassFish competes with other Java application servers and servlet containers. The table clarifies its position.

Server	Type	Standout strength	Best for
GlassFish	Full Jakarta EE app server	Reference implementation, standards-faithful	Development, testing, standards-based apps
Apache Tomcat	Servlet/JSP container	Lightweight, ubiquitous	Web apps not needing the full EE stack
Eclipse Jetty	Lightweight servlet container	Embeddable, small footprint	Embedded and microservice use
WildFly	Full Jakarta EE app server	Feature-rich, active community	Enterprise apps wanting a full server
Oracle WebLogic / IBM WebSphere	Commercial app servers	Vendor support, enterprise tooling	Large enterprises needing commercial support

If headers suggest a different Java server, the same signals distinguish it, the Server header value, the presence of JSESSIONID, and default paths all help. Because Java application servers share the JSESSIONID convention, recognizing the broader stack matters; you can compare server fingerprints alongside front-end components like the FullCalendar scheduling library to build a fuller picture of an application.

Use Cases

GlassFish is most at home running standards-based Java enterprise applications. Development teams use it as a faithful reference implementation to build and test Jakarta EE applications, confident that standards-compliant code will behave correctly. Educational settings use it to teach enterprise Java because it implements the specifications completely and is free.

It also serves organizations running internal enterprise applications, business systems that rely on EJBs, transactions, messaging, and connection pooling, and teams that prefer an open-source, standards-focused server over a commercial product. Because it bundles the full platform, it suits applications that genuinely use the broader enterprise APIs rather than just servlets.

From a competitive-research and lead-qualification perspective, detecting GlassFish, or any Java application server, on a site is a meaningful signal about the organization's technology choices. It indicates a Java-based, often enterprise-oriented stack, which can inform how a vendor positions a product or how an analyst profiles a company's engineering maturity. Translating these technology footprints into actionable insight is the core idea behind using tech-stack data to qualify leads.

A few concrete examples illustrate the fit. A software team building a standards-compliant enterprise application might run GlassFish in development to validate against the reference implementation before deploying to a supported server in production. A university computer-science course might standardize on GlassFish so students learn Jakarta EE on the canonical platform. An organization committed to open-source infrastructure might run GlassFish in production for internal business applications that use the full enterprise stack. In each case the common thread is a Java, standards-first approach to server-side software.

Frequently Asked Questions

Is GlassFish still maintained in 2026?

Yes. GlassFish continues as the open-source reference implementation of Jakarta EE under the stewardship of the Eclipse Foundation, following the migration of the platform from Java EE to Jakarta EE. It remains relevant for development, testing, and education because it tracks the specifications closely, and it is used in production by organizations that favor a standards-focused, open-source application server. As with any platform, teams should run current, supported releases.

What is the difference between GlassFish and Apache Tomcat?

Tomcat is a lightweight servlet and JSP container, it runs web applications built on Servlets and JSP but does not include the full enterprise Java stack. GlassFish is a complete Jakarta EE application server that bundles a web container together with an EJB container and the rest of the enterprise APIs (persistence, messaging, transactions, and more). Choose Tomcat when you only need a servlet container, and GlassFish (or another full server) when your application genuinely uses the broader enterprise platform.

How can I tell if a website runs on GlassFish?

Start with HTTP headers: run curl -I URL and look at the Server header for a GlassFish or Grizzly value, and check for a Set-Cookie: JSESSIONID cookie, which indicates a Java servlet container. Java-style URLs (ending in .jsp or .do, or containing ;jsessionid=) reinforce a Java back end. Note that production sites often sit behind a reverse proxy that masks the Server header, so combine signals, and tools like Wappalyzer and BuiltWith can also identify a Java application server.

Does a JSESSIONID cookie always mean GlassFish?

No. JSESSIONID is the standard session cookie name used by Java servlet containers in general, so it indicates that some Java server, GlassFish, Tomcat, Jetty, WildFly, or another, is behind the site, but not specifically which one. To narrow it down, combine the cookie with the Server header value and any other server-identifying clues. The presence of JSESSIONID is a reliable sign of a Java back end, while the Server header (when not hidden) is what distinguishes GlassFish from its peers.

Why is GlassFish often used in development rather than production?

Because GlassFish is the reference implementation of Jakarta EE, it implements the specifications faithfully, which makes it ideal for developing and testing standards-compliant applications, you can be confident the platform behaves as the specs intend. In production, some organizations prefer servers with commercial vendor support, a smaller footprint, or particular operational features, so they may deploy to Tomcat, WildFly, WebLogic, or WebSphere. That said, GlassFish is also used in production by teams that value an open-source, standards-focused server.

Want to detect GlassFish and the rest of a site's technology stack instantly? Run any URL through StackOptic at https://stackoptic.com.