Bugzilla – Full Text Bug Listing
| Summary: | JMX instrumentation | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Eugene Chan <ewchan> |
| Component: | TPTP.monitoring | Assignee: | Matt Mings <mmings> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | antony.miguel, george.christelis, sluiman, smith, srinivas.p.doddapaneni |
| Version: | unspecified | Keywords: | plan |
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 2000 | ||
| URL: | http://www.eclipse.org/tptp/groups/Architecture/documents/features/hf_128731.html | ||
| Whiteboard: | |||
|
Description
Eugene Chan
We have some substantial concerns regarding the proposed implementation of this feature. My understanding of this is that a custom piece of UI will be written to allow the user to manage these resources through WBEM/JMX, through what is in all likehood going to be a custom funcationality interface. Such a custom interface does not allow for generic control or for generic UI. JMX and WBEM form a clean subset of the functionality that is provided through a variable interface. Such a generic interface would allow for a more generic mangement UI that could be used to manage any resource, or agent, where the extension interface is arbitrary. I realise that the variable interface has been in debate for a number of years now, yet we believe that this is the perfect opportunity to begin to understand it's potential so that a more complete generic control interface is developed, and not to implement another solution with another arbitrary interface. (In reply to comment #1) This is a really good point to bring out. The intent of this user interface is much like the intent of the generated Web Services explorer in WTP or a debugger interface. It is for the purpose of a developer of MBeans or WSDM resources to be able to unit test, poke and debug what they are developing. It is also for the the developer that wants to understand what the JMX or WSDM interface to an application can surface. This is not anything like a end user interface for these services. In th ecase of JMX, imagine what you would have used when you were writting your JMX client. In Java 5 there is a Swing application called JConsole that does this as well. We are simply providing that 'explorer" as an integrated part of the workbench development experience. To continue the example, this would have helped you figure out how to write your client and the app server provider with implementing it. It is not at all intended to be the end user interface or displace any of our current code in that area. The probe part of this to assist in the exposure of management interfaces. In fact the prototype that was used to drive the need for this work was simply probekit probes or AspectJ aspects plus JConsole as the developer interaction point. I hope this clears up your concern. Either way a AG review of the feature work will be planned to address any concerns shortly. This is our process ;-) My concern is over the control API: I've looked into JMX and WSDM extensivly in house. Let's not build domain-specific control APis, there is no upside to this, and only additional complexity. Surely, the control interface itself belongs in the Platform porject, with the various projects containing implementations thereof, subject to that generic interface being defined. The cart should not precede the horse. So what I propose we do is create a component in the Platform project which owns such a generic control API. Then we requie anything that exposes controls to do it through that API. This way we can build generic UI and runtime that doesn't have an artificial discrimination amongst the types of controlled entity. This in turn will reduce complexity and give us a lot more flexibility in a broad range of future usecases. The proposed concept of a generic control interface has already been widely socialised I believe now is the time to incorporate it. Do you have any objections to this? This feature will be scoped to providing the infrastructure for instrumenting resources/applications for JMX, using TPTP ProbeKit technology, and integrating it into the TPTP launch configuration framework. Therefore, it more appropriately should be done under the Monitor.Agents component. Feature 129450 will provide the UI for monitoring and managing the instrumented resource after it is launched. update target Reassigning to feature owner. This feature was approved by PMC to be added to the 4.2 Feature Plan. Retargetting to i3 when code will be fully tested. - Added JMX instrument model using probekit to deploy the JMX probe - Added JMX analysis type to the instrumentation collector - Added Test Case for JMX Closing |