Scott M Stark wrote:
> >
> > Nobody has yet given me a good reason why we should
> > force a DynamicMBean to decide who manages it's
> > lifecycle, at compile time (what you are suggesting)
> > or at deployment time (stick it in a config file)
> > instead of at runtime (which I am suggesting).
> There has to be some configurable aspect for a DynamicMBean to integrate into
> an arbitrary framework. Without this your left with introspection alone. This may
> be useful for a human with a browser but not for integrating into a framework.
<RANT>
I have no problem with the Service lifecycle being your integration point. Just the
way the
MBeans indicate that they support this lifecycle and want it managed by JBoss.
>
>
> >
> > If I have chosen to use DynamicMBeans it's because I
> > want to make decisions like this at run time. Do we
> > have an overwhelmingly good reason why this is such a
> > bad idea.
> >
> > I promise not to mention this again,
> >
> What algorithm have you come up with that allows for dynamic self configuring
> code? I would love to take a look at that! Feel free to speak to your heart's
> content on this issue as far as I'm concerned.
>
OK - You asked !
I don't have to come up with it, simply the fact that there is no good reason (no one
has even
tried to apply Occams razor here) to disallow runtime decision making about lifecycle
management, means that you should leave that avenue open.
But since you've challenged me - here we go.
Let's imagine integrating JBoss with a similar large system of MBeans, with a separate
lifecycle implementation and manager.
(a bit like connecting England to France via the Eurotunnel)
Suddenly someone decides it would be nice to have some Service which would be useful
to both
Countries, let's call it a Train.
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?
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 could go on.....
>
> Here is what I'm struggling with how to accomplish using a DynamicMBean. We
> are talking about acertaining whether an mbean supports the org.jboss.util.Service
> interface contract as an indication of its willingness to participate in the JBoss
>lifecycle
> abstraction. If we fix the class loader issues, a standard mbean can be queried for
> support of this contract in no uncertain terms. How can I make the same level of test
> for a DynamicMBean?
>
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.
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.
It would seem sensible therefore to use this fact to make a test that will work for
standard
and DynamicMBeans to ask them if they wish their lifecycle managed by ServiceControl.
By calling a method isJBossService() via the JMX framework, on an MBean you achieve
this :
1. You don't need to know whether the MBean is standard or dynamic - the MBean should
only be
managed by ServiceControl IFF it returns 'true' successfully.
If you want to make this decision at compile time for standard MBeans - stick public
boolean
isJBossService() {return true;} into MBeanServiceSupport, and define the interface in
Service.
If you want to make it a deployment decision - stick it in a config file, and override
isJBossService() to return the value stored in your config.
If you want to make the decision at runtime, override JBossService() to do so.
2. 3rd party MBeans which know nothing about JBoss, will not publish this method and
will be
ignored.
3. JBoss Service DynamicMBeans which implement this, return 'true' and implement the
lifecycle
methods incorrectly are just as flawed as standard MBeans which do the same.
4. MBeans which find the Service defined lifecycle useful, but do not wish to be
Services may
use it and decline management.
etc........
This fascination with isA(Service) is fine in a static environment like standard java
or C++,
but when using a dynamic, introspective environment like JMX, however, standard
inheritance
issues go out of the window. the published interface means everything, the inherited
one
nothing.
>
> 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?
So.
I believe that I have shown that:
My proposed solution is more simple (one method works for Standard and Dynamic MBeans)
My proposed solution is more powerful (it allows DynamicMBeans to react to their
environment
and make a runtime decision about how best to implement their Service).
</RANT >
OK.
That is definitely my last comment on the subject ! no matter who invites me to start
ranting
again - I WILL decline. I've tried to explain why I think this approach is better. If
everyone
is still convinced it isn't then I guess I should retire and let democracy have the
day.
Thanks for your patience,
Jules
P.S.
Apologies to anyone who thinks this has got out of hand - I am surprised at how much
bandwidth
this this thread has consumed. Someone should have just shouted at me to sit down and
shut-up !
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
