axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giridharan Rajagopalan <>
Subject Re: Requirements on JMX API
Date Sun, 07 Mar 2004 10:46:49 GMT
Few questions:
>>enum registered services
What might be the possible services that can be accorded in this?
Some of my observations are:
1.Providers like RPCProvider and MsgProviders can be monitored.
Included services are Message & Wrapped services.

>>examine service config, change it,

>>usage logging of service load (and failures)
Provide seperate interfaces for logging of service loads.
Does this mean every request needs to be logged along with the action ?

>>any other things worth monitoring to trigger management alerts.
Can you be more specific on this?

Thanks & Regards

Steve Loughran <> wrote:
Giridharan Rajagopalan wrote:

> Hi All:
> I am new to this group.
> Have been working in Axis for the past 1 year.
> Could somone let me know the requirements on the JMX API that needs to 
> be done , as part of Administration & Monitoring of Axis.

> Few of my questions are:
> 1. Does this JMX API provide the user exit feature of adding custom API 
> handlers?

if you want it :)

> 2. What are the components of Axis or webservice that needs to be 
> managed using this?

Good question. I dont know. I'd expect the core bits of the system to be 
manageable to see what is going on, to examine and manipulate endpoint 
configuration, etc. Things that would be good

-enum registered services
-examine service config, change it,
-usage logging of service load (and failures)
-any other things worth monitoring to trigger management alerts.

Client side monitoring would be useful too -if you have JMX management 
for your app, you want to be able to manage all of it.

> 3. Is there any framework design on the actual implementation?

No. But if you look at there is a class there that uses 
reflection to find the method in MX4J to register any object as a JMX 
management point.

My goal was to add manageablility to base system components (probably 
through new interfaces or helper classes), but not make the core system 
dependent upon having JMX around.

> I would luv to get things started on this requirement.

I think a lot of people would welcome JMX support. Assuming your own 
project needs JMX, your own requirements should provide a good focus for 
JMX integration.

> Thanks & Regards
> giri
> Please raise your voice against SCO Issue.Register and discuss NO2SCO at

I think dims has already made his position on that entertainingly clear :)

Please raise your voice against SCO Issue.Register and discuss NO2SCO at

Do you Yahoo!?
Yahoo! Search - Find what you’re looking for faster.
View raw message