Hey Yannick,

this is about contracts: a component should start when start() is called (it has a 'veto' option then, and only then, by throwing an exception, that is), then keep running until stop() is called. No argument, no room for discussion. The component is told by the container what to do, and it had better listen ("Do as yer told, boy!"). That's the idea behind inversion of control.

If a component fails to do as it is told, that is usually because /something else/ didn't do what it was supposed to do (maybe the database server crashed, or the JVM has a bug). In that case, the component can hardly be considered responsible for fixing things. It should just start complaining to whomever is still asking it to do stuff that something is wrong ("Can't do that. But its not my fault! The database did it!").

That error message should make it through to whatever or whomever can fix the problem. That is not the container either, so it has no business inquiring about any issue. ("Hey, you, component, having any kind of issue?" is not something the container is accustomed to asking).

The container is always in sync with the component state; what you should be thinking of is a component being out of sync with its own state (its out-of-line, and it'd better get back in line real quick).

The application or person who ends up fixing the problem can then, obviously, will delegate most of the error recovery to the container ("Oi! You, container! Kick that friggin' component out of the JVM, pronto! Now get me a new one!").

hope this helps!

g'night,

- Leo

Yannick Menager wrote:

But that way you're putting a risk that the container might be out of sync with the real state of the component. All that to save having an extra function. I would think the downsides are bigger than the cost of having an extra function to check the state of the component. Otherwise most people will implement that function but it won't be standard, reducing potential reusability, and causing pains to people who want to incorporate dynamic administration capabilities in the container.



--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to