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 <[EMAIL PROTECTED]> 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
signature.asc
Description: This is a digitally signed message part
