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.
NB 3.6 may not support creating Servlet 2.3 spec web apps, but it should be able to load existing ones (created, for example, by NB 3.5). You can fake creating one by creating a webapp and in web.xml change the servlet spec version from 2.4 to 2.3. However, on doing so, the DDBeans still identify themselves as J2EE 1.4. The behavior is as follows: DDBeanRoot.getDDBeanRootVersion() is not implemented (hardcoded to return null). This JSR88 method is the preferred method to use for determining the J2EE version of a module. DDBeanRoot.getModuleDTDVersion() returns "1.4". This method is supposed to be replaced by the above method though. DeployableObject.getModuleDTDVersion() returns "1.4". This method is deprecated in JSR-88 1.1 also. Anyway, for a Servlet 2.3 webapp, I believe all of these methods were supposed to return "1.3".
Do we support generating/saving web.xml 1.3 version? If not I don't this is a bug. Peter: I still don't understand the issue. A J2EE 1.4 web.xml still can refer to 2.3 servlets. So having a 2.3 servlet in the module, I don't think it should mean we should save web.xml as J2EE 1.3?
So it looks like I misstated the version numbers then. So, for a web app implementing Servlet 2.4, should the version methods return "1.4" or "2.4". In order to allow distinguishing a Servlet 2.3 webapp from a Servlet 2.4 webapp inside an EAR for example, it seems they would have to return the Servlet Spec version, not the J2EE version. Does anyone have a different reading of the JSR-88 specification? It is not clear on this distinction as far as I can tell.
Web module now returns 2.3 or 2.4 as its version and DDBeanRoot.getDDBeanRootVersion() delegates it. I think there was also a problem that the xpath events were lost after the version changed and I am not sure if that was filed separately. I am reassigning to Nam to check this and fix if needed.
What j2eeserver listens to is the BaseBean returned from the J2eeModule.getDescriptor() call. Even though the WebApp root object survive the version reparsing, this contained BB is gone with the discarded old graph. So I don't see we can avoid the need of explicit API to detect module version change something like: J2eeModule { void addModuleVersionListener(VersionListener vl); } This seems to be not reasonable at this time. So, I think the best we can do is documentation and minimize the effect by allow the action of close/open the ConfigDO to be the manual refresh of the whole DDBean and ConfigBean caching.
Complete the fix with VersionListener implementation. On version change we do save if needed, disposal of uneeded listeners, reload configuration storage, refresh ConfigBeanTopComponent.