Solving eclipse error with SVN 1.6 (loading JavaHL library)

If you are using Eclipse and SVN (Subversion), there are high chances that you are using the Eclipse plugin - Subclipse. And if you recently upgraded to subclipse 1.6, there is a good chance that you have encountered the error or loading JavaHL Library, that says something like this:

Problem:

Failed to load JavaHL Library.
These are the errors that were encountered:
no libsvnjavahl-1 in java.library.path
no svnjavahl-1 in java.library.path
no svnjavahl in java.library.path
java.library.path = /opt/jdk/64/jdk1.6.0_20/jre/lib/amd64/server:/opt/jdk/64/jdk1.6.0_20/jre/lib/amd64:/opt/jdk/64/jdk1.6.0_20/jre/../lib/amd64:/usr/lib64/xulrunner-addons:/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib

If this is the case, then few tips to get this working. As always, I will suggest solutions with the least number of steps, and all simple.

1. When installing/updating subclipse 1.6, use the update site - http://subclipse.tigris.org/update_1.6.x/ from within Eclipse.
2. The installation screen shows the features. Make sure that all features marked "required" are selected for installation. (You will anyway be not allowed to proceed otherwise).

If it still does not work, it is highly possible that the Java native libraries required for the SVN to work together with Java (thats Java HL) is not available to the Java. Either not installed or just that Java is not able to find it.

1. Install Java HL

You can refer to here for a generic discussion on this topic, especially for Windows and Mac OS. For Linux, I have simpler solutions :).
Install through your package manager, a package named libsvn-java, that contains the JavaHL. You must make sure that it is for SVN 1.6.
For Ubuntu or other Debian based Linux, the command should be handy:

sudo  apt-get install libsvn-java

However, it is possible that the installation is requiring you to install the whole Java binaries itself, although you already have one (an old version, or a manually configured Java for example), and you are not willing to install the Java packages. In that case, just go to your package maintainer's site, and manually download the package, and unzip it to your system (yes, you will need root permissions), so that the dependencies are not installed.

If you had installations fine, without any hacks, restarting Eclipse should get your Subclipse working. If not, follow what is below.

2. Make Eclipse runtime aware of the new JavaHL binaries.

. There are two options for doing this:

1. Tell JVM/Eclipse about the JavaHL libraries when starting JVM with the system property, that points to the java library path where the JavaHL binaries are installed. eg:

      -Djava.library.path=/usr/lib/jni
   

   This option can be specified in config.ini as well.
2. Put the JavaHL binaries in paths that JVM normally searches for native libraries. Normally these paths are listed, in the error above. Above the paths are listed as:

   java.library.path = /opt/jdk/64/jdk1.6.0_20/jre/lib/amd64/server:/opt/jdk/64/jdk1.6.0_20/jre/lib/amd64:/opt/jdk/64/jdk1.6.0_20/jre/../lib/amd64:/usr/lib64/xulrunner-addons:/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib
   

I went for the second option, since that one seemed most non-intrusive and easy to me. Let me show it how I did that:

1. Choose any of the listed Java library paths. In a terminal, move into that directory:

cd /usr/lib/jvm/java-6-sun/jre/lib/i386

2. Make softlinks to the JavaHL libraries.

   sudo ln -s /usr/lib/jni/libsvnjavahl-1.so libsvnjavahl-1.so
   sudo ln -s /usr/lib/jni/libsvnjavahl-1.so.0 libsvnjavahl-1.so.0
   sudo ln -s /usr/lib/jni/libsvnjavahl-1.so.0.0.0 libsvnjavahl-1.so.0.0.0
   

Now restarting Eclipse should get everything working fine. If it does not, review your steps, and also read in full length about JavaHL from http://subclipse.tigris.org/wiki/JavaHL, and try the steps again.

Running tomcat/webserver on port 80/443 without root permissions on Linux

The Problem

One of the concerns for web application developers is to run their web servers on the default port (which is 80 for HTTP, and 443 for HTTPS). However, since these ports are privileged ports (ports less that 1024 are privileged ports in Linux/UNIX), the developers are either required to run the server either as a root, or run on alternative non privileged ports such as 8080 or 8443.

The Solution

While to the same problem, there may be different solutions, the most simplest of all that I found was to do local port forwarding. Again here, many do not like to fiddle with commands every time. An easier, and one time solution to this is to use a program called "guidedog".

Guidedog is a GUI based advanced and powerful networking configuration tool for Linux, that can be used for packet routing, NAT and port-forwarding. Although it is for KDE, your Linux package manager should be intelligent enough to make that work for you even if you do not use KDE. We will here use its port-forwarding feature.

Steps

1. Launch your favorite package manager tool (Synaptic/Aptitude/YUM etc) and install "guidedog". For Ubuntu I use Synaptics Package manager, or even a command would do.
   

   sudo apt-get install guidedog
   

2. Once installed, launch the application with root permissions (don't worry, you require it to do just once).
   

   sudo guidedog

   
   On Ubuntu, you can also find it under the menu Applications->Other. You will have to even edit the menu command to gksu guidedog.
3. Move to the "Forward" tab. Add a new rule, such that TCP traffic on port 80 is forwarded to port 8080 (or whatever port your server runs on). Similarly, add another rule, such that TCP traffic on port 443 is forwarded to port 8443 (or whatever port your server runs on for HTTPS/SSL connections). After you are done, your screen should look like this:
   
   
   
4. Apply the changes.

You are done. Now just hit on localhost instead of localhost:8080, next time you start your applications.

Tool power

The tool creates a system rule to forward the traffic to a different port(8080/8443) from its original destination (port 80/443) on the same machine. You can see in the tool that it is much more powerful, and can allow even port forwarding for other machines too, or even do IP Masquadering/NAT (Network Address Transilation). However, explaining on these topics would outgrow the topic of this blog and would take more of your and my time too.

VNC via SSH tunneling

5 simple steps to connect through VNC to office/work PC via SSH tunneling

Situation:

You have to connect to your office PC from home via VNC, but your office PC does not have a public IP. The only way to access your PC is through one of the access point machines provided by your office that can be reached through Internet.

Concept:

VNC port is 5900. You can ssh tunnel to your office PC through your office access point, and connect to this tunnel to have VNC connection.

Assumption:

Office access point machine: accesspts1.company.com
Internal IP of your office machine: 192.168.1.31

Also assume that your Office PC is switched on, and access point machine can access your office PC via the internal IP, and can access its ports as well.

Steps:

1. SSH to access point machine. Provide password when prompted
   

   ssh username@accesspts1.company.com

2. Now that you are on access point machine, ssh from there to your office PC. Again provide password when prompted.
   

   ssh username@192.168.1.31

3. On your office pc, start VNC server. Keep this terminal open.
   

   x11vnc

4. On another terminal, make open a tunnel to your office pc via the access point. Provide the password for your access point machine when prompted.
   

   ssh -L 0.0.0.0:xxxx:192.168.1.31:5900 username@accesspts1.company.com

5. Use an VNC viewer to connect to your Office PC via the tunnel. Use the following details:
   

   Host: localhost
   Port: xxxx

Agility and more - better & faster business solutions with software - part-3

In my previous posts, I discussed about practicing agile in real life, and why adapting the agile prescriptions is important. I discussed how the basic values of Agile manifesto narrates it all. This is my last post in this series, where I will explain about practices even beyond the direct agile prescriptions, that can help build faster and quality software with smiling teams.

Some Agility and beyond

While the software creation itself is creative, the process employed to create this software is also creative. Its not just practicing agile, that helps create good software, there are more things to it. The craftsman (developer) who creates software has also to be given importance (Did I mention that before?). Let me discuss few of these things that include things from the Agile practices such as XP and Scrum, as well as those that go beyond them.

Agility and more: better & faster business solutions with software - part-2

In my previous blog post, I talked about why software development needs processes, and the need for agile in the processes. Here, I continue with the discussions, focusing on how the basic principles of agile itself has a lot to say, that can help us build better software.

Practicing agile - adapting is more important

As mentioned before, the popular practiced tools for agile process include Scrum, Kanban and XP. But often, the process models/tools are applied as a religion, being strict on what the text prescribes. This has resulted in some rumblings that has questioned the effectiveness of agile processes to deliver quality and creative solutions to business. The InfoQ book on Scrum and Kanban has highlighted the need for the process models to be adapted to their needs.

One size doesn't fit all - adapting is important.

(Image Courtesy: Robin Skyler Tell's photostream)

So what needs to be practiced is taking a lean model, and adapting it to your needs, probably by adding "prescriptions" from the stouter process models, and even removing "prescriptions" that hinder your progress, but with absolute knowledge of what is being removed. This is what Henrik has put in his InfoQ book - "Do not limit yourself to one tool!".