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.
I'm keeping tag-libraries and subsystem libraries appart from the main web application. Currently they are defined with the generic 'Java Library', despite being 'Web Modules'. In order to compile for the servlet API I need to manually create a ServletJSP library, pointing at both APIs in bundled Tomcat. This library definition is hardly attached to NB intallation folder, therefore, updating means redefining the library. Being this a common scenario, why Bundled Tomcat isn't exposed as a library? It would facilitate the creation of those 'Web Modules', making them portable among NB versions. Do I miss something?
Wrong module, reassigning.
What to do in case that you deploy your WebApp to SunAppServer? Should we compile against Bundled Tomcat or AppServer JAR files? I would prefer add possibility to add 'All server JAR files' of any server to Java project classpath (if possible).
Not bad, but it doesn't change the fact. You could compile using Bundled Tomcat library and deploy into SJSAS, JBoss, etc. Using Bundled Tomcat keeps easy adding servlet and JSP APIs. Maybe 'Bundled Tomcat' isn't the right name and changing that to 'Servletx.x/JSPx.x' would be a better idea. Or even better, moving those apis out of Tomcat and back to a standard library. The real thing is that we want both APIs available, not the implementing container.
Would someone please explain clearly how to make this transision to use Bundled Tomcat on libraries which which previously used the jsp20 and servlet24 libraries, so we can start using the released version of 4.1. I have asked in the nbusers forum and gotten zero response. I don't care if I have to slightly change the project settings. The project was created as a simple java jar, which used these libraries to implement a taglibrary. The only option I can think of that we are left with is making binary copies of the servlet and jsp libraries in an extra directory in the project. Why should this be necessary? It clearly is not a web project itself since it has no web pages, etc. and should be bundled as a jar, not as a war. It gets used by multiple other web applications. I see no explanation of how to carry forward here. How would I compile using Bundled Tomcat Library, when it does not appear in the library list (short of manually adding it as a library on the machine of every user).
I work from Linux, Mac, etc. and experience the problem so I have changed Platform and OS to All. This also works fine in the beta version and is preventing us from using the final release, which I would have thought was a regression, rather than a feature request, but I'll leave that up to the judgement of someone else, maybe something removed between beta and final release can be rationalized as a misfeature of the beta (I sure miss the feature :-).
rayjhax, to workaround this problem with servlet/jsp apis, i created a new library with [NBInstall]/netbeans-4.1/enterprise1/jakarta-tomcat-5.5.7/common/lib/servlet-api.jar and jsp-api.jar. Because this path depends on NB version, I copied those libraries into a generic folder and build up the library from there.
Rayjhax, I would also recommend you the same workaround. Marking as 4.2-candidate and moving to j2eeserver.
As I began to indicate before, I believe this would involve forcing every user to perform the library addition manually whenever they reinitialize the program's settings (it tends to corrupt itself fairly frequently), which is not a reasonable option. The library feature seems completely worthless to me (at least I have not discovered how to make it useful) for this reason, except for useful libraries that come pre-installed, (none left in 4.1 final release). If there is a better way to use the libraries option than that, I need a clear explanation of how since they do not seem to me to be stored in any part of the settings that are reasonable to share between users (especially users of different platforms) at least last time I tried to define them. That is why it is so important to have basic ones defined at installation for standard things such as jsps and servlets that are supplied as part of the package anyway.
Won't be part of 4.2 - it needs non-trivial changes in Libraries management. It is not still clear how to solve it.