Monday, 24 November 2008

How to install glassfish Java application server

I installed Glassfish application server few days ago, for the first time.
Although it has no GUI installer and you have to do it all by typing in console window, it’s a quite easy thing to do…

I needed new Java app server for some job to be done, and it was all up to me to decide which one to use…

At the end, I decided to use either Glassfish or JBoss.

Since I worked with glassfish that comes with NetBeans, and was very pleased with it , it was probably quite easy to guess that my choice is going to be glassfish…
After all, glassfish is nothing else then Sun Java System Application Server , but without GUI installer and some extra options in it and, of course, without support…

So, glassfish it is!

There’s a lot of documentation on how to install and start it, and you can easily find out everything you need to do that…

Since all the information that you need to know when installing this application server are on several locations on the internet, I will try to explain the entire process on how to install glassfish on windows so you don’t have to look for it on the net, hoping to save you some time…

- Prerequisites

In order to install glassfish, we need to have JDK 1.5 , or some newer version installed on the computer on which the glassfish will be running.
Be aware: not just JRE , but JDK + JRE!

So, install it and set all system variables ( JAVA_HOME, PATH and CLASSPATH ).

- Installation

Let’s start with downloading binaries.
Go to the and download the latest stable version.

The installation file is java archive. I downloaded

Let’s take this file, and place it where you want to install it.

Tip: Wherever you place it, when you start the installation, the installer itself will create a “glassfish” folder on that location and place all the files in it…

I don’t know why, but I like to install servers and all similar applications in root of C disk and not in “Program files”, so I’ll create a folder called “Sun” on the C disk , and copy glassfish-installer-v2ur2-b04-windows.jar in it , because I want my server to have a “C:\Sun\glassfish” path.

We will start installation by typing

java –Xmx256m –jar glassfish-installer-v2ur2-b04-windows.jar

It will first ask you to read ( scroll all the way down ) some licence agreement , or something like that. After you accept it, the installer will copy all the files to the “.\glassfish” folder.
The installation is almost finished. There are just few more things that needs to be done.
First of all, go to the <GLASSFISH_HOME>\lib\ant\bin\ and type

ant –f setup.xml

or from within installation directory type

.\lib\ant\bin\ant –f setup.xml

This way, we created a new domain: domain1.
Before you do this, you can open it with some editor and change the default names and ports, but if there’s no special need to do it – just don’t . Install it with default settings.

Now add the <GLASSFISH_HOME>\bin folder to the environment variable “PATH” ( then restart console window) , and at this moment your glassfish is installed and you can start it by typing

asadmin start-domain domain1

and stop it by typing

asadmin stop-domain domain1


We now have two problems:

- Glassfish does not have any tool to help you create a windows service for it , and since it is an application server , we need to have it running as a windows service. Fortunately, glassfish has executable called appservService.exe which communicates with the windows service controller, and we’ll use it later…

- Glassfish was developed using Java and therefore it uses JVM. But, when a user logs off - JVM turns off as well, and this is something we do not want to happen with our application server when the user that started it logs of…We need to control this.

So, the solution for the first problem is provided to us by Ryan de Laplante , who made a GlassfishSvc.jar file that will help us create a windows service for glassfish server.
Go to
and download this file.
After you downloaded it, copy it to your installation folder ( in my case: “C:\Sun\glassfish\” ) and run it with

java –jar GlassfishSvc.jar –i

First problem solved ;-)

We will solve the second problem with –Xrs JVM option.

Open <GLASSFISH_HOME>\domains\domain1\config\domain.xml file and add the following line:


to the part of the file that has many other <jvm-options>something…</jvm-options> tags…

Now, as I red, many people reported that this doesn’t work on windows 2003 server, so if this didn.t help, go to <GLASSFISH_HOME>\lib\processLauncher.xml
and add a line

<sysproperty key=”-Xrs”/>

inside a

<process name=”as9-server”>


What I did first, I added a line to <GLASSFISH_HOME>\domains\domain1\config\domain.xml , restarted a server and logged off, but the JVM turned off also. This didn’t work for me…

Then, I tried second option, restarted a server, logged off - but it didn’t work as well…???

Then, I restarted windows, (server started by itself because it’s now a windows service), logged of and everything worked well…
If someone asks me which solution helped me – I would tell him “I really don’t know, and I don’t care…”

So, that’s it!
Now you have a glassfish application server installed, you have a windows process for it and your JVM won’t turn off causing the server to shut down as well when you log off, and that is all we needed…

I hope this text will help someone…

Good luck and enjoy your glassfish!

Thursday, 20 November 2008

Read and write to .properties and .ini files

It is usual to store settings or properties of an application in some of these 5 known ways:

- to DB
- to XML
- to .ini file
- to .properties file
- to registry

My favorite are XML and .ini/.properties file.
All of them has some kind of restrictions, and it’s really up to data type that application needs to save , and which programming language I’m using at that moment…

If my application needs to read/save small number of information, without complex scheme of sections, then I always use .properties or .ini files.

To be honest, first time I used ( Java )class that works with .properties files, I was very surprised how easy is it to read/write settings. And all of that with small-size code, which is not usual in Java. ( Look at my earlier blog about parsing a document in PHP and Java : )

In Java, in order to work with .properties files, there’s a Properties class. Properties class extends HashTable , so we manipulate properties through the get and set methods.
It’s quite easy and fun to work with it.
Let’s say we have some file:, and it looks something like this:

We could easily parse it like this:
or, write current properties in application into the file with:

If we write

public static void main(String args[])
Main main = new Main();

the result would be:

color= blue
width= 150
height= 100
color= blue width= 150 height= 100
The other way around, if we write

public static void main(String args[])
Main main = new Main();

the file would look like this:
but, as you can see, without any particular order among properties that we wrote.

As I sad, I didn’t used to write something in Java with such small code size, and it feels great… :-)

All of this reminds me of TIniFile class in Borland Builder, and it is very hard to catch up with BCB when it comes to simplicity ( in my opinion, that is…).

Let’s take a look how we would do this in BCB. Ini files are very similar to .properties files. The difference is that .ini files have sections, and .properties doesn’t.

Let’s make a test application:
and let’s say we have file example.ini with a "data" section, and is looks something like this:
and we need to write these settings in appropriate Edits on the Form when someone starts the application. At exit, we need to overwrite properties in a file with those that are in these three Edits at that moment…

First of all, we would need this line:

Then, we could easily parse the document with:

or, write current properties in application into the file with:

If we write a constructor and a FormClose event like this:
__fastcall TForm1::TForm1(TComponent* Owner)
: TForm(Owner)

void __fastcall TForm1::FormClose(TObject *Sender, TCloseAction &Action)

and we start the app, it will read properties from ini file, and show it.

and , if we write some other values, then the FormClose event will write new values to the ini file, preserving the order that we wanted...

So, you saw now how easy it is to save properties into these two formats. I hope you like it the way I do...

Tuesday, 18 November 2008

Writing OS-independent JAVA code

One of the best things about Java is the fact that it’s applications are OS independent.
This means that you can write application on one OS, and run it on some completely different.

We ought to thank to JVM for this. It is JVM that cares how things should be done on certain OS.

When you say, for example:

new Thread(new Runnable(){public void run(){System.out.println("Hi, I'm thread!");}}).start();

Different OS will create this new Thread , set it’s priority , execute it and do many other things on completely different way, but thanks to JVM Java developers do not have to care about these things...

Another good example is file chooser. For example, windows and Solaris have different file chooser , and if you use it’s APIs to call it your code would look completely different, but in Java you don’t care about it. Code:

JFileChooser jfilechooser = new JFileChooser();
if (jfilechooser.showOpenDialog(frame) == JFileChooser.APPROVE_OPTION)

will work on windows, and on Linux, and on about any other OS that you can find JVM for it...

But, there is always a "BUT..."!

Yes, with Java and it’s JVM over 90% of your apps will work on any OS that has JVM for it, but there are some rules that you must stick to when developing app that will run on different OSs.

These are mostly trivial things, but enough to make your app not working correctly on a different OS.

These are some of the most common:

-Using "/" or "\" instead of System.getProperty("file.separator"). Different operating systems has different file separators. So, if you don’t know on which OS your app will run on, it is wise that instead of using, for example,

String some_path = ".\\some_file.txt";

you use

String some_path = "." + System.getProperty("file.separator") + "some_file.txt";

-Using absolute, instead of relative path. It is wise to use relative instead of absolute path because different OS have different file paths! For example, "c:\\some_file.txt" doesn’t mean anything on some linux, but "." + System.getProperty("file.separator") + "some_file.txt" , for example, certainly does!

-Using sockets on port < 1023. Be aware that on some operating system ( for example linux ) only special users ( root) can use ports smaller than 1023. It is very wise to use port > 1023 if you can...

-It is wise to use System.getProperty("line.separator") instead of "\n" at the end of the line when writing something to files.

-Using OS-specific command when executing OS commands.
Process process = Runtime.getRuntime().exec(command); can be very convenient , but be aware that different operating systems have different commands!

-Mixing letter case when working with files and folders. This is very common problem. Many developers that use windows just forget that other OS are case-sensitive. So, in linux , if you try to read from file
"." + System.getProperty("file.separator") + "some_file.txt"
and that file is realy a "Some_file.txt" or , for example, "Some_file.TXT" you wan’t be able to read it, and your app will not work correctly...

And the last ( and probably the least ):
-You probably will never create so many threads so that your OS will not be able to process them all, but if you are using some older OS, or create very very large number of threads, different OS will act differently because not all OS have the same limitation for maximum number of active threads at the same time ( native threads, not green threads )

These are just some of the rules you should stick to, if you want your app to really work the same way on different operating systems. No matter how trivial they are, people often forget about it...

Wednesday, 12 November 2008

God bless debugger

Have you ever wrote a code , and when you looked at it you just felt proud you wrote it.

And then you decide to try it, and at some moment you find out that it has some kind of a bug?!
Fortunately, you are able to fix a code in a short time, like you always do…
Then you take a good look at the code and at some point you say to yourself “No, there’s no way there’s something wrong with it!”
Then you keep on trying , and you test it more and more, you write it again and the damn bug just keep on playing with your brain… “What wrong? Where did I made a mistake?”

So, have you? Yes? No?

Well, I have!

Not very often, but once or twice in a while...

Oh, and yes , I forgot to mention: the worst thing is not the fact that you have a bug in your code!
Noooo: the worst thing is that your application is a network-based and you have several instances of it communicating in VPN so you don’t know is it something a bad network does to it, some kind of a collision, unplugged cable, a firewall, bad code, some bad admin’s setup, is there some older version communicating with the new ones or just some of 1000000 other possible reasons… yes, that’s the worst thing about it!

Fortunately, there’s something called debugger!
If you develop software for living , you will soon find out that a good debugger is your best friend!

There isn’t a problem you can’t solve in a few minutes!

Unfortunately it seems that many developers have forgotten this.

It's really fascinating that debugger isn't used as often as it should...
I think this is one of those must-know-how-to-use things, and every developer should now how to use it, but at the moment I don’t know many people who does.

Even if they know how to use it, they never do…

I use NetBeans IDE . It has a great debugger!

I always use it when there's a need.
I find my self able to spot and fix a bug in a very short time, no matter how big, small, stupid or hidden it is, but few days ago… Man, I wanted to buy my debugger a beer!
That is when I decided to write about it on my blog.

There’s no way I could solve those problems that fast without it!
I would be stuck for hours trying to find a problem…

Now, it all works just fine… ;-)

How often do you use debugger?