Hi,
Maybe i'm nuts, but just to throw some more fuel on the fire here...
When I first heard about the mbeans stuff I kind of wondered why it wasn't
set up through jini. Now I wonder even more.
How about putting more of the reponsibility for getting a service control
manager on the mbeans that wish to be managed? i.e., service controllers
listen for notifications of "I wanna have my lifecycle managed and I'm in
the XXX namespace" and proceed to manage those with acceptable namespaces.
All mbeans wishing to be managed are responsible for sending a notification
of this type when they are created and periodically thereafter (in case the
service controller isn't started yet or crashes and needs restarting). I
would suggest that the lifecycle management contract be subject to (jini
style) leases, but this may not fit into the mbean framework. A more
sophisticated selection scheme for who manages whom could involve sending a
(jini) entry describing what's needed as the object along with the
notification, instead of the namespace string.
just an idea.
David Jencks
On 2001.04.12 21:03:13 -0400 Scott M Stark wrote:
> >
> > We get bored of producing different types of train, some for France and
> some for England, and
> > decide that it would be easier to manufacture one type of Train which
> figured out which Country
> > it was in and adapted it's electric motor automagically to the
> available power-supply (perhaps
> > it had a diesel engine as well, in case it went where there was no
> electricity).
> >
> > Far-fetched, maybe, but complicated distributed systems are a reality
> and JBoss is the proof.
> > So why force the Train company to maintain two different Train
> codebases when just one can do
> > the job?
> >
> I agree with this completely, but your solution doesn't scale. Now add in
> the United States,
> Japan, Australia, Africa, ... How smart/adaptable can you make your
> motor?
>
> > Alternatively I might produce a LogService jar which I can drop into a
> number of application
> > servers where the service it contains it will publish the correct
> interface and happily deal
> > with logging issues as expected without recompilation. A win for the
> company shipping it - one
> > size fits all.
> >
> > Pretty much what I believe was intended when MBeans were dreamt up.
> >
> I agree, but without a better definition of service pattern discovery
> there are many holes
> is its pratical application. For example, application server N+1 comes
> out and I drop
> the LogService.jar into it. Its likely that this will not work and
> requires a new release of the
> LogService.jar. This is the MxN (application server)x(service) problem
> that the JCA is trying
> to address by defining standard service interfaces.
>
> >
> > All we need is to ascertain is whether or not an MBean requires
> ControlService to manage it's
> > lifecycle - correct me if this is wrong. Who it inherits from is
> irrelevant in the JMX world.
> >
> Now this an interesting way to state the issue and really points at the
> issue. Right now
> JBoss is effectively trying to manage all mbeans rather than letting
> mbeans locate and join
> the JBoss lifecycle service.
>
> > MBeans publish their interface via JMX.
> >
> > Standard and DynamicMBeans may be treated in exactly the same way by
> their client, since JMX
> > simply uses introspection to build the same interface for a standard
> MBean as a dynamic MBean
> > rolls for itself - am I wrong.
> >
> Your not wrong but I'm claiming that the introspection factilities of JMX
> amount to a weakly
> typed system and there is a difference between standard mbeand and
> dynamic mbeans. With
> a standard mbean I can ask if it implements a Java interface. With a
> dynamic mbean I
> cannot, at least not with the JMX RI. All I can do with a dynamic mbean
> is identify
> which attributes, fields and operations it supports. Knowing that an
> mbean supports
> init/start/destroy/stop methods tells me nothing about how they relate to
> the Service interface
> version of these methods. I am wrong in this statement?
>
> > > I can obtain its list of operations and check for the existence of
> init/start/destroy/stop
> > > methods but this guarentees nothing in the absence of some namespace.
> This is
> > > equivalent to assuming that an xml element is an XHTML anchor element
> simply
> > > because it has a href attribute. I believe there has to be some
> namespace aspect
> > > along with the check of operations existence to validate the
> conformance to a
> > > contract pattern.
> > >
> >
> > If you add a namespace requirement then I SHALL step in with Occam's
> razor - Which is simpler ?
> >
> > 1. adding one method - isJBossService(), and whichever out of init(),
> start(), stop(),
> > destroy(), that you require (regardless of whether you are Standard or
> Dynamic)
> >
> > 2. extending an interface if you're a standard MBean, existing in a
> particular namespace if
> > you're a DynamicMBean and implementing whichever out of init(),
> start(), stop(), destroy() that
> > you require - oh yes - and we have to fix classloading so that we can
> actually query the
> > standard MBeans statically about their inheritance hierarchy because
> they were loaded in a
> > different thread....
> >
> > Why should the MBean's client have to care whether it is Standard or
> Dynamic. JMX goes to great
> > lengths to make this transparent, what are we doing distinguishing
> between the two?
> >
> Because as a client of an MBean I only want to invoke a method on it if I
> know what the
> method does. A method isJBossService() is really just an attempt to
> collapse the org.jboss.util.Service
> namespace into a flat namespace so that the client knows what the method
> means. To
> me this is just a hack and throws away the strong type system Java offers
> for an expediant
> one off solution.
>
>
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
