By default, RedHat Linux AS and AS4 servers don’t come with a JDK (Java Development Kit) installed on them. Depending on your install, if you run the java command you may get some sort of error message or a file not found message.
In this post I will describe how to install a JDK on your RedHat Linux server. It should also work on Fedora, however I have not tried it personally.
continue reading…
Yesterday I introduced how I send files via FTP and SFTP from my java applications. In that post I showed you how to use the Jakarta Commons Net package to FTP files. Today I will show you how to use the JSch (Java Secure Channel) library to do SFTP transfers.
Part 2 of 2 – Using JSch (Java Secure Channel)
First off, what exactly is JSch? Well, the JCraft team describes it says that “JSch allows you to connect to an sshd server and use port forwarding, X11 forwarding, file transfer, etc., and you can integrate its functionality into your own Java programs.” Personally, I’ve only used it to SFTP files, and have not yet used any of its other features.
To use JSch, you’ll first want to download the appropriate libraries from JCraft. Click here to be taken to the JSch homepage and download the jsch library. For my example I downloaded the jsch-0.1.32.jar file directly from their site. Once you download the file, put it in your classpath.
Now just grab the code I present below and go to town. Like the Commons Net library, the JSch library is extremely easy to use!
continue reading…
Within the enterprise applications that I design and develop, a requirement always comes up to integrate it in some way with an external, 3rd party system. For example, in writing an insurance policy management system, the carriers often want policy details FTP’ed to them. Logistics companies typically FTP EDI files around all day. And most recently at the University for which I work, we have integrated our systems to transmit financial aid data to the government, send information related to book store vouchers to our outsourced bookstore, and we have our student data geocoded to help us analyze what profile of students are enrolling. All of these external providers want the data to be FTP’ed to them.
To meet these requirements, I develop most of my data feeds in Java. Java makes it very easy to get data out of a database, package it up into a file, and FTP it off to its destination. Two of the libraries I find very useful to perform the FTP are the Jakarta Commons Net library for standard FTP transfers, and the JSch (Java Secure Channel) library to do SFTP transfers.
In this post I will show you how easy it is to use the Jakarta Commons Net library to perform FTP transfers. My next post will then show you how to use the JSch library to perform SFTP transfers.
continue reading…
Last night I presented my article discussing how to use JavaMail to check a POP3 mail account and retrieve its messages. Tonight I am going to follow that up with a summary of my EmailDelivery class. This is a simple class I wrote to help me easily send emails from my Java applications. A few highlights of the class are that it:
Recently I wrote a java daemon process that monitors a POP3 email box for messages, automatically downloads the messages, and then processes them. Basically my daemon process looks for returned and bounced emails in a POP3 mailbox and then updates certain flags in our ERP system so we don’t send to that email address again. In some cases people reply to the messages our ERP system sends out, and in that case my daemon process forwards those messages to an appropriate user for manual review and handling.
I’m not going to go into the details of how this daemon process work since it goes far beyond the scope of this post (and it is a huge piece of software in itself). However, I am going to share the basic java class that I use to check the POP3 mail account, download messages, and then loop through them for processing.
For this example to work, you will need to download the JavaBeans Activation Framework, and the Javamail libraries. Unzip the downloaded archives and put the appropriate jar file into your classpath. This example was tested with JavaMail 1.3.1 (mail-1.3.1.jar) and the Javabeans Activation Framework 1.0.2 (activation-1.0.2.jar).
My example also uses Log4j to log its output. If you don’t want to configure log4j, then replace all of my log.info and log.debug calls with a call to System.out.println.
Once you get your classpath setup, take the class I present below and compile it. The only thing you’ll have to modify to run the example is a few lines in the main() method. Once you get that running, you should be able to take the code, pick it apart, and make it do what you need for your own applications.
continue reading…
In my Java based applications I usually have the need to encrypt a string before storing it somewhere. Most commonly, I need to encrypt user passwords and credit card information before storing it in a character field in the database. I don’t want people to be able to walk away with a cleartext list of passwords or credit card numbers just by doing a simple select. Instead they’ll have to work a little harder to decrypt the values stored in the database.
To do this, I wrote a very simple utility class that takes a String, runs it through a javax.crypto.Cipher object to DES encrypt it, and finally passes it through the Jakarta Commons Codec class which encodes the encrypted bytes into a Base64 (org.apache.commons.codec.binary.Base64) byte array. I wanted to encode the encrypted string in Base64 to ensure it only contains ASCII characters before storing it in my database. The decryption just follows the previous explanation in reverse: decode base 64, unencrypt string, return unencrypted string.
I will present my class below, complete with a main method showing how to use it. Before compiling the class, make sure you have downloaded the Jakarta Commons Codec library from http://jakarta.apache.org/site/downloads/downloads_commons-codec.cgi. I downloaded the file labeled 1.3.zip Binary. Uncompress the zip file and put the commons codec jar file into your classpath. The name of the jar file in my example is commons-codec-1.3.jar. The Commons Codec jar file is what supports the Base 64 encryption and decryption.
And now I will present my utility class:
continue reading…
Every good application should verify that data which must conform to a specific pattern actually does when it is being entered. For example email addresses, social security numbers, phone numbers, IP addresses, etc all have basic formats that they should conform to. Fortunately, in Java Swing applications the javax.swing.InputVerifier allows us to easily do this.
The InputVerifier class itself is designed such that the programmer must create a subclass of it and override the verifyText method. This verifyText method has a signature that looks like:
protected boolean verifyText(String textToVerify)
The verifyText method is designed to take in a text string, and the programmer writes the logic to verify if the text is of the format that is it should be. If so, you return true. If not, return false. It’s as simple as that. continue reading…
Have you ever had the requirement to compress or uncompress files or byte streams from within your java applications? This requirement seems to be a common need for me in all sorts of applications from B2B data feeds to my client applications. Within my client applications I allow users to attach files to records and I compress them to conserve space before storing them on the server. Once I compress the byte stream, I usually do one of two things. I will either store the byte stream representing the compressed file directly into a BLOB column in my database, or I will write it to a file in a common file system location.
Below I will present my simple ZipUtil java class which allows us to easily compress and uncompress files. My class consists of two convenience methods that take a byte array and call either the java.util.zip.Deflater or java.util.zip.Inflater objects to compress/decompress the byte array, and then it returns the new byte array. These java classes provide support for general purpose compression/decompression using the ZLIB compression library.
This class is not designed to create Zip files per se, but rather to just compress and uncompress byte streams. I will present the class to you below: continue reading…
While I was writing an EMR application, I quickly realized that my framework needed a class with static methods to help me perform measurement conversions. Namely I needed to convert pounds to kilograms and inches to centimeters.
I searched the web for a while and didn’t find a stock Jakarta Commons utility, so I decided I would build my own class named MeasurementUtil. In the future, when I come up with a new measurement conversion requirement it will be placed within this class in my framework package. You’ll probably look at my code and say, “well that’s extremely simple, why not just do calculation using the logic inline”. The answer is simple: I wanted a basic utility class that encapsulates all of my measurement conversion logic. In reality this could probably be turned into its own package with a suite of classes, but since I only started off with the requirement for two measurement conversions, we ended up with one class for now. This is in an effort to keep it simple. continue reading…
In the Swing based java applications I write, the requirement usually exists to allow the app to open up other files such as Word Documents, PDF’s, HTML pages, etc. Since I try not to limit myself to just the file types defined in requirements gathering, I looked for a more general solution that will allow my apps to open any file type. After all, if on my Windows or Linux desktops I can double click on a file name to open the appropriate program, then why can’t my java applications?
My first take at this was to just use the java runtime, and assume my code would only run on windows 2000 or greater. The code at that point to open a file looked like this:
String cmd = "cmd /c \"" + fileName + "\"";
log.debug("Opening file with command: "+cmd);
java.lang.Runtime.getRuntime().exec(cmd);
Well, after that was in place for a few months, we wanted allow our application to also run on Linux. Uh oh, now the code above no longer works… continue reading…
