News: Choosing a Glassfish Profile

  1. Choosing a Glassfish Profile (1 messages)

    Alexis Moussine-Pouchkine has written a post on choosing one of the three Glassfish profiles - developer, cluster, and enterprise (with enterprise being available through SJSAS 9.1). Basically, the developer profile disables the security manager, a GMS heartbeat, session replication, and clustering. It also provides a quick startup (by deferring services until they're requested.) This profile is built by using the "setup.xml" created when Glassfish is first unpacked. The cluster profile (created with "setup-cluster.xml") adds session replication and cluster creation, obviously enough, and enables the GMS heartbeat (which is part of availability provisioning). The enterprise profile, available from SJSAS 9.1, uses the NSS keystore, provides a security manager, and patch support to the clustered edition of Glassfish. Glassfish is growing by leaps and bounds, from all accounts. Have you used it? What's your opinion of the server?
  2. Re: Choosing a Glassfish Profile[ Go to top ]

    I've always thought that "Developer" profile was a bit of a misnomer. It's more a "single machine" profile. You can run GF Developer in production all day long. The profiles will get even more complicated with GFv3 and their more modular architecture, thus being able to deploy "just what you want". But in truth that's going be more an impact on disk space than anything else, and GF isn't the huge to begin with. But I'm a big fan of GF. It works, it works well, it's easy to use, the community is great, and bugs get fixed pretty quickly. The source code is legible, usable, and accessible, though I've never actually built it myself. I've just debugged with it. I think it's a little memory heavy, in that I would like to see it use less memory. This is more important as more and more folks go with VPS style servers, and the "value" packages tend to be skimpy on memory (128MB and under being really common). I'd like to think that v3 will help that, but it's hard to imagine that the idle services are really consuming that much memory, being as v2 already dynamically starts them up as necessary. I'd like to think that "tomcat with session beans" (which we'll probably get with EJB 3.1) shouldn't be THAT much more expensive than simple WARs. And while a lot of folks use EJB to it's full extent, a lot more don't. With JEE5 and EJB3, JEE is more accessible and easy to use than ever. "Tomcat with session beans" is simple to do, and works really well. But right now, we pay a penalty in memory for that, at least with GFv2. But, for all intents and purposes you won't find a better out of box experience than with Glassfish, at least at its price range. Netbeans with Glassfish is particularly powerful and easy to use. I recommend it highly to anyone looking at service software in this space.