>
> 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
