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 18:40:50 GMT
It is on page 45 of the JSR-77 spec:

Standard event types are:
• j2ee.object.created- a new managed object was created.
• j2ee.object.deleted - a managed object was deleted.
• j2ee.state.starting - a state manageable object entered the starting 
state.
• j2ee.state.running - a state manageable object entered the running 
state.
• j2ee.state.stopping - a state manageable object entered the stopping 
state.
• j2ee.state.stopped - a state manageable object entered the stopped 
state.
• j2ee.state.failed - a state manageable object entered the failed 
state.
• j2ee.attribute.changed - an attribute has change value

The attribute changed event is not fired right now, but all of the rest 
are fired.

-dain

On May 2, 2004, at 1:28 PM, Brendan W.McAdams wrote:

> Out of curiosity, What events will be supported, and at what level? 
> (E.g. Application only, or sub module lifecycles?)
> ---
> 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 2, 2004, at 1:54 PM, Dain Sundstrom wrote:
>
>> 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