>
> 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.
>
> 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.
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?
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.
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
