Posted by kohsuke
on April 28, 2008 at 2:34 PM PDT
Now you can embed GlassFish v3 in any existing JVM and run it from there. This enables a whole range of possibilities.
I've always liked Jetty's ability to run inside an existing JVM, just as a library of another application. This enabled Jetty to be used in many situations, like mvn jetty:run for
debugging a webapp without even running an application server on its own. IMO this contributed
to a part of Jetty's usefulness. Almost every Maven documents today use Jetty for
web app development, or doing site:run, etc.
So naturally, we wanted to do the same for GlassFish v3, and I'm happy to report that
it got to the point that it holds the water. I mean, I can now run Hudson in this embedded GFv3.
Here's how it works — GlassFish v3 can be run as an OSGi appliation as Sahoo reported earlier , but in fact it can also be run without any kind of classloader isolation system at all. Sure, you won't get the isolations, but this means you can just drop a bunch of GFv3 jars in your classpath and run it like that.
So I added a little bit of API around that to make things pretty, and now you have the embeddable GFv3 API, which can be used like this:
GlassFish glassfish = new GlassFish();
// create smallest possible HTTP set up listening on port 8080
GFApplication app = glassfish.deploy(new File("path/to/simple.war"));
Imagine the possibilities...
Thanks to the extensibility of GFv3, when you embed GFv3 in your JVM, you can plug into any of its extensibility points and tweak the behaviors in ways that you can't do with externally launched GFv3. You could also pick any flavor of GFv3 you want; if you just need the barebone servlet container and get smaller footprint, you can do that. But if you also need EJB functionality or some of our scripting offerings, that's cool with us, too. This is where we have an edge over Jetty, I think.
This is still a work in progress, but just imagine what we can do with this kind of stuff. How about testing your web services end-to-end without ever requring your developers to install GlassFish and set up database and all that. It also gives you interesting deployment options.
Oh, did I mention the start up time? One good thing about using a single classloader to load everything is that classloading overhead becomes much smaller. On my system, the server now starts in 300ms or so, complete with a deployment of a webapp. How many seconds does it take for your application server to start?
I also wrote Maven glassfish plugin to wrap this as a Maven plugin. This allows you to do mvn glassfish:run to run the web appliation that you are developing on Maven (the equivalent of mvn jetty:run.)
I'm also thinking about quickly putting together Ant tasks.
As I wrote, this is still a work in progress, but please tell us what you think about where we are going.
Finally, I'll be co-speaking more about this in the upcoming JavaOne technical session "TS-5921 GlassFish Project v3 as an Extensible Server Platform." If you are coming to JavaOne, I hope you'll come to the session.