geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@coredevelopers.net>
Subject Re: ?Enhanced? Lifecycle Interface for Application Developers
Date Sun, 02 May 2004 17:54:25 GMT
I plan on implementing this with GBeans, but it can't be done with 
depenencies.  I plan on supporting this by adding a general purpose 
event listener system to GBeans.  Since JSR-77 already defines 
life-cycle events that match up to your proposed interface it should be 
trivial to implement (once I add the not so trivial event system).

-dain

On May 1, 2004, at 6:18 PM, Brendan W.McAdams wrote:

> Alan Cabrera was kind enough to point out a good question: Why not use 
> GBeans?
>
> There was another component to the conversation regarding this which I 
> neglected to include:  It *IS* possible to interface the GBeans for 
> lifecycle, but from what I understand there isn't "orderly"  
> deployment.  I don't know this section of things too well, but from 
> what I understand there is a necessity to define various dependencies 
> if you were to use Gbeans for this.
>
> By defining a LifecycleInterface, conceivably dependencies could be 
> configured on the fly based on the modules defined in application.xml
>
> Dain & Jeremy, can you guys backfill this a bit?  I'll go back through 
> the IRC log as well and pull up that piece of the conversation.
>
> Thanks,
>
> 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"
> On May 1, 2004, at 6:46 PM, Brendan W.McAdams wrote:
>
>> 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