I manually undeployed the app from SJSAS, then tried the "Undeploy and Deploy" command.  It still gave me the error, but
did deploy.

I tried a few more times and the most recent time the error was gone, but SJSAS shows an error:

java.io.FileNotFoundException: D:/dev/MyProject/MyProjectEAR/dist/gfdeploy
        at com.sun.enterprise.deployment.deploy.shared.FileArchive.open(FileArchive.java:79)
        at com.sun.enterprise.instance.AppsManager.getAppDescriptor(AppsManager.java:355)
        at com.sun.enterprise.server.ApplicationLoader.<init>(ApplicationLoader.java:112)
        at com.sun.enterprise.server.TomcatApplicationLoader.<init>(TomcatApplicationLoader.java:88)
        at
com.sun.enterprise.server.pluggable.TomcatApplicationLoaderFactory.createApplicationLoader(TomcatApplicationLoaderFactory.java:63)
        at com.sun.enterprise.server.ApplicationManager.getLoader(ApplicationManager.java:166)
        at com.sun.enterprise.server.AbstractManager.load(AbstractManager.java:201)
        at com.sun.enterprise.server.ApplicationLifecycle.onStartup(ApplicationLifecycle.java:217)
        at com.sun.enterprise.server.ApplicationServer.onStartup(ApplicationServer.java:442)
        at com.sun.enterprise.server.ondemand.OnDemandServer.onStartup(OnDemandServer.java:120)
        at com.sun.enterprise.server.PEMain.run(PEMain.java:411)
        at com.sun.enterprise.server.PEMain.main(PEMain.java:338)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at com.sun.enterprise.server.PELaunch.main(PELaunch.java:412)

My app is deployed, and seems to be running fine?

These issues might be because I am bringing a NB 5.5.1 project over to NB 6.0, and replacing the NB 5.5.1 deployed
projects with the newly built NB 6.0 projects

I've learned some more.  In order to deploy without errors I first have to manually undeploy the project from the app
server, restart the app server, then use the "Undeploy and Deploy" menu item.  If I don't restart the app server, I
still get the errors.

Could you please attach the project that is causing the deploy failure. 

I'm sorry I cannot provide the project. It is a large closed source system with many dependencies.  Maybe I could create
a new EAR and if it has the same problems, I could attach it.  Inside the EAR is an EJB module project, two VWP
projects, and the dependencies.

regarding the comment from rdelaplante Thu Oct 11 20:23:32 +0000 2007....

Do you need to go through this 'undeploy, stop server, start server, "undeploy and deploy"' process when you want to
redeploy the app... after you have gotten it to deploy with this process initially?

I only did it two or three times yesterday, but yes I had to do that every time. 

I know I ran into this a couple of times:

"undeploy and deploy", error message, go to glassfish to try to undeploy but the app has already been undeployed,
"undeploy and deploy", error message, restart glassfish, "undeploy and deploy", either success or error message (I
forget) but the app works.

And later:

manually undeploy from glassfish, "undeploy and deploy", error message, restart glassfish, "undeploy and deploy", either
success or error message (I forget) but the app works.


I didn't really understand what was happening and was experimenting with different steps in different orders.

I have not been able to reproduce this issue. 
Are you still seeing this error? Could you try to deploy this project on a clean appserver and list the steps and
behavior you are seeing. 

Funny you ask.. I forgot about this issue because I haven't noticed it lately.  However I haven't been deploying that
app much, and have been restarting the app server semi-frequently because of file locking issues.  When I try to do
builds, or clean-builds it fails because it can't delete files.  I just tried an "Undeploy and Deploy" on the EAR now
and got this exception:

Initial deploying MyProjectEAR to D:\dev\MyProject\MyProjectEAR\dist\gfdeploy
Error during incremental deploy: org.netbeans.modules.masterfs.filebasedfs.utils.FSException: Cannot delete file
velocity-dep-1.5.jar in D:/dev/MyProject/MyProjectEAR/dist/gfdeploy.
Start registering the project's server resources
Finished registering server resources
Deployment error:
null
See the server log for details.
        at org.netbeans.modules.j2ee.deployment.devmodules.api.Deployment.deploy(Deployment.java:163)
        at org.netbeans.modules.j2ee.ant.Deploy.execute(Deploy.java:104)
        at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
        at sun.reflect.GeneratedMethodAccessor339.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105)
        at org.apache.tools.ant.Task.perform(Task.java:348)
        at org.apache.tools.ant.Target.execute(Target.java:357)
        at org.apache.tools.ant.Target.performTasks(Target.java:385)
        at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1329)
        at org.apache.tools.ant.Project.executeTarget(Project.java:1298)
        at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
        at org.apache.tools.ant.Project.executeTargets(Project.java:1181)
        at org.apache.tools.ant.module.bridge.impl.BridgeImpl.run(BridgeImpl.java:277)
        at org.apache.tools.ant.module.run.TargetExecutor.run(TargetExecutor.java:460)
        at org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:151)
Caused by: java.lang.NullPointerException
        at org.netbeans.modules.j2ee.sun.bridge.DirectoryDeployment.initialDeploy(DirectoryDeployment.java:326)
        at
org.netbeans.modules.j2ee.sun.ide.j2ee.incrdeploy.DirectoryDeploymentFacade.initialDeploy(DirectoryDeploymentFacade.java:210)
        at org.netbeans.modules.j2ee.deployment.impl.TargetServer.deploy(TargetServer.java:508)
        at org.netbeans.modules.j2ee.deployment.devmodules.api.Deployment.deploy(Deployment.java:148)
        ... 16 more
BUILD FAILED (total time: 5 seconds)

I stopped the app server and was able to do a build.  I started the app server back up, and "Undeploy and Deploy". It
worked, and I was able to run my app.  Without restarting the app server, I tried to "Undeploy and Deploy" again.  It
gave the same exception.

Maybe it was just a fluke that it chose the .svn folder when I originally created the ticket.  Now it's complaining
about velocity-dep-1.5.jar.  I still wonder why I did not have this problem on NB 5.5.1 but do on 6.0.

Regarding trying with a clean app server, I'll have to make some time to do that this week. I'll have to install
Glassfish on an other computer and set it all up etc.

I forgot to show the second exception, the one while deploying to the app server. I said it was the same exception, but
it turns out the stack dump is slightly different.  It is still complaining about deleting the velocity-deps file.

Undeployment of application MyProjectEAR  completed successfully
All operations completed successfully
Initial deploying MyProjectEAR to D:\dev\MyProject\MyProjectEAR\dist\gfdeploy
Error during incremental deploy: org.netbeans.modules.masterfs.filebasedfs.utils.FSException: Cannot delete file
velocity-dep-1.5.jar in D:/dev/MyProject/MyProjectEAR/dist/gfdeploy.
Start registering the project's server resources
Finished registering server resources
Deployment error:
null
See the server log for details.
        at org.netbeans.modules.j2ee.deployment.devmodules.api.Deployment.deploy(Deployment.java:163)
        at org.netbeans.modules.j2ee.ant.Deploy.execute(Deploy.java:104)
        at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
        at sun.reflect.GeneratedMethodAccessor339.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105)
        at org.apache.tools.ant.Task.perform(Task.java:348)
        at org.apache.tools.ant.Target.execute(Target.java:357)
        at org.apache.tools.ant.Target.performTasks(Target.java:385)
        at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1329)
        at org.apache.tools.ant.Project.executeTarget(Project.java:1298)
        at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
        at org.apache.tools.ant.Project.executeTargets(Project.java:1181)
        at org.apache.tools.ant.module.bridge.impl.BridgeImpl.run(BridgeImpl.java:277)
        at org.apache.tools.ant.module.run.TargetExecutor.run(TargetExecutor.java:460)
        at org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:151)
Caused by: java.lang.NullPointerException
        at org.netbeans.modules.j2ee.sun.bridge.DirectoryDeployment.initialDeploy(DirectoryDeployment.java:326)
        at
org.netbeans.modules.j2ee.sun.ide.j2ee.incrdeploy.DirectoryDeploymentFacade.initialDeploy(DirectoryDeploymentFacade.java:210)
        at org.netbeans.modules.j2ee.deployment.impl.TargetServer.deploy(TargetServer.java:508)
        at org.netbeans.modules.j2ee.deployment.devmodules.api.Deployment.deploy(Deployment.java:148)
        ... 16 more
BUILD FAILED (total time: 2 seconds)

This does seem related to Windows file locking issues. Will investigate some more.

Unable to consistently reproduce this issue. Happens randomly on redeploy or clean of a deployed project. 
Did not see this any issues at all, if deployed after disabling Directory Deployment.

rdelaplante, could you deploy this project after disbling Directory Deployment? Services->GlassFish
V2->Properties->Options->Directory Deployment Enabled checkbox.

Yes this helped, I don't have to restart Glassfish every time I want to try a change now! Thanks.

WA - disabling directory deployment works. Will file an IZ against GlassFish regarding this behavior.
Downgrading to P3.

There is a long history of file locking problems on Windows.  I have blogged about it in connection with GlassFish and
posted a tool that helps diagnose the cause of such lock-ups here
http://blogs.sun.com/quinn/entry/tool_for_diagnosing_failed_glassfish.

In the more recent file-locking variation of this problem does the GlassFish server.log contain anything helpful?

Clearly, some code somewhere is opening a stream to the JAR and not closing it.  The tool I mentioned helps to pinpoint
the code that opens the JAR.  

The reason this behavior is intermittent is that garbage collection can trigger finalizers that close the files. If GC
has run, then a subsequent delete or rename might work; if it has not run then the JAR might remain open thereby causing
the next delete or rename attempt to fail.  Because the memory usage in GlassFish can vary greatly depending on what is
asked of it and in what order, the problem can seem to come and go with no apparent pattern.  Truly maddening.

If GlassFish itself or code that GlassFish invokes (such as the application or a third-party library) is opening the
JAR, then the tool will show where and that's the first step in understanding this problem.  If you use the tool please
follow the instructions carefully to get the most focused output and post it here.

- Tim

This is still an issue on RC2. Even if file locking issues are GlassFish issues, shouldn't NetBeans not be doing a stack
dump of a NullPointerException?

In an earlier comment by Nitya, it soulds like the root cause needs to be fixed on the GlassFish side. Has a bug against
GF been filed? Thanks.

please close this issue if you forgot to earlier.  If this issue is still open,
please change the target milestone to reflect the current commitment.

Will try to reproduce this again with the latest server versions and close/update accordingly.

Tested several times with various applications. Cannot reproduce.
Closing.