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 [EMAIL PROTECTED]
"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"
