>> (Don't know where to put this in, so I'll do it here)
Rickard, I'll take this for what it means and not feel bad for the rest of
your response...
You've made my finer points of return codes vs exceptions moot by moving to
a better design. I was nitpicking on something down near the bottom of the
pile. I'll try to keep to the top in the future since we are all good java
programmers...
I think instead of the previously put forth idea for a service which is
trying to start, to poll the services it is dependent on (how I understood
it), you are now advocating a service controller which knows all the
dependencies and starts each service when the services it is dependent on
are all available. Sort of point-to-point vs hub and spoke. Your approach
is cleaner - most of the logic goes into the service controller vs
distributing it in little bits in the various services - e.g. coding into
the Container service how to handle the Logger service being unavailable
when the Container service is trying to start. The actual services need
only receive start and stop messages and generate an "I'm going to stop"
message for the service controller before they stop.
Cheers
-----Original Message-----
From: Rickard �berg [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 31, 2000 1:00 AM
To: jBoss Developer
Subject: Re: [jBoss-Dev] JMX Status?
Hi!
(Don't know where to put this in, so I'll do it here)
Jay Walters wrote:
> Sounds like we're thinking of different things. If you consider the
startup
> case, either the service is there or it isn't and that code should all be
in
> one place and should use a boolean. Almost like a precondition in the
start
> or init method of a MBean. If you're in the middle of processing some
> entity bean request and you need the logging service and it's not there,
> that should be an exception. I believe you are addressing the second case
> rather than the first, and I was addressing the first.
You're all wrong IMHO. The requirements are preconditions for having a
service in "started" mode. When the requirements are met the "start"
method should be called, and when they are no longer met the "stop"
method is called. How the service handles this internally is
implementation dependent.
So, for example, what I did in XS was to have a service "service
control" that everyone depended on, and if that was started everything
was started (given that the other requirements were met), and if it was
stopped, the entire server got stopped.
I think that is how we should do this. There is one problem here with
the messages being asynchronous though: during "stop" one wants to first
send the notification that the service is stopping *before* it is
actually stopped, to allow any services to gracefully stop using it. For
example, if I want to stop the logging facility the other services that
uses it would want to stop first so that their "I have now stopped ok"
messages are shown.
/Rickard
--
Rickard �berg
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
