Frequent readers of the GlassFish forum (here's part of one such thread) would know that one annoyance plaguing some users has been that releases of Java 1.6 (up through update 03) have included version 2.0 of Java Web Services (JAX-WS). This was a good step forward for non-GlassFish Java users, who were then able to benefit from the improvements without having to worry about explicitly managing classpaths to include the updated JAX-WS JARs.
But GlassFish depends on - and therefore bundles with itself - JAX-WS 2.1. This worked fine for the server, which manages its classpath to use the bundled 2.1 libraries. But for app clients, especially ones launched using Java Web Start, this was a real pain. Why? The GlassFish class loaders follow the normal class loader delegation model, in which a loader defers to its parent to load a class or resource and only if the parent cannot do so will the loader try to resolve the class or resource itself. With Java SE 1.5 - which did not include JAX-WS JARs - the GlassFish class loader would load JAX-WS classes from the bundled 2.1 libraries because the ancestor loaders would not find any of those classes.
With Java SE 1.6, the ancestor loaders (specifically, the Java runtime bootstrap class loader) would resolve the web services classes using the JAX-WS 2.0 libraries. This would cause attempts to use GlassFish web services to fail because the GlassFish web services code knows it needs 2.1 and checks for that version explicitly.
Some users could work around this by installing the JAX-WS 2.1 JARs as endorsed extension JARs which would allow the Java runtime bootstrap class loader to resolve the 2.1 classes instead of the 2.0 ones.
But this was a real problem for users launching app clients using Java Web Start. The whole point of Java Web Start in general, and the GlassFish support of it for launching app clients, is that you want to avoid having to prepare the environment on the client systems ahead of time. You just click and launch, and everything that user needs is downloaded (if it is not already cached on the client system). Requiring you as a developer or administrator to go to every client system to install the 2.1 libraries as an endorsed extension runs completely counter to the intent and basically robs the benefit of the Java Web Start launch feature of any value.
Now that Java SE 1.6.0_04 includes the JAX-WS 2.1 libraries (instead of the 2.0 ones) this problem gets easier. Of course, you need to make sure that the client system is running 1.6.0_04 or later. At least it is much easier to ask your user community to install an update to Java (send a single URL) than to ask them to install JAX-WS 2.1 as an endorsed extension. (I can only imagine the look on an average end-user's face when asked to do that!)
So Java SE 1.6.0_04 does not make this problem go away completely, but it does make it a bit easier to solve.