Kohsuke Kawaguchi reports that he's able to run Glassfish V3 as an embeddable container, much as Jetty has been able to run for years: drop the container into your classpath, and run via code. There's no classloader isolation with this, but the ability to embed quickly and easily is hard to undersell.

...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 glassfish.minimallyConfigure(8080); GFApplication app = glassfish.deploy(new File("path/to/simple.war")); ... app.undeploy(); glassfish.stop();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. ... 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?

This is separate from the OSGi deployment model mentioned earlier by Glassfish bloggers (and mentioned here on TSS) but, then again, this capability might serve OSGi deployers well in a pinch.

Hm...thinking outside of the box here...throw togethere a Swing app with embedded Glassfish or Jetty, display an embedded JDIC browser as the only control in the main frame and deploy into it a web app written using JSeamless framework: http://jseamless.org and what you have is...Adobe AIR, but in pure Java, without the Adobe part. Cool :-)

Hm...thinking outside of the box here...throw togethere a Swing app with embedded Glassfish or Jetty, display an embedded JDIC browser as the only control in the main frame and deploy into it a web app written using JSeamless framework:
http://jseamless.org

and what you have is...Adobe AIR, but in pure Java, without the Adobe part.

Cool :-)

I like the idea. In the same way, you might find interesting my post Revisiting XHTML as a base (?) for XUL-like programming, trying to gather a "global" view of this idea. For example, why not using Flying Saucer instead of a JDIC browser !? Looks like (X)HTML is not dead, just as some web frameworks, like Wicket, are using it as template langage.

Because FlyingSaucer cannot display Flash. :-)

... or just use AjaxSwing and you don't need GlassFish/Flex ;-)

Why should I use Glassfish V3 embedable instead of Jetty? Jetty is a very light and fast embedable server. Where is the innovation?

I guess it would be that Glassfish is a full Java EE 5 container, so out of the box you get support for EJB 3.0, sessions beans, messaging beans, etc. Impressive set of functionality to have in an embedded app.

Why should I use Glassfish V3 embedable instead of Jetty?
Jetty is a very light and fast embedable server.
Where is the innovation?

What the heck are you talking about? Whoever you are - you're making the same stupid mistake made by every idiot "Java EE programmer" who hates Java EE because EJBs were the wrong solution to a problem, and couldn't figure out that Java EE isn't the same as EJB. Not every problem requires a hammer; not every problem is a nail. Jetty is a servlet container. It's a good one. Use it if it's all you need. Glassfish is a Java EE container. It's ALSO a good one. Use it if you need more than Jetty provides - i.e., EJB, JCA, JMS, etc. etc. While "jetty is as good as glassfish" is a qualitative statement, and can't be verifiable because of it, the comparison relies on an apples-to-fenceposts comparison. Speaking of fenceposts, aren't you supposed to be losing an argument with one?

Interesting! Doubly interesting as we're busy porting Jetty as an alternative webtier for Glassfish V3 (we also did this for V2 but that work has fossilized a bit as we've looked more to the future with V3). Jan http://www.webtide.com

Why should I use Glassfish V3 embedable instead of Jetty?
Jetty is a very light and fast embedable server.
Where is the innovation?

Speaking from many years of experience, I can tell you that the interest for running embedded containers is huge. Still, Glassfish footprint is not amongst the smallest, and I dare say that there is quite some way to go before it can compete with the vendors already in that market segment. Either way, Its all very interesting and I am excited to see what it will lead to.

Speaking from many years of experience, I can tell you that the interest for running embedded containers is huge.

Still, Glassfish footprint is not amongst the smallest, and I dare say that there is quite some way to go before it can compete with the vendors already in that market segment.

Either way, Its all very interesting and I am excited to see what it will lead to.

I agree. It is useful to run a web server embedded, I have already used jetty in this way some year ago: and the winning choice was due to its small memory footprint and its performance. you get the problem: Glassfish is an AS, with a huge memory footprint and its performances are not so beautiful (I used an old version....I don't know if recently it became faster). I heared that the V3 will be shipped with and without EJB... a glassfish embedded without EJB is similar to jetty, but a glassfish embedded with EJB could be too heavy.

"The focus of the release is modularization, enablement of non Java EE containers, and embedability." Maybe check http://wiki.glassfish.java.net/Wiki.jsp?page=PlanForGlassFishV3 , http://wiki.glassfish.java.net/Wiki.jsp?page=V3embedded and https://hk2.dev.java.net/ about the modular and component based model GFv3 is based upon. JEE5 (or maybe it's JEE6) is also component based, and additionally JSE7 will also implement a modular system, so once GFv3 will enter the beta phase around November 2008 you should be able to use it both as a monolithic app server and scattered around as "micro" servers. hth Paul

People are talking about huge memory footprint of Glassfish, since it's a full application server. However, Glassfish is lazy - i.e. it uses lazy loading of containers, and only loads what the app needs at run time. So if you're running just a JSP/Servlet web app, only the web/servlet container part is loaded, and it's memory footprint should be roughly equivelent to Tomcat (doubt it would be as small as Jetty). Then, if your app is using EJB, JMS, or JPA, Glassfish will load those containers/libraries, as needed. And that gives it an advantage over plain old Tomcat or Jetty. Add to that the fact that Glassfish is highly regarded as being very fast, easy to work with, and is fully JEE 5 compliant (it's the reference implementation), and you have a very compelling solution.

Look a little like incomplete task. Some questions: 1. Is this a replacement for JMX or it uses JMX internally? 2. Are you going to give me my datasources and my bound objects? 3. Is it going to launch a new server or connect to an existing server? 4. Why not provide an ANT task? 5. You want to deploy your programs using another program rather than a build tool that is meant for that?!?! As of now, nothing but Marketing crap. Add an ANT task around it, and then tell me it is usable.

Pawan, Can you please explain what you mean ? How can a java program since jdk 1.5 not be using JMX internally ? Or are you referring to the OSGi buzz ?