It looks like our problems with GlassFish have just began. Whereas the installation issues found a quick solution, we almost immediately ran into a year old problem, reported by the guys from YourKit. The issue is with with loading the “ServerLogManager” class (see also this forum post).

A quick foray into the JDK source shows that log managers are loaded from the system classloader and then from the Thread context classloader. Of course in case of GlassFish the manager is not in the system classpath, but instead found via the context classloader. However the context classloader is set only after GlassFish initialization begins, so any agents that need to access Java API before that are left in the void (both YourKit Profiler and JavaRebel feature instrumentation agents, which are initialized before the actual application begins execution).

To be fair this is a definite failing in the JDK log manager resolution logic. Since log managers are determined using a system property it is dangerous to assume that their resolution is in any particular context (which context classloader obviously implies). GlassFish just happened to hit this case, since very few others use a custom log manager for the JDK logging. The only reasonable fix I can see here is lifting the ServerLogManager to the system classpath and decoupling it from the child classloaders.

For those who can’t wait until it’s fixed it seems that adding “-Drebel.disable_update=true” to the jvm-options also fixes the problem for JavaRebel (it disables the update notification, which is apparently the only thing in JavaRebel that utilizes JDK logging).

Writen by one of the first JavaRebel users, Nathan Hamblen, this JavaWorld article talks about building applications with a text editor, Buildr, Jetty and JavaRebel. Bringing examples from Wicket and Scala applications it is worth a read whether you plan to develop without an IDE or not.

JavaRebel 1.0.1 includes support for GlassFish v2 or later and some minor fixes to reflection support.

Disclaimer: Since some of you took this personally I want to make a few things clear. This is not an attack on GlassFish or its community. This is just a recap of my personal experience with installing it and the resulting frustration. This could be avoided in the future with a couple of simple fixes.

I just had the weirdest installation experience ever. We are trying to get JavaRebel to work with Glassfish and for that, of course, we need at the very least to install it.

After downloading the JAR I assumed that it will be the usual self-extracting installation package, like the one JDK comes with. When I ran the JAR it displayed a license agreement dialog and vanished with no message of any kind. I assumed that perhaps it’s not a self-installing JAR after all and needs to be unziped manually. Inside the JAR I found a single “glassfish.class” over 50 MB large. After some thought I found out that it unzipped itself in the current directory (which just happened to be my “download” dir with about a hundred other folders). Finally I could start using Glassfish!

Quickly it turned out I was wrong. There was no kind of executables or scripts of any kind that I could start the server with. Of course the first thought was that the extraction process did not finish (remember the lack of message or progress bar). After reiterating through the same process twice I googled for “glassfish quick start” (there was no installation guide with the distribution that I could find). Although it didn’t really talk about installation, it mentioned in passing that I should have ran “ant -f setup.xml” at some point. Turned out this was what extracted all of the scripts and everything else.

So the real question I want to ask is why can’t I just get a ZIP, unzip it and run?

UPDATE: although GlassFish now runs fine when I tried to deploy the Java EE tutorial sample applications it turned out that’s nearly impossible without NetBeans (all build scripts are bound to the .nbproject or somesuch). Is there no end to this torment? I understand that Sun favors NetBeans, but why tie everything to it?

UPDATE 2: Toomas got GlassFish running before me and support is included in the JavaRebel 1.0.1 release. Enjoy!

In addition to the final release we are proud to present the first ZeroTurnaround animated short. It tells a story of an enthusiastic Java programmer who found JavaRebel and how it changed him forever. And you may just know that guy :)

We would also like to apologize to the DZone community, which saw the said short mislabeled as pure entertainment. Yes, this is a promotional animation and it should have been labeled as such and we are very sorry for doing just the opposite. Regrettably DZone does not provide a way to change title or description after submission.

We are proud to announce the immediate availability of the JavaRebel 1.0 Final Release! The final release incorporates all of the improvements of the previous releases and fixes a number of issues reported by our users. To celebrate the final release we have also made this cartoon.

JavaRebel eliminates the need for application server redeployment by instantly reloading changes to Java classes. It can also be used for standalone Java applications to pick up changes without restarting. For the impatient: watch the demonstration screencast (~5 mins) and download!