> On the other side I think the MBeans should be as independent from each
> other as possible because this allows the user (administrator) of such
> a system (like jBoss) to define the system how he likes. When a MBean
> is able to detect MBean dynamically (MBean Interface) then the
> administrator
> can dynamically load or unload MBeans to the actual needs instead of
> changing the jboss.conf file, shut down and start up the server.
>
You know it sort of makes sense, I have a natural dislike for graphs anyway
:)
So you would define the initialization that depends on other services in a
method called only when the set of services that it needs have been
initialized. Of course that means that you would want to register interest
with all the services you are looking for, and deal with multiple callbacks
to be sure to trigger that operation only and only when ALL the services
have been offered.
At the same time I would see for a nice service where you provide a set of
services that are needed for a particular configuration. You would be
notified immediately through a boolean return that all the services you
requested are already on line. And what you register is a callback
interface with methods such as "public void allOnline()", equivalent of
"dinner is served" for the service, but also maybe a "public boolean
serviceGoingDown(Service orSomething)" as soon as one of the services in the
required set is going down. This way you don't have to code the
notifications yourself, it is a JMXBean of sorts.
If this type of interface takes care of most scenarios, it might be helpful
to give this "Set" approach a try at beating the "graph" approach. As you
point out Andy it's main advantages is increased simplicity and robustness
in defining depencies (a Set with all required services as opposed to a
"parent-child" graph), and also that these operations can be done
programmaticaly at run-time and not through the conf file. Can somebody
submit a case to me when a graph dependency cannot be implemented by a nice
and simple Set approach as pointed out above?
he he, back to doco, way to go Andy, way to go!
PLgC
marc
_____________________
"Andy, dis moi oui!"
-Les ritas mitsoukos-
_____________________
> Let's assume that a MBean needs a Message Queue (JMS interface(s)) then
> it can wait till a Message Queue MBean is loaded/registered. When the
> administrator needs to replace the actual Message Queue (performance
> or reliability) then he/she can unregister the actual Message Queue
> MBean which suspend all the activity on our MBean. Then he/she loads
> and register another Message Queue MBean and then our MBean can resume
> its activities (I know it is a little bit a artificial scenario).
>
> Mad Andy
>
> >
> > marc
> >
> > >
> > > You can make it even more advanced when you also listen to
> > unregister
> > > events of the MBean(s) you depend on to disconnect your
> > MBean from the
> > > other. Therefore a dynamic reload could be implemented and
> > jBoss becomes
> > > a real pluggable EJB Server.
> > >
> > > Have fun
> > > Mad Andy, good Pizza
> > >
> > > > -----Original Message-----
> > > > From: Aaron Mulder [mailto:[EMAIL PROTECTED]]
> > > > Sent: Wednesday, August 30, 2000 5:27 AM
> > > > To: jBoss Developer
> > > > Subject: [jBoss-Dev] JMX Status?
> > > >
> > > >
> > > > One of the things I just fought through to get the
> test beans to
> > > > use Minerva was the JMX startup order issue. There's really
> > > > no way around
> > > > it without horrible hacks. Do we have any idea when the
> > > > final JMX release
> > > > will be available? I don't think we can call jBoss
> > production-quality
> > > > until we nail the startup order.
> > > >
> > > > Aaron
> > > >
> > > > P.S. I'm supposed to finally get a phone line on Friday, so I
> > > > should be
> > > > able to get internet access from home again soon! Woo-Hoo!
> > > >
> > > >
> > >
> > >
> >
> >
>
>
