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.
The httpserver module contains some old and obsolete copy of tomcat. I guess tomcat 3. Given the fact that the IDE also contains tomcat 5.5.x this is a very nice example of duplicated bits - e.g. bigger download size, outdated functionality, poor architecture. The httpserver shall share the most recent tomcat version.
We internally use in the IDE some simplified version of Tomcat 3.x.y (+ related Servlet API) to make internal HTTPserver functional. We also internally use some bits from Tomcat5 in web support (JSP parsing) and bundle whole Tomcat5. It is possible that we also depends on something from Tomcat4. As far as I understand it the goal is to simplify these dependecies and make building of packages easier. Here in HTTPserver we can 1) update it to recent Tomcat3 version. We need to be carefull here as noone remembers what we needed and how we repackaged this in the past. OTOH patch in http://www.zarb.org/cgi-bin/viewvc.cgi/rpms/devel/netbeans/netbeans-modules.patch?root=jpackage&view=markup&rev=1.2 can help us 2) migrate to newer version of Tomcat. We can use Rich's contribution of update to Tomcat 4 and try to update it to Tomcat 5 (change between 3 and 4 was much bigger). I am afraid that the result will be much bigger beast than we have now with all deps on things like commons-*, catalina-{core|bootstrap|...} 3) similar like 2) but migrate to GlassFish
I don't see why this is a DEFECT, definitely not according to the bug priority guidelines. The biggest reason to use Tomcat 3.x (besides the fact that it is a lot of work to migrate to a newer one and I don't see any end user value in this work) is that Tomcat 3.x can be used as a very lightweight container, which is not the case with Tomcat 4 and 5. Also, the copy of Tomcat 5.5 that we have has to be very easy to decouple from the IDE (ideally, the integration should be done by the installer). If we use it in the embedded HTTP server, it would be much harder to decouple.