avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject RE: [phoenix] JMX Management - the good, the bad and the ugly
Date Wed, 25 Apr 2001 16:02:02 GMT
At 05:32  25/4/01 +0200, Leo Simons wrote:
>> There is a few changes that are different from Leos proposal. They
>> important ones are the following. I hid most of the complexity behind a
>> facade of 3 methods rather than directly accessing MBeanServer
>> and creating
>> MBeans directly.
>Which we discussed and I would like to see in a different way but where
>I can understand why we don't do this =)

;) I got some more ideas on this .. wait for some thoughts that are
gestating ;)

>> DynamicMbeanFactory will throw exceptions when there is get/is/set methods
>> that don't conform to JavaBeans standard where I think it should just
>> ignore them (Leo can you confirm that???).
>No (sorry). According to the specification, an object that us not a valid
>JavaBeam/MBean will not be exposed.  have no problem with going against
>that spec...it'd mean we could never claim actual JMX compliance though.

We are compliant with JavaBeans (they say ignore anything that doesn't fit
pattern) however your implementation assumes that if they start with get
they MUST bet a getter (which is not true in our case). Same with is and set.

>I've typed three replies to that question before I got what you ment.
>having a
>DynamicMBeanFactory.create( Object object, Class clazz )

or preferrably

DynamicMBeanFactory.create( Object object, Class[] interfaces )

>I am wondering though - if a method/property should not be exposed through
>management, should it be public?

if it is *used* by other blocks it should be public but not necessary
manageable. (ie why would you need a createSocket() method to be manageable ;)

>There is another thing I want to do - I want to make it possible to
>specify your own description of the methods of the DynamicMBean.
>What I was thinking:
>DynamicMBeanFactory.create(	Object object,
>					Class clazz,
>					Set attributeDescriptions,
>					Set operatonDescriptions );
>where attributeDescriptions contains an attribute name and
>a description for each attribute, and
>operationDescriptions contains a method name and a
>description for that method for each method.
>There is an alternative. Simply keep
>DynamicMBeanFactory.create( Object object, Class clazz )
>and get those descriptions from methods of the object. So if the
>factory finds an object implements
>interface ClassDescriptor {
>	Set getAttributeDescriptions();
>	Set getOperationDescriptions();
>it uses its two methods for method/attribute descriptions.
>The first puts the responsibility for providing those descriptions
>in the hands of the container developer, the second in the hands of
>the component developer. The third option (do both) shares
>the responsibility.
>Finally, it is possible to have the ClassDescriptor as the basis
>for determining which attributes/operations are exposed:
>DynamicMBeanFactory.create( ClassDescriptor obj );
>I am thinking this may be the best option. We could have
>(Kernel, Deployer, Facility, Application) extend ClassDescriptor
>and (PhoenixKernel, DefaultDeployer, DefaultApplication &
>the facilities) implement it.

I am -1 on anything directly implementing ClassDescriptor (violation of
IOC) however I don't mind if they sit side by side. So you could pass in
descriptor when creating proxy.

>> Another thing we have to think about is how we define management
>> interfaces. One way is tagging them as manageable in .xinfo while another
>> way is having them extend ManagedService rather than Service directly. I
>> currently favour the second approach as it feels more heavyweight and I
>> don't see any need for "configurable" management interfaces. Thoughts?
>I'm all for #2, though blocks should be manageable as well so we need to
>have ManagedBlock as wel.
>It might make more sense to have ManageableService and ManageableBlock
>though - it is not guaranteed that the container of those components
>actually supports management.

But remember that Blocks implement Service (and thus ManagedService) so
they automagically inherit manageable facet. And if we implement above
method (ie pass in Class objects) the CLass objects will all be interfaces
and thus no need to have Block implement Managable or anything like that.

>> There is a few other issues to do with thread protection boundaries.
>> Currently methods etc execute in kernel thread - in the future we
>> will have
>> to make sure it executes in the appropriate thread (ie application thread
>> or whatever).
>I think the kernel management stuff should be in a "manager" thread,
>probably inside a "facility" group. The ApplicationManager should be
>in the "application" thread.

yup - me too ;)

>I just thought of another thing  - a block/app/service that extends
>an MBean interface or is its own DynamicMBean should be registered
>directly (change in ApplicationManager). The factory should check
>if an object passed in is a std MBean (which throws an exception)
>or a DynamicMBean (in that case, it should simply return the
>object passed in).


>I hope to have time for these changes this weekend...

kewl ;)


| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |

To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org

View raw message