Home‎ > ‎

Open source

Alternatives to Elasticsearch X-Pack (Elastic Stack Features)

posted Oct 15, 2018, 1:31 PM by Jageshwar Tripathi

X-Pack (now known as Elastic Stack Features) as a plugin provides several functionalities to Elasticsearch deployment such as:
  • Security
  • Alerting
  • Monitoring
  • Reporting
  • Graph (network)
  • Machine Learning
  • Elasticsearch SQL
X-Pack or its new name Elastic Stack Features is not free. After trial license expiry lots of features of X-Pack become disabled. Price of X-Pack is not disclosed on its website and one need to inquire about it from the company but there is license cost of significant amount. If you don't have that much money to spend , you can still enable some of those features by using other cheap or free plugins which are open source.
X-Pack Security - Alternative “SearchGuard” 
X-Pack Graph - Alternative “Kibi Community” , "Kbn_Network Kibana 5"
X-Pack Machine Learning - Alternative "Knowi"
X-Pack Altering - Alternative “ElastAlerts” 
X-Pack Monitoring - Alternative “KOPF or Cerebro” cost FREE

Java Frameworks Feature List

posted Mar 31, 2013, 8:34 AM by Jageshwar Tripathi   [ updated Mar 31, 2013, 10:19 AM ]

Java code review tools

posted Mar 31, 2013, 8:33 AM by Jageshwar Tripathi

One of the reason behind failing projects is the fact that people don't do lot of reviews and when they find bugs in system testing phase just jump to code review. At this time it is not possible to fix all those issues in code.

People may think that what is impact of comments or naming conventions but poor code clarity, no comments are the reasons why at later stage even people who wrote the code can not understand code written by themselves and if some one else is working on the code written by others then it is a serious issue.

Advantages of code review tools
Tools not only review basic standards and conventions but they can also validate your design decisions whether implemented in code or not. Issues important for performance and memory can be caught through tools.
Most important is that full coverage of code review can only be possible in a big project and it saves your money too. If you have 800 Java files in your project you can understand manual review even if done for month can not cover 100% code. But tool takes hardly 10 to 15 minutes to review 700 Java files.

Tools available
Although many tools are there in the market for Java Code Review but I will mention only few which either I evaluated or got feedback from my teams, other folks.
Following is the list of Java Code Review Tools:-

Check Style
Jalopy (It is a source code beautifier not a code review tool.)
I would like to mention here that selection of tool suitable for you is important but more important is use of tool and implementation of code review process.
Different tools have different advantages and are more suitable for specific use.

1. Best thing about hammurapi is no dependency on any IDE and can be run as Ant task from any IDE.
2. Another very useful feature from project management point of view is that results of review are stored in a database and published through web application. This way whole project team and project manager can see the results and multiple runs of the project can be compared.
3. There is no requirement to compile it for review. To review code you need source files only not all the dependency libraries. It makes reviewer's life simple.
4. Time taken in a review is also not too high. With hammurapi version run on P-IV machine 800 it takes 11 minutes for review. This time may vary depending upon machine configuration. As per my experience its performance is good.
5. It provides review reports in two ways:- 1. Summary of the violations. 2. Individual code file with all violations on that code file. Here with hammurapi a developer can see all the violations on a source file written by him and by clicking on violation can directly go to the section of the html report (having javasource embedded) to see which piece of code is having problem.
6. In later versions of Hammurapi eclipse plugin is available only for development purposese but for commercial you it requires subscription (fee).

1. PMD is also a powerful tool and much talked about tool for Java code review.
2. Eclipse plugin is available so tool can be used from within IDE. It may help developers better by allowing them to see the violations on IDE and going directly to actual source like where problem is.
3. Web report is not at all available through a database store so you can not have results stored in a database to be compared later on.
4. You can generate off line html page of review report but source is not linked to it. You will have to use some tool to convert your java source files to html. Again here is a problem:- review report generated by PMD will have hyper links to the html of source but you can not navigate to source html by clicking on report likes because generated html from source will have extension .java.html
Solution:- You can use glean with Java2HTML to generate PMD report along with generation of source HTML. This way above mentioned problem can be avoided.
5. In PMD you can write your own rules either in Java or using XPath expression.
Both the tools provide similar default rules and new rules can be created.

With my experience hammurapi has one great advantage and that is:- results are stored in a database. Another good thing is it comes bundled with everything, only you need to do is run the installation. One thing that may not suite you in longer run is that its eclipse plugin for commerical use is licenced and you will have to pay for it. For some new review rules also they can charge but it was a plan only till last update I had.

PMD can better help developers in IDE because eclipse and other IDE plugins are freely available. If you are using gleen along with Java2HTML pages and you can take some pain to configure glean properties (feedback) file then PMD is most rich in terms of more rules available, ease of rules creation. Even results can be deployed in tomcat or any other java web container using an Ant task. See my post to see how it all can be done.

Check Style
Historically it was a code layout checker but with new versions it can check many aspects of Java code. There are standard and optional checks available. Plugins written by third parties for Eclipse/WSAD, NetBeans, Borland JBuilder, IntelliJ Idea and few other IDE's are available.

It is a source code beautifier not a code review tool. Even if it is not a code review tool I have listed it here to clarify this fact. Plugins for Eclipse, JDeveloper, JEdit are available.
Its commericial version is also available with more features.

Strategy for code review
Clearcut strategy and its implementation is most importnat for code reviews otherwise doing them is waste of time. Following things should be kept in mind:-
1. Plan for reviews. Identify reviews as a task in your project plan.
2. Keep practical time duration and effort for review and issue closure activity.
3. Setup code review tool early in the project life cycle. Before start of coding tool should be setup.
4. Let your developers know what are the things to keep in mind, means rules to take care of so that they should minimize injection of more violations. Also give them training of tool.
5. Ask developers to run the tool frequently (e.g. 2 times a day). Also run tool on complete code and publish it on central machine. For it you should setup a project website where along with code review results other important documents can be stored (e.g. html version of project plan, published design model etc). In most of the companies people don't have modeling tool license for every developer so publishing model as html is a good option.
6. Most important is closer of violations and it should be done on daily basis only then people will stop injecting more bugs in future.

Innovations and a bitter truth

posted Dec 24, 2010, 10:27 AM by Jageshwar Tripathi   [ updated Mar 28, 2012, 2:08 PM ]

Aim behind open source initiatives and community was to make standards and develop software on open standards. Benefit in open standard software was portability, re usability and elimination of vendor dependency.

Lot many open source initiatives and projects came in last decade. Most of them were really great initiatives. These projects set an example how community can drive the technology and what are the benefits of open source.

Dark side

Previously maturity of open source tools was a problem. Support, proper documentation and trained workforce were also some issues raised by people but these are non issues now a days with many open source software tools available.
Issues now a days are- it is becoming incompatible, non reusable, non portable, proprietary and most importantly expensive.


When open source was started large number of vendors were also involved in it and were promoting it, but they were promoting it to fight with another proprietary non open source house (you can easily guess who). At that time these vendors (supporter of open source) were interested in selling hardware. Now when open source became mature, great and worth selling, these vendors are trying to sell open source means they want to earn money from it.

Vendors have made "Java" language itself incompatible on various platforms because every one implemented JVM according to his own wish. Idea behind letting others implement JVM was to promote better quality of JVM but strict implementation of specification was expected so that anything developed on Java can be ported on any platform and JVM.
Now they have made their own JVM and if you have written some application on a specific vendors JVM sometimes you will feel that now it is risky to move to other. Few years back it happened but JVM is not an issue now a days. Issue is what happened next.....

J2EE specification was a great promise to the business community that once an application is written it can be ported to any J2EE compliant application server.
Now every vendor has written J2EE application server according to his proprietary libraries and they only promote those proprietary things.

What is the disadvantage

Most promising thing about open source (Java) is diluted that is "write once run anywhere".

New tools are coming every day and developers have to learn tools every day. Organizations ask them:- "did you work on this (xyz Java Application Server)) server?" How funny about open standards?
So you don't have large number of common work force but have specific folks and then they become costlier not only because they ask for more money but because you don't have sufficient numbers of developers at right time.

Now next dangerous step vendors are moving towards is:- making hit open source software proprietary by imposing worst licensing. Either vendors have acquired these open source organizations or these organizations themselves became money friendly vendors.


Community should stand firmly to protect work done by community and save open source.

Vendors should realize that things should be on standards not on proprietary specifications. In manufacturing industry manufacturers don't use different specifications or standards and in fact various parts are standardized. You can use same tyres on so many models. Manufacturing or any other industry (either mechanical or electrical) are surviving and making life better by creating difference with quality, real value and benefit.

At least industry should finalize common specifications of core things. There is a huge scope of making the difference so basic things should not be used to make a difference.

If industry and these vendors will not think about it we will never have a mature industry like manufacturing industry and we will be fighting forever for compatibility and other issues.

1-4 of 4