Thanks for the feedback! Responses below. Andy On Thu, Nov 19, 2009 at 8:31 PM, Richard Hirsch <[email protected]>wrote:
> Looks great. > > >>There is no security on the api. This obviously should not stay like this > and should only be accessable with an administrator >>account. > > You are probably correct about the necessity of authorization added to > the interface but this might just be necessary for those interfaces > that write / change settings, What about using the lift authorization > mechanism here to distinguish it from the ESME user base? > > I haven't played with lift authorization yet. I am not sure how it works. I know to adhere to being RESTful we should use WWW-Authenticate. I don't know if lift supports this I will look into it. I so far left security as an after thought while I nail down the api. > >It is worth thinking about switching to a property api like Configgy which > uses mutable data structures for properties. > > This is a good idea. First we must determine which properties might be useful to be to change on the fly. I once started a list of such properties in the wiki. I'll finish it and publish the link. > Cool. > I really like the fact that JMX data is available via REST. I started > looking and found there is a a related JSR 262, Web Services Connector > for JMX Agents where the author examined rest-based access > ( > http://blogs.sun.com/jmxnetbeans/entry/restful_access_to_jmx_instrumentation > ). > The author has some interesting ideas (for example, creating an Ajax > based application to follow the JMX changes), I also found a very old > Google Code project that looked at this topic > (http://code.google.com/p/polarrose-jmx-rest-bridge/) where the author > mentions using Cacti (Cacti is a complete network graphing solution: > http://www.cacti.net/) to graph the material. Maybe we could try and > use Cacti as well to graph our data. > Yes, I also saw that project. We should be able to try Cacti. I can see if I still remember all the horrible PHP coding I did for years. ( Cacti is in PHP ) > So you could probably create a very cool administration application > for ESME (written in whatever language you want) that allows you to > monitor everything in ESME. What I'd like to see is a very basic admin > app (maybe separate from ESME). Creating more complicated admin apps > would then be a business opportunity for someone. > > What we have to look at as well is how to deal with those enterprises > that already have monitoring environments in place (for example, > SolMan). I don't know if such applications can deal with REST. I'll > do some research here. > It could be used to integrate a third party monitoring system with ESME in a cloud env. > So, in my opinion, it looks v. cool. Send me a patch and I'll commit it. Once we get the foundation up and running, we should talk about what other measures we want to monitor. > I should have some time this weekend to work in the suggestions from this email thread and I will send a patch when I finish. Thanks again for the input. -A > > Thanks. > > D. > > 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 > > GET /jmx/mbean/[mbean name]/info - returns MBeanInfo for specified mbean > > GET /jmx/mbean/[mbean name]/attributes - returns attribute name and > string > > values > > > > 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> > > > > == 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 > > >
