Monthly Archives: December 2014

2014 in review

The stats helper monkeys prepared a 2014 annual report for this blog.

Here’s an excerpt:

A New York City subway train holds 1,200 people. This blog was viewed about 3,800 times in 2014. If it were a NYC subway train, it would take about 3 trips to carry that many people.

Click here to see the complete report.

Just another mirror for HBase

While testing the Hadoop database, HBase, I noticed that dedicated mirrors were very slow. Here’s another link using 4shared.



By the way, if you see this error while trying to start HBase (./

$ ./
Exception in thread "main" java.lang.UnsupportedClassVersionError: org/apache/hadoop/hbase/util/HBaseConfTool : Unsupported major.minor version 51.0

Be sure that you’re running the minimum required JDK (1.7) and that the HBASE_HOME is set. I found this line in

# The java implementation to use.  Java 1.7+ required.
# export JAVA_HOME=/usr/java/jdk1.6.0/

Simple JTAPI Applet – CISCO Implementation

JTAPI is a Java library intended to ensure communication between a Java client and a CTI server. There are many implementations of JTAPI, proprietary(AVAYA, CISCO,…) and open source(GJTAPI, XTAPI). I’ve been working on an Applet to replace the CISCO IP Communicator. This applet uses the CISCO JTAPI implementation to listen to incoming calls, emit consultation calls and execute a call transfer. A consultation call is a call to a target number (B) started by an agent while receiving another call from source (A). The active call from A is switched to “waiting mode” (listening to some music on the wait tone). The agent has the possibility to join source A to target B without listening to their conversation (not a conference).

To achieve this task, I’ve been reading the JTAPI developer guide. The test platform preparation is not discussed in this post. Two common problems to solve to make this applet work correctly: How to make the applet access to local resources(mainly client logging)? How to implement these functions with such a restricted community?

To enable the applet interaction with client local resources, I implemented a test one. the applet looks like :

<applet id="sph" code=""
archive="miniphone.jar,jtapi.jar,log4j.jar" />


The miniphone.jar holds my implementation of the applet (, “jtapi.jar” is the cisco JTAPI implementation and “log4j.jar” is the default logging library for CISCO JTAPI. Note that this applet also interacts with an SWF (the main application) via some JS code. To avoid paths problems, I moved those libraries to the root context of my application under the server.

To execute the applet in IE for example, you have first of all to sign you jar with a valid certificate (using jarsigner tool from the default JDK installation bin). You will have to update your browser plugin  to the latest java release. Next, you have to trust your host in the java configuration panel.

Trust Server

To manage logging params in JTAPI, use the given CISCO tool(Cisco Unified Communications Manager JTAPI Preferences). You need also to place the jtapi.ini side by side with jtapi.jar. If this file is not generated during installation process, use the following command:

java CiscoJtapiVersion -parms

Then you can manage logging properties. It is useful to enable all traces for tests for easier troubleshooting.

2014-12-04_1514Logging management












In the Log Destination tab, I used “c:\TEMP\” as logging path. This will create a rolling file where every action of the JTAPI is logged. You can also use the client java console as an output. An interesting tip here, is how to print an exception stack trace into a given text box for example (inConsole is an AWT TextField in this snippet).

  StringWriter sw = new StringWriter();
  PrintWriter ps = new PrintWriter(sw);

One more thing to add in the user home to enable the applet write in a local directory: Create a file called “.java.policy” in the user home dir, and assign wanted rights to your source server:

grant codeBase "http://localhost:8080/ctiapp/*" {
  permission "C:\\TEMP\\*", "read";
grant codeBase "http://localhost:8080/ctiapp/*" {
  permission "C:\\TEMP\\*", "write";

Now, as soon as I went to my applet web page,  IE asked me to accept this “hazardous” applet:

Applet warning signed jar

So, I’m done with the first problem. Let’s now focus on the JTAPI implementation.

First of all, we need a valid CUCM server with valid credentials. We have to implement the ProviderObserver interface with its providerChangedEvent (aProviderObserverImpl).

public void providerChangedEvent ( ProvEv [] eventList ) {
if ( eventList != null ) {
for ( int i = 0; i < eventList.length; i++ )
if ( eventList[i] instanceof ProvInServiceEv )

conditionInService.set ();

Then, we try to connect the applet to the CUCM (providerName=CUCM IP; Login=cucem username; passwd=cucm password):

 Provider provider;
 JtapiPeer peer = JtapiPeerFactory.getJtapiPeer ( null );
 String providerString = providerName + ";login=" + login + ";passwd=" + passwd; "INFCTI101 Trying to reach provider[Connection String :" + providerString + "]" );
 provider = peer.getProvider ( providerString );
 provider.addObserver ( aProviderObserverImpl);
 conditionInService.waitTrue ();

Next, we need to implement the CallObserver interface to listen to call events.

protected final void metaEvent ( CallEv [] eventList ) {
 //"INFCTI100 Received a CallEv array event - Length = "+eventList.length);
 for ( int i = 0; i < eventList.length; i++ ) {
 TerminalConnection tc = null;
 try {
 CallEv curEv = eventList[i];
 //"INFCTI101 Processing event item : "+i);
 if ( curEv instanceof CallCtlTermConnRingingEv ) {
 //"INFCTI102 Event type is : CallCtlTermConnRingingEv.");
 tc = ((CallCtlTermConnRingingEv)curEv).getTerminalConnection ();
 //"INFCTI103 CTI connection is : "+(tc!=null?tc.getState():"null"));
 tc.answer ();
 //"INFCTI104 Agent answered the call....");
 }else if (curEv instanceof CallControlCall) {
 CallControlCall ccc = (CallControlCall)curEv.getCall();
 String callerName = ccc.getCallingAddress().getName();
 System.out.println("Received a call from "+callerName);
 //"INFCTI105 Event type is : CallControlCall. Caller =["+callerName+"]");
 catch ( Exception e ) {
//redirect the e.printstacktrace to a textField for example

//still a draft…

A very short introduction to MongoDB



Originally called humongous (big, enormous), the MongoDB project is carried by Eliot & Dwight since 2007. This is one of the best NoSql concepts implementation. For SQL fanatics, there is a small comparison between the SQL and the MongoDB NoSQL implementation.

NoSQL does not stand for “NO TO SQL” or “NON SQL”. It stands for “Not Only SQL”.

Recently I was testing it and I decided to pin this post for me and my team as a reminder.

MongoDB does not offer any official GUI. They delegated the mission to the community, and I think it was the right choice as there are now many GUI tools developed by the growing MongoDB community.

You can download the latest version from the Install it as an administrator if you are on Windows.

The default datastore for MongoDB is c:\data\db. Alternatively, you can specify the datastore when starting the DB engine (–dpath=”yourpath”).

To start the MongoDB server, run “mongod” on CMD. By default, 27017. You can check if the server was started by taping this address in the browser http://localhost:27017/. You will get this message on the page (It looks like you are trying to access MongoDB over HTTP on the native driver port.)
Open another console, and run “mongo.exe”.  First thing you must be aware of, there’s no “CREATE DATABASE” command on MongoDB. Let’s now create a new database called “knw”.  We’ll create a “table” called “projects” inside this database. A table in the MongoDB terminology is called a collection. A collection is a set of “rows” (called documents in this NoSQL variant). We’ll back to collections later in this post.

 MongoDB shell version: 2.6.3
 connecting to: test
//something like mysql use to specify current database
 > use knw 
 switched to db knw
 > show dbs;
 admin (empty)
 local 0.078GB
//there are no custom databases yet
//now, we'll insert a document in the table projects (not yet created)
 > db.projects.insert({name:"DALEEL", 
                  description:"Directories and VAS plateforms for call centers", 
 WriteResult({ "nInserted" : 1 })
 > show dbs
 admin (empty)
 knw 0.078GB
 local 0.078GB
//You can see that knw database was created

So, the database “knw” and the collection “projects” were created on first document insertion. Note that a collection can contain many documents with different structure.

> db.projects.insert({client:"Currency Museum", 
                      description:"Currency Museum management platform"})
WriteResult({ "nInserted" : 1 })

As you can see, column (field) names are not the same (“client” field does not appear in the first document although they are stored in the same collection).

Note also that a field value can be an integer, a string, a date  (etc) or a full document. (like “soldTo” field)

> db.projects.insert({name:"GEDARC", 
                      description:"EDM and ARCHIVES MGMT platform", 
                               name:"Client A", 
                     } )
WriteResult({ "nInserted" : 1 })

The select of MongoDB is called “find”. To find our main project “DALEEL”.

> db.projects.find({name:"DALEEL"})
{ "_id" : ObjectId("547d8321a2fdc9b65ab4805a"), "name" : "DALEEL", "description" : "Directories and VAS plateforms for call centers", "start_date" :
"2008-07-01" }

Now, you can start reading about NoSQL and MongoDB. There is something really humongous about MongoDB: The documentation 😉

One more post, I want you all to check before starting any project based on NoSQL spec, Sarah Mei arguing “Why you should never use MongoDB“.

How a NoSQL DB looks like in real world ? :D

How a NoSQL DB looks like in real world ? 😀