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<[EMAIL PROTECTED]> Phone/fax: +44 7092063462 Mort Bay Consulting Australia and UK. http://www.mortbay.com
