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.
Current Sierra Build 020206 on RH 7.2 1. Create a web module 2. Choose "web.xml", select servlet-mappings property item from property sheet Add the default "servlet-mapping" shown i.e, servlet name is "my_servlet" and servlet URL is "/my_url_pattern" try executing some JSp/Servlet in this web module Tomcat throws : 2002-08-06 17:55:33 ContextConfig[] Configuration error in application web.xml java.lang.IllegalArgumentException: Servlet mapping specifies an unknown servlet name my_servlet at org.apache.catalina.core.StandardContext.addServletMapping(StandardContext.java:1625) at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.util.xml.MethodSetter.end(XmlMapper.java:879) at org.apache.catalina.util.xml.XmlMapper.matchEnd(XmlMapper.java:419) at org.apache.catalina.util.xml.XmlMapper.endElement(XmlMapper.java:119) at org.xml.sax.helpers.XMLReaderAdapter.endElement(XMLReaderAdapter.java:347) at org.apache.xerces.parsers.SAXParser.endElement(SAXParser.java:1403) at org.apache.xerces.validators.common.XMLValidator.callEndElement(XMLValidator.java:1480) at org.apache.xerces.framework.XMLDocumentScanner$ContentDispatcher.dispatch(XMLDocumentScanner.java:1204) at org.apache.xerces.framework.XMLDocumentScanner.parseSome(XMLDocumentScanner.java:381) at org.apache.xerces.framework.XMLParser.parse(XMLParser.java:1081) at org.xml.sax.helpers.XMLReaderAdapter.parse(XMLReaderAdapter.java:223) at javax.xml.parsers.SAXParser.parse(SAXParser.java:314) at javax.xml.parsers.SAXParser.parse(SAXParser.java:89) at org.apache.catalina.util.xml.XmlMapper.readXml(XmlMapper.java:275) at org.apache.catalina.startup.ContextConfig.applicationConfig(ContextConfig.java:256) at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:824) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:224) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:155) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1131) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3334) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1123) at org.apache.catalina.core.StandardHost.start(StandardHost.java:612) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1123) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:307) at org.apache.catalina.core.StandardService.start(StandardService.java:388) at org.apache.catalina.core.StandardServer.start(StandardServer.java:505) at org.apache.catalina.startup.Catalina.start(Catalina.java:776) at org.apache.catalina.startup.Catalina.execute(Catalina.java:681) at org.apache.catalina.startup.Catalina.process(Catalina.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:243) 2002-08-06 17:55:33 ContextConfig[]: Marking this application unavailable due to previous error(s) 2002-08-06 17:55:33 StandardContext[]: Error initializing naming context for context 2002-08-06 17:55:33 StandardContext[]: Context startup failed due to previous errors 2002-08-06 17:55:33 StandardContext[]: Error initializing naming context for context
This bug is not completly a NetBeans bug - property editors are specific for S1S. OTOH we may think about such action that could be performed on demand. What you suggest is a semantic validation that depends on target server. The check whether document is valid (or well-formed) cannot reveal such problem. New spec (JSP2.0) may improve this little bit when XML schema will be used but I am not convinced that there is general solution.
We shouldn't allow putting a <servlet-mapping> that isn't related to some existing <servlet> element.
The problem is that the deployment descriptor can't know what's available on the server. It's legal to deploy servlets directly to shared repositories on the server, and not that uncommon either. There is no generic API for figuring out which classes are available on the server (Servlet 2.4 provides APIs which makes it possible to discover libraries, but not individual classes, and this won't cover our needs here since that's up to the libraries to declare, not to the server to discover). The best we can do is to see if the class is available in WEB-INF and if not warn (with a "don't you ever show this dialog to me again!" option). I'm not sure if I'm in favour of that as a solution from a usability point of view. We need Jeff to take a look.
It seems like Ana's suggestion is reasonable, since we might not want to restrict using the DD editor to add mappings for already deployed servlets (just give the warning).