Geek 2.0

The Java CAPS Developer Conference is comming back to Europe. Join us in Munchen, Germany, Oct 13-15.

This is the unique occasion

• to learn about the many new features of Java CAPS 6
• to network with developers and users from different industries and geographies
• to directly meet and talk to the Sun Engineering team.

Registration is now open.

Do not implement too many operations in a single BPEL, you will end up with something like this.

Thinking about refactoring ?  This is were NetBeans BPEL refactoring features are handy (Thanks Jason for the link).

I was tired to filter out many information not directly useful to my debugging process while reading a GlassFish log file.

A log entry  like this one

[#|2008-08-24T08:58:38.325+0200|INFO|sun-appserver9.1|STC.eWay.batch.com.stc.connector.batchadapter.system.BatchInboundWork|_ThreadID=43;_ThreadName=p:
thread-pool-1; w: 7;|BATCH-MSG-M0992: Another Work item already
checking for files... |#]

contains many useful information, like the timestamp, the message severity level, the component that issued the message, the thread name and pool etc … But when I do look at a GlassFish log file, nine times out of ten, I do not need all these extra information, I just need the last message. 

Visually filtering out this is boring, error prone and, in general, slow down your analysis process.

When looking at the server log file from NetBeans, it does filter out all that information to propose you only the "relevant" part.  But, when working from command line, switching to NetBeans "just" to read your uncluttered log file is tedious as well.

I decided to implement from the command line, the same filtering as the one proposed by NetBeans, using sed and regular expressions. The first expression I crafted is

 ^\[.*;\|

It matches any line starting (^) with a bracket and containing anything (.*) until it matches the sequence ;|.  ([ and | must be escaped because they have special meanings in regular expression language).

Combining this with sed‘s substitute function (s/…/…), allows me to eliminate the first part of each line in the log entry.  Applying this to the previous log line gives :

tail server.log  | sed -e 's/^\[.*;\|//'
BATCH-MSG-M0992: Another Work item already checking for files... |#]

This is already more readable.  Then, just for the fun of it, we can get rid of the last three characters as well, by applying a second sed command :

sed -e 's/\|#\]$//'

where the regular expression \|#\]$ means "any line ending with ($) the charaters |#]" (once again, | and ] are escaped with a \).

To summarize, the complete tail command looks like this

tail server.log  | sed -e 's/^\[.*;\|//' | sed -e 's/\|#\]$//'

Of course, I scripted all this to avoid entering this each time I am looking at a GlassFish log file :-).  I let you create your own script as a follow-up exercise.

If you happen to know how to improve this by using only one sed command, I will welcome your input !

Enjoy !

As a follow up to my previous entry about converting Excel spreadsheet into CSV files using OpenOffice API, here is a small improvement.

The files we do receive have a first row containing the title of the columns, not any actual business data.  My intent was to skip this line while encoding the CSV file into XML, using some feature of the Open ESB Custom Encoders module.  Apparently, the Custom Encoder can not be configured in such a way, i.e. there is no possible configuration telling the Custom Encoder to skip the first line of a file.

So, I returned to the OpenOffice API and decided to remove the first row in the spreadsheet itself, before converting it to CSV.

Here is the code :

     private void removeFirstRow(XComponent xDoc) throws Exception {

         //get the speadsheet object
         XSpreadsheetDocument sDoc = (XSpreadsheetDocument) UnoRuntime.queryInterface(XSpreadsheetDocument.class, xDoc);
         Object o = sDoc.getSheets().getByName("Sheet1");
         XSpreadsheet xSheet = (XSpreadsheet) UnoRuntime.queryInterface(XSpreadsheet.class, o);

         //get the rows
         XColumnRowRange xRange = (XColumnRowRange) UnoRuntime.queryInterface(XColumnRowRange.class, xSheet);
         XTableRows rows = xRange.getRows();

         //delete the first row
         rows.removeByIndex(0, 1);

     }

As usual, I welcome your comments and feedbacks.

Enjoy !

Based on my previous blog entry, I applied the same technique to programmatically generate PDF documents.

The sample NetBeans project is available for you to download.

This sample does the following :

• It creates an empty text document (using OO’s writer application)
• It inserts the content of a template (another document containing text, images, etc …)
• It searches and replaces occurences of tags (like @name@) with actual data
• It saves the resuting document as PDF

Using this technique, you can generate professional looking PDF documents from your Java application using only free and open-source softwares.

This was tested on Mac OS X, with Apple’s Java 6 and StarOffice 9 Beta. Enjoy !

As usual, I welcome your comments and feedbacks.

I am currently working on a Proof Of Concept around Java CAPS and its capacity to handle, parse and transform Swift messages.

Customer do receive fund subscription orders from their partners and customers in many different formats : XML, CSV and … Excel files.

Excel files are always a bit tricky to handle when you’re not developping nor deploying on Windows servers (if you are using Windows, then check out our DCOM Binding Components as it might be an elegant way to handle DCOM compliant objects from OpenESB – or – our DCOM OTD for the folks using Java CAPS repository-based projects)

The solution I choose to handle these files is quite simple : I am using the OpenOffice API to programmatically open the XLS file with OO and save it as a CSV text file … just like you would do it by hand, using the OO GUI.

I attached a code sample to demonstrate this.  This is a complete NetBeans project.

For this sample to compile and execute, you will need a couple of OO jar files in your classpath (see the code sample for the exact list of required jars, they are all shipping with OpenOffice) and you will need to start OpenOffice in background mode, listening to network invocations from your client program (the exact command is given in the code sample).

This was tested on Mac OS X, with Apple’s Java 6 and StarOffice 9 Beta. Enjoy !

The same technique can be applied to programmatically generates PDF files, without buying the expensive Distiller.  This will be the subject of my next blog entry.

As usual, your comments and feebacks are welcome.