users@glassfish.java.net

Re: JBoss SAR replacement

From: Binod <Binod.Pg_at_Sun.COM>
Date: Mon, 24 Sep 2007 16:13:15 +0530

Jörg Henne wrote:
> Hi all,
>
> we are currently investigating alternatives to JBoss AS. Glassfish
> looks interesting, so far, but, I could not quite make out whether
> Glassfish features an equivalent to JBoss SARs, we absolutely need. In
> case you are not familiar with SARs, here's the bottom line:
>
> * SARs are similar to EARs in that they present a self-contained
> application including descriptors, Code and, possibly libraries.
> * In contrast to EARs, SARs don't deploy enterprise applications (Web
> Applications, EJBs), but services.
> * Services are quite simply MBeans implementing a service interface
> that lets the service hook into the container life-cycle (start/stop)
> along with a descriptor detailing dependencies etc.
>
> I understand that Glassfish features deployment of plain-old MBeans as
> well as Lifecycle Modules. However, as I understand it, both can't
> quite do what JBoss SARs can:
> * Glassfish MBeans can't be packaged like a SAR, i.e. in a
> self-contaiend module to be deployed like other applications.
> * Additionally, they lack the life-cycle hooks.
> * Lifecycle Modules, on the other hand, are closer to SARs in that
> they can be deployed in a self-contained (?) fashion, however, they
> have two drawbacks:
> ** They require a server-restart upon deployment
> ** There doesn't seem to be a mechanism to specify module dependencies.
>
> I may be wrong about some or all of those observations, so please let
> me know if this is the case. Anyway, to make things a bit clearer,
> here is our use case:
>
> * Deploy services other than J2EE apps. Think, for example,
> implementations of classic UNIX services like NFS, TFTP etc.
What exactly your app do? Would resource adapters (JSR 112) be a choice?

thanks,
Binod.
>
> * We would like to be able to just drop the service packages somewhere
> for deployment.
> * They should be self-contained so that they can use their own
> isolated class loader, in order to overcome possible library version
> conflicts.
> * Of course we need the life-cycle hooks.
> * Oh, and did I mention: hot (re-) deployment would be great...
>
> From the demos it seems like v3 is just what we're looking for, but
> can v2 do that as well?
>
> Thanks
> Joerg Henne
>