Hi, O.
The info from the class loader may not be too helpful.
The forum and the issue list has numerous entries on this sort of problem - JARs remaining locked and thus causing undeployments or redeployments to fail. Ultimately this ties back to the Windows prohibition against renaming or deleting open files. Often in these situations the JARs are opened by class loaders based on the JDK's URLClassLoader (or that loader itself) which opens JARs to load classes and find resources but does not provide a way for the caller to indicate that it is finished with that class loader and, therefore, open JARs should be closed. The app server itself uses its own class loader for precisely this reason so that clean-up can occur.
GlassFish V2, starting with build 14 (and there have been quite a few since then), has significant improvements in how locked JARs are handled that would probably help you a great deal. I don't know if using the more recent version is an option for you. (If it is, keep in mind that you will want to use NetBeans 5.5.1 with GlassFish V2 - you mentioned that you used NetBeans with your app.) This blog entry explains the behavior and the ideas behind the fix:
http://blogs.sun.com/quinn/entry/addressing_locked_jar_problems
If you want to do a little detective work you can download and use this free (and totally unsupported but quite useful) tool that will help identify what logic is opening but not closing the locked JARs. This blog entry
http://blogs.sun.com/quinn/entry/tool_for_diagnosing_failed_glassfish contains a link to the tool and gives detailed instructions for how to use it. If you choose that route, please feel free to post the results from the tool here or you can e-mail me directly if you'd prefer.
- Tim
[Message sent by forum member 'tjquinn' (tjquinn)]
http://forums.java.net/jive/thread.jspa?messageID=220270