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.
Copy IDE bundled tomcat's server.xml to a dir and mount it Righ click on this server.xml you would find popuup men with menu items similar to the "server.xml" of tomcat. The new copy is just like a regular XML file. Why's is the IDE showing popup menu items here for tomcat's config? ( I just tried creating a new XML doc called 'server.xml' but that didn't have these menu items).
The original intention was to recognize the "Tomcat40DataObject" by the : - <Server> element - mandatory "port attribute" of the <Server> element - mandatory "shutdown attribute" of the <Server> element The actions which have no sense (in case the configuration file isn't mounted in the Server Registry) - are disabled. Is it really a bug ? What do you think Jeff ?
I think it's a bit confusing that you can mount the Tomcat401 directory in the file system, rename the existing server.xml and create a new server.xml--however, the new server.xml file will not be used as the config file (even if it meets all the criteria for being a Tomcat 4 config file). I think it would be less confusing if server.xml was treated like any other XML file *except* when it is shown in the server registy. For example, what if I'd like to use the XML editor to modify the server.xml. That is currently not possible with the Tomcat40DataObject. In my opinion, this is not a P2 bug, but more like a P4. And perhaps it could be reclassified as a Feature, since the Tomcat40DataObject is missing an action to launch the XML editor. It's also missing many of the generic XML actions like "Check XML", "Validate XML", "Add <new element type>" and "Save as Template..."
We discussed how to fix this bug - here in Prague. I agree that the reasons given by submitter, Damian Frach and Jeff Hoffman are logical - server.xml should behave like regular xml file outside the server registry. The fix seems too complicated for Orion FCS, because the Tomcat4.0 configuration file was build on the Tomcat40DataObject which extends XMLDataObject. Thus, it is difficult to distinct, whether the file is the part of the Server Registry or not. The smart fix requires to change the architecture of the Tomcat4.0 instalation representation. Considering the fact, that the bug does not principally bound user possibilities to handle server.xml file as regular XML file(there doesn't even exist the DTD file to server.xml so it is not possible to validate it), I am changing the priority to P4. Also I am changing the type to "FEATURE".
Set target milestone to TBD
Fixed in 4.1.