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.
In the latest build 20041215-0521 it is impossible to run web application. It throws a bunch of exceptions and ends with message: "Deployment FAILED: Context path is required". It is urgent because it blocks the commit validation suite. In change logs there is only one commit done by Ludo. I don't know if this can cause this problem but previous build was OK. To reproduce: - create a web application project - set Bundled Tomcat for running the project in its properties - run the project => exceptions are printed out and finally the Deployment progress Monitor dialog shows a message: "Deployment FAILED: Context path is required". Build 20041215-0521, JDK1.5.0_01.
Created attachment 19298 [details] IDE log with stack traces
You cannot even create a web app project when sjas is the default server, for tomcat it works. I know that Nam has done some changes in j2eeserver to support multiple config files which may be realted to this. They are probably used in the version of plugin checked in by Ludo. Jirka will disble the test, do not close this P1 until the test is added back.
Ludo, please reassign as needed.
Nam: on my private build, I cannot reproduce... Why would j2eeserver get this NPE in storage...?
one comment: did you correctly set up the J2EE platform manager and picked a valida 8.1 installation directory and restarted the IDE?
No, I used bundled Tomcat. But the first exception was thrown during project creation.
I just synced with trunk, rebuild and can't reproduce this. I can deploy successfullly using the test case against both tomcat and sunas. The test case needs refined or the code has change since the failure?
OK, the precise test case should include precondition of a brand-new userdir. This one would make the AS81 plugin non-operational (No AS81 installation directory specified yet). Yet the default server instance still is localhost:4848. Create a new WebAppliation, would cause an array of stack traces, originate from the fact that list of configuration files now depends on DeploymentPlanSplitter class packaged in one of the library from the installation. This is from a change in the plugin, not a recent change in j2eeserver. However, the fixes should be in j2eeserver: (1) Consolidate the deployment config file list declaration to be from the layer.xml; deprecating the declaration from DSP. (2) Bullet-proof the get/setContextRoot() call from failure to load configuration. I will commit the fixes later today.
Ludo, Nam, thanks for testing this. The non operational as8 in time of commit validation was why I removed the test in the first place, but seems like it has been working for some time after Jiri re-added it and now there is a regression. Thanks for fixing this.
Fix checked in. Test can be turn backon and issue closed if all tests passed.
Changing Target milestone and resolution instead of Nam.
Test added again and passed in build 20041216-0726.