javanna.net…not just java

A few days ago I released the first beta version of the elasticshell, a shell for elasticsearch. The idea I had was to create a command line tool that allows you to easily interact with elasticsearch.

Isn’t elasticsearch easy enough already?
I really do think elasticsearch is already great and really easy to use. However, on the other hand there is quite some API available and quite some json involved too. Also, interacting with REST APIs requires a tool other than the browser to use the proper http methods and so on. There are different solutions available: some of them are generic, like curl or browser plugins, while others are elasticsearch plugins like head or sense, that you can use to send json requests and see the result, still in json format. What was missing is a command line tool, something that plays the role of the mongo shell in the elasticsearch world. That’s ambitious, isn’t it?

Click here to read the rest of the article I wrote on the Trifork blog.

Some days ago I needed to manually update some MD5 values stored into an Oracle database. I usually generate those fields through a Java application, with the same code I commonly use to encrypt passwords. I couldn’t run a Java program on the production server and I needed to do the job quickly, hopefully with a single command. I looked up for an Oracle function and I found out the dbms_obfuscation_toolkit package.

In the previous post I wrote about some SSL common issues in Java. One of them, the most popular in my opinion, points out to a flexible way to make ssl connections using Jakarta Commons Http Client 3.1 without any static call. This is a good choice if your client has to communicate with two or more different hosts using different keystores or truststores.

Basically, you have to use a specific HostConfiguration and a given ProtocolSocketFactory implementation within your HttpClient object. I found out that the HostConfiguration has to contain the name of the host you want to communicate with, while the HttpMethod object must contain a relative path, otherwise the HostConfiguration will be overridden at runtime with the default one. And what about doing the same to make a web service call through Spring Web Services?

Much has been written about making SSL connections in Java. I think it would be useful to share my personal experience, so I’m gonna write about some common issues I dealt with.

• First of all, I remember a generic SSLHandshakeException due to the popular Transport Layer Security (TLS) Renegotiation Issue. I solved it by re-enabling the SSL renegotiation this way:

  System.setProperty("sun.security.ssl.allowUnsafeRenegotiation", true);
  

• I came across the following error too:

  javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
  

  which might depend on either the server configuration or the client certificate. For example, if you try to use a client certificate signed by a an issuer refused on the server side, you’ll have this exception thrown on the client side.