Developers, Developers, Developers! Maksim Sorokin IT Blog


Java SE 7 Certificates Are Almost Out!

Check the Oracle certification page. Java SE 7 certificates are now in beta (programmer certificate is not available yet, however). The price is 50$, instead of ordinary 300$. However, it has twice more questions and is twice longer.


Maven + Apache Felix + CXF + DOSGi: An Example of DOSGi Service

Link in series

Link to two Felix instances

Here is yet another post in Maven + Apache Felix + CXF + DOSGi series.

Here I will show how to use Apache CXF DOSGi for cosuming remote services. You may see the sources on my GitHub account.

We will have


Maven + Apache Felix + CXF: Securing a Service with HTTP Basic Authentication

This is another post in series Maven + Apache Felix + CXF + DOSGi Series. Here I will describe how to secure CXF published web services with HTTP basic authentication. You can find the sources on my GitHub account.

We will have three projects here. The first one defines an interface for a service. Another one provides implementation for it. And the third one will provide security.


dosgiSecurity will be just a holder project.

Our interface HelloService in bundle dosgiSecurity-api will be similar to the one we defined in


Discovering Version of Java in a BAT File

Sometimes in a BAT file we need to know what Java version are we running -- is it 32bit or 64bit. Here is a sample bat file, which depending on a Java version uses different native library directory:

@echo off

:: At this point you can place assumptions about Java version. It is still better than nothing anyway. In this particular case, we rely on a knowledge of Java version during installation time (with IzPack). Or you can just specify default value here, for example by default assume that 32 version is being run
if $SYSTEM_os_arch==x86 (
  set JVM_VERSION=32
) else (
  set JVM_VERSION=64
:: End of assumption section

:: Now trying to find out, what is current jvm version.

set TEMP_FILE=%TEMP%\javaCheck%RANDOM%%TIME:~9,5%.txt

java -version 2>%TEMP_FILE%
FOR /F "tokens=*" %%i in (%TEMP_FILE%) do (
  echo %%i | find "HotSpot" >nul
  if not errorlevel 1 (
    echo %%i | find "64-Bit" >nul
    if not errorlevel 1 (
      set JVM_VERSION=64
    ) else (
      set JVM_VERSION=32


if %JVM_VERSION%==32 (
) else (

start "App" javaw -classpath .;"%NATIVE_JARS%/*"

The trick is to redirect java -version to a temporary file. Then try to find a line with "HotSpot" substring. If that line contains "64-Bit", then it is 64bit version Java. Otherwise it is 32bit.


Yahoo Query Language — Finding Geographic Coordinates of ZIP Codes in Denmark

This post will describe a simply way to get geographic coordinates (latitude and longitude) for ZIP codes in Denmark using Yahoo Query Language (YQL).

The motivation is quite simple. One may need an estimate of the distance between two points on the map using ZIP codes. This may be because you do not have any real addresses. Or just you are totally fine with just a direct distance between two ZIP codes areas.
One could go several ways. Hire a lady to query all possible into Google Maps and get coordinates from there. Or try getting some information from the post office. Or just try finding coordinates on the Internet. But we will go slightly different way using the power of Yahoo Query Language (YQL).

First, let's have some tests.


Comparing Maven String Versions

This posts describes comparint Maven String versions. It is assumed, that you have a Maven-managed project.

Add a maven-artifact dependency


Then you could write something like this:

public int compare(String version1, String version2) {
  ArtifactVersion mavenVersion1 = new DefaultArtifactVersion(version1);
  ArtifactVersion mavenVersion2 = new DefaultArtifactVersion(version2);

  int result = mavenVersion1.compareTo(mavenVersion2);

  return result;

Building IzPack installers on the fly

One can grab ideas on how to build IzPack installers on the fly from izpack-maven-plugin.

You will of course need to depend on IzPack standalone compiler.

Basically, what do you need to do is to have some directory for staging. This is useful, when you want to run some filtering or putting some additional resources from somewhere else to the installer. You can use %TEMP% directory (File.createTempFile(...)) for that. Do not forget to wipe it afterwards!
When you have all your installer resources in some staging directory and you know the direct path to your install.xml you are ready to build a installer:

CompilerConfig compilerConfig = new CompilerConfig(installXmlPath, stagingDirPath, null, targetFilePath);

Panel for Reading Registry in IzPack 4

The panel called RegistryReaderPanel. It can be used in automated installation (silent installations). However, it can be used only once (can be easily extended). Code depends on IzPack COI tools. So COI tools classes need to be delivered together with the panel. Panel is built using Maven, so COI tools are shaded with Maven Shade Plugin. By default we are reading from HKEY_LOCAL_MACHINE registry root. You have to provide an xml file specifying what you want to read and to which variable to store the read value. Here is an example:

  <registry key="SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\myApp"
      name="DisplayVersion" default="null" variable="myApp.version" />

You may have several registry entries to read multiple keys. name specifies registry key. variable specifies to which variable to store the value. default specifies what should be a default value, when key was not found.

You will also need to provide COI dlls in install.xml:

<native type="3rdparty" name="COIOSHelper.dll" stage="both">
  <os family="windows" />
<native type="3rdparty" name="COIOSHelper_x64.dll" stage="both">
  <os family="windows" />

You will need to separate COI package yourself and add it to your Maven repository.

And here is the panel source:izpackExtensions-registryReader


Custom IzPack Panels. Necessary Changes for Silent Installation.

Here I described how to develop and debug your own custom panel. However, in order to have it work with automated installers (aka silent installation) we need to add some changes.

You will need to add AutomationHelper class. Here is how you can do it. Assuming you have custom panel with a name MyPanel, create class MyPanelAutomationHelper in the same package. This class has to extend PanelAutomationHelper and implement PanelAutomation. And then you will have to specify how to run the panel silently.
Basically, you can just repeat all the routine from panelActivate method in MyPanel panel (or if you do not want to repeat yourself, invoke/call MyPanel smartly). But you cannot use UI stuff like emitWarning or emitError. If you need to inform user about something -- write it directly to the output. Silent installer should be silent.

Here is AutomationHelper class for MyPanel panel, which we developed previously:

package com.izforge.izpack.panels;

import java.util.List;

import com.izforge.izpack.adaptator.IXMLElement;
import com.izforge.izpack.installer.AutomatedInstallData;
import com.izforge.izpack.installer.InstallerException;
import com.izforge.izpack.installer.PanelAutomation;
import com.izforge.izpack.installer.PanelAutomationHelper;

public class MyPanelAutomationHelper extends PanelAutomationHelper implements PanelAutomation {

  public void makeXMLData(AutomatedInstallData installData, IXMLElement panelRoot) {

  public void runAutomated(AutomatedInstallData installData, IXMLElement panelRoot) throws InstallerException {
    System.out.println("Hello, IzPack");

Silent Panels in IzPack

In your custom IzPack panel you may want to do some routine silently. In this case you would need just to skip your panel:

  public void panelActivate() {
Tagged as: , Comments Off