Salomo's Blog spot

Tomcat behind Apache HTTP server using Spring Security

2011-11-10T11:31:00.000-08:00

Since I have been struggling with applications not working properly behind Apache HTTP server that use Spring Security I dedicated this blog to this issue.

When you develop an application using Spring security this works fine when just running on a Tomcat server e.g. http://localhost:8080/app-context/. The problems start when you want to setup your environment properly by adding an Apache HTTP server in front of it using proxy AJP. You would start by adding the following to your apache config file:


ProxyPass /app-context/ ajp://localhost:8009/app-context/

This works fine when trying to go to http://servername/app-context/ but when you try to login you will be redirected back to the login page everytime. To avoid this behavior you need to add the following line to your Apache configuration:


ProxyPass /app-context/j_spring_security_check ajp://localhost:8009/app-context/j_spring_security_check

For some reason it doesn't work without this line which seems weird to me since you basically map the context and everything that comes after it with the previous line. After trying a lot of options I just tried adding this and this seemed to work. I discovered that when I was logging in (using firebug) that it couldn't find the path /app-context/j_spring_security_check so I tried adding it and it finally worked :-).

There is still one thing left to do though since you also want to be able to logout you have to add the following line too:


ProxyPass /app-context/j_spring_security_check ajp://localhost:8009/app-context/j_spring_security_logout

Configure Tomcat as a deamon on Linux

2011-07-27T09:23:00.000-07:00

Since I keep on forgetting how to do this I decided to put this on my blog to make it easier for me and other people that have the same issue as me. It's pretty simple actually but yesterday I caught myself forgetting how it needs to be done. Basically you need to follow to following steps to successfully.

Step 1 - Creating startup deamon file

You can take the following file and adjust it accordingly. You have to create this file in /etc/init.d/.



#Jenkins startup script
#!/bin/sh -e
#Jenkins startup script
#chkconfig: 2345 80 05
#description: Jenkins CI

# Define some variables
# Name of app
APP=Jenkins
# Name of the user to run as
USER=tomcat
# Location of application's bin directory
BASE=/var/tomcat/instances/jenkins
# Location of Java JDK
export JAVA_HOME=/opt/java/jdk1.6.0_11

case "$1" in
  # Start command
  start)
    echo "Starting $APP"
    /bin/su -m $USER -c "cd $BASE/logs && $BASE/bin/startup.sh &> /dev/null"
    ;;
  # Stop command
  stop)
    echo "Stopping $APP"
    /bin/su -m $USER -c "$BASE/bin/shutdown.sh &> /dev/null"
    echo "$APP stopped successfully"
    ;;
   # Restart command
   restart)
        $0 stop
        sleep 5
        $0 start
        ;;
  *)
    echo "Usage: /etc/init.d/$APP {start|restart|stop}"
    exit 1
    ;;
esac

exit 0

Step 2 - Register your deamon

To register your deamon you can use chkconfig. This will make sure your deamon will be started up on boot and enables you to use the following command to start and stop your tomcat instance.

To start:


service jenkins start

To stop:


service jenkins stop

To do the magic you should execute the following command:


chkconfig jenkins --add

Now your done :-)

Cargo-itest extended

2009-04-27T06:46:00.000-07:00

I have been doing some work on the cargo-itest project and extended it with the following features:
- JOnas support
- Jetty support
- Auto detection of configuration files for JBoss
- Extended logging information to be able to detect problems in an easier way

These changes will be in the next release 1.2.0.

The auto detection is a nice one since it automatically picks up .properties files and -ds.xml (Data source files) from a preconfigured location so you don't have to copy them selves to the correct location. :-)

In the future we will try to implement configuration by annotation since some users prefer doing configuration through annotation instead of an XML file. In this case a Spring context file.

Disk Defragmenter Could not start

2009-02-24T06:14:00.000-08:00

Anyone getting the "Disk Defragmenter Could not start" message and on Windows XP this is what worked for me.

Go to Control Panel, Select System and select the Advance Tab. Now Select Settings Under Performance and again select the advance tab. Under Virtual Memory select Change. Make sure that the Paging File Size for selected Drive for the Drive partition you want to Defrag has either a custom at least 2 times the amount of installed RAM if the space is available or is set to System Managed Size.

Once I did this Defrag started working again. I don't know how the Page file got turned off on my system but this has been driving me mad for months!! Hope it helps someone else out there !!!

Shared configuration on Tomcat 6

2009-02-18T01:05:00.000-08:00

In Tomcat 5 there was the famous ${catalina.home}/shared/classes which you could use for sharing class files, properties files etc. Tomcat 6 by default doesn't come with this directory. In a first glance it seems that you can't do it anymore :-(.. But that's not true :-)..

You need to configure Tomcat to point to a directory which you want to be shared location so applications can pick up resources from the classpath. The configuration is very simple. Just go to ${catalina.home}/conf and open catalina.properties. Add the path to the shared.loader property. It will look something like this:

#
# List of comma-separated paths defining the contents of the "shared" 
# classloader. Prefixes should be used to define what is the repository type.
# Path may be relative to the CATALINA_BASE path or absolute. If left as blank,
# the "common" loader will be used as Catalina's "shared" loader.
# Examples:
#     "foo": Add this folder as a class repository
#     "foo/*.jar": Add all the JARs of the specified folder as class 
#                  repositories
#     "foo/bar.jar": Add bar.jar as a class repository 
# Please note that for single jars, e.g. bar.jar, you need the URL form
# starting with file:.
shared.loader=${catalina.home}/shared/classes

This can be very usefull when you want to share configuration between several web applications or even just to decouple the configuration from your web application in an easy way. Using this makes it easier to have a platform independent configuration without creating separate artifacts for every platform. :-)

Fastest XML parser

2009-02-17T03:44:00.000-08:00

In most applications you need to do some XML parsing to either provide XML to external systems or parse XML from external systems or of course both. Since the systems I work on use a lot of XML and they need to be as fast as possible I did some tests on several XML parsers. I tested the following parsers/XML frameworks:

JDom
Piccolo
StaxMate
XStream
JAXB 2.1

All parsers were tested in isolation with the following parameters:

25 threads running simultaniously
Every thread calls the parser 100 times

The results are as follows.

JDom
Avg. parsing time: 325.24 ms
Avg. memory usage: 307 KB
Piccolo
Avg. parsing time: 88.08 ms
Avg. memory usage: 454 KB
StaxMate
Avg. parsing time: 96.16 ms
Avg. memory usage: 203 KB
XStream
Avg. parsing time: 77.04 ms
Avg. memory usage: 319 KB
Jaxb 2.1
Avg. parsing time: 1778.12 ms
Avg. memory usage: 618 KB

As you can see XStream is the fastest one of them all. The total ranking of the parsers you can find below:

XStream
Piccolo
StaxMate
JDom
JAXB 2.1

As you can see StaxMate has the smallest memory footprint. The total ranking of the parser you can find below:

StaxMate
JDom
XStream
Piccolo
JAXB 2.1

If you take the ovarall pro's and con's XStream comes out as the best choice as it comes to:

Speed
Memory footprint
Ease of use

JDom has a remarkably low memory footprint but this is because the test was done with a single XML file which wasn't that big so when the XML file will grow the memory footprint will drastically grow with JDom since it loads everything in memory to construct the full document.

JAXB is dissapointingly slow and has a huge memory footprint. The ease of use was a big plus though but if you compare it to XStream it's almost the same. XStream also provides annotations to easily map XML to Java objects. And it performs much better.

Piccolo was a bit slower than XStream but there is a significant difference in the memory footprint but also in the ease of use. When using Piccolo you need to implement a lot of stuff that you actually don't use at all. Also a lot of Exceptions need to catched resulting in a lot of boiler plate code.

StaxMate would also be a good choice but the ease of use compared to XStream or JAXB lacks a bit.

XStream itself also has some additional features like:

JSON support.
Streaming capabilities.
Ability to switch to other type of XML parser without changing the parsing code.

So in general if you want fast XML parsing and an easy to use API I would recommend to use XStream. :-)

Cargo-itest continues

2009-02-13T11:17:00.000-08:00

The 0.3 version of my cargo-itest project now also supports Tomcat. So now Tomcat users can also write integration tests with fairly little effort.

I am also extending it with an AbstractDefaultHibernateDeploymentTest which can be used to easily generate your database schema from your annotated classes. Before it wasn't possible to execute SQL scripts for test data. Now I added the functionality to enable you to execute SQL scripts before the deployment tests are run and also after. The execution of the SQL scripts will be before and after transaction so it will not be rolled back by the test case itself. Internally it uses the AbstractTransactionalJUnit4SpringContextTests but you only need to configure a list of file names in your itest-context.xml file which in turn will automatically be picked up by the test.

Also added support for applications that don't use a database at all with the AbstractDefaultNoDbDeploymentTest class. In the near future I will also implement container utilies for:

Jetty
Resin
Jonas

Cargo-itest open source project

2009-01-29T07:51:00.000-08:00

I recently started an open source project called cargo-itest. This was started up because when I worked on several projects I needed to create integration tests for them which all had similarities. I was previously doing it with the maven2 cargo plug-in but wasn't really fond of it because it most of the times didn't work and when it worked it stopped working after editing the configuration. In other words it was very unstable. This initiated me to start to use the java API of Cargo instead of the maven plugin. By using the java API it already removes the dependency from your build system in this case Maven.

Having no dependency on the build system gives you a couple of advantages:

You can run it in any IDE that supports JUnit.
You can switch easily to another build system without changing your tests and test configuration.

These are general advantages of just using the API but also part of using my open source project cargo-itest. This project enables you to easily start creating integration tests by just extending your unit test (JUnit 4.4) from a base class called AbstractDefaultDeploymentTest or AbstractDefaultHibernateDeploymentTest. These base classes provide you with out of the box functionality to start up a container and run integration tests on them. So to start up from scratch you need to do the following steps

Extend from AbstractJBossContainerUtil
Create a context file called itest-context.xml in the root of the classpath
Configure the container utility in the itest-context.xml
Create your own JBoss configuration ZIP file by using the test-app.zip as template since this one already contains certain variables that are used by the AbstractJBossContainerUtil and put it on a server so the container utility can download it.
Put JBoss on a server in a ZIP file also so the container utility can download it.

After these steps your container utility should be setup correctly and all is left is to create a unit test that either extends from the default tests that are supplied in the project or create your own test and start the container yourself.

There are fully functional examples in the SVN repository which can be found here:

http://cargo-itest.googlecode.com/svn/maven-repo/

Now there is only a JBossContainer utility available since I worked a lot with JBoss but in the near future I am planning to extend it with Tomcat and Jetty and maybe in the future some other utility containers. The important part is that you can actually do it yourself if you like in an easy way without influencing your tests.

So the overal benefits for using this projects are:

Without extensive knowledge of the cargo API you can start creating integration tests with fairly little effort.
You can create your own container utility if the container you are using is not supported yet.
You are not stuck to a build system so you can easily switch build systems without changing your tests
You can run the tests within your IDE which will speed up the development
It's open source so you can extend it in any way you like :-)

The project itself is hosted on Google code on this location:

http://cargo-itest.googlecode.com/

Specify context name in Tomcat

2009-01-29T07:17:00.000-08:00

When developing web applications that are distributed as WAR files running in Tomcat most of the times you want to be able to specify the context name to a nicer name than Tomcat provides by default. Which is the name of the WAR file itself. When i.e. you are keeping the version within the name of the WAR this will result in some weird name like myapp-1.2. This is most of the times not what you want.

Most of the times you want a nice context name like myapp without the version in it. According to the Tomcat documentation you can do it in 3 ways:

Edit the server.xml
Add a context.xml to the $CATALINA_HOME/conf/Catalina/localhost with the name of your context.
Add a context.xml to your META-INF directory in your WAR file

The first two options just work fine only the last one doesn't do the job for you for some reason.

Personally the second option is the best option since it's not intrusive to your application and also not to Tomcat since you leave the server.xml alone. This way you define the context name in a separate configuration file and enables you to also keep the environment specific configuration out of the application. You can than simply provide this configuration file in a distribution package for installation. Another benefit is that you provide yourself with more flexibility since you can easily switch to EAR file distribution when running on an application server. On an application server you define your context within your EAR file which will only effect your distribution project and not your application.

So why would you put a context.xml in your META-INF directory in your WAR file? Well it can be useful if you just want to expose some application specific JNDI resources for your application.

So how can I achieve this? Here is a link to the Tomcat documentation where you can find out what exactly you should do to achieve this.
http://tomcat.apache.org/tomcat-4.1-doc/jndi-datasource-examples-howto.html

Setup Postgres on Fedora Linux 10

2008-11-27T06:56:00.000-08:00

Installing PostgreSQL on Fedora Linux 10 is pretty straight forward. You need to follow the following steps:

#1 Initialize postgres
initdb /var/lib/pgsql/data

#2 Add the following line to pg_hba.conf:
local all all trust

#3 Switch to postgres user
su postgres

#4 Connect to PostgreSQL
psql -d template1

#5 Change password
ALTER USER postgres WITH PASSWORD 'this_is_my_password';

#6 Remove line from step 2

Enabling GZIP compression on Tomcat

2008-09-25T06:53:00.000-07:00

Enabling GZIP compression for your web application is a good way to accelerate your web site. This can reduce the size of data being transferred and, consequently, speed your application.

Enabling compression on the web server will make data be transferred in compressed form. The browser will decompress the data on the fly, making the application faster. If your application uses Ajax, what usually increases the volume of data transferred from server to client, compression of data will significantly improve your application performance.

Here is how to enable GZIP compression on Tomcat: edit file /conf/server.xml and add to the HTTP Connector configuration something like this:
compression="on" compressionMinSize="2048" noCompressionUserAgents="gozilla, traviata" compressableMimeType="text/html,text/xml"

An example of a HTTP Connector configuration with compression enabled could be:


      Connector port="8080" maxHttpHeaderSize="8192"
              maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
              enableLookups="false" redirectPort="8443" acceptCount="100"
              connectionTimeout="20000" disableUploadTimeout="true"
              compression="on"
        compressionMinSize="2048"
        noCompressionUserAgents="gozilla, traviata"
        compressableMimeType="text/html,text/xml"

How to install Java in Fedora Core

2008-09-08T06:52:00.000-07:00

By default, Fedora Core 6 systems come with an old Java software installed, so you need to install a newer version of Java Runtime Environment to enjoy all the Java applications out there. In this quick guide, I will teach you how to update/install your Java Environment.

Let's begin by downloading the latest version of JRE (Java Runtime Environment) from here. Just click on the Download link where it says Java Runtime Environment (JRE) 5.0 Update, then you'll need to accept the license and download the Linux self-extracting file.

WARNING: Please remember to always replace the xx from the jre-1_5_0_xx-linux-i586.bin file with the latest version. At the moment of this guide's writing, the latest version was 09, so the file should look like this: jre-1_5_0_09-linux-i586.bin

After you have finished downloading the file, you need to move it into the /opt folder. Open a console and type:
mv jre-1_5_0_xx-linux-i586.bin /opt

Now, you will need to make this file executable so you can extract it. Follow the commands below:
cd /opt - so you can go into the /opt directory chmod x jre-1_5_0_xx-linux-i586.bin

And now, let's run the executable file with the following command:
./jre-1_5_0_xx-linux-i586.bin
You'll be prompted with the License Agreement, hit space until you are asked if you agree or not. Type Yes and the extraction process will begin. After the extraction process is finished, just remove the binary file with the following command:
rm -rf jre-1_5_0_xx-linux-i586.bin
Now, let's put the Java plugin into your browser's plugin folder. Konqueror, Firefox and Mozilla browsers will all look into the same folder, for plugins. So type the following command:
ln -s /opt/jre1.5.0_xx/plugin/i386/ns7/libjavaplugin_oji.so /usr/lib/mozilla/plugins/libjavaplugin_oji.so
Well, now you need to make the Java executable available for the whole system, so you can run all the Java applications you encounter. Create the following file with your preferred text editor:
kwrite /etc/profile.d/java.sh
Now paste the following options into the file, remember to enter a carriage return after these lines, then save it. Remember to replace the xx with the latest version you have downloaded:
export J2RE_HOME=/opt/jre1.5.0_xx export PATH=$J2RE_HOME/bin:$PATH
Now, type the following command to make that file available:
source /etc/profile.d/java.sh
Then type this command to see if the path is correct:
which java
You will see something like this: /opt/jre1.5.0_09/bin/java

Then type these commands:
/usr/sbin/alternatives --install /usr/bin/java java /opt/jre1.5.0_xx/bin/java 2 /usr/sbin/alternatives --config java
After you have entered the last command, you'll be asked to choose which Java software you want for your system. Just press 2 key and hit enter.

And finally, just type this command to see if everything looks good and your system has a new Java Environment:


/usr/sbin/alternatives --display java

And you can also type this command to see the version of your Java Runtime Environment:


java -version

Mine looks like this:


java version "1.5.0_09"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_09-b01)
Java HotSpot(TM) Client VM (build 1.5.0_09-b01, mixed mode, sharing)

Opening a PDF file in a Java Application

2008-08-01T06:51:00.000-07:00

PDF is a very common used file format for documents so quite often you need to develop applications that work with them. In Java it's fairly easy to open a PDF document using the runtime executer. Below you find a code snippet that does the job.

Runtime.getRuntime().exec("rundll32 url.dll,FileProtocolHandler " + file);

This peace of code let's Windows deside what application to use to open the PDF file which is quite cool since most of the time you don't know what application users use to open PDF files. :-)

Remotely debugging JBoss

2008-07-24T14:00:00.000-07:00

When working with JBoss sometimes it's needed to debug your code while running instead of running your application in a lightweight servlet container like Jetty or Tomcat. This can be done by adding the following line to your run.bat or run.sh:
-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=1044

You need to add this to your JAVA_OPTS variable so it will be used when JBoss starts up. When starting up now you can attach a debugger i.e. in Eclipse to the port you specified. :-)

Hibernate LazyInitializationException

2008-07-23T22:00:00.000-07:00

People who use Hibernate will surely come across this irritating exception. In my whole career I have encountered this several times. Actually this problem is quite easily to fix. Let's start with when this exception can occur... Most of the time it has to do with a collection that is mapped to some objects that are lazily loaded. Lazy loading is used when you don't need the collection every time you retrieve the specific object. So i.e. you have an object called Person that can have multiple PhoneNumber objects. The objects will look something like this:
public class Person { private String name; private Integer age; private Set phoneNumbers; ..... }

public class PhoneNumber {
private String areaCode;

Publish Post

private String number;
private Person person;
.....
}

Having mapped the collection as lazy (Hibernate3 defaults to lazy) the call to the collection will cause an LazyInitializationException when you try to call it after you retrieved in i.e. the GUI layer or in another service where you pass this object. This problem can easily be fixed by just calling the person.getPhoneNumbers() after you retrieved it with your DAO. This will cause Hibernate to retrieve the elements in the collection from the database. In the GUI now you can just use the collection to display the phone numbers i.e. So the key thing here is to initialize the collection that is lazy initialized.

Testing your application

2008-03-12T22:00:00.000-07:00

Recently I finished a research about how to test an application. This was needed to have clear guidelines on how you should test your application and what kind of tools could be used for accomplishing that. The result of this research is spread out into the following paragraphs.

What is testing?

The definition of testing

To keep it simple testing is making sure your application does what you expect it should do. This can be determined in different ways:
- Unit isolation testing
- Unit integration testing
- Integration testing
- Acceptance / functional testing

Unit isolation testing
Particularly useful when testing the logic of your application, like calculations etc. There shouldn’t be a lot of these kinds of tests in your code base. In other words, Mock tests.

Goal
The goal of this kind of test should be making sure the logic you have written doesn’t break and produces the right outcome.

Unit integration testing
Used for testing your logic in its context. So only use mocks if it’s really necessary (i.e. for a web service, network resource etc.)

Goal
The goal of this kind of test should be making sure the logic you have written in combination with the context it is living in is producing the right out come and doesn’t brake.

Integration testing
Useful for testing your whole application through all layers so you actually know that your application layers operate properly when joined together. The use of mocks should be prevented here.

Goal
The goal of this kind of test should be making sure the application as is working correctly when all layers are put together.

Acceptance / functional testing
These kinds of tests are almost the same as an integration test but more focused on the end user driving it.

Goal
The goal of this kind of test should be making sure all functional requirements are met.
All these kind of tests can be done in an automated way. Of course there should be some sanity checks done during the Acceptance / functional testing. But most scenarios can be automated.

How should I test?

When to use ‘Unit isolation testing’
Using Unit isolation testing is useful to find out quickly where exactly the problem occurred when your tests fails. Generally these kinds of tests apply only on the service layer of your application where the logic of your application resides. Writing a mocked DAO isolation test doesn’t really make sense because writing a test for a DAO the goal is to know if the data can be retrieved from the data store as you expect it would be retrieved. Or knowing that the data put in is actually stored.

So in general use this one only if you have a class that has some logic that is worthy to test.

When to use ‘Unit integration testing’
These kinds of tests are very important because they actually test your code in the context it’s going to be used. It will test your logic with some real data preferably. Less mocks the better making it a better test because it’s actually testing your real code. Actually these kinds of tests kind off overrule the Unit isolation testing because it’s doing almost the same but closer to reality. These tests in general have more value than an isolated test because they are testing the real thing. It also lets you know when you break something in the code base. The Unit isolation testing is actually the start of these kinds of tests. I would recommend extending your isolation test into a unit integration test instead of writing a new one. But be careful with this because that doesn’t apply to all of the Unit isolation tests. It’s case specific. There is no general rule for doing this. It’s more a decision you should take when you are about to make such a test. Think about the following things:
- How much effort does it cost me?
- Does it give me more assurance?
- What are the risks?
- Do I expose too much?

Answering all these questions will give you a rough answer so you can decide to create a separate test or an extended one.

So in general this could be used when i.e. implementations of interfaces you use are available and you want to test the real thing and making sure your code base is stable.

When to use ‘Integration testing’
These kinds of tests should actually only be run on some continuous build server and not on your local machine to determine if you made the code base unstable. I would say that these kinds of tests are run when the application is actually running so you know that your code actually works when deployed. This is more like a live test not only testing your code but also the configuration of the application. A good example of an integration test would be testing your web services in an automated way, doing the actual web service calls exactly the way they are going to be made when your application is used in production.

So in general always do this to make sure your application actually still runs when you deploy it.

When to use ‘Acceptance / functional testing’
Actually most of these kinds of tests should be done by a separate test team. They have a more objective look on the application than the developers that worked on it. You could write some automated tests that use i.e. the GUI and write some common use cases for your application. This will cause the test team to focus on only specific things that can go wrong. It also provides you with some valuable information that use cases where you wrote tests for, actually still work and have the desired outcome.

So in general I see this more as an extra thing to make it all much nicer and of course you will be able to notice problem in much earlier stage. This does save time eventually and is recommended.

Which tools to use for testing

For writing tests in general people use JUnit. When using the Springframework note that this framework also provides some handy classes to use as your base class for testing. And of course the famous EasyMock is used a lot for creating mock objects in an easy way. Actually there isn’t much to tell about the ‘normal’ testing of your code if it comes to tools.

When it comes to integration testing there are some tools you could use:
- Selenium
- Cargo
- JMeter
- MultiThreadedTC

Selenium
This tool is for automated GUI tests. You can record your actions in your browser and create a JUnit test from it and alter it accordingly.

Website:
http://selenium.openqa.org/

Cargo
To be able to start-up an application server in your tests you can use this tool for the job. You can start-up your application server and deploy your application and run test on it. This can be included in your automated build environment so you know your application actually still works correctly when you plan to deploy it.

Website:
http://cargo.codehaus.org/

JMeter
To load test your application you can use JMeter from Apache. This is something that should be run for every release actually to see if your application still performs the same.

Website:
http://jakarta.apache.org/jmeter/index.html

MultiThreadedTC
MultithreadedTC is a framework for testing concurrent applications. It features a metronome that is used to provide fine control over the sequence of activities in multiple threads.

Website:
http://www.cs.umd.edu/projects/PL/multithreadedtc/index.html

Why use interfaces for your domain objects?

2008-03-12T06:43:00.000-07:00

The opinions are spread about this subject. Some people even say that it's bad practice. I don't think it's bad practice but it might seem like overkill but I'll explain what the benefits are for doing this.

If you i.e. use Hibernate in your application you probably use Hibernate annotations in your POJO's. Actually domain objects mapped with annotations aren't really POJO's anymore because they have Hibernate dependencies. So if you don't use an interface for your domain object your logic will be stuck to Hibernate specific implementations of your domain objects and thus have Hibernate dependencies. Reusing your logic with some other technology i.e. IBatis will cause you to change more code than necessary if you would have had interfaces for your domain classes. This will also affects a lot of other layers where your domain objects are used. This could also been prevented by using an interface for your domain object.

The part in the application that will change the most and most likely will be reused in the future is the Service layer. To make sure it is easy to be reused it is better to use in interface for your domain object because this way the service layer is not coupled to anything at all. Only the interfaces he is talking to. This also makes sense because services don’t need to know to what kind of implementation he is talking to. He just wants to retrieve and manipulate data without worrying about i.e. Hibernate, IBatis etc.

If you take a look at the DAO layer and you would use an interface for your domain objects this would mean that all your DAO interfaces can be reused. If you just have an implementation your interface is stuck to that implementation so reusing it becomes difficult. If you use an interface for your domain object you enable the DAO layer to be reused in a better way and makes it easier to use different kind of persistency technologies.

Another interesting reason for using an interface for your domain object is if you want a SOA architecture and you want to run your persistence and logic on a separate server than your GUI will not be dependent on i.e. Hibernate that would be the case if you just use the implementation.

So if you sum all these things up you should see the benefits it will bring for you. If you are saying that it will cost to much time.. that's not really true. Because if you compare the time you will save in the future to the time you spend on only creating an interface this time can even be disregarded as most IDE's have features that make maintaining interfaces very easy. So I would say.. use it.. it will pay off.

JVM Memory usage

2008-02-23T14:58:00.000-08:00

During development of a J2EE application at my current employer I came across OutOfMemoryExceptions in the permGen space. The first thing we thought was that it was a memory leak in one of the applications where it occurred. After further investigation it seemed to be that we were pushing the limits of the JVM.

The big problem was that we had 3 EAR files deployed on a JBoss server that by itself already uses a lot of memory. Deploying so many EAR files in 1 JBoss instance is definitely not recommended when using the default JVM configuration. If you crank up the JVM max perm gen space than it is possible to have such a configuration. But keep in mind that if you crank up the permGen space other parts of the JVM memory have less. A better solution is trying to integrate your applications if possible so the common libraries are not loaded multiple times. If this is not possible try to deploy them on separate servers or undeploy some of the default applications of JBoss to save memory.

So when building web applications always make sure if it's really necessary to divide them into separate EAR files. Also check your memory usage of the application before releasing it live so you can prevent such problems.

The Google Webtoolkit

2008-01-03T18:40:00.000-08:00

Developing web applications in Java for a couple of years now the big annoyance part always was the GUI part. Making it work in every browser, implementing AJAX, etc.. AJAX is hot nowadays and when demands are rising I started looking for an easy to use AJAX framework to build a web application GUI in. I came across many frameworks like YUI (Yahoo User Interfaces), DWR in combination with spring MVC, Wicket and many more. The one that stood out the most was GWT (Google Web Toolkit). The nice thing about this framework is that you only code in Java :-). No more HTML, Javascript etc.. But if you really want to use HTML and Javascript (In some specific cases) you can, so full flexibility is available.

How does it work than? Your package structure needs to have a package called ...client and ...server. All code that is written in the client application is compiled to javascripts and HTML files are created where needed. The javascript that is created is compliant to the most used browsers like:
IE, Firefox, Mozilla, Safari and Opera. So no need to focus on that part anymore ;-). It's also optimized already for you so it will work as fast as possible.

Since this framework/toolkit is component oriented and implemented very nice it's much easier to reuse components. You can actually reuse components by using JAR files :-). Another great thing is that you don't have to do a mind switch because you are still coding Java with type checking etc. So you know what you write actually works. Something that you don't have when coding javascript. As we all know it's very error prone and hard to write good quality javascript that will work in every browser. The learning curve is therefore not steep at all. Coding with GWT looks and feels like coding a regular Swing application. I think this is the real power of GWT. Creating GUI's like you are used to be doing. Even if you didn't develop in Java it's the same principal i.e. in VB, Delphi, Borland C++ etc.. It's all roughly the same unlike using Struts, JSF, Spring MVC etc. Those are frameworks using a different approach and have a steep learning curve. Actually I wonder why no one else came up with this kind of technology earlier. It would have saved us a lot of headaches. At least that is my experience. I didn't come across any other framework that is as easy as the GWT. A lot off people think it's wonderful but I think they didn't really take a good look at GWT. I used Wicket and GWT both and must say that GWT is much better implemented and saves you more time in development.

I must say that Wicket is much better than i.e. Struts or Spring MVC but it doesn't beat GWT. GWT has more capabilities. To make your application look good and have drag & drop etc.. you can use i.e. GWT-ext. This way you can use the Javascript Ext components in GWT without writing javascript! :-D It looks very nice: http://code.google.com/p/gwt-ext/
So on that part you also save a lot of time because this library has a lot of controls/widgets you can use out of the box like a sortable table, calendars and many more. GWT 1.5 will support Java 5 syntax so that will be no issue anymore for the people that use Java 5. It's already available but isn't released yet.

There are also some nice Eclipse plug-ins for GWT like the GWT Designer from instantiations. You can take a look at it here:
http://www.instantiations.com/gwtdesigner/index.html

I recommend this one. It doesn't cost much and saves you a lot of time creating a GUI. Just drag & drop your components on to the screen and voila!

So I would say invest some time in the GWT and I am sure you will like it ;-)