glassfish_at_javadesktop.org wrote:
> Why are dependent jars being locked, forcing me to reboot the app server?
>
> [code]
> WARNING: The following file(s) were left(locked) from the previous deployment; they were not updated during this deployment and could interfere with the application: C:\glassfish\domains\domain1\applications\j2ee-apps\Portlets\DataAccess.jar C:\glassfish\domains\domain1\applications\j2ee-apps\Portlets\Utility.jar C:\glassfish\domains\domain1\applications\j2ee-apps\Portlets\jcommon-1.0.0.jar
> [/code]
>
> I've used JBoss up until now, for 2 years, and this never happened. Is there a way around this without having to restart Glassfish (very disruptive to other apps hosted on the same server)? Just undeploying the app and trying to redeploy it did nothing at all - it didn't help. How was it that I could undeploy it, yet somehow there are resources left behind to be locked?
>
>
Two comments:
1. Because these files lie within the GlassFish-managed directories, it
is probably the GlassFish server process that has locked the files but
Byron's suggestion is a very good one to verify that.
If it is the GlassFish server that has the files locked you can get a
very good idea of what code is locking the files by using the simple but
effective tool described on this blog entry:
http://blogs.sun.com/quinn/entry/tool_for_diagnosing_failed_glassfish
If you use the tool please follow the instructions carefully to get the
most useful information. You can post the results here or, if they are
large, feel free to send the output to me directly.
2. The message you are seeing is a warning, as it says, not necessarily
an error. What happens is this: GlassFish knows that on Windows some
files may become locked and therefore unable to be deleted or renamed
during undeployment or redeployment. This happens most often if an
application opens a stream to a resource in a JAR file that is part of
the application. This may happen without explicit coding by the app,
such as if it uses a third-party library that opens such resources.
Unfortunately this can also happen if a third-party library uses the
Java URLClassLoader which can lock JARs.
When you undeploy an app GlassFish tries to remove all the files from
the GlassFish directories, such as the library JARs you mentioned. If
it cannot this is not actually a failure of the undeployment because
end-users can no longer run the app. When you redeploy an app GlassFish
will overwrite-in-place any lingering files from a previous deployment,
and that works fine and GlassFish does not issue any warnings or errors.
But suppose you package a library jar a.jar into your app, deploy it,
then revise the app to remove a.jar and redeploy it. Further suppose
that a.jar is locked and so GlassFish could not remove it during the
earlier undeployment. In this case, GlassFish issues the warning
because there are files in the GlassFish-managed directories that should
not be there. There is a small chance that those files could interfere
with the execution of the new revision of the app. That is what this
warning means. Normally this would not be a problem, but because of the
small chance of a problem we included the warning you are seeing.
Please try continuing your work without restarting the server, despite
seeing these warnings. In most cases your newly-revised app should
behave as expected even though the locked files are still present.
I hope that helps.
- Tim