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 was following the web services tutorial and erroneously created a web module and then realized I was supposed to build a jar file of the current source first. I copied the files from WEB-INF/classes to the root of the web module and then unmounted WEB-INF/classes. I then attempted to delete META-INF and WEB-INF. Got an exception.
Created attachment 14108 [details] StackTrace for NPE
This is in RC1.
Actually, this is worse than I thought - I get an NPE whenever I select the directory after that. I had to restart the IDE to make that go away.
Ana, I agree there should be a way how to make the filesystem non-webmodule, but in my opinion, deleting the WEB-INF folder or the deployment descriptor is quite rare and abnormal case and hence it is IMHO not a P2.
I can't think of a method *other* than deleting the WEB-INF directory to turn it into a non-web module :) so I don't see how this is a corner case. Do you think it's unusual for people to create a web module when they needed to create a regular directory? Maybe it is, I don't know. (But at least I have done it before - see issue 40099 where I complained about something else in that context - back then the IDE didn't get as screwed up as it does now though. The point is that if you do make a mistake that requires you to convert a web module to an ordinary directory, basic IDE operations do not work. A user can reasonably expect to be able to unmount a directory from the file systems tab (it's a UI action), and to delete a directory (likewise) without the IDE getting into such a state that it needs to be restarted. Instead, we'd have to explain that they need to exit the IDE before doing the delete from the command line.
I still thing this is very unusual case. The *other* way I mentioned could be something like a new action Tools -> Cancel Webmodule. Anyway, IMO this discussion is useless since we wont be likely able to fix this to 3.6. In 4.0 the existence of a j2ee project itself will -fix- this problem (I hope noone will create a j2ee project by an accident and try to convert it to a j2se project by deleting a bunch of files ;-) ).
I am a little worried that we speculate what users do and do not do this way. I have said I think it's OK to waive it privately, but Ann has said that there might be release criteria that prevents this: that we can't release the product with a known NPE. If that's the case, then it's irrelevant what UI actions may be introduced or removed in the future. The only thing that matters is that the UI action is there and doesn't work. We've been wrong before when we guess how people go about developing.
I've been given the impression (and agree with) that we should try to catch all NPE that we know of and can reproduce. Otherwise, it just gives the user a bad impression of the product. If we're lucky, they file an issue. If we're not, they may abandon the IDE. The bug might not have to be completely fixed but at least the NPE is caught somehow and perhaps the user gets an error dialog or something telling them how to proceed. I guess in this case the user has to restart the IDE.
Yes, we should try to at least catch all NPEs and display a friendly message, but not in high resistance mode. The fact that the exception appears is not a showstopper, hence we should not fix it now. I will ask for a waiver.
Waiver approved.
Chris, one more in the relnote parade....
For the Release Notes Online help topic "Changing Web Module Filesystems Into Standard Filesystems" is incorrect. If you follow the instructions in this topic, the IDE will output Null Pointer Errors (NPEs) when you try to open files for editing. Use the following instructions instead. 1. Unmount the filesystem. 2. In the operating systems file manager, move any files under WEB-INF that you want to save, and delete the WEB-INF directory. Do the same with the META-INF directory. You must rename or delete both of these directories. 3. Remount the filesystem.
I changed the behaviour of the monitor to include the text as described, but I don't think it's enough. I will attach the resulting page from Tomcat in the next message. The problem I have is that the text combined with the stack trace makes it look like it is the MonitorFilter that is causing the problem. I think that this text needs to make this clear, or otherwise I'll just get a bunch of bugs logged against the monitor. I would prefer to start the message with: The HTTP Monitor's server side component has caught a java.lang.StackOverflowError. This happens when an infinite loop in the web module... The way things are, it looks like the message comes from the Tomcat server.
Created attachment 14399 [details] Error page created by Tomcat server
I think you posted to the wrong bug, but your revised text is ok with me.
Ooops, disregard my last messages!
This appears to be fixed. In NetBeans 4, no unexpected behavior after deleting WEB-INF and META-INF is observed.
v