On Friday, January 2, 2004, at 04:15 PM, Dain Sundstrom wrote:

On Jan 2, 2004, at 4:13 PM, Jules Gosnell wrote:

David Jencks wrote:

When converting AbstractManagedObject thingies to GeronimoMBeans I have generally ignored this advice and simply thrown a RuntimeException.

i thought of that, but I think you would agree that it is not the best solution :-(

Not a good idea. Then you move to the failed state which requires an admin to fix.

I know it's not a good idea. As I recall, most or all of these were problems outside the bean itself.

I think that perhaps it's reasonable to check internal consistency in canStart but not do anything that queries the outside world. I would prefer an explicit "CantStart" exception in the signature of Start. For instance, if you are opening a server socket, you'd have to open it in canStart and leave it open to guarantee that it will still be available in Start. AFAIK this won't work if later you decide not to start:-)

Agreed,

Internal consistency can be checked in canStart(), but anything relying on the external world in doStart() cannot be tested, unless you lock the whole external world between the canStart() and doStart() methods...

Forunately, the particular case that is troubling me now is one of internal consistency...

This is a big problem. Especially, when you get into multi object GeronimoMBeans, which is why we have canStart. The issue is once you have decided you can start, we go through each bean and call doStart, which will interact with the external world (like creating sockets). If one of the objects in the GeronimoMBeans throws an exception, we have no reliable way to rollback the system to a "starting" state, so the component fails. I actually think that having the web service move to failed when the socket is in use is the correct outcome.

So, is the conclusion that canStart should check internal consistency but not talk to the outside world, and if a problem occurs in the outside world in doStart we throw a RuntimeException, and expect to get into the failed state?


Is there any particular reason we would or wouldn't want a specific declared exception here?


thanks david


-dain




Reply via email to