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.
Created attachment 122237 [details] debug output of the generated ant script This error is hard to reproduce, but it has happened many times with the same web project. I first thought that this has to do with the fact that the project runs in root application context but that may not be the case. It mostly occurs after something in the project setup is fresh, e.g. a new server, or as in this case, when the server was "lost" after the project had been opened by an older version of the IDE (7.1.2) that does not know about the new server. The error then happened after the project is opened again with the new IDE version (7.2 dev). I have taken a snapshot copy of the project. So additional information may be available. Please request. In the projects window, I opened the Web Pages node and right clicked on index.html|Run File. I could just have run the application with the same result.
Product Version: NetBeans IDE Dev (Build 201206280002) Java: 1.7.0_04; Java HotSpot(TM) Client VM 23.0-b21 System: Windows XP version 5.1 running on x86; Cp1252; en_NZ (nb) User directory: C:\Documents and Settings\name\Application Data\NetBeans\dev Cache directory: C:\Documents and Settings\name\Local Settings\Application Data\NetBeans\Cache\dev I don't think the version matters much - this bug has been around for a long time.
This seems to be not related to Glassfish plugin, ${client.url} expansion should be done on project level.
Have a look at j2ee.ant/antsrc/org/netbeans/modules/j2ee/ant/Deploy.java - that's were client.url property is set to a value returned by Deployment.getDefault().deploy(), that is a value coming from the server. GlassFish is not setting it after deployment.
Targeting to 7.3 after all P1 and more fatal P2 will be solved.
There is still some layer between and and GlassFish. Deployment.getDefault().deploy() will end up in org.netbeans.modules.j2ee.deployment.devmodules.api.Deployment.deploy(...) and this method returns deploymentTarget.getClientUrl(clientUrlPart); what is in org.netbeans.modules.j2ee.deployment.impl.projects.DeploymentTarget.getClientUrl(...) method.
Here is closer view on how GF plugin is accessed: org.netbeans.modules.glassfish.javaee.ide .Hk2TargetModuleID.getWebURL(Hk2TargetModuleID.java:119) org.netbeans.modules.j2ee.deployment.impl .TargetModule.getWebURL(TargetModule.java:200) org.netbeans.modules.j2ee.deployment.impl.projects .DeploymentTarget.findWebUrl(DeploymentTarget.java:211) org.netbeans.modules.j2ee.deployment.impl.projects .DeploymentTarget.getClientUrl(DeploymentTarget.java:134) org.netbeans.modules.j2ee.deployment.devmodules.api .Deployment.deploy(Deployment.java:214) org.netbeans.modules.j2ee.ant .Deploy.execute(Deploy.java:111) ... In Hk2TargetModuleID.getWebURL(...) null is returned when contextPath of deployed application is not known. This value is coming from constructor. "exec_WebApplication1 (run-deploy)_1" org.netbeans.modules.glassfish.javaee.ide .Hk2TargetModuleID.<init>(Hk2TargetModuleID.java:72) org.netbeans.modules.glassfish.javaee.ide .Hk2TargetModuleID.get(Hk2TargetModuleID.java:93) org.netbeans.modules.glassfish.javaee.ide .Hk2TargetModuleID.get(Hk2TargetModuleID.java:81) org.netbeans.modules.glassfish.javaee .Hk2DeploymentManager.getDeployedModules(Hk2DeploymentManager.java:454) org.netbeans.modules.glassfish.javaee ... In Hk2DeploymentManager.getDeployedModules(...) List of applications including context root is being retrieved by AppDesc [] appList = commonSupport.getModuleList(GlassfishModule.WEB_CONTAINER); This is being retrieved using administration command API org.netbeans.modules.glassfish.common.CommonServerSupport.getModuleList(...) This method is still using old CommandRunner class with isReallyRunning() check.
This is not show stopper and also it's happening only from time to time so I'm moving it to enhancements requests for next release. We already have 7.3 in testing only stage and it's not a good idea to start with some large changes here. This piece of code (getModuleList method) will be rewritten from scratch to use GF Tooling SDK commands API.
Ehhancement? In my projects, with 7.3 release, this now breaks always. Combined with bug 224528 this is fundamental. I have some doubts whether 224528 can be solved unless we challenge the outcome of bug 226239 with some major breakthrough. When will we have a working flow for deploying web app classes even for the traditional edit-compile-run cycle? This seems to always get broken by something. Deploy on save does not work for me except for hello world sample apps.
I tend to agree that exceptions are typically bugs rather than enhancements, but still, can you please elaborate on the exact scenarios when this happens and what is the impact on the workflow? Thanks.
It happens when I run a web project that is deployed to GlassFish. Only recently with 7.3 it seems to happen 90% of the time to me. My application is in the root context which at times I thought might make a difference, but I don't know. From my perspective the compile/deploy/run cycle should be uninterrupted and flawless given that it has been around for so long. There are new technologies with their own software stack that use the Eclipse compiler plugin without the need to even re-deploy anything except saving source code - see Play Framework. I feel being left behind even with the latest NetBeans technology. So perhaps the regression keyword would help a bit.
It happens if I select the projects window Run context menu item on the web project node. There is an error in the output window after the project was deployed successfully.