geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brendan W.McAdams <bmcad...@sluggy.com>
Subject ?Enhanced? Lifecycle Interface for Application Developers
Date Sat, 01 May 2004 22:46:05 GMT
I'm doing my best to collate some of the information provided here by 
several people ; it's my hope they will put in their two cents as well 
in reply and straighten out any misquotes I may make, and help flesh 
this idea out.

I had a conversation with Jeremy Boynes on Thursday Night, to which 
Dain gave some input on Friday morning, regarding some of the 
Application Level Lifecycle interfacing that BEA provides in their 
Weblogic product.

Using the weblogic-application.xml file (Weblogic's custom supplement 
to application.xml for EAR files), one is able to define a Lifecycle 
application (or more than one ; there is no limit) which implements a 
basic Lifecycle interface:

preStart - before contents (modules) of application (EAR) are loaded, 
this method is invoked
postStart - after all contents (modules - ejbs, etc) are loaded and 
initialised, this method is invoked
preStop - when the application (or encompassing appserver) signals it 
is being stopped, this is invoked before signalling modules to stop
postStop - once all modules in the application have been shut down, 
this method is invoked

As I stated, once you've written a class that implements the interface 
and these methods, you simply declare it in a <lifecycle> block in 
weblogic-application.xml.  When the EAR file is deployed, the AppServer 
automatically picks up the Lifecycle app, and sends each change of 
status (one of the four) notification through it.

I realise it may sound like I'm rambling but I do have a point... I 
think that a similar facility would help Geronimo greatly.
   As a usage example, we use it at my company to preload the entity 
cache with the approximately 15,000 bond offers that are active in our 
marketplace at a given time.  [This way, we load the entity cache 
before the system is available, preventing 'database load' slowdown the 
first time someone does a large market search].  We are also using it 
to initialise certain timer events, and fire off events to our Message 
Driven Beans to setup the marketplace.  There are, I am sure, plenty of 
other beneficial uses that we haven't even begun to touch on.

The conversations with Jeremy and Dain  yielded some good feedback , 
and I believe they agree with the idea.

One of the things suggested [by Jeremy] was allowing lifecycle 
definitions even at the level of individual modules of an application, 
to do more fine tuned control.

On the same lines, we discussed allowing access from the lifecycle 
level to the Local interfaces; from what I understand of the EJB 
container contract it's ok to let other services in the appserver 
access local interfaces [BEA doesn't allow it directly but  instead 
optimises away the RMI calls on any remote bean invocation within the 
AppServer].  This would certainly make the lifecycle even more powerful 
[in our case for Beans which are Local only, our lifecycle invokes a 
session bean to do the job].

I believe I've put a good bit of the information compiled here, of 
course if anyone has feedback please post it back to the list.

Regards,

Brendan
---
Brendan W. McAdams
bmcadams@twodot.org

"I am free, no matter what rules surround me. If I find them tolerable, 
I tolerate them; if I find them too obnoxious, I break them. I am free 
because I know that I alone am morally responsible for everything I 
do."				--- Professor Bernardo de La Paz
			     Robert A. Heinlein "The Moon Is A Harsh Mistress"


Mime
View raw message