You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Peter Donald <do...@apache.org> on 2001/04/25 11:15:55 UTC
[phoenix] JMX Management - the good, the bad and the ugly
Hi,
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.
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).
Now most of this is going to be really easy to enable (2-3 lines in a few
places and a few marker interfaces). However we have a few things we have
to work out.
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. For this
reason RMIAdaptorImpl now extends RemoteServer rather than
UnicastRemoteServer and we have to manually export the object.
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???). Consequently no objects are
exported because they all have these get/is/set "features".
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??? :)
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?
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 we will be able to do this when I get around to
revamping the ThreadManager/ThreadPool/ThreadContext classes.
Anyways thats it for now - congrats to Leo on JMX stuff ;)
Cheers,
Pete
*-----------------------------------------------------*
| "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
RE: [phoenix] JMX Management - the good, the bad and the ugly
Posted by Peter Donald <do...@apache.org>.
At 09:17 25/4/01 +0200, Leo Simons wrote:
>> >> 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 fixed that, didn't I?
>whoops...old copy in the CVS...ouch.
;)
>addendum: that might be tomorrow...actually thought it was the day
>after tomorrow today, so that my imaginary tomorrow would be the
>weekend. This is of course not the case as today is today and that
>other tomorrow is actually be a few days away which is why I did not
>say what I ment. (if you followed that on the first run, congrats.
>You're used to structural programming ;)
alternatively you used to be a logic student ;)
Cheers,
Pete
*-----------------------------------------------------*
| "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
RE: [phoenix] JMX Management - the good, the bad and the ugly
Posted by Leo Simons <le...@wanadoo.nl>.
> >> 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 fixed that, didn't I?
whoops...old copy in the CVS...ouch.
Got it covered...I'm actually now using the same array and filtering out
javabeans methods. Whatever is left gets to be an operation. I'll commit
soon.
I'm still thinking about the exact impl. It kinda makes sense to use
java.beans.Introspector. More to follow...
> >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 )
ahh. Really tired right now... ;)
> 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.
After more thought, I am as well. Figured out a recursive function
that will do the other one quite nicely...I think.
> 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.
yupyup.
> >I hope to have time for these changes this weekend...
addendum: that might be tomorrow...actually thought it was the day
after tomorrow today, so that my imaginary tomorrow would be the
weekend. This is of course not the case as today is today and that
other tomorrow is actually be a few days away which is why I did not
say what I ment. (if you followed that on the first run, congrats.
You're used to structural programming ;)
greetz,
LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: [phoenix] JMX Management - the good, the bad and the ugly
Posted by Peter Donald <do...@apache.org>.
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).
agreed.
>I hope to have time for these changes this weekend...
kewl ;)
Cheers,
Pete
*-----------------------------------------------------*
| "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
RE: [phoenix] JMX Management - the good, the bad and the ugly
Posted by Leo Simons <ma...@leosimons.com>.
> 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