geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Wilkins <gr...@mortbay.com>
Subject Re: [PATCH] Was: JSR77 component lifecycle
Date Wed, 13 Aug 2003 04:50:26 GMT

Sean,

I agree that we can do more to move towards support for JSR77 at
the base level and a StateManageable interface could well be part of
this.

But as you say more reading of the spec is required (at least on
my behalf) before creating these classes.

For now, my patch (which I have now committed) has at least got
our vocab and states into the same ball park as JSR77.  Hopefully
we can move the structure closer soon as well.

cheers


Sean Hamblett wrote:
> On Tuesday 12 August 2003 11:30 pm, Greg Wilkins wrote:
> 
> Greg,
> 
> 	Thanks!  I appreciate the details on the component/container relationship, 
> and it makes sense.  On a separate note, I was looking over JSR77, and as I 
> interpreted it, there is a whole separate layer of interfaces for organizing 
> State, Performance, and Events.  I think it might be a good idea to separate 
> out the State Management interface from the Component interface, as a new 
> StateManageable interface (JSR77.5), which either the Container and Component 
> interfaces can extend, or just limit the StateManageable interface to those 
> objects that need some sort of 'State Management', which could include all 
> components, and hence all containers.  
> 	I still have some more reading to do on JSR77, but what I have seen so far I 
> like, and looks like it could be broken down into its core components of 
> State, Performance, and Management, and applied as needed.  Let me know what 
> you think, and thanks again!
> 
> Sean
> 
> 
>>Sean,
>>
>>firstly I was not the author of the original Component/Container
>>code... so I don't really know the answers to all your questions and
>>I too would like to see some more doco on it.
>>
>>But the container/component thang is a pretty standard pattern and
>>can be found in most pattern books (can't remember the name but
>>it is probably container?)
>>
>>Container are components so that containers can contain other containers.
>>eg J2eeContainer contains WebContainer contains WebApplication (which
>>may be a Container of Servlets/Filters ??)
>>
>>I think there needs to be an AbstactContainer class to implement the
>>recursive nature of this.  Currently that is done in ContainerImpl, which
>>is not generic enough for me.
>>
>>We also need a good policy on what is containment.   It is pretty
>>obvious that a WebApp is contained in a WebContainer is contained in
>>a J2eeContainer.   But we don't want to have services contained
>>by the JNDIService, just so they can get an initial context.
>>
>>cheers
>>
>>Sean Hamblett wrote:
>>
>>>Greg,
>>>
>>>	Quick question, I noticed that the Container interface extends the
>>>Component interface.  Is this so a Container can be 'contained' by
>>>another Container? And is the Component interface satisfied, because the
>>>ContainerImpl extends AbstraceComponent which implements the Component
>>>Interface?  Just trying to get my head wrapped around what is going on.
>>>	If you can point me to some specific documentation so I can do some
>>>reading on this, that would be great.
>>>
>>>Thanks,
>>>
>>>Sean
>>>
>>>On Tuesday 12 August 2003 09:00 pm, Greg Wilkins wrote:
>>>
>>>>OK, I have an initial patch for this ready.  I can commit it myself,
>>>>but I wanted to post it as a warning as it has a few unresolved issues.
>>>>
>>>>I have implemented the JSR77 state model in Component and
>>>>AbstractComponent
>>>>
>>>>For start and stop this was simple.   But I have also removed the
>>>>create and destroy methods for now.   I moved any create operations
>>>>I found to the start() (or doStart()) methods.
>>>>
>>>>I have left destroy methods in the code, but noted that they are
>>>>currently not supported by the lifecycle.   I think they do contain
>>>>good cleanup code - but we could just rely on java finalize mechanism?
>>>>Or we could move the code into doStop to be symmetric with doStart.
>>>>
>>>>I have implemented startRecursive in ContainerImpl - however, I really
>>>>think that we need an AbstractContainer class for this.   But this
>>>>would need a method for iterating over children in the Container
>>>>interface. As this is not there - I have not done this... more reading
>>>>of JSR77 spec required to support their container naming and methods I
>>>>think?
>>>>
>>>>In JSR77 there is no stopRecursive method - so ContainerImpl.stop is
>>>>actually recursive (which I think is the correct thing to do?) Again
>>>>this should be in AbstactContainer.
>>>>
>>>>I'll give this a few hours for "DON'T DO IT" reponses and if I don't
>>>>get them I'll do the commit and we can work on the remaining issues.


-- 
Greg Wilkins<gregw@mortbay.com>             Phone/fax: +44 7092063462
Mort Bay Consulting Australia and UK.          http://www.mortbay.com


Mime
View raw message