beginOperation and endOperation in 2.5.0 Beta

[subes]

Hi,

we have been using the following piece of code to fix some synchronization issue with fields getting values set from a model:

Code: [Select]

public void synchronizeGUI(){
/*
 * SwingUtilities.invokeLater is used to delay the synchronization until the controls are visible
 * in the UI. This fixes a problem with tabbed windows where the values are only getting added
 * to the fields after the window updates.
 *
 * The delay fixes this problem for Swing, but AjaxSwing has to be notified about the execution
 * being delayed in EDT. To do so, we have to use AjaxSwingManager.beginOperation() and
 * AjaxSwingManager.endOperation(). Only after endOperation is called, AjaxSwing updates the
 * web content and shows the fields with correct values. Those methods do nothing, if not in AjaxSwing.
 */
AjaxSwingManager.beginOperation();
SwingUtilities.invokeLater(new Runnable(){
public void run() {
DisplaySyncManager.synchronizeGUI();
AjaxSwingManager.endOperation();
    }
});
}

This fix worked for 2.4.2 but stopped working in 2.5.0 Beta (just verified to be sure).
Have there been any changes to the way beginOperation() and endOperation() work?

[Support Team]

There hasn't been any changes to beginOperation/endOperation. The only relevant changes are with thread context class loader, but that shouldn't have effect. I've tested beginOperation/endOperation on our demos and it works. Can you please attach the log file?

And when you say it stopped working, what exactly is happening? Does AjaxSwing start rendering before endOperation() is called, so your updates are not picked up?

[subes]

It is rendering before endOperation, thats why the fields that get filled by DisplaySyncManager.synchronizeGUI() don't show the values.
Atleast thats my guess. ^^

I've attached both the log file of 2.4.2 and the one of 2.5.0 for comparison.

The moment when the effect occurs is the last dual beginOperation/endOperation block.
I also added a trace message when DisplaySyncManager.synchronizeGUI() is called.

I tried removing the inner beginOperation/endOperation so only the second one actually runs, but that did not help.

[subes]

eh, files attached in this post ^^

[Support Team]

In the log file it is very clear that rendering of windows occurs after the call to endOperation(), so it appears that AjaxSwing is working correctly. Be advised that begin/end operation are not cumulative, so the first call to endOperation() completes the entire operation. I've created an enhancement request on this, but again, from the log it doesn't seem to be an issue.

So we may be dealing with a different bug. What happens if you refresh the browser - do you see updated values?

What components specifically do not get updated correctly?

Is there multithreading inside synchronizeGUI()? What does it do?

There were some speed optimizations on rendering internal frames, menus and tables. Is your trace level set to 10?
I looked thru the log files from 2.4.2 and 2.50 and they actually appear to be almost identical.

[subes]

In the log file it is very clear that rendering of windows occurs after the call to endOperation(), so it appears that AjaxSwing is working correctly. Be advised that begin/end operation are not cumulative, so the first call to endOperation() completes the entire operation. I've created an enhancement request on this, but again, from the log it doesn't seem to be an issue.

This was no issue in 2.4.2 and I also tested removing the inner begin/end block with no effect.

So we may be dealing with a different bug. What happens if you refresh the browser - do you see updated values?

The values stay empty.

What components specifically do not get updated correctly?

All components are empty.

Is there multithreading inside synchronizeGUI()? What does it do?

There is no Multithreading in it, it just puts the values from the model into the textfields.

There were some speed optimizations on rendering internal frames, menus and tables. Is your trace level set to 10?
I looked thru the log files from 2.4.2 and 2.50 and they actually appear to be almost identical.

Last log files were with trace level 9. I've set trace level to 10, removed the inner begin/end and attached new log files.

[Support Team]

There are some minor differences in the logs but nothing that would explain why the values are not showing up correctly.

First, if after refreshing the page you are still not seeing correct values in the components, this suggests that the issue is not with multithreading/synchronization, but rather with something else.

Can you verify that the values are actually set to the controls? Maybe you can call a get() right after set() to double check that the value has been set. It's hard to provide meaningful explanation without seeing your code and being able reproduce the problem.

Is there some other code that would reset the controls?

Which components are failing (class name)?

From the log files it seems that 3 controls are picked up for AJAX update - JLabel, JPanel and SelectionArea. Are these the controls you are setting values to?

If non of this helps, we may have to issue a patch for you to try with some of the changes reverted. Which JDK version are you using?

[subes]

I would like to try the patch. As I said, the code works fine with Swing and AjaxSwing 2.4.2.

I am using JDK 1.5.0_12.

I've attached screenshots that show the difference. As you can see, almost all fields get changed some way but AjaxSwing 250 does not pick up those changes.

[subes]

Well, I even tried delaying the endOperation for 1 sec. It is taking effect in the GUI.
But AjaxSwing 2.5.0 still does not show it correctly...

Code: [Select]

public void synchronizeGUI(){
    AjaxSwingManager.beginOperation();
    SwingUtilities.invokeLater(new Thread(){
public void run() {
DisplaySyncManager.synchronizeGUI();
    }
    });
   
    if (AjaxSwingManager.isAjaxSwingRunning()) {
    new Thread(){
    @Override
    public void run() {
try {
sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
ClientAgent.getCurrentInstance().setUpdateBrowser(true); //From DemoFrame.java
AjaxSwingManager.endOperation();
    }
    }.start();
    }
    }

Well, im still seaching for other possible reasons.

[Support Team]

Can you email your source file(s) to support@creamtec.com?  There must be something about this dialog that's different from others, which is what probably makes it break.

[subes]

It's not that easy. This is not a frame but a framework that creates frames and does some other stuff. So I can't just send you the code. ^^
I'll keep on trying to isolate the problem but I didn't have much luck as of now.

As long as this problem is not resolved we will not be able to upgrade to 2.5.0.

Different about the dialog is that it is tabbed. Normal frames work fine.

[subes]

I'm starting from scratch again with this bug, removing the ajaxswing fix and trying to change other stuff.
It seems this workaround was just a dirty hack...

Thank you for your help, I will tell more when I know more.

[subes]

Ok, I've created a sample that shows the current variation of the problem.
The sample code sets the text of components during tab change.

Relevant for the execution is isShowing.
Under Swing it works fine. In AjaxSwing 2.4.2 and 2.5.0 the second tab always keeps its content empty.

My current implementation of the new fix is the same as in the sample. See attachment.

The trace output shows that only when I resize the window, I get the showing event and also somehow both textfields are showing.
Though I need a window update on tab change and the isShowing behaviour of Swing.

[subes]

I just rechecked.
With the sample I posted the behaviour is the same in 2.5.0 and 2.4.2.
But when trying our framework code, the initial tab stays empty until a postback is done in 2.5.0 (so no real change from the initial problem).
So after clicking a button the fields get their content.

Though the implementation of the sample shows the behaviour of the framework simplified.

[Support Team]

Thank you for your post. Your TabTest has helped us to identify and fix the problem, which we treated as a bug in AjaxSwing. The root problem was that you were changing the label text in ComponentEvent listener. That event was not firing at the right time in AjaxSwing, it was firing during rending so the changes to the component were not picked up.

We've changed AjaxSwing to fire those events during update phase, and your TabTest works now. I'll post an update when we release Beta2, and once you get it your code should work. You shouldn't even have to use beginOperation/endOperation.