Know your Geolocation right away with HTML5

Wondered how Google Maps tracks you current location? HTML5! Thats what enables most of the modern-day applications to track down your current location.

You can do it too right away!

Open up your JavaScript/Firebug console. You can hit F12 to work on most of the browsers. And paste the following JavaScript code snippet.

navigator.geolocation.getCurrentPosition(function(position){console.log(position);});

or

navigator.geolocation.getCurrentPosition(function(position){alert(position.coords.longitude + " / " + position.coords.latitude);});

Did you see a confirmation asked on your browser? Allow it! Thats it! It was so simple. You can now see your location in terms of longitude and latitude on the console. You can use this data along with Google Maps API to spot your location on a map.

Developing Java / OSGi applications on Day CQ

Day CQ is a very popular enterprise CMS (Content Management System) suite from Adobe. Although most of the time the development on Day CQ is related to CMS and most of the development can be mapped to a proper CMS system, there are times when you would need to develop some logic in your application, or need to develop some feature that may not be available readily within Day CQ. In these cases, you may need to write some application code.

Day CQ is a Java based software, and Java is the most popular way to develop custom features and application logic. To be specific, Day CQ is largely built using OSGi - a technology that enables you to develop truly modular applications. Developing any custom Java application modules also needs to be built on OSGi.

I have noticed that developing OSGi modules is often a pain for a CMS developer, largely because of the lack of full development support  (or call it a buggy development support) from the CRXDE (The bundled Eclipse based IDE), which makes OSGi module development to take long time and painful. This post intends to give more insights to a CQ developer on OSGi, and also to do faster development of OSGi modules with OSGi.

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