Although I did some testing with GlassFishv3TP2 in the past, it is only since yesterday that I am really diving deep into the GlassFish v3 code.
Installing GlassFish v3 TP2 (that is version 3, Technical Preview 2 if I am correct?) is straightforward and easy, except that the graphical installer never quits (on my Fedora system). No worries, the software got installed. I could also easily deploy a war in the Application Server.
Compared with the early days of installing the SunOne Application Server, installation and configuration has become much easier (or I have grown older).
The main reason I want to do some tests with GFv3, however, is to see how exactly OSGi is used internally, and if/how it can be used by applications as well. The best way to find out, is to have a look at the code.
I downloaded the trunk version of GFv3 from the svn repository. The build system for GFv3 is Maven, and I am not very familiar with this tool. It didn't take too long, however, before I could build and run the whole Application Server. Some useful notes about building GFv3 with Maven can be found at http://wiki.glassfish.java.net/Wiki.jsp?page=HowDoesV3BuildWorks and at http://wiki.glassfish.java.net/Wiki.jsp?page=V3DevelopmentInstructions.
Next step: make some changes to the code and run the appserver again. That didn't work with the "mvn gf:run" command for me, unfortunately.
But I noticed that the created jar files were placed in my local maven-repository, so I c ould copy them manually to the GlassFish working directories.
At this moment, the startup process in my local working copy is broken due to
Exception in thread "main" java.lang.NoClassDefFoundError: com/sun/enterprise/module/Repository at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:68)
Indeed, ASMain.java uses ASMainFelix.java or ASMainKnopflerFish.java, and these classes extends ASMainOSGi which imports import com.sun.enterprise.module.Repository. And that class isn't in my current source tree. However, building with maven works fine, so I guess maven adds some jars to the classpath that are not in my working directory. I haven't find a way to discover or influence the classpath that is used when compiling, but no worries, we'll solve this. And then we are looking forward to the next problem 😉
Johan's blog 