Mailing-List: contact user-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: domain of ammulder@gmail.com designates
 64.233.162.202 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=Gcl7I/bxs1uxfB/wgx0mqO5hRU+tvoDA4y5VH4l5RihvkHM+Mlu4QoSE1s1U8Gzj7cW8dy0Gscfo2SxSGDKBE99flFmxIHO2WocUX/k4o2Mqngrvc4bP4E70QhMl8q/L449Yh5H0nrTWW2g6eMKzaO0sKpcSVfNizeYUBIkwAvg=
Message-ID: <74e15baa0605300926y160a0dffje11c6e63c4288357@mail.gmail.com>
Date: Tue, 30 May 2006 12:26:23 -0400
From: "Aaron Mulder" <ammulder@alumni.princeton.edu>
Sender: ammulder@gmail.com
To: user@geronimo.apache.org
Subject: Re: Headless Java Application Deployment?
In-Reply-To: <1149003925.5087.20.camel@localhost.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <1148677285.5130.11.camel@localhost.localdomain>
	 <74e15baa0605261445x33aaff88gf960a56f4218573d@mail.gmail.com>
	 <1148680549.5130.20.camel@localhost.localdomain>
	 <74e15baa0605261533y5dba7864ib8acbc37f1f3d05f@mail.gmail.com>
	 <1148684941.5130.31.camel@localhost.localdomain>
	 <74e15baa0605261804k649e6608v23e62c7542410c21@mail.gmail.com>
	 <1149003925.5087.20.camel@localhost.localdomain>

What you're describing is certainly possible.

You'd probably want to have integration with Geronimo security,
transactions, resources, and threading... plus deployment and the
admin console and so on.

I think we're most likely to do this for Spring first, so if your app
ran in Spring then you'd be able to do things like you're describing.
But once we get the Spring integration worked out, you should be able
to use that as a template if you want to set up a J2SE container like
you're describing.

Thanks,
    Aaron

On 5/30/06, Marcus Malcom <malcomm@community-health.org> wrote:
> Thanks again for the response.
>
> So, I'm thinking that the "manager" scenario would be a better fit for
> our needs. But this still feels like it might not be an exact match for
> what we're looking to do.
>
> One thing that I keep thinking about is to have the ability in Geronimo
> to deploy and manage non-J2EE applications - like these headless apps.
> Over the years, every single J2EE container that I have used has failed
> in this regard. I remember WebSphere did have some ability, but it
> always felt like a hack. So, what I was wondering could we work on
> something a little more formal - say a J2SE container for any type of
> stand-alone Java application. This thing would just be a zip/tar/jar
> that has:
>
> -- lib/
> -- classes/
> -- runtime.xml (don't care about the name)
>
> The runtime.xml would have definitions in there that would describe
> 1...* applications that are "runnable". What I'm thinking is that we
> would mimic a lot of other J2EE application deployments - for example,
> there would be a flag that allows the application to start on the load
> of the container, application args, ... etc. Also having the ability to
> reference resources would be a good thing to have.
>
> Thoughts?
>
> Thanks!
>
> --
> Marcus
>
> On Fri, 2006-05-26 at 21:04 -0400, Aaron Mulder wrote:
> > Hmm...
> >
> > So the main question is around "kill".
> >
> > A GBean can have a lifecycle including "start" and "stop".  Those are
> > called automatically when the module containing the GBean is started
> > or stopped.  We definitely don't encourage you to independently start
> > and stop a given GBean while the module containing it is still
> > running.
> >
> > So is it OK if we forget about kill and just create a GBean that's
> > does your start code when the module starts and does your stop code
> > when your module stops, and if you want to force it to stop right
> > away, you can just use the deploy tool "stop" command to shut down
> > that whole module?
> >
> > An alternative would be for the GBean to be kind of a like a "manager"
> > that's always running, and could start, stop, or kill your service as
> > three management commands that it could execute.  So the service may
> > or may not be running, but the manager GBean would always be there to
> > control the service.  This would be kind of a force fit if the service
> > is expected to be generally always running, but it's probably the way
> > to go if you want to be able to independently start and stop the
> > underlying service without having to start and stop the whole module
> > in Geronimo (for instance, if due to some business rule the service
> > should only run for 60 seconds per hour or something like that, so
> > it's expected to regularly switch off and on).
> >
> > Any thoughts on which way to go?
> >
> > Thanks,
> >     Aaron
> >
> > On 5/26/06, Marcus Malcom <malcomm@community-health.org> wrote:
> > > On Fri, 2006-05-26 at 18:33 -0400, Aaron Mulder wrote:
> > > > OK, well, you could certainly deploy the "headless apps" as GBeans --
> > > > or at least, deploy a GBean that starts the app when the GBean starts
> > > > and stops it when the GBean stops (and perhaps hooks it up to some JMS
> > > > resources or JDBC pools).  You could then create an EAR containing the
> > > > web apps, the JDBC/JMS resources, and the GBean definitions.  Though I
> > > > don't know how you can package an arbitrary JAR (containing the
> > > > headless application code) in an EAR, so it might be easier to put all
> > > > the J2EE and JDBC/JMS stuff in an EAR and put the headless
> > > > applications in a separate JAR that just depends on the EAR.
> > >
> > > OK, so I think there's some options for me in there. I think the first
> > > thing will be to work on creating the GBeans (see below).
> > >
> > > > If you need help with the GBeans, let's start by sketching out what
> > > > GBeans you need and what each one should do.
> > >
> > > For the moment, the only thing that I need is to be able to perform a
> > > stop(), start() and kill().
> > >
> > > start():
> > >   public boolean start() {
> > >     initLogging();
> > >     int corePoolSize = 4;
> > >     int maxPoolSize = 30;
> > >     long aliveTime = 60L;
> > >     TimeUnit unit = TimeUnit.SECONDS;
> > >     BlockingQueue<Runnable> workQueue = new
> > > SynchronousQueue<Runnable>();
> > >     ExecutorService service = new ThreadPoolExecutor(corePoolSize,
> > >         maxPoolSize, aliveTime, unit, workQueue);
> > >     ExampleWorkItem workItem = new ExampleWorkItem();
> > >     workItem.setService(service);
> > >     service.submit(workItem);
> > >     setService(service);
> > >
> > >     return true;
> > >   }
> > >
> > > stop():
> > >
> > >   public void stop() {
> > >     ExecutorService service = getService();
> > >     if (service != null) {
> > >       service.shutdown();
> > >     }
> > >   }
> > >
> > > kill():
> > >   public void stop() {
> > >     ExecutorService service = getService();
> > >     if (service != null) {
> > >       service.shutdownNow();
> > >     }
> > >   }
> > >
> > > My first cut at writing a GBean was to do something like this:
> > >
> > >   public class GBeanExample extends AbstractGBeanReference
> > >
> > > but after reading a bit more on GBean's, I'm not so sure this is what I
> > > want. So I guess at this point, I'd love to find out what I need to do
> > > to write and deploy this kind of a GBean (sample descriptors would be
> > > very helpful).
> > >
> > > Oh and my "WorkItem" is just this:
> > > public class ExampleWorkItem implements Callable {
> > >
> > > ...
> > >
> > >   public Object call() throws Exception {
> > >     ExecutorService service = getService();
> > >     Logger logger = Logger.getLogger(ExampleWorkItem.class);
> > >     while(! service.isShutdown()) {
> > >       Thread.sleep(10000);
> > >       logger.info("logging a message now.");
> > >     }
> > >     return null;
> > >   }
> > >
> > > }
> > >
> > > That's pretty much all I need to do for a prototype.
> > >
> > > Again thanks for the replies and the help!
> > >
> > > --
> > > Marcus
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (GNU/Linux)
>
> iD8DBQBEfGiUCmHgPZZrHwIRAiSVAKCSD1KPU+MYUprGWW+dEZBvLegNsgCfbrDd
> KT6urjkM1jtZwM0ajWRCYOY=
> =Yz8j
> -----END PGP SIGNATURE-----
>
>
>