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.
Allow other modules to register servlets which the HTTP server module would run. This would allow extending the functionality of the internal server. For example, currently there is a Javadoc servlet, which is a part of the HTTP server module, although in fact it should be a part of the Javadoc module. The registration should be done through modules' XML layers and should contain at least the servlet class name and URI mapping.
Target milestone 3.3.1.
I'd think that the preferred way to do this would not be through layer files, but through web.xml files, which are already fully descriptive of servlet contexts. I'm already accomplishing this in my httpserver_tomcat4 module by having modules that wish to register servlets drop .war files into netbeans/system/httpserver/webapps
I agree that registering servlets through standard web.xml files is a better way than the layer file. [This enhancement request was entered when we did not support .war files, but with Rich's module, the situation is now different.]
Set target milestone to TBD
I have another use case. I need to add new content to be served in new projects based IDE. My content is generated Javadoc in following formats: HTTP URL, local folder and JAR archive. I need to support showing Javadoc content in browser (possibly external). I have trouble with the JAR archives that cannot be accessed directly by a well-known URL. Currently the httpserver serves global repository content. But I cannot mount jar archive content in global repository because its project specifics. Conceptually, ideal registration would look like: at module layer: <file name="HTTPContentProviders"> <file name="handlerProtocol.instance"> <attr name="instanceCreate" .... /> URL producer API: HTTPContent.createURL(String handlerProtocol, String content) and a callback InputStream serve(String content); Besides, in Jini module I solve similar problem using generic (unsupported) custom servlet and passing around URLs pointing to it "http://:8082/servlet/o.n.m.j.s.ExportServlet/content_path-info". This raw approach suits too. I do not know WARs.