Creating Unit Tests in Eclipse

In eclipse, with Designer, you can create a unit test with New -> Other -> Designer -> GWT -> JUnit Test Case

Choose the class you want to test.

This will create a source directory called src-test, the test case which extends GWTTestCase? , and it willl automatically add the module name for you.

Add the jar gwt-dev-windows.jar in the GWT distro to your classpath.

To run from within eclipse, you can just choose "Run as GWT Junit Test"

To run from ant, make sure the source and test source directories are on the classpath.

Example ant file:

how to setup your run configuration to run your GWT app under eclipse.

Assuming you have tried to run your GWT app and failed...

Open Run Dialog and locate your app run config. Copy the following into the VM arguments field in the Arguments tab

-Xmx512m
-Djava.naming.factory.initial=org.jboss.security.jndi.JndiLoginInitialContextFactory
-Djava.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces
-Djava.naming.security.principal=admin
-Djava.naming.security.credentials=admin
-Djava.naming.provider.url=localhost:1099

Copy the attached jndi.properties file into a folder called conf and add that folder to the project classpath (I do this by adding it as a src folder).

Add Jboss Client and Jboss libraries to your project cllasspath (you need jboss client jars as well as server jars).

Get rid of Log 4 J library if you have it on classpath (when we migrated to Jboss 4.2.3, I started getting weird errors about TRACE field not being available - probably jboss uses a newer log4j version that what is in our libs).

Dual Booting, MBR and Grub

I had Linux and Solaris installed and had an empty partition I wanted to install Windows on. When installing Windows, I was able to choose the correct partition and format it, however then it something about Windows needing the active partition to be set. This is a dos term and meaning is bootable partition. Windows apparently overwrites the Master Boot Record (which is

master boot record (MBR), or partition sector, is the 512-byte boot sector that is the first sector ("LBA Sector 0") of a partitioned data storage device such as a hard disk.

There can however be a boot sector for each partition.

BIOS executes code in the MBR which could be the code that bootstraps windows (called a chain loader ) or it can be code that can load and run Grub, which can bootstrap any OS. Info on how Grub works:

http://www.redhat.com/docs/manuals/linux/RHL-7.2-Manual/ref-guide/ch-grub.html

GWT Exceptions

You need to declare RuntimeExceptions as throwable from GWT servlet if you want to be able to catch it in the javascript. Otherwise you will just get a StatusCodeRPC exception or whatever.

change default python version

Doesn't sound very official, but apparently you change the /usr/bin/python symlink to point to /usr/bin/python2.5 and then change instances of python2.5 in /usr/share/python/debian_defaults

Static vs Dynamic Libraries

I always wanted to understand the mechanism by which your C program calls library code at runtime.

From http://stackoverflow.com/questions/311882/what-do-statically-linked-and-dynamically-linked-mean

When you compile some C code (for instance), it is translated to machine language. Just a sequence of bytes which when run causes the processor to add, subtract, compare, "goto", read memory, write memory, that sort of thing. This stuff is stored in object (.o) files.

Now, a long time ago, computer scientists invented this "subroutine" thing. Execute-this-chunk-of-code-and-return-here. It wasn't too long before they realised that the most useful subroutines could be stored in a special place and used by any program that needed them.

Now in the early days programmers would have to punch in the memory address that these subroutines were located at. Something like CALL 0x5A62. This was tedious and problematic should those memory addresses ever need to be changed.

So, the process was automated. You write a program that calls printf(), and the compiler doesn't know the memory address of printf. So the compiler just writes CALL 0x0000, and adds a note to the object file saying "must replace this 0x0000 with the memory location of printf".

Static linkage means that the linker program (the GNU one is called ld) adds printf's machine code directly to your executable file, and changes the 0x0000 to the address of printf. This happens when your executable is created.

Dynamic linkage means that the above step doesn't happen. The executable file still has a note that says "must replace 0x000 with the memory location of printf". The operating system's loader needs to find the printf code, load it into memory, and correct the CALL address, each time the program is run.

It's common for programs to call some functions which will be statically linked (standard library functions like printf are usually statically linked) and other functions which are dynamically linked. The static ones "become part" of the executable and the dynamic ones "join in" when the executable is run.

Also good:
http://www.learncpp.com/cpp-tutorial/a1-static-and-dynamic-libraries/