Ají is Jolokia UI which contains a Dashboard with various textual and graphical widgets and an MBean Browser for an easy exploration of the JMX space. It is an add-on to the normal Jolokia agents and gets deployed along with it.
Well, this is how it will look like. At the moment there is not much here and we are still in the design phase. In this README you will find a description of the planned tech stack, description of the use cases to be implemented, a rough roadmap and some ideas for future versions. And how you can participate:
Development is coordinated over two channels:
- A mailing-list firstname.lastname@example.org. Please use Google Groups for subscribing.
- A scrum based task distribution with help of Ají's JIRA. The current planned stories and task can be found in the planning board.
- Use IRC channel
#jolokiafor live discussions on Freenode
This list of a high level goals serve as guideline for the overall development. These are not connected to a particular use case, but always part of the acceptance criteria of each user story
- Self contained - it is essential, that Ají gets deployed along with the Jolokia agent it uses as backend. This implies that there will be 4 variants, each for each Jolokia agent variant.
- Small - Ají + Jolokia <= 350k.
- Good UX - A focus should be on keyboard navigation, appropriate (and maybe innovative) UI elements and an overall good user experience. Difficult.
- Beautiful - it should look good. This means there should be put efforts into the choice of things like fonts, spacing, UI element arrangements, fluid behaviour.
The first two use cases we want to cover is a Dashboard and a MBean Browser.
The Dashboard provides timeseries chart and other widget which can be grouped in various sections. There are widget that came out of the box (Memory usage, thread count), application server specific widgets and others can be defined by the user. The user can arrange the widgets freely on the dashboard and the configuration is saved locally in the browser
See AJI-3 for details.
The MBean Browser allows for easy navigation to an MBean and applying certain actions like reading/writing of attributes or execution of operations. Keyboard navigation is easily possible.
See AJI-1 for details.
- Plugin architecture
- Development Tools
- Thread Dump Analysis
- Memory Analysis
- App-Server specific views
Ají is also a playground project for having fun with the latest stuff, even when it is not matured. That's our fun part ;-). Also, browser compatibility is not a main goal and Ají will require decent HTML-5 capabilities.
Armed with this freedom, and after quite some time of research and evaluation the following tech stack settled won, although nothing is really fixed while we are going.
As already said, Ají will be a SPA (single page application) with no logic on the server side and everything running on the client. The Jolikia agent is the server part (with maybe some slight addition for supporting some use cases).
Here now the proposed stack. It is not really settled down, maybe you
have some strong opinions here ? Let us know at
I tried it and I like it. My only concerns where about an extended round-trip due to the extra compilation step and debugging hurdles for correlating back to the CS source. The former can be avoided by a proper build process and workflow (see below), the later is (currently) a non-issue since it is really straightforward from the generated JS code to the original CS code.
An initial example is checked in:
$ cd aji/war $ mvn jetty:run ..... [other terminal:] $ cd aji/war $ mvn brew:compile -Dbrew.watch=true ..... [other terminal:] $ vi aji/war/src/main/coffeescript/aji/jolokia.coffee [edit and save] [watch output on terminals] [reload http://localhost:8080/aji/app/index.html or so]
The main ingredients are a Maven Jetty Plugin with customized
contextHandler configuration an the Brew Plugin for compiling
Cofeescript source. The later includes also a watch mode for
periodically checking the CoffeeScript source.
- Seems to have the largest momemtum
- Small enough
- Sufficient for our needs
An alternative would be spine.js.
Whether Ají requires an additional layer as application framework on top of backbone.js has not yet been evaluated: Thorax, Marionette and Chaplin. On a first view, Chaplin seems to be quite charming.
Everybody uses Bootstrap these days, there even already quite some additions to the hype. Since I'm not a design expert (although I highly appreciate good design), we will go this road as well with appropriate adoption (there must be a chili somewhere ;-). This implies that we will use Less as well, which a good thing on its own.
There are tons of charting libraries out there. However, most of them have memory issues if the charts are updated periodically (which is the common use case for us). That is the major reason, why Tomasz Nurkiewicz has chosen Highcharts as charting library for its Jolokia Dashboard Sample. However, HighCharts is not free and not compatible to an Apache License, so that it is not suitable for our purposes where we have to package and distribute the charting library along with the agent.
Another nice approach for modern browsers is to use SVG based charting (instead of canvas based one). Here, d3.js is an outstanding support library, however it is rather low-level.
In order to let the door open for various graphing library some sort of abstraction bei an plugin API would be nice as described here
Since server side persistence is not yet in focus, for persistence needs like the dashboard configuration HTML-5 client side storage should be used. The first option should be IndexedDB with an fallback to LocalStorage and cookies. Why IndexedDB should be the first choice is laid out in this post whose arguments I can follow.