This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Tried CMPRoster application (J2EE tutorial Sample) First deployment was OK without errors. Redeployment is failed due to ear file is locked by running Appserver.
Build used : 200502101900 on XP SP2 IDE output: do-clean: Deleting directory C:\cmprster\RosterApp\build Deleting directory C:\cmprster\RosterApp\dist C:\cmprster\RosterApp\nbproject\build-impl.xml:294: Unable to delete file C:\cmprster\RosterApp\dist\rosterapp.ear BUILD FAILED (total time: 0 seconds)
Sounds like we need ant task 'nbstop' and the entailed api=changes to support it: o.n.m.d.devmodules.api.Deployment.stop(J2eeModuleProvider jmp);
not sure about the need for stop.... Cannot reproduce with an ear that has only web apps... Would it be only for cmp ejb modules within ear? I don't have this app around... Could you try to stop the server before the 2nd deployment to make sure the lock is from the server itself?
Well, I cannot reproduce this state, so we need more info. I tried with a j2ee app with one ejb module plenty of cmp ejbs, and one web app. What I need to know is: do you use run or deploy popup menu? when you are in this state, can you attach the entire output of the build process? I am trying to see if you have a 'redeploy' or a deploy...This would be in this output.
Ludo, Stepan: I don't have windows to verify this, but can you try just Clean. The ant output seems to tell PCM is doing a Clean action instead of Redeploy?
Created attachment 20338 [details] Test application
Test application is attached. This application is taken from J2EE tutorial ("Roster" CMP application)
Created attachment 20339 [details] error message
Created attachment 20340 [details] IDE log
The bitmap is *not* about a "ear file is locked" error. So either we have 2 bugs or something. Alos the bitmap shows an error that would be more a user error... Can you check the application.xml and see if it points to the correct archives? If not, fix your J2ee app, as this is a message due to a user error. ps: I still cannot reproduce the lock bug... Should I close it as "workforme"?
As Ludo pointed out the problem is in your application.xml file, remove the following lines from it <module> <ejb>ejb-jar-ic.jar</ejb> </module> <module> <java>app-client-ic.jar</java> </module> <module> <ejb>ejb-jar-ic1.jar</ejb> </module> go to the J2EE Modules node of your RosterApp project and remove the web and the ejb module. Now, when you add those j2ee modules back, your application.xml file should be automatically updated and your problem should be fixed.
Downgrading to P2 since workaround exists - stopping the server before running clean & build action. lock issue: this bug seems to be similar to Tomcat jar locking issue 47919. We could probably use the same workaround - quiet delete. broken application.xml issue: this is already filed: issue 54829.
Setting the TM to 4.1.
After modifying application.xml <module> <ejb>ejb-jar-ic.jar</ejb> </module> <module> <java>app-client-ic.jar</java> </module> <module> <ejb>ejb-jar-ic1.jar</ejb> </module> with <module> <ejb>RosterApp-EJBModule.jar</ejb> </module> It is working fine. In the Information dislog the message is truncated and that is the reason I am not able to figureout the cause of the problem.
After modifying application.xml this is working fine.
Having an error occuring during J2EE application deployment should not cause file streams to not be released. I am seeing this same issue, when a J2EE application deployment fails the ear file is locked which causes subsequent deployment failures. This issue could be related to SunDeploymentManager, there is a suspicious ma.close() statement not in a finally block. I spoke about this with Nam and it appears this issue is related to the sun plug-in.
OK, reassigning to sunappserv module.
Cannot reproduce so far... I need a real scenario to reproduce.
Cannot reproduce so far... I need a real scenario to reproduce. If it was the sun plugin having the lock, then I think the same vm (i.e the IDE) could anyway delete this file. Also I did grep for the ma.close() without success. Please be specific. Finally, one app server related bug has been fixed in UR1: See http://monaco.sfbay/detail.jsp?cr=6226697 WOuld it be related?
cannot reproduce: p3, random
This could be the issue, the application I was deploying had a library.
So can you try with latest ur1 bits? http://javaweb.sfbay/java/re/sjsas_pe/8.1_01/nightly/bundles/latest/
PCM, can you reproduce this bug? How?
Ludo, I am not able to reproduce this bug after modifying "application.xml". I already update this information in issue report. -PCM
reopen if we has a test case...