Bugzilla – Full Text Bug Listing
| Summary: | Error when selecting J2EE Module dependencies | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [WebTools] WTP Common Tools | Reporter: | Philipp Mising name <faralla> | ||||||||||||
| Component: | wst.common | Assignee: | Carl Anderson <ccc> | ||||||||||||
| Status: | RESOLVED FIXED | QA Contact: | Konstantin Komissarchik <konstantin> | ||||||||||||
| Severity: | major | ||||||||||||||
| Priority: | P3 | CC: | cbridgha, david_williams, suchko.pm | ||||||||||||
| Version: | 2.0 | Keywords: | helpwanted | ||||||||||||
| Target Milestone: | --- | ||||||||||||||
| Hardware: | PC | ||||||||||||||
| OS: | Windows XP | ||||||||||||||
| Whiteboard: | |||||||||||||||
| Attachments: |
|
||||||||||||||
I don't know what you did, either. I have grabbed builds since then and have been unable to reproduce. The problem that the stack trace shows is a Component (AppClient, Connector, EAR, EJB, or Web) that does not have a .component file associated with it. Could you create a new workspace with the bad component, zip it up, and attach it? (Or give clear steps on how to reproduce this?) (In reply to comment #0) > Created an attachment (id=75648) [details] > the corresponding stacktrace > I don´t know what I did, because this worked before, but now I don´t seem to > have a chance to get rid of this bug anymore. I already tried this on a totally > new project, in a new workspace, with a clean installation of eclipse, but > nothing helps. > Here is what happens: > When I click on J2EE Module dependencies in the properties window, I get a > message saying "The currently displayed page contains invalid values" > I´ll attach the stacktrace I used the debugger to determine that this was being caused by projects in teh workspace which had a .settings/org.eclipse.wst.common.component file which looked like this. <?xml version="1.0" encoding="UTF-8"?> <project-modules id="moduleCoreId"/> I am not sure how the file got that way but I suspect since I am using Eclipse under RAD (v 7.0.0.3) that one of the migration builders did this (I obviously did not go in there and edit them manually to cause this.) Another adopter/user (Paul) was able to reproduce this and give me steps, so I am reopening this. (And this problem has been around since the 1.5.x timeframe.) Created attachment 79229 [details]
Check for null components
The original changes were provided by Paul- I tweaked them to comply with WTP code standards (and to avoid unnecessary logging.) This patch goes on top of WTP 1.5.5
Created attachment 79230 [details]
Updated patch (works for both 1.5.x and 2.0.x)
Removed an extraneous import (which caused a compile error with the 2.0.1 compiler settings). Otherwise, it is the same patch file (and can be loaded on 1.5.x, 2.0.x, and 3.0.)
Carl, you don't really describe the steps to reproduce. Can they be described here? I assume its not reproducible with just WTP? Are there some other work around for 1.5 based stream? (such as hand fixing the component.xml file?) Is this frequently seen by everyone? Or, just a few times, some special types of setups/projects? Also, you say "original changes were provided by Paul" ... technically he should be the one attaching them here then, as that automatically makes it EPL. In this case, since is basically just added null checks, I wouldn't imagine there's any real issue, but, just wanted to remind you of the process. Also, normally the contributors name would be added to the files prolog, with bug number, etc. As I noted in comment #2, Phillip never gave me steps to reproduce. And Paul is not sure exactly how he got a Java Project that has a nearly empty component.xml file- my assumption is that this is from a migrator that is not functioning properly. (Although it may be a migrator that was provided in an adopter's product.) I have not followed up on any other workarounds, since I was not able to reproduce this, and since Paul contacted me with a proposed solution. (However, he sent complete java files that did not follow WTP coding guidelines, so I adopted his changes to meet our standards, and created a patch file from them.) The most difficult part about this problem is that the NPE is logged, things don't work, and you are not notified as to what project(s) are causing the problem. I suppose that I could have Paul try to just delete the invalid component.xml file. And as to the frequency, so far I only know of Phillip and Paul's cases, but this is the type of problem where essential things (such as the MANIFEST.MF editor and the J2EE Dependencies page in Properties) stop working in the workspace, and in Paul's case, it was simply a Java project that caused this problem. Paul, do you want to attach the Java files you originally sent? (That way, there is no question of us following the EPL.) Created attachment 79350 [details] Fixed file as requested in comment #7 Created attachment 79351 [details] Fixed file as requested in comment #7 I discussed this patch with Chuck Bridgham (the component leader). He does not like the fact that the patch allows WTP to work in an environment where there is a badly formatted component.xml file. As such, we need to do further investigation into what caused the bad state, and fix that cause. (In reply to comment #10) > I discussed this patch with Chuck Bridgham (the component leader). > He does not like the fact that the patch allows WTP to work in an environment > where there is a badly formatted component.xml file. As such, we need to do > further investigation into what caused the bad state, and fix that cause. While I could not agree more that the source of the corruption should be fixed, I also am a strong proponent of defensive coding. Even if that source were fixed, given the complexity of Eclipse, it is very likely that another plug in could corrupt the file at some point in the future. Since this bug is has such a severe impact to the product's functionality, I cannot believe that it is going to be ignored. With all due respect, I strongly disagree with the component leader on the decision to sweep this bug under the proverbial carpet. +1 on Comment #11 ... couldn't have said that better myself. I think Chuck is on vacation, so I'll re-open on his behalf based on this latests comments. At least until he has a chance to respond. I'll make a few high level observations. It is good to check for null, if something can ever be null (corrupt file or not). But, I also appreciate the concern about continuing in the presence of a corrupt file. Perhaps a valid solution to both concerns is to instead of continuing in the case of null (if I'm understanding the patch, at all) is to simply log a message detailing the information about the corrupt file. I seems this would help users to restore the corrupt file, from their own local history, or from some source code management system. I could imagine many users would appreciate this opportunity, and knowledge, instead of just continuing with what could be figured out or reconstructed. I could also imagine more defensive programming, by inserting XML validation checks at various points ... if the file didn't even pass XML validation, that would be a sure sign it was corrupt. I've marked the bug as help wanted, since this would be a good opportunity to contribute. Lastly, Paul, it really does help to have patches attached to bugs, instead of full source files. Remember, the core developers are trying to deal with thousands of issues, so anything you can do to save them time make it more likely they will address your concerns. I just barely understand the issues here, so apologies in advance if my comments are not helpful. Thank you to everyone. I'm finally getting back to this defect, and while I do think adding a null check here and there can be good, I also don't want to hide a real problem, so I would like at the very least some logging introduced indicating a problem with the file. I'm reducing this from critical, as it seems no one is actually blocked currently. Removing target, since this is a helpwanted now. Comment on attachment 79230 [details]
Updated patch (works for both 1.5.x and 2.0.x)
Marking the rejected patch as obsolete.
It looks like, between what David Williams seems to have done to VirtualResource, and what I just fixed in bug 250004 that this is now fixed. (Note that bug 250004 plugged a hole that could allow an empty component file to be created.) |
Created attachment 75648 [details] the corresponding stacktrace I don´t know what I did, because this worked before, but now I don´t seem to have a chance to get rid of this bug anymore. I already tried this on a totally new project, in a new workspace, with a clean installation of eclipse, but nothing helps. Here is what happens: When I click on J2EE Module dependencies in the properties window, I get a message saying "The currently displayed page contains invalid values" I´ll attach the stacktrace