The Unix WGET command

WGET is a great Unix tool to retrieve files from the World Wide Web using HTTP and FTP.

This is especially useful for downloading directories and files from the web.

Example:

wget -r http://asap.ahabs.wisc.edu/~glasner/EnteroFams/alignments

Using this, GNU has come up with "GNU Wget", a free software package for retrieving files using HTTP, HTTPS and FTP.

 

Use the wget command to download files to a remote Unix/Linux workstation

wget is especially useful for bioinformaticians working with NCBI. NCBI has a ftp site with major resources for researchers. If you are working on a Unix/Linux machine remotely through an SSH session, and then you need to get a resource (like a tar or gzip file) that's on the NCBI ftp site, there are the following options.

1. You can download that file to your local machine.
2. Use scp to copy it to your remote Unix box.

You can bypass this two step process using the wget command:

Copy the URL for the resource in your local workstation and use wget on the remote workstation and download it directly to that machine.

In my SSH terminal I typed this:

wget ftp://ftp.ncbi.nih.gov/gene/DATA/gene2refseq.gz

As soon as the download was completed I had the files I needed on my remote server, with no need for the extra scp step.

You can also try the different options available for wget

Example:

wget -r -l1 --no-parent -A.html http://asap.ahabs.wisc.edu/~glasner/EnteroFams/alignments/

Here, -r -l1 means to retrieve recursively, with maximum depth of 1. --no-parent means that references to the parent directory are ignored. And -A.html means to download only the HTML files. -A "*.html" would have worked too.

One more thing to know is that this will leave a record in the remote system's access log files, showing the hit coming from the remote system where you ran the wget command.

ClassLoaders

What is the difference between the different ClassLoaders in Java and when to use what?

A class loader is an object that is responsible for loading classes or resources. In general, when loading a resource dynamically, you can choose from at least three classloaders:

The system classloader:

This is also referred to as the application classholder and handles –classpath.

ClassLoader c1 = ClassLoader.getSystemClassLoader();

The current classloader:

The current classloader loads and defines the class to which your current method belongs. Class.getClassLoader() returns the ClassLoader that loaded the class it is invoked on.

ClassLoader c2 = getClass().getClassLoader();

The current thread context classloader:

ClassLoader c3 = Thread.currentThread().getContextClassLoader();

Thread.getContextClassLoader() returns the ClassLoader set as the context ClassLoader for the Thread it is invoked on. This can be different from the ClassLoader that loaded the Thread class itself if the Thread's setContextClassLoader(ClassLoader) method has been invoked. This can be used to allow the object starting a thread to specify a

ClassLoader, the objects running in that thread should use. The cooperation of some of those objects is required for it to work.

Example:

Properties files are an example of a resource that is loaded using ClassLoaders. Both current classloader and current thread classloader can be used in loading a properties file for a J2EE application.

Using current classloader:

Using current thread context classloader:

References:

http://en.wikipedia.org/wiki/Classloader

R, Vladimir (2003). "Find a way out of the ClassLoader maze. System, current, context? Which ClassLoader should you use?"

javaworld.com. http://www.javaworld.com/javaworld/javaqa/2003-06/01-qa-0606-load.html. Retrieved on 2009-03-11.

Principles of Exception Handling

The following are some of the generally accepted principles of exception handling:

1. If you can't handle an exception, don't catch it.
2. If you catch an exception, don't swallow it.
3. Catch an exception as close as possible to its source.
4. Log an exception where you catch it, unless you plan to rethrow it.
5. Structure your methods according to how fine-grained your exception handling must be.
6. Use as many typed exceptions as you need, particularly for application exceptions.

Point 1 is obviously in conflict with Point 3. The practical solution is a trade-off between how close to the source you catch an exception and how far you let it fall before you've completely lost the intent or content of the original exception.

Example:

References:

Best practices in EJB exception handling