Vincent Deschênes wrote:
> Here is my test project sandbox.
>
> I am using java 1.6_17.
> Eclipse plug-in 1.0.41.
> Windows XP.
> I have tried "GlassFish v3 (build 47.4)" and "GlassFish v3 (build 72)". Both generate the problem.
>
> Make sure testproject.jar get deployed to "...glassfishv3\glassfish\domains\domain1\eclipseApps\testAPP\lib".
> Then without restarting the server try a publish.
>
> Thanks.
>
> VD
>
> -----Original Message-----
> From: Ludovic.Champenois_at_Sun.COM [mailto:Ludovic.Champenois_at_Sun.COM]
> Sent: Monday, November 30, 2009 10:28 AM
> To: users_at_glassfish.dev.java.net
> Subject: Re: Cannot deploy using Eclipse plugin. Jar file May be locked by another process
>
> Vincent Deschênes wrote:
>
>> I must be doing something wrong.
>>
>> I did some tests. I have created a simple ear application with only one jar file in the lib directory. And a simple web app.
>> The jar only contains a simple class with a String member. The class is not even used by the web app. And I am still having this
>> lock file issue.
>> So it can not be that the jar contains a class which would not close an handle.
>> I have also validated that the process locking the file is java.exe.
>>
>>
> Will try to reproduce... (or zip you entire ear project if you can).
> Also, let us know the gf build number you are using, plugin number, JDK
> and exact os (vista,xp,win7?)
> Ludo
>
>> VD
>>
>> -----Original Message-----
>> From: Ludovic.Champenois_at_Sun.COM [mailto:Ludovic.Champenois_at_Sun.COM]
>> Sent: Friday, November 27, 2009 3:29 PM
>> To: users_at_glassfish.dev.java.net
>> Subject: Re: Cannot deploy using Eclipse plugin. Jar file May be locked by another process
>>
>> Vincent Deschênes wrote:
>>
>>
>>> If you have an application with jar file in the lib directory that are used by your application the publish will always fail
>>>
>>>
>> (except
>>
>>
>>> for the first time).
>>> The only solution is to restart your server.
>>>
>>> So when your server is running, each time you save a file the plugin will try to publish it and will fail whith an error like
>>>
> this
>
>>>
>>>
>> :
>>
>>
>>> Could not delete C:\glassfishv3\glassfish\domains\domain1\eclipseApps\....jar. May be locked by another process.
>>>
>>> If there is no file in your EarContent\lib or WEB-INF\lib folder there is no problem.
>>>
>>> I am using the pluging version 1.0.41 on Eclipse 3.4.1 and latest glassfish V3 on Windows.
>>>
>>>
>>> I can not beleive a bug like this can exist for that long.
>>> This is why I am asking out what solution users found to this problem.
>>>
>>> I have found an unresolved issue here:
>>> https://glassfishplugins.dev.java.net/issues/show_bug.cgi?id=219
>>>
>>>
>>>
>> The process which lock the files is the server, not Eclipse or the plugin.
>> It is usually related to external frameworks that keep files locked (no
>> cleaning at undeploy time), not GlassFish itself.
>> Try http://blogs.sun.com/quinn/entry/tool_for_diagnosing_failed_glassfish
>> http://blogs.sun.com/quinn/entry/addressing_locked_jar_problems
>> Ludo
>>
>>
>>> Thanks.
>>>
>>> Vincent Deschenes
>>>
Not sure yet about the entire issue, but here is what is working for me.
Since the lib project is defined as an Eclipse project, it seems you
also want to edit/modify this lib project. So instead of physically
adding the jar "tesproject.jar" inside the lib dir of the EAR, just
remove this static inclusion (go to the ear project and EarContent/lib
directory and delete the jar).
Then, edit the Ear project properties, go to the "Java EE Modules
Dependencies" tab, and select the testproject.jar and select the "In Lib
Dir" check box.
This way, Eclipse will make sure that whenever you change your lib
project, the new updated lib content will be changed in the EAR.
You'll notice than in the deployed area
C:\glassfishv3\glassfish\domains\domain1\eclipseApps , the lib jar will
be in fact an exploded direcotory deploy jar, so that you get
incremental changes (if you only change 1 class in your lib) effect.
Redeployment in this configuration is working fine.
I'll continue to investigate the locking issue, but for now, you have
another setting that works and is more developer friendly (i.e changes
in the lib affect changes in the ear)
Ludo