Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 215793 - no protocol: ${client.url} no protocol: ${client.url}
Status: NEW
Product: serverplugins
Classification: Unclassified
Component: GlassFish
PC Windows XP
: P1 with 3 votes (vote)
: 7.4
Assigned To: TomasKraus
Depends on:
  Show dependency treegraph
Reported: 2012-07-21 06:28 UTC by bht
Modified: 2013-03-03 00:09 UTC (History)
3 users (show)

See Also:

debug output of the generated ant script (232.29 KB, text/plain)
2012-07-21 06:28 UTC, bht

Note You need to log in before you can comment on or make changes to this bug.
Description bht 2012-07-21 06:28:26 UTC
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.
Comment 1 bht 2012-07-21 06:29:59 UTC
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.
Comment 2 TomasKraus 2012-09-14 10:37:23 UTC
This seems to be not related to Glassfish plugin, ${client.url} expansion should be done on project level.
Comment 3 David Konecny 2012-09-14 11:50:00 UTC
Have a look at j2ee.ant/antsrc/org/netbeans/modules/j2ee/ant/ - 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.
Comment 4 TomasKraus 2012-09-24 12:54:21 UTC
Targeting to 7.3 after all P1 and more fatal P2 will be solved.
Comment 5 TomasKraus 2012-10-18 14:35:00 UTC
There is still some layer between and and GlassFish.

Deployment.getDefault().deploy() will end up in
and this method returns deploymentTarget.getClientUrl(clientUrlPart);
what is in
org.netbeans.modules.j2ee.deployment.impl.projects.DeploymentTarget.getClientUrl(...) method.
Comment 6 TomasKraus 2012-10-18 15:06:02 UTC
Here is closer view on how GF plugin is accessed:


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"

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

This method is still using old CommandRunner class with isReallyRunning() check.
Comment 7 TomasKraus 2012-10-18 15:10:16 UTC
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.
Comment 8 bht 2013-02-23 21:17:22 UTC
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.
Comment 9 Petr Jiricka 2013-03-02 23:21:30 UTC
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.
Comment 10 bht 2013-03-03 00:07:44 UTC
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.
Comment 11 bht 2013-03-03 00:09:52 UTC
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.

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo