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 17:53:24 GMT
Excellent ... some of our apps will be Spring, but for now none are.
We'll also need to have this ability for non-Spring application
deployment and management moving forward as well. So, I agree waiting
until the Spring integration is done and then start work on the J2SE
container bit sounds great. Any idea when the Spring integration will be
started/completed?

Thanks!

--
Marcus

On Tue, 2006-05-30 at 12:26 -0400, Aaron Mulder wrote:
> 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-----
> >
> >
> >
-- 
Marcus Malcom
OCHIN
Software Engineer
malcomm@community-health.org
Phone: 503-943-2500

Mime
View raw message