geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcus Malcom" <malc...@community-health.org>
Subject Re: Headless Java Application Deployment?
Date Tue, 30 May 2006 15:45:24 GMT
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

Mime
View raw message