Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Development" <avalon-dev@jakarta.apache.org>
From: "Leo Simons" <mail@leosimons.com>
To: "Avalon Development" <avalon-dev@jakarta.apache.org>
Subject: RE: [phoenix] JMX Management - the good, the bad and the ugly
Date: Wed, 25 Apr 2001 17:32:59 +0200
Message-ID: <LPBBIELKDCIBOMAGCPIOOELDDEAA.mail@leosimons.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-Reply-To: <3.0.6.32.20010425191555.008078e0@mail.alphalink.com.au>
Importance: Normal

> I have mostly merged in Leos JMX management stuff to the main trunk except
> for a few things (which should be easy enough todo). So we are getting
> closer - Yea !!!

=)

> 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 also moved most of the functionality into the "SystemManager" component
> that sits at the same abstraction level as Kernel. This is responsible for
> instantiating mBeanServer, exporting it via RMI and binding it in
> nameserver. There is also a kernel Facility (ApplicationManager) that
> exports the sub-components of Application (ie Blocks).

nice ;)

> RMI is insecure by default - we can make it more secure over SSL and
> requiring certain certificates so I hope we can solve this issue.

I'm counting on it...I've never heard of this being a problem so...

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

For that reason, it might be worth investigating how hard it is to change
our objects to become valid beans.

> I also want some way of limiting what attributes/operations/notifications
> are exported. The way I think is best is by passing in interfaces to
> DynamicMbeanFactory which will introspect on those interfaces rather than
> directly on the object itself. Thoughts? This way we could limit ourselves
> to set management interfaces. Leo do you want to hack at
> DynamicMbeanFactory to add this??? :)

I've typed three replies to that question before I got what you ment.
having a

DynamicMBeanFactory.create( Object object, Class clazz )

method is certainly an option.
I am wondering though - if a method/property should not be exposed through
management, should it be public?


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.
So, which one is best?

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

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

> I think we will be able to do this when I get around to
> revamping the ThreadManager/ThreadPool/ThreadContext classes.

have no doubt ;)

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

cheers!

LSD


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