Markus, great feedback. Thanks! Responses below... On Thu, Nov 19, 2009 at 11:10 PM, Markus Kohler <[email protected]>wrote:
> Hi Andy, > See my comments below... > > On Fri, Nov 20, 2009 at 3:55 AM, Andy the destroyer < > [email protected]> wrote: > > > FYI & RFC > > > > I have finished a REST api for generic jmx MBeans. It allows for listing > > mbeans, getting mbeaninfo, reading and setting attributes and invoking > > operations with parameters that can be represented as Strings ( i.e. > > String, > > Long etc. serialized classes don't count). > > > > Before I send to code to Richard I would like some feedback to see if I > am > > missing something or should do something different. > > > > Here is the api and sample returns. Bad requests or errors will return > > BadResponse. > > > > GET /jmx/mbeans - returns a list of mbean names > > > > I would suggest returning the urls in the next line directly. That would > make it compliant with the HATEOS constraint. > The advantage is that the client does not need to know how to construct the > URL. > I agree. Good idea. I will work on making this HTTP API more RESTful. > > > > GET /jmx/mbean/[mbean name]/info - returns MBeanInfo for specified mbean > > GET /jmx/mbean/[mbean name]/attributes - returns attribute name and > string > > values > > > > > Would it make sense to support GET /jmx/mbean/[mbean name] as well, which > would return everything? > I originally did that but due to a bug in lift I could not end a URI with the bean name so I just included everything separately. I got a message from DPP yesterday saying the bug was fixed. I will add it. > > > > POST /jmx/mbean/[mbean name]/invoke/[operation name] > > <Params> > > <Param>pone</Param> > > <Param signature="java.lang.Long">123</Param> > > </Params> > > > > POST /jmx/mbean/[mbean name/set - sets a single attribute > > <Attribute name="attr" value="val" /> > > > > POST /jmx/mbean/[mbean name]/set - sets multiple attributes > > <AttributeList> > > <Attribute name="att1" value="val1" /> > > <Attrubute name="att2" value="val2" /> > > </AttributeList> > > > > > Hmm, partially updating a resource is an recurring pattern. I'm not a 100% > sure yet what would be the best way to do it, but couldn't one just do it > without the "set" postfix? > I'm not sure I understand what you are saying. With the above resources I am just providing an API to MBeanServer.invoke, MBeanServer.setAttribute and MBeanServer.setAttributes. > > > > == SAMPLES == > > > > GET /jmx/mbeans > > > > <esme_api operation="mbeans" success="true"> > > <MBeans> > > <MBean name="java.lang:type=Memory"/> > > <MBean name="java.lang:type=GarbageCollector,name=Copy"/> > > <MBean name="java.lang:type=MemoryPool,name=Code Cache"/> > > <MBean name="java.lang:type=Runtime"/> > > <MBean name="java.lang:type=ClassLoading"/> > > <MBean name="java.lang:type=MemoryPool,name=Perm Gen [shared-rw]"/> > > <MBean name="java.lang:type=Threading"/> > > <MBean name="java.util.logging:type=Logging"/> > > <MBean name="java.lang:type=MemoryPool,name=Perm Gen [shared-ro]"/> > > <MBean name="java.lang:type=Compilation"/> > > <MBean name="java.lang:type=MemoryPool,name=Eden Space"/> > > <MBean name="org.apache.esme.stats:type=Stats"/> > > <MBean name="StatsAgent:name=htmlAdaptor,port=9092"/> > > <MBean name="com.sun.management:type=HotSpotDiagnostic"/> > > <MBean name="java.lang:type=GarbageCollector,name=MarkSweepCompact"/> > > <MBean name="java.lang:type=MemoryPool,name=Survivor Space"/> > > <MBean name="java.lang:type=MemoryPool,name=Tenured Gen"/> > > <MBean name="java.lang:type=MemoryPool,name=Perm Gen"/> > > <MBean name="java.lang:type=OperatingSystem"/> > > <MBean name="JMImplementation:type=MBeanServerDelegate"/> > > <MBean name="java.lang:type=MemoryManager,name=CodeCacheManager"/> > > </MBeans> > > </esme_api> > > > > GET /jmx/mbean/org.apache.esme.stats:type=Stats/attributes > > <esme_api operation="mbean" success="true"> > > <MBeanAttributes name="org.apache.esme.stats:type=Stats"> > > <MBeanAttribute value="1" name="counter_userCount"/> > > <MBeanAttribute value="1" name="counter_liftSessions"/> > > <MBeanAttribute value="1.0" name="gauge_users"/> > > <MBeanAttribute value="1.0" name="gauge_listener"/> > > </MBeanAttributes> > > </esme_api> > > > > GET /jmx/mbean/org.apache.esme.stats:type=Stats/info > > <esme_api operation="mbean" success="true"> > > <MBeanInfo name="org.apache.esme.stats:type=Stats"> > > <MBeanAttributes> > > <MBeanAttributeInfo isIs="false" type="java.lang.Long" > > description="counter" > > isReadable="true" name="counter_userCount" isWritable="false"/> > > <MBeanAttributeInfo isIs="false" type="java.lang.Long" > > description="counter" > > isReadable="true" name="counter_liftSessions" isWritable="false"/> > > <MBeanAttributeInfo isIs="false" type="java.lang.Long" > description="gauge" > > isReadable="true" name="gauge_users" isWritable="false"/> > > <MBeanAttributeInfo isIs="false" type="java.lang.Long" > description="gauge" > > isReadable="true" name="gauge_listener" isWritable="false"/> > > </MBeanAttributes> > > <MBeanOperations> > > <MBeanOperationInfo impact="ACTION" description="Remove all Counters, > > Timers, Gauges and restart gathering timestamp." > > returnType="java.lang.String" name="clear"> > > <Signature> > > </Signature> > > </MBeanOperationInfo> > > </MBeanOperations> > > <MBeanNotifications/> > > </MBeanInfo> > > </esme_api> > > > > ================= > > > > There is no security on the api. This obviously should not stay like this > > and should only be accessable with an administrator account. > > > > I tested it with the Stats MBean and the java.util.Logging MBean and it > is > > working. I can access stats, reset them and change logging levels. > > > > It would be nice to be able to change runtime properties though JMX > however > > most of the Lift and ESME code uses vals and immutable data structures > that > > are set when the app is originally loaded. The lift Props object used by > > esme is totally immutable after it is constructed. It is worth thinking > > about switching to a property api like Configgy which uses mutable data > > structures for properties. > > > > We could change in real time things like resent & links period, refresh > > intervals, analyzer settings like long query time, db connection pool > sizes > > etc. > > > > I didn't enable sending serialized objects through the REST api because > it > > seems like more trouble than it's worth. Besides that sort of JMX > > functionality is only useful between servers and this api is really just > > for > > the cloud environment like stax which doesn't allow you to bind to ports. > > > > I welcome any comments or suggestions of Stats or JMX features to add > > before > > I send the code to Richard. Should invalid requests return specific error > > messages or just BadResponse? > > > > Thanks, > > Andy > > > > > Regards, > Markus >
