Community
Participate
Working Groups
Created attachment 200316 [details] stack trace When disposing the Display sometimes I get a stack trace because the text size code tries to get a request parameter from the request provided by FakeContextUtil which throws an exception. Would it be safe for the proxy to support getProperty by returning null?
From my current understanding, it might obscure the true source of the problem if getProperty() wouldn't throw an exception. Why does the text size determination query the request parameter in the first place? Can you provide a simple snippet (preferrably without depending on the Workbench) to reproduce the issue? BTW, Display must not be subclassed (see the JavaDoc)
> Why does the text size determination query the request parameter in the first > place? It looks like the root of the problem is a label is having its text changed in response to an Editor being deactivated. The editor is being deactivated because the workbench is shutting down and closing/saving all open editors in the process. The work bench is shutting down in a non-request because the session is being invalidated. I don't want to have to check for a valid context every time I set a text property in a listener attached to the work bench that may be fired when it shuts down. > Can you provide a simple snippet (preferrably without depending on the > Workbench) to reproduce the issue? At this point in time, no. We're a week or so from a production deployment and time is being pushed already. > BTW, Display must not be subclassed (see the JavaDoc) I know its not supposed to be... I do it to run certain things in the next http request to work around bug 332243
(In reply to comment #2) Chris, I didn't mean that the application code should check the context or anything like this. The application code doesn't do anything invalid. I just found the fact that text size determination queries the request at this occasion looks suspicious.
> I just found the fact that text size determination queries the request at this > occasion looks suspicious. The stack trace looks fairly logical. The label gets its text set, a layout is triggered, the text size needs to be determined, the text size determination code gets executed.. It just happened to happen while the session was being invalidated so its got a fake context and text size determination is not compatible with the servlet proxy
(In reply to comment #4) > > I just found the fact that text size determination queries the request at > this > > occasion looks suspicious. > The stack trace looks fairly logical. The label gets its text set, a layout is > triggered, the text size needs to be determined, the text size determination > code gets executed.. I totally agree with you that far. It is just fine that the text size determination code gets executed. I am just saying that it should not access the request. From my understanding, TextSizeUtil#determineTextSize() looks up the string to be measured in the text size store. If it cannot be found, the string is added to the 'items to be measured' that will be sent with the next response. In MeasurementOperator#addItemToMeasure() however the request is queried if it holds the size for the string to be measured. And this is what I don't understand. If the request held a size for that string it would have been put in in the test size store already (see MeasurementOperator#readMeasuredTextSizes()) If would rather try to remove the call to requestContainsMeasurementResult(). If doing so however, a test fails and I haven't figured yet what this test is for.
(In reply to comment #5) Measurement results will be handled in the MeasurementListener#afterPhase of the PROCESS_ACTION phase. Therefore the process action phase could indeed add items for which the search results are already in the request.
I'm still getting this issue occasionally on the latest nightly build. When the exception happens while JBoss (tomcat..) is shutting down, the shutdown is aborted by the uncaught exception so the JVM has to be forcefully killed.
All I'm asking for is a [code] } else if( "getProperty".equals( method.getName() ) ) { result = null; [/code] added at line 118 of org.eclipse.rwt.internal.lifecycle.FakeContextUtil null is a valid response from the getProperty method.
Created attachment 213236 [details] Stacktrace at my side
(In reply to comment #6) > Measurement results will be handled in the MeasurementListener#afterPhase of the > PROCESS_ACTION phase. Therefore the process action phase could indeed add items > for which the search results are already in the request. PROCESS_ACTION phase is needed for resize events execution (textSizeRecalculation.execute()). But why measurement results are handled in MeasurementListener#afterPhase? We could handle measurement results in MeasurementListener#beforePhase and remove the check from MeasurementOperator#addItemToMeasure.
Created attachment 213624 [details] Snippet to reproduce the exception
Created attachment 213648 [details] Proposed patch This patch handle measurement results in MeasurementListener#beforePhase of PROCESS_ACTION and remove the check from MeasurementOperator#addItemToMeasure. JUtin test added. Existing tests adjusted.
Just another note - we have a bug opened (bug 350300) to reconsider the proxy implementation in FakeContextUtil.
Applied patch to master. Fixed with commit fe0f2b1970115ee6cc02bec5c29ec37b141f7da7.
