Of course you can consider using the new GlassFish 3.1 because it is operations-friendly with full clustering and centralized admin or because it offers a great developer environment with fast startup, a modular architecture or application versioning but I’d like to argue that the GlassFish value is greater than sum of the parts and a devops appserver. Today.
In fact GlassFish is pursuing what it’s been doing since version 2.x: hit a middle ground between the requirements from developers (latest APIs, lightweight runtime) and those from operations (manageable, stable, centralized admin). Here are some features which I believe to be relevant to developers, operations and QA :
• Fast startup: whether you’re developing, testing or deploying an application, the time it takes to bring a service online is critical. GlassFish has had this for a while (even before 3.0) but the full modular architecture offers yet greater flexibility.
• Embedded API: while the new standard
EJBContainer API is a great step forward, it mostly addresses the unit testing use-case while this feature offers an API to drive the entire set of GlassFish services and features.
• Maven plugin: easily integratable into your favorite continuous integration server. In a continuous deployment scenario and generally for automation, Maven and CI’s are key tools to rely on.
• Domain-driven administration: the concept of a domain has been around for a while in GlassFish and with 3.1 the entire admin tools (CLI, Web and REST) scale from a single instance development or production config to a full multi-cluster environment. This makes for easy transfer of work from development to QA and/or to production and back.
• More questionable features (wrt Devops) are active redeployment and application versioning. While the former is recommended only in development the versioning feature can be used in many different ways for testing and potentially in production (with the caveat that only one application version can be active at a given point in time).
Of course there’s much more to devops than just a product or technology. Is your application server devops-friendly?