> -----Original Message-----
> From: marc fleury [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, August 30, 2000 10:02 AM
> To: jBoss Developer
> Subject: RE: [jBoss-Dev] JMX Status?
>
>
>
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of
> Schaefer, Andreas
> > Sent: Wednesday, August 30, 2000 8:48 AM
> > To: 'jBoss Developer'
> > Subject: RE: [jBoss-Dev] JMX Status?
> >
> >
> > Hi
> >
> > I am not quite sure if there should be an order in the
> loading of the
> > MLets because the MLets should allow the user to load the MBeans
> > dynamically on demand. Therefore even when you have a load order in
> > your <MLET> definition it is useless when you want to reload or load
> > the MBean after the startup.
> >
> > IMO the MBean should not rely on the load order but try to wait till
> > the necessary MBean(s) are loaded to connect to them (I think the
> > MBeanServer sends a Notification Event when a MBean is loaded).
> > Now register your MBean as a Notification Listener (you can use
> > NotificationFilter to reduce the number of events received) and then
> > wait till its registered (OK, Ok, of course only when the
> MBean(s) is
> > not already loaded).
>
> Interesting you are saying that the work to be done in the MBeans at
> startup/init if it depends on other service can be coded in the
> "notifications"...
>
> maybe...but I am not sure I understand the objections to
> "dependent graphs"
> of MBeans
According to the JMX spec dependencies between MBeans should be defined
in the JMX Agent Relation Service. But at the moment I have no clear
picture what this service will do and how.
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.
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!
> > >
> > >
> >
> >
>
>
