Community
Participate
Working Groups
I thought it would be nice to be able to set a little more information in a successful requestMonitor. To do that, I was going to use the status, and use a message or a code. The problem is that successful request monitors do not preserve the status when it is successful, so any special content is lost. It is easy enough to replace in RequestMonitor.java protected void handleSuccess() { if (fParentRequestMonitor != null) { fParentRequestMonitor.done(); } } with protected void handleSuccess() { if (fParentRequestMonitor != null) { fParentRequestMonitor.setStatus(getStatus()); fParentRequestMonitor.done(); } } The problem is that we overide handleSuccess() and handleCompleted() all over the place, and those also don't preserve the status(). We wouldn't have to change anything actually, but if anyone wanted to use special content in a successful RM, they would have to make sure they chain of RMs did preserve the status(). This is kind of a enhancement in the DSF programming style... So I'm not sure it is something we should do.
Interesting, I never thought of this use case before. I agree that if we're going to try to fix this bug we should go through all the places in open source where handleSuccess/handleCompleted are overridden and fix them. Another complication may be that if there are multiple async operations being performed for a single client operation. Then the OK statuses would need to be merged into a single status in the parent RM. Where as in case of an error, the first error encountered is usually reported directly to the client and no merging of statuses is needed.
(In reply to comment #1) > Interesting, I never thought of this use case before. I agree that if we're > going to try to fix this bug we should go through all the places in open source > where handleSuccess/handleCompleted are overridden and fix them. > > Another complication may be that if there are multiple async operations being > performed for a single client operation. Then the OK statuses would need to be > merged into a single status in the parent RM. Right, I had not thought of that. Well, I worked around this 'limitation' :-) So I don't really need it anymore. I think it would be nice, but there is no way I'm going through all the code to fix the overridden handleSuccess/handleCompleted :-) Let's leave it as an exercise to the reader.
