vendredi octobre 03, 2008

Bundling GlassFish v3 Prelude - XWiki and the GlassFish Embedded (Part 2)

In Part I, I covered a first technique to bundle the XWiki application with GlassFish v3 Prelude. The distribution and packaging discussed included a "traditional" auto-deployment of a web application (WAR) in a lightweight application server (GlassFish v3 Prelude).

XWiki is a non-trivial application and I felt it would be a great test for the GlassFish Embedded API. This enables GlassFish to run in-process as explained in the rest of this entry. While the embedded API can be very useful for testing (it can now already be used with Maven and Grails for instance), the goal here is to produce a self-container Java SE application which contains GlassFish Embedded, the XWiki WAR archive and some glue code to start glassfish and deploy the application

GlassFish Embedded does not use OSGi but rather a more traditional class-loader hierarchy so I had to work around a "classical" JAR precedence issue:
• removed the log4j jar from the XWiki application and make it available as a library (appropriate Class-Path: entry in the manifest of the overall JAR).
• used <class-loader delegate="false"/> in sun-web.xml to avoid further library conflicts (documented here)

Using the GlassFish Embedded API is pretty straightforward :

import org.glassfish.embed.App;
import org.glassfish.embed.AppServer;


public class XWikiOnGlassFish {
    public static void main(String[] args) throws IOException {

        AppServer glassfish = new AppServer(8080);
        App app = glassfish.deploy( new File("/path/to/xwiki-enterprise-web-1.5.2.war") );
    }
}

The application weights 20 MB for the full GFv3 Prelude embedded (see other distributions here) + 4Ko "glue" application + 40MB XWiki.

The startup time is as follows:

with an additional 12 seconds to load the XWiki web app. The memory consumed (used heap as reported by VisualVM) is 15 MB right after the welcome page is displayed and 35 MB after exercising the application a bit.

I'll leave the packaging of this Java SE application (see what the OpenSSO guys did) using Java Web Start as an exercice to the reader.

More coverage of the GlassFish Embedded API (including the ScatteredWar API, and the Maven integration) can be found here. Note that a few API changes happened since that post.

vendredi septembre 26, 2008

Bundling GlassFish v3 Prelude - XWiki (Part 1)

In previous blog posts about XWiki and GlassFish, I explained how to expose XWiki on the GlassFish v2 update center and how to deploy XWiki in a GlassFish container.

This was a while back and XWiki, now a GlassFish partner, has nicely moved forward to version 1.5.2 (Stable). At the same time GlassFish released an embedded API and will soon ship GlassFish v3 Prelude, a lightweight container.

Shipping XWiki and GlassFish v3 Prelude together actually makes sense. The download is much smaller (21MB) than it would have been with GlassFish v2 (65MB), but having now an embedded API for the GlassFish makes it a reasonable Jetty alternative. It can for instance be used to implement an evaluation bundle (similar to what the OpenSSO folks did: 85Mb, Java Web Start deployment included).

Using JavaDB this time (no need to add driver in XWiki's WEB-INF/lib directory): simply edit WEB-INF/hibernate.cfg.xml to uncomment and adjust the JavaDB section, add a sun-web.xml file with a context-root set to /xwiki and update the WAR archive (xwiki-enterprise-web-1.5.2.war in my case).

Using GlassFish v3 Prelude promoted build #25 (Sept 19th), I could easily deploy by copying the archive in the auto-deploy directory (domains/domain1/autodeploy).

This can lead to a simple ZIP archive with GlassFish v3 + XWiki 1.5.2 war sitting in the auto-deploy directory. Make sure also that you nuke the domains/domain1/.felix bundle cache to avoid OSGi bundle symbolic name issues. Unzipping, starting GlassFish and pointing to http://localhost:8080/xwiki does the job (simple enough for testing/evaluating). Startup with XWiki in the autodeploy directory takes 15 seconds on my machine. Starting with Xwiki already deployed takes 8 seconds.

The next step is to start using the GlassFish embedded API.

Thanks to XWiki CTO Vincent Massol for the quick turnaround answering my questions and bug reports.

lundi octobre 22, 2007

Using the GlassFish Update Center to reach out to thousands of developers

The GlassFish Update Center is a tool that lets you deploy extra features, libraries, or even applications to an existing installation in a very user-friendly fashion. It is part of every copy of GlassFish, Sun Java System Application Server and the Java EE 5 SDK (3.5M+ downloads). The following describes the simplest GlassFish Update Center module who's only job is to deploy a self-contained web application (no database dependency in particular).

To follow-up on a previous post, I'll use XWiki which has since hit version 1.0 with 1.1.1 being the latest. I've tweaked their WAR distribution to use HSQL (as already described in the previous post) so that it has no dependency on external resources. Making this XWiki distribution available via the GlassFish Update Center requires 2 easy steps:

1/ Package the WAR artifact into a module file (default extension is .nbm but anything can be used as it is really only a ZIP file) with info/info.xml and module/xwiki.war as the only two entries. I've actually called the file xwiki.gfz for no particular reason and posted it here.

2/ Author an Update Center catalog file compliant with this DTD describing the module - download size, module author, license, short/long description, etc... This XML file is the only server-side component needed. I've created and posted the file here (so you can try it). The key line here is :
     Module-Type="APPLICATION"
which basically tells the update center that the module is a Java EE artifact (WAR, EAR, RAR) which will cause the updater to copy it to GlassFish's autodeploy directory. Other valid values for Module-Type are ADDON_INSTALLER, ADDON_CONFIGURATOR, and ARCHIVE.

The user experience then looks like this :
•  Start the Update Center client located in GLASSFISH_INSTALL/updatecenter/bin.
•  Add an Update Center definition in the "Preferences" tab using this URL - http://blogs.sun.com/alexismp/resource/xwiki-gfuc.xml
•  Install the update after agreeing to the license (download, unpack and install all happens under the cover)
•  Launch the application (no restart)

Steps are illustrated on this other page

This is an easy way for the many web applications out there to be easily made available to the large number of people downloading GlassFish. Of course not every application is self-contained like the one I used and in that case you would have to use a custom installer and configurator as explained by Manveen here and here. It allows for the Update Center to install bits (libraries, config files, ...), modify existing file (i.e. domain.xml) and create the appropriate resources in the application server (connection pools for instance).

Interested in packaging your application for the GlassFish Update Center? Try this out and post comments here!

lundi janvier 29, 2007

XWiki meets GlassFish v2

Why XWiki?
There are a lot of wikis out there (I mainly use JSPWiki).  The main reasons for XWiki are rights management and programming (using Velocity or Groovy). Other features are described here.

You can get XWiki from here. I chose to download the XWiki 1.0 beta 2 WAR file. It's 41Mb, which is the same size as the simple install which bundles Jetty as the default web container (btw, here's a Jetty aficionados who started using GlassFish). If XWiki were to ship GlassFish, the download size might be an issue as GlassFish is around 60MB (which is pretty good for a full blown application server BTW). XWiki install instructions are here.

Before deploying the archive, the database needs to be configured. Although I started using JavaDB (part of GlassFish) based on these instructions and browsing the data using NetBeans, I quickly hit a missing XWIKILINKS table error. So back to HSQL which is bundled with XWiki. The config is really straightforward.

After upgrading the content of the WEB-INF/hibernate.cfg.xml file to reflect the database settings and update the WAR file (% jar uvf xwiki-1.0-beta-2.war WEB-INF\hibernate.cfg.xml, the deploy can be simply done using the GlassFish Web Console.

You can also use the CLI's asadmin deploy command. Simply make sure you use 'xwiki' as the application Context Root (I wish XWiki didn't have the webcontext hard-coded to xwiki). Once the deployment is done (should take less 30 seconds), the application is available from http://localhost:8080/xwiki.

To make the content a little more useful, I used the administration page to upload a xwiki-1.0-beta-2.xar XWiki archive to populate the system. This also creates a administrator user ( Admin / admin )

So Why GlassFish?
Since XWiki is a web app, I guess that Jean-François' blog about what's new in GlassFish 2's web tier is pretty relevant (Improved Virtual Server support, JSP compilation with JSR 199, HTTP Compression support, SSL support now use NIO non blocking, ...). It would be interesting to compare performance of various containers (Jetty, GlassFish, Tomcat, JBoss, ...). I wonder if the XWiki guys have some benchmark or scalability test they run against their developments.

Also, with GlassFish v2 (soon to be in beta), clustering is now a simple add-on feature enabling cluster-wide deployments, load-balancing and fail-over. There's also the new auto-update feature and WSIT-based Web Services (Microsoft-interoperable WS-* stack implementation). Of course, GlassFish is also a production-ready Java EE 5 application server which XWiki could use to upgrade to newer technologies such as EJB3, JPA, JAX-WS, etc...


( janv. 29 2007, 03:11:05 PM CET ) Permalink