RAR in Linux

RAR is a very popular compression format in Windows (at least, since I am using Windows at work & at home). RAR generally has a better compression ratio than ZIP, and in places where disk space counts, would be cost-saving and "life-saving".

At my workplace, there's a need to Un-RAR a RAR file (created in Windows) in a Linux box. In the standard build of Linux (based on RHEL4) that we were running, the "unrar" command-line program is not present. Fortunately there's a free version on the Internet. Just need to do a little searching to get the RPM.

So I went to http://rpm.pbone.net/ and I found the right RPM file. My exact search result: http://rpm.pbone.net/index.php3/stat/4/idpl/11979708/dir/redhat_el_4/com/unrar-3.7.8-1.el4.rf.i386.rpm.html

Installing it is a breeze (phew!), with all the dependencies fulfilled in my Linux box. The command is simple (recommended using root-access to run):

rpm -i unrar-3.7.8-1.el4.rf.i386.rpm

So now, we can un-RAR files in Linux!

Basic usage:

unrar x myrarfile.rar

where 'x' is to extract files. Full list of options can be obtained by just typing "unrar".

What about creating RAR files in Linux? AFAIK, there's no free tool, but you can purchase or try one. Go get the files @ http://www.rarlabs.com

XMLBeans - First Steps

I attempted to revisit XMLBeans to generate XML-Java mapping codes based on the IFX schema. I've tried JAXB v1 but failed miserably (there might be some tweaking needed but I've searched high and low, to no avail...few years ago) The multi-XSD file structure from IFX Forum website was used.

In the XSD folder (all files are from the IFX Forum):
$pain.001.001.01.xsd
$pain.002.001.01.xsd
$pain.004.001.01.xsd
IFX170_XSD.xsd
RemitDetail_Type.xsd

Using XMLBeans 2.5.0 distribution, the command I run:
E:\experiments\exploded-apis\xmlbeans-2.5.0\bin>scomp -mx 1024M -out ifx17.jar E:\yk\xpdesktop\IFX-SIT\IFX1.7_XSD\IFX170_XSD.xsd

IFX is a HUGE schema so the heap size is increased to 1024M in order for the command to complete successfully.

Results:
Time to build schema type system: 3.39 seconds
Time to generate code: 109.938 seconds
Time to compile code: 145.939 seconds
Compiled types to: ifx17.jar

Wokay, this is good. First try without fancy options, and a JAR file is produced. I couldn't achieve the same thing in JAXB v1. Will need to try out using JAXB v2. More on this later.

Java VisualVM - Remote Display, Firewall-Protected, Offline Environment

VisualVM can be used for remote monitoring of Java applications. Things work fine for an environment without firewall "interference". For folks that are fortunate enough to have the protection of a firewall, here's a trick which worked for me, and may work for you.

Basically, I used SSH + X-Windows to view the VisualVM GUI on my local PC. In my current company's testing environment, SSH access is given and certain number of ports e.g. 80-90 (HTTP), 443-449 (HTTPS) are open for access as well. The rest are inaccessible i.e. blocked by firewall. No doubt firewall ports can be opened to allow RMI traffic essential for VisualVM to connect to the remote machine, but due to the nature of the out-of-the-box RMI implementation that dynamically assigns its port numbers, ports assigned are only valid for that particular time. A restart will have different ports assigned. There are ways to go around this behaviour, but exploring this option is out of the scope of this blog entry.

So the tools I used: Putty (for SSH), NetSarang's Xmanager2 (for X-Windows display), and of course, Sun JDK6 (u21).

First, I run Putty to access Machine A (Linux box) via SSH. Xmanager2 is also running in the background in Passive mode. At the Putty console, I ran the command below to enable X-Window display on my PC (assuming IP=10.123.124.67):

export DISPLAY=10.123.124.67:0.0

Then just run VisualVM on Machine A. On Machine A (could be different in your own environment):

/usr/java/jdk1.6.0_21/bin/jvisualvm &

The VisualVM GUI will then appear on my PC, but running on Machine A. So you can just "remotely" monitor your Java applications running on Machine A as a local client.

But unfortunately, the stock VisualVM application that comes with Sun JDK6 doesn't have the MBeans viewer plugin installed. And Machine A does not have access to the Internet, so online installation of the plugin is not possible. But fortunately, the plugin files (*.nbm) can be downloaded and installed offline (https://visualvm.dev.java.net/pluginscenters.html).

So that's it. I will be using the MBeans viewer to monitor my application's Tomcat database connection pool, after I'm done converting from Apache DBCP to Tomcat Jdbc Pool. More on this later.

If there's no firewall to make this complicated, you can add this to your Java application startup command:

-Dcom.sun.management.jmxremote=true
-Dcom.sun.management.jmxremote.port=9394
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false

This will disable SSL and authentication (username/password). You can then use VisualVM to connect to the remote machine.